INTERNET-DRAFT Paul A. Lambert draft-ietf-smime-ecc-00.txt Certicom, Inc. 22 October, 1999 Expires: 22 April 2000 Elliptic Curve 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 first draft of a profile for the incorporation of Elliptic Curve (EC) public key algorithms in the Cryptographic Message Syntax (CMS). The EC algorithms support the creation of digital signatures and the distribution of keys to encrypt or authen- ticate message content. The definition of the algorithm processing is based on the ANSI X9.63 draft, developed by the ANSI X9F1 working group. Table of Contents 1. Introduction 2. Signed-data 2.1. ECDSA Algorithm Support 3. Enveloped-data 3.1 ECDH Algorithm Support 4. Authenticated-data 1. Introduction The Cryptographic Message Syntax (CMS) is cryptographic algorithm independent. This specification defines a standard profile for the use of Elliptic Curve (EC) public key cryptography in the CMS. The EC algorithms are incorporated into following CMS content types: o 'SignedData' to support EC based digital signatures o 'EnvelopedData' to support EC public key agreement to create shared keys to encrypt information o 'AuthenticatedData' to support EC public key agreement to authenticate information with a MAC The signature algorithm is based on the elliptic curve analog of the DSA signature [FIPS-186]. The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by ANSI [X9.62]. A profile for the use of ECDSA in X.509 certificates [EPKIX] describes the means to carry EC keys in X.509 certificates. The key agreement mechanism is based on the elliptic curve analog of the Diffie-Hellman key agreement mechanism [RFC2631][ANSIX9.42]. A wide variety of EC key-agreement mechanisms are defined in the draft ANSI X9.63 specification for Key Agreement and Key Transport Using Elliptic Curve Cryptography [X9.63]. The 1-Pass EC Diffie-Hellman scheme (ECDH) was selected from X9.63 and is specified herein. The ECDH key agreement algorithm is used in a 'ephemeral-static' mode where the originator generates a unique ephemeral key for every key agreement. The recipient publishes a fixed EC public key.or certificate containing a EC public key. 2. Signed-data EC signatures are identified in CMS syntax by the 'signatureAlgorithm' field in the 'signerInfos' portion of the 'SignedData' content type. The EC parameters should not be included in the object identifier. All necessary EC parameters can be inferred from the signers public key. The EC public key of the signer must be available to the recipient for validation processing. This public key may be contained in the option 'certificates' field of 'SignedData'. The incorporation of EC public keys in X.509 certificates is specified in [EPKIX]. The 'SignerInfo' in 'SignedData', uses the 'sid' field to identify a specific key or certificate for the validation processing. This identifier is either a distinguished name and serial number or a key identifier. EC keys are small and in some applications the EC public key may be used as the opaque octet string 'SubjectKeyIdentifier'. This draft only specifies the application of the ECDSA algorithm for CMS signed data. 2.1. ECDSA Algorithm Support The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in the ANSI X9.62 standard [X9.62]. ECDSA should always be used with the SHA-1 message digest algorithm. The algorithm identifier for ECDSA is: ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 } The algorithm parameters field must not be present. 3. Enveloped-data Information is encrypted by the 'EnvelopedData' content type in the CMS. This structure contains a set of 'RecipientInfo' that allows each authorized recipient to decrypt the 'EncryptedContent'. EC public key algorithms can be used to distribute the keys to decrypt the content by creating a one-way shared secret between the originator and each recipient. The basic steps of this process are: 1) Generate a key, K, and use this key to encrypt the content. This is typically a symmetric algorithm and key like Triple-DES. 2) For each recipient: a) Obtain the recipients public key (often in a certificate). This is a static public key. This key is identified by the 'KeyAgreeRecipientIdentifier'. When carried as a 'SubjectKeyIdentifier' the identifier may be a EC public key. b) Use the recipients public key to determine the appropriate type of EC key and parameters for the key agreement process. c) Generate a unique new public ephemeral key with the same set of defining parameters as the recipient. This key should only be used once. This key is carried in 'OriginatorPublicKey'. The key is always identified with a 'id-ecPublicKey' object identifier. The parameters of this key should be absent. c) Select an appropriate key aggrement scheme and create a shared secret, ZZ, using the two public public keys (static recipient and ephemeral originator). This key agreement algorithm is identified in the CMS by the 'KeyEncryptionAlgorithm' object identifier. d) Use the appropriate Key Derivation Function (KDF) to transform the secret ZZ into a key appropriate to encrypt the data encryption key K. This is the Key Encryption Key (KEK). The KDF is typically based on the SHA-1 [FIPS-180] hash algorithm. e) Use the KEK to encrypt K using the key wrap algorithm. The key wrap algorithm is identified by the 'KeyWrapAlgorithm' parameter within the 'KeyEncryptionAlgorithm' object. Where EC public keys are described by object identifiers ( like 'OriginatorPublicKey') the following definition must be used: id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) id-public-key-type(2) 1 } Editors note - need to investigate the encoding for the ECAES algorithm that direcetly combnes the definition of the key agreement and the key encryption. 3.1 ECDH Algorithm Support The processing of the 1-Pass Diffie-Hellman scheme is defined in Section 6.2. of ANSI X9.63 [X9.63]. Two variations of this key agreement are defined. The standards 1-Pass Diffie-Hellman key agreement is identified by: dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 2 } When the cofactor Diffie-Hellman primitive is used the object identifier is defined as: dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 3 } Editor note - need to identify one as prefered/mandatory. The processing definition in [X9.63] includes SHA-1 as the KDF. When using ECDH the following constraints on the 'KeyAgreeRecipientInfo' must be enforced: o The 'version' must be 3. o The 'originatorKey' algorithm fields must contain the 'id-ecPublicKey' object identifier with absent parameters. o The 'originatorKey public key field must contain the sender's ephemeral public key. o The 'ukm' field must be absent. o The algorithm identifier parameter field for 'dhSinglePass-stdDH-sha1kdf-scheme' or 'dhSinglePass-cofactorDH-sha1kdf-scheme' is 'KeyWrapAlgorihtm', and this parameter must be present. o The KeyWrapAlgorithm denotes the KEK algorithm. 4. Authenticated-data CMS content can be authenticated using a message authentication code (MAC) carried in a 'AuthenticatedData' content type. A symmetric algorithm is used to validate the source and integrity of the content. The use of EC public key techniques in 'AuthenticatedData' is nearly identical to the processing for 'EnvelopedData' described in Section 3. The only difference in the processing is that the generated key (Section 3, step 1) is used for the MAC operation. The remainder of the processing of the 'RecipientInfo' fields is identical to Section 3. Security Considerations The techniques specified herein do not guarantee that a particular implementation is secure. Implementators need to consider small subgroup attacks, storage of private key, generation of random numbers, source and verification of public keys, appropriate key size, reuse of ephemeral keys, trusted path to use of key, non-repudiation versus authentication, etc. The security of EC algorithms requires the careful selection of the field and curves parameters. Selection guidelines for EC parameters are provided in [NIST-ECC],[GEC1], [X9.63] The strength of cryptographic algorithms depend on the effective key size. Key size recommendations are provided in [NIST-ECC] 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. Acknowledgments The Key Agreement method 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 Simon Blake-Wilson, and Peter de Roij 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. References [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 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. [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. [P1363] "Standard Specifications for Public Key Cryptography", IEEE P1363 working group draft, 1998, Annex D. [X9.42] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", ANSI draft, May 1999. [X9.62] X9.62-1999, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)". [X9.63] "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", Draft ANSI X9F1, October 1999. [NIST-ECC] National Institute for Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", July 1999, <http://csrc.nist.gov/encryption/NISTReCur.pdf> [SEC1] Certicom Research, "Elliptic Curve Cryptography", SEC1, February, 1999. [GEC1] Certicom Research, "Guidelines for Efficinet Cryptography", GEC1, February, 1999. Author's Address Paul Lambert Certicom, Corp. 25801 Industrial Blvd. Hayward, CA 94545 EMail: plambert@sprintmail.com Full Copyright Statement Copyright (C) The Internet Society (1999). 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.
Datatracker
draft-ietf-smime-ecc-00
Internet-Draft
