idnits 2.17.1 draft-ietf-smime-cmsalg-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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 4 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: '...tions of the CMS MAY support these alg...' RFC 2119 keyword, line 94: '...tions of the CMS MAY support other alg...' RFC 2119 keyword, line 105: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 106: '... SHOULD NOT, RECOMMENDED, and MAY ar...' RFC 2119 keyword, line 134: '... syntax the OPTIONAL associated with...' (66 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 (September 2001) is 8252 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 90, but not defined == Missing Reference: 'STDWORDS' is mentioned on line 108, but not defined == Missing Reference: 'SHA1' is mentioned on line 126, but not defined == Missing Reference: 'MD5' is mentioned on line 152, but not defined == Missing Reference: 'DSS' is mentioned on line 951, but not defined == Missing Reference: 'WRAP' is mentioned on line 967, but not defined == Missing Reference: 'RC2' is mentioned on line 970, but not defined == Missing Reference: 'CERTALGS' is mentioned on line 384, but not defined == Missing Reference: 'MMA' is mentioned on line 1017, but not defined == Missing Reference: '3DES' is mentioned on line 969, but not defined == Missing Reference: 'DES' is mentioned on line 631, but not defined == Missing Reference: 'HMAC' is mentioned on line 684, but not defined == Missing Reference: 'RANDOM' is mentioned on line 950, but not defined == Unused Reference: 'PROFILE' is defined on line 933, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 971, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PROFILE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 5 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 September 2001 6 Cryptographic Message Syntax (CMS) Algorithms 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 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 This document describes several cryptographic algorithms for use with 38 the Cryptographic Message Syntax (CMS) [CMS]. CMS is used to 39 digitally sign, digest, authenticate, or encrypt arbitrary messages. 41 This document obsoletes section 12 of RFC 2630. [CMS] obsoletes the 42 rest of RFC 2630. Separation of the protocol and algorithm 43 specifications allows each one to be updated without impacting the 44 other. However, the conventions for using additional algorithms with 45 the CMS are likely to be specified in separate documents. 47 This draft is being discussed on the "ietf-smime" mailing list. To 48 join the list, send a message to with 49 the single word "subscribe" in the body of the message. Also, there 50 is a Web site for the mailing list at . 53 Table of Contents 55 Status of this Memo .............................................. 1 56 Abstract ......................................................... 1 57 Table of Contents ................................................ 2 58 1 Introduction ................................................. 3 59 2 Message Digest Algorithms .................................... 3 60 2.1 SHA-1 ................................................. 3 61 2.2 MD5 ................................................... 4 62 3 Signature Algorithms ......................................... 4 63 3.1 DSA ................................................... 4 64 3.2 RSA ................................................... 5 65 4 Key Management Algorithms .................................... 7 66 4.1 Key Agreement Algorithms .............................. 7 67 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ........ 7 68 4.1.2 X9.42 Static-Static Diffie-Hellman ........... 9 69 4.2 Key Transport Algorithms .............................. 10 70 4.2.1 RSA (PKCS #1 v1.5) ........................... 10 71 4.3 Symmetric Key-Encryption Key Algorithms ............... 11 72 4.3.1 Triple-DES Key Wrap .......................... 11 73 4.3.2 RC2 Key Wrap ................................. 12 74 4.4 Key Derivation Algorithms ............................. 13 75 4.4.1 PBKDF2 ....................................... 13 76 5 Content Encryption Algorithms ................................ 14 77 5.1 Triple-DES CBC ........................................ 14 78 5.2 RC2 CBC ............................................... 14 79 6 Message Authentication Code (MAC) Algorithms ................. 15 80 6.1 HMAC with SHA-1 ....................................... 15 81 Appendix A: ASN.1 Module ........................................ 16 82 References ....................................................... 19 83 Security Considerations .......................................... 20 84 Acknowledgments .................................................. 23 85 Author's Address ................................................. 23 86 Full Copyright Statement ......................................... 23 88 1 Introduction 90 The Cryptographic Message Syntax (CMS) [CMS] is used to digitally 91 sign, digest, authenticate, or encrypt arbitrary messages. This 92 companion specification lists the common cryptographic algorithms. 93 Implementations of the CMS MAY support these algorithms; 94 implementations of the CMS MAY support other algorithms as well. 96 The CMS values are generated using ASN.1 [X.208-88], using BER- 97 encoding [X.209-88]. Algorithm identifiers (which include ASN.1 98 object identifiers) identify cryptographic algorithms, and some 99 algorithms require additional parameters. When needed, parameters 100 are specified with an ASN.1 structure. The algorithm identifier for 101 each algorithm is specified, and, when needed, the parameter 102 structure is specified. The fields in the CMS employed by each 103 algorithm are identified. 105 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 106 SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described 107 by Scott Bradner in [STDWORDS]. 109 2 Message Digest Algorithms 111 This section specifies the conventions employed by CMS 112 implementations that support SHA-1 or MD5. 114 Digest algorithm identifiers are located in the SignedData 115 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 116 DigestedData digestAlgorithm field, and the AuthenticatedData 117 digestAlgorithm field. 119 Digest values are located in the DigestedData digest field and the 120 Message Digest authenticated attribute. In addition, digest values 121 are input to signature algorithms. 123 2.1 SHA-1 125 The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 126 [SHA1]. The algorithm identifier for SHA-1 is: 128 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 129 oiw(14) secsig(3) algorithm(2) 26 } 131 There are two possible encodings for the SHA-1 AlgorithmIdentifier 132 parameters field. The two alternatives arise from the fact that when 133 the 1988 syntax for AlgorithmIdentifier was translated into the 1997 134 syntax the OPTIONAL associated with the AlgorithmIdentifier 135 parameters got lost. Later the OPTIONAL was recovered via a defect 136 report, but by then many people thought that algorithm parameters 137 were mandatory. Because of this history some implementations encode 138 parameters as a NULL element and others omit them entirely. The 139 correct encoding is to omit the parameters field; however, 140 implementations MUST also handle a SHA-1 AlgorithmIdentifier 141 parameters field which contains a NULL. 143 The AlgorithmIdentifier parameters field is OPTIONAL. If present, 144 the parameters field MUST contain a NULL. Implementations MUST 145 accept SHA-1 AlgorithmIdentifiers with absent parameters. 146 Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL 147 parameters. Implementations SHOULD generate SHA-1 148 AlgorithmIdentifiers with absent parameters. 150 2.2 MD5 152 The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm 153 identifier for MD5 is: 155 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 156 rsadsi(113549) digestAlgorithm(2) 5 } 158 The AlgorithmIdentifier parameters field MUST be present, and the 159 parameters field MUST contain NULL. Implementations MAY accept the 160 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 161 parameters. 163 3 Signature Algorithms 165 This section specifies the conventions employed by CMS 166 implementations that support DSA or RSA (PKCS #1 v1.5). 168 Signature algorithm identifiers are located in the SignerInfo 169 signatureAlgorithm field of SignedData. Also, signature algorithm 170 identifiers are located in the SignerInfo signatureAlgorithm field of 171 countersignature attributes. 173 Signature values are located in the SignerInfo signature field of 174 SignedData. Also, signature values are located in the SignerInfo 175 signature field of countersignature attributes. 177 3.1 DSA 179 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA 180 MUST be used with the SHA-1 message digest algorithm. 182 The algorithm identifier for DSA subject public keys in certificates 183 is: 185 id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) 186 us(840) x9-57 (10040) x9cm(4) 1 } 188 DSA signature validation requires three parameters, commonly called 189 p, q, and g. When the id-dsa algorithm identifier is used, 190 AlgorithmIdentifier parameters field is optional. If present, the 191 AlgorithmIdentifier parameters field MUST contain the three DSA 192 parameter values encoded using the Dss-Parms type. If absent, the 193 subject DSA public key uses the same DSA parameters as the 194 certificate issuer. 196 Dss-Parms ::= SEQUENCE { 197 p INTEGER, 198 q INTEGER, 199 g INTEGER } 201 When the id-dsa algorithm identifier is used, the DSA public key, 202 commonly called Y, MUST be encoded as an INTEGER. The output of this 203 encoding is carried in the certificate subject public key. 205 Dss-Pub-Key ::= INTEGER -- Y 207 The algorithm identifier for DSA with SHA-1 signature values is: 209 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 210 us(840) x9-57 (10040) x9cm(4) 3 } 212 When the id-dsa-with-sha1 algorithm identifier is used, 213 AlgorithmIdentifier parameters field MUST be absent. 215 When signing, the DSA algorithm generates two values, commonly called 216 r and s. To transfer these two values as one signature, they MUST be 217 encoded using the Dss-Sig-Value type: 219 Dss-Sig-Value ::= SEQUENCE { 220 r INTEGER, 221 s INTEGER } 223 3.2 RSA 225 The RSA (PKCS #1 v1.5) signature algorithm is defined in RFC 2437 226 [NEWPKCS#1]. RFC 2437 specifies the use of the RSA signature 227 algorithm with the SHA-1 and MD5 message digest algorithms. 229 The algorithm identifier for RSA subject public keys in certificates 230 is: 232 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 233 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 235 When the rsaEncryption algorithm identifier is used, 236 AlgorithmIdentifier parameters field MUST contain NULL. 238 When the rsaEncryption algorithm identifier is used, the RSA public 239 key, which is composed of a modulus and a public exponent, MUST be 240 encoded using the RSAPublicKey type. The output of this encoding is 241 carried in the certificate subject public key. 243 RSAPublicKey ::= SEQUENCE { 244 modulus INTEGER, -- n 245 publicExponent INTEGER } -- e 247 CMS implementations that include the RSA (PKCS #1 v1.5) signature 248 algorithm MUST also implement the SHA-1 message digest algorithm. 249 Such implementations SHOULD also support MD5 message digest 250 algorithm. 252 The rsaEncryption algorithm identifier is used to identify RSA (PKCS 253 #1 v1.5) signature values regardless of the message digest algorithm 254 employed. CMS implementations that include the RSA (PKCS #1 v1.5) 255 signature algorithm MUST support the rsaEncryption signature value 256 algorithm identifier, and CMS implementations MAY support RSA (PKCS 257 #1 v1.5) signature value algorithm identifiers that specify both the 258 RSA (PKCS #1 v1.5) signature algorithm and the message digest 259 algorithm. 261 The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature 262 values is: 264 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 265 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 267 The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature 268 values is: 270 md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 271 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 273 When the rsaEncryption, sha1WithRSAEncryption, or 274 md5WithRSAEncryption signature value algorithm identifiers are used, 275 the AlgorithmIdentifier parameters field MUST be NULL. 277 When signing, the RSA algorithm generates a single value, and that 278 value is used directly as the signature value. 280 4 Key Management Algorithms 282 CMS accommodates the following general key management techniques: key 283 agreement, key transport, previously distributed symmetric key- 284 encryption keys, and passwords. 286 4.1 Key Agreement Algorithms 288 This section specifies the conventions employed by CMS 289 implementations that support key agreement using X9.42 Ephemeral- 290 Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie- 291 Hellman (X9.42 S-S D-H). 293 When a key agreement algorithm is used, a key-encryption algorithm is 294 also needed. Therefore, when key agreement is supported, a key- 295 encryption algorithm MUST be provided for each content-encryption 296 algorithm. The key wrap algorithms for Triple-DES and RC2 are 297 described in RFC [WRAP]. 299 For key agreement of RC2 key-encryption keys, 128 bits MUST be 300 generated as input to the key expansion process used to compute the 301 RC2 effective key [RC2]. 303 Key agreement algorithm identifiers are located in the EnvelopedData 304 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 305 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 306 keyEncryptionAlgorithm fields. 308 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 309 parameters within the EnvelopedData RecipientInfos 310 KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData 311 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 313 Wrapped content-encryption keys are located in the EnvelopedData 314 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 315 encryptedKey field. Wrapped message-authentication keys are located 316 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 317 RecipientEncryptedKeys encryptedKey field. 319 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman 321 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 322 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the 323 EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used as 324 follows: 326 version MUST be 3. 328 originator MUST be the originatorKey alternative. The 329 originatorKey algorithm field MUST contain the dh-public-number 330 object identifier with absent parameters. The originatorKey 331 publicKey field MUST contain the sender's ephemeral public key. 332 The dh-public-number object identifier is: 334 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 335 us(840) ansi-x942(10046) number-type(2) 1 } 337 ukm may be present or absent. CMS implementations MUST support 338 ukm being absent, and CMS implementations SHOULD support ukm being 339 present. When present, the ukm is used to ensure that a different 340 key-encryption key is generated when the ephemeral private key 341 might be used more than once. 343 keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm 344 identifier. The algorithm identifier parameter field for id-alg- 345 ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The 346 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 347 to encrypt the content-encryption key with the pairwise key- 348 encryption key generated using the X9.42 Ephemeral-Static Diffie- 349 Hellman key agreement algorithm. Triple-DES and RC2 key wrap 350 algorithms are described in RFC [WRAP]. The id-alg-ESDH 351 algorithm identifier and parameter syntax is: 353 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 354 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 355 alg(3) 5 } 357 KeyWrapAlgorithm ::= AlgorithmIdentifier 359 recipientEncryptedKeys contains an identifier and an encrypted key 360 for each recipient. The RecipientEncryptedKey 361 KeyAgreeRecipientIdentifier MUST contain either the 362 issuerAndSerialNumber identifying the recipient's certificate or 363 the RecipientKeyIdentifier containing the subject key identifier 364 from the recipient's certificate. In both cases, the recipient's 365 certificate contains the recipient's static public key. 366 RecipientEncryptedKey EncryptedKey MUST contain the content- 367 encryption key encrypted with the X9.42 Ephemeral-Static Diffie- 368 Hellman generated pairwise key-encryption key using the algorithm 369 specified by the KeyWrapAlgorithm. 371 4.1.2 X9.42 Static-Static Diffie-Hellman 373 Static-Static Diffie-Hellman key agreement is defined in RFC 2631 374 [DH-X9.42]. When using Static-Static Diffie-Hellman, the 375 EnvelopedData RecipientInfos KeyAgreeRecipientInfo and 376 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are 377 used as follows: 379 version MUST be 3. 381 originator MUST be either the issuerAndSerialNumber or 382 subjectKeyIdentifier alternative. In both cases, the originator's 383 certificate contains the sender's static public key. RFC 384 [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and 385 values that are included in the originator's certificate. The 386 originator's certificate subject public key information field MUST 387 contain the dh-public-number object identifier: 389 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 390 us(840) ansi-x942(10046) number-type(2) 1 } 392 ukm MUST be present. The ukm ensures that a different key- 393 encryption key is generated for each message between the same 394 sender and recipient. 396 keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm 397 identifier. The algorithm identifier parameter field for id-alg- 398 SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The 399 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 400 to encrypt the content-encryption key with the pairwise key- 401 encryption key generated using the X9.42 Static-Static Diffie- 402 Hellman key agreement algorithm. Triple-DES and RC2 key wrap 403 algorithms are described in RFC [WRAP]. The id-alg-SSDH 404 algorithm identifier and parameter syntax is: 406 id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 407 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 408 alg(3) 10 } 410 KeyWrapAlgorithm ::= AlgorithmIdentifier 412 recipientEncryptedKeys contains an identifier and an encrypted key 413 for each recipient. The RecipientEncryptedKey 414 KeyAgreeRecipientIdentifier MUST contain either the 415 issuerAndSerialNumber identifying the recipient's certificate or 416 the RecipientKeyIdentifier containing the subject key identifier 417 from the recipient's certificate. In both cases, the recipient's 418 certificate contains the recipient's static public key. 420 RecipientEncryptedKey EncryptedKey MUST contain the content- 421 encryption key encrypted with the X9.42 Static-Static Diffie- 422 Hellman generated pairwise key-encryption key using the algorithm 423 specified by the KeyWrapAlgortihm. 425 4.2 Key Transport Algorithms 427 This section specifies the conventions employed by CMS 428 implementations that support key transport using RSA (PKCS #1 v1.5). 430 Key transport algorithm identifiers are located in the EnvelopedData 431 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 433 Key transport encrypted content-encryption keys are located in the 434 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 435 field. 437 4.2.1 RSA (PKCS #1 v1.5) 439 The RSA key transport algorithm is the RSA encryption scheme defined 440 in RFC 2313 [PKCS#1], block type is 02, where the message to be 441 encrypted is the content-encryption key. The algorithm identifier 442 for RSA (PKCS #1 v1.5) is: 444 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 445 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 447 The AlgorithmIdentifier parameters field MUST be present, and the 448 parameters field MUST contain NULL. 450 When using a Triple-DES content-encryption key, CMS implementations 451 MUST adjust the parity bits for each DES key comprising the Triple- 452 DES key prior to RSA encryption. 454 The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 455 [PKCS#1], to provide confidentiality has a known vulnerability. The 456 vulnerability is primarily relevant to usage in interactive 457 applications rather than to store-and-forward environments. Further 458 information and proposed countermeasures are discussed in the 459 Security Considerations section of this document and RFC [MMA]. 461 Note that the same RSA encryption scheme is also defined in RFC 2437 462 [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called 463 RSAES-PKCS1-v1_5. 465 4.3 Symmetric Key-Encryption Key Algorithms 467 This section specifies the conventions employed by CMS 468 implementations that support symmetric key-encryption key management 469 using Triple-DES or RC2 key-encryption keys. When RC2 is supported, 470 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST 471 be used with the RC2ParameterVersion parameter set to 58. A CMS 472 implementation MAY support mixed key-encryption and content- 473 encryption algorithms. For example, a 40-bit RC2 content-encryption 474 key MAY be wrapped with 168-bit Triple-DES key-encryption key or with 475 a 128-bit RC2 key-encryption key. 477 Key wrap algorithm identifiers are located in the EnvelopedData 478 RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and 479 AuthenticatedData RecipientInfos KEKRecipientInfo 480 keyEncryptionAlgorithm fields. 482 Wrapped content-encryption keys are located in the EnvelopedData 483 RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- 484 authentication keys are located in the AuthenticatedData 485 RecipientInfos KEKRecipientInfo encryptedKey field. 487 The output of a key agreement algorithm is a key-encryption key, and 488 this key-encryption key is used to encrypt the content-encryption 489 key. To support key agreement, key wrap algorithm identifiers are 490 located in the KeyWrapAlgorithm parameter of the EnvelopedData 491 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 492 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 493 keyEncryptionAlgorithm fields. However, only key agreement 494 algorithms that inherently provide authentication ought to be used 495 with AuthenticatedData. Wrapped content-encryption keys are located 496 in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo 497 RecipientEncryptedKeys encryptedKey field, wrapped message- 498 authentication keys are located in the AuthenticatedData 499 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 500 encryptedKey field. 502 4.3.1 Triple-DES Key Wrap 504 A CMS implementation MAY support mixed key-encryption and content- 505 encryption algorithms. For example, a 128-bit RC2 content-encryption 506 key MAY be wrapped with 168-bit Triple-DES key-encryption key. 508 Triple-DES key encryption has the algorithm identifier: 510 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 511 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 513 The AlgorithmIdentifier parameter field MUST be NULL. 515 The key wrap algorithm used to encrypt a Triple-DES content- 516 encryption key with a Triple-DES key-encryption key is specified in 517 section 3.1 of RFC [WRAP]. The corresponding key unwrap 518 algorithm is specified in section 3.2 of RFC [WRAP]. 520 Out-of-band distribution of the Triple-DES key-encryption key used to 521 encrypt the Triple-DES content-encryption key is beyond of the scope 522 of this document. 524 4.3.2 RC2 Key Wrap 526 A CMS implementation MAY support mixed key-encryption and content- 527 encryption algorithms. For example, a 128-bit RC2 content-encryption 528 key MAY be wrapped with 168-bit Triple-DES key-encryption key. 529 Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with 530 128-bit RC2 key-encryption key. 532 RC2 key encryption has the algorithm identifier: 534 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 535 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 537 The AlgorithmIdentifier parameter field MUST be RC2wrapParameter: 539 RC2wrapParameter ::= RC2ParameterVersion 541 RC2ParameterVersion ::= INTEGER 543 The RC2 effective-key-bits (key size) greater than 32 and less than 544 256 is encoded in the RC2ParameterVersion. For the effective-key- 545 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 546 and 58 respectively. These values are not simply the RC2 key length. 547 Note that the value 160 must be encoded as two octets (00 A0), 548 because the one octet (A0) encoding represents a negative number. 550 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST 551 be used with the RC2ParameterVersion parameter set to 58. 553 The key wrap algorithm used to encrypt a RC2 content-encryption key 554 with a RC2 key-encryption key is specified in section 4.1 of RFC 555 [WRAP]. The corresponding key unwrap algorithm is specified 556 4.2 of RFC [WRAP]. 558 Out-of-band distribution of the RC2 key-encryption key used to 559 encrypt the RC2 content-encryption key is beyond of the scope of this 560 document. 562 4.4 Key Derivation Algorithms 564 This section specifies the conventions employed by CMS 565 implementations that support password-based key management using 566 PBKDF2. 568 Key derivation algorithms are used to convert a password into a key- 569 encryption key as part of the password-based key management 570 technique. 572 Key derivation algorithm identifiers are located in the EnvelopedData 573 RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and 574 AuthenticatedData RecipientInfos PasswordRecipientInfo 575 keyDerivationAlgorithm fields. 577 The key-encryption key that is derived from the password is used to 578 encrypt the content-encryption key. 580 The content-encryption keys encrypted with password-derived key- 581 encryption keys are located in the EnvelopedData RecipientInfos 582 PasswordRecipientInfo encryptedKey field. The message-authentication 583 keys encrypted with password-derived key-encryption keys are located 584 in the AuthenticatedData RecipientInfos PasswordRecipientInfo 585 encryptedKey field. 587 4.4.1 PBKDF2 589 The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5]. 590 The KeyDerivationAlgorithmIdentifer identifies the key-derivation 591 algorithm, and any associated parameters, used to derive the key- 592 encryption key from the user-supplied password. The algorithm 593 identifier for the PBKDF2 key derivation algorithm is: 595 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 596 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 598 The AlgorithmIdentifier parameter field MUST be PBKDF2-params: 600 PBKDF2-params ::= SEQUENCE { 601 salt CHOICE { 602 specified OCTET STRING, 603 otherSource AlgorithmIdentifier }, 604 iterationCount INTEGER (1..MAX), 605 keyLength INTEGER (1..MAX) OPTIONAL, 606 prf AlgorithmIdentifier 607 DEFAULT { algorithm hMAC-SHA1, parameters NULL } } 609 Within the PBKDF2-params, the salt MUST use the specified OCTET 610 STRING. 612 5 Content Encryption Algorithms 614 This section specifies the conventions employed by CMS 615 implementations that support content encryption using Three-Key 616 Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC 617 mode. 619 Content encryption algorithms identifiers are located in the 620 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 621 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 623 Content encryption algorithms are used to encipher the content 624 located in the EnvelopedData EncryptedContentInfo encryptedContent 625 field and the EncryptedData EncryptedContentInfo encryptedContent 626 field. 628 5.1 Triple-DES CBC 630 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 631 Triple-DES is composed from three sequential DES [DES] operations: 632 encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different 633 key for each DES operation. Two-Key Triple-DES uses one key for the 634 two encrypt operations and different key for the decrypt operation. 635 The same algorithm identifiers are used for Three-Key Triple-DES and 636 Two-Key Triple-DES. The algorithm identifier for Triple-DES in 637 Cipher Block Chaining (CBC) mode is: 639 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 640 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 642 The AlgorithmIdentifier parameters field MUST be present, and the 643 parameters field must contain a CBCParameter: 645 CBCParameter ::= IV 647 IV ::= OCTET STRING -- exactly 8 octets 649 5.2 RC2 CBC 651 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 652 identifier for RC2 in CBC mode is: 654 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 655 rsadsi(113549) encryptionAlgorithm(3) 2 } 657 The AlgorithmIdentifier parameters field MUST be present, and the 658 parameters field MUST contain a RC2CBCParameter: 660 RC2CBCParameter ::= SEQUENCE { 661 rc2ParameterVersion INTEGER, 662 iv OCTET STRING } -- exactly 8 octets 664 The RC2 effective-key-bits (key size) greater than 32 and less than 665 256 is encoded in the rc2ParameterVersion. For the effective-key- 666 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 667 and 58 respectively. These values are not simply the RC2 key length. 668 Note that the value 160 must be encoded as two octets (00 A0), since 669 the one octet (A0) encoding represents a negative number. 671 6 Message Authentication Code Algorithms 673 This section specifies the conventions employed by CMS 674 implementations that support the HMAC with SHA-1 message 675 authentication code (MAC). 677 MAC algorithm identifiers are located in the AuthenticatedData 678 macAlgorithm field. 680 MAC values are located in the AuthenticatedData mac field. 682 6.1 HMAC with SHA-1 684 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 685 algorithm identifier for HMAC with SHA-1 is: 687 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 688 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 690 There are two possible encodings for the HMAC with SHA-1 691 AlgorithmIdentifier parameters field. The two alternatives arise 692 from the fact that when the 1988 syntax for AlgorithmIdentifier was 693 translated into the 1997 syntax the OPTIONAL associated with the 694 AlgorithmIdentifier parameters got lost. Later the OPTIONAL was 695 recovered via a defect report, but by then many people thought that 696 algorithm parameters were mandatory. Because of this history some 697 implementations encode parameters as a NULL element and others omit 698 them entirely. CMS implementations that support HMAC with SHA-1 MUST 699 handle both an AlgorithmIdentifier parameters field which contains a 700 NULL and an AlgorithmIdentifier with an absent parameters. 702 Appendix A: ASN.1 Module 704 CryptographicMessageSyntaxAlgorithms 705 { iso(1) member-body(2) us(840) rsadsi(113549) 706 pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) } 708 DEFINITIONS IMPLICIT TAGS ::= 709 BEGIN 711 -- EXPORTS All 712 -- The types and values defined in this module are exported for use in 713 -- the other ASN.1 modules. Other applications may use them for their 714 -- own purposes. 716 IMPORTS 717 -- Directory Authentication Framework (X.509-2000) 718 AlgorithmIdentifier 719 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 720 module(1) authenticationFramework(7) 4 } ; 722 -- Algorithm Identifiers 724 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 725 oiw(14) secsig(3) algorithm(2) 26 } 727 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 728 rsadsi(113549) digestAlgorithm(2) 5 } 730 id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 731 x9-57(10040) x9cm(4) 1 } 733 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 734 us(840) x9-57(10040) x9cm(4) 3 } 736 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 737 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 739 md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 740 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 742 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 743 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 745 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 746 us(840) ansi-x942(10046) number-type(2) 1 } 748 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 749 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 751 id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 752 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 } 754 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 755 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 757 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 758 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 760 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 761 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 763 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 764 rsadsi(113549) encryptionAlgorithm(3) 2 } 766 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 767 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 769 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 770 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 772 -- Public Key Types 774 Dss-Pub-Key ::= INTEGER -- Y 776 RSAPublicKey ::= SEQUENCE { 777 modulus INTEGER, -- n 778 publicExponent INTEGER } -- e 780 DHPublicKey ::= INTEGER -- y = g^x mod p 782 -- Signature Value Types 784 Dss-Sig-Value ::= SEQUENCE { 785 r INTEGER, 786 s INTEGER } 788 -- Algorithm Identifier Parameter Types 790 Dss-Parms ::= SEQUENCE { 791 p INTEGER, 792 q INTEGER, 793 g INTEGER } 795 DHDomainParameters ::= SEQUENCE { 796 p INTEGER, -- odd prime, p=jq +1 797 g INTEGER, -- generator, g 798 q INTEGER, -- factor of p-1 799 j INTEGER OPTIONAL, -- subgroup factor 800 validationParms ValidationParms OPTIONAL } 802 ValidationParms ::= SEQUENCE { 803 seed BIT STRING, 804 pgenCounter INTEGER } 806 KeyWrapAlgorithm ::= AlgorithmIdentifier 808 RC2wrapParameter ::= RC2ParameterVersion 810 RC2ParameterVersion ::= INTEGER 812 CBCParameter ::= IV 814 IV ::= OCTET STRING -- exactly 8 octets 816 RC2CBCParameter ::= SEQUENCE { 817 rc2ParameterVersion INTEGER, 818 iv OCTET STRING } -- exactly 8 octets 820 PBKDF2-params ::= SEQUENCE { 821 salt CHOICE { 822 specified OCTET STRING, 823 otherSource AlgorithmIdentifier }, 824 iterationCount INTEGER (1..MAX), 825 keyLength INTEGER (1..MAX) OPTIONAL, 826 prf AlgorithmIdentifier 827 DEFAULT { algorithm hMAC-SHA1, parameters NULL } } 829 END -- of CryptographicMessageSyntaxAlgorithms 831 References 833 3DES American National Standards Institute. ANSI X9.52-1998, 834 Triple Data Encryption Algorithm Modes of Operation. 1998. 836 CERTALGS Bassham, L., R. Housley, and W. Polk. Algorithms and 837 Identifiers for the Internet X.509 Public Key 838 Infrastructure Certificate and CRL Profile. RFC . 839 . {draft-ietf-pkix-ipki-pkalgs-03.txt} 841 CMS Housley, R. Cryptographic Message Syntax. RFC . 842 . {draft-ietf-smime-rfc2630bis-*.txt} 844 DES American National Standards Institute. ANSI X3.106, 845 "American National Standard for Information Systems - Data 846 Link Encryption". 1983. 848 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 849 RFC 2631. June 1999. 851 DSS National Institute of Standards and Technology. 852 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 854 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 855 RFC 2104. February 1997. 857 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 858 April 1992. 860 MMA Rescorla, E. Preventing the Million Message Attack on CMS. 861 RFC . . {draft-ietf-smime-pkcs1-*.txt} 863 MODES National Institute of Standards and Technology. 864 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 866 NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, 867 Version 2.0. RFC 2437. October 1998. 869 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 870 RFC 2313. March 1998. 872 PKCS#5 Kaliski, B. PKCS #5: Password-Based Cryptography 873 Specification, Version 2.0. RFC 2898. September 2000. 875 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 876 X.509 Public Key Infrastructure: Certificate and CRL 877 Profile. RFC . . 878 {draft-ietf-pkix-new-part1-*.txt} 880 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 881 Recommendations for Security. RFC 1750. December 1994. 883 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 884 RFC 2268. March 1998. 886 SHA1 National Institute of Standards and Technology. 887 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 889 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 890 Requirement Levels. RFC2119. March 1997. 892 WRAP Housley, R. Triple-DES and RC2 Key Wrapping. RFC . 893 . {draft-ietf-smime-key-wrap-*.txt} 895 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 896 Syntax Notation One (ASN.1). 1988. 898 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 899 Rules for Abstract Syntax Notation One (ASN.1). 1988. 901 Security Considerations 903 The CMS provides a method for digitally signing data, digesting data, 904 encrypting data, and authenticating data. This document identifies 905 the conventions for using several cryptographic algorithms for use 906 with the CMS. 908 Implementations must protect the signer's private key. Compromise of 909 the signer's private key permits masquerade. 911 Implementations must protect the key management private key, the key- 912 encryption key, and the content-encryption key. Compromise of the 913 key management private key or the key-encryption key may result in 914 the disclosure of all messages protected with that key. Similarly, 915 compromise of the content-encryption key may result in disclosure of 916 the associated encrypted content. 918 Implementations must protect the key management private key and the 919 message-authentication key. Compromise of the key management private 920 key permits masquerade of authenticated data. Similarly, compromise 921 of the message-authentication key may result in undetectable 922 modification of the authenticated content. 924 The key management technique employed to distribute message- 925 authentication keys must itself provide authentication, otherwise the 926 message content is delivered with integrity from an unknown source. 927 Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman 929 [DH-X9.42] provide the necessary data origin authentication. Static- 930 Static Diffie-Hellman [DH-X9.42] does provide the necessary data 931 origin authentication when both the originator and recipient public 932 keys are bound to appropriate identities in X.509 certificates 933 [PROFILE]. 935 When more than two parties share the same message-authentication key, 936 data origin authentication is not provided. Any party that knows the 937 message-authentication key can compute a valid MAC, therefore the 938 message could originate from any one of the parties. 940 Implementations must randomly generate content-encryption keys, 941 message-authentication keys, initialization vectors (IVs), one-time 942 values (such as the k value when generating a DSA signature), and 943 padding. Also, the generation of public/private key pairs relies on 944 a random numbers. The use of inadequate pseudo-random number 945 generators (PRNGs) to generate cryptographic such values can result 946 in little or no security. An attacker may find it much easier to 947 reproduce the PRNG environment that produced the keys, searching the 948 resulting small set of possibilities, rather than brute force 949 searching the whole key space. The generation of quality random 950 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 951 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 952 PRNG technique. 954 When using key agreement algorithms or previously distributed 955 symmetric key-encryption keys, a key-encryption key is used to 956 encrypt the content-encryption key. If the key-encryption and 957 content-encryption algorithms are different, the effective security 958 is determined by the weaker of the two algorithms. If, for example, 959 a message content is encrypted with 168-bit Triple-DES and the 960 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 961 then at most 40 bits of protection is provided. A trivial search to 962 determine the value of the 40-bit RC2 key can recover Triple-DES key, 963 and then the Triple-DES key can be used to decrypt the content. 964 Therefore, implementers must ensure that key-encryption algorithms 965 are as strong or stronger than content-encryption algorithms. 967 RFC [WRAP] specifies key wrap algorithms used to encrypt a 968 Triple-DES content-encryption key with a Triple-DES key-encryption 969 key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key- 970 encryption key [RC2]. The key wrap algorithms makes use of CBC mode 971 [MODES]. These key wrap algorithms have been reviewed for use with 972 Triple-DES and RC2. They have not been reviewed for use with other 973 cryptographic modes or other encryption algorithms. Therefore, if a 974 CMS implementation wishes to support ciphers in addition to Triple- 975 DES or RC2, then additional key wrap algorithms need to be defined to 976 support the additional ciphers. 978 Implementers should be aware that cryptographic algorithms become 979 weaker with time. As new cryptanalysis techniques are developed and 980 computing performance improves, the work factor to break a particular 981 cryptographic algorithm will reduce. Therefore, cryptographic 982 algorithm implementations should be modular allowing new algorithms 983 to be readily inserted. That is, implementers should be prepared to 984 regularly update the set of algorithms in their implementations. 986 Users of the CMS, particularly those employing the CMS to support 987 interactive applications, should be aware that RSA (PKCS #1 v1.5), as 988 specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen 989 ciphertext attacks when applied for encryption purposes. 990 Exploitation of this identified vulnerability, revealing the result 991 of a particular RSA decryption, requires access to an oracle which 992 will respond to a large number of ciphertexts (based on currently 993 available results, hundreds of thousands or more), which are 994 constructed adaptively in response to previously-received replies 995 providing information on the successes or failures of attempted 996 decryption operations. As a result, the attack appears significantly 997 less feasible to perpetrate for store-and-forward S/MIME environments 998 than for directly interactive protocols. Where the CMS constructs 999 are applied as an intermediate encryption layer within an interactive 1000 request-response communications environment, exploitation could be 1001 more feasible. 1003 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 1004 [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1 1005 Version 2.0 preserves support for the encryption padding format 1006 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 1007 alternative. To resolve the adaptive chosen ciphertext 1008 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 1009 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 1010 is used to provide confidentiality. Designers of protocols and 1011 systems employing CMS for interactive environments should either 1012 consider usage of OAEP, or should ensure that information which could 1013 reveal the success or failure of attempted PKCS #1 Version 1.5 1014 decryption operations is not provided. Support for OAEP will likely 1015 be added to a future version of the CMS algorithm specification. 1017 See RFC [MMA] for more information about thwarting the adaptive 1018 chosen ciphertext vulnerability in PKCS #1 Version 1.5 1019 implementations. 1021 Acknowledgments 1023 This document is the result of contributions from many professionals. 1024 I appreciate the hard work of all members of the IETF S/MIME Working 1025 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 1026 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 1027 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 1028 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 1029 Jim Schaad, and Dave Solo for their efforts and support. 1031 Author Address 1033 Russell Housley 1034 RSA Laboratories 1035 918 Spring Knoll Drive 1036 Herndon, VA 20170 1037 USA 1039 rhousley@rsasecurity.com 1041 Full Copyright Statement 1043 Copyright (C) The Internet Society (2001). All Rights Reserved. 1045 This document and translations of it may be copied and furnished to 1046 others, and derivative works that comment on or otherwise explain it 1047 or assist in its implementation may be prepared, copied, published 1048 and distributed, in whole or in part, without restriction of any 1049 kind, provided that the above copyright notice and this paragraph are 1050 included on all such copies and derivative works. In addition, the 1051 ASN.1 module presented in Appendix A may be used in whole or in part 1052 without inclusion of the copyright notice. However, this document 1053 itself may not be modified in any way, such as by removing the 1054 copyright notice or references to the Internet Society or other 1055 Internet organizations, except as needed for the purpose of 1056 developing Internet standards in which case the procedures for 1057 copyrights defined in the Internet Standards process shall be 1058 followed, or as required to translate it into languages other than 1059 English. 1061 The limited permissions granted above are perpetual and will not be 1062 revoked by the Internet Society or its successors or assigns. This 1063 document and the information contained herein is provided on an "AS 1064 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1065 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1066 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1067 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1068 OR FITNESS FOR A PARTICULAR PURPOSE.