INTERNET-DRAFT Daniel R. L. Brown
draft-ietf-smime-ecc-01.txt Certicom Corp
14 July, 2000 Expires: 14 January 2001
Use of ECC Algorithms in S/MIME
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document is the second draft of a profile for the
incorporation of Elliptic Curve Cryptography (ECC) public key
algorithms in the Cryptographic Message Syntax (CMS). The ECC
algorithms support the creation of digital signatures and the
exchange of keys to encrypt or authenticate message content. The
definition of the algorithm processing is based on the ANSI X9.62
standard and the ANSI X9.63 draft, developed by the ANSI X9F1
working group.
Brown Expires January 2001 [Page 1]
Internet-Draft Use of ECC in S/MIME July 2000
Table of Contents
1 Introduction ........................................ 3
1.1 Requirement terminology ........................ 3
2 EnvelopedData using ECC ............................. 3
2.1 EnvelopedData using X9.63 ECDH ................. 3
2.1.1 Fields of KeyAgreeRecipientInfo type .... 4
2.1.2 Actions of the sending agent ............ 5
2.1.3 Actions of the receiving agent .......... 5
2.2 EnvelopedData using X9.63 modified ECDH ........ 5
2.2.1 Fields of KeyAgreeRecipientInfo type .... 6
2.2.2 Actions of the sending agent ............ 6
2.2.3 Actions of the receiving agent .......... 6
2.3 EnvelopedData using X9.63 1-Pass MQV ........... 7
2.3.1 Fields of KeyAgreeRecipientInfo type .... 7
2.3.2 Actions of the sending agent ............ 9
2.3.3 Actions of the receiving agent .......... 9
2.3.4 Originator certificates ................. 9
3 AuthenticatedData using X9.63 1-Pass MQV ............ 10
3.1 AuthenticatedData using X9.63 1-pass MQV ....... 11
3.1.1 Fields of KeyAgreeRecipientInfo type .... 11
3.1.2 Actions of the sending agent ............ 11
3.1.3 Actions of the receiving agent .......... 11
3.1.4 Originator certificates ................. 11
3.1.5 Re-using a KEK with 1-Pass MQV .......... 11
4 SignedData using ECC ................................ 12
4.1 SignedData using X9.62 ECDSA ................... 12
4.1.1 Fields of the SignedData type ........... 13
4.1.2 Actions of the sending agent ............ 14
4.1.3 Actions of the receiving agent .......... 14
5 Certificates using ECC .............................. 15
6 SMIMECapabilites Attribute and ECC .................. 15
7 ASN.1 Types and Identifiers ......................... 15
7.1 Object identifiers ............................. 15
7.2 Type definitions ............................... 17
8 Summary ............................................. 17
References ............................................. 18
Security Considerations ................................ 19
Intellectual Property Rights ........................... 19
Acknowledgments ........................................ 20
Author's Address ....................................... 20
Full Copyright Statement ............................... 20
Brown Expires January 2001 [Page 2]
Internet-Draft Use of ECC in S/MIME July 2000
1 Introduction
The Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent. This specification defines a standard profile for the
use of Elliptic Curve Cryptography (ECC) public key algorithms in
the CMS. The ECC algorithms are incorporated into following CMS
content types:
- 'EnvelopedData' to support ECC public key agreement methods
(ECDH and MQV) to generate pairwise key-encryption keys to
encrypt content-encryption keys used for content encryption
- 'AuthenticatedData' to support ECC based public key agreement
methods (MQV) to generate pairwise key-encryption keys to
encrypt MAC keys used for content authentication
- 'SignedData' to support ECC based digital signature methods
(ECDSA) to sign content
Certificates based on ECC digital signatures (ECDSA) are also
supported.
1.1 Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[MUST].
2 EnvelopedData using X9.63 ECC methods
Elliptic curve cryptography (ECC) methods for key agreement are
specified in [X9.63]. This specification refers to [X9.63] for the
cryptographic operations.
Note: all the key agreement methods here use the key derivation
method specified in [X9.63, Section 5.6.3].
2.1 EnvelopedData using X9.63 (standard) ephemeral-static ECDH
Ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key agreement
algorithm is the elliptic curve analog of the Diffie-Hellman key
agreement algorithm specified jointly in the documents [CMS,
Section 12.3.1.1] and [DH-X9.42]. The key agreement method is
adapted to use the elliptic curve methods from [X9.63, Section
6.2], the "1-Pass Diffie-Hellman scheme" using the standard
Diffie-Hellman primitive [X9.63, Section 5.4.1].
Brown Expires January 2001 [Page 3]
Internet-Draft Use of ECC in S/MIME July 2000
2.1.1 Fields of KeyAgreeRecipientInfo type
When using ephemeral-static ECDH, the EnvelopedData RecipientInfos
KeyAgreementInfo fields must be used as follows:
version is 3, as in [CMS, section 12.3.1.1].
originator is the alternative originatorKey, as in [CMS, Section
12.3.1.1]. The originatorKey algorithm fields contains the
id-ecPublicKey object identifer with absent parameters. The
id-ecPublicKey object identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
ansi-x9-62(10045) keyType(2) 1 }
The originatorKey publicKey field contains the sender's
ephemeral EC public key as determined below (by methods of
[X9.63]).
ukm may be absent, as in [CMS, Section 12.3.1.1], and has the
same meaning as in [CMS].
keyEncryptionAlgorithm is the dhSinglePass-stdDH-sha1kdf-scheme
algorithm identifier, with parameter field KeyWrapAlgorithm
present, with the follow value and syntax:
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9-63(63) schemes(0) 2}
KeyWrapAlgorithm ::= AlgorithmIdentifier
The KeyWrapAlgorithm indicates the symmetric encryption
algorithm used to encrypt the CEK with the KEK.
recipientEncryptedKeys contains an encrypted (wrapped)
content-encryption key and an identifier for each recipient, as
in [CMS, section 12.3.1.1].
The next two sections specify actions of sending and receiving
agents to handle ephemeral-static ECDH in keyAgreeRecipientInfo
fields of EnvelopedData.
Brown Expires January 2001 [Page 4]
Internet-Draft Use of ECC in S/MIME July 2000
2.1.2 Actions of the sending agent
When using ephemeral-static ECDH to generate EnvelopedData
KeyAgreeRecipientInfo fields, the sending agent selects groups of
recipients with common EC domain parameters. For each group, the
sending agent selects an ephemeral EC public key pair, as per the
1-Pass Diffie-Hellman scheme initiator transformation, specified in
[X9.63, Section 6.2.1]. The sending agent determines an integer
"keydatalen" from key-size of the KeyWrapAlgorithm and a bit string
"SharedData" from the ukm field if present. For each recipient in
the group, the sending agent completes the X9.63 1-Pass
Diffie-Hellman initiator transformation using the selected
ephemeral EC public key and the recipient's static EC public key
(i.e. from a certificate) to obtain a bit string "KeyData". The
"KeyData" bit string becomes the pairwise key-encryption key for
the recipient.
2.1.3 Actions of the receiving agent
The receiving agent uses the following process on an EnvelopedData
to detect if ephemeral-static Diffie-Hellman is used to transfer
the CEK to the receiving agent, and if so to compute the
key-encryption key used to unwrap the CEK.
The receiving agent determines the bit string "SharedData" from the
ukm field if present, and the integer "keydatalen" from the
key-size of the KeyWrapAlgorithm and completes the X9.63 1-Pass
Diffie-Hellman responder transformation [X9.63, Section 6.2.2],
using the ephemeral EC public key and the identified receiving
agent's static EC public key, to obtain a bit string "KeyData".
The "KeyData" bit string becomes the pairwise key-encryption key
for the receiving agent.
2.2 EnvelopedData using X9.63 modified ephemeral-static ECDH
Modified ephemeral-static Elliptic Curve Diffie-Hellman (ECDH) key
agreement algorithm is identical to standard ECDH except that a
modified version of the Diffie-Hellman primitive [X9.63, Section
5.4.2] is used. The modification involves multiplication by a
cofactor. A purpose of the modification is to prevent the
small-subgroup attack [SSG]. To indicate that the modified
Diffie-Hellman primitive is used, a different algorithm identifider
for this key agreement algorithm is provided, as specified below.
Brown Expires January 2001 [Page 5]
Internet-Draft Use of ECC in S/MIME July 2000
2.2.1 Fields of KeyAgreeRecipientInfo type
When using modified ephemeral-static ECDH, the EnvelopedData
RecipientInfos KeyAgreementInfo fields are the same as in those
specified in Section 2.1.1 of this document, except:
keyEncryptionAlgorithm is the
dhSinglePass-cofactorDH-sha1kdf-scheme algorithm identifier,
with parameter KeyWrapAlgorithm present, and the following value
and syntax:
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9-63(63) schemes(0) 3}
KeyWrapAlgorithm ::= AlgorithmIdentifier
2.2.2 Actions of the sending agent
The actions of the sending agent are identical to the actions of
sending agent using standard ephemeral-static ECDH specified above
in Section 2.1.2, except that:
- The sending agent uses the modified Diffie-Hellman primitive
of [X9.63, Section 5.4.2] rather than the standard
Diffie-Hellman primitive [X9.63, Section 5.4.1].
Note: modified and standard ephemeral-static ECDH can only be used
within separate KeyAgreeRecipientInfo fields.
2.2.3 Actions of the receiving agent
The actions of the receiving agent are identical to the actions of
receiving agent using standard ephemeral-static ECDH specified
above in Section 2.1.2, except that:
- The receiving agent uses the modified Diffie-Hellman primitive
of [X9.63, Section 5.4.2] rather than the standard
Diffie-Hellman primitive [X9.63, Section 5.4.1].
Brown Expires January 2001 [Page 6]
Internet-Draft Use of ECC in S/MIME July 2000
2.3 EnvelopedData using X9.63 1-Pass MQV
In [X9.63, Appendix H.4.5], 1-Pass MQV is suggested for
store-and-forward applications such as e-mail.
The 1-Pass MQV key agreement method, specified in [X9.63, Section
6.9], uses three EC public keys to generate keying data
(i.e. pairwise key-encryption key). The three keys are: a static
recipient key, a static originator key, and an ephemeral originator
key.
The originator's static EC public key is identified in the
originator field, usually by reference to a certificate. The
originator's ephemeral EC public is specified within the ukm field.
The recipient's static EC public key is identified according to
[CMS], within a rid field.
2.3.1 Fields of KeyAgreeRecipientInfo type
When using 1-Pass MQV, the EnvelopedData RecipientInfos
KeyAgreementInfo fields are used as follows:
version is 3, as in [CMS, section 12.3.1.1].
originator identifies the static EC public key of the sender.
It should be the one of the alternatives issuerAndSerialNumber
or subjectKeyIdentifier and point to one of the sender's
certificates supplied in the EnvelopedData originatorInfo field.
(If necessary, it may be the alternative originatorKey, as in
[CMS, Section 12.3.1.1], and if so, the originatorKey algorithm
field contains the id-ecPublicKey object identifer with absent
parameters. The id-ecPublicKey object identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
ansi-x9-62(10045) keyType(2) 1 }
The originatorKey publicKey field contains the sender's static
EC public key.)
Brown Expires January 2001 [Page 7]
Internet-Draft Use of ECC in S/MIME July 2000
ukm is present. It identifies the ephemeral EC public key of
the sender. It may also identify some additional information
for purposes similar to those specified in [CMS, Section
12.3.1.1]. The ukm field contains an octet string which is the
DER encoding of the following ASN.1 type
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The MQVuserKeyingMaterial ephemeralPublicKey algorithm field
contains the id-ecPublicKey object identifer with absent
parameters. The id-ecPublicKey object identifier is:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1)
member-body(2) ansi-x9-62(10045) keyType(2) 1 }
The MQVuserKeyingMaterial ephemeralPublicKey publicKey field
contains the sender's ephemeral EC public key as determined
below (by methods of [X9.63]). The MQVuserKeyingMaterial
addedukm field, if present, contains an octet string, whose
meaning is similar to meaning of the ukm field in [CMS,
Section 12.3.1.1].
keyEncryptionAlgorithm is the mqvSinglePass-sha1kdf-scheme
algorithm identifier, with parameter field KeyWrapAlgorithm
present, with the following values and syntax:
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) 16}
KeyWrapAlgorithm ::= AlgorithmIdentifier
The KeyWrapAlgorithm indicates the symmetric encryption
algorithm used to encrypt the CEK with the KEK generated using
the 1-Pass MQV algorithm.
recipientEncryptedKeys contains an encrypted (wrapped)
content-encryption key and an identifier for each recipient, as
in [CMS, section 12.3.1.1].
Brown Expires January 2001 [Page 8]
Internet-Draft Use of ECC in S/MIME July 2000
2.3.2 Actions of the sending agent
When using 1-Pass MQV to generate EnvelopedData
KeyAgreeRecipientInfo fields, the sending agent selects groups of
recipients with common EC domain parameters. For each group, the
sending agent selects an ephemeral EC public key pair, as per the
1-Pass MQV scheme initiator transformation, specified in [X9.63,
Section 6.9.1]. The sending agent specifies the ephemeral EC
public key in the KeyAgreeRecipientInfo ukm field, ASN.1 encoded
within in the MQVuserKeyingMaterial ephemeralPublickey publicKey
field. The sending agent determines an integer "keydatalen" from
key-size of the KeyWrapAlgorithm and a bit string "SharedData" from
the MQVuserKeyingMaterial addedukm field (if present) ASN.1 encoded
in the ukm field. For each recipient in the group, the sending
agent completes the 1-Pass MQV initiator transformation using the
selected ephemeral EC public key pair, the static EC public keys
(i.e. from certificates) of the originator and the recipient, and
the bit string "SharedData" if present, to obtain a bit string
"KeyData". The bit string "KeyData" becomes the pairwise
key-encryption key (KEK) for the recipient.
2.3.3 Actions of the receiving agent
The receiving agent uses the following process on an EnvelopedData
to detect if 1-Pass MQV is used to agree on the pairwise KEK for
the receiving agent, and if so to compute the pairwise KEK.
The receiving agent determines the bit string "SharedData" from the
ukm field if present, and the integer "keydatalen" from the
key-size of the KeyWrapAlgorithm and completes the 1-Pass MQV
responder transformation [X9.63, Section 6.9.2], using the
ephemeral EC public key, the identified static EC public keys of
the recipient and originator, and the bit string "SharedData" if
present, to obtain a bit string "KeyData". The bit string
"KeyData" becomes the the pairwise key-encryption key (KEK) for the
receiving agent.
2.3.4 Originator's certificates
If some recipients do not have other means to obtain the
originator's certificate for a static EC public key used in 1-Pass
MQV, then the originator's certificate containing the originator
static EC public key should be included in the EnvelopedData
originatorInfo field.
Brown Expires January 2001 [Page 9]
Internet-Draft Use of ECC in S/MIME July 2000
3 AuthenticatedData using ECC
The 1-Pass MQV scheme of [X9.63] has been selected in this document
for AuthenticatedData using ECC because it has security attributes
that are appropriate for the AuthenticatedData CMS type.
Note: in general, pure 'ephemeral-static' key agreement methods are
not suitable for AuthenticatedData because the originator's key is
ephemeral and therefore not authenticated.
Note: both SignedData and AuthenticatedData provide assurance to
the receiving agent that the content data originated from the
purported originator and the content was in no way modified.
However, SignedData and AuthenticatedData differ in some important
respects:
1. In AuthenticatedData the assurance of the content origin and
integrity is only provided to the specific recipients of the
AuthenticatedData. In SignedData, the assurance of content
origin and integrity is provided to potentially everyone.
2. In AuthenticatedData, the sending agent and receiving agent
are equally capable producing any given AuthenticatedData. In
SignedData, only the sending agent is capable of producing the
SignedData.
Careful consideration should be applied to the choice of using
AuthenticatedData or SignedData because of the these differences.
In particular, in AuthenticatedData the originator has less
'commitment' to the content than SignedData because
AuthenticatedData does not have the non-repudiative feature of
SignedData.
3.1 AuthenticatedData using 1-pass MQV
In general, using 1-Pass MQV in AuthenticatedData is similar to
using 1-Pass MQV in EnvelopedData (see Section 2.3 of this
document). Further details are provided in Sections 3.1.1 to
3.1.4.
However, 1-Pass MQV, AuthenticatedData and EnvelopedData can be use
together more efficiently by the re-using pairwise key-encryption
keys. A method to do this is specified in Section 3.1.5.
Brown Expires January 2001 [Page 10]
Internet-Draft Use of ECC in S/MIME July 2000
3.1.1 Fields of the KeyAgreementInfo type
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
same manner as the fields for the corresponding EnvelopedData
KeyAgreeRecipeintInfo fields of Section 2.3.1 of this document.
Note: the originator field should be one of the alternatives
issuerAndSerialNumber or subjectKeyIdentifier. If it is necessary
to use the originatorKey alternative, the recipients should have
other means (i.e. without certificates) to authenticate the
originator's static key.
3.1.2 Actions of the sending agent
The sending agent may use the same actions as for EnvelopedData
with 1-Pass MQV, as specified in Section 2.3.2 of this document.
3.1.3 Actions of the receiving agent
The receiving agent may use the same actions as for EnvelopedData
with 1-Pass MQV, as specified in Section 2.3.3 of this document.
3.1.4 Originator certificates
If some recipients do not have other means to obtain the
originator's certificate for a static EC public key used in 1-Pass
MQV, then the originator's certificate certifying the originator
static EC public key should be included in the AuthenticatedData
originatorInfo field.
For recipients that do not have other measn to obtain all the issue
certificates necessary to authenticate the originator's static EC
public key, then the necessary certificates (i.e. CA
cross-certifcates) may be included in the AuthenticatedData
originatorInfo field.
3.1.5 Re-using a KEK with 1-Pass MQV
When using 1-Pass MQV for an AuthenticatedData whose content is an
EnvelopedData, or for an AuthenticatedData which is the content is
an EnvelopedData, the KEKRecipientInfo type of [CMS] is an
efficient way to re-use a 1-Pass MQV generated pairwise KEK from
the EnvelopedData. Re-use of the EnvelopedData KEK helps to reduce
the total length of the ASN.1 encoding of the AuthenticatedData and
the total number of public key cryptographic operations performed
by both sending agents and receiving agents.
Brown Expires January 2001 [Page 11]
Internet-Draft Use of ECC in S/MIME July 2000
The KEKRecipientInfo encryptedKey field contains the wrapped "MAC"
key, encrypted with the previously generated KEK using 1-Pass MQV.
Generally, the pairwise KEK will have been generated within an
EnvelopedData. The KEKRecipientInfo KEKIdentifier keyIdentifier
field may be used to identify the re-used secret pairwise KEK
by providing an octet encoding of the originator's ephemeral EC
public key used in a 1-Pass MQV to to generate the KEK.
The KEKIdentifier other field may be absent, if it is certain that
the KEK is unambiguously identified. If the KEKIdentifier
keyIdentifier field alone is insufficient to identify the KEK
(perhaps because the receiving agent supports other methods that
use KEKReicipientInfo) then the KEKIdentifier other keyAttrId
field may be object identifier mqvSinglePass-sha1kdf-scheme (see
Section 2.3.1 of this document).
Note: if the content of the AuthenticatedData is an EnvelopedData,
then the KeyAgreeRecipientInfo fields of the EnvelopedData are in
plaintext and therefore, the KEK can be computed before the
EnvelopedData is decrypted or encrypted. If the content of an
EnvelopedData is an AuthenticatedData the KEK will be computed
before the AuthenticatedData is encrypted or decrypted. In the
either case, both the sending agent and receiving agent are able to
determine the necessary KEK from the EnvelopedData.
4 SignedData using ECC
An elliptic curve cryptography (ECC) method for signing is
specified in [X9.62]. In a single SignedData type [CMS] many
signing algorithms may be used but within each SignerInfo field
only one signing algorithm can be used.
4.1 SignedData using X9.62 ECDSA
The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified
in [X9.62]. The method is the elliptic curve analog of the [X9.30]
Digital Signature Algorithm (DSA). In [CMS] the meanings of the
fields of SignedData are specified, the actions of the sending
agent to generate SignedData are specified and the actions of the
receiving agent to process SignedData are specified. In [CMS], the
specificiations are algorithm independent. The following
subsections provide additional details about the SignedData fields
and actions of S/MIME agents when [X9.62] ECDSA is being used with
SignedData.
Brown Expires January 2001 [Page 12]
Internet-Draft Use of ECC in S/MIME July 2000
4.1.1 Fields of the SignedData type
When using [X9.62] ECDSA in an SignedData SignerInfo type the
fields are as in [CMS], but with the following restrictions.
digestAlgorithm is the following algorithm identifier for SHA-1:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
signatureAlgorithm is an algorithm identifer with parameters
field absent that identifies the ECDSA signature algorithm with
the object identifier:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) 10045 signatures(4) 1 }
signature is the DER encoding (as an octet string) of a value of
the [X9.62] ASN.1 type:
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
where the integers r and s are caculated according to [X9.62,
Section 5.3] using the signer's private key except that the
integer "e" is the result of the SignedData message digest
specified in [CMS] converted from an octet string to an intger
(i.e. not the result of [X9.63, Section 5.3.1]).
When using [X9.62] ECDSA the SignedData certificates field may
include the certificates for the EC public keys used in generation
of ECDSA signatures in the SignedData. If it is expected that
recipients have alternative means of obtaining the certain
certificates necessary to authenticate the EC public keys used for
signing, then such certificates may be omitted from the SignedData
certificates field. All certificates necessary for the
authentication of the EC public keys using for signing for which it
is not expected that the recipients have alternative means of
obtaining should be included in the SignedData certificates field.
Brown Expires January 2001 [Page 13]
Internet-Draft Use of ECC in S/MIME July 2000
4.1.2 Actions of the sending agent
The sending agent uses the message digest calculation process and
signature generation process for SignedData that are specified in
[CMS]. The sending agent follows the actions for ECDSA signature
generation specified in [X9.62, Section 5.3] with the following
exceptions:
- In [X9.62, Section 5.3.1], the integer "e" shall instead
be determined by converting the octet string resulting from
[CMS, Section 5.4] to an integer using the data conversion
method in [X9.62, Section 4.3.2].
The sending agent uses the encoding process specified [X9.62,
Section 6.5] to convert (encode) the ECDSA signature as an octet
string. This octet string is the value of the SignerInfo
SignatureValue field. The sending agent uses DER encoding rules
and includes the entire encoding of the ASN.1 type ECDSA-Sig-Value
(see above and [X9.62]) including the tag and length octets in the
octet string SignerInfo SignatureValue.
4.1.3 Actions of the receiving agent
The receiving agent uses the message digest calculation process
and signature verification process for SignedData that are
specified in [CMS]. The receiving agent follows the actions
for ECDSA signature verification specified in [X9.62, Section 5.4]
with the following exceptions:
- In [X9.62, Section 5.4.1] the integer "e" shall instead be
determined by converting the octet string resulting from [CMS,
Section 5.4] to an integer using the data conversion method in
[X9.62, Section 4.3.2].
The receiving agent uses the encoding process specified in [X9.62,
Section 6.5] to convert (decode) the octet string value of the
SignerInfo SignatureValue field to the [X9.62] signature. The
receiving agent uses DER decoding rules.
Brown Expires January 2001 [Page 14]
Internet-Draft Use of ECC in S/MIME July 2000
5 Certificates using ECC
The use of a certificates with ECC is specified in [EPKIX].
Further information on the use ECC with certificates is given in
[SECG-WG-EC].
6 SMIMECapabilities Attribute and ECC
A sending agent may choose to announce to receiving agents that it
supports one or more of the ECC algorithms in this document by
using SMIMECapabilities signed attribute as specified in [MSG,
Section 2.5.2].
The SMIMECapability capabilityID object identifiers for the
supported key agreement algorithms in this document are
dhSinglePass-stdDH-sha1kdf-scheme,
dhSinglePass-cofactorDH-sha1kdf-scheme, and
mqvSinglePass-sha1kdf-scheme. For each of these SMIMECapability
SEQUENCEs the parameters field is present and indicates the
supported key-encryption algorithm with the KeyWrapAlgorithm
algorithm identifier.
The SMIMECapability value to indicate support for the ECDSA
signature algorithm is the SEQUENCE with the capabilityID field
containing the object identifier ecdsa-with-SHA1 and the parameters
field absent.
7 ASN.1 Types and Identifiers
The ASN.1 types and object identifiers that are used in this
document are gathered together in this section for reference
purposes.
7.1 Object identifiers
The object identifiers used in this document are taken from [CMS],
[X9.63] and [X9.62].
Brown Expires January 2001 [Page 15]
Internet-Draft Use of ECC in S/MIME July 2000
The following object identifiers indicate the key agreement
algorithms used in this document:
dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) 2}
dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) tc68(133) country(16)
x9(840) x9-63(63) schemes(0) 3}
mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) tc68(133) country(16) x9(840)
x9-63(63) schemes(0) 16}
The following object identifier indicates the digital signature
algorithm used in this document:
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) 10045 signatures(4) 1 }
The following object identifier indicates the hash algorithm used
in this document:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
The following object identifier is used in this document to
indicate an elliptic curve public key:
id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2)
ansi-x9-62(10045) keyType(2) 1 }
Brown Expires January 2001 [Page 16]
Internet-Draft Use of ECC in S/MIME July 2000
7.2 Type definitions
The following ASN.1 type defintions are used.
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
MQVuserKeyingMaterial ::= SEQUENCE {
ephemeralPublicKey OriginatorPublicKey,
addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
The former is taken from [X9.62]. In this document, DER encodings
as octet strings of values of the two above ASN.1 types
ECDSA-Sig-Value and MQVuserKeyingMaterial are used as values of
octet string ASN.1 types from [CMS]. An encoding of
ECDSA-Sig-Value is used as the value of a SignedData SignerInfo
SignatureValue and an encoding of MQVuserKeyingMaterial is used as
the value of EnvelopedData KeyAgreeRecipeintInfo UserKeyingMaterial
or AuthenticatedData KeyAgreeRecipeintInfo UserKeyingMaterial.
8 Summary
This document specifies how to use ECC methods with S/MIME CMS
type. The most notable advantage of ECC methods over integer
arithmetic based methods (Diffie-Hellman, DSA and RSA) is the
shorter length of cryptographic overhead in signatures,
certificates, encrypted and authenticated messages..
This document specifies a cryptographic method to be used with the
[CMS] content type AuthenticatedData. The cryptographic method is
X9.63 1-Pass MQV scheme. The AuthenticateData type achieves
authentication without 'non-repudiation'. For certain kinds of
data, AuthenticatedData may be preferrable to SignedData.
Brown Expires January 2001 [Page 17]
Internet-Draft Use of ECC in S/MIME July 2000
References
[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999.
[DH-X9.42] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[EPKIX] L. Bassham and D. Johnson, "Internet X.509 Public Key
Infrastructure Representation of Elliptic Curve Digital
Signature Algorithm (ECDSA) Keys and Signatures in
Internet X.509 Public Key Infrastructure Certificates",
PKIX Working Group Internet-Draft, October, 1999.
[FIPS-180] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, "Secure Hash Standard", 1995 April
17.
[FIPS-186] Federal Information Processing Standards Publication
(FIPS PUB) 186, "Digital Signature Standard", 1994 May
19.
[GEC1] Certicom Research, "Guidelines for Efficinet
Cryptography", GEC1, February, 1999.
[KEA] J. Pawling, "CMS KEA and SKIPJACK Conventions", S/MIME
Working Group Internet-Draft, December, 1999.
[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
"An efficient protocol for authenticated key
agreement", Technical report CORR 98-05, University of
Waterloo, 1998.
[LL97] C.H. Lim and P.J. Lee, "A key recovery attack on
discrete log-based schemes using a prime order
subgroup", B.S. Kaliski, Jr., editor, Advances in
Cryptology - Crypto '97, Lecture Notes in Computer
Science, vol. 1295, 1997, Springer-Verlag, pp. 249-263.
[MSG] B. Ramsdell, "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[MUST] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
Brown Expires January 2001 [Page 18]
Internet-Draft Use of ECC in S/MIME July 2000
[NIST-ECC] National Institute for Standards and Technology,
"Recommended Elliptic Curves for Federal Government
Use", July 1999,
<http://csrc.nist.gov/encryption/NISTReCur.pdf>
[IEEE1363] IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363-2000 Specification, 2000,
Annex D.
[SEC1] Certicom Research, "Elliptic Curve Cryptography", SEC1,
February, 1999.
[SEC-WG-EC] Certicom Research, "ECC in X.509", SEC X.509 Working
Group Draft, August, 1999.
[SSG] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000.
[X9.30] ANSI X9.30-1995, Part 1, "Public key cryptography using
irreversible algorithms for the financial services
industry: The Digital Signature Algorithm (Revised)",
1995.
[X9.42] "Agreement Of Symmetric Keys Using Diffie-Hellman and
MQV Algorithms", ANSI draft, May 1999.
[X9.62] ANSI X9.62-1999, "Public Key Cryptography For The
Financial Services Industry: The Elliptic Curve Digital
Signature Algorithm (ECDSA)", 1999.
[X9.63] "Public Key Cryptography For The Financial Services
Industry: Key Agreement and Key Transport Using
Elliptic Curve Cryptography", Draft ANSI X9F1, October
1999.
Security Considerations
This specification is based on [CMS], [X9.62] and [X9.63] and the
appropriate security considerations of those documents apply.
Intellectual Property Rights
This specification is based on ANSI specification X9.62 and X9.63.
A variety of patent statements in these working may apply to this
specification. A later draft will attempt to identify a reference
for the ANSI X9F1 related claims.
Brown Expires January 2001 [Page 19]
Internet-Draft Use of ECC in S/MIME July 2000
Acknowledgments
The key agreement methods described in this document is based on
work done by the ANSI X9F1 working group. The author wishes to
extend his thanks for their assistance.
The author also wishes to thank Paul Lambert, Simon Blake-Wilson,
and Peter de Rooij for their patient assistance. The basis of this
work is derived from the ANSI X9F1 working group and their
specifications for ECDSA and EC key agreement techniques.
Author's Address
Daniel R. L. Brown
Certicom Corp
5520 Explorer Drive #400
Mississauga, ON L4W 5L1
EMail: dbrown@certicom.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Brown Expires January 2001 [Page 20]