idnits 2.17.1 draft-ietf-smime-cms-rsaes-oaep-06.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 111: '...mpliant software MUST meet the require...' RFC 2119 keyword, line 115: '...t-encryption key MUST be randomly gene...' RFC 2119 keyword, line 122: '...ds of the EnvelopedData syntax MUST be...' RFC 2119 keyword, line 126: '...elopedData version MUST be 0, 2, or 3....' RFC 2119 keyword, line 129: '... However, this field MAY be present to...' (43 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 (August 2002) is 7923 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 112 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 308 looks like a reference -- Missing reference section? 'STDWORDS' on line 99 looks like a reference -- Missing reference section? '3DES' on line 171 looks like a reference -- Missing reference section? '0' on line 586 looks like a reference -- Missing reference section? '1' on line 587 looks like a reference -- Missing reference section? '2' on line 588 looks like a reference -- Missing reference section? 'SHA1' on line 233 looks like a reference -- Missing reference section? 'CERTALGS' on line 284 looks like a reference -- Missing reference section? 'MSG' on line 327 looks like a reference -- Missing reference section? 'RANDOM' on line 489 looks like a reference -- Missing reference section? 'SHA2' on line 513 looks like a reference -- Missing reference section? 'NISTGUIDE' on line 530 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 20 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 August 2002 6 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/1id-abstracts.html 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 (2002). 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 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. 74 In the interest of long-term security assurance, it is prudent to 75 adopt an improved cryptographic technique rather than embedding 76 countermeasures within protocols. To this end, an updated version of 77 PKCS #1 has been published. PKCS #1 Version 2.0 [PKCS#1v2.0] 78 supersedes RFC 2313. It preserves support for the PKCS #1 Version 79 1.5 encryption padding format, and it also defines a new one. To 80 resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 81 Version 2.0 specifies and recommends use of Optimal Asymmetric 82 Encryption Padding (OAEP) for RSA key transport. 84 This document specifies the use of RSAES-OAEP key transport algorithm 85 in the CMS. The CMS can be used in either a store-and-forward or an 86 interactive request-response environment. 88 The CMS supports variety of architectures for certificate-based key 89 management, particularly the one defined by the PKIX working group 90 [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require the 91 same RSA public key information. Thus, a certified RSA public key 92 may be used with either RSA key transport technique. 94 The CMS uses ASN.1 [X.208-88], the Basic Encoding Rules (BER) 95 [X.209-88], and the Distinguished Encoding Rules (DER) [X.509-88]. 97 Throughout this document, when the terms "MUST," "MUST NOT," 98 "SHOULD," and "MAY" are used in capital letters, their use conforms 99 to the definitions in RFC 2119 [STDWORDS]. These key word 100 definitions help make the intent of standards documents as clear as 101 possible. These key words are used in this document to help 102 implementers achieve interoperability. 104 2. Enveloped-data Conventions 106 The CMS enveloped-data content type consists of an encrypted content 107 and wrapped content-encryption keys for one or more recipients. The 108 RSAES-OAEP key transport algorithm is used to wrap the content- 109 encryption key for one recipient. 111 Compliant software MUST meet the requirements for constructing an 112 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 113 data Content Type". 115 A content-encryption key MUST be randomly generated for each instance 116 of an enveloped-data content type. The content-encryption key is 117 used to encipher the content. 119 2.1. EnvelopedData Fields 121 The enveloped-data content type is ASN.1 encoded using the 122 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 123 populated as described in this section when RSAES-OAEP key transport 124 is employed for one or more recipients. 126 The EnvelopedData version MUST be 0, 2, or 3. 128 The EnvelopedData originatorInfo field is not used for the RSAES-OAEP 129 key transport algorithm. However, this field MAY be present to 130 support recipients using other key management algorithms. 132 The EnvelopedData recipientInfos CHOICE MUST be 133 KeyTransRecipientInfo. See section 2.2 for further discussion of 134 KeyTransRecipientInfo. 136 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 137 field MUST be a symmetric encryption algorithm identifier. 139 The EnvelopedData unprotectedAttrs MAY be present. 141 2.2. KeyTransRecipientInfo Fields 143 The fields of the KeyTransRecipientInfo syntax MUST be populated as 144 described in this section when RSAES-OAEP key transport is employed 145 for one or more recipients. 147 The KeyTransRecipientInfo version MUST be 0 or 2. If the 148 RecipientIdentifier uses the issuerAndSerialNumber alternative, then 149 the version MUST be 0. If the RecipientIdentifier uses the 150 subjectKeyIdentifier alternative, then the version MUST be 2. 152 The KeyTransRecipientInfo RecipientIdentifier provides two 153 alternatives for specifying the recipient's certificate, and thereby 154 the recipient's public key. The recipient's certificate MUST contain 155 a RSA public key. The content-encryption key is encrypted with the 156 recipient's RSA public key. The issuerAndSerialNumber alternative 157 identifies the recipient's certificate by the issuer's distinguished 158 name and the certificate serial number; the subjectKeyIdentifier 159 identifies the recipient's certificate by the X.509 160 subjectKeyIdentifier extension value. 162 The KeyTransRecipientInfo keyEncryptionAlgorithm specifies use of the 163 RSAES-OAEP algorithm, and its associated parameters, to encrypt the 164 content-encryption key for the recipient. The key-encryption process 165 is described in [PKCS#1v2.0]. See section 3 of this document for the 166 algorithm identifier and the parameter syntax. 168 The KeyTransRecipientInfo encryptedKey is the result of encrypting 169 the content-encryption key in the recipient's RSA public key using 170 the RSAES-OAEP algorithm. The RSA public key MUST be at least 1024 171 bits in length. When using a Triple-DES [3DES] content-encryption 172 key, implementations MUST adjust the parity bits to ensure odd parity 173 for each octet of each DES key comprising the Triple-DES key prior to 174 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 has 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 within RSAES-OAEP-params have the following meanings: 219 hashFunc identifies the one-way hash function. Implementations 220 MUST support SHA-1 [SHA1], and implementations MAY support other 221 one-way hash functions. The SHA-1 algorithm identifier is 222 comprised of the id-sha1 object identifier and a parameter of 223 NULL. Implementations that perform encryption MUST omit the 224 hashFunc field when SHA-1 is used, indicating that the default 225 algorithm was used. Implementations that perform decryption MUST 226 recognize both the id-sha1 object identifier and an absent 227 hashFunc field as an indication that SHA-1 was used. 229 maskGenFunc identifies the mask generation function. 230 Implementations MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a 231 one-way hash function, and it is identified in the parameter field 232 of the MFG1 algorithm identifier. Implementations MUST support 233 SHA-1 [SHA1], and implementations MAY support other one-way hash 234 functions. The MFG1 algorithm identifier is comprised of the id- 235 mgf1 object identifier and a parameter that contains the algorithm 236 identifier of the one-way hash function employed with MFG1. The 237 SHA-1 algorithm identifier is comprised of the id-sha1 object 238 identifier and a parameter of NULL. Implementations that perform 239 encryption MUST omit the maskGenFunc field when MFG1 with SHA-1 is 240 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. Certificate Conventions 261 RFC 3280 [PROFILE] specifies the profile for using X.509 Certificates 262 in Internet applications. When a RSA public key will be used for 263 RSAES-OAEP key transport, the conventions specified in this section 264 augment RFC 3280. 266 Traditionally, the rsaEncryption object identifier is used to 267 identify RSA public keys. However, to implement all of the 268 recommendations described in the Security Considerations section of 269 this document (see section 7), the certificate user needs to be able 270 to determine the form of key transport that the RSA private key owner 271 associates with the public key. 273 The rsaEncryption object identifier continues to identify the subject 274 public key when the RSA private key owner does not wish to limit the 275 use of the public key exclusively to RSAES-OAEP. In this case, the 276 rsaEncryption object identifier MUST be used in the algorithm field 277 within the subject public key information, and the parameters field 278 MUST contain NULL. 280 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 282 Further discussion of the conventions associated with use of the 283 rsaEncryption object identifier can be found in RFC 3279 (see 284 [CERTALGS], section 2.3.1). 286 When the RSA private key owner wishes to limit the use of the public 287 key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object 288 identifier MUST be used in the algorithm field within the subject 289 public key information, and the parameters field MUST contain 290 RSAES-OAEP-params. The id-RSAES-OAEP object identifier value and 291 the RSAES-OAEP-params syntax are fully described in section 3 of 292 this document. 294 Regardless of the object identifier used, the RSA public key is 295 encoded in the same manner in the subject public key information. 296 The RSA public key MUST be encoded using the type RSAPublicKey type: 298 RSAPublicKey ::= SEQUENCE { 299 modulus INTEGER, -- n 300 publicExponent INTEGER } -- e 302 Here, the modulus is the modulus n, and publicExponent is the public 303 exponent e. The DER encoded RSAPublicKey is carried in the 304 subjectPublicKey BIT STRING within the subject public key 305 information. 307 The intended application for the key MAY be indicated in the key 308 usage certificate extension (see [PROFILE], section 4.2.1.3). If the 309 keyUsage extension is present in a certificate that conveys an RSA 310 public key with the id-RSAES-OAEP object identifier, then the key 311 usage extension MUST contain a combination of the following values: 313 keyEncipherment; and 314 dataEncipherment. 316 However, both keyEncipherment and dataEncipherment SHOULD NOT be 317 present. 319 When a certificate that conveys an RSA public key with the 320 id-RSAES-OAEP object identifier, the certificate user MUST only 321 use the certified RSA public key for RSAES-OAEP operations, and 322 the certificate user MUST perform those operations using the 323 parameters identified in the certificate. 325 5. SMIMECapabilities Attribute Conventions 327 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 328 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 329 used to specify a partial list of algorithms that the software 330 announcing the SMIMECapabilities can support. When constructing a 331 signedData object, compliant software MAY include the 332 SMIMECapabilities signed attribute announcing that it supports the 333 RSAES-OAEP algorithm. 335 When all of the default settings are selected, the SMIMECapability 336 SEQUENCE representing RSAES-OAEP MUST include the id-RSAES-OAEP 337 object identifier in the capabilityID field and MUST include an empty 338 SEQUENCE in the parameters field. In this case, RSAES-OAEP is 339 represented by the rSAES-OAEP-Default-Identifier: 341 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 342 { id-RSAES-OAEP, 343 { sha1Identifier, 344 mgf1SHA1Identifier, 345 pSpecifiedEmptyIdentifier } } 347 The SMIMECapability SEQUENCE representing rSAES-OAEP-Default- 348 Identifier MUST be DER-encoded as the following hexadecimal string: 350 30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00 352 When settings other than the defaults are selected, the 353 SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 354 id-RSAES-OAEP object identifier in the capabilityID field and MUST 355 include the RSAES-OAEP-params SEQUENCE that identifies the 356 non-default settings in the parameters field. 358 When SHA-256 is used in the hashFunc and SHA-256 is used with MGF1 in 359 the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP 360 is the rSAES-OAEP-SHA256-Identifier, as specified in Appendix A. The 361 SMIMECapability SEQUENCE representing rSAES-OAEP-SHA256-Identifier 362 MUST be DER-encoded as the following hexadecimal string: 364 30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 365 0D 06 09 60 86 48 01 65 03 04 02 01 05 00 30 1A 366 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 367 86 48 01 65 03 04 02 01 05 00 369 When SHA-384 is used in the hashFunc and SHA-384 is used with MGF1 in 370 the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP 371 is the rSAES-OAEP-SHA384-Identifier, as specified in Appendix A. The 372 SMIMECapability SEQUENCE representing rSAES-OAEP-SHA384-Identifier 373 MUST be DER-encoded as the following hexadecimal string: 375 30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 376 0D 06 09 60 86 48 01 65 03 04 02 02 05 00 30 1A 377 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 378 86 48 01 65 03 04 02 02 05 00 380 When SHA-512 is used in the hashFunc and SHA-512 is used with MGF1 in 381 the maskGenFunc, the SMIMECapability SEQUENCE representing RSAES-OAEP 382 is the rSAES-OAEP-SHA512-Identifier, as specified in Appendix A. The 383 SMIMECapability SEQUENCE representing rSAES-OAEP-SHA512-Identifier 384 MUST be DER-encoded as the following hexadecimal string: 386 30 38 06 09 2A 86 48 86 F7 0D 01 01 07 30 2B 30 387 0D 06 09 60 86 48 01 65 03 04 02 03 05 00 30 1A 388 06 09 2A 86 48 86 F7 0D 01 01 08 30 0D 06 09 60 389 86 48 01 65 03 04 02 03 05 00 391 6. References 393 This section provides normative and informative references. 395 6.1. Normative References 397 3DES American National Standards Institute. ANSI X9.52-1998, 398 Triple Data Encryption Algorithm Modes of Operation. 1998. 400 CMS Housley, R. Cryptographic Message Syntax. RFC . 401 . 403 MSG Ramsdell, B. S/MIME Version 3 Message Specification. 404 RFC 2633. June 1999. 406 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 407 RFC 2437. October 1998. 409 PROFILE Housley, R., W. Polk, W. Ford, and D. Solo. Internet 410 X.509 Public Key Infrastructure: Certificate and 411 Certificate Revocation List (CRL) Profile. RFC 3280. 412 April 2002. 414 SHA1 National Institute of Standards and Technology. 415 FIPS Pub 180-1: "Secure Hash Standard." April 1995. 417 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 418 Requirement Levels. BCP 14, RFC 2119. March 1997. 420 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 421 Syntax Notation One (ASN.1). 1988. 423 X.209-88 CCITT. Recommendation X.209: Specification of Basic 424 Encoding Rules for Abstract Syntax Notation One 425 (ASN.1). 1988. 427 X.509-88 CCITT. Recommendation X.509: The Directory - 428 Authentication Framework. 1988. 430 6.2. Informative References 432 CERTALGS Polk, W., R. Housley, and L. Bassham. "Algorithms 433 and Identifiers for the Internet X.509 Public Key 434 Infrastructure Certificate and Certificate Revocation 435 List (CRL) Profile. RFC 3279. April 2002. 437 CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against 438 Protocols Based on the RSA Encryption Standard PKCS #1," 439 in H. Krawczyk (editor), Advances in Cryptology - 440 CRYPTO '98 Proceedings, Lecture Notes in Computer 441 Science 1462 (1998), Springer-Verlag, pp. 1-12. 443 MMA Rescorla, E. Preventing the Million Message Attack on 444 Cryptographic Message Syntax. RFC 3218. January 2002. 446 NISTGUIDE National Institute of Standards and Technology. 447 Second Draft: "Key Management Guideline, Part 1: 448 General Guidance." June 2002. 449 [http://csrc.nist.gov/encryption/kms/guideline-1.pdf] 451 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 452 RFC 2313. March 1998. 454 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 455 Recommendations for Security. RFC 1750. December 1994. 457 RSALABS Bleichenbacher, D., B. Kaliski, and J. Staddon. 458 Recent Results on PKCS #1: RSA Encryption Standard. 459 RSA Laboratories' Bulletin No. 7, June 26, 1998. 460 [http://www.rsasecurity.com/rsalabs/bulletins] 462 SHA2 National Institute of Standards and Technology. 463 Draft FIPS Pub 180-2: "Specifications for the Secure 464 Hash Standard." May 2001. 465 [http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf] 467 SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol, 468 Version 3.0. Netscape Communications. November 1996. 469 [http://wp.netscape.com/eng/ssl3/draft302.txt] 471 TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. 472 RFC 2246. January 1999. 474 7. Security Considerations 476 Implementations must protect the RSA private key and the content- 477 encryption key. Compromise of the RSA private key may result in the 478 disclosure of all messages protected with that key. Compromise of 479 the content-encryption key may result in disclosure of the associated 480 encrypted content. 482 The generation of RSA public/private key pairs relies on a random 483 numbers. The use of inadequate pseudo-random number generators 484 (PRNGs) to generate cryptographic keys can result in little or no 485 security. An attacker may find it much easier to reproduce the PRNG 486 environment that produced the keys, searching the resulting small set 487 of possibilities, rather than brute force searching the whole key 488 space. The generation of quality random numbers is difficult. RFC 489 1750 [RANDOM] offers important guidance in this area. 491 Generally, good cryptographic practice employs a given RSA key pair 492 in only one scheme. This practice avoids the risk that vulnerability 493 in one scheme may compromise the security of the other, and may be 494 essential to maintain provable security. While PKCS #1 Version 1.5 495 [PKCS#1v1.5] has been employed for both key transport and digital 496 signature without any known bad interactions, such a combined use of 497 an RSA key pair is not recommended in the future. Therefore, an RSA 498 key pair used for RSAES-OAEP key transport should not also be used 499 for other purposes. For similar reasons, one RSA key pair should 500 always be used with the same RSAES-OAEP parameters. 502 This specification requires implementation to support the SHA-1 one- 503 way hash function for interoperability, but support for other one-way 504 hash function is permitted. At the time of this writing, the best 505 (known) collision attacks against SHA-1 are generic attacks with 506 complexity 2^80, where 80 is one-half the bit length of the hash 507 value. When a one-way hash function is used with a digital signature 508 scheme, a collision attack is easily translated into a signature 509 forgery. Therefore, the use of SHA-1 in a digital signature scheme 510 provides a security level of no more than 80 bits. If a greater 511 level of security is desired, then a secure one-way hash function 512 with a longer hash value is needed. SHA-256, SHA-384, and SHA-512 513 are likely candidates [SHA2]. 515 The metrics for choosing a one-way hash function for use in digital 516 signatures do not directly apply to the RSAES-OAEP key transport 517 algorithm, since a collision attack on the one-way hash function does 518 not directly translate into an attack on the key transport algorithm, 519 unless the encoding parameters P varies (in which case a collision 520 the hash value for different encoding parameters might be exploited). 521 Nevertheless, for consistency with the practice for digital signature 522 schemes, and in case the encoding parameters P is not the empty 523 string, it is recommended that the same rule of thumb be applied to 524 selection of a one-way hash function for use with RSAES-OAEP. That 525 is, the one-way hash function should be selected so that the bit 526 length of the hash value is at least twice as long as the desired 527 security level in bits. 529 A 1024-bit RSA public key and SHA-1 both provide a security level of 530 about 80 bits. In [NISTGUIDE], the National Institute of Standards 531 and Technology suggests that a security level of 80 bits is adequate 532 for most applications until 2015. If a security level greater than 533 80 bits is needed, then a longer RSA public key and a secure one-way 534 hash function with a longer hash value are needed. Again, SHA-256, 535 SHA-384, and SHA-512 are likely candidates for such a one-way hash 536 function. For this reason, the algorithm identifiers for these one- 537 way hash functions are included in the ASN.1 module in Appendix A. 539 The same one-way hash function should be employed for the hashFunc 540 and the maskGenFunc, but it is not required. Using the same one-way 541 hash function reduces the potential for implementation errors. 543 8. Acknowledgments 545 This document is the result of contributions from many professionals. 546 I appreciate the hard work of all members of the IETF S/MIME Working 547 Group. Further, I extend a special thanks to Burt Kaliski, Jakob 548 Jonsson, Francois Rousseau, and Jim Schaad. 550 9. Author Address 552 Russell Housley 553 RSA Laboratories 554 918 Spring Knoll Drive 555 Herndon, VA 20170 556 USA 558 rhousley@rsasecurity.com 560 Appendix A. ASN.1 Module 562 CMS-RSAES-OAEP 563 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 564 pkcs-9(9) smime(16) modules(0) cms-rsaes-oaep(20) } 566 DEFINITIONS IMPLICIT TAGS ::= 567 BEGIN 569 -- EXPORTS ALL -- 571 IMPORTS 572 AlgorithmIdentifier 573 FROM PKIX1Explicit88 -- RFC 3280 574 { iso(1) identified-organization(3) dod(6) internet(1) 575 security(5) mechanisms(5) pkix(7) id-mod(0) 576 id-pkix1-explicit(18) }; 578 pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 579 rsadsi(113549) pkcs(1) pkcs-1(1) } 581 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 583 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 585 RSAES-OAEP-params ::= SEQUENCE { 586 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 587 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 588 pSourceFunc [2] AlgorithmIdentifier DEFAULT 589 pSpecifiedEmptyIdentifier } 591 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 593 sha256Identifier AlgorithmIdentifier ::= { id-sha256, NULL } 595 sha384Identifier AlgorithmIdentifier ::= { id-sha384, NULL } 597 sha512Identifier AlgorithmIdentifier ::= { id-sha512, NULL } 599 mgf1SHA1Identifier AlgorithmIdentifier ::= 600 { id-mgf1, sha1Identifier } 602 mgf1SHA256Identifier AlgorithmIdentifier ::= 603 { id-mgf1, sha256Identifier } 605 mgf1SHA384Identifier AlgorithmIdentifier ::= 606 { id-mgf1, sha384Identifier } 608 mgf1SHA512Identifier AlgorithmIdentifier ::= 609 { id-mgf1, sha512Identifier } 611 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= 612 { id-pSpecified, nullOctetString } 614 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 616 id-sha1 OBJECT IDENTIFIER ::= { iso(1) 617 identified-organization(3) oiw(14) 618 secsig(3) algorithms(2) 26 } 620 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 621 country(16) us(840) organization(1) gov(101) 622 csor(3) nistalgorithm(4) hashalgs(2) 1 } 624 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 625 country(16) us(840) organization(1) gov(101) 626 csor(3) nistalgorithm(4) hashalgs(2) 2 } 628 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 629 country(16) us(840) organization(1) gov(101) 630 csor(3) nistalgorithm(4) hashalgs(2) 3 } 632 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 634 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 636 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= 637 { id-RSAES-OAEP, 638 { sha1Identifier, 639 mgf1SHA1Identifier, 640 pSpecifiedEmptyIdentifier } } 642 rSAES-OAEP-SHA256-Identifier AlgorithmIdentifier ::= 643 { id-RSAES-OAEP, 644 { sha256Identifier, 645 mgf1SHA256Identifier, 646 pSpecifiedEmptyIdentifier } } 648 rSAES-OAEP-SHA384-Identifier AlgorithmIdentifier ::= 649 { id-RSAES-OAEP, 650 { sha384Identifier, 651 mgf1SHA384Identifier, 652 pSpecifiedEmptyIdentifier } } 654 rSAES-OAEP-SHA512-Identifier AlgorithmIdentifier ::= 655 { id-RSAES-OAEP, 656 { sha512Identifier, 657 mgf1SHA512Identifier, 658 pSpecifiedEmptyIdentifier } } 660 END 662 Full Copyright Statement 664 Copyright (C) The Internet Society (2002). All Rights Reserved. 666 This document and translations of it may be copied and furnished to 667 others, and derivative works that comment on or otherwise explain it 668 or assist in its implementation may be prepared, copied, published 669 and distributed, in whole or in part, without restriction of any 670 kind, provided that the above copyright notice and this paragraph are 671 included on all such copies and derivative works. In addition, the 672 ASN.1 module presented in Appendix A may be used in whole or in part 673 without inclusion of the copyright notice. However, this document 674 itself may not be modified in any way, such as by removing the 675 copyright notice or references to the Internet Society or other 676 Internet organizations, except as needed for the purpose of 677 developing Internet standards in which case the procedures for 678 copyrights defined in the Internet Standards process shall be 679 followed, or as required to translate it into languages other than 680 English. 682 The limited permissions granted above are perpetual and will not be 683 revoked by the Internet Society or its successors or assigns. This 684 document and the information contained herein is provided on an "AS 685 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 686 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 687 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 688 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 689 OR FITNESS FOR A PARTICULAR PURPOSE.