idnits 2.17.1 draft-ietf-smime-cms-rsaes-oaep-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 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 8 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 87: '..., when the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 88: '... MAY are used in capital letters, th...' RFC 2119 keyword, line 93: '...th this document MUST provide the capa...' RFC 2119 keyword, line 94: '...indicated by the MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 103: '...mpliant software MUST meet the require...' (20 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 (February 2000) is 8836 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: 'CMS' is mentioned on line 106, but not defined == Missing Reference: 'PROFILE' is mentioned on line 81, but not defined == Missing Reference: 'MUSTSHOULD' is mentioned on line 89, but not defined -- Looks like a reference, but probably isn't: '0' on line 182 -- Looks like a reference, but probably isn't: '1' on line 183 -- Looks like a reference, but probably isn't: '2' on line 184 == Missing Reference: 'SHA1' is mentioned on line 215, but not defined == Unused Reference: 'RANDOM' is defined on line 303, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RANDOM' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 6 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 February 2000 5 CMS RSAES-OAEP Conventions 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 algorithm specified in PKCS #1 Version 53 1.5 [PKCS#1v1.5] is used for key management, it is vulnerable to 54 adaptive chosen ciphertext attacks. The use of PKCS #1 Version 1.5 55 key transport in interactive applications is especially vulnerable. 56 Exploitation of this identified vulnerability, revealing the result 57 of a particular RSA decryption, requires access to an oracle which 58 will respond to hundreds of thousands of ciphertexts, which are 59 constructed adaptively in response to previously-received replies 60 providing information on the successes or failures of attempted 61 decryption operations. As a result, the attack appears significantly 62 less feasible in store-and-forward environments, such as S/MIME. 63 When PKCS #1 Version 1.5 key transport is applied as an intermediate 64 encryption layer within an interactive request-response 65 communications environment, exploitation could be more feasible. 67 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 68 [PKCS#1v2.0]. This new document supersedes RFC 2313. PKCS #1 69 Version 2.0 preserves support for the encryption padding format 70 defined in PKCS #1 Version 1.5 [PKCS#1v1.5], and it also defines a 71 new alternative. To resolve the adaptive chosen ciphertext 72 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 73 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 74 is used to provide confidentiality. 76 This document specifies the use of RSAES-OAEP key transport algorithm 77 in the Cryptographic Message Syntax (CMS) [CMS]. 79 CMS supports variety of architectures for certificate-based key 80 management, particularly the one defined by the PKIX working group 81 [PROFILE]. 83 CMS values are generated using ASN.1 [X.208-88], using the Basic 84 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 85 (DER) [X.509-88]. 87 Throughout this document, when the terms MUST, MUST NOT, SHOULD and 88 MAY are used in capital letters, their use conforms to the 89 definitions in [MUSTSHOULD]. [MUSTSHOULD] defines these key words to 90 help make the intent of standards track documents as clear as 91 possible. The same key words are used in this document to help 92 implementers achieve interoperability. Implementations that claims 93 compliance with this document MUST provide the capabilities as 94 indicated by the MUST, MUST NOT, SHOULD and MAY terms. 96 2 Enveloped-data Conventions 98 The CMS enveloped-data content type consists of encrypted content and 99 wrapped content-encryption keys for one or more recipients. The RSAES- 100 OAEP key transport algorithm is used to wrap the content-encryption key 101 for one recipient. 103 Compliant software MUST meet the requirements for constructing an 104 enveloped-data content type stated in [CMS] Section 6, "Enveloped-data 105 Content Type". [CMS] Section 6 should be studied before reading this 106 section, because this section does not repeat the [CMS] text. 108 A content-encryption key MUST be randomly generated for each instance of 109 an enveloped-data content type. The content-encryption key is used to 110 encipher the content. 112 2.1 EnvelopedData Fields 114 The enveloped-data content type is ASN.1 encoded using the 115 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 116 populated as follows: 118 The EnvelopedData version MUST be either 0 or 2. 120 The EnvelopedData originatorInfo field MUST be absent. 122 The EnvelopedData recipientInfos CHOICE MUST be 123 KeyTransRecipientInfo. See section 2.2 for further discussion of 124 KeyTransRecipientInfo. 126 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 127 field MUST be specify a symmetric encryption algorithm. 128 Implementations MUST support the encryption of Triple-DES content- 129 encryption keys, but implementations MAY support other algorithms as 130 well. 132 The EnvelopedData unprotectedAttrs MAY be present. 134 2.2 KeyTransRecipientInfo Fields 136 The enveloped-data content type is ASN.1 encoded using the 137 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 138 populated as follows: 140 The KeyTransRecipientInfo version MUST be either 0 or 2. If the 141 RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the 142 version MUST be 0. If the RecipientIdentifier is 143 subjectKeyIdentifier, then the version MUST be 2. 145 The KeyTransRecipientInfo RecipientIdentifier provides two 146 alternatives for specifying the recipient's certificate, and thereby 147 the recipient's public key. The recipient's certificate must contain 148 a RSA public key. The content-encryption key is encrypted with the 149 recipient's RSA public key. The issuerAndSerialNumber alternative 150 identifies the recipient's certificate by the issuer's distinguished 151 name and the certificate serial number; the subjectKeyIdentifier 152 identifies the recipient's certificate by the X.509 153 subjectKeyIdentifier extension value. 155 The KeyTransRecipientInfo keyEncryptionAlgorithm specifies that the 156 RSAES-OAEP algorithm, and its associated parameters, was used to 157 encrypt the content-encryption key for the recipient. The key- 158 encryption process is described in [PKCS#1v2.0]. See section 3 of 159 this document for the algorithm identifier and the parameter syntax. 161 The KeyTransRecipientInfo encryptedKey is the result of encrypting 162 the content-encryption key in the recipient's RSA public key using 163 the RSAES-OAEP algorithm. When using a Triple-DES content-encryption 164 key, implementations MUST adjust the parity bits for each DES key 165 comprising the Triple-DES key prior to RSAES-OAEP encryption. 167 3 RSAES-OAEP Algorithm Identifiers and Parameters 169 The RSAES-OAEP key transport algorithm is the RSA encryption scheme 170 defined in RFC 2347 [PKCS#1v2.0], where the message to be encrypted 171 is the content-encryption key. The algorithm identifier for RSAES- 172 OAEP is: 174 id-RSAES-OAEP OBJECT IDENTIFIER ::= { 175 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } 177 The AlgorithmIdentifier parameters field must be present, and the 178 parameters field must contain RSAES-OAEP-params. RSAES-OAEP-params 179 have the following syntax: 181 RSAES-OAEP-params ::= SEQUENCE { 182 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 183 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 184 pSourceFunc [2] AlgorithmIdentifier DEFAULT pSpecifiedEmptyIdentifier } 186 sha1Identifier ::= AlgorithmIdentifier { 187 id-sha1, NULL } 189 mgf1SHA1Identifier ::= AlgorithmIdentifier { 190 id-mgf1, sha1Identifier } 192 pSpecifiedEmptyIdentifier ::= AlgorithmIdentifier { 193 id-pSpecified, OCTET STRING SIZE (0) } 195 id-sha1 OBJECT IDENTIFIER ::= { 196 iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } 198 id-mgf1 OBJECT IDENTIFIER ::= { 199 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 8 } 201 id-pSpecified OBJECT IDENTIFIER ::= { 202 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 9 } 204 The fields of type RSAES-OAEP-params have the following meanings: 206 hashFunc identifies the one-way hash function. Implementations 207 MUST support SHA-1 [SHA1]. The SHA-1 algorithm identifier is 208 comprised of the id-sha1 object identifier and a parameter of 209 NULL. 211 maskGenFunc identifies the mask generation function. 212 Implementations MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a 213 one-way hash function, and it is identified in the parameter field 214 of the algorithm identifier. Implementations MUST support SHA-1 215 [SHA1]. The MFG1 algorithm identifier is comprised of the id-mgf1 216 object identifier and a parameter of the SHA-1 algorithm 217 identifier. Again, the SHA-1 algorithm identifier is comprised of 218 the id-sha1 object identifier and a parameter of NULL. 220 pSourceFunc identifies the source (and possibly the value) of the 221 encoding parameters, commonly called P. Implementations MUST 222 represent P by an algorithm identifier, id-pSpecified, indicating 223 that P is explicitly provided as an OCTET STRING in the 224 parameters. The default value for P is an empty string. In this 225 case, pHash in EME-OAEP contains the hash of a zero length string. 227 4 SMIMECapabilities Attribute Conventions 229 RFC 2633, Section 2.5.2 defines the SMIMECapabilities signed 230 attribute (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be 231 used to specify a partial list of algorithms that the software 232 announcing the SMIMECapabilities can support. When constructing a 233 signedData object, compliant software MAY include the 234 SMIMECapabilities signed attribute announcing that it supports the 235 RSAES-OAEP algorithm. 237 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 238 id-RSAES-OAEP object identifier in the capabilityID field and MUST 239 include a RSAES-OAEP-Default-Identifier SEQUENCE in the parameters 240 field. 242 RSAES-OAEP-Default-Identifier ::= AlgorithmIdentifier { 243 id-RSAES-OAEP, { 244 sha1Identifier, mgf1SHA1Identifier, pSpecifiedEmptyIdentifier } } 246 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST be DER- 247 encoded as follows: {{{TBD}}}. 249 References 251 CMS Housley, R. Cryptographic Message Syntax. RFC 2630. 252 June 1999. 254 MUSTSHOULD Bradner, S. Key Words for Use in RFCs to Indicate 255 Requirement Levels. BCP 14, RFC 2119. March 1997. 257 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 258 RFC 2313. March 1998. 260 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 261 RFC 2347. October 1998. 263 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 264 X.509 Public Key Infrastructure: Certificate and CRL 265 Profile. RFC 2459. January 1999. 267 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 268 Recommendations for Security. RFC 1750. December 1994. 270 SHA1 National Institute of Standards and Technology. 271 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 273 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 274 Syntax Notation One (ASN.1). 1988. 276 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 277 Rules for Abstract Syntax Notation One (ASN.1). 1988. 279 X.509-88 CCITT. Recommendation X.509: The Directory - Authentication 280 Framework. 1988. 282 Security Considerations 284 Implementations must protect the RSA private key and the content- 285 encryption key. Compromise of the RSA private key may result in the 286 disclosure of all messages protected with that key. Compromise of 287 the content-encryption key may result in disclosure of the associated 288 encrypted content. 290 Implementations must protect the key management private key and the 291 message-authentication key. Compromise of the key management private 292 key permits masquerade of authenticated data. Compromise of the 293 message-authentication key may result in undetectable modification of 294 the authenticated content. 296 The generation of RSA public/private key pairs relies on a random 297 numbers. The use of inadequate pseudo-random number generators 298 (PRNGs) to generate cryptographic keys can result in little or no 299 security. An attacker may find it much easier to reproduce the PRNG 300 environment that produced the keys, searching the resulting small set 301 of possibilities, rather than brute force searching the whole key 302 space. The generation of quality random numbers is difficult. RFC 303 1750 [RANDOM] offers important guidance in this area. 305 Acknowledgments 307 This document is the result of contributions from many professionals. 308 I appreciate the hard work of all members of the IETF S/MIME Working 309 Group. I wish to extend a special thanks to Burt Kaliski. 311 Author Address 313 Russell Housley 314 SPYRUS 315 381 Elden Street 316 Suite 1120 317 Herndon, VA 20170 318 USA 320 housley@spyrus.com 322 Full Copyright Statement 324 Copyright (C) The Internet Society (2000). All Rights Reserved. 326 This document and translations of it may be copied and furnished to 327 others, and derivative works that comment on or otherwise explain it 328 or assist in its implementation may be prepared, copied, published 329 and distributed, in whole or in part, without restriction of any 330 kind, provided that the above copyright notice and this paragraph are 331 included on all such copies and derivative works. In addition, the 332 ASN.1 module presented in Appendix A may be used in whole or in part 333 without inclusion of the copyright notice. However, this document 334 itself may not be modified in any way, such as by removing the 335 copyright notice or references to the Internet Society or other 336 Internet organizations, except as needed for the purpose of 337 developing Internet standards in which case the procedures for 338 copyrights defined in the Internet Standards process shall be 339 followed, or as required to translate it into languages other than 340 English. 342 The limited permissions granted above are perpetual and will not be 343 revoked by the Internet Society or its successors or assigns. This 344 document and the information contained herein is provided on an "AS 345 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 346 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 347 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 348 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 349 OR FITNESS FOR A PARTICULAR PURPOSE.