idnits 2.17.1 draft-ietf-smime-aes-alg-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 65 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. ** 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 2002) is 8129 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'AES' on line 498 looks like a reference -- Missing reference section? 'CMS' on line 481 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 46 looks like a reference -- Missing reference section? 'DES' on line 71 looks like a reference -- Missing reference section? 'RSALAB' on line 110 looks like a reference -- Missing reference section? 'CRYPTO98' on line 110 looks like a reference -- Missing reference section? 'MMA' on line 113 looks like a reference -- Missing reference section? 'SSL' on line 128 looks like a reference -- Missing reference section? 'TLS' on line 129 looks like a reference -- Missing reference section? 'PROFILE' on line 158 looks like a reference -- Missing reference section? 'DH' on line 306 looks like a reference -- Missing reference section? 'CMSALG' on line 503 looks like a reference -- Missing reference section? 'AES-WRAP' on line 415 looks like a reference -- Missing reference section? 'SYMKEYDIST' on line 440 looks like a reference -- Missing reference section? '0' on line 873 looks like a reference -- Missing reference section? '1' on line 874 looks like a reference -- Missing reference section? '2' on line 875 looks like a reference -- Missing reference section? 'SHA1' on line 602 looks like a reference -- Missing reference section? 'MSG' on line 640 looks like a reference -- Missing reference section? 'RANDOM' on line 718 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 23 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-04.txt R. Housley 5 Expires: July 2002 RSA Laboratories 6 January 2002 8 Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS 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 RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Comments or suggestions for improvement may be made on the "ietf- 31 smime" mailing list, or directly to the author. 33 Abstract 35 This document specifies the conventions for using the Advanced 36 Encryption Standard (AES) algorithm [AES] for encryption and the 37 RSAES-OAEP key transport algorithm [PKCS#1v2.0] for key management 38 with the Cryptographic Message Syntax (CMS) [CMS]. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in RFC 2119 45 [MUSTSHOULD]. 47 1 Overview 49 This document specifies the conventions for using the RSAES-OAEP key 50 transport algorithm and Advanced Encryption Standard (AES) content 51 encryption algorithm with the Cryptographic Message Syntax [CMS] 52 enveloped-data and encrypted-data content types. 54 Use of the AES Algorithm in CMS February 2002 56 This document presents the use of the two algorithms together, since 57 we anticipate that they will be used together. However, the two 58 algorithms can be used independently. For example, RSA-OAEP could be 60 used to transport Triple-DES keys, and AES keys could be distributed 61 out-of-band for use with mail lists. 63 CMS values are generated using ASN.1 [X.208-88], using the Basic 64 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 65 (DER) [X.509-88]. 67 1.1 AES 69 The Advanced Encryption Standard (AES) [AES] was developed to replace 71 DES [DES]. The AES Federal Information Processing Standard (FIPS) 72 Publication specifies a cryptographic algorithm for use by U.S. 73 Government organizations. However, the AES will also be widely used 74 by organizations, institutions, and individuals outside of the U.S. 75 Government. 77 Two researchers who developed and submitted the Rijndael algorithm 78 for consideration are both cryptographers from Belgium: Dr. Joan 79 Daemen of Proton World International and Dr. Vincent Rijmen, a 80 postdoctoral researcher in the Electrical Engineering Department of 81 Katholieke Universiteit Leuven. 83 The National Institute of Standards and technology (NIST) selected 84 the Rijndael algorithm for AES because it offers a combination of 85 security, performance, efficiency, ease of implementation, and 86 flexibility. Specifically, Rijndael appears to be consistently a 87 very good performer in both hardware and software across a wide range 89 of computing environments regardless of its use in feedback or non- 90 feedback modes. Its key setup time is excellent, and its key agility 92 is good. The very low memory requirements of the Rijndael algorithm 93 make it very well suited for restricted-space environments, in which 94 it also demonstrates excellent performance. The Rijndael algorithm 95 operations are among the easiest to defend against power and timing 96 attacks. Additionally, it appears that some defense can be provided 97 against such attacks without significantly impacting the algorithm's 98 performance. Finally, the algorithm's internal round structure 99 appears to have good potential to benefit from instruction-level 100 parallelism. 102 The AES specifies three key sizes: 128, 192 and 256 bits. 104 1.2 RSA-OAEP 106 When the variant of the RSA key transport algorithm specified in PKCS 108 #1 Version 1.5 [PKCS#1v1.5] is used for key management, it is 109 vulnerable to adaptive chosen ciphertext attacks. This attack is 110 described in [RSALAB] and [CRYPTO98]. The use of PKCS #1 Version 1.5 112 key transport in interactive applications is especially vulnerable, 113 but countermeasures are described in [MMA]. Exploitation of this 114 identified vulnerability, revealing the result of a particular RSA 115 decryption, requires access to an oracle which will respond to 116 Use of the AES Algorithm in CMS February 2002 118 hundreds of thousands of ciphertexts, which are constructed 119 adaptively in response to previously-received replies providing 120 information on the successes or failures of attempted decryption 121 operations. 123 The attack appears significantly less feasible in store-and-forward 124 environments, such as S/MIME. When PKCS #1 Version 1.5 key transport 126 is applied as an intermediate encryption layer within an interactive 127 request-response communications environment, exploitation could be 128 more feasible. However, Secure Sockets Layer (SSL) [SSL] and 129 Transport Layer Security (TLS) [TLS] protocol implementations could 130 include countermeasures that detect and prevent Bleichenbacher's and 131 other chosen-ciphertext attacks, without changing the way the RSA key 133 transport algorithm is used. These countermeasures are performed 134 within the protocol level. In the interest of long-term security 135 assurance, it is prudent to adopt an improved cryptographic technique 137 rather than embedding countermeasures in protocols. 139 An updated version of PKCS #1 has been published: PKCS #1 Version 2.0 141 [PKCS#1v2.0]. This new document supersedes RFC 2313 [PKCS#1v1.5]. 142 PKCS #1 Version 2.0 preserves support for the encryption padding 143 format defined in PKCS #1 Version 1.5 [PKCS#1v1.5], and it also 144 defines a new alternative. To resolve the adaptive chosen ciphertext 146 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 147 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 148 is used to provide confidentiality, such as key transport. 150 This document specifies the use of RSAES-OAEP key transport algorithm 152 in the Cryptographic Message Syntax (CMS) [CMS]. CMS can be used in 153 either a store-and-forward or an interactive request-response 154 environment. 156 CMS supports variety of architectures for certificate-based key 157 management, particularly the one defined by the PKIX working group 158 [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require the 159 same RSA public key information. Thus, a certified RSA public key 160 may be used with either RSA key transport technique. 162 2 Enveloped-data Conventions 164 The CMS enveloped-data content type consists of encrypted content and 166 wrapped content-encryption keys for one or more recipients. The 167 RSAES-OAEP key transport algorithm is used to wrap the content- 168 encryption key for one recipient. The AES algorithm is used to 169 encrypt the content. 171 Compliant software MUST meet the requirements for constructing an 172 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 173 data Content Type". 175 An AES content-encryption key MUST be randomly generated for each 176 instance of an enveloped-data content type. The content-encryption 177 key (CEK) is used to encrypt the content. 179 Use of the AES Algorithm in CMS February 2002 181 AES can be used with the enveloped-data content type using any of the 183 following key management techniques defined in [CMS] Section 6. 185 1) Key Transport: The AES CEK is uniquely wrapped for each recipient 186 using the recipient's public RSA key and other values. Section 2.2 187 provides additional details. 189 2) Key Agreement: The AES CEK is uniquely wrapped for each recipient 190 using a pairwise symmetric key-encryption key (KEK) generated using 191 DH-ES [DH] using the originator's randomly generated private key, the 193 recipient's public DH key, and other values. Section 2.3 provides 194 additional details. 196 3) Previously Distributed Symmetric KEK: The AES CEK is wrapped 197 using a previously distributed symmetric KEK (such as a Mail List 198 Key). The methods by which the symmetric KEK is generated and 199 distributed are beyond the scope of this document. Section 2.4 200 provides additional details. 202 4) Password Encryption: The AES CEK is wrapped using a KEK derived 203 from a password or other shared secret. Section 2.5 provides 204 additional details. 206 2.1 EnvelopedData Fields 208 The enveloped-data content type is ASN.1 encoded using the 209 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 211 populated as follows: 213 The EnvelopedData version is determined based on a number of factors. 215 See [CMS] section 6.1 for the algorithm to determine this value. 217 The EnvelopedData originatorInfo field is not used for the RSAES-OAEP 219 key transport algorithm. However, this field MAY be present to 220 support recipients using other key management algorithms. 222 The EnvelopedData recipientInfos CHOICE is dependent on the key 223 management technique used. Section 2.2, 2.3, 2.4 and 2.5 provide 224 additional information. 226 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 227 field MUST specify a symmetric encryption algorithm. Implementations 229 MUST support content encryption with AES, but implementations MAY 230 support other algorithms as well. 232 The EnvelopedData unprotectedAttrs MAY be present. 234 2.2 KeyTransRecipientInfo Fields 236 The enveloped-data content type is ASN.1 encoded using the 237 EnvelopedData syntax. The fields of the EnvelopedData syntax MUST be 239 populated as follows: 241 Use of the AES Algorithm in CMS February 2002 243 The KeyTransRecipientInfo version MUST be either 0 or 2. If the 244 RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the 245 version MUST be 0. If the RecipientIdentifier is 246 subjectKeyIdentifier, then the version MUST be 2. 248 The KeyTransRecipientInfo RecipientIdentifier provides two 249 alternatives for specifying the recipient's certificate, and thereby 250 the recipient's public key. The recipient's certificate MUST contain 252 a RSA public key. The CEK is encrypted with the recipient's RSA 253 public key. The issuerAndSerialNumber alternative identifies the 254 recipient's certificate by the issuer's distinguished name and the 255 certificate serial number; the subjectKeyIdentifier identifies the 256 recipient's certificate by the X.509 subjectKeyIdentifier extension 257 value. 259 The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies the 260 RSAES-OAEP algorithm, and the associated parameters used to encrypt 261 the CEK for the recipient. The key encryption process is described 262 in [PKCS#1v2.0]. See section 4.2 of this document for the algorithm 263 identifier and the parameter syntax. 265 The KeyTransRecipientInfo encryptedKey is the result of encrypting 266 the CEK with the recipient's RSA public key using the RSAES-OAEP 267 algorithm. 269 Note: When using a Triple-DES CEK, implementations MUST adjust the 270 parity bits for each DES key comprising the Triple-DES key prior to 271 RSAES-OAEP encryption. 273 Note: The same key wrap algorithm is used for both Two-key Triple-DES 275 and Three-key Triple-DES CEK keys. When a Two-key Triple-DES key is 276 to be wrapped, a third DES key with the same value as the first DES 277 key is created. Thus, all wrapped Triple-DES keys include three DES 278 keys. 280 2.3 KeyAgreeRecipientInfo Fields 282 This section describes the conventions for using ES-DH and AES with 283 the CMS enveloped-data content type to support key agreement. When 284 key agreement is used, then the RecipientInfo keyAgreeRecipientInfo 285 CHOICE MUST be used. 287 The KeyAgreeRecipient version MUST be 3. 289 The EnvelopedData originatorInfo field MUST be the originatorKey 290 alternative. The originatoryKey algorithm fields MUST contain the 291 dh-public-number object identifier with absent parameters. The 292 originatorKey publicKey MUST contain the originator's ephemeral 293 public key. 295 The EnvelopedData ukm MAY be present. 297 The EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH 298 algorithm identifier [CMSALG]. 300 Use of the AES Algorithm in CMS February 2002 302 2.3.1 ES-DH/AES Key Derivation 304 Generation of the AES KEK to be used with the AES -key wrap algorithm 306 is done using the method described in [DH]. 308 2.3.1.1 Example 1 310 ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 311 0a 0b 0c 0d 0e 0f 10 11 12 13 313 The key wrap algorithm is AES-128 wrap, so we need 128 bits (16 314 bytes) of keying material. 316 No partyAInfo is used. 318 Consequently, the input to SHA-1 is: 320 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 321 30 1b 322 30 11 323 06 09 60 86 48 01 65 03 04 01 05 ; AES-128 wrap OID 324 04 04 325 00 00 00 01 ; Counter 326 a2 06 327 04 04 328 00 00 00 80 ; key length 330 And the output is the 32 bytes: 332 d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9 334 Consenquently, 336 K= d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 338 2.3.1.2 Example 2 340 ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 341 0a 0b 0c 0d 0e 0f 10 11 12 13 343 The key wrap algorithm is AES-256 key wrap, so we need 256 bits (32 344 bytes) of keying material. 346 The partyAInfo used is the 64 bytes 348 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 349 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 350 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 351 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 353 Consequently, the input to first invocation of SHA-1 is: 355 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 356 Use of the AES Algorithm in CMS February 2002 358 30 5f 359 30 11 360 06 09 60 86 48 01 65 03 04 01 2c ; AES-256 wrap OID 361 04 04 362 00 00 00 01 ; Counter 363 a0 42 364 04 40 365 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo 367 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 368 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 369 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 370 a2 06 371 04 04 372 00 00 01 00 ; key length 374 And the output is the 20 bytes: 376 6f da b9 fa 67 09 30 3e 7e 2f 68 50 29 6f 28 fb 1b a6 4e 2a 378 The input to second invocation of SHA-1 is: 380 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ 381 30 5f 382 30 11 383 06 09 60 86 48 01 65 03 04 01 2c ; AES-256 wrap OID 384 04 04 385 00 00 00 02 ; Counter 386 a0 42 387 04 40 388 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo 390 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 391 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 392 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 393 a2 06 394 04 04 395 00 00 01 00 ; key length 397 And the output is the 20 bytes: 399 73 36 a5 ae 90 33 31 39 cb 3f 0e 90 cd d8 03 96 66 36 61 b0 401 Consequently, 403 K = 6f da b9 fa 67 09 30 3e 7e 2f 68 50 29 6f 28 fb 1b a6 4e 2a 404 73 36 a5 ae 90 33 31 39 cb 3f 0e 90 406 2.3.2 AES CEK Wrap Process 408 The AES key wrap algorithm encrypts one AES key in another AES key. 409 The algorithm produces an output 64-bits longer than the input AES 410 CEK, the additional bits are a checksum. The algorithm uses 6*n AES 411 encryption/decryption operations where n is number of 64-bit blocks 412 Use of the AES Algorithm in CMS February 2002 414 in the AES CEK. Full details of the AES key wrap algorithm are 415 available at [AES-WRAP]. 417 NIST has assigned the following OIDs to define the AES key wrap 418 algorithm. 420 id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } 421 id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } 422 id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } 424 In all cases the parameters field MUST be absent. The OID gives the 425 KEK key size, but does not make any statements as to the size of the 426 wrapped AES CEK. Implementations MAY use different KEK and CEK 427 sizes. Implements MUST support the CEK and the KEK having the same 428 length. If different lengths are supported, the KEK MUST be of equal 430 or greater length than the CEK. 432 2.4 KEKRecipientInfo Fields 434 This section describes the conventions for using AES with the CMS 435 enveloped-data content type to support previously distributed 436 symmetric KEKs. When a previously distributed symmetric KEK is used 437 to wrap the AES CEK, then the RecipientInfo KEKRecipientInfo CHOICE 438 MUST be used. The methods used to generate and distribute the 439 symmetric KEK are beyond the scope of this document. One possible 440 method of distributing keys is documented in [SYMKEYDIST]. 442 The KEKRecipientInfo fields MUST be populated as specified in [CMS] 443 Section 6.2.3, KEKRecipientInfo Type. 445 The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be 446 one of the OIDs defined in section 2.3.2 indicating that the AES wrap 448 function is used to wrap the AES CEK. The KEKRecipientInfo 449 keyEncryptionAlgorithm parameters field MUST be absent. 451 The KEKRecipientInfo encryptedKey field MUST include the AES CEK 452 wrapped using the previously distributed symmetric KEK as input to 453 the AES wrap function. 455 2.5 PasswordRecipientInfo Fields 457 This section describes the conventions for using AES with the CMS 458 enveloped-data content type to support password-based key management. 460 When a password derived KEK is used to wrap the AES CEK, then the 461 RecipientInfo PasswordRecipientInfo CHOICE MUST be used. 463 The keyEncryptionAlgorithm algorithm field MUST be one of the OIDs 464 defined in section 2.3.2 indicating the AES wrap function is used to 465 wrap the AES CEK. The keyEncryptionAlgorithm parameters field MUST 466 be absent. 468 The encryptedKey field MUST be the result of the AES key wrap 469 algorithm applied to the AES CEK value. 471 Use of the AES Algorithm in CMS February 2002 473 3 Encrypted-data Conventions 475 The encrypted-data content type is ASN.1 encoded using the 476 EncryptededData syntax. The fields of the EncryptedData syntax MUST 477 be populated as follows: 479 The EncryptedData version is determined based on a number of factors. 481 See [CMS] section 9.1 for the algorithm to determine this value. 483 The EncryptedData encryptedContentInfo contentEncryptionAlgorithm 484 field MUST specify a symmetric encryption algorithm. Implementations 486 MUST support encryption using AES, but implementations MAY support 487 other algorithms as well. 489 The EncryptedData unprotectedAttrs MAY be present. 491 4 Algorithm Identifiers and Parameters 493 This section specified algorithm identifiers for the AES encryption 494 algorithm and the RSAES-OAEP key transport algorithm. 496 4.1 AES Algorithm Identifiers and Parameters 498 The AES algorithm is defined in [AES]. RSA #1 v1.5 [PKCS#1v1.5] 499 MUST NOT be used to transport AES keys. RSAES-OAEP [PKCS#1v2.0] MAY 500 be used to transport AES keys. 502 AES is added to the set of symmetric content encryption algorithms 503 defined in [CMSALG]. The AES content-encryption algorithm, in Cipher 505 Block Chaining (CBC) mode, for the three different key sizes are 506 identified by the following object identifiers: 508 id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 } 509 id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 } 510 id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 } 512 The AlgorithmIdentifier parameters field MUST be present, and the 513 parameters field MUST contain a AES-IV: 515 AES-IV ::= OCTET STRING (SIZE(16)) 517 Content encryption algorithm identifiers are located in the 518 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 520 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 522 Content encryption algorithms are used to encrypt the content located 524 in the EnvelopedData EncryptedContentInfo encryptedContent and the 525 EncryptedData EncryptedContentInfo encryptedContent fields. 527 4.2 RSAES-OAEP Algorithm Identifiers and Parameters 529 The RSAES-OAEP key transport algorithm is the RSA encryption scheme 530 defined in RFC 2437 [PKCS#1v2.0], where the message to be encrypted 531 is the content-encryption key. 533 Use of the AES Algorithm in CMS February 2002 535 The RSA key is identified in a certificate using the rsaEncryption 536 object identifier: 538 pkcs-1 OBJECT IDENTIFIER ::= { 539 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) } 541 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 543 Note: This is the same algorithm identifier used by RSAES-PKCS1-v1_5. 545 This means that the existence of an RSA key in a certificate cannot 546 be used to infer that a recipient can decrypt an RSAES-OAEP encrypted 548 content-encryption key. 550 The object identifier for RSAES-OAEP is: 552 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 554 The AlgorithmIdentifier parameters field MUST be present, and the 555 parameters field MUST contain RSAES-OAEP-params. RSAES-OAEP-params 556 have the following syntax: 558 RSAES-OAEP-params ::= SEQUENCE { 559 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 560 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 562 pSourceFunc [2] AlgorithmIdentifier 563 DEFAULT pSpecifiedEmptyIdentifier } 565 sha1Identifier ::= AlgorithmIdentifier { 566 id-sha1, NULL } 568 mgf1SHA1Identifier ::= AlgorithmIdentifier { 569 id-mgf1, sha1Identifier } 571 pSpecifiedEmptyIdentifier ::= AlgorithmIdentifier { 572 id-pSpecified, nullOctetString } 574 id-sha1 OBJECT IDENTIFIER ::= { 575 iso(1) identified-organization(3) oiw(14) secsig(3) 576 algorithms(2) 26 } 578 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 580 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 582 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 584 The fields of type RSAES-OAEP-params have the following meanings: 586 hashFunc identifies the one-way hash function. Implementations MUST 587 support SHA-1 [SHA1]. The SHA-1 algorithm identifier is comprised of 589 the id-sha1 object identifier and a parameter of NULL. 590 Implementations that perform key encryption MUST omit the hashFunc 591 field when SHA-1 is used, indicating that the default algorithm was 592 Use of the AES Algorithm in CMS February 2002 594 used. Implementations that perform key decryption MUST recognize 595 both the id-sha1 object identifier and an absent hashFunc field as an 597 indication that SHA-1 was used. 599 maskGenFunc identifies the mask generation function. Implementations 600 MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a one-way hash 601 function, and it is identified in the parameter field of the MFG1 602 algorithm identifier. Implementations MUST support SHA-1 [SHA1]. 603 The MFG1 algorithm identifier is comprised of the id-mgf1 object 604 identifier and a parameter that contains the algorithm identifier of 605 the one-way hash function employed with MFG1. The SHA-1 algorithm 606 identifier is comprised of the id-sha1 object identifier and a 607 parameter of NULL. Implementations that perform key encryption MUST 608 omit the maskGenFunc field when MFG1 with SHA-1 is used, indicating 609 that the default algorithm was used. Implementations that perform 610 key decryption MUST recognize both the id-mgf1 and id-sha1 object 611 identifiers as well as an absent maskGenFunc field as an indication 612 that MFG1 with SHA-1 was used. 614 pSourceFunc identifies the source (and possibly the value) of the 615 encoding parameters, commonly called P. Implementations MUST 616 represent P by an algorithm identifier, id-pSpecified, indicating 617 that P is explicitly provided as an OCTET STRING in the parameters. 618 The default value for P is an empty string. In this case, pHash in 619 EME-OAEP contains the hash of a zero length string. Implementations 620 MUST support a zero length P value. Implementations that perform key 622 encryption MUST omit the pSourceFunc field when a zero length P value 624 is used, indicating that the default value was used. Implementations 626 that perform key decryption MUST recognize both the id-pSpecified 627 object identifier and an absent pSourceFunc field as an indication 628 that a zero length P value was used. 630 5 SMIMECapabilities Attribute Conventions 632 An S/MIME client SHOULD announce the set of cryptographic functions 633 it supports by using the S/MIME capabilities attribute. This 634 attribute provides a partial list of object identifiers of 635 cryptographic functions and MUST be signed by the client. The 636 algorithm OIDs SHOULD be logically separated in functional categories 638 and MUST be ordered with respect to their preference. 640 RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed 641 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 642 used to specify a partial list of algorithms that the software 643 announcing the SMIMECapabilities can support. 645 5.1 RSAES-OEAP SMIMECapability Attribute 647 When constructing a signedData object, compliant software MAY include 649 the SMIMECapabilities signed attribute announcing that it supports 650 the RSAES-OAEP algorithm. 652 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 654 id-RSAES-OAEP object identifier in the capabilityID field and MUST 655 Use of the AES Algorithm in CMS February 2002 657 include the RSAES-OAEP-Default-Identifier SEQUENCE in the parameters 658 field. 660 RSAES-OAEP-Default-Identifier ::= AlgorithmIdentifier { 661 id-RSAES-OAEP, { sha1Identifier, mgf1SHA1Identifier, 662 pSpecifiedEmptyIdentifier } } 664 When all of the default settings are selected, the SMIMECapability 665 SEQUENCE representing RSAES-OAEP MUST be DER-encoded as: 667 30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00 669 5.2 AES S/MIME Capability Attributes 671 If an S/MIME client is required to support symmetric encryption with 672 AES, the capabilities attribute MUST contain the AES object 673 identifier specified above in the category of symmetric algorithms. 674 The parameter associated with this object identifier MUST is 675 AESSMimeCapability. 677 AESSMimeCapabilty ::= NULL 679 The encodings for the mandatory key sizes are: 681 Key Size Capability 682 128 30 0D 06 09 60 86 48 01 65 03 04 01 02 30 00 683 196 30 0D 06 09 60 86 48 01 65 03 04 01 16 30 00 684 256 30 0D 06 09 60 86 48 01 65 03 04 01 2A 30 00 686 When a sending agent creates an encrypted message, it has to decide 687 which type of encryption algorithm to use. In general the decision 688 process involves information obtained from the capabilities lists 689 included in messages received from the recipient, as well as other 690 information such as private agreements, user preferences, legal 691 restrictions, and so on. If users require AES for symmetric 692 encryption, the S/MIME clients on both the sending and receiving side 694 MUST support it, and it MUST be set in the user preferences. 696 6 Security Considerations 698 If RSA-OAEP and RSA #1 v1.5 are both used to transport the same CEK, 699 then an attacker can still use the Bleichenbacher attack against the 700 RSA #1 v1.5 encrypted key. It is generally unadvisable to mix both 701 RSA-OAEP and RSA #1 v1.5 in the same set of recipients. 703 Implementations must protect the RSA private key and the CEK. 704 Compromise of the RSA private key may result in the disclosure of all 706 messages protected with that key. Compromise of the CEK may result 707 in disclosure of the associated encrypted content. 709 The generation of AES CEKs, RSA public/private key pairs, and MGF 710 seeds rely on random numbers. The use of inadequate pseudo-random 711 number generators (PRNGs) to generate these values can result in 712 little or no security. An attacker may find it much easier to 713 Use of the AES Algorithm in CMS February 2002 715 reproduce the PRNG environment that produced the keys, searching the 716 resulting small set of possibilities, rather than brute force 717 searching the whole key space. The generation of quality random 718 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 720 this area. 722 When wrapping a CEK with a KEK, the KEK MUST always be at least the 723 same length as the CEK. An attacker will generally work at the 724 weakest point in an encryption system. This would be the smaller of 725 the two key sizes for a brute force attack. 727 References 729 AES National Institute of Standards. 730 FIPS Pub 197: Advanced Encryption Standard (AES). 731 26 November 2001. 733 AES-WRAP Schaad, J., R. Housley, "AES Key Wrap Algorithm", 734 Draft-ietf-smime-aes-key-wrap-00.txt 736 CMS Housley, R., Cryptographic Message Syntax. 737 draft-ietf-smime-rfc2630bis-06.txt. 739 CMSALG Housley, R., Cryptographic Message Syntax (CMS) Algorithms, 740 draft-ietf-smime-cmsalg-07.txt. 742 CRYPTO98 Bleichenbacher, D., "Chosen Ciphertext Attacks Against 743 Protocols Based on the RSA Encryption Standard PKCS #1," 744 in H. Krawczyk (editor), Advances in Cryptology - CRYPTO'98 745 Proceedings, Lecture Notes in Computer Science 1462 (1998), 746 Springer-Verlag, pp. 1-12. 748 DES National Institute of Standards and Technology. 749 FIPS Pub 46: Data Encryption Standard. 15 January 1977. 751 DH Rescorla, E., Diffie-Hellman Key Agreement Method, RFC 752 2631, June 1999. 754 MUSTSHOULD Bradner, S., Key Words for Use in RFCs to Indicate 755 Requirement Levels. BCP 14, RFC 2119. March 1997. 757 MMA Rescorla, E., Preventing the Million Message Attack 758 on CMS, RFC 3218, January 2002. 760 MSG Ramsdell, B., Editor. S/MIME Version 3 Message 761 Specification. RFC 2633. June 1999. 763 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 764 RFC 2313. March 1998. 766 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 767 RFC 2437. October 1998. 769 Use of the AES Algorithm in CMS February 2002 771 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 772 X.509 Public Key Infrastructure: Certificate and CRL 773 Profile. . 775 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 776 Recommendations for Security. RFC 1750. December 1994. 778 RSALABS Bleichenbacher, D., B. Kaliski, and J. Staddon. 779 Recent Results on PKCS #1: RSA Encryption Standard. 780 RSA Laboratories' Bulletin No. 7, June 26, 1998. 781 [At http://www.rsasecurity.com/rsalabs/bulletins] 783 SHA1 National Institute of Standards and Technology. 784 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 786 SSL Freier, A., P. Karlton, and P. Kocher. The SSL Protocol, 787 Version 3.0. Netscape Communications. November 1996. 788 [At http://www.netscape.com/eng/ssl3/draft302.txt] 790 SYMKEYDIST Turner, S. CMS Symmetric Key Management and Distribution. 791 RFC TDB. Date TBD. 792 794 TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. 795 RFC 2246. January 1999. 797 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 798 Syntax Notation One (ASN.1). 1988. 800 X.209-88 CCITT. Recommendation X.209: Specification of Basic 801 Encoding Rules for Abstract Syntax Notation One (ASN.1). 802 1988. 804 X.509-88 CCITT. Recommendation X.509: The Directory - 805 Authentication Framework. 1988. 807 Acknowledgements 809 This document is the result of contributions from many 810 professionals. We appreciate the hard work of all members of the 811 IETF S/MIME Working Group. We wish to extend a special thanks to 812 Burt Kaliski. 814 Author's Addresses 816 Jim Schaad 817 Soaring Hawk Consulting 819 Email: jimsch@exmsft.com 821 Russell Housley 822 RSA Laboratories 823 918 Spring Knoll Drive 824 Use of the AES Algorithm in CMS February 2002 826 Herndon, VA 20170 827 USA 829 Email: rhousley@rsasecurity.com 831 Appendix A ASN.1 Module 833 CMSAesRsaesOaep {iso(1) member-body(2) us(840) rsadsi(113549) 834 pkcs(1) pkcs-9(9) smime(16) modules(0) aes-rsaes-oaep(19) } 836 DEFINITIONS IMPLICIT TAGS ::= 837 BEGIN 839 -- EXPORTS ALL -- 840 IMPORTS 841 -- PKIX 842 AlgorithmIdentifier 843 FROM PKIXExplicit88 {iso(1) identified-organization(3) dod(6) 844 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 845 id-pkix1-explicit(18)}; 847 -- AES information object identifiers -- 849 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 850 organization(1) gov(101) csor(3)_ nistAlgorithms(4) 1 } 852 -- AES using CBC-chaining mode for key sizes of 128, 192, 256 854 id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 } 855 id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 } 856 id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 } 858 -- AES-IV is a the parameter for all the above object identifiers. 860 AES-IV ::= OCTET STRING (SIZE(16)) 862 -- AES S/MIME Capabilty parameter for all the above object identifiers 864 AESSMimeCapability ::= NULL 866 -- Definitions for RSA-OAEP 868 pkcs-1 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 869 rsadsi(113549) pkcs(1) pkcs-1(1) } 870 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 872 RSAES-OAEP-params ::= SEQUENCE { 873 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 874 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 875 pSourceFunc [2] AlgorithmIdentifier 876 DEFAULT pSpecifiedEmptyIdentifier } 878 sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL } 879 Use of the AES Algorithm in CMS February 2002 881 mgf1SHA1Identifier AlgorithmIdentifier ::= {id-mgf1, sha1Identifier } 883 nullOctetString OCTET STRING (SIZE (0)) ::= { ''H } 885 pSpecifiedEmptyIdentifier AlgorithmIdentifier ::= { id-pSpecified, 886 nullOctetString } 888 id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 889 oiw(14) secsig(3) algorithms(2) 26 } 891 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 893 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 895 rSAES-OAEP-Default-Identifier AlgorithmIdentifier ::= { 896 id-RSAES-OAEP, { sha1Identifier, mgf1SHA1Identifier, 897 pSpecifiedEmptyIdentifier } } 899 END