idnits 2.17.1 draft-ietf-smime-aes-alg-01.txt: -(501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? == There are 4 instances of lines with non-ascii characters in the document. == 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 649 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 (March 2001) is 8443 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? '1' on line 295 looks like a reference -- Missing reference section? 'AES' on line 36 looks like a reference -- Missing reference section? 'CMS' on line 252 looks like a reference -- Missing reference section? '2' on line 296 looks like a reference -- Missing reference section? 'RSALAB' on line 64 looks like a reference -- Missing reference section? 'CRYPTO98' on line 64 looks like a reference -- Missing reference section? 'SSL' on line 77 looks like a reference -- Missing reference section? 'TLS' on line 78 looks like a reference -- Missing reference section? 'PROFILE' on line 102 looks like a reference -- Missing reference section? 'DH' on line 233 looks like a reference -- Missing reference section? 'SHA-256' on line 235 looks like a reference -- Missing reference section? '0' on line 294 looks like a reference -- Missing reference section? 'SHA1' on line 341 looks like a reference -- Missing reference section? 'RANDOM' on line 475 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 17 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-01.txt R. Housley 5 Expires: September 2, 2001 RSA Laboratories 6 March 2001 8 Use of the Advanced Encryption Algorithm 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 RFC2026 [1]. 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 how to incorporate the Advanced Encryption 36 Standard (AES) algorithm [AES] and RSAES-OAEP key transport method of 37 key management into the S/MIME Cryptographic Message Syntax [CMS] as 38 additional algorithms. 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 [2]. 46 1. Overview 48 This document describes the conventions for using the RSAES-OAEP key 49 transport algorithm and Advanced Encryption Standard (AES) content 50 encryption algorithm with the Cryptographic Message Syntax [CMS] 51 enveloped-data, encrypted-data and authenticated-data content types. 53 While this document presents the use of the two algorithms together, 54 that fact does not imply that they cannot be used independently. 55 Schaad, Housley 1 56 Use of the AES Algorithm in CMS November 2000 58 They are presented together simply because the initial usage of each 59 will be as a matched pair. 61 When the variant of the RSA key transport algorithm specified in PKCS 62 #1 Version 1.5 [PKCS#1v1.5] is used for key management, it is 63 vulnerable to adaptive chosen ciphertext attacks. This attack is 64 explained in [RSALAB] and [CRYPTO98]. The use of PKCS #1 Version 1.5 65 key transport in interactive applications is especially vulnerable. 66 Exploitation of this identified vulnerability, revealing the result 67 of a particular RSA decryption, requires access to an oracle which 68 will respond to hundreds of thousands of ciphertexts, which are 69 constructed adaptively in response to previously-received replies 70 providing information on the successes or failures of attempted 71 decryption operations. 73 The attack appears significantly less feasible in store-and-forward 74 environments, such as S/MIME. When PKCS #1 Version 1.5 key transport 75 is applied as an intermediate encryption layer within an interactive 76 request-response communications environment, exploitation could be 77 more feasible. However, Secure Sockets Layer (SSL) [SSL] and 78 Transport Layer Security (TLS) [TLS] protocol implementations could 79 include countermeasures that detect and prevent Bleichenbacher's and 80 other chosen-ciphertext attacks, without changing the way the RSA key 81 transport algorithm is used. These countermeasures are performed 82 within the protocol level. In the interest of long-term security 83 assurance, it is prudent to adopt an improved cryptographic technique 84 rather than embedding countermeasures within protocols. 86 An updated version of PKCS #1 has been published, PKCS #1 Version 2.0 87 [PKCS#1v2.0]. This new document supersedes RFC 2313. PKCS #1 88 Version 2.0 preserves support for the encryption padding format 89 defined in PKCS #1 Version 1.5 [PKCS#1v1.5], and it also defines a 90 new alternative. To resolve the adaptive chosen ciphertext 91 vulnerability, the PKCS #1 Version 2.0 specifies and recommends use 92 of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption 93 is used to provide confidentiality, such as key transport. 95 This document specifies the use of RSAES-OAEP key transport algorithm 96 in the Cryptographic Message Syntax (CMS) [CMS]. CMS can be used in 97 either a store-and-forward or an interactive request-response 98 environment. 100 CMS supports variety of architectures for certificate-based key 101 management, particularly the one defined by the PKIX working group 102 [PROFILE]. PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require the 103 same RSA public key information. Thus, a certified RSA public key 104 may be used with either RSA key transport technique. 106 CMS values are generated using ASN.1 [X.208-88], using the Basic 107 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 108 (DER) [X.509-88]. 110 2. Enveloped-data Conventions 112 Schaad, Housley 2 113 Use of the AES Algorithm in CMS November 2000 115 The CMS enveloped-data content type consists of encrypted content and 116 wrapped content-encryption keys for one or more recipients. The 117 RSAES-OAEP key transport algorithm is used to wrap the content- 118 encryption key for one recipient. The AES algorithm is used to 119 encrypt the content. 121 Compliant software MUST meet the requirements for constructing an 122 enveloped-data content type stated in [CMS] Section 6, "Enveloped- 123 data Content Type". 125 A content-encryption key MUST be randomly generated for each instance 126 of an enveloped-data content type. The content-encryption key is 127 used to encipher the content. 129 AES can be used with the enveloped-data content type using any of the 130 following key management techniques defined in [CMS] Section 6. 132 1) Key Transport: The AES CEK is uniquely wrapped for each recipient 133 using the recipient's public RSA key and other values. Section 2.XX 134 provides additional details. RSAES-OEAP is a key transport algorithm 135 and it�s usage is described here. 137 2) Key Agreement: The AES CEK is uniquely wrapped for each recipient 138 using a pairwise symmetric key-encryption key (KEK) generated using 139 DH-ES using the a randomly generated private key value for the 140 originator, the recipient's public DH key and other values. Section 141 2.XX provides additional details. 143 3) "Previously Distributed" Symmetric KEK: The AES CEK is wrapped 144 using a "previously distributed" symmetric KEK (such as a Mail List 145 Key). The methods by which the symmetric KEK is generated and 146 distributed are beyond the scope of this document. Section 2.XXX 147 provides more details. 149 2.1 EnvelopedData Fields 151 The enveloped-data content type is ASN.1 encoded using the 152 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 153 populated as follows: 155 The EnvelopedData version MUST be either 0 or 2. 157 The EnvelopedData originatorInfo field is not used for the RSAES-OAEP 158 key transport algorithm. However, this field MAY be present to 159 support recipients using other key management algorithms. 161 The EnvelopedData recipientInfos CHOICE is dependent on the key 162 managment technique used. Section 2.2, 2.3 and 2.4 provide more 163 inforamtion. 165 The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm 166 field MUST specify a symmetric encryption algorithm. Implementations 167 MUST support the encryption of AES keys, but implementations MAY 168 support other algorithms as well. 169 Schaad, Housley 3 170 Use of the AES Algorithm in CMS November 2000 172 The EnvelopedData unprotectedAttrs MAY be present. 174 2.2 KeyTransRecipientInfo Fields 176 The enveloped-data content type is ASN.1 encoded using the 177 EnvelopedData syntax. The fields of the EnvelopedData syntax must be 178 populated as follows: 180 The KeyTransRecipientInfo version MUST be either 0 or 2. If the 181 RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the 182 version MUST be 0. If the RecipientIdentifier is 183 subjectKeyIdentifier, then the version MUST be 2. 185 The KeyTransRecipientInfo RecipientIdentifier provides two 186 alternatives for specifying the recipient's certificate, and thereby 187 the recipient's public key. The recipient's certificate must contain 188 a RSA public key. The content-encryption key is encrypted with the 189 recipient's RSA public key. The issuerAndSerialNumber alternative 190 identifies the recipient's certificate by the issuer's distinguished 191 name and the certificate serial number; the subjectKeyIdentifier 192 identifies the recipient's certificate by the X.509 193 subjectKeyIdentifier extension value. 195 The KeyTransRecipientInfo keyEncryptionAlgorithm specifies that the 196 RSAES-OAEP algorithm, and its associated parameters, was used to 197 encrypt the content-encryption key for the recipient. The key- 198 encryption process is described in [PKCS#1v2.0]. See section 3 of 199 this document for the algorithm identifier and the parameter syntax. 201 The KeyTransRecipientInfo encryptedKey is the result of encrypting 202 the content-encryption key in the recipient's RSA public key using 203 the RSAES-OAEP algorithm. When using a Triple-DES content-encryption 204 key, implementations MUST adjust the parity bits for each DES key 205 comprising the Triple-DES key prior to RSAES-OAEP encryption. 207 2.3 KeyAgreeRecipientInfo Fields 209 This section describes the conventions for using ES-DH and AES with 210 the CMS enveloped-data content type to support key agreement. When 211 key agreement is used, then the RecipientInfo keyAgreeRecipientInfo 212 CHOICE MUST be used. 214 The KeyAgreeRecipient version MUST be 3. 216 The EnvelopedData originatorInfo field must be the originatorKey 217 alternative. The originatoryKey algorithm fields MUST contain the 218 dh-public-number object identifier with absent parameters. The 219 originatorKey publicKey MUST contain the sender�s ephemeral public 220 key. 222 The EnvelopedData ukm MAY be absent. 224 Schaad, Housley 4 225 Use of the AES Algorithm in CMS November 2000 227 The EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH 228 algorithm identifier. 230 2.3.1 ES-DH/AES Key Derivation 232 Generation of the an AES key used in doing AES-KeyWrap is done using 233 the method in [DH] with the following modifications: 235 The Hash function H will be [SHA-256] rather than SHA-1. 237 NOTE: 2 examples to be provided at this location. 239 2.3.2 AES CEK Wrap Process 241 To be supplied. 243 2.4 KEKRecipientInfo Fields 245 This section describes the conventions for using AES with the CMS 246 enveloped-data content type to support "previously distributed" 247 symmetric KEKs. When a "previously distributed" symmetric KEK is 248 used to wrap the AES CEK, then the RecipientInfo KEKRecipientInfo 249 CHOICE MUST be used. The methods used to generate and distribute the 250 symmetric KEK are beyond the scope of this document. 252 The KEKRecipientInfo fields MUST be populated as specified in [CMS] 253 Section 6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo 254 keyEncryptionAlgorithm algorithm field MUST be the id-NIST-AES-KEY- 255 WRAP OID indicating that the AES wrap function is used to wrap the 256 AES CEK. The KEKRecipientInfo keyEncryptionAlgorithm parameters field 257 MUST be absent. The KEKRecipientInfo encryptedKey field MUST include 258 the AES CEK wrapped using the "previously distributed" symmetric KEK 259 as input to the AES wrap function. 261 To Be Decided � Do we have multiple sizes of key wrap algorithms. 263 3. Encrypted-data Conventions 265 To be supplied. 267 4. Authenticated-data Conventions 269 To be supplied. 271 5. Algorithm Identifiers and Parameters 273 5.1 RSAES-OAEP Algorithm Identifiers and Parameters 275 The RSAES-OAEP key transport algorithm is the RSA encryption scheme 276 defined in RFC 2437 [PKCS#1v2.0], where the message to be encrypted 277 is the content-encryption key. The algorithm identifier for RSAES- 278 OAEP is: 280 id-RSAES-OAEP OBJECT IDENTIFIER ::= 282 Schaad, Housley 5 283 Use of the AES Algorithm in CMS November 2000 285 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 286 7 } 288 The AlgorithmIdentifier parameters field must be present, and the 289 parameters field must contain RSAES-OAEP-params. RSAES-OAEP-params 290 have the following syntax: 292 RSAES-OAEP-params ::= SEQUENCE 294 hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier, 295 maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier, 296 pSourceFunc [2] AlgorithmIdentifier DEFAULT 297 pSpecifiedEmptyIdentifier } 299 sha1Identifier ::= AlgorithmIdentifier 301 id-sha1, NULL } 303 mgf1SHA1Identifier ::= AlgorithmIdentifier 305 id-mgf1, sha1Identifier } 307 pSpecifiedEmptyIdentifier ::= AlgorithmIdentifier 309 id-pSpecified, OCTET STRING SIZE (0) } 311 id-sha1 OBJECT IDENTIFIER ::= 313 iso(1) identified-organization(3) oiw(14) secsig(3) 314 algorithms(2) 26 } 316 id-mgf1 OBJECT IDENTIFIER ::= 318 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 319 8 } 321 id-pSpecified OBJECT IDENTIFIER ::= 323 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 324 9 } 326 The fields of type RSAES-OAEP-params have the following meanings: 328 hashFunc identifies the one-way hash function. Implementations 329 MUST support SHA-1 [SHA1]. The SHA-1 algorithm identifier is 330 comprised of the id-sha1 object identifier and a parameter of NULL. 331 Implementations that perform encryption MUST omit the hashFunc field 332 when SHA-1 is used, indicating that the default algorithm was used. 333 Implementations that perform decryption MUST recognize both the id- 334 sha1 object identifier and an absent hashFunc field as an indication 335 that SHA-1 was used. 337 maskGenFunc identifies the mask generation function. 338 Implementations MUST support MFG1 [PKCS#1v2.0]. MFG1 requires a one- 339 way hash function, and it is identified in the parameter field of the 340 MFG1 algorithm identifier. Implementations MUST support SHA-1 341 [SHA1]. The MFG1 algorithm identifier is comprised of the id-mgf1 342 object identifier and a parameter that contains the algorithm 343 identifier of the one-way hash function employed with MFG1. The SHA- 344 1 algorithm identifier is comprised of the id-sha1 object identifier 345 and a parameter of NULL. Implementations that perform encryption 346 Schaad, Housley 6 347 Use of the AES Algorithm in CMS November 2000 349 MUST omit the maskGenFunc field when MFG1 with SHA-1 is used, 350 indicating that the default algorithm was used. Implementations that 351 perform decryption MUST recognize both the id-mgf1 and id-sha1 object 352 identifiers as well as an absent maskGenFunc field as an indication 353 that MFG1 with SHA-1 was used. 355 pSourceFunc identifies the source (and possibly the value) of the 356 encoding parameters, commonly called P. Implementations MUST 357 represent P by an algorithm identifier, id-pSpecified, indicating 358 that P is explicitly provided as an OCTET STRING in the parameters. 359 The default value for P is an empty string. In this case, pHash in 360 EME-OAEP contains the hash of a zero length string. Implementations 361 MUST support a zero length P value. Implementations that perform 362 encryption MUST omit the pSourceFunc field when a zero length P value 363 is used, indicating that the default value was used. Implementations 364 that perform decryption MUST recognize both the id-pSpecified object 365 identifier and an absent pSourceFunc field as an indication that a 366 zero length P value was used. 368 5.2 AES Algorithm Identifiers and Parameters 370 AES is added to the set of symmetric content encryption algorithms in 371 CMS. The AES content-encryption algorithm in Cipher Block Chaining 372 (CBC) mode for the three different key sizes are identified by the 373 OID: 375 id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 } 376 id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 } 377 id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 } 379 The AlgorithmIdentifier parameters field MUST be present, and the 380 parameters field MUST contain a AES-IV associated with this OID 381 contains the initialization vector IV: 383 AES-IV ::= OCTET STRING (SIZE(16)) 385 6 SMIMECapabilities Attribute Conventions 387 An S/MIME client SHOULD announce the set of cryptographic functions 388 it supports by using the S/MIME capabilities attribute. This 389 attribute provides a partial list of OIDs of cryptographic functions 390 and MUST be signed by the client. The algorithm OIDs SHOULD be 391 logically separated in functional categories and MUST be ordered with 392 respect to their preference. 394 RFC 2633, Section 2.5.2 defines the SMIMECapabilities signed 395 attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be 396 used to specify a partial list of algorithms that the software 397 announcing the SMIMECapabilities can support. 399 6.1 RSAES-OEAP SMIMECapability Attribute 401 Schaad, Housley 7 402 Use of the AES Algorithm in CMS November 2000 404 When constructing a signedData object, compliant software MAY include 405 the SMIMECapabilities signed attribute announcing that it supports 406 the RSAES-OAEP algorithm. 408 The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the 409 id-RSAES-OAEP object identifier in the capabilityID field and MUST 410 include the RSAES-OAEP-Default-Identifier SEQUENCE in the parameters 411 field. 413 RSAES-OAEP-Default-Identifier ::= AlgorithmIdentifier 415 id-RSAES-OAEP, 417 sha1Identifier, mgf1SHA1Identifier, pSpecifiedEmptyIdentifier 418 } } 420 When all of the default settings are selected, the SMIMECapability 421 SEQUENCE representing RSAES-OAEP MUST be DER-encoded as: 423 30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00 425 6.2 AES S/MIME Capability Attributes 427 If an S/MIME client is required to support symmetric encryption with 428 AES, the capabilities attribute MUST contain the AES OID specified 429 above in the category of symmetric algorithms. The parameter 430 associated with this OID MUST is AESSMimeCapability. 432 AESSMimeCapabilty ::= NULL 434 The encodings for the mandatory key sizes are: 436 Key Size Capability 437 128 30 0D 06 09 60 86 48 01 65 03 04 01 02 30 00 438 196 30 0D 06 09 60 86 48 01 65 03 04 01 16 30 00 439 256 30 0D 06 09 60 86 48 01 65 03 04 01 2A 30 00 441 When a sending agent creates an encrypted message, it has to decide 442 which type of encryption algorithm to use. In general the decision 443 process involves information obtained from the capabilities lists 444 included in messages received from the recipient, as well as other 445 information such as private agreements, user preferences, legal 446 restrictions, and so on. If users require AES for symmetric 447 encryption, the S/MIME clients on both the sending and receiving side 448 MUST support it, and it MUST be set in the user preferences. 450 7. Security Considerations 452 Note on mix of OEAP and v1.5 RSA encryption from RFC 2437 454 Implementations must protect the RSA private key and the content- 455 encryption key. Compromise of the RSA private key may result in the 456 disclosure of all messages protected with that key. Compromise of 457 the content-encryption key may result in disclosure of the associated 458 encrypted content. 459 Schaad, Housley 8 460 Use of the AES Algorithm in CMS November 2000 462 Implementations must protect the key management private key and the 463 message-authentication key. Compromise of the key management private 464 key permits masquerade of authenticated data. Compromise of the 465 message-authentication key may result in undetectable modification of 466 the authenticated content. 468 The generation of RSA public/private key pairs relies on a random 469 numbers. The use of inadequate pseudo-random number generators 470 (PRNGs) to generate cryptographic keys can result in little or no 471 security. An attacker may find it much easier to reproduce the PRNG 472 environment that produced the keys, searching the resulting small set 473 of possibilities, rather than brute force searching the whole key 474 space. The generation of quality random numbers is difficult. RFC 475 1750 [RANDOM] offers important guidance in this area. 477 8. Open Issues 479 - Key wrap algorithm is undetermined. 480 - Mandatory key sizes for Key Wrap 481 - Mandatory key sizes for AES algorithm 482 - Supplying any patent and licensing statements. 483 - References to each algorithm that would be acceptable to the RFC 484 editor. 485 - Does the oid for key derivation need to be changed since we are 486 using SHA-256 not SHA-1? 488 References 490 CMS Housley, R. Cryptographic Message Syntax. RFC 2630. 491 June 1999. 493 CRYPTO98 Bleichenbacher, D. "Chosen Ciphertext Attacks Against 494 Protocols Based on the RSA Encryption Standard PKCS #1," 495 in H. Krawczyk (editor), Advances in Cryptology - CRYPTO 496 '98 497 Proceedings, Lecture Notes in Computer Science 1462 498 (1998), 499 Springer-Verlag, pp. 1-12. 501 DH E. Rescorla, �Diffie-Hellman Key Agreement Method�, RFC 502 2631, June 1999. 504 MUSTSHOULD Bradner, S. Key Words for Use in RFCs to Indicate 505 Requirement Levels. BCP 14, RFC 2119. March 1997. 507 PKCS#1v1.5 Kaliski, B. PKCS #1: RSA Encryption, Version 1.5. 508 RFC 2313. March 1998. 510 PKCS#1v2.0 Kaliski, B. PKCS #1: RSA Encryption, Version 2.0. 511 RFC 2437. October 1998. 513 PROFILE Housley, R., W. Ford, W. Polk, and D. Solo. Internet 514 Schaad, Housley 9 515 Use of the AES Algorithm in CMS November 2000 517 X.509 Public Key Infrastructure: Certificate and CRL 518 Profile. RFC 2459. January 1999. 520 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 521 Recommendations for Security. RFC 1750. December 1994. 523 RSALABS Bleichenbacher, D., B. Kaliski, and J. Staddon. 524 Recent Results on PKCS #1: RSA Encryption Standard. 525 RSA Laboratories' Bulletin No. 7, June 26, 1998. 526 [Available at 527 http://www.rsasecurity.com/rsalabs/bulletins] 529 SHA1 National Institute of Standards and Technology. 530 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 532 SSL Freier, A., P. Karlton, and P. Kocher. The SSL 533 Protocol, 534 Version 3.0. Netscape Communications. November 1996. 535 [Available at http://draft-freier-ssl-version3-02.txt] 537 TLS Dierks, T. and C. Allen. The TLS Protocol Version 1.0. 538 RFC 2246. January 1999. 540 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 541 Syntax Notation One (ASN.1). 1988. 543 X.209-88 CCITT. Recommendation X.209: Specification of Basic 544 Encoding 545 Rules for Abstract Syntax Notation One (ASN.1). 1988. 547 X.509-88 CCITT. Recommendation X.509: The Directory - 548 Authentication 549 Framework. 1988. 551 Acknowledgements 553 This document is the result of contributions from many 554 professionals. We appreciate the hard work of all members of the 555 IETF S/MIME Working Group. We wish to extend a special thanks to 556 Burt Kaliski. 558 Author's Addresses 560 Jim Schaad 561 Soaring Hawk Consulting 562 Email: jimsch@exmsft.com 564 Russell Housley 565 RSA Laboratories 566 918 Spring Knoll Drive 567 Herndon, VA 20170 568 USA 570 Schaad, Housley 10 571 Use of the AES Algorithm in CMS November 2000 573 rhousley@rsasecurity.com 575 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 576 9, RFC 2026, October 1996. 578 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 579 Levels", BCP 14, RFC 2119, March 1997 581 Schaad, Housley 11