idnits 2.17.1 draft-ietf-smime-cms-rsaes-oaep-03.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 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.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 99: '..., when the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 100: '... MAY are used in capital letters, th...' RFC 2119 keyword, line 113: '...mpliant software MUST meet the require...' RFC 2119 keyword, line 117: '...t-encryption key MUST be randomly gene...' RFC 2119 keyword, line 124: '...ds of the EnvelopedData syntax MUST be...' (25 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 2002) is 7985 days in the past. Is this intentional? 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 section? 'RSALABS' on line 51 looks like a reference -- Missing reference section? 'CRYPTO98' on line 51 looks like a reference -- Missing reference section? 'MMA' on line 60 looks like a reference -- Missing reference section? 'CMS' on line 114 looks like a reference -- Missing reference section? 'SSL' on line 68 looks like a reference -- Missing reference section? 'TLS' on line 69 looks like a reference -- Missing reference section? 'PROFILE' on line 91 looks like a reference -- Missing reference section? 'STDWORDS' on line 101 looks like a reference -- Missing reference section? '3DES' on line 171 looks like a reference -- Missing reference section? '0' on line 414 looks like a reference -- Missing reference section? '1' on line 415 looks like a reference -- Missing reference section? '2' on line 416 looks like a reference -- Missing reference section? 'SHA1' on line 232 looks like a reference -- Missing reference section? 'MSG' on line 259 looks like a reference -- Missing reference section? 'RANDOM' on line 373 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet Draft RSA Laboratories 4 expires in six months June 2002 6 Use of the RSAES-OAEP Key Transport Algorithm in CMS 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Copyright Notice 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Abstract 35 This document describes the use of the RSAES-OAEP key transport 36 method of key management within the Cryptographic Message Syntax. 38 1 Introduction 40 This draft is being discussed on the "ietf-smime" mailing list. To 41 join the list, send a message to with 42 the single word "subscribe" in the body of the message. Also, there 43 is a Web site for the mailing list at . 46 PKCS #1 Version 1.5 [PKCS#1v1.5] specifies a widely deployed variant 47 of the RSA key transport algorithm. PKCS #1 Version 1.5 key 48 transport is vulnerable to adaptive chosen ciphertext attacks, 49 especially when it is used to for key management in interactive 50 applications. This attack is often referred to as the "Million 51 Message Attack," and it explained in [RSALABS] and [CRYPTO98]. 52 Exploitation of this vulnerability, which reveals the result of a 53 particular RSA decryption, requires access to an oracle which will 54 respond to hundreds of thousands of ciphertexts, which are 55 constructed adaptively in response to previously received replies 56 that provide information on the successes or failures of attempted 57 decryption operations. 59 The attack is significantly less feasible in store-and-forward 60 environments, such as S/MIME. RFC 3218 [MMA] discussed the 61 countermeasures to this attack that are available when PKCS #1 62 Version 1.5 key transport is used in conjunction with the 63 Cryptographic Message Syntax (CMS) [CMS]. 65 When PKCS #1 Version 1.5 key transport is applied as an intermediate 66 encryption layer within an interactive request-response 67 communications environment, exploitation could be more feasible. 68 However, Secure Sockets Layer (SSL) [SSL] and Transport Layer 69 Security (TLS) [TLS] protocol implementations could include 70 countermeasures that detect and prevent the Million Message Attack 71 and other chosen-ciphertext attacks. These countermeasures are 72 performed within the protocol level. In the interest of long-term 73 security assurance, it is prudent to adopt an improved cryptographic 74 technique rather than embedding countermeasures within protocols. 76 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 77 [PKCS#1v2.0]. This new document supersedes RFC 2313. PKCS #1 78 Version 2.0 preserves support for the encryption padding format 79 defined in PKCS #1 Version 1.5 [PKCS#1v1.5], and it also defines a 80 new alternative. To resolve the adaptive chosen ciphertext 81 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 82 of Optimal Asymmetric Encryption Padding (OAEP) for RSA key 83 transport. 85 This document specifies the use of RSAES-OAEP key transport algorithm 86 in the CMS. The CMS can be used in either a store-and-forward or an 87 interactive request-response environment. 89 The CMS supports variety of architectures for certificate-based key 90 management, particularly the one defined by the PKIX working group 91 [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require the 92 same RSA public key information. Thus, a certified RSA public key 93 may be used with either RSA key transport technique. 95 The CMS uses ASN.1 [X.208-88], the Basic Encoding Rules (BER) 97 [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88]. 99 Throughout this document, when the terms MUST, MUST NOT, SHOULD and 100 MAY are used in capital letters, their use conforms to the 101 definitions in [STDWORDS]. These key word definitions help make the 102 intent of standards documents as clear as possible. These key words 103 are used in this document to help implementers achieve 104 interoperability. 106 2 Enveloped-data Conventions 108 The CMS enveloped-data content type consists of an encrypted content 109 and wrapped content-encryption keys for one or more recipients. The 110 RSAES-OAEP key transport algorithm is used to wrap the content- 111 encryption key for one recipient. 113 Compliant software MUST meet the requirements for constructing an 114 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 115 data Content Type". 117 A content-encryption key MUST be randomly generated for each instance 118 of an enveloped-data content type. The content-encryption key is 119 used to encipher the content. 121 2.1 EnvelopedData Fields 123 The enveloped-data content type is ASN.1 encoded using the 124 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 125 populated as follows: 127 The EnvelopedData version MUST be 0, 2, or 3. 129 The EnvelopedData originatorInfo field is not used for the RSAES-OAEP 130 key transport algorithm. However, this field MAY be present to 131 support recipients using other key management algorithms. 133 The EnvelopedData recipientInfos CHOICE MUST be 134 KeyTransRecipientInfo. See section 2.2 for further discussion of 135 KeyTransRecipientInfo. 137 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 138 field MUST be a symmetric encryption algorithm identifier. 140 The EnvelopedData unprotectedAttrs MAY be present. 142 2.2 KeyTransRecipientInfo Fields 144 The enveloped-data content type is ASN.1 encoded using the 145 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 146 populated as follows: 148 The KeyTransRecipientInfo version MUST be 0 or 2. If the 149 RecipientIdentifier uses the issuerAndSerialNumber alternative, then 150 the version MUST be 0. If the RecipientIdentifier uses the 151 subjectKeyIdentifier alternative, then the version MUST be 2. 153 The KeyTransRecipientInfo RecipientIdentifier provides two 154 alternatives for specifying the recipient's certificate, and thereby 155 the recipient's public key. The recipient's certificate MUST contain 156 a RSA public key. The content-encryption key is encrypted with the 157 recipient's RSA public key. The issuerAndSerialNumber alternative 158 identifies the recipient's certificate by the issuer's distinguished 159 name and the certificate serial number; the subjectKeyIdentifier 160 identifies the recipient's certificate by the X.509 161 subjectKeyIdentifier extension value. 163 The KeyTransRecipientInfo keyEncryptionAlgorithm specifies that the 164 RSAES-OAEP algorithm, and its associated parameters, was used to 165 encrypt the content-encryption key for the recipient. The key- 166 encryption process is described in [PKCS#1v2.0]. See section 3 of 167 this document for the algorithm identifier and the parameter syntax. 169 The KeyTransRecipientInfo encryptedKey is the result of encrypting 170 the content-encryption key in the recipient's RSA public key using 171 the RSAES-OAEP algorithm. When using a Triple-DES [3DES] content- 172 encryption key, implementations MUST adjust the parity bits to ensure 173 odd parity for each octet of each DES key comprising the Triple-DES 174 key prior to RSAES-OAEP encryption. 176 3 RSAES-OAEP Algorithm Identifiers and Parameters 178 The RSAES-OAEP key transport algorithm is the RSA encryption scheme 179 defined in RFC 2437 [PKCS#1v2.0], where the message to be encrypted 180 is the content-encryption key. The algorithm identifier for RSAES- 181 OAEP is: 183 id-RSAES-OAEP OBJECT IDENTIFIER ::= { iso(1) member-body(2) 184 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 186 The AlgorithmIdentifier parameters field must be present, and the 187 parameters field must contain RSAES-OAEP-params. RSAES-OAEP-params 188 have the following syntax: 190 RSAES-OAEP-params ::= SEQUENCE { 191 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 192 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 193 pSourceFunc [2] AlgorithmIdentifier DEFAULT 194 pSpecifiedEmptyIdentifier } 196 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 198 mgf1SHA1Identifier AlgorithmIdentifier ::= 199 { id-mgf1, sha1Identifier } 201 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 202 { id-pSpecified, nullOctetString } 204 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 206 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 207 identified-organization(3) oiw(14) 208 secsig(3) algorithms(2) 26 } 210 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 211 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) } 213 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 215 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 217 The fields of type RSAES-OAEP-params have the following meanings: 219 hashFunc identifies the one-way hash function. Implementations 220 MUST support SHA-1 [SHA1]. The SHA-1 algorithm identifier is 221 comprised of the id-sha1 object identifier and a parameter of 222 NULL. Implementations that perform encryption MUST omit the 223 hashFunc field when SHA-1 is used, indicating that the default 224 algorithm was used. Implementations that perform decryption MUST 225 recognize both the id-sha1 object identifier and an absent 226 hashFunc field as an indication that SHA-1 was used. 228 maskGenFunc identifies the mask generation function. 229 Implementations MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a 230 one-way hash function, and it is identified in the parameter field 231 of the MFG1 algorithm identifier. Implementations MUST support 232 SHA-1 [SHA1]. The MFG1 algorithm identifier is comprised of the 233 id-mgf1 object identifier and a parameter that contains the 234 algorithm identifier of the one-way hash function employed with 235 MFG1. The SHA-1 algorithm identifier is comprised of the id-sha1 236 object identifier and a parameter of NULL. Implementations that 237 perform encryption MUST omit the maskGenFunc field when MFG1 with 238 SHA-1 is used, indicating that the default algorithm was used. 239 Implementations that perform decryption MUST recognize both the 240 id-mgf1 and id-sha1 object identifiers as well as an absent 241 maskGenFunc field as an indication that MFG1 with SHA-1 was used. 243 pSourceFunc identifies the source (and possibly the value) of the 244 encoding parameters, commonly called P. Implementations MUST 245 represent P by an algorithm identifier, id-pSpecified, indicating 246 that P is explicitly provided as an OCTET STRING in the 247 parameters. The default value for P is an empty string. In this 248 case, pHash in EME-OAEP contains the hash of a zero length string. 249 Implementations MUST support a zero length P value. 250 Implementations that perform encryption MUST omit the pSourceFunc 251 field when a zero length P value is used, indicating that the 252 default value was used. Implementations that perform decryption 253 MUST recognize both the id-pSpecified object identifier and an 254 absent pSourceFunc field as an indication that a zero length P 255 value was used. 257 4 SMIMECapabilities Attribute Conventions 259 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 260 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 261 used to specify a partial list of algorithms that the software 262 announcing the SMIMECapabilities can support. When constructing a 263 signedData object, compliant software MAY include the 264 SMIMECapabilities signed attribute announcing that it supports the 265 RSAES-OAEP algorithm. 267 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 268 id-RSAES-OAEP object identifier in the capabilityID field and MUST 269 include the RSAES-OAEP-Default-Identifier SEQUENCE in the parameters 270 field. 272 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 273 { id-RSAES-OAEP, 274 { sha1Identifier, 275 mgf1SHA1Identifier, 276 pSpecifiedEmptyIdentifier } } 278 When all of the default settings are selected, the SMIMECapability 279 SEQUENCE representing RSAES-OAEP MUST be DER-encoded as the following 280 hexadecimal string: 282 30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00 284 5 References 286 This section provides normative and informative references. 288 5.1 Normative References 290 3DES American National Standards Institute. ANSI X9.52-1998, 291 Triple Data Encryption Algorithm Modes of Operation. 1998. 293 CMS Housley, R. Cryptographic Message Syntax. RFC . 294 . 296 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 297 RFC 2633. June 1999. 299 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 300 RFC 2437. October 1998. 302 PROFILE Housley, R., W. Polk, W. Ford, and D. Solo. Internet 303 X.509 Public Key Infrastructure: Certificate and 304 Certificate Revocation List (CRL) Profile. RFC 3280. 305 April 2002. 307 SHA1 National Institute of Standards and Technology. 308 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 310 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 311 Requirement Levels. BCP 14, RFC 2119. March 1997. 313 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 314 Syntax Notation One (ASN.1). 1988. 316 X.209-88 CCITT. Recommendation X.209: Specification of Basic 317 Encoding Rules for Abstract Syntax Notation One 318 (ASN.1). 1988. 320 X.509-88 CCITT. Recommendation X.509: The Directory - 321 Authentication Framework. 1988. 323 5.2 Informative References 325 CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against 326 Protocols Based on the RSA Encryption Standard PKCS #1," 327 in H. Krawczyk (editor), Advances in Cryptology - CRYPTO '98 328 Proceedings, Lecture Notes in Computer Science 1462 (1998), 329 Springer-Verlag, pp. 1-12. 331 MMA Rescorla, E. Preventing the Million Message Attack on 332 Cryptographic Message Syntax. RFC 3218. January 2002. 334 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 335 RFC 2313. March 1998. 337 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 338 Recommendations for Security. RFC 1750. December 1994. 340 RSALABS Bleichenbacher, D., B. Kaliski, and J. Staddon. 341 Recent Results on PKCS #1: RSA Encryption Standard. 342 RSA Laboratories' Bulletin No. 7, June 26, 1998. 343 [http://www.rsasecurity.com/rsalabs/bulletins] 345 SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol, 346 Version 3.0. Netscape Communications. November 1996. 347 [http://wp.netscape.com/eng/ssl3/draft302.txt] 349 TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. 350 RFC 2246. January 1999. 352 6 Security Considerations 354 Implementations must protect the RSA private key and the content- 355 encryption key. Compromise of the RSA private key may result in the 356 disclosure of all messages protected with that key. Compromise of 357 the content-encryption key may result in disclosure of the associated 358 encrypted content. 360 Implementations must protect the key management private key and the 361 message-authentication key. Compromise of the key management private 362 key permits masquerade of authenticated data. Compromise of the 363 message-authentication key may result in undetectable modification of 364 the authenticated content. 366 The generation of RSA public/private key pairs relies on a random 367 numbers. The use of inadequate pseudo-random number generators 368 (PRNGs) to generate cryptographic keys can result in little or no 369 security. An attacker may find it much easier to reproduce the PRNG 370 environment that produced the keys, searching the resulting small set 371 of possibilities, rather than brute force searching the whole key 372 space. The generation of quality random numbers is difficult. RFC 373 1750 [RANDOM] offers important guidance in this area. 375 7 Acknowledgments 377 This document is the result of contributions from many professionals. 378 I appreciate the hard work of all members of the IETF S/MIME Working 379 Group. Further, I extend a special thanks to Burt Kaliski. 381 8 Author Address 383 Russell Housley 384 RSA Laboratories 385 918 Spring Knoll Drive 386 Herndon, VA 20170 387 USA 389 rhousley@rsasecurity.com 391 Appendix A ASN.1 Module 393 CMS-RSAES-OAEP {iso(1) member-body(2) us(840) rsadsi(113549) 394 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-rsaes-oaep(20) } 396 DEFINITIONS IMPLICIT TAGS ::= 397 BEGIN 399 -- EXPORTS ALL -- 401 IMPORTS 402 -- From PKIX Certificate and CRL Profile 403 AlgorithmIdentifier 404 FROM PKIXExplicit88 { iso(1) identified-organization(3) 405 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 406 id-mod(0) id-pkix1-explicit(18) }; 408 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 409 rsadsi(113549) pkcs(1) pkcs-1(1) } 411 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 413 RSAES-OAEP-params ::= SEQUENCE { 414 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 415 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 416 pSourceFunc [2] AlgorithmIdentifier DEFAULT 417 pSpecifiedEmptyIdentifier } 419 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 421 mgf1SHA1Identifier AlgorithmIdentifier ::= 422 { id-mgf1, sha1Identifier } 424 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 425 { id-pSpecified, nullOctetString } 427 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 428 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 429 identified-organization(3) oiw(14) 430 secsig(3) algorithms(2) 26 } 432 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 434 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 436 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 437 { id-RSAES-OAEP, 438 { sha1Identifier, 439 mgf1SHA1Identifier, 440 pSpecifiedEmptyIdentifier } } 442 END 444 Full Copyright Statement 446 Copyright (C) The Internet Society (2002). All Rights Reserved. 448 This document and translations of it may be copied and furnished to 449 others, and derivative works that comment on or otherwise explain it 450 or assist in its implementation may be prepared, copied, published 451 and distributed, in whole or in part, without restriction of any 452 kind, provided that the above copyright notice and this paragraph are 453 included on all such copies and derivative works. In addition, the 454 ASN.1 module presented in Appendix A may be used in whole or in part 455 without inclusion of the copyright notice. However, this document 456 itself may not be modified in any way, such as by removing the 457 copyright notice or references to the Internet Society or other 458 Internet organizations, except as needed for the purpose of 459 developing Internet standards in which case the procedures for 460 copyrights defined in the Internet Standards process shall be 461 followed, or as required to translate it into languages other than 462 English. 464 The limited permissions granted above are perpetual and will not be 465 revoked by the Internet Society or its successors or assigns. This 466 document and the information contained herein is provided on an "AS 467 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 468 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 469 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 470 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 471 OR FITNESS FOR A PARTICULAR PURPOSE.