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, [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]