idnits 2.17.1 draft-ietf-smime-cms-rsaes-oaep-01.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 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 93: '..., when the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 94: '... MAY are used in capital letters, th...' RFC 2119 keyword, line 99: '...th this document MUST provide the capa...' RFC 2119 keyword, line 100: '...indicated by the MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 109: '...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 (June 2000) is 8716 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 112, but not defined == Missing Reference: 'RSALAB' is mentioned on line 49, but not defined == Missing Reference: 'CRYPTO98' is mentioned on line 49, but not defined == Missing Reference: 'SSL' is mentioned on line 62, but not defined == Missing Reference: 'TLS' is mentioned on line 63, but not defined == Missing Reference: 'PROFILE' is mentioned on line 87, but not defined == Missing Reference: 'MUSTSHOULD' is mentioned on line 95, but not defined -- Looks like a reference, but probably isn't: '0' on line 188 -- Looks like a reference, but probably isn't: '1' on line 189 -- Looks like a reference, but probably isn't: '2' on line 190 == Missing Reference: 'SHA1' is mentioned on line 225, but not defined == Missing Reference: '30 00' is mentioned on line 271, but not defined == Unused Reference: 'RANDOM' is defined on line 345, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RANDOM' Summary: 7 errors (**), 0 flaws (~~), 15 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 June 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 Copyright Notice 30 Copyright (C) The Internet Society (2000). All Rights Reserved. 32 Abstract 34 This document describes the use of the RSAES-OAEP key transport 35 method of key management within the Cryptographic Message Syntax 36 [CMS]. 38 This draft is being discussed on the "ietf-smime" mailing list. To 39 join the list, send a message to with 40 the single word "subscribe" in the body of the message. Also, there 41 is a Web site for the mailing list at . 44 1 Introduction 46 When the variant of the RSA key transport algorithm specified in PKCS 47 #1 Version 1.5 [PKCS#1v1.5] is used for key management, it is 48 vulnerable to adaptive chosen ciphertext attacks. This attack is 49 explained in [RSALAB] and [CRYPTO98]. The use of PKCS #1 Version 1.5 50 key transport in interactive applications is especially vulnerable. 51 Exploitation of this identified vulnerability, revealing the result 52 of a particular RSA decryption, requires access to an oracle which 53 will respond to hundreds of thousands of ciphertexts, which are 54 constructed adaptively in response to previously-received replies 55 providing information on the successes or failures of attempted 56 decryption operations. 58 The attack appears significantly less feasible in store-and-forward 59 environments, such as S/MIME. When PKCS #1 Version 1.5 key transport 60 is applied as an intermediate encryption layer within an interactive 61 request-response communications environment, exploitation could be 62 more feasible. However, Secure Sockets Layer (SSL) [SSL] and 63 Transport Layer Security (TLS) [TLS] protocol implementations could 64 include countermeasures that detect and prevent Bleichenbacher's and 65 other chosen-ciphertext attacks, without changing the way the RSA key 66 transport algorithm is used. These countermeasures are performed 67 within the protocol level. In the interest of long-term security 68 assurance, it is prudent to adopt an improved cryptographic technique 69 rather than embedding countermeasures within protocols. 71 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 72 [PKCS#1v2.0]. This new document supersedes RFC 2313. PKCS #1 73 Version 2.0 preserves support for the encryption padding format 74 defined in PKCS #1 Version 1.5 [PKCS#1v1.5], and it also defines a 75 new alternative. To resolve the adaptive chosen ciphertext 76 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 77 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 78 is used to provide confidentiality, such as key transport. 80 This document specifies the use of RSAES-OAEP key transport algorithm 81 in the Cryptographic Message Syntax (CMS) [CMS]. CMS can be used in 82 either a store-and-forward or an interactibe request-response 83 environment. 85 CMS supports variety of architectures for certificate-based key 86 management, particularly the one defined by the PKIX working group 87 [PROFILE]. 89 CMS values are generated using ASN.1 [X.208-88], using the Basic 90 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 91 (DER) [X.509-88]. 93 Throughout this document, when the terms MUST, MUST NOT, SHOULD and 94 MAY are used in capital letters, their use conforms to the 95 definitions in [MUSTSHOULD]. [MUSTSHOULD] defines these key words to 96 help make the intent of standards track documents as clear as 97 possible. The same key words are used in this document to help 98 implementers achieve interoperability. Implementations that claims 99 compliance with this document MUST provide the capabilities as 100 indicated by the MUST, MUST NOT, SHOULD and MAY terms. 102 2 Enveloped-data Conventions 104 The CMS enveloped-data content type consists of encrypted content and 105 wrapped content-encryption keys for one or more recipients. The 106 RSAES-OAEP key transport algorithm is used to wrap the content- 107 encryption key for one recipient. 109 Compliant software MUST meet the requirements for constructing an 110 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 111 data Content Type". [CMS] Section 6 should be studied before reading 112 this section, because this section does not repeat the [CMS] text. 114 A content-encryption key MUST be randomly generated for each instance 115 of an enveloped-data content type. The content-encryption key is 116 used to encipher the content. 118 2.1 EnvelopedData Fields 120 The enveloped-data content type is ASN.1 encoded using the 121 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 122 populated as follows: 124 The EnvelopedData version MUST be either 0 or 2. 126 The EnvelopedData originatorInfo field MUST be absent. 128 The EnvelopedData recipientInfos CHOICE MUST be 129 KeyTransRecipientInfo. See section 2.2 for further discussion of 130 KeyTransRecipientInfo. 132 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 133 field MUST be specify a symmetric encryption algorithm. 134 Implementations MUST support the encryption of Triple-DES content- 135 encryption keys, but implementations MAY support other algorithms as 136 well. 138 The EnvelopedData unprotectedAttrs MAY be present. 140 2.2 KeyTransRecipientInfo Fields 142 The enveloped-data content type is ASN.1 encoded using the 143 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 144 populated as follows: 146 The KeyTransRecipientInfo version MUST be either 0 or 2. If the 147 RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the 148 version MUST be 0. If the RecipientIdentifier is 149 subjectKeyIdentifier, then the version MUST be 2. 151 The KeyTransRecipientInfo RecipientIdentifier provides two 152 alternatives for specifying the recipient's certificate, and thereby 153 the recipient's public key. The recipient's certificate must contain 154 a RSA public key. The content-encryption key is encrypted with the 155 recipient's RSA public key. The issuerAndSerialNumber alternative 156 identifies the recipient's certificate by the issuer's distinguished 157 name and the certificate serial number; the subjectKeyIdentifier 158 identifies the recipient's certificate by the X.509 159 subjectKeyIdentifier extension value. 161 The KeyTransRecipientInfo keyEncryptionAlgorithm specifies that the 162 RSAES-OAEP algorithm, and its associated parameters, was used to 163 encrypt the content-encryption key for the recipient. The key- 164 encryption process is described in [PKCS#1v2.0]. See section 3 of 165 this document for the algorithm identifier and the parameter syntax. 167 The KeyTransRecipientInfo encryptedKey is the result of encrypting 168 the content-encryption key in the recipient's RSA public key using 169 the RSAES-OAEP algorithm. When using a Triple-DES content-encryption 170 key, implementations MUST adjust the parity bits for each DES key 171 comprising the Triple-DES key prior to RSAES-OAEP encryption. 173 3 RSAES-OAEP Algorithm Identifiers and Parameters 175 The RSAES-OAEP key transport algorithm is the RSA encryption scheme 176 defined in RFC 2347 [PKCS#1v2.0], where the message to be encrypted 177 is the content-encryption key. The algorithm identifier for RSAES- 178 OAEP is: 180 id-RSAES-OAEP OBJECT IDENTIFIER ::= { 181 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 183 The AlgorithmIdentifier parameters field must be present, and the 184 parameters field must contain RSAES-OAEP-params. RSAES-OAEP-params 185 have the following syntax: 187 RSAES-OAEP-params ::= SEQUENCE { 188 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 189 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 190 pSourceFunc [2] AlgorithmIdentifier DEFAULT pSpecifiedEmptyIdentifier } 192 sha1Identifier ::= AlgorithmIdentifier { 193 id-sha1, NULL } 195 mgf1SHA1Identifier ::= AlgorithmIdentifier { 196 id-mgf1, sha1Identifier } 198 pSpecifiedEmptyIdentifier ::= AlgorithmIdentifier { 199 id-pSpecified, OCTET STRING SIZE (0) } 201 id-sha1 OBJECT IDENTIFIER ::= { 202 iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } 204 id-mgf1 OBJECT IDENTIFIER ::= { 205 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 8 } 207 id-pSpecified OBJECT IDENTIFIER ::= { 208 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 9 } 210 The fields of type RSAES-OAEP-params have the following meanings: 212 hashFunc identifies the one-way hash function. Implementations 213 MUST support SHA-1 [SHA1]. The SHA-1 algorithm identifier is 214 comprised of the id-sha1 object identifier and a parameter of 215 NULL. Implementations that perform encryption MUST omit the 216 hashFunc field when SHA-1 is used, indicating that the default 217 algorithm was used. Implementations that perform decryption MUST 218 recognize both the id-sha1 object identifier and an absent 219 hashFunc field as an indication that SHA-1 was used. 221 maskGenFunc identifies the mask generation function. 222 Implementations MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a 223 one-way hash function, and it is identified in the parameter field 224 of the algorithm identifier. Implementations MUST support SHA-1 225 [SHA1]. The MFG1 algorithm identifier is comprised of the id-mgf1 226 object identifier and a parameter of the SHA-1 algorithm 227 identifier. Again, the SHA-1 algorithm identifier is comprised of 228 the id-sha1 object identifier and a parameter of NULL. 229 Implementations that perform encryption MUST omit the maskGenFunc 230 field when MFG1 with SHA-1 is used, indicating that the default 231 algorithm was used. Implementations that perform decryption MUST 232 recognize both the id-mgf1 and id-sha1 object identifiers as well 233 as an absent maskGenFunc field as an indication that MFG1 with 234 SHA-1 was used. 236 pSourceFunc identifies the source (and possibly the value) of the 237 encoding parameters, commonly called P. Implementations MUST 238 represent P by an algorithm identifier, id-pSpecified, indicating 239 that P is explicitly provided as an OCTET STRING in the 240 parameters. The default value for P is an empty string. In this 241 case, pHash in EME-OAEP contains the hash of a zero length string. 242 Implementations MUST support a zero length P value. 243 Implementations that perform encryption MUST omit the pSourceFunc 244 field when a zero length P value is used, indicating that the 245 default value was used. Implementations that perform decryption 246 MUST recognize both the id-pSpecified object identifier and an 247 absent pSourceFunc field as an indication that a zero length P 248 value was used. 250 4 SMIMECapabilities Attribute Conventions 252 RFC 2633, Section 2.5.2 defines the SMIMECapabilities signed 253 attribute (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be 254 used to specify a partial list of algorithms that the software 255 announcing the SMIMECapabilities can support. When constructing a 256 signedData object, compliant software MAY include the 257 SMIMECapabilities signed attribute announcing that it supports the 258 RSAES-OAEP algorithm. 260 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 261 id-RSAES-OAEP object identifier in the capabilityID field and MUST 262 include the RSAES-OAEP-Default-Identifier SEQUENCE in the parameters 263 field. 265 RSAES-OAEP-Default-Identifier ::= AlgorithmIdentifier { 266 id-RSAES-OAEP, { 267 sha1Identifier, mgf1SHA1Identifier, pSpecifiedEmptyIdentifier } } 269 When all of the default settings are selected, the SMIMECapability 270 SEQUENCE representing RSAES-OAEP MUST be DER-encoded as: 30 length 271 [id-RSAES-OAEP OID encoding] [30 00]. 273 References 275 CMS Housley, R. Cryptographic Message Syntax. RFC 2630. 276 June 1999. 278 CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against 279 Protocols Based on the RSA Encryption Standard PKCS #1," 280 in H. Krawczyk (editor), Advances in Cryptology - CRYPTO '98 281 Proceedings, Lecture Notes in Computer Science 1462 (1998), 282 Springer-Verlag, pp. 1-12. 284 MUSTSHOULD Bradner, S. Key Words for Use in RFCs to Indicate 285 Requirement Levels. BCP 14, RFC 2119. March 1997. 287 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 288 RFC 2313. March 1998. 290 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 291 RFC 2347. October 1998. 293 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 294 X.509 Public Key Infrastructure: Certificate and CRL 295 Profile. RFC 2459. January 1999. 297 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 298 Recommendations for Security. RFC 1750. December 1994. 300 RSALABS Daniel Bleichenbacher, D., B. Kaliski, and J. Staddon. 301 Recent Results on PKCS #1: RSA Encryption Standard. RSA 302 Laboratories' Bulletin No. 7, June 26, 1998. 303 [Available at http://www.rsasecurity.com/rsalabs/bulletins] 305 SHA1 National Institute of Standards and Technology. 306 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 308 SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol, 309 Version 3.0. Netscape Communications. November 1996. 310 [Available at http://draft-freier-ssl-version3-02.txt] 312 TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. 313 RFC 2246. January 1999. 315 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 316 Syntax Notation One (ASN.1). 1988. 318 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 319 Rules for Abstract Syntax Notation One (ASN.1). 1988. 321 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 322 Framework. 1988. 324 Security Considerations 326 Implementations must protect the RSA private key and the content- 327 encryption key. Compromise of the RSA private key may result in the 328 disclosure of all messages protected with that key. Compromise of 329 the content-encryption key may result in disclosure of the associated 330 encrypted content. 332 Implementations must protect the key management private key and the 333 message-authentication key. Compromise of the key management private 334 key permits masquerade of authenticated data. Compromise of the 335 message-authentication key may result in undetectable modification of 336 the authenticated content. 338 The generation of RSA public/private key pairs relies on a random 339 numbers. The use of inadequate pseudo-random number generators 340 (PRNGs) to generate cryptographic keys can result in little or no 341 security. An attacker may find it much easier to reproduce the PRNG 342 environment that produced the keys, searching the resulting small set 343 of possibilities, rather than brute force searching the whole key 344 space. The generation of quality random numbers is difficult. RFC 345 1750 [RANDOM] offers important guidance in this area. 347 Acknowledgments 349 This document is the result of contributions from many professionals. 350 I appreciate the hard work of all members of the IETF S/MIME Working 351 Group. I wish to extend a special thanks to Burt Kaliski. 353 Author Address 355 Russell Housley 356 SPYRUS 357 381 Elden Street 358 Suite 1120 359 Herndon, VA 20170 360 USA 362 housley@spyrus.com 364 Full Copyright Statement 366 Copyright (C) The Internet Society (2000). All Rights Reserved. 368 This document and translations of it may be copied and furnished to 369 others, and derivative works that comment on or otherwise explain it 370 or assist in its implementation may be prepared, copied, published 371 and distributed, in whole or in part, without restriction of any 372 kind, provided that the above copyright notice and this paragraph are 373 included on all such copies and derivative works. In addition, the 374 ASN.1 module presented in Appendix A may be used in whole or in part 375 without inclusion of the copyright notice. However, this document 376 itself may not be modified in any way, such as by removing the 377 copyright notice or references to the Internet Society or other 378 Internet organizations, except as needed for the purpose of 379 developing Internet standards in which case the procedures for 380 copyrights defined in the Internet Standards process shall be 381 followed, or as required to translate it into languages other than 382 English. 384 The limited permissions granted above are perpetual and will not be 385 revoked by the Internet Society or its successors or assigns. This 386 document and the information contained herein is provided on an "AS 387 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 388 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 389 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 390 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 391 OR FITNESS FOR A PARTICULAR PURPOSE.