idnits 2.17.1 draft-ietf-smime-ecc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 351 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'EPKIX' is mentioned on line 86, but not defined == Missing Reference: 'RFC2631' is mentioned on line 66, but not defined == Unused Reference: 'CMS' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'LAW98' is defined on line 260, but no explicit reference was found in the text == Unused Reference: 'LL97' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'P1363' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'SEC1' is defined on line 289, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' -- Possible downref: Non-RFC (?) normative reference: ref. 'LAW98' -- Possible downref: Non-RFC (?) normative reference: ref. 'LL97' -- Possible downref: Non-RFC (?) normative reference: ref. 'P1363' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-ECC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'GEC1' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Paul A. Lambert 2 draft-ietf-smime-ecc-00.txt Certicom, Inc. 3 22 October, 1999 4 Expires: 22 April 2000 6 Elliptic Curve S/MIME 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document is the first draft of a profile for the incorporation 30 of Elliptic Curve (EC) public key algorithms in the Cryptographic 31 Message Syntax (CMS). The EC algorithms support the creation of 32 digital signatures and the distribution of keys to encrypt or authen- 33 ticate message content. The definition of the algorithm processing 34 is based on the ANSI X9.63 draft, developed by the ANSI X9F1 35 working group. 37 Table of Contents 39 1. Introduction 40 2. Signed-data 41 2.1. ECDSA Algorithm Support 42 3. Enveloped-data 43 3.1 ECDH Algorithm Support 44 4. Authenticated-data 46 1. Introduction 48 The Cryptographic Message Syntax (CMS) is cryptographic algorithm 49 independent. This specification defines a standard profile for the 50 use of Elliptic Curve (EC) public key cryptography in the CMS. The 51 EC algorithms are incorporated into following CMS content types: 53 o 'SignedData' to support EC based digital signatures 54 o 'EnvelopedData' to support EC public key agreement to 55 create shared keys to encrypt information 56 o 'AuthenticatedData' to support EC public key agreement 57 to authenticate information with a MAC 59 The signature algorithm is based on the elliptic curve analog of the 60 DSA signature [FIPS-186]. The Elliptic Curve Digital Signature Algorithm 61 (ECDSA) is defined by ANSI [X9.62]. A profile for the use of ECDSA in 62 X.509 certificates [EPKIX] describes the means to carry EC keys in 63 X.509 certificates. 65 The key agreement mechanism is based on the elliptic curve analog of 66 the Diffie-Hellman key agreement mechanism [RFC2631][ANSIX9.42]. A 67 wide variety of EC key-agreement mechanisms are defined in the draft 68 ANSI X9.63 specification for Key Agreement and Key Transport Using 69 Elliptic Curve Cryptography [X9.63]. The 1-Pass EC Diffie-Hellman 70 scheme (ECDH) was selected from X9.63 and is specified herein. The 71 ECDH key agreement algorithm is used in a 'ephemeral-static' mode where 72 the originator generates a unique ephemeral key for every key agreement. 73 The recipient publishes a fixed EC public key.or certificate containing 74 a EC public key. 76 2. Signed-data 78 EC signatures are identified in CMS syntax by the 'signatureAlgorithm' 79 field in the 'signerInfos' portion of the 'SignedData' content type. 80 The EC parameters should not be included in the object identifier. 81 All necessary EC parameters can be inferred from the signers public key. 83 The EC public key of the signer must be available to the recipient for 84 validation processing. This public key may be contained in the option 85 'certificates' field of 'SignedData'. The incorporation of EC public 86 keys in X.509 certificates is specified in [EPKIX]. 88 The 'SignerInfo' in 'SignedData', uses the 'sid' field to identify a 89 specific key or certificate for the validation processing. This 90 identifier is either a distinguished name and serial number or a 91 key identifier. EC keys are small and in some applications the EC 92 public key may be used as the opaque octet string 'SubjectKeyIdentifier'. 94 This draft only specifies the application of the ECDSA algorithm 95 for CMS signed data. 97 2.1. ECDSA Algorithm Support 99 The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 100 the ANSI X9.62 standard [X9.62]. ECDSA should always be used with the 101 SHA-1 message digest algorithm. The algorithm identifier for ECDSA is: 103 ecdsa-with-SHA1 OBJECT IDENTIFIER ::= 104 { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 } 106 The algorithm parameters field must not be present. 108 3. Enveloped-data 110 Information is encrypted by the 'EnvelopedData' content type in the CMS. 111 This structure contains a set of 'RecipientInfo' that allows each 112 authorized recipient to decrypt the 'EncryptedContent'. EC public key 113 algorithms can be used to distribute the keys to decrypt the content by 114 creating a one-way shared secret between the originator and each 115 recipient. The basic steps of this process are: 117 1) Generate a key, K, and use this key to encrypt the content. This 118 is typically a symmetric algorithm and key like Triple-DES. 120 2) For each recipient: 122 a) Obtain the recipients public key (often in a certificate). 123 This is a static public key. 124 This key is identified by the 'KeyAgreeRecipientIdentifier'. 125 When carried as a 'SubjectKeyIdentifier' the identifier may 126 be a EC public key. 128 b) Use the recipients public key to determine the 129 appropriate type of EC key and parameters for the 130 key agreement process. 132 c) Generate a unique new public ephemeral key with the 133 same set of defining parameters as the recipient. 134 This key should only be used once. 135 This key is carried in 'OriginatorPublicKey'. 136 The key is always identified with a 'id-ecPublicKey' 137 object identifier. The parameters of this key 138 should be absent. 140 c) Select an appropriate key aggrement scheme and create 141 a shared secret, ZZ, using the two public public keys 142 (static recipient and ephemeral originator). 143 This key agreement algorithm is identified in the CMS 144 by the 'KeyEncryptionAlgorithm' object identifier. 146 d) Use the appropriate Key Derivation Function (KDF) to 147 transform the secret ZZ into a key appropriate to encrypt 148 the data encryption key K. This is the Key Encryption 149 Key (KEK). The KDF is typically based on the SHA-1 [FIPS-180] 150 hash algorithm. 152 e) Use the KEK to encrypt K using the key wrap algorithm. 153 The key wrap algorithm is identified by the 'KeyWrapAlgorithm' 154 parameter within the 'KeyEncryptionAlgorithm' object. 156 Where EC public keys are described by object identifiers ( like 157 'OriginatorPublicKey') the following definition must be used: 159 id-ecPublicKey OBJECT IDENTIFIER ::= 160 { iso(1) member-body(2) us(840) ansi-X9-62(10045) 161 id-public-key-type(2) 1 } 163 Editors note - need to investigate the encoding for the ECAES 164 algorithm that direcetly combnes the definition of the key agreement 165 and the key encryption. 167 3.1 ECDH Algorithm Support 169 The processing of the 1-Pass Diffie-Hellman scheme is defined in 170 Section 6.2. of ANSI X9.63 [X9.63]. Two variations of this key agreement 171 are defined. The standards 1-Pass Diffie-Hellman key 172 agreement is identified by: 174 dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= 175 { iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 2 } 177 When the cofactor Diffie-Hellman primitive is used the object identifier 178 is defined as: 180 dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= 181 { iso(1) member-body(2) us(840) ansi-x9-63(??) schemes(0) 3 } 183 Editor note - need to identify one as prefered/mandatory. 185 The processing definition in [X9.63] includes SHA-1 as the KDF. 187 When using ECDH the following constraints on the 'KeyAgreeRecipientInfo' 188 must be enforced: 190 o The 'version' must be 3. 191 o The 'originatorKey' algorithm fields must contain the 192 'id-ecPublicKey' object identifier with absent parameters. 193 o The 'originatorKey public key field must contain the 194 sender's ephemeral public key. 195 o The 'ukm' field must be absent. 196 o The algorithm identifier parameter field for 197 'dhSinglePass-stdDH-sha1kdf-scheme' or 198 'dhSinglePass-cofactorDH-sha1kdf-scheme' is 'KeyWrapAlgorihtm', 199 and this parameter must be present. 200 o The KeyWrapAlgorithm denotes the KEK algorithm. 202 4. Authenticated-data 204 CMS content can be authenticated using a message authentication code (MAC) 205 carried in a 'AuthenticatedData' content type. A symmetric algorithm is 206 used to validate the source and integrity of the content. 208 The use of EC public key techniques in 'AuthenticatedData' is nearly 209 identical to the processing for 'EnvelopedData' described in Section 3. 210 The only difference in the processing is that the generated key 211 (Section 3, step 1) is used for the MAC operation. The remainder of the 212 processing of the 'RecipientInfo' fields is identical to Section 3. 214 Security Considerations 216 The techniques specified herein do not guarantee that a particular 217 implementation is secure. Implementators need to consider small 218 subgroup attacks, storage of private key, generation of random 219 numbers, source and verification of public keys, appropriate key 220 size, reuse of ephemeral keys, trusted path to use of key, 221 non-repudiation versus authentication, etc. 223 The security of EC algorithms requires the careful selection of the 224 field and curves parameters. Selection guidelines for EC parameters 225 are provided in [NIST-ECC],[GEC1], [X9.63] 227 The strength of cryptographic algorithms depend on the effective 228 key size. Key size recommendations are provided in [NIST-ECC] 230 Intellectual Property Rights 232 This specification is based on ANSI specification X9.62 and X9.63. A 233 variety of patent statements in these working may apply to this 234 specification. A later draft will attempt to identify a reference 235 for the ANSI X9F1 related claims. 237 Acknowledgments 239 The Key Agreement method described in this document is based on work 240 done by the ANSI X9F1 working group. The author wishes to extend his 241 thanks for their assistance. 243 The author also wishes to thank Simon Blake-Wilson, and Peter de Roij 244 for their patient assistance. The basis of this work is derived from 245 the ANSI X9F1 working group and their specifications for ECDSA and EC 246 key agreement techniques. 248 References 250 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, 251 June 1999. 253 [FIPS-180] Federal Information Processing Standards Publication 254 (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17. 256 [FIPS-186] Federal Information Processing Standards Publication 257 (FIPS PUB) 186, "Digital Signature Standard", 1994 May 258 19. 260 [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, 261 "An efficient protocol for authenticated key agreement", 262 Technical report CORR 98-05, University of Waterloo, 263 1998. 265 [LL97] C.H. Lim and P.J. Lee, "A key recovery attack on discrete 266 log-based schemes using a prime order subgroup", B.S. 267 Kaliski, Jr., editor, Advances in Cryptology - Crypto 268 '97, Lecture Notes in Computer Science, vol. 1295, 1997, 269 Springer-Verlag, pp. 249-263. 271 [P1363] "Standard Specifications for Public Key Cryptography", 272 IEEE P1363 working group draft, 1998, Annex D. 274 [X9.42] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV 275 Algorithms", ANSI draft, May 1999. 277 [X9.62] X9.62-1999, "Public Key Cryptography For The Financial 278 Services Industry: The Elliptic Curve Digital Signature 279 Algorithm (ECDSA)". 281 [X9.63] "Public Key Cryptography For The Financial Services 282 Industry: Key Agreement and Key Transport Using Elliptic 283 Curve Cryptography", Draft ANSI X9F1, October 1999. 285 [NIST-ECC] National Institute for Standards and Technology, 286 "Recommended Elliptic Curves for Federal Government Use", 287 July 1999, 289 [SEC1] Certicom Research, "Elliptic Curve Cryptography", SEC1, 290 February, 1999. 292 [GEC1] Certicom Research, "Guidelines for Efficinet Cryptography", 293 GEC1, February, 1999. 295 Author's Address 297 Paul Lambert 298 Certicom, Corp. 299 25801 Industrial Blvd. 300 Hayward, CA 94545 302 EMail: plambert@sprintmail.com 304 Full Copyright Statement 306 Copyright (C) The Internet Society (1999). All Rights Reserved. 308 This document and translations of it may be copied and furnished to 309 others, and derivative works that comment on or otherwise explain it 310 or assist in its implementation may be prepared, copied, published 311 and distributed, in whole or in part, without restriction of any 312 kind, provided that the above copyright notice and this paragraph are 313 included on all such copies and derivative works. However, this 314 document itself may not be modified in any way, such as by removing 315 the copyright notice or references to the Internet Society or other 316 Internet organizations, except as needed for the purpose of 317 developing Internet standards in which case the procedures for 318 copyrights defined in the Internet Standards process must be 319 followed, or as required to translate it into languages other than 320 English. 322 The limited permissions granted above are perpetual and will not be 323 revoked by the Internet Society or its successors or assigns. 325 This document and the information contained herein is provided on an 326 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 327 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 328 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 329 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 330 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.