idnits 2.17.1 draft-ietf-smime-cms-rsaes-oaep-02.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 59 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 11 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([CMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 101: '..., when the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 102: '... MAY are used in capital letters, th...' RFC 2119 keyword, line 107: '...th this document MUST provide the capa...' RFC 2119 keyword, line 108: '...indicated by the MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 117: '...mpliant software MUST meet the require...' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- The document date (November 2000) is 8560 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'CMS' is mentioned on line 118, but not defined == Missing Reference: 'RSALAB' is mentioned on line 55, but not defined == Missing Reference: 'CRYPTO98' is mentioned on line 55, but not defined == Missing Reference: 'SSL' is mentioned on line 68, but not defined == Missing Reference: 'TLS' is mentioned on line 69, but not defined == Missing Reference: 'PROFILE' is mentioned on line 93, but not defined == Missing Reference: 'MUSTSHOULD' is mentioned on line 103, but not defined -- Looks like a reference, but probably isn't: '0' on line 197 -- Looks like a reference, but probably isn't: '1' on line 198 -- Looks like a reference, but probably isn't: '2' on line 199 == Missing Reference: 'SHA1' is mentioned on line 234, but not defined == Unused Reference: 'RANDOM' is defined on line 355, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RANDOM' Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group R. Housley 2 Internet Draft SPYRUS 3 expires in six months November 2000 5 Use of the RSAES-OAEP Key Transport Algorithm in CMS 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 Abstract 40 This document describes the use of the RSAES-OAEP key transport 41 method of key management within the Cryptographic Message Syntax 42 [CMS]. 44 This draft is being discussed on the "ietf-smime" mailing list. To 45 join the list, send a message to with 46 the single word "subscribe" in the body of the message. Also, there 47 is a Web site for the mailing list at . 50 1 Introduction 52 When the variant of the RSA key transport algorithm specified in PKCS 53 #1 Version 1.5 [PKCS#1v1.5] is used for key management, it is 54 vulnerable to adaptive chosen ciphertext attacks. This attack is 55 explained in [RSALAB] and [CRYPTO98]. The use of PKCS #1 Version 1.5 56 key transport in interactive applications is especially vulnerable. 57 Exploitation of this identified vulnerability, revealing the result 58 of a particular RSA decryption, requires access to an oracle which 59 will respond to hundreds of thousands of ciphertexts, which are 60 constructed adaptively in response to previously-received replies 61 providing information on the successes or failures of attempted 62 decryption operations. 64 The attack appears significantly less feasible in store-and-forward 65 environments, such as S/MIME. When PKCS #1 Version 1.5 key transport 66 is applied as an intermediate encryption layer within an interactive 67 request-response communications environment, exploitation could be 68 more feasible. However, Secure Sockets Layer (SSL) [SSL] and 69 Transport Layer Security (TLS) [TLS] protocol implementations could 70 include countermeasures that detect and prevent Bleichenbacher's and 71 other chosen-ciphertext attacks, without changing the way the RSA key 72 transport algorithm is used. These countermeasures are performed 73 within the protocol level. In the interest of long-term security 74 assurance, it is prudent to adopt an improved cryptographic technique 75 rather than embedding countermeasures within protocols. 77 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 78 [PKCS#1v2.0]. This new document supersedes RFC 2313. PKCS #1 79 Version 2.0 preserves support for the encryption padding format 80 defined in PKCS #1 Version 1.5 [PKCS#1v1.5], and it also defines a 81 new alternative. To resolve the adaptive chosen ciphertext 82 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 83 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 84 is used to provide confidentiality, such as key transport. 86 This document specifies the use of RSAES-OAEP key transport algorithm 87 in the Cryptographic Message Syntax (CMS) [CMS]. CMS can be used in 88 either a store-and-forward or an interactive request-response 89 environment. 91 CMS supports variety of architectures for certificate-based key 92 management, particularly the one defined by the PKIX working group 93 [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require the 94 same RSA public key information. Thus, a certified RSA public key 95 may be used with either RSA key transport technique. 97 CMS values are generated using ASN.1 [X.208-88], using the Basic 98 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 99 (DER) [X.509-88]. 101 Throughout this document, when the terms MUST, MUST NOT, SHOULD and 102 MAY are used in capital letters, their use conforms to the 103 definitions in [MUSTSHOULD]. [MUSTSHOULD] defines these key words to 104 help make the intent of standards track documents as clear as 105 possible. The same key words are used in this document to help 106 implementers achieve interoperability. Implementations that claims 107 compliance with this document MUST provide the capabilities as 108 indicated by the MUST, MUST NOT, SHOULD and MAY terms. 110 2 Enveloped-data Conventions 112 The CMS enveloped-data content type consists of encrypted content and 113 wrapped content-encryption keys for one or more recipients. The 114 RSAES-OAEP key transport algorithm is used to wrap the content- 115 encryption key for one recipient. 117 Compliant software MUST meet the requirements for constructing an 118 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 119 data Content Type". 121 A content-encryption key MUST be randomly generated for each instance 122 of an enveloped-data content type. The content-encryption key is 123 used to encipher the content. 125 2.1 EnvelopedData Fields 127 The enveloped-data content type is ASN.1 encoded using the 128 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 129 populated as follows: 131 The EnvelopedData version MUST be either 0 or 2. 133 The EnvelopedData originatorInfo field is not used for the RSAES-OAEP 134 key transport algorithm. However, this field MAY be present to 135 support recipients using other key management algorithms. 137 The EnvelopedData recipientInfos CHOICE MUST be 138 KeyTransRecipientInfo. See section 2.2 for further discussion of 139 KeyTransRecipientInfo. 141 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 142 field MUST be specify a symmetric encryption algorithm. 143 Implementations MUST support the encryption of Triple-DES content- 144 encryption keys, but implementations MAY support other algorithms as 145 well. 147 The EnvelopedData unprotectedAttrs MAY be present. 149 2.2 KeyTransRecipientInfo Fields 151 The enveloped-data content type is ASN.1 encoded using the 152 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 153 populated as follows: 155 The KeyTransRecipientInfo version MUST be either 0 or 2. If the 156 RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the 157 version MUST be 0. If the RecipientIdentifier is 158 subjectKeyIdentifier, then the version MUST be 2. 160 The KeyTransRecipientInfo RecipientIdentifier provides two 161 alternatives for specifying the recipient's certificate, and thereby 162 the recipient's public key. The recipient's certificate must contain 163 a RSA public key. The content-encryption key is encrypted with the 164 recipient's RSA public key. The issuerAndSerialNumber alternative 165 identifies the recipient's certificate by the issuer's distinguished 166 name and the certificate serial number; the subjectKeyIdentifier 167 identifies the recipient's certificate by the X.509 168 subjectKeyIdentifier extension value. 170 The KeyTransRecipientInfo keyEncryptionAlgorithm specifies that the 171 RSAES-OAEP algorithm, and its associated parameters, was used to 172 encrypt the content-encryption key for the recipient. The key- 173 encryption process is described in [PKCS#1v2.0]. See section 3 of 174 this document for the algorithm identifier and the parameter syntax. 176 The KeyTransRecipientInfo encryptedKey is the result of encrypting 177 the content-encryption key in the recipient's RSA public key using 178 the RSAES-OAEP algorithm. When using a Triple-DES content-encryption 179 key, implementations MUST adjust the parity bits for each DES key 180 comprising the Triple-DES key prior to RSAES-OAEP encryption. 182 3 RSAES-OAEP Algorithm Identifiers and Parameters 184 The RSAES-OAEP key transport algorithm is the RSA encryption scheme 185 defined in RFC 2437 [PKCS#1v2.0], where the message to be encrypted 186 is the content-encryption key. The algorithm identifier for RSAES- 187 OAEP is: 189 id-RSAES-OAEP OBJECT IDENTIFIER ::= { 190 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 192 The AlgorithmIdentifier parameters field must be present, and the 193 parameters field must contain RSAES-OAEP-params. RSAES-OAEP-params 194 have the following syntax: 196 RSAES-OAEP-params ::= SEQUENCE { 197 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 198 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 199 pSourceFunc [2] AlgorithmIdentifier DEFAULT pSpecifiedEmptyIdentifier } 201 sha1Identifier ::= AlgorithmIdentifier { 202 id-sha1, NULL } 204 mgf1SHA1Identifier ::= AlgorithmIdentifier { 205 id-mgf1, sha1Identifier } 207 pSpecifiedEmptyIdentifier ::= AlgorithmIdentifier { 208 id-pSpecified, OCTET STRING SIZE (0) } 210 id-sha1 OBJECT IDENTIFIER ::= { 211 iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } 213 id-mgf1 OBJECT IDENTIFIER ::= { 214 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 8 } 216 id-pSpecified OBJECT IDENTIFIER ::= { 217 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 9 } 219 The fields of type RSAES-OAEP-params have the following meanings: 221 hashFunc identifies the one-way hash function. Implementations 222 MUST support SHA-1 [SHA1]. The SHA-1 algorithm identifier is 223 comprised of the id-sha1 object identifier and a parameter of 224 NULL. Implementations that perform encryption MUST omit the 225 hashFunc field when SHA-1 is used, indicating that the default 226 algorithm was used. Implementations that perform decryption MUST 227 recognize both the id-sha1 object identifier and an absent 228 hashFunc field as an indication that SHA-1 was used. 230 maskGenFunc identifies the mask generation function. 231 Implementations MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a 232 one-way hash function, and it is identified in the parameter field 233 of the MFG1 algorithm identifier. Implementations MUST support 234 SHA-1 [SHA1]. The MFG1 algorithm identifier is comprised of the 235 id-mgf1 object identifier and a parameter that contains the 236 algorithm identifier of the one-way hash function employed with 237 MFG1. The SHA-1 algorithm identifier is comprised of the id-sha1 238 object identifier and a parameter of NULL. Implementations that 239 perform encryption MUST omit the maskGenFunc field when MFG1 with 240 SHA-1 is used, indicating that the default algorithm was used. 241 Implementations that perform decryption MUST recognize both the 242 id-mgf1 and id-sha1 object identifiers as well as an absent 243 maskGenFunc field as an indication that MFG1 with SHA-1 was used. 245 pSourceFunc identifies the source (and possibly the value) of the 246 encoding parameters, commonly called P. Implementations MUST 247 represent P by an algorithm identifier, id-pSpecified, indicating 248 that P is explicitly provided as an OCTET STRING in the 249 parameters. The default value for P is an empty string. In this 250 case, pHash in EME-OAEP contains the hash of a zero length string. 251 Implementations MUST support a zero length P value. 252 Implementations that perform encryption MUST omit the pSourceFunc 253 field when a zero length P value is used, indicating that the 254 default value was used. Implementations that perform decryption 255 MUST recognize both the id-pSpecified object identifier and an 256 absent pSourceFunc field as an indication that a zero length P 257 value was used. 259 4 SMIMECapabilities Attribute Conventions 261 RFC 2633, Section 2.5.2 defines the SMIMECapabilities signed 262 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 263 used to specify a partial list of algorithms that the software 264 announcing the SMIMECapabilities can support. When constructing a 265 signedData object, compliant software MAY include the 266 SMIMECapabilities signed attribute announcing that it supports the 267 RSAES-OAEP algorithm. 269 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 270 id-RSAES-OAEP object identifier in the capabilityID field and MUST 271 include the RSAES-OAEP-Default-Identifier SEQUENCE in the parameters 272 field. 274 RSAES-OAEP-Default-Identifier ::= AlgorithmIdentifier { 275 id-RSAES-OAEP, { 276 sha1Identifier, mgf1SHA1Identifier, pSpecifiedEmptyIdentifier } } 278 When all of the default settings are selected, the SMIMECapability 279 SEQUENCE representing RSAES-OAEP MUST be DER-encoded as: 281 30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00 283 References 285 CMS Housley, R. Cryptographic Message Syntax. RFC 2630. 286 June 1999. 288 CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against 289 Protocols Based on the RSA Encryption Standard PKCS #1," 290 in H. Krawczyk (editor), Advances in Cryptology - CRYPTO '98 291 Proceedings, Lecture Notes in Computer Science 1462 (1998), 292 Springer-Verlag, pp. 1-12. 294 MUSTSHOULD Bradner, S. Key Words for Use in RFCs to Indicate 295 Requirement Levels. BCP 14, RFC 2119. March 1997. 297 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 298 RFC 2313. March 1998. 300 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 301 RFC 2437. October 1998. 303 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 304 X.509 Public Key Infrastructure: Certificate and CRL 305 Profile. RFC 2459. January 1999. 307 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 308 Recommendations for Security. RFC 1750. December 1994. 310 RSALABS Bleichenbacher, D., B. Kaliski, and J. Staddon. 311 Recent Results on PKCS #1: RSA Encryption Standard. 312 RSA Laboratories' Bulletin No. 7, June 26, 1998. 313 [Available at http://www.rsasecurity.com/rsalabs/bulletins] 315 SHA1 National Institute of Standards and Technology. 316 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 318 SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol, 319 Version 3.0. Netscape Communications. November 1996. 320 [Available at http://draft-freier-ssl-version3-02.txt] 322 TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. 323 RFC 2246. January 1999. 325 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 326 Syntax Notation One (ASN.1). 1988. 328 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 329 Rules for Abstract Syntax Notation One (ASN.1). 1988. 331 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 332 Framework. 1988. 334 Security Considerations 336 Implementations must protect the RSA private key and the content- 337 encryption key. Compromise of the RSA private key may result in the 338 disclosure of all messages protected with that key. Compromise of 339 the content-encryption key may result in disclosure of the associated 340 encrypted content. 342 Implementations must protect the key management private key and the 343 message-authentication key. Compromise of the key management private 344 key permits masquerade of authenticated data. Compromise of the 345 message-authentication key may result in undetectable modification of 346 the authenticated content. 348 The generation of RSA public/private key pairs relies on a random 349 numbers. The use of inadequate pseudo-random number generators 350 (PRNGs) to generate cryptographic keys can result in little or no 351 security. An attacker may find it much easier to reproduce the PRNG 352 environment that produced the keys, searching the resulting small set 353 of possibilities, rather than brute force searching the whole key 354 space. The generation of quality random numbers is difficult. RFC 355 1750 [RANDOM] offers important guidance in this area. 357 Acknowledgments 359 This document is the result of contributions from many professionals. 360 I appreciate the hard work of all members of the IETF S/MIME Working 361 Group. I wish to extend a special thanks to Burt Kaliski. 363 Author Address 365 Russell Housley 366 SPYRUS 367 381 Elden Street 368 Suite 1120 369 Herndon, VA 20170 370 USA 372 housley@spyrus.com 374 Full Copyright Statement 376 Copyright (C) The Internet Society (2000). All Rights Reserved. 378 This document and translations of it may be copied and furnished to 379 others, and derivative works that comment on or otherwise explain it 380 or assist in its implementation may be prepared, copied, published 381 and distributed, in whole or in part, without restriction of any 382 kind, provided that the above copyright notice and this paragraph are 383 included on all such copies and derivative works. In addition, the 384 ASN.1 module presented in Appendix A may be used in whole or in part 385 without inclusion of the copyright notice. However, this document 386 itself may not be modified in any way, such as by removing the 387 copyright notice or references to the Internet Society or other 388 Internet organizations, except as needed for the purpose of 389 developing Internet standards in which case the procedures for 390 copyrights defined in the Internet Standards process shall be 391 followed, or as required to translate it into languages other than 392 English. 394 The limited permissions granted above are perpetual and will not be 395 revoked by the Internet Society or its successors or assigns. This 396 document and the information contained herein is provided on an "AS 397 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 398 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 399 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 400 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 401 OR FITNESS FOR A PARTICULAR PURPOSE.