idnits 2.17.1 draft-ietf-smime-aes-alg-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 3) being 66 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 abstract seems to contain references ([AES], [CMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 2003) is 7762 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 section? 'AES' on line 410 looks like a reference -- Missing reference section? 'CMS' on line 393 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 43 looks like a reference -- Missing reference section? 'DES' on line 58 looks like a reference -- Missing reference section? 'DH' on line 213 looks like a reference -- Missing reference section? 'RSA-OAEP' on line 410 looks like a reference -- Missing reference section? 'CMSALG' on line 414 looks like a reference -- Missing reference section? 'AES-WRAP' on line 320 looks like a reference -- Missing reference section? 'SYMKEYDIST' on line 346 looks like a reference -- Missing reference section? 'MSG' on line 448 looks like a reference -- Missing reference section? 'RANDOM' on line 502 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group J. Schaad 3 Internet Draft Soaring Hawk Consulting 4 Document: draft-ietf-smime-aes-alg-06.txt 5 Expires: July 2003 January 2003 7 Use of the AES Encryption Algorithm in CMS 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 RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Comments or suggestions for improvement may be made on the "ietf- 29 smime" mailing list, or directly to the author. 31 Abstract 33 This document specifies the conventions for using the Advanced 34 Encryption Standard (AES) algorithm [AES] for encryption with the 35 Cryptographic Message Syntax (CMS) [CMS]. 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in RFC 2119 42 [MUSTSHOULD]. 44 1 Overview 46 This document specifies the conventions for using Advanced Encryption 48 Standard (AES) content encryption algorithm with the Cryptographic 49 Message Syntax [CMS] enveloped-data and encrypted-data content types. 51 CMS values are generated using ASN.1 [X.208-88], using the Basic 52 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 53 (DER) [X.509-88]. 55 1.1 AES 56 The Advanced Encryption Standard (AES) [AES] was developed to replace 58 DES [DES]. The AES Federal Information Processing Standard (FIPS) 59 Publication specifies a cryptographic algorithm for use by U.S. 60 Government organizations. However, the AES will also be widely used 61 by organizations, institutions, and individuals outside of the U.S. 62 Government. 64 Two researchers who developed and submitted the Rijndael algorithm 65 for consideration are both cryptographers from Belgium: Dr. Joan 66 Daemen of Proton World International and Dr. Vincent Rijmen, a 67 postdoctoral researcher in the Electrical Engineering Department of 68 Katholieke Universiteit Leuven. 70 The National Institute of Standards and technology (NIST) selected 71 the Rijndael algorithm for AES because it offers a combination of 72 security, performance, efficiency, ease of implementation, and 73 flexibility. Specifically, Rijndael appears to be consistently a 74 very good performer in both hardware and software across a wide range 76 of computing environments regardless of its use in feedback or non- 77 feedback modes. Its key setup time is excellent, and its key agility 79 is good. The very low memory requirements of the Rijndael algorithm 80 make it very well suited for restricted-space environments, in which 81 it also demonstrates excellent performance. The Rijndael algorithm 82 operations are among the easiest to defend against power and timing 83 attacks. Additionally, it appears that some defense can be provided 84 against such attacks without significantly impacting the algorithm's 85 performance. Finally, the algorithm's internal round structure 86 appears to have good potential to benefit from instruction-level 87 parallelism. 89 The AES specifies three key sizes: 128, 192 and 256 bits. 91 2 Enveloped-data Conventions 93 The CMS enveloped-data content type consists of encrypted content and 95 wrapped content-encryption keys for one or more recipients. The AES 96 algorithm is used to encrypt the content. 98 Compliant software MUST meet the requirements for constructing an 99 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 100 data Content Type". 102 The AES content-encryption key MUST be randomly generated for each 103 instance of an enveloped-data content type. The content-encryption 104 key (CEK) is used to encrypt the content. 106 AES can be used with the enveloped-data content type using any of the 108 following key management techniques defined in [CMS] Section 6. 110 1) Key Transport: The AES CEK is uniquely wrapped for each recipient 111 using the recipient's public RSA key and other values. Section 2.2 112 provides additional details. 114 Schaad 2 115 2) Key Agreement: The AES CEK is uniquely wrapped for each recipient 116 using a pairwise symmetric key-encryption key (KEK) generated using 117 an originator's randomly generated private key (ES-DH [DH]) or 118 previously generated private key (SS-DH [DH]), the recipient's public 120 DH key, and other values. Section 2.3 provides additional details. 122 3) Previously Distributed Symmetric KEK: The AES CEK is wrapped 123 using a previously distributed symmetric KEK (such as a Mail List 124 Key). The methods by which the symmetric KEK is generated and 125 distributed are beyond the scope of this document. Section 2.4 126 provides additional details. 128 4) Password Encryption: The AES CEK is wrapped using a KEK derived 129 from a password or other shared secret. Section 2.5 provides 130 additional details. 132 Documents defining the use of the Other Recipient Info structure will 134 need to define the proper use for the AES algorithm if desired. 136 2.1 EnvelopedData Fields 138 The enveloped-data content type is ASN.1 encoded using the 139 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 141 populated as follows: 143 The EnvelopedData version is determined based on a number of factors. 145 See [CMS] section 6.1 for the algorithm to determine this value. 147 The EnvelopedData recipientInfos CHOICE is dependent on the key 148 management technique used. Section 2.2, 2.3, 2.4 and 2.5 provide 149 additional information. 151 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 152 field MUST specify a symmetric encryption algorithm. Implementations 154 MUST support content encryption with AES, but implementations MAY 155 support other algorithms as well. 157 The EnvelopedData unprotectedAttrs MAY be present. 159 2.2 KeyTransRecipientInfo Fields 161 The enveloped-data content type is ASN.1 encoded using the 162 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 164 populated as follows: 166 The KeyTransRecipientInfo version MUST be either 0 or 2. If the 167 RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the 168 version MUST be 0. If the RecipientIdentifier is 169 subjectKeyIdentifier, then the version MUST be 2. 171 The KeyTransRecipientInfo RecipientIdentifier provides two 172 alternatives for specifying the recipient's certificate, and thereby 173 the recipient's public key. The recipient's certificate MUST contain 175 a RSA public key. The CEK is encrypted with the recipient's RSA 176 Schaad 3 177 public key. The issuerAndSerialNumber alternative identifies the 178 recipient's certificate by the issuer's distinguished name and the 179 certificate serial number; the subjectKeyIdentifier identifies the 180 recipient's certificate by the X.509 subjectKeyIdentifier extension 181 value. 183 The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies the 184 key transport algorithm (i.e. RSAES-OAEP [RSA-OAEP]), and the 185 associated parameters used to encrypt the CEK for the recipient. 187 The KeyTransRecipientInfo encryptedKey is the result of encrypting 188 the CEK with the recipient's RSA public key. 190 2.3 KeyAgreeRecipientInfo Fields 192 This section describes the conventions for using ES-DH or SS-DH and 193 AES with the CMS enveloped-data content type to support key 194 agreement. When key agreement is used, then the RecipientInfo 195 keyAgreeRecipientInfo CHOICE MUST be used. 197 The KeyAgreeRecipient version MUST be 3. 199 The EnvelopedData originatorInfo field MUST be the originatorKey 200 alternative. The originatorKey algorithm fields MUST contain the dh- 201 public-number object identifier with absent parameters. The 202 originatorKey publicKey MUST contain the originator's ephemeral 203 public key. 205 The EnvelopedData ukm MAY be present. 207 The EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH 208 algorithm identifier [CMSALG]. 210 2.3.1 ES-DH/AES Key Derivation 212 Generation of the AES KEK to be used with the AES-key wrap algorithm 213 is done using the method described in [DH]. 215 2.3.1.1 Example 1 217 ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 218 0a 0b 0c 0d 0e 0f 10 11 12 13 220 The key wrap algorithm is AES-128 wrap, so we need 128 bits (16 221 bytes) of keying material. 223 No partyAInfo is used. 225 Consequently, the input to SHA-1 is: 227 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 228 30 1b 229 30 11 230 06 09 60 86 48 01 65 03 04 01 05 ; AES-128 wrap OID 231 Schaad 4 232 04 04 233 00 00 00 01 ; Counter 234 a2 06 235 04 04 236 00 00 00 80 ; key length 238 And the output is the 32 bytes: 240 d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9 242 Consenquently, 244 K= d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 246 2.3.1.2 Example 2 248 ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 249 0a 0b 0c 0d 0e 0f 10 11 12 13 251 The key wrap algorithm is AES-256 key wrap, so we need 256 bits (32 252 bytes) of keying material. 254 The partyAInfo used is the 64 bytes 256 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 257 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 258 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 259 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 261 Consequently, the input to first invocation of SHA-1 is: 263 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 264 30 5f 265 30 11 266 06 09 60 86 48 01 65 03 04 01 2c ; AES-256 wrap OID 267 04 04 268 00 00 00 01 ; Counter 269 a0 42 270 04 40 271 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo 273 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 274 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 275 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 276 a2 06 277 04 04 278 00 00 01 00 ; key length 280 And the output is the 20 bytes: 282 6f da b9 fa 67 09 30 3e 7e 2f 68 50 29 6f 28 fb 1b a6 4e 2a 284 The input to second invocation of SHA-1 is: 286 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 287 Schaad 5 288 30 5f 289 30 11 290 06 09 60 86 48 01 65 03 04 01 2c ; AES-256 wrap OID 291 04 04 292 00 00 00 02 ; Counter 293 a0 42 294 04 40 295 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo 297 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 298 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 299 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 300 a2 06 301 04 04 302 00 00 01 00 ; key length 304 And the output is the 20 bytes: 306 73 36 a5 ae 90 33 31 39 cb 3f 0e 90 cd d8 03 96 66 36 61 b0 308 Consequently, 310 K = 6f da b9 fa 67 09 30 3e 7e 2f 68 50 29 6f 28 fb 1b a6 4e 2a 311 73 36 a5 ae 90 33 31 39 cb 3f 0e 90 313 2.3.2 AES CEK Wrap Process 315 The AES key wrap algorithm encrypts one AES key in another AES key. 316 The algorithm produces an output 64-bits longer than the input AES 317 CEK, the additional bits are a checksum. The algorithm uses 6*n AES 318 encryption/decryption operations where n is number of 64-bit blocks 319 in the AES CEK. Full details of the AES key wrap algorithm are 320 available at [AES-WRAP]. 322 NIST has assigned the following OIDs to define the AES key wrap 323 algorithm. 325 id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } 326 id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } 327 id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } 329 In all cases the parameters field MUST be absent. The OID gives the 330 KEK key size, but does not make any statements as to the size of the 331 wrapped AES CEK. Implementations MAY use different KEK and CEK 332 sizes. Implements MUST support the CEK and the KEK having the same 333 length. If different lengths are supported, the KEK MUST be of equal 335 or greater length than the CEK. 337 2.4 KEKRecipientInfo Fields 339 This section describes the conventions for using AES with the CMS 340 enveloped-data content type to support previously distributed 341 symmetric KEKs. When a previously distributed symmetric KEK is used 342 to wrap the AES CEK, then the RecipientInfo KEKRecipientInfo CHOICE 343 Schaad 6 344 MUST be used. The methods used to generate and distribute the 345 symmetric KEK are beyond the scope of this document. One possible 346 method of distributing keys is documented in [SYMKEYDIST]. 348 The KEKRecipientInfo fields MUST be populated as specified in [CMS] 349 Section 6.2.3, KEKRecipientInfo Type. 351 The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be 352 one of the OIDs defined in section 2.3.2 indicating that the AES wrap 354 function is used to wrap the AES CEK. The KEKRecipientInfo 355 keyEncryptionAlgorithm parameters field MUST be absent. 357 The KEKRecipientInfo encryptedKey field MUST include the AES CEK 358 wrapped using the previously distributed symmetric KEK as input to 359 the AES wrap function. 361 2.5 PasswordRecipientInfo Fields 363 This section describes the conventions for using AES with the CMS 364 enveloped-data content type to support password-based key management. 366 When a password derived KEK is used to wrap the AES CEK, then the 367 RecipientInfo PasswordRecipientInfo CHOICE MUST be used. 369 The keyEncryptionAlgorithm algorithm field MUST be one of the OIDs 370 defined in section 2.3.2 indicating the AES wrap function is used to 371 wrap the AES CEK. The keyEncryptionAlgorithm parameters field MUST 372 be absent. 374 The encryptedKey field MUST be the result of the AES key wrap 375 algorithm applied to the AES CEK value. 377 3 Encrypted-data Conventions 379 The CMS encrypted-data content type consists of encrypted content 380 with implicit key management. The AES algorithm is used to encrypt 381 the content. 383 Compliant software MUST meet the requirements for constructing an 384 enveloped-data content type stated in [CMS] Section 8, "Encrypted- 385 data Content Type". 387 The encrypted-data content type is ASN.1 encoded using the 388 EncryptededData syntax. The fields of the EncryptedData syntax MUST 389 be populated as follows: 391 The EncryptedData version is determined based on a number of factors. 393 See [CMS] section 9.1 for the algorithm to determine this value. 395 The EncryptedData encryptedContentInfo contentEncryptionAlgorithm 396 field MUST specify a symmetric encryption algorithm. Implementations 398 MUST support encryption using AES, but implementations MAY support 399 other algorithms as well. 401 The EncryptedData unprotectedAttrs MAY be present. 402 Schaad 7 403 4 Algorithm Identifiers and Parameters 405 This section specified algorithm identifiers for the AES encryption 406 algorithm. 408 4.1 AES Algorithm Identifiers and Parameters 410 The AES algorithm is defined in [AES]. RSAES-OAEP [RSA-OAEP] MAY be 411 used to transport AES keys. 413 AES is added to the set of symmetric content encryption algorithms 414 defined in [CMSALG]. The AES content-encryption algorithm, in Cipher 416 Block Chaining (CBC) mode, for the three different key sizes are 417 identified by the following object identifiers: 419 id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 } 420 id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 } 421 id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 } 423 The AlgorithmIdentifier parameters field MUST be present, and the 424 parameters field MUST contain a AES-IV: 426 AES-IV ::= OCTET STRING (SIZE(16)) 428 Content encryption algorithm identifiers are located in the 429 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 431 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 433 Content encryption algorithms are used to encrypt the content located 435 in the EnvelopedData EncryptedContentInfo encryptedContent and the 436 EncryptedData EncryptedContentInfo encryptedContent fields. 438 5 SMIMECapabilities Attribute Conventions 440 An S/MIME client SHOULD announce the set of cryptographic functions 441 it supports by using the S/MIME capabilities attribute. This 442 attribute provides a partial list of object identifiers of 443 cryptographic functions and MUST be signed by the client. The 444 algorithm OIDs SHOULD be logically separated in functional categories 446 and MUST be ordered with respect to their preference. 448 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 449 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 450 used to specify a partial list of algorithms that the software 451 announcing the SMIMECapabilities can support. 453 5.1 AES S/MIME Capability Attributes 455 If an S/MIME client is required to support symmetric encryption with 456 AES, the capabilities attribute MUST contain the AES object 457 identifier specified above in the category of symmetric algorithms. 458 The parameter associated with this object identifier MUST is 459 AESSMimeCapability. 460 Schaad 8 461 AESSMimeCapabilty ::= NULL 463 The encodings for the mandatory key sizes are: 465 Key Size Capability 466 128 30 0D 06 09 60 86 48 01 65 03 04 01 02 30 00 467 196 30 0D 06 09 60 86 48 01 65 03 04 01 16 30 00 468 256 30 0D 06 09 60 86 48 01 65 03 04 01 2A 30 00 470 When a sending agent creates an encrypted message, it has to decide 471 which type of encryption algorithm to use. In general the decision 472 process involves information obtained from the capabilities lists 473 included in messages received from the recipient, as well as other 474 information such as private agreements, user preferences, legal 475 restrictions, and so on. If users require AES for symmetric 476 encryption, the S/MIME clients on both the sending and receiving side 478 MUST support it, and it MUST be set in the user preferences. 480 6 Security Considerations 482 If RSA-OAEP [PKCS#1v2.0] and RSA PKCS #1 v1.5 [PKCS#1v1.5] are both 483 used to transport the same CEK, then an attacker can still use the 484 Bleichenbacher attack against the RSA PKCS #1 v1.5 encrypted key. 485 It is generally unadvisable to mix both RSA-OAEP and RSA PKCS#1 v1.5 486 in the same set of recipients. 488 Implementations must protect the RSA private key and the CEK. 489 Compromise of the RSA private key may result in the disclosure of all 491 messages protected with that key. Compromise of the CEK may result 492 in disclosure of the associated encrypted content. 494 The generation of AES CEKs relies on random numbers. The use of 495 inadequate pseudo-random number generators (PRNGs) to generate these 496 values can result in little or no security. An attacker may find it 497 much easier to reproduce the PRNG environment that produced the keys, 499 searching the resulting small set of possibilities, rather than brute 501 force searching the whole key space. The generation of quality 502 random numbers is difficult. RFC 1750 [RANDOM] offers important 503 guidance in this area. 505 When wrapping a CEK with a KEK, the KEK MUST always be at least the 506 same length as the CEK. An attacker will generally work at the 507 weakest point in an encryption system. This would be the smaller of 508 the two key sizes for a brute force attack. 510 Normative References 512 AES National Institute of Standards. 513 FIPS Pub 197: Advanced Encryption Standard (AES). 514 26 November 2001. 516 CMS Housley, R., "Cryptographic Message Syntax (CMS)", RFC 517 Schaad 9 518 3369, August 2002. 520 AES-WRAP Schaad, J., R. Housley, "Advanced Encryption Standard (AES) 521 Key Wrap Algorithm", RFC 3394, September 2002 523 CMSALG Housley, R., "Cryptographic Message Syntax (CMS) 524 Algorithms, RFC 3370, August 2002. 526 DES National Institute of Standards and Technology. 527 FIPS Pub 46: Data Encryption Standard. 15 January 1977. 529 DH Rescorla, E., Diffie-Hellman Key Agreement Method, RFC 530 2631, June 1999. 532 RSA-OAEP Housley, R. "Use of the RSAES-OAEP Key Transport Algorithm 533 in CMS", draft-ietf-smime-cms-rsaes-oaep-03.txt, June 2002. 535 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 536 Syntax Notation One (ASN.1). 1988. 538 X.209-88 CCITT. Recommendation X.209: Specification of Basic 539 Encoding Rules for Abstract Syntax Notation One (ASN.1). 540 1988. 542 X.509-88 CCITT. Recommendation X.509: The Directory - 543 Authentication Framework. 1988. 545 Informational References 547 MUSTSHOULD Bradner, S., Key Words for Use in RFCs to Indicate 548 Requirement Levels. BCP 14, RFC 2119. March 1997. 550 MSG Ramsdell, B., Editor. S/MIME Version 3 Message 551 Specification. RFC 2633. June 1999. 553 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 554 RFC 2313. March 1998. 556 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 557 RFC 2437. October 1998. 559 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 560 Recommendations for Security. RFC 1750. December 1994. 562 SYMKEYDIST Turner, S. CMS Symmetric Key Management and Distribution. 563 RFC TDB. Date TBD. 564 566 Acknowledgements 568 Schaad 10 569 This document is the result of contributions from many 570 professionals. We appreciate the hard work of all members of the 571 IETF S/MIME Working Group. 573 Author's Addresses 575 Jim Schaad 576 Soaring Hawk Consulting 578 Email: jimsch@exmsft.com 580 Appendix A ASN.1 Module 582 CMSAesRsaesOaep {iso(1) member-body(2) us(840) rsadsi(113549) 583 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) } 585 DEFINITIONS IMPLICIT TAGS ::= 586 BEGIN 588 -- EXPORTS ALL -- 589 IMPORTS 590 -- PKIX 591 AlgorithmIdentifier 592 FROM PKIXExplicit88 {iso(1) identified-organization(3) dod(6) 593 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 594 id-pkix1-explicit(18)}; 596 -- AES information object identifiers -- 598 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 599 organization(1) gov(101) csor(3)_ nistAlgorithms(4) 1 } 601 -- AES using CBC-chaining mode for key sizes of 128, 192, 256 603 id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 } 604 id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 } 605 id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 } 607 -- AES-IV is a the parameter for all the above object identifiers. 609 AES-IV ::= OCTET STRING (SIZE(16)) 611 -- AES S/MIME Capabilty parameter for all the above object identifiers 613 AESSMimeCapability ::= NULL 615 -- AES Key Wrap Algorithm Identifiers - Parameter is absent 617 id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } 618 id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } 619 id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } 621 Schaad 11 622 END 624 Schaad 12