idnits 2.17.1 draft-ietf-smime-cmsalg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 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 12 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 95: '... the algorithms that MUST be supported...' RFC 2119 keyword, line 96: '...t also lists algorithms that SHOULD be...' RFC 2119 keyword, line 97: '...s. Of course, CMS implementations MAY...' RFC 2119 keyword, line 100: '...ms that CMS implantations MUST support...' RFC 2119 keyword, line 101: '... and SHOULD support....' (62 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 (April 2001) is 8410 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 93, but not defined == Missing Reference: 'STDWORDS' is mentioned on line 114, but not defined == Missing Reference: 'SHA1' is mentioned on line 566, but not defined == Missing Reference: 'MD5' is mentioned on line 163, but not defined == Missing Reference: 'DSS' is mentioned on line 858, but not defined == Missing Reference: 'RC2' is mentioned on line 876, but not defined == Missing Reference: 'MMA' is mentioned on line 936, but not defined == Missing Reference: 'DES' is mentioned on line 465, but not defined == Missing Reference: 'HMAC' is mentioned on line 517, but not defined == Missing Reference: 'RANDOM' is mentioned on line 857, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '3DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group R. Housley 2 Internet Draft RSA Laboratories 3 expires in six months April 2001 5 Cryptographic Message Syntax (CMS) Algorithms 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This document describes cryptographic algorithms for use with the 37 Cryptographic Message Syntax (CMS) [CMS]. CMS is used to digitally 38 sign, digest, authenticate, or encrypt arbitrary messages. 40 Once approved, this draft will obsolete section 12 of RFC 2630. The 41 companion document (draft-ietf-smime-rfc2630bis-00.txt) will obsolete 42 the rest of RFC 2630. Separation of the protocol and algorithm 43 specifications allows the IETF to select different mandatory to 44 implement algorithms in the future without reissuing the protocol 45 document. 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 ................................................ 3 58 1 Introduction ................................................. 5 59 2 Message Digest Algorithms .................................... 35 60 2.1 SHA-1 ................................................. 35 61 2.2 MD5 ................................................... 35 62 3 Signature Algorithms ......................................... 36 63 3.1 DSA ................................................... 36 64 3.2 RSA ................................................... 36 65 4 Key Management Algorithms .................................... 36 66 4.1 Key Agreement Algorithms .............................. 36 67 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman ........ 37 68 4.2 Key Transport Algorithms .............................. 38 69 4.2.1 RSA .......................................... 39 70 4.3 Symmetric Key-Encryption Key Algorithms ............... 39 71 4.3.1 Triple-DES Key Wrap .......................... 40 72 4.3.2 RC2 Key Wrap ................................. 41 73 5 Content Encryption Algorithms ................................ 41 74 5.1 Triple-DES CBC ........................................ 42 75 5.2 RC2 CBC ............................................... 42 76 6 Message Authentication Code (MAC) Algorithms ................. 42 77 6.1 HMAC with SHA-1 ....................................... 43 78 7 Triple-DES and RC2 Key Wrap Algorithms ....................... 43 79 7.1 Key Checksum .......................................... 44 80 7.2 Triple-DES Key Wrap ................................... 44 81 7.3 Triple-DES Key Unwrap ................................. 44 82 7.4 RC2 Key Wrap .......................................... 45 83 7.5 RC2 Key Unwrap ........................................ 46 84 Appendix A: ASN.1 Module ........................................ 47 85 References ....................................................... 55 86 Security Considerations .......................................... 56 87 Acknowledgments .................................................. 58 88 Author's Address ................................................. 59 89 Full Copyright Statement ......................................... 60 91 1 Introduction 93 The Cryptographic Message Syntax (CMS) [CMS] is used to digitally 94 sign, digest, authenticate, or encrypt arbitrary messages. This 95 companion specification lists the algorithms that MUST be supported 96 by CMS implementations. It also lists algorithms that SHOULD be 97 supported by CMS implementations. Of course, CMS implementations MAY 98 support other algorithms as well. 100 Table 1 summarizes the algorithms that CMS implantations MUST support 101 and SHOULD support. 103 The CMS values are generated using ASN.1 [X.208-88], using BER- 104 encoding [X.209-88]. Algorithm are be identified by algorithm 105 identifiers (ASN.1 object identifiers), and some algorithms require 106 additional parameters. When needed, parameters are specified with an 107 ASN.1 structure. The algorithm identifiers for each algorithm are 108 specified, and, when needed, the parameter structure is specified. 109 The fields in the CMS employed by each algorithm are identified. 111 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 112 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 113 described by Scott Bradner in [STDWORDS]. 115 Table 1. CMS Implantation Algorithm Requirements 117 Algorithm Type MUST implement SHOULD implement 118 ----------------------------------------------------------------- 119 Message Digest SHA-1 MD5 120 Signature DSA and RSA (*) -- 121 Key Management 122 Key Agreement -- X9.42 E-S D-H 123 Key Transport RSA -- 124 Symmetric KEK Wrap Triple-DES Key Wrap RC2 Key Wrap 125 Content Encryption Triple-DES CBC RC2 CBC 126 Message Authentication HMAC with SHA-1 -- 128 (*) Note: CMS implementations MUST be able to verify signatures 129 with both DSA and RSA, and they MUST be able to 130 generate signatures with at least one of them. 132 2 Message Digest Algorithms 134 CMS implementations MUST support SHA-1. CMS implementations SHOULD 135 support MD5. 137 Digest algorithm identifiers are located in the SignedData 138 digestAlgorithms field, the SignerInfo digestAlgorithm field, the 139 DigestedData digestAlgorithm field, and the AuthenticatedData 140 digestAlgorithm field. 142 Digest values are located in the DigestedData digest field, and 143 digest values are located in the Message Digest authenticated 144 attribute. In addition, digest values are input to signature 145 algorithms. 147 2.1 SHA-1 149 The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [SHA1]. The 150 algorithm identifier for SHA-1 is: 152 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 153 oiw(14) secsig(3) algorithm(2) 26 } 155 The AlgorithmIdentifier parameters field is OPTIONAL. If present, 156 the parameters field MUST contain an ASN.1 NULL. Implementations 157 SHOULD accept SHA-1 AlgorithmIdentifiers with absent parameters as 158 well as NULL parameters. Implementations SHOULD generate SHA-1 159 AlgorithmIdentifiers with NULL parameters. 161 2.2 MD5 163 The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm 164 identifier for MD5 is: 166 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 167 rsadsi(113549) digestAlgorithm(2) 5 } 169 The AlgorithmIdentifier parameters field MUST be present, and the 170 parameters field MUST contain NULL. Implementations MAY accept the 171 MD5 AlgorithmIdentifiers with absent parameters as well as NULL 172 parameters. 174 3 Signature Algorithms 176 CMS implementations MUST support both DSA and RSA. CMS 177 implementations MUST be able to verify signatures with both DSA and 178 RSA. CMS implementations MUST be able to generate signatures with 179 either DSA or RSA. CMS implementations MAY be able to generate 180 signatures with both DSA and RSA. 182 Signature algorithm identifiers are located in the SignerInfo 183 signatureAlgorithm field. Also, signature algorithm identifiers are 184 located in the SignerInfo signatureAlgorithm field of 185 countersignature attributes. 187 Signature values are located in the SignerInfo signature field. 188 Also, signature values are located in the SignerInfo signature field 189 of countersignature attributes. 191 3.1 DSA 193 The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is 194 always used with the SHA-1 message digest algorithm. The algorithm 195 identifier for DSA is: 197 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 198 us(840) x9-57 (10040) x9cm(4) 3 } 200 The AlgorithmIdentifier parameters field MUST NOT be present. 202 3.2 RSA 204 The RSA signature algorithm is defined in RFC 2437 [NEWPKCS#1]. RFC 205 2437 specifies the use of the RSA signature algorithm with the SHA-1 206 and MD5 message digest algorithms. The algorithm identifier for RSA 207 is: 209 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 210 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 212 CMS implementations MUST support RSA with SHA-1. CMS implementations 213 SHOULD support RSA with MD5. 215 4 Key Management Algorithms 217 CMS accommodates three general key management techniques: key 218 agreement, key transport, and previously distributed symmetric key- 219 encryption keys. 221 4.1 Key Agreement Algorithms 223 CMS implementations SHOULD support key agreement using X9.42 224 Ephemeral-Static Diffie-Hellman (X9.42 E-S D-H). 226 Any symmetric encryption algorithm that a CMS implementation includes 227 as a content-encryption algorithm MUST also be included as a key- 228 encryption algorithm. CMS implementations SHOULD include key 229 agreement of Triple-DES pairwise key-encryption keys. CMS 230 implementations SHOULD include key agreement of RC2 pairwise key- 231 encryption keys. CMS implementations MUST include Triple-DES 232 wrapping of Triple-DES content-encryption keys and RC2 wrapping of 233 RC2 content-encryption keys. The key wrap algorithms for Triple-DES 234 and RC2 are described in section 7. 236 A CMS implementation MAY support mixed key-encryption and content- 237 encryption algorithms. For example, a 128-bit RC2 content-encryption 238 key MAY be wrapped with 168-bit Triple-DES key-encryption key. 239 Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with 240 128-bit RC2 key-encryption key. 242 For key agreement of RC2 key-encryption keys, 128 bits MUST be 243 generated as input to the key expansion process used to compute the 244 RC2 effective key [RC2]. 246 Key agreement algorithm identifiers are located in the EnvelopedData 247 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 248 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 249 keyEncryptionAlgorithm fields. 251 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 252 parameters within the EnvelopedData RecipientInfos 253 KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData 254 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 256 Wrapped content-encryption keys are located in the EnvelopedData 257 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 258 encryptedKey field. Wrapped message-authentication keys are located 259 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 260 RecipientEncryptedKeys encryptedKey field. 262 4.1.1 X9.42 Ephemeral-Static Diffie-Hellman 264 Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631 265 [DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the 266 EnvelopedData RecipientInfos KeyAgreeRecipientInfo and 267 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are 268 used as follows: 270 version MUST be 3. 272 originator MUST be the originatorKey alternative. The 273 originatorKey algorithm field MUST contain the dh-public-number 274 object identifier with absent parameters. The originatorKey 275 publicKey field MUST contain the sender's ephemeral public key. 277 The dh-public-number object identifier is: 279 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 280 us(840) ansi-x942(10046) number-type(2) 1 } 282 ukm MAY be absent. When present, the ukm is used to ensure that a 283 different key-encryption key is generated when the ephemeral 284 private key might be used more than once. 286 keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm 287 identifier. The algorithm identifier parameter field for id-alg- 288 ESDH is KeyWrapAlgorihtm, and this parameter MUST be present. The 289 KeyWrapAlgorithm denotes the symmetric encryption algorithm used 290 to encrypt the content-encryption key with the pairwise key- 291 encryption key generated using the X9.42 Ephemeral-Static Diffie- 292 Hellman key agreement algorithm. Triple-DES and RC2 key wrap 293 algorithms are discussed in section 7. The id-alg-ESDH algorithm 294 identifier and parameter syntax is: 296 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 297 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 299 KeyWrapAlgorithm ::= AlgorithmIdentifier 301 recipientEncryptedKeys contains an identifier and an encrypted key 302 for each recipient. The RecipientEncryptedKey 303 KeyAgreeRecipientIdentifier MUST contain either the 304 issuerAndSerialNumber identifying the recipient's certificate or 305 the RecipientKeyIdentifier containing the subject key identifier 306 from the recipient's certificate. In both cases, the recipient's 307 certificate contains the recipient's static public key. 308 RecipientEncryptedKey EncryptedKey MUST contain the content- 309 encryption key encrypted with the X9.42 Ephemeral-Static Diffie- 310 Hellman generated pairwise key-encryption key using the algorithm 311 specified by the KeyWrapAlgortihm. 313 4.2 Key Transport Algorithms 315 CMS implementations MUST support key transport using RSA. RSA 316 implementations MUST support key transport of Triple-DES content- 317 encryption keys. RSA implementations SHOULD support key transport of 318 RC2 content-encryption keys. 320 Key transport algorithm identifiers are located in the EnvelopedData 321 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and 322 AuthenticatedData RecipientInfos KeyTransRecipientInfo 323 keyEncryptionAlgorithm fields. 325 Key transport encrypted content-encryption keys are located in the 326 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 327 field. Key transport encrypted message-authentication keys are 328 located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo 329 encryptedKey field. 331 4.2.1 RSA 333 The RSA key transport algorithm is the RSA encryption scheme defined 334 in RFC 2313 [PKCS#1], block type is 02, where the message to be 335 encrypted is the content-encryption key. The algorithm identifier 336 for RSA is: 338 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 339 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 341 The AlgorithmIdentifier parameters field must be present, and the 342 parameters field must contain NULL. 344 When using a Triple-DES content-encryption key, CMS implementations 345 MUST adjust the parity bits for each DES key comprising the Triple- 346 DES key prior to RSA encryption. 348 The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to 349 provide confidentiality has a known vulnerability. The vulnerability 350 is primarily relevant to usage in interactive applications rather 351 than to store-and-forward environments. Further information and 352 proposed countermeasures are discussed in the Security Considerations 353 section of this document and RFC [MMA]. 355 Note that the same encryption scheme is also defined in RFC 2437 356 [NEWPKCS#1]. Within RFC 2437, this scheme is called RSAES- 357 PKCS1-v1_5. 359 4.3 Symmetric Key-Encryption Key Algorithms 361 CMS implementations MUST support symmetric key-encryption key 362 management. CMS implementations MUST include Triple-DES key- 363 encryption keys wrapping Triple-DES content-encryption keys. CMS 364 implementations SHOULD include RC2 key-encryption keys wrapping RC2 365 content-encryption keys. RC2 128-bit keys MUST be used as key- 366 encryption keys, and they MUST be used with the RC2ParameterVersion 367 parameter set to 58. A CMS implementation MAY support mixed key- 368 encryption and content-encryption algorithms. For example, a 40-bit 369 RC2 content-encryption key MAY be wrapped with 168-bit Triple-DES 370 key-encryption key or with a 128-bit RC2 key-encryption key. 372 Key wrap algorithm identifiers are located in the EnvelopedData 373 RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and 374 AuthenticatedData RecipientInfos KEKRecipientInfo 375 keyEncryptionAlgorithm fields. 377 Wrapped content-encryption keys are located in the EnvelopedData 378 RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- 379 authentication keys are located in the AuthenticatedData 380 RecipientInfos KEKRecipientInfo encryptedKey field. 382 The output of a key agreement algorithm is a key-encryption key, and 383 this key-encryption key is used to encrypt the content-encryption 384 key. In conjunction with key agreement algorithms, CMS 385 implementations MUST include encryption of content-encryption keys 386 with the pairwise key-encryption key generated using a key agreement 387 algorithm. To support key agreement, key wrap algorithm identifiers 388 are located in the KeyWrapAlgorithm parameter of the EnvelopedData 389 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 390 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 391 keyEncryptionAlgorithm fields. Wrapped content-encryption keys are 392 located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo 393 RecipientEncryptedKeys encryptedKey field, wrapped message- 394 authentication keys are located in the AuthenticatedData 395 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 396 encryptedKey field. 398 4.3.1 Triple-DES Key Wrap 400 Triple-DES key encryption has the algorithm identifier: 402 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 403 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 405 The AlgorithmIdentifier parameter field MUST be NULL. 407 The key wrap algorithm used to encrypt a Triple-DES content- 408 encryption key with a Triple-DES key-encryption key is specified in 409 section 7.2. The corresponding key unwrap algorithm is specified in 410 section 7.3. 412 Out-of-band distribution of the Triple-DES key-encryption key used to 413 encrypt the Triple-DES content-encryption key is beyond of the scope 414 of this document. 416 4.3.2 RC2 Key Wrap 418 RC2 key encryption has the algorithm identifier: 420 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 421 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 423 The AlgorithmIdentifier parameter field must be RC2wrapParameter: 425 RC2wrapParameter ::= RC2ParameterVersion 427 RC2ParameterVersion ::= INTEGER 429 The RC2 effective-key-bits (key size) greater than 32 and less than 430 256 is encoded in the RC2ParameterVersion. For the effective-key- 431 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 432 and 58 respectively. These values are not simply the RC2 key length. 433 Note that the value 160 must be encoded as two octets (00 A0), 434 because the one octet (A0) encoding represents a negative number. 436 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST 437 be used with the RC2ParameterVersion parameter set to 58. 439 The key wrap algorithm used to encrypt a RC2 content-encryption key 440 with a RC2 key-encryption key is specified in section 7.4. The 441 corresponding key unwrap algorithm is specified in section 7.5. 443 Out-of-band distribution of the RC2 key-encryption key used to 444 encrypt the RC2 content-encryption key is beyond of the scope of this 445 document. 447 5 Content Encryption Algorithms 449 CMS implementations MUST support Three-Key Triple-DES in CBC mode. 450 MS implementations SHOULD support Two-Key Triple-DES in CBC mode. 451 CMS implementations SHOULD support RC2 in CBC mode. 453 Content encryption algorithms identifiers are located in the 454 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 455 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 457 Content encryption algorithms are used to encipher the content 458 located in the EnvelopedData EncryptedContentInfo encryptedContent 459 field and the EncryptedData EncryptedContentInfo encryptedContent 460 field. 462 5.1 Triple-DES CBC 464 The Triple-DES algorithm is described in ANSI X9.52 [3DES]. The 465 Triple-DES is composed from three sequential DES [DES] operations: 466 encrypt, decrypt, and encrypt. Three-Key Triple-DES uses a different 467 key for each DES operation. Two-Key Triple-DES uses one key for the 468 two encrypt operations and different key for the decrypt operation. 469 The same algorithm identifiers are used for Three-Key Triple-DES and 470 Two-Key Triple-DES. The algorithm identifier for Triple-DES in 471 Cipher Block Chaining (CBC) mode is: 473 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 474 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 476 The AlgorithmIdentifier parameters field MUST be present, and the 477 parameters field must contain a CBCParameter: 479 CBCParameter ::= IV 481 IV ::= OCTET STRING -- exactly 8 octets 483 5.2 RC2 CBC 485 The RC2 algorithm is described in RFC 2268 [RC2]. The algorithm 486 identifier for RC2 in CBC mode is: 488 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 489 rsadsi(113549) encryptionAlgorithm(3) 2 } 491 The AlgorithmIdentifier parameters field MUST be present, and the 492 parameters field MUST contain a RC2CBCParameter: 494 RC2CBCParameter ::= SEQUENCE { 495 rc2ParameterVersion INTEGER, 496 iv OCTET STRING } -- exactly 8 octets 498 The RC2 effective-key-bits (key size) greater than 32 and less than 499 256 is encoded in the rc2ParameterVersion. For the effective-key- 500 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 501 and 58 respectively. These values are not simply the RC2 key length. 502 Note that the value 160 must be encoded as two octets (00 A0), since 503 the one octet (A0) encoding represents a negative number. 505 6 Message Authentication Code Algorithms 507 CMS implementations that support authenticatedData MUST support HMAC 508 with SHA-1. 510 MAC algorithm identifiers are located in the AuthenticatedData 511 macAlgorithm field. 513 MAC values are located in the AuthenticatedData mac field. 515 6.1 HMAC with SHA-1 517 The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The 518 algorithm identifier for HMAC with SHA-1 is: 520 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 521 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 523 The AlgorithmIdentifier parameters field must be absent. 525 7 Triple-DES and RC2 Key Wrap Algorithms 527 CMS implementations MUST include encryption of a Triple-DES content- 528 encryption key with a Triple-DES key-encryption key using the 529 algorithm specified in Sections 7.2 and 7.3. CMS implementations 530 SHOULD include encryption of a RC2 content-encryption key with a RC2 531 key-encryption key using the algorithm specified in Sections 7.4 and 532 7.5. Triple-DES and RC2 content-encryption keys are encrypted in 533 Cipher Block Chaining (CBC) mode [MODES]. 535 Key Transport algorithms allow for the content-encryption key to be 536 directly encrypted; however, key agreement and symmetric key- 537 encryption key algorithms encrypt the content-encryption key with a 538 second symmetric encryption algorithm. This section describes how 539 the Triple-DES or RC2 content-encryption key is formatted and 540 encrypted. 542 Key agreement algorithms generate a pairwise key-encryption key, and 543 a key wrap algorithm is used to encrypt the content-encryption key 544 with the pairwise key-encryption key. Similarly, a key wrap 545 algorithm is used to encrypt the content-encryption key in a 546 previously distributed key-encryption key. 548 The key-encryption key is generated by the key agreement algorithm or 549 distributed out of band. For key agreement of RC2 key-encryption 550 keys, 128 bits MUST be generated as input to the key expansion 551 process used to compute the RC2 effective key [RC2]. 553 The same algorithm identifier is used for both Two-key Triple-DES and 554 Three-key Triple-DES. When the length of the content-encryption key 555 to be wrapped is a Two-key Triple-DES key, a third key with the same 556 value as the first key is created. Thus, all Triple-DES content- 557 encryption keys are wrapped like Three-key Triple-DES keys. However, 558 a Two-key Triple-DES key MUST NOT be used to wrap a Three-key Triple- 559 DES key. 561 7.1 Key Checksum 563 The CMS Checksum Algorithm is used to provide a content-encryption 564 key integrity check value. The algorithm is: 566 1. Compute a 20 octet SHA-1 [SHA1] message digest on the 567 content-encryption key. 568 2. Use the most significant (first) eight octets of the message 569 digest value as the checksum value. 571 7.2 Triple-DES Key Wrap 573 The Triple-DES key wrap algorithm encrypts a Triple-DES content- 574 encryption key with a Triple-DES key-encryption key. The Triple-DES 575 key wrap algorithm is: 577 1. Set odd parity for each of the DES key octets comprising 578 the content-encryption key, call the result CEK. 579 2. Compute an 8 octet key checksum value on CEK as described above 580 in Section 12.6.1, call the result ICV. 581 3. Let CEKICV = CEK || ICV. 582 4. Generate 8 octets at random, call the result IV. 583 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use 584 the random value generated in the previous step as the 585 initialization vector (IV). Call the ciphertext TEMP1. 586 6. Let TEMP2 = IV || TEMP1. 587 7. Reverse the order of the octets in TEMP2. That is, the most 588 significant (first) octet is swapped with the least significant 589 (last) octet, and so on. Call the result TEMP3. 590 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 591 an initialization vector (IV) of 0x4adda22c79e82105. 592 The ciphertext is 40 octets long. 594 Note: When the same content-encryption key is wrapped in different 595 key-encryption keys, a fresh initialization vector (IV) must be 596 generated for each invocation of the key wrap algorithm. 598 7.3 Triple-DES Key Unwrap 600 The Triple-DES key unwrap algorithm decrypts a Triple-DES content- 601 encryption key using a Triple-DES key-encryption key. The Triple-DES 602 key unwrap algorithm is: 604 1. If the wrapped content-encryption key is not 40 octets, then 605 error. 606 2. Decrypt the wrapped content-encryption key in CBC mode using 607 the key-encryption key. Use an initialization vector (IV) 608 of 0x4adda22c79e82105. Call the output TEMP3. 609 3. Reverse the order of the octets in TEMP3. That is, the most 610 significant (first) octet is swapped with the least significant 611 (last) octet, and so on. Call the result TEMP2. 612 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 613 significant (first) 8 octets, and TEMP1 is the least significant 614 (last) 32 octets. 615 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 616 the IV value from the previous step as the initialization vector. 617 Call the ciphertext CEKICV. 618 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant 619 (first) 24 octets, and ICV is the least significant (last) 8 octets. 620 7. Compute an 8 octet key checksum value on CEK as described above 621 in Section 12.6.1. If the computed key checksum value does not 622 match the decrypted key checksum value, ICV, then error. 623 8. Check for odd parity each of the DES key octets comprising CEK. 624 If parity is incorrect, then there is an error. 625 9. Use CEK as the content-encryption key. 627 7.4 RC2 Key Wrap 629 The RC2 key wrap algorithm encrypts a RC2 content-encryption key with 630 a RC2 key-encryption key. The RC2 key wrap algorithm is: 632 1. Let the content-encryption key be called CEK, and let the length 633 of the content-encryption key in octets be called LENGTH. LENGTH 634 is a single octet. 635 2. Let LCEK = LENGTH || CEK. 636 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple 637 of 8, the PAD has a length of zero. If the length of LCEK is 638 not a multiple of 8, then PAD contains the fewest number of 639 random octets to make the length of LCEKPAD a multiple of 8. 640 4. Compute an 8 octet key checksum value on LCEKPAD as described 641 above in Section 12.6.1, call the result ICV. 642 5. Let LCEKPADICV = LCEKPAD || ICV. 643 6. Generate 8 octets at random, call the result IV. 644 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. 645 Use the random value generated in the previous step as the 646 initialization vector (IV). Call the ciphertext TEMP1. 647 8. Let TEMP2 = IV || TEMP1. 648 9. Reverse the order of the octets in TEMP2. That is, the most 649 significant (first) octet is swapped with the least significant 650 (last) octet, and so on. Call the result TEMP3. 651 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 652 an initialization vector (IV) of 0x4adda22c79e82105. 654 Note: When the same content-encryption key is wrapped in different 655 key-encryption keys, a fresh initialization vector (IV) must be 656 generated for each invocation of the key wrap algorithm. 658 7.5 RC2 Key Unwrap 660 The RC2 key unwrap algorithm decrypts a RC2 content-encryption key 661 using a RC2 key-encryption key. The RC2 key unwrap algorithm is: 663 1. If the wrapped content-encryption key is not a multiple of 8 664 octets, then error. 665 2. Decrypt the wrapped content-encryption key in CBC mode using 666 the key-encryption key. Use an initialization vector (IV) 667 of 0x4adda22c79e82105. Call the output TEMP3. 668 3. Reverse the order of the octets in TEMP3. That is, the most 669 significant (first) octet is swapped with the least significant 670 (last) octet, and so on. Call the result TEMP2. 671 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 672 significant (first) 8 octets, and TEMP1 is the remaining octets. 673 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 674 the IV value from the previous step as the initialization vector. 675 Call the plaintext LCEKPADICV. 676 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the 677 least significant (last) octet 8 octets. LCEKPAD is the 678 remaining octets. 679 7. Compute an 8 octet key checksum value on LCEKPAD as described 680 above in Section 12.6.1. If the computed key checksum value 681 does not match the decrypted key checksum value, ICV, then error. 682 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the 683 most significant (first) octet. CEK is the following LENGTH 684 octets. PAD is the remaining octets, if any. 685 9. If the length of PAD is more than 7 octets, then error. 686 10. Use CEK as the content-encryption key. 688 Appendix A: ASN.1 Module 690 CryptographicMessageSyntaxAlgorithms 691 { iso(1) member-body(2) us(840) rsadsi(113549) 692 pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) } 694 DEFINITIONS IMPLICIT TAGS ::= 695 BEGIN 697 -- EXPORTS All 698 -- The types and values defined in this module are exported for use in 699 -- the other ASN.1 modules. Other applications may use them for their 700 -- own purposes. 702 -- IMPORTS None 704 -- Algorithm Identifiers 706 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 707 oiw(14) secsig(3) algorithm(2) 26 } 709 md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 710 rsadsi(113549) digestAlgorithm(2) 5 } 712 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) 713 us(840) x9-57 (10040) x9cm(4) 3 } 715 rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 716 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 718 dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) 719 us(840) ansi-x942(10046) number-type(2) 1 } 721 id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 722 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } 724 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 725 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 727 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 728 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 730 des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) 731 us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } 733 rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 734 rsadsi(113549) encryptionAlgorithm(3) 2 } 736 hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 737 dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } 739 -- Algorithm Parameters 741 KeyWrapAlgorithm ::= AlgorithmIdentifier 743 RC2wrapParameter ::= RC2ParameterVersion 745 RC2ParameterVersion ::= INTEGER 747 CBCParameter ::= IV 749 IV ::= OCTET STRING -- exactly 8 octets 751 RC2CBCParameter ::= SEQUENCE { 752 rc2ParameterVersion INTEGER, 753 iv OCTET STRING } -- exactly 8 octets 755 END -- of CryptographicMessageSyntaxAlgorithms 757 References 759 3DES American National Standards Institute. ANSI X9.52-1998, 760 Triple Data Encryption Algorithm Modes of Operation. 1998. 762 CMS Housley, R. Cryptographic Message Syntax. RFC . . 763 {draft-ietf-smime-rfc2630bis-*.txt} 765 DES American National Standards Institute. ANSI X3.106, 766 "American National Standard for Information Systems - Data 767 Link Encryption". 1983. 769 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 770 RFC 2631. June 1999. 772 DSS National Institute of Standards and Technology. 773 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 775 HMAC Krawczyk, H. HMAC: Keyed-Hashing for Message Authentication. 776 RFC 2104. February 1997. 778 MD5 Rivest, R. The MD5 Message-Digest Algorithm. RFC 1321. 779 April 1992. 781 MMA Rescorla, E. Preventing the Million Message Attack on CMS. 782 RFC . . {draft-ietf-smime-pkcs1-*.txt} 784 MODES National Institute of Standards and Technology. 785 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 787 NEWPKCS#1 Kaliski, B., and J. Staddon. PKCS #1: RSA Encryption, 788 Version 2.0. RFC 2437. October 1998. 790 PKCS#1 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 791 RFC 2313. March 1998. 793 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 794 Recommendations for Security. RFC 1750. December 1994. 796 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 797 RFC 2268. March 1998. 799 SHA1 National Institute of Standards and Technology. 800 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 802 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 803 Requirement Levels. RFC2119. March 1997. 805 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 806 Syntax Notation One (ASN.1). 1988. 808 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 809 Rules for Abstract Syntax Notation One (ASN.1). 1988. 811 Security Considerations 813 The CMS provides a method for digitally signing data, digesting data, 814 encrypting data, and authenticating data. This document identifies 815 the cryptographic algorithms for use with CMS. 817 Implementations must protect the signer's private key. Compromise of 818 the signer's private key permits masquerade. 820 Implementations must protect the key management private key, the key- 821 encryption key, and the content-encryption key. Compromise of the 822 key management private key or the key-encryption key may result in 823 the disclosure of all messages protected with that key. Similarly, 824 compromise of the content-encryption key may result in disclosure of 825 the associated encrypted content. 827 Implementations must protect the key management private key and the 828 message-authentication key. Compromise of the key management private 829 key permits masquerade of authenticated data. Similarly, compromise 830 of the message-authentication key may result in undetectable 831 modification of the authenticated content. 833 The key management technique employed to distribute message- 834 authentication keys must itself provide data origin authentication, 835 otherwise the message content is delivered with integrity from an 836 unknown source. Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static 837 Diffie-Hellman [DH-X9.42] provide the necessary data origin 838 authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide 839 the necessary data origin authentication when both the originator and 840 recipient public keys are bound to appropriate identities in X.509 841 certificates. 843 When more than two parties share the same message-authentication key, 844 data origin authentication is not provided. Any party that knows the 845 message-authentication key can compute a valid MAC, therefore the 846 message could originate from any one of the parties. 848 Implementations must randomly generate content-encryption keys, 849 message-authentication keys, initialization vectors (IVs), and 850 padding. Also, the generation of public/private key pairs relies on 851 a random numbers. The use of inadequate pseudo-random number 852 generators (PRNGs) to generate cryptographic keys can result in 853 little or no security. An attacker may find it much easier to 854 reproduce the PRNG environment that produced the keys, searching the 855 resulting small set of possibilities, rather than brute force 856 searching the whole key space. The generation of quality random 857 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 858 this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 859 PRNG technique. 861 When using key agreement algorithms or previously distributed 862 symmetric key-encryption keys, a key-encryption key is used to 863 encrypt the content-encryption key. If the key-encryption and 864 content-encryption algorithms are different, the effective security 865 is determined by the weaker of the two algorithms. If, for example, 866 a message content is encrypted with 168-bit Triple-DES and the 867 Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, 868 then at most 40 bits of protection is provided. A trivial search to 869 determine the value of the 40-bit RC2 key can recover Triple-DES key, 870 and then the Triple-DES key can be used to decrypt the content. 871 Therefore, implementers must ensure that key-encryption algorithms 872 are as strong or stronger than content-encryption algorithms. 874 Section 7 specifies key wrap algorithms used to encrypt a Triple-DES 875 [3DES] content-encryption key with a Triple-DES key-encryption key or 876 to encrypt a RC2 [RC2] content-encryption key with a RC2 key- 877 encryption key. The key wrap algorithms make use of CBC mode 878 [MODES]. These key wrap algorithms have been reviewed for use with 879 Triple-DES and RC2. They have not been reviewed for use with other 880 cryptographic modes or other encryption algorithms. Therefore, if a 881 CMS implementation wishes to support ciphers in addition to Triple- 882 DES or RC2, then additional key wrap algorithms need to be defined to 883 support the additional ciphers. 885 Implementers should be aware that cryptographic algorithms become 886 weaker with time. As new cryptoanalysis techniques are developed and 887 computing performance improves, the work factor to break a particular 888 cryptographic algorithm will reduce. Therefore, cryptographic 889 algorithm implementations should be modular allowing new algorithms 890 to be readily inserted. That is, implementers should be prepared for 891 the set of mandatory to implement algorithms to change over time. 893 The countersignature unauthenticated attribute includes a digital 894 signature that is computed on the content signature value, thus the 895 countersigning process need not know the original signed content. 896 This structure permits implementation efficiency advantages; however, 897 this structure may also permit the countersigning of an inappropriate 898 signature value. Therefore, implementations that perform 899 countersignatures should either verify the original signature value 900 prior to countersigning it (this verification requires processing of 901 the original content), or implementations should perform 902 countersigning in a context that ensures that only appropriate 903 signature values are countersigned. 905 Users of CMS, particularly those employing CMS to support interactive 906 applications, should be aware that PKCS #1 Version 1.5 as specified 907 in RFC 2313 [PKCS#1] is vulnerable to adaptive chosen ciphertext 908 attacks when applied for encryption purposes. Exploitation of this 909 identified vulnerability, revealing the result of a particular RSA 910 decryption, requires access to an oracle which will respond to a 911 large number of ciphertexts (based on currently available results, 912 hundreds of thousands or more), which are constructed adaptively in 913 response to previously-received replies providing information on the 914 successes or failures of attempted decryption operations. As a 915 result, the attack appears significantly less feasible to perpetrate 916 for store-and-forward S/MIME environments than for directly 917 interactive protocols. Where CMS constructs are applied as an 918 intermediate encryption layer within an interactive request-response 919 communications environment, exploitation could be more feasible. 921 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 922 [NEWPKCS#1]. This new document supersedes RFC 2313. PKCS #1 Version 923 2.0 preserves support for the encryption padding format defined in 924 PKCS #1 Version 1.5 [PKCS#1], and it also defines a new alternative. 926 To resolve the adaptive chosen ciphertext vulnerability, the PKCS #1 927 Version 2.0 specifies and recommends use of Optimal Asymmetric 928 Encryption Padding (OAEP) when RSA encryption is used to provide 929 confidentiality. Designers of protocols and systems employing CMS 930 for interactive environments should either consider usage of OAEP, or 931 should ensure that information which could reveal the success or 932 failure of attempted PKCS #1 Version 1.5 decryption operations is not 933 provided. Support for OAEP will likely be added to a future version 934 of the CMS algorithm specification. 936 See RFC [MMA] for more information about thwarting the adaptive 937 chosen ciphertext vulnerability in PKCS #1 Version 1.5 938 implementations. 940 Acknowledgments 942 This document is the result of contributions from many professionals. 943 I appreciate the hard work of all members of the IETF S/MIME Working 944 Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, 945 Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, 946 Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt 947 Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, 948 Jim Schaad, and Dave Solo for their efforts and support. 950 Author Address 952 Russell Housley 953 RSA Laboratories 954 918 Spring Knoll Drive 955 Herndon, VA 20170 956 USA 958 rhousley@rsasecurity.com 960 Full Copyright Statement 962 Copyright (C) The Internet Society (2001). All Rights Reserved. 964 This document and translations of it may be copied and furnished to 965 others, and derivative works that comment on or otherwise explain it 966 or assist in its implementation may be prepared, copied, published 967 and distributed, in whole or in part, without restriction of any 968 kind, provided that the above copyright notice and this paragraph are 969 included on all such copies and derivative works. In addition, the 970 ASN.1 module presented in Appendix A may be used in whole or in part 971 without inclusion of the copyright notice. However, this document 972 itself may not be modified in any way, such as by removing the 973 copyright notice or references to the Internet Society or other 974 Internet organizations, except as needed for the purpose of 975 developing Internet standards in which case the procedures for 976 copyrights defined in the Internet Standards process shall be 977 followed, or as required to translate it into languages other than 978 English. 980 The limited permissions granted above are perpetual and will not be 981 revoked by the Internet Society or its successors or assigns. This 982 document and the information contained herein is provided on an "AS 983 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 984 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 985 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 986 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 987 OR FITNESS FOR A PARTICULAR PURPOSE.