idnits 2.17.1 draft-ietf-smime-cmsalg-02.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 14 instances of too long lines in the document, the longest one being 5 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 99: '... implementations MAY support these alg...' RFC 2119 keyword, line 100: '... MAY support other algorithms as wel...' RFC 2119 keyword, line 111: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 112: '... SHOULD NOT, RECOMMENDED, and MAY ar...' RFC 2119 keyword, line 140: '... syntax the OPTIONAL associated with...' (59 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2001) is 8282 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 96, but not defined == Missing Reference: 'STDWORDS' is mentioned on line 114, but not defined == Missing Reference: 'SHA1' is mentioned on line 714, but not defined == Missing Reference: 'MD5' is mentioned on line 157, but not defined == Missing Reference: 'DSS' is mentioned on line 1069, but not defined == Missing Reference: 'RC2' is mentioned on line 1087, but not defined == Missing Reference: 'MMA' is mentioned on line 1135, but not defined == Missing Reference: 'DES' is mentioned on line 610, but not defined == Missing Reference: 'HMAC' is mentioned on line 663, but not defined == Missing Reference: 'RANDOM' is mentioned on line 1068, but not defined == Unused Reference: 'PROFILE' is defined on line 1051, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PROFILE' -- Possible downref: Non-RFC (?) normative reference: ref. '3DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 7 errors (**), 0 flaws (~~), 15 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 August 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 ................................. 11 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 ........................................ 13 78 5.2 RC2 CBC ............................................... 14 79 6 Message Authentication Code (MAC) Algorithms ................. 14 80 6.1 HMAC with SHA-1 ....................................... 14 81 7 Triple-DES and RC2 Key Wrap Algorithms ....................... 15 82 7.1 Key Checksum .......................................... 15 83 7.2 Triple-DES Key Wrap ................................... 16 84 7.3 Triple-DES Key Unwrap ................................. 16 85 7.4 RC2 Key Wrap .......................................... 17 86 7.5 RC2 Key Unwrap ........................................ 17 87 Appendix A: ASN.1 Module ........................................ 18 88 References ....................................................... 21 89 Security Considerations .......................................... 22 90 Acknowledgments .................................................. 25 91 Author's Address ................................................. 25 92 Full Copyright Statement ......................................... 26 94 1 Introduction 96 The Cryptographic Message Syntax (CMS) [CMS] is used to digitally 97 sign, digest, authenticate, or encrypt arbitrary messages. This 98 companion specification lists the common cryptographic algorithms. 99 CMS implementations MAY support these algorithms; CMS implementations 100 MAY support other algorithms as well. 102 The CMS values are generated using ASN.1 [X.208-88], using BER- 103 encoding [X.209-88]. Algorithm identifiers (which include ASN.1 104 object identifiers) identify cryptographic algorithms, and some 105 algorithms require additional parameters. When needed, parameters 106 are specified with an ASN.1 structure. The algorithm identifier for 107 each algorithm is specified, and, when needed, the parameter 108 structure is specified. The fields in the CMS employed by each 109 algorithm are identified. 111 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 112 SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described 113 by Scott Bradner in [STDWORDS]. 115 2 Message Digest Algorithms 117 This section specifies the conventions employed by CMS 118 implementations that support SHA-1 or MD5. 120 Digest algorithm identifiers are located in the SignedData 121 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 122 DigestedData digestAlgorithm field, and the AuthenticatedData 123 digestAlgorithm field. 125 Digest values are located in the DigestedData digest field the 126 Message Digest authenticated attribute. In addition, digest values 127 are input to signature algorithms. 129 2.1 SHA-1 131 The SHA-1 message digest algorithm is defined in FIPS Pub 180-1 132 [SHA1]. The algorithm identifier for SHA-1 is: 134 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 135 oiw(14) secsig(3) algorithm(2) 26 } 137 There are two possible encodings for the SHA-1 AlgorithmIdentifier 138 parameters field. The two alternatives arise from the fact that when 139 the 1988 syntax for AlgorithmIdentifier was translated into the 1997 140 syntax the OPTIONAL associated with the AlgorithmIdentifier 141 parameters got lost. Later the OPTIONAL was recovered via a defect 142 report, but by then many people thought that algorithm parameters 143 were mandatory. Because of this history some implementations encode 144 parameters as a NULL element and others omit them entirely. The 145 correct encoding is to omit the parameters field; however, 146 implementations MUST also handle a SHA-1 AlgorithmIdentifier 147 parameters field which contains a NULL. 149 The AlgorithmIdentifier parameters field is OPTIONAL. If present, 150 the parameters field MUST contain a NULL. Implementations SHOULD 151 accept SHA-1 AlgorithmIdentifiers with absent parameters as well as 152 NULL parameters. Implementations SHOULD generate SHA-1 153 AlgorithmIdentifiers with absent parameters. 155 2.2 MD5 157 The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm 158 identifier for MD5 is: 160 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 161 rsadsi(113549) digestAlgorithm(2) 5 } 163 The AlgorithmIdentifier parameters field MUST be present, and the 164 parameters field MUST contain NULL. Implementations MAY accept the 165 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 166 parameters. 168 3 Signature Algorithms 170 This section specifies the conventions employed by CMS 171 implementations that support DSA or RSA (PKCS #1 v1.5). 173 Signature algorithm identifiers are located in the SignerInfo 174 signatureAlgorithm field of SignedData. Also, signature algorithm 175 identifiers are located in the SignerInfo signatureAlgorithm field of 176 countersignature attributes. 178 Signature values are located in the SignerInfo signature field of 179 SignedData. Also, signature values are located in the SignerInfo 180 signature field of countersignature attributes. 182 3.1 DSA 184 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA 185 MUST be used with the SHA-1 message digest algorithm. 187 The algorithm identifier for DSA subject public keys in certificates 188 is: 190 id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) 191 us(840) x9-57 (10040) x9cm(4) 1 } 193 DSA signature validation requires three parameters, commonly called 194 p, q, and g. When the id-dsa algorithm identifier is used, 195 AlgorithmIdentifier parameters field is optional. If present, the 196 AlgorithmIdentifier parameters field MUST contain the three DSA 197 parameter values encoded using the Dss-Parms type. If absent, the 198 subject DSA public key uses the same DSA parameters as the 199 certificate issuer. 201 Dss-Parms ::= SEQUENCE { 202 p INTEGER, 203 q INTEGER, 204 g INTEGER } 206 When the id-dsa algorithm identifier is used, the DSA public key, 207 commonly called Y, MUST be encoded as an INTEGER. The output of this 208 encoding is carried in the certificate subject public key. 210 Dss-Pub-Key ::= INTEGER -- Y 212 The algorithm identifier for DSA with SHA-1 signature values is: 214 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 215 us(840) x9-57 (10040) x9cm(4) 3 } 217 When the id-dsa-with-sha1 algorithm identifier is used, 218 AlgorithmIdentifier parameters field MUST be absent. 220 When signing, the DSA algorithm generates two values, commonly called 221 r and s. To transfer these two values as one signature, they MUST be 222 encoded using the Dss-Sig-Value type: 224 Dss-Sig-Value ::= SEQUENCE { 225 r INTEGER, 226 s INTEGER } 228 3.2 RSA 230 The RSA signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC 231 2437 specifies the use of the RSA signature algorithm with the SHA-1 232 and MD5 message digest algorithms. 234 The algorithm identifier for RSA subject public keys in certificates 235 is: 237 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 238 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 240 When the rsaEncryption algorithm identifier is used, 241 AlgorithmIdentifier parameters field MUST contain NULL. 243 When the rsaEncryption algorithm identifier is used, the RSA public 244 key, which is composed of a modulus and a public exponent, MUST be 245 encoded using the RSAPublicKey type. The output of this encoding is 246 carried in the certificate subject public key. 248 RSAPublicKey ::= SEQUENCE { 249 modulus INTEGER, -- n 250 publicExponent INTEGER } - e 252 CMS implementations that support the RSA (PKCS #1 v1.5) signature 253 algorithm MUST also support the SHA-1 message digest algorithm. Such 254 implementations SHOULD also support MD5 message digest algorithm. 256 The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature 257 values is: 259 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 260 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 262 The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature 263 values is: 265 md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 266 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 268 When either the sha1WithRSAEncryption algorithm identifier or the 269 md5WithRSAEncryption algorithm identifier is used, the 270 AlgorithmIdentifier parameters field MUST be NULL. 272 When signing, the RSA algorithm generates a single value, and that 273 value is used directly as the signature value. 275 4 Key Management Algorithms 277 CMS accommodates the following general key management techniques: key 278 agreement, key transport, previously distributed symmetric key- 279 encryption keys, and passwords. 281 4.1 Key Agreement Algorithms 283 This section specifies the conventions employed by CMS 284 implementations that support key agreement using X9.42 Ephemeral- 285 Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie- 286 Hellman (X9.42 S-S D-H). 288 Any symmetric encryption algorithm that a CMS implementation includes 289 as a content-encryption algorithm MUST also be included as a key- 290 encryption algorithm. The key wrap algorithms for Triple-DES and RC2 291 are described in section 7. 293 A CMS implementation MAY support mixed key-encryption and content- 294 encryption algorithms. For example, a 128-bit RC2 content-encryption 295 key MAY be wrapped with 168-bit Triple-DES key-encryption key. 296 Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with 297 128-bit RC2 key-encryption key. 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. When present, the ukm is used to 338 ensure that a different key-encryption key is generated when the 339 ephemeral private key might be used more than once. 341 keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm 342 identifier. The algorithm identifier parameter field for id-alg- 343 ESDH is KeyWrapAlgorihtm, and this parameter MUST be present. The 344 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 345 to encrypt the content-encryption key with the pairwise key- 346 encryption key generated using the X9.42 Ephemeral-Static Diffie- 347 Hellman key agreement algorithm. Triple-DES and RC2 key wrap 348 algorithms are discussed in section 7. The id-alg-ESDH algorithm 349 identifier and parameter syntax is: 351 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 352 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 354 KeyWrapAlgorithm ::= AlgorithmIdentifier 356 recipientEncryptedKeys contains an identifier and an encrypted key 357 for each recipient. The RecipientEncryptedKey 358 KeyAgreeRecipientIdentifier MUST contain either the 359 issuerAndSerialNumber identifying the recipient's certificate or 360 the RecipientKeyIdentifier containing the subject key identifier 361 from the recipient's certificate. In both cases, the recipient's 362 certificate contains the recipient's static public key. 363 RecipientEncryptedKey EncryptedKey MUST contain the content- 364 encryption key encrypted with the X9.42 Ephemeral-Static Diffie- 365 Hellman generated pairwise key-encryption key using the algorithm 366 specified by the KeyWrapAlgortihm. 368 4.1.2 X9.42 Static-Static Diffie-Hellman 370 Static-Static Diffie-Hellman key agreement is defined in RFC 2631 371 [DH-X9.42]. When using Static-Static Diffie-Hellman, the 372 EnvelopedData RecipientInfos KeyAgreeRecipientInfo and 373 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are 374 used as follows: 376 version MUST be 3. 378 originator MUST be either the issuerAndSerialNumber or 379 subjectKeyIdentifier alternative. In both cases, the recipient's 380 certificate contains the sender's static public key, and the 381 certificate subject public key information field MUST contain the 382 dh-public-number object identifier is: 384 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 385 us(840) ansi-x942(10046) number-type(2) 1 } 387 ukm MUST be present. The ukm ensures that a different key- 388 encryption key is generated for each message between the same 389 sender and recipient. 391 keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm 392 identifier. The algorithm identifier parameter field for id-alg- 393 SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The 394 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 395 to encrypt the content-encryption key with the pairwise key- 396 encryption key generated using the X9.42 Static-Static Diffie- 397 Hellman key agreement algorithm. Triple-DES and RC2 key wrap 398 algorithms are discussed in section 7. The id-alg-SSDH algorithm 399 identifier and parameter syntax is: 401 id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 402 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 } 404 KeyWrapAlgorithm ::= AlgorithmIdentifier 406 recipientEncryptedKeys contains an identifier and an encrypted key 407 for each recipient. The RecipientEncryptedKey 408 KeyAgreeRecipientIdentifier MUST contain either the 409 issuerAndSerialNumber identifying the recipient's certificate or 410 the RecipientKeyIdentifier containing the subject key identifier 411 from the recipient's certificate. In both cases, the recipient's 412 certificate contains the recipient's static public key. 413 RecipientEncryptedKey EncryptedKey MUST contain the content- 414 encryption key encrypted with the X9.42 Static-Static Diffie- 415 Hellman generated pairwise key-encryption key using the algorithm 416 specified by the KeyWrapAlgortihm. 418 4.2 Key Transport Algorithms 420 This section specifies the conventions employed by CMS 421 implementations that support key transport using RSA (PKCS #1 v1.5). 423 Key transport algorithm identifiers are located in the EnvelopedData 424 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 426 Key transport encrypted content-encryption keys are located in the 427 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 428 field. 430 4.2.1 RSA (PKCS #1 v1.5) 432 The RSA key transport algorithm is the RSA encryption scheme defined 433 in RFC 2313 [PKCS#1], block type is 02, where the message to be 434 encrypted is the content-encryption key. The algorithm identifier 435 for RSA (PKCS #1 v1.5) is: 437 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 438 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 440 The AlgorithmIdentifier parameters field MUST be present, and the 441 parameters field MUST contain NULL. 443 When using a Triple-DES content-encryption key, CMS implementations 444 MUST adjust the parity bits for each DES key comprising the Triple- 445 DES key prior to RSA encryption. 447 The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313 448 [PKCS#1], to provide confidentiality has a known vulnerability. The 449 vulnerability is primarily relevant to usage in interactive 450 applications rather than to store-and-forward environments. Further 451 information and proposed countermeasures are discussed in the 452 Security Considerations section of this document and RFC [MMA]. 454 Note that the same RSA encryption scheme is also defined in RFC 2437 455 [NEWPKCS#1]. Within RFC 2437, this RSA encryption scheme is called 456 RSAES-PKCS1-v1_5. 458 4.3 Symmetric Key-Encryption Key Algorithms 460 This section specifies the conventions employed by CMS 461 implementations support symmetric key-encryption key management using 462 Triple-DES or RC2 key-encryption keys. When RC2 is supported, RC2 463 128-bit keys MUST be used as key-encryption keys, and they MUST be 464 used with the RC2ParameterVersion parameter set to 58. A CMS 465 implementation MAY support mixed key-encryption and content- 466 encryption algorithms. For example, a 40-bit RC2 content-encryption 467 key MAY be wrapped with 168-bit Triple-DES key-encryption key or with 468 a 128-bit RC2 key-encryption key. 470 Key wrap algorithm identifiers are located in the EnvelopedData 471 RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and 472 AuthenticatedData RecipientInfos KEKRecipientInfo 473 keyEncryptionAlgorithm fields. 475 Wrapped content-encryption keys are located in the EnvelopedData 476 RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- 477 authentication keys are located in the AuthenticatedData 478 RecipientInfos KEKRecipientInfo encryptedKey field. 480 The output of a key agreement algorithm is a key-encryption key, and 481 this key-encryption key is used to encrypt the content-encryption 482 key. To support key agreement, key wrap algorithm identifiers are 483 located in the KeyWrapAlgorithm parameter of the EnvelopedData 484 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 485 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 486 keyEncryptionAlgorithm fields. However, only key agreement 487 algorithms that inherently provide authentication ought to be used 488 with AuthenticatedData. Wrapped content-encryption keys are located 489 in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo 490 RecipientEncryptedKeys encryptedKey field, wrapped message- 491 authentication keys are located in the AuthenticatedData 492 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 493 encryptedKey field. 495 4.3.1 Triple-DES Key Wrap 497 Triple-DES key encryption has the algorithm identifier: 499 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 500 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 502 The AlgorithmIdentifier parameter field MUST be NULL. 504 The key wrap algorithm used to encrypt a Triple-DES content- 505 encryption key with a Triple-DES key-encryption key is specified in 506 section 7.2. The corresponding key unwrap algorithm is specified in 507 section 7.3. 509 Out-of-band distribution of the Triple-DES key-encryption key used to 510 encrypt the Triple-DES content-encryption key is beyond of the scope 511 of this document. 513 4.3.2 RC2 Key Wrap 515 RC2 key encryption has the algorithm identifier: 517 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 518 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 520 The AlgorithmIdentifier parameter field MUST be RC2wrapParameter: 522 RC2wrapParameter ::= RC2ParameterVersion 523 RC2ParameterVersion ::= INTEGER 525 The RC2 effective-key-bits (key size) greater than 32 and less than 526 256 is encoded in the RC2ParameterVersion. For the effective-key- 527 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 528 and 58 respectively. These values are not simply the RC2 key length. 529 Note that the value 160 must be encoded as two octets (00 A0), 530 because the one octet (A0) encoding represents a negative number. 532 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST 533 be used with the RC2ParameterVersion parameter set to 58. 535 The key wrap algorithm used to encrypt a RC2 content-encryption key 536 with a RC2 key-encryption key is specified in section 7.4. The 537 corresponding key unwrap algorithm is specified in section 7.5. 539 Out-of-band distribution of the RC2 key-encryption key used to 540 encrypt the RC2 content-encryption key is beyond of the scope of this 541 document. 543 4.4 Key Derivation Algorithms 545 This section specifies the conventions employed by CMS 546 implementations that support password-based key management using 547 PBKDF2. 549 Key derivation algorithms are used to convert a password into a key- 550 encryption key as part of the password-based key management 551 technique. CMS implementations that support the password-based key 552 management technique MUST implement the PBKDF2 key derivation 553 algorithm specified in RFC 2898 [PKCS#5]. 555 Key derivation algorithm identifiers are located in the EnvelopedData 556 RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and 557 AuthenticatedData RecipientInfos PasswordRecipientInfo 558 keyDerivationAlgorithm fields. 560 The key-encryption key that is derived from the password is used to 561 encrypt the content-encryption key 563 The content-encryption keys encrypted with password-derived key- 564 encryption keys are located in the EnvelopedData RecipientInfos 565 PasswordRecipientInfo encryptedKey field. The message-authentication 566 keys encrypted with password-derived key-encryption keys are located 567 in the AuthenticatedData RecipientInfos PasswordRecipientInfo 568 encryptedKey field. 570 4.4.1 PBKDF2 572 The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5]. 573 The KeyDerivationAlgorithmIdentifer identifies the key-derivation 574 algorithm, and any associated parameters, used to derive the key- 575 encryption key from the user-supplied password. The algorithm 576 identifier for the PBKDF2 key derivation algorithm is: 578 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 579 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 581 The AlgorithmIdentifier parameter field MUST be PBKDF2-params: 583 PBKDF2-params ::= SEQUENCE { 584 salt CHOICE { 585 specified OCTET STRING, 586 otherSource AlgorithmIdentifier }, 587 iterationCount INTEGER (1..MAX), 588 keyLength INTEGER (1..MAX) OPTIONAL, 589 prf AlgorithmIdentifier DEFAULT hMAC-SHA1 } 591 5 Content Encryption Algorithms 593 This section specifies the conventions employed by CMS 594 implementations that support content encryption using Three-Key 595 Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC 596 mode. 598 Content encryption algorithms identifiers are located in the 599 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 600 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 602 Content encryption algorithms are used to encipher the content 603 located in the EnvelopedData EncryptedContentInfo encryptedContent 604 field and the EncryptedData EncryptedContentInfo encryptedContent 605 field. 607 5.1 Triple-DES CBC 609 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 610 Triple-DES is composed from three sequential DES [DES] operations: 611 encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different 612 key for each DES operation. Two-Key Triple-DES uses one key for the 613 two encrypt operations and different key for the decrypt operation. 614 The same algorithm identifiers are used for Three-Key Triple-DES and 615 Two-Key Triple-DES. The algorithm identifier for Triple-DES in 616 Cipher Block Chaining (CBC) mode is: 618 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 619 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 621 The AlgorithmIdentifier parameters field MUST be present, and the 622 parameters field must contain a CBCParameter: 624 CBCParameter ::= IV 626 IV ::= OCTET STRING -- exactly 8 octets 628 5.2 RC2 CBC 630 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 631 identifier for RC2 in CBC mode is: 633 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 634 rsadsi(113549) encryptionAlgorithm(3) 2 } 636 The AlgorithmIdentifier parameters field MUST be present, and the 637 parameters field MUST contain a RC2CBCParameter: 639 RC2CBCParameter ::= SEQUENCE { 640 rc2ParameterVersion INTEGER, 641 iv OCTET STRING } -- exactly 8 octets 643 The RC2 effective-key-bits (key size) greater than 32 and less than 644 256 is encoded in the rc2ParameterVersion. For the effective-key- 645 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 646 and 58 respectively. These values are not simply the RC2 key length. 647 Note that the value 160 must be encoded as two octets (00 A0), since 648 the one octet (A0) encoding represents a negative number. 650 6 Message Authentication Code Algorithms 652 This section specifies the conventions employed by CMS 653 implementations that support the HMAC with SHA-1 message 654 authentication code (MAC). 656 MAC algorithm identifiers are located in the AuthenticatedData 657 macAlgorithm field. 659 MAC values are located in the AuthenticatedData mac field. 661 6.1 HMAC with SHA-1 663 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 664 algorithm identifier for HMAC with SHA-1 is: 666 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 667 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 669 The AlgorithmIdentifier parameters field must be absent. 671 7 Triple-DES and RC2 Key Wrap Algorithms 673 This section specifies algorithms for wrapping content-encryption 674 keys with Triple-DES and RC2 key-encryption keys. Encryption of a 675 Triple-DES content-encryption key with a Triple-DES key-encryption 676 key uses the algorithm specified in sections 7.2 and 7.3. Encryption 677 of a RC2 content-encryption key with a RC2 key-encryption key uses 678 the algorithm specified in sections 7.4 and 7.5. Both of these 679 algorithms rely on the key checksum algorithm specified in section 680 7.1. Triple-DES and RC2 content-encryption keys are encrypted in 681 Cipher Block Chaining (CBC) mode [MODES]. 683 Key Transport algorithms allow for the content-encryption key to be 684 directly encrypted; however, key agreement and symmetric key- 685 encryption key algorithms encrypt the content-encryption key with a 686 second symmetric encryption algorithm. This section describes how 687 the Triple-DES or RC2 content-encryption key is formatted and 688 encrypted. 690 Key agreement algorithms generate a pairwise key-encryption key, and 691 a key wrap algorithm is used to encrypt the content-encryption key 692 with the pairwise key-encryption key. Similarly, a key wrap 693 algorithm is used to encrypt the content-encryption key in a 694 previously distributed key-encryption key. 696 The key-encryption key is generated by the key agreement algorithm or 697 distributed out of band. For key agreement of RC2 key-encryption 698 keys, 128 bits MUST be generated as input to the key expansion 699 process used to compute the RC2 effective key [RC2]. 701 The same algorithm identifier is used for both Two-key Triple-DES and 702 Three-key Triple-DES. When the length of the content-encryption key 703 to be wrapped is a Two-key Triple-DES key, a third key with the same 704 value as the first key is created. Thus, all Triple-DES content- 705 encryption keys are wrapped like Three-key Triple-DES keys. However, 706 a Two-key Triple-DES key MUST NOT be used to wrap a Three-key Triple- 707 DES key. 709 7.1 Key Checksum 711 The CMS Key Checksum Algorithm is used to provide a content- 712 encryption key integrity check value. The algorithm is: 714 1. Compute a 20 octet SHA-1 [SHA1] message digest on the 715 content-encryption key. 716 2. Use the most significant (first) eight octets of the message 717 digest value as the checksum value. 719 7.2 Triple-DES Key Wrap 721 The Triple-DES key wrap algorithm encrypts a Triple-DES content- 722 encryption key with a Triple-DES key-encryption key. The Triple-DES 723 key wrap algorithm is: 725 1. Set odd parity for each of the DES key octets comprising 726 the content-encryption key, call the result CEK. 727 2. Compute an 8 octet key checksum value on CEK as described above 728 in Section 7.1, call the result ICV. 729 3. Let CEKICV = CEK || ICV. 730 4. Generate 8 octets at random, call the result IV. 731 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use 732 the random value generated in the previous step as the 733 initialization vector (IV). Call the ciphertext TEMP1. 734 6. Let TEMP2 = IV || TEMP1. 735 7. Reverse the order of the octets in TEMP2. That is, the most 736 significant (first) octet is swapped with the least significant 737 (last) octet, and so on. Call the result TEMP3. 738 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 739 an initialization vector (IV) of 0x4adda22c79e82105. 740 The ciphertext is 40 octets long. 742 Note: When the same content-encryption key is wrapped in different 743 key-encryption keys, a fresh initialization vector (IV) must be 744 generated for each invocation of the key wrap algorithm. 746 7.3 Triple-DES Key Unwrap 748 The Triple-DES key unwrap algorithm decrypts a Triple-DES content- 749 encryption key using a Triple-DES key-encryption key. The Triple-DES 750 key unwrap algorithm is: 752 1. If the wrapped content-encryption key is not 40 octets, then 753 error. 754 2. Decrypt the wrapped content-encryption key in CBC mode using 755 the key-encryption key. Use an initialization vector (IV) 756 of 0x4adda22c79e82105. Call the output TEMP3. 757 3. Reverse the order of the octets in TEMP3. That is, the most 758 significant (first) octet is swapped with the least significant 759 (last) octet, and so on. Call the result TEMP2. 760 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 761 significant (first) 8 octets, and TEMP1 is the least significant 762 (last) 32 octets. 763 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 764 the IV value from the previous step as the initialization vector. 765 Call the ciphertext CEKICV. 766 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant 767 (first) 24 octets, and ICV is the least significant (last) 8 octets. 768 7. Compute an 8 octet key checksum value on CEK as described above 769 in Section 7.1. If the computed key checksum value does not 770 match the decrypted key checksum value, ICV, then error. 771 8. Check for odd parity each of the DES key octets comprising CEK. 772 If parity is incorrect, then there is an error. 773 9. Use CEK as the content-encryption key. 775 7.4 RC2 Key Wrap 777 The RC2 key wrap algorithm encrypts a RC2 content-encryption key with 778 a RC2 key-encryption key. The RC2 key wrap algorithm is: 780 1. Let the content-encryption key be called CEK, and let the length 781 of the content-encryption key in octets be called LENGTH. LENGTH 782 is a single octet. 783 2. Let LCEK = LENGTH || CEK. 784 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple 785 of 8, the PAD has a length of zero. If the length of LCEK is 786 not a multiple of 8, then PAD contains the fewest number of 787 random octets to make the length of LCEKPAD a multiple of 8. 788 4. Compute an 8 octet key checksum value on LCEKPAD as described 789 above in Section 7.1, call the result ICV. 790 5. Let LCEKPADICV = LCEKPAD || ICV. 791 6. Generate 8 octets at random, call the result IV. 792 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. 793 Use the random value generated in the previous step as the 794 initialization vector (IV). Call the ciphertext TEMP1. 795 8. Let TEMP2 = IV || TEMP1. 796 9. Reverse the order of the octets in TEMP2. That is, the most 797 significant (first) octet is swapped with the least significant 798 (last) octet, and so on. Call the result TEMP3. 799 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 800 an initialization vector (IV) of 0x4adda22c79e82105. 802 Note: When the same content-encryption key is wrapped in different 803 key-encryption keys, a fresh initialization vector (IV) must be 804 generated for each invocation of the key wrap algorithm. 806 7.5 RC2 Key Unwrap 808 The RC2 key unwrap algorithm decrypts a RC2 content-encryption key 809 using a RC2 key-encryption key. The RC2 key unwrap algorithm is: 811 1. If the wrapped content-encryption key is not a multiple of 8 812 octets, then error. 813 2. Decrypt the wrapped content-encryption key in CBC mode using 814 the key-encryption key. Use an initialization vector (IV) 815 of 0x4adda22c79e82105. Call the output TEMP3. 816 3. Reverse the order of the octets in TEMP3. That is, the most 817 significant (first) octet is swapped with the least significant 818 (last) octet, and so on. Call the result TEMP2. 819 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 820 significant (first) 8 octets, and TEMP1 is the remaining octets. 821 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 822 the IV value from the previous step as the initialization vector. 823 Call the plaintext LCEKPADICV. 824 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the 825 least significant (last) octet 8 octets. LCEKPAD is the 826 remaining octets. 827 7. Compute an 8 octet key checksum value on LCEKPAD as described 828 above in Section 7.1. If the computed key checksum value does 829 not match the decrypted key checksum value, ICV, then error. 830 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the 831 most significant (first) octet. CEK is the following LENGTH 832 octets. PAD is the remaining octets, if any. 833 9. If the length of PAD is more than 7 octets, then error. 834 10. Use CEK as the content-encryption key. 836 Appendix A: ASN.1 Module 838 CryptographicMessageSyntaxAlgorithms 839 { iso(1) member-body(2) us(840) rsadsi(113549) 840 pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) } 842 DEFINITIONS IMPLICIT TAGS ::= 843 BEGIN 845 -- EXPORTS All 846 -- The types and values defined in this module are exported for use in 847 -- the other ASN.1 modules. Other applications may use them for their 848 -- own purposes. 850 -- IMPORTS None 851 -- Algorithm Identifiers 853 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 854 oiw(14) secsig(3) algorithm(2) 26 } 856 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 857 rsadsi(113549) digestAlgorithm(2) 5 } 859 id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 860 x9-57(10040) x9cm(4) 1 } 862 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 863 us(840) x9-57(10040) x9cm(4) 3 } 865 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 866 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 868 md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 869 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 871 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) 872 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 874 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 875 us(840) ansi-x942(10046) number-type(2) 1 } 877 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 878 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 880 id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 881 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 } 883 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 884 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 886 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 887 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 889 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 890 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 892 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 893 rsadsi(113549) encryptionAlgorithm(3) 2 } 895 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 896 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 898 id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 899 rsadsi(113549) pkcs(1) pkcs-5(5) 12 } 901 -- Public Key Types 903 Dss-Pub-Key ::= INTEGER -- Y 905 RSAPublicKey ::= SEQUENCE { 906 modulus INTEGER, -- n 907 publicExponent INTEGER } -- e 909 DHPublicKey ::= INTEGER -- y = g^x mod p 911 -- Signature Value Types 913 Dss-Sig-Value ::= SEQUENCE { 914 r INTEGER, 915 s INTEGER } 917 -- Algorithm Identifier Parameter Types 919 Dss-Parms ::= SEQUENCE { 920 p INTEGER, 921 q INTEGER, 922 g INTEGER } 924 DHDomainParameters ::= SEQUENCE { 925 p INTEGER, -- odd prime, p=jq +1 926 g INTEGER, -- generator, g 927 q INTEGER, -- factor of p-1 928 j INTEGER OPTIONAL, -- subgroup factor 929 validationParms ValidationParms OPTIONAL } 931 ValidationParms ::= SEQUENCE { 932 seed BIT STRING, 933 pgenCounter INTEGER } 935 KeyWrapAlgorithm ::= AlgorithmIdentifier 937 RC2wrapParameter ::= RC2ParameterVersion 939 RC2ParameterVersion ::= INTEGER 941 CBCParameter ::= IV 943 IV ::= OCTET STRING -- exactly 8 octets 944 RC2CBCParameter ::= SEQUENCE { 945 rc2ParameterVersion INTEGER, 946 iv OCTET STRING } -- exactly 8 octets 948 PBKDF2-params ::= SEQUENCE { 949 salt CHOICE { 950 specified OCTET STRING, 951 otherSource AlgorithmIdentifier }, 952 iterationCount INTEGER (1..MAX), 953 keyLength INTEGER (1..MAX) OPTIONAL, 954 prf AlgorithmIdentifier DEFAULT hMAC-SHA1 } 956 END -- of CryptographicMessageSyntaxAlgorithms 958 References 960 3DES American National Standards Institute. ANSI X9.52-1998, 961 Triple Data Encryption Algorithm Modes of Operation. 1998. 963 CMS Housley, R. Cryptographic Message Syntax. RFC . . 964 {draft-ietf-smime-rfc2630bis-*.txt} 966 DES American National Standards Institute. ANSI X3.106, 967 "American National Standard for Information Systems - Data 968 Link Encryption". 1983. 970 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 971 RFC 2631. June 1999. 973 DSS National Institute of Standards and Technology. 974 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 976 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 977 RFC 2104. February 1997. 979 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 980 April 1992. 982 MMA Rescorla, E. Preventing the Million Message Attack on CMS. 983 RFC . . {draft-ietf-smime-pkcs1-*.txt} 985 MODES National Institute of Standards and Technology. 986 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 988 NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, 989 Version 2.0. RFC 2437. October 1998. 991 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 992 RFC 2313. March 1998. 994 PKCS#5 Kaliski, B. PKCS #5: Password-Based Cryptography 995 Specification, Version 2.0. RFC 2898. September 2000. 997 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 998 X.509 Public Key Infrastructure: Certificate and CRL 999 Profile. RFC . . 1000 {draft-ietf-pkix-new-part1-*.txt} 1002 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 1003 Recommendations for Security. RFC 1750. December 1994. 1005 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 1006 RFC 2268. March 1998. 1008 SHA1 National Institute of Standards and Technology. 1009 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 1011 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 1012 Requirement Levels. RFC2119. March 1997. 1014 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 1015 Syntax Notation One (ASN.1). 1988. 1017 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 1018 Rules for Abstract Syntax Notation One (ASN.1). 1988. 1020 Security Considerations 1022 The CMS provides a method for digitally signing data, digesting data, 1023 encrypting data, and authenticating data. This document identifies 1024 the conventions for using several cryptographic algorithms for use 1025 with the CMS. 1027 Implementations must protect the signer's private key. Compromise of 1028 the signer's private key permits masquerade. 1030 Implementations must protect the key management private key, the key- 1031 encryption key, and the content-encryption key. Compromise of the 1032 key management private key or the key-encryption key may result in 1033 the disclosure of all messages protected with that key. Similarly, 1034 compromise of the content-encryption key may result in disclosure of 1035 the associated encrypted content. 1037 Implementations must protect the key management private key and the 1038 message-authentication key. Compromise of the key management private 1039 key permits masquerade of authenticated data. Similarly, compromise 1040 of the message-authentication key may result in undetectable 1041 modification of the authenticated content. 1043 The key management technique employed to distribute message- 1044 authentication keys must itself provide authentication, otherwise the 1045 message content is delivered with integrity from an unknown source. 1046 Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman 1047 [DH-X9.42] provide the necessary data origin authentication. Static- 1048 Static Diffie-Hellman [DH-X9.42] does provide the necessary data 1049 origin authentication when both the originator and recipient public 1050 keys are bound to appropriate identities in X.509 certificates 1051 [PROFILE]. 1053 When more than two parties share the same message-authentication key, 1054 data origin authentication is not provided. Any party that knows the 1055 message-authentication key can compute a valid MAC, therefore the 1056 message could originate from any one of the parties. 1058 Implementations must randomly generate content-encryption keys, 1059 message-authentication keys, initialization vectors (IVs), one-time 1060 values (such as the k value when generating a DSA signature), and 1061 padding. Also, the generation of public/private key pairs relies on 1062 a random numbers. The use of inadequate pseudo-random number 1063 generators (PRNGs) to generate cryptographic such values can result 1064 in little or no security. An attacker may find it much easier to 1065 reproduce the PRNG environment that produced the keys, searching the 1066 resulting small set of possibilities, rather than brute force 1067 searching the whole key space. The generation of quality random 1068 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 1069 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 1070 PRNG technique. 1072 When using key agreement algorithms or previously distributed 1073 symmetric key-encryption keys, a key-encryption key is used to 1074 encrypt the content-encryption key. If the key-encryption and 1075 content-encryption algorithms are different, the effective security 1076 is determined by the weaker of the two algorithms. If, for example, 1077 a message content is encrypted with 168-bit Triple-DES and the 1078 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 1079 then at most 40 bits of protection is provided. A trivial search to 1080 determine the value of the 40-bit RC2 key can recover Triple-DES key, 1081 and then the Triple-DES key can be used to decrypt the content. 1082 Therefore, implementers must ensure that key-encryption algorithms 1083 are as strong or stronger than content-encryption algorithms. 1085 Section 7 specifies key wrap algorithms used to encrypt a Triple-DES 1086 [3DES] content-encryption key with a Triple-DES key-encryption key or 1087 to encrypt a RC2 [RC2] content-encryption key with a RC2 key- 1088 encryption key. The key wrap algorithms make use of CBC mode 1089 [MODES]. These key wrap algorithms have been reviewed for use with 1090 Triple-DES and RC2. They have not been reviewed for use with other 1091 cryptographic modes or other encryption algorithms. Therefore, if a 1092 CMS implementation wishes to support ciphers in addition to Triple- 1093 DES or RC2, then additional key wrap algorithms need to be defined to 1094 support the additional ciphers. 1096 Implementers should be aware that cryptographic algorithms become 1097 weaker with time. As new cryptanalysis techniques are developed and 1098 computing performance improves, the work factor to break a particular 1099 cryptographic algorithm will reduce. Therefore, cryptographic 1100 algorithm implementations should be modular allowing new algorithms 1101 to be readily inserted. That is, implementers should be prepared to 1102 regularly update the set of algorithms in their implementations. 1104 Users of the CMS, particularly those employing the CMS to support 1105 interactive applications, should be aware that RSA (PKCS #1 v1.5), as 1106 specified in RFC 2313 [PKCS#1], is vulnerable to adaptive chosen 1107 ciphertext attacks when applied for encryption purposes. 1108 Exploitation of this identified vulnerability, revealing the result 1109 of a particular RSA decryption, requires access to an oracle which 1110 will respond to a large number of ciphertexts (based on currently 1111 available results, hundreds of thousands or more), which are 1112 constructed adaptively in response to previously-received replies 1113 providing information on the successes or failures of attempted 1114 decryption operations. As a result, the attack appears significantly 1115 less feasible to perpetrate for store-and-forward S/MIME environments 1116 than for directly interactive protocols. Where the CMS constructs 1117 are applied as an intermediate encryption layer within an interactive 1118 request-response communications environment, exploitation could be 1119 more feasible. 1121 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 1122 [NEWPKCS#1]. This updated document supersedes RFC 2313. PKCS #1 1123 Version 2.0 preserves support for the encryption padding format 1124 defined in PKCS #1 Version 1.5 [PKCS#1], and it also defines a new 1125 alternative. To resolve the adaptive chosen ciphertext 1126 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 1127 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 1128 is used to provide confidentiality. Designers of protocols and 1129 systems employing CMS for interactive environments should either 1130 consider usage of OAEP, or should ensure that information which could 1131 reveal the success or failure of attempted PKCS #1 Version 1.5 1132 decryption operations is not provided. Support for OAEP will likely 1133 be added to a future version of the CMS algorithm specification. 1135 See RFC [MMA] for more information about thwarting the adaptive 1136 chosen ciphertext vulnerability in PKCS #1 Version 1.5 1137 implementations. 1139 Acknowledgments 1141 This document is the result of contributions from many professionals. 1142 I appreciate the hard work of all members of the IETF S/MIME Working 1143 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 1144 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 1145 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 1146 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 1147 Jim Schaad, and Dave Solo for their efforts and support. 1149 Author Address 1151 Russell Housley 1152 RSA Laboratories 1153 918 Spring Knoll Drive 1154 Herndon, VA 20170 1155 USA 1157 rhousley@rsasecurity.com 1159 Full Copyright Statement 1161 Copyright (C) The Internet Society (2001). All Rights Reserved. 1163 This document and translations of it may be copied and furnished to 1164 others, and derivative works that comment on or otherwise explain it 1165 or assist in its implementation may be prepared, copied, published 1166 and distributed, in whole or in part, without restriction of any 1167 kind, provided that the above copyright notice and this paragraph are 1168 included on all such copies and derivative works. In addition, the 1169 ASN.1 module presented in Appendix A may be used in whole or in part 1170 without inclusion of the copyright notice. However, this document 1171 itself may not be modified in any way, such as by removing the 1172 copyright notice or references to the Internet Society or other 1173 Internet organizations, except as needed for the purpose of 1174 developing Internet standards in which case the procedures for 1175 copyrights defined in the Internet Standards process shall be 1176 followed, or as required to translate it into languages other than 1177 English. 1179 The limited permissions granted above are perpetual and will not be 1180 revoked by the Internet Society or its successors or assigns. This 1181 document and the information contained herein is provided on an "AS 1182 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1183 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1184 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1185 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1186 OR FITNESS FOR A PARTICULAR PURPOSE.