idnits 2.17.1 draft-ietf-smime-cmsalg-04.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 63 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...' (64 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? 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 942, but not defined == Missing Reference: 'WRAP' is mentioned on line 958, but not defined == Missing Reference: 'RC2' is mentioned on line 961, but not defined == Missing Reference: 'CERTALGS' is mentioned on line 375, but not defined == Missing Reference: 'MMA' is mentioned on line 1008, but not defined == Missing Reference: '3DES' is mentioned on line 960, but not defined == Missing Reference: 'DES' is mentioned on line 621, but not defined == Missing Reference: 'HMAC' is mentioned on line 675, but not defined == Missing Reference: 'RANDOM' is mentioned on line 941, but not defined == Unused Reference: 'PROFILE' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'MODES' is defined on line 962, 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 (==), 4 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 .................................... 6 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 ........... 8 69 4.2 Key Transport Algorithms .............................. 9 70 4.2.1 RSA (PKCS #1 v1.5) ........................... 10 71 4.3 Symmetric Key-Encryption Key Algorithms ............... 10 72 4.3.1 Triple-DES Key Wrap .......................... 11 73 4.3.2 RC2 Key Wrap ................................. 12 74 4.4 Key Derivation Algorithms ............................. 12 75 4.4.1 PBKDF2 ....................................... 13 76 5 Content Encryption Algorithms ................................ 13 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 absent 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 signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC 226 2437 specifies the use of the RSA signature algorithm with the SHA-1 227 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 algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature 253 values is: 255 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 256 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 258 The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature 259 values is: 261 md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 262 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 264 When either the sha1WithRSAEncryption algorithm identifier or the 265 md5WithRSAEncryption algorithm identifier is used, the 266 AlgorithmIdentifier parameters field MUST be NULL. 268 When signing, the RSA algorithm generates a single value, and that 269 value is used directly as the signature value. 271 4 Key Management Algorithms 273 CMS accommodates the following general key management techniques: key 274 agreement, key transport, previously distributed symmetric key- 275 encryption keys, and passwords. 277 4.1 Key Agreement Algorithms 279 This section specifies the conventions employed by CMS 280 implementations that support key agreement using X9.42 Ephemeral- 281 Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie- 282 Hellman (X9.42 S-S D-H). 284 When a key agreement algorithm is used, a key-encryption algorithm is 285 also needed. Therefore, when key agreement is supported, a key- 286 encryption algorithm MUST be provided for each content-encryption 287 algorithm. The key wrap algorithms for Triple-DES and RC2 are 288 described in RFC [WRAP]. 290 For key agreement of RC2 key-encryption keys, 128 bits MUST be 291 generated as input to the key expansion process used to compute the 292 RC2 effective key [RC2]. 294 Key agreement algorithm identifiers are located in the EnvelopedData 295 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 296 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 297 keyEncryptionAlgorithm fields. 299 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 300 parameters within the EnvelopedData RecipientInfos 301 KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData 302 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 304 Wrapped content-encryption keys are located in the EnvelopedData 305 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 306 encryptedKey field. Wrapped message-authentication keys are located 307 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 308 RecipientEncryptedKeys encryptedKey field. 310 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman 312 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 313 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the 314 EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used as 315 follows: 317 version MUST be 3. 319 originator MUST be the originatorKey alternative. The 320 originatorKey algorithm field MUST contain the dh-public-number 321 object identifier with absent parameters. The originatorKey 322 publicKey field MUST contain the sender's ephemeral public key. 323 The dh-public-number object identifier is: 325 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 326 us(840) ansi-x942(10046) number-type(2) 1 } 328 ukm may be present or absent. CMS implementations MUST support 329 ukm being absent, and CMS implementations SHOULD support ukm being 330 present. When present, the ukm is used to ensure that a different 331 key-encryption key is generated when the ephemeral private key 332 might be used more than once. 334 keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm 335 identifier. The algorithm identifier parameter field for id-alg- 336 ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The 337 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 338 to encrypt the content-encryption key with the pairwise key- 339 encryption key generated using the X9.42 Ephemeral-Static Diffie- 340 Hellman key agreement algorithm. Triple-DES and RC2 key wrap 341 algorithms are described in RFC [WRAP]. The id-alg-ESDH 342 algorithm identifier and parameter syntax is: 344 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 345 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 346 alg(3) 5 } 348 KeyWrapAlgorithm ::= AlgorithmIdentifier 350 recipientEncryptedKeys contains an identifier and an encrypted key 351 for each recipient. The RecipientEncryptedKey 352 KeyAgreeRecipientIdentifier MUST contain either the 353 issuerAndSerialNumber identifying the recipient's certificate or 354 the RecipientKeyIdentifier containing the subject key identifier 355 from the recipient's certificate. In both cases, the recipient's 356 certificate contains the recipient's static public key. 357 RecipientEncryptedKey EncryptedKey MUST contain the content- 358 encryption key encrypted with the X9.42 Ephemeral-Static Diffie- 359 Hellman generated pairwise key-encryption key using the algorithm 360 specified by the KeyWrapAlgortihm. 362 4.1.2 X9.42 Static-Static Diffie-Hellman 364 Static-Static Diffie-Hellman key agreement is defined in RFC 2631 365 [DH-X9.42]. When using Static-Static Diffie-Hellman, the 366 EnvelopedData RecipientInfos KeyAgreeRecipientInfo and 367 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are 368 used as follows: 370 version MUST be 3. 372 originator MUST be either the issuerAndSerialNumber or 373 subjectKeyIdentifier alternative. In both cases, the originator's 374 certificate contains the sender's static public key. RFC 375 [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and 376 values that are included in the originator's certificate. The 377 originator's certificate subject public key information field MUST 378 contain the dh-public-number object identifier: 380 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 381 us(840) ansi-x942(10046) number-type(2) 1 } 383 ukm MUST be present. The ukm ensures that a different key- 384 encryption key is generated for each message between the same 385 sender and recipient. 387 keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm 388 identifier. The algorithm identifier parameter field for id-alg- 389 SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The 390 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 391 to encrypt the content-encryption key with the pairwise key- 392 encryption key generated using the X9.42 Static-Static Diffie- 393 Hellman key agreement algorithm. Triple-DES and RC2 key wrap 394 algorithms are described in RFC [WRAP]. The id-alg-SSDH 395 algorithm identifier and parameter syntax is: 397 id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) 398 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 399 alg(3) 10 } 401 KeyWrapAlgorithm ::= AlgorithmIdentifier 403 recipientEncryptedKeys contains an identifier and an encrypted key 404 for each recipient. The RecipientEncryptedKey 405 KeyAgreeRecipientIdentifier MUST contain either the 406 issuerAndSerialNumber identifying the recipient's certificate or 407 the RecipientKeyIdentifier containing the subject key identifier 408 from the recipient's certificate. In both cases, the recipient's 409 certificate contains the recipient's static public key. 410 RecipientEncryptedKey EncryptedKey MUST contain the content- 411 encryption key encrypted with the X9.42 Static-Static Diffie- 412 Hellman generated pairwise key-encryption key using the algorithm 413 specified by the KeyWrapAlgortihm. 415 4.2 Key Transport Algorithms 417 This section specifies the conventions employed by CMS 418 implementations that support key transport using RSA (PKCS #1 v1.5). 420 Key transport algorithm identifiers are located in the EnvelopedData 421 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 423 Key transport encrypted content-encryption keys are located in the 424 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 425 field. 427 4.2.1 RSA (PKCS #1 v1.5) 429 The RSA key transport algorithm is the RSA encryption scheme defined 430 in RFC 2313 [PKCS#1], block type is 02, where the message to be 431 encrypted is the content-encryption key. The algorithm identifier 432 for RSA (PKCS #1 v1.5) is: 434 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 435 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 437 The AlgorithmIdentifier parameters field MUST be present, and the 438 parameters field MUST contain NULL. 440 When using a Triple-DES content-encryption key, CMS implementations 441 MUST adjust the parity bits for each DES key comprising the Triple- 442 DES key prior to RSA encryption. 444 The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 445 [PKCS#1], to provide confidentiality has a known vulnerability. The 446 vulnerability is primarily relevant to usage in interactive 447 applications rather than to store-and-forward environments. Further 448 information and proposed countermeasures are discussed in the 449 Security Considerations section of this document and RFC [MMA]. 451 Note that the same RSA encryption scheme is also defined in RFC 2437 452 [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called 453 RSAES-PKCS1-v1_5. 455 4.3 Symmetric Key-Encryption Key Algorithms 457 This section specifies the conventions employed by CMS 458 implementations that support symmetric key-encryption key management 459 using Triple-DES or RC2 key-encryption keys. When RC2 is supported, 460 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST 461 be used with the RC2ParameterVersion parameter set to 58. A CMS 462 implementation MAY support mixed key-encryption and content- 463 encryption algorithms. For example, a 40-bit RC2 content-encryption 464 key MAY be wrapped with 168-bit Triple-DES key-encryption key or with 465 a 128-bit RC2 key-encryption key. 467 Key wrap algorithm identifiers are located in the EnvelopedData 468 RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and 469 AuthenticatedData RecipientInfos KEKRecipientInfo 470 keyEncryptionAlgorithm fields. 472 Wrapped content-encryption keys are located in the EnvelopedData 473 RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- 474 authentication keys are located in the AuthenticatedData 475 RecipientInfos KEKRecipientInfo encryptedKey field. 477 The output of a key agreement algorithm is a key-encryption key, and 478 this key-encryption key is used to encrypt the content-encryption 479 key. To support key agreement, key wrap algorithm identifiers are 480 located in the KeyWrapAlgorithm parameter of the EnvelopedData 481 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 482 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 483 keyEncryptionAlgorithm fields. However, only key agreement 484 algorithms that inherently provide authentication ought to be used 485 with AuthenticatedData. Wrapped content-encryption keys are located 486 in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo 487 RecipientEncryptedKeys encryptedKey field, wrapped message- 488 authentication keys are located in the AuthenticatedData 489 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 490 encryptedKey field. 492 4.3.1 Triple-DES Key Wrap 494 A CMS implementation MAY support mixed key-encryption and content- 495 encryption algorithms. For example, a 128-bit RC2 content-encryption 496 key MAY be wrapped with 168-bit Triple-DES key-encryption key. 498 Triple-DES key encryption has the algorithm identifier: 500 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 501 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 503 The AlgorithmIdentifier parameter field MUST be NULL. 505 The key wrap algorithm used to encrypt a Triple-DES content- 506 encryption key with a Triple-DES key-encryption key is specified in 507 section 3.1 of RFC [WRAP]. The corresponding key unwrap 508 algorithm is specified in section 3.2 of RFC [WRAP]. 510 Out-of-band distribution of the Triple-DES key-encryption key used to 511 encrypt the Triple-DES content-encryption key is beyond of the scope 512 of this document. 514 4.3.2 RC2 Key Wrap 516 A CMS implementation MAY support mixed key-encryption and content- 517 encryption algorithms. For example, a 128-bit RC2 content-encryption 518 key MAY be wrapped with 168-bit Triple-DES key-encryption key. 519 Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with 520 128-bit RC2 key-encryption key. 522 RC2 key encryption has the algorithm identifier: 524 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 525 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 527 The AlgorithmIdentifier parameter field MUST be RC2wrapParameter: 529 RC2wrapParameter ::= RC2ParameterVersion 531 RC2ParameterVersion ::= INTEGER 533 The RC2 effective-key-bits (key size) greater than 32 and less than 534 256 is encoded in the RC2ParameterVersion. For the effective-key- 535 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 536 and 58 respectively. These values are not simply the RC2 key length. 537 Note that the value 160 must be encoded as two octets (00 A0), 538 because the one octet (A0) encoding represents a negative number. 540 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST 541 be used with the RC2ParameterVersion parameter set to 58. 543 The key wrap algorithm used to encrypt a RC2 content-encryption key 544 with a RC2 key-encryption key is specified in section 4.1 of RFC 545 [WRAP]. The corresponding key unwrap algorithm is specified 546 4.2 of RFC [WRAP]. 548 Out-of-band distribution of the RC2 key-encryption key used to 549 encrypt the RC2 content-encryption key is beyond of the scope of this 550 document. 552 4.4 Key Derivation Algorithms 554 This section specifies the conventions employed by CMS 555 implementations that support password-based key management using 556 PBKDF2. 558 Key derivation algorithms are used to convert a password into a key- 559 encryption key as part of the password-based key management 560 technique. 562 Key derivation algorithm identifiers are located in the EnvelopedData 563 RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and 564 AuthenticatedData RecipientInfos PasswordRecipientInfo 565 keyDerivationAlgorithm fields. 567 The key-encryption key that is derived from the password is used to 568 encrypt the content-encryption key. 570 The content-encryption keys encrypted with password-derived key- 571 encryption keys are located in the EnvelopedData RecipientInfos 572 PasswordRecipientInfo encryptedKey field. The message-authentication 573 keys encrypted with password-derived key-encryption keys are located 574 in the AuthenticatedData RecipientInfos PasswordRecipientInfo 575 encryptedKey field. 577 4.4.1 PBKDF2 579 The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5]. 580 The KeyDerivationAlgorithmIdentifer identifies the key-derivation 581 algorithm, and any associated parameters, used to derive the key- 582 encryption key from the user-supplied password. The algorithm 583 identifier for the PBKDF2 key derivation algorithm is: 585 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 586 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 588 The AlgorithmIdentifier parameter field MUST be PBKDF2-params: 590 PBKDF2-params ::= SEQUENCE { 591 salt CHOICE { 592 specified OCTET STRING, 593 otherSource AlgorithmIdentifier }, 594 iterationCount INTEGER (1..MAX), 595 keyLength INTEGER (1..MAX) OPTIONAL, 596 prf AlgorithmIdentifier 597 DEFAULT { algorithm hMAC-SHA1, parameters NULL } } 599 Within the PBKDF2-params, the salt MUST use the specified OCTET 600 STRING. 602 5 Content Encryption Algorithms 604 This section specifies the conventions employed by CMS 605 implementations that support content encryption using Three-Key 606 Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC 607 mode. 609 Content encryption algorithms identifiers are located in the 610 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 611 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 613 Content encryption algorithms are used to encipher the content 614 located in the EnvelopedData EncryptedContentInfo encryptedContent 615 field and the EncryptedData EncryptedContentInfo encryptedContent 616 field. 618 5.1 Triple-DES CBC 620 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 621 Triple-DES is composed from three sequential DES [DES] operations: 622 encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different 623 key for each DES operation. Two-Key Triple-DES uses one key for the 624 two encrypt operations and different key for the decrypt operation. 625 The same algorithm identifiers are used for Three-Key Triple-DES and 626 Two-Key Triple-DES. The algorithm identifier for Triple-DES in 627 Cipher Block Chaining (CBC) mode is: 629 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 630 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 632 The AlgorithmIdentifier parameters field MUST be present, and the 633 parameters field must contain a CBCParameter: 635 CBCParameter ::= IV 637 IV ::= OCTET STRING -- exactly 8 octets 639 5.2 RC2 CBC 641 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 642 identifier for RC2 in CBC mode is: 644 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 645 rsadsi(113549) encryptionAlgorithm(3) 2 } 647 The AlgorithmIdentifier parameters field MUST be present, and the 648 parameters field MUST contain a RC2CBCParameter: 650 RC2CBCParameter ::= SEQUENCE { 651 rc2ParameterVersion INTEGER, 652 iv OCTET STRING } -- exactly 8 octets 654 The RC2 effective-key-bits (key size) greater than 32 and less than 655 256 is encoded in the rc2ParameterVersion. For the effective-key- 656 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 657 and 58 respectively. These values are not simply the RC2 key length. 659 Note that the value 160 must be encoded as two octets (00 A0), since 660 the one octet (A0) encoding represents a negative number. 662 6 Message Authentication Code Algorithms 664 This section specifies the conventions employed by CMS 665 implementations that support the HMAC with SHA-1 message 666 authentication code (MAC). 668 MAC algorithm identifiers are located in the AuthenticatedData 669 macAlgorithm field. 671 MAC values are located in the AuthenticatedData mac field. 673 6.1 HMAC with SHA-1 675 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 676 algorithm identifier for HMAC with SHA-1 is: 678 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 679 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 681 There are two possible encodings for the HMAC with SHA-1 682 AlgorithmIdentifier parameters field. The two alternatives arise 683 from the fact that when the 1988 syntax for AlgorithmIdentifier was 684 translated into the 1997 syntax the OPTIONAL associated with the 685 AlgorithmIdentifier parameters got lost. Later the OPTIONAL was 686 recovered via a defect report, but by then many people thought that 687 algorithm parameters were mandatory. Because of this history some 688 implementations encode parameters as a NULL element and others omit 689 them entirely. CMS implementations that support HMAC with SHA-1 MUST 690 handle both an AlgorithmIdentifier parameters field which contains a 691 NULL and an AlgorithmIdentifier with an absent parameters. 693 Appendix A: ASN.1 Module 695 CryptographicMessageSyntaxAlgorithms 696 { iso(1) member-body(2) us(840) rsadsi(113549) 697 pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) } 699 DEFINITIONS IMPLICIT TAGS ::= 700 BEGIN 702 -- EXPORTS All 703 -- The types and values defined in this module are exported for use in 704 -- the other ASN.1 modules. Other applications may use them for their 705 -- own purposes. 707 IMPORTS 708 -- Directory Authentication Framework (X.509-2000) 709 AlgorithmIdentifier 710 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 711 module(1) authenticationFramework(7) 4 } ; 713 -- Algorithm Identifiers 715 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 716 oiw(14) secsig(3) algorithm(2) 26 } 718 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 719 rsadsi(113549) digestAlgorithm(2) 5 } 721 id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 722 x9-57(10040) x9cm(4) 1 } 724 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 725 us(840) x9-57(10040) x9cm(4) 3 } 727 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 728 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 730 md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 731 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 733 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 734 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 736 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 737 us(840) ansi-x942(10046) number-type(2) 1 } 739 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 740 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 742 id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 743 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 } 745 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 746 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 748 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 749 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 751 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 752 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 754 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 755 rsadsi(113549) encryptionAlgorithm(3) 2 } 757 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 758 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 760 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 761 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 763 -- Public Key Types 765 Dss-Pub-Key ::= INTEGER -- Y 767 RSAPublicKey ::= SEQUENCE { 768 modulus INTEGER, -- n 769 publicExponent INTEGER } -- e 771 DHPublicKey ::= INTEGER -- y = g^x mod p 773 -- Signature Value Types 775 Dss-Sig-Value ::= SEQUENCE { 776 r INTEGER, 777 s INTEGER } 779 -- Algorithm Identifier Parameter Types 781 Dss-Parms ::= SEQUENCE { 782 p INTEGER, 783 q INTEGER, 784 g INTEGER } 786 DHDomainParameters ::= SEQUENCE { 787 p INTEGER, -- odd prime, p=jq +1 788 g INTEGER, -- generator, g 789 q INTEGER, -- factor of p-1 790 j INTEGER OPTIONAL, -- subgroup factor 791 validationParms ValidationParms OPTIONAL } 793 ValidationParms ::= SEQUENCE { 794 seed BIT STRING, 795 pgenCounter INTEGER } 797 KeyWrapAlgorithm ::= AlgorithmIdentifier 799 RC2wrapParameter ::= RC2ParameterVersion 801 RC2ParameterVersion ::= INTEGER 803 CBCParameter ::= IV 805 IV ::= OCTET STRING -- exactly 8 octets 807 RC2CBCParameter ::= SEQUENCE { 808 rc2ParameterVersion INTEGER, 809 iv OCTET STRING } -- exactly 8 octets 811 PBKDF2-params ::= SEQUENCE { 812 salt CHOICE { 813 specified OCTET STRING, 814 otherSource AlgorithmIdentifier }, 815 iterationCount INTEGER (1..MAX), 816 keyLength INTEGER (1..MAX) OPTIONAL, 817 prf AlgorithmIdentifier 818 DEFAULT { algorithm hMAC-SHA1, parameters NULL } } 820 END -- of CryptographicMessageSyntaxAlgorithms 822 References 824 3DES American National Standards Institute. ANSI X9.52-1998, 825 Triple Data Encryption Algorithm Modes of Operation. 1998. 827 CERTALGS Bassham, L., R. Housley, and W. Polk. Algorithms and 828 Identifiers for the Internet X.509 Public Key 829 Infrastructure Certificate and CRL Profile. RFC . 830 . {draft-ietf-pkix-ipki-pkalgs-03.txt} 832 CMS Housley, R. Cryptographic Message Syntax. RFC . 833 . {draft-ietf-smime-rfc2630bis-*.txt} 835 DES American National Standards Institute. ANSI X3.106, 836 "American National Standard for Information Systems - Data 837 Link Encryption". 1983. 839 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 840 RFC 2631. June 1999. 842 DSS National Institute of Standards and Technology. 843 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 845 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 846 RFC 2104. February 1997. 848 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 849 April 1992. 851 MMA Rescorla, E. Preventing the Million Message Attack on CMS. 852 RFC . . {draft-ietf-smime-pkcs1-*.txt} 854 MODES National Institute of Standards and Technology. 855 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 857 NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, 858 Version 2.0. RFC 2437. October 1998. 860 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 861 RFC 2313. March 1998. 863 PKCS#5 Kaliski, B. PKCS #5: Password-Based Cryptography 864 Specification, Version 2.0. RFC 2898. September 2000. 866 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 867 X.509 Public Key Infrastructure: Certificate and CRL 868 Profile. RFC . . 869 {draft-ietf-pkix-new-part1-*.txt} 871 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 872 Recommendations for Security. RFC 1750. December 1994. 874 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 875 RFC 2268. March 1998. 877 SHA1 National Institute of Standards and Technology. 878 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 880 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 881 Requirement Levels. RFC2119. March 1997. 883 WRAP Housley, R. Triple-DES and RC2 Key Wrapping. RFC . 884 . {draft-ietf-smime-key-wrap-*.txt} 886 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 887 Syntax Notation One (ASN.1). 1988. 889 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 890 Rules for Abstract Syntax Notation One (ASN.1). 1988. 892 Security Considerations 894 The CMS provides a method for digitally signing data, digesting data, 895 encrypting data, and authenticating data. This document identifies 896 the conventions for using several cryptographic algorithms for use 897 with the CMS. 899 Implementations must protect the signer's private key. Compromise of 900 the signer's private key permits masquerade. 902 Implementations must protect the key management private key, the key- 903 encryption key, and the content-encryption key. Compromise of the 904 key management private key or the key-encryption key may result in 905 the disclosure of all messages protected with that key. Similarly, 906 compromise of the content-encryption key may result in disclosure of 907 the associated encrypted content. 909 Implementations must protect the key management private key and the 910 message-authentication key. Compromise of the key management private 911 key permits masquerade of authenticated data. Similarly, compromise 912 of the message-authentication key may result in undetectable 913 modification of the authenticated content. 915 The key management technique employed to distribute message- 916 authentication keys must itself provide authentication, otherwise the 917 message content is delivered with integrity from an unknown source. 918 Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman 920 [DH-X9.42] provide the necessary data origin authentication. Static- 921 Static Diffie-Hellman [DH-X9.42] does provide the necessary data 922 origin authentication when both the originator and recipient public 923 keys are bound to appropriate identities in X.509 certificates 924 [PROFILE]. 926 When more than two parties share the same message-authentication key, 927 data origin authentication is not provided. Any party that knows the 928 message-authentication key can compute a valid MAC, therefore the 929 message could originate from any one of the parties. 931 Implementations must randomly generate content-encryption keys, 932 message-authentication keys, initialization vectors (IVs), one-time 933 values (such as the k value when generating a DSA signature), and 934 padding. Also, the generation of public/private key pairs relies on 935 a random numbers. The use of inadequate pseudo-random number 936 generators (PRNGs) to generate cryptographic such values can result 937 in little or no security. An attacker may find it much easier to 938 reproduce the PRNG environment that produced the keys, searching the 939 resulting small set of possibilities, rather than brute force 940 searching the whole key space. The generation of quality random 941 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 942 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 943 PRNG technique. 945 When using key agreement algorithms or previously distributed 946 symmetric key-encryption keys, a key-encryption key is used to 947 encrypt the content-encryption key. If the key-encryption and 948 content-encryption algorithms are different, the effective security 949 is determined by the weaker of the two algorithms. If, for example, 950 a message content is encrypted with 168-bit Triple-DES and the 951 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 952 then at most 40 bits of protection is provided. A trivial search to 953 determine the value of the 40-bit RC2 key can recover Triple-DES key, 954 and then the Triple-DES key can be used to decrypt the content. 955 Therefore, implementers must ensure that key-encryption algorithms 956 are as strong or stronger than content-encryption algorithms. 958 RFC [WRAP] specifies key wrap algorithms used to encrypt a 959 Triple-DES content-encryption key with a Triple-DES key-encryption 960 key [3DES] or to encrypt a RC2 content-encryption key with a RC2 key- 961 encryption key [RC2]. The key wrap algorithms makes use of CBC mode 962 [MODES]. These key wrap algorithms have been reviewed for use with 963 Triple-DES and RC2. They have not been reviewed for use with other 964 cryptographic modes or other encryption algorithms. Therefore, if a 965 CMS implementation wishes to support ciphers in addition to Triple- 966 DES or RC2, then additional key wrap algorithms need to be defined to 967 support the additional ciphers. 969 Implementers should be aware that cryptographic algorithms become 970 weaker with time. As new cryptanalysis techniques are developed and 971 computing performance improves, the work factor to break a particular 972 cryptographic algorithm will reduce. Therefore, cryptographic 973 algorithm implementations should be modular allowing new algorithms 974 to be readily inserted. That is, implementers should be prepared to 975 regularly update the set of algorithms in their implementations. 977 Users of the CMS, particularly those employing the CMS to support 978 interactive applications, should be aware that RSA (PKCS #1 v1.5), as 979 specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen 980 ciphertext attacks when applied for encryption purposes. 981 Exploitation of this identified vulnerability, revealing the result 982 of a particular RSA decryption, requires access to an oracle which 983 will respond to a large number of ciphertexts (based on currently 984 available results, hundreds of thousands or more), which are 985 constructed adaptively in response to previously-received replies 986 providing information on the successes or failures of attempted 987 decryption operations. As a result, the attack appears significantly 988 less feasible to perpetrate for store-and-forward S/MIME environments 989 than for directly interactive protocols. Where the CMS constructs 990 are applied as an intermediate encryption layer within an interactive 991 request-response communications environment, exploitation could be 992 more feasible. 994 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 995 [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1 996 Version 2.0 preserves support for the encryption padding format 997 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 998 alternative. To resolve the adaptive chosen ciphertext 999 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 1000 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 1001 is used to provide confidentiality. Designers of protocols and 1002 systems employing CMS for interactive environments should either 1003 consider usage of OAEP, or should ensure that information which could 1004 reveal the success or failure of attempted PKCS #1 Version 1.5 1005 decryption operations is not provided. Support for OAEP will likely 1006 be added to a future version of the CMS algorithm specification. 1008 See RFC [MMA] for more information about thwarting the adaptive 1009 chosen ciphertext vulnerability in PKCS #1 Version 1.5 1010 implementations. 1012 Acknowledgments 1014 This document is the result of contributions from many professionals. 1015 I appreciate the hard work of all members of the IETF S/MIME Working 1016 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 1017 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 1018 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 1019 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 1020 Jim Schaad, and Dave Solo for their efforts and support. 1022 Author Address 1024 Russell Housley 1025 RSA Laboratories 1026 918 Spring Knoll Drive 1027 Herndon, VA 20170 1028 USA 1030 rhousley@rsasecurity.com 1032 Full Copyright Statement 1034 Copyright (C) The Internet Society (2001). All Rights Reserved. 1036 This document and translations of it may be copied and furnished to 1037 others, and derivative works that comment on or otherwise explain it 1038 or assist in its implementation may be prepared, copied, published 1039 and distributed, in whole or in part, without restriction of any 1040 kind, provided that the above copyright notice and this paragraph are 1041 included on all such copies and derivative works. In addition, the 1042 ASN.1 module presented in Appendix A may be used in whole or in part 1043 without inclusion of the copyright notice. However, this document 1044 itself may not be modified in any way, such as by removing the 1045 copyright notice or references to the Internet Society or other 1046 Internet organizations, except as needed for the purpose of 1047 developing Internet standards in which case the procedures for 1048 copyrights defined in the Internet Standards process shall be 1049 followed, or as required to translate it into languages other than 1050 English. 1052 The limited permissions granted above are perpetual and will not be 1053 revoked by the Internet Society or its successors or assigns. This 1054 document and the information contained herein is provided on an "AS 1055 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1056 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1057 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1058 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1059 OR FITNESS FOR A PARTICULAR PURPOSE.