idnits 2.17.1 draft-ietf-smime-aes-alg-00.txt: ** The Abstract section seems to be numbered -(284): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(296): 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 3 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 350 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 (November 2000) is 8562 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) -- Looks like a reference, but probably isn't: '1' on line 13 == Missing Reference: 'AES' is mentioned on line 35, but not defined -- Looks like a reference, but probably isn't: '2' on line 46 == Missing Reference: 'SHA-256' is mentioned on line 223, but not defined == Unused Reference: 'IPR' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RSA-OEAP' is defined on line 296, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPR' ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) -- No information found for draft-ietf-smime-cms-rsaes-oeap - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RSA-OEAP' ** Obsolete normative reference: RFC 2633 (ref. 'SMIME3') (Obsoleted by RFC 3851) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 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-00.txt November 2000 5 Expires: May 31, 20001 7 Use of the Advanced 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 RFC2026 [1]. 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 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Comments or suggestions for improvement may be made on the "ietf- 30 smime" mailing list, or directly to the author. 32 1. Abstract 34 This document specifies how to incorporate the Advanced Encryption 35 Standard (AES) candidate algorithm [AES] into the S/MIME 36 Cryptographic Message Syntax (CMS) as an additional algorithm for 37 symmetric encryption. The relevant OIDs and processing steps are 38 provided so that the AES algorithms may be included in the CMS 39 specification [CMS] for symmetric content and key encryption. 41 2. Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in RFC-2119 [2]. 47 3. Overview 49 S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME3] is a 50 set of specifications for the secure transport of MIME objects. In 52 Schaad 1 53 Use of the AES Algorithm in CMS November 2000 55 the current (S/MIME v3) specifications the mandatory-to-implement 56 symmetric algorithm for content encryption and key encryption is 57 triple-DES (3DES). The algorithm is considered to be both more 58 secure and faster than 3DES. 60 AES is an iterated block cipher with a variable block length and a 61 variable key length. In the base algorithm, the block length and the 62 key length can be independently specified to 128, 192 or 256 bits. 63 AES has fixed the block length to be 128-bits. 65 4. AES Algorithm 67 AES is a symmetric block cipher with a block size of 128 bits and a 68 key size of 128, 198 or 256-bits. AES is free of intellectual 69 property issues. Compliant implementations MUST support key sizes of 70 128 and 256 bits. Compliant implementation MAY support a key size of 71 196 bits. Compliant implementations MUST support a block size of 128- 72 bits. 74 4.1 Content Encryption 76 AES is added to the set of symmetric content encryption algorithms in 77 CMS. The AES content-encryption algorithm in Cipher Block Chaining 78 (CBC) mode for the three different key sizes are identified by the 79 OID: 81 id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 } 82 id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 } 83 id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 } 85 The AlgorithmIdentifier parameters field MUST be present, and the 86 parameters field MUST contain a AES-IV associated with this OID 87 contains the initialization vector IV: 89 AES-IV ::= OCTET STRING (SIZE(16)) 91 4.2 Key Wrap 93 NOTE: This section is subject to change when the key wrap algorithm 94 (see section 5) is selected. 96 AES key wrap has the algorithm identifier: 98 id-xxxxx-AESWrap ::= {TBD} 100 The algorithm identifier parameter field MUST be present, and the 101 parameter field MUST contain a AESCBCWrap object: 103 AESCBCWrap ::= NULL 105 The key wrap algorithm used to encrypt an AES content-encryption key 106 with a AES key-encryption key is specified in section 2. 108 Schaad 2 109 Use of the AES Algorithm in CMS November 2000 111 Out-of-band distribution of the AES key-encryption key used to 112 encrypt the AES content-encryption key is beyond of the scope of this 113 document. 115 The key encryption key used with the wrapping algorithm MUST be 256- 116 bits. 118 4.3 S/MIME Capability Attribute 120 An S/MIME client SHOULD announce the set of cryptographic functions 121 it supports by using the S/MIME capabilities attribute. This 122 attribute provides a partial list of OIDs of cryptographic functions 123 and MUST be signed by the client. The algorithm OIDs SHOULD be 124 logically separated in functional categories and MUST be ordered with 125 respect to their preference. If an S/MIME client is required to 126 support symmetric encryption with AES, the capabilities attribute 127 MUST contain the AES OID specified above in the category of symmetric 128 algorithms. The parameter associated with this OID MUST is 129 AESSMimeCapability. 131 AESSMimeCapabilty ::= SEQUENCE 133 KeySize INTEGER 134 } 136 The encodings for the mandatory key sizes are: 138 Key Size Capability 139 128 30 XX 06 XX YY YY YY 30 04 02 02 00 80 140 196 30 XX 06 XX YY YY YY 30 04 02 02 00 C0 141 256 30 XX 06 XX YY YY YY 30 04 02 02 01 00 143 When a sending agent creates an encrypted message, it has to decide 144 which type of encryption algorithm to use. In general the decision 145 process involves information obtained from the capabilities lists 146 included in messages received from the recipient, as well as other 147 information such as private agreements, user preferences, legal 148 restrictions, and so on. If users require AES for symmetric 149 encryption, the S/MIME clients on both the sending and receiving side 150 MUST support it, and it MUST be set in the user preferences. 152 5. AES Key Wrap Algorithm 154 NOTE: Although no key wrap algorithms have been announced by NIST, a 155 request has been submitted that they designate a key wrap algorithm 156 as part of the AES standard. In the event that this is done, this 157 entire section is to be replaced with the NIST designated algorithm. 158 Should NIST decide not to provide a key wrap algorithm, it is 159 expected we will develop one based on the current CMS key wrap 160 algorithm. 162 6. Key Management for AES 164 Schaad 3 165 Use of the AES Algorithm in CMS November 2000 167 CMS accommodates three general key management techniques: key 168 transport, key agreement, and previously distributed symmetric key- 169 encryption keys. 171 6.1 Key Transport for AES 173 Key Transport using RSA-OEAP MUST be implemented to comply with this 174 document. 176 Key transport algorithm identifiers are located in the EnvelopedData 177 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and 178 AuthenticatedData RecipientInfos KeyTransRecipientInfo 179 keyEncryptionAlgorithm fields. 181 Key transport encrypted content-encryption keys are located in the 182 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 183 field. Key transport encrypted message-authentication keys are 184 located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo 185 encryptedKey field. 187 6.2 Key Agreement for AES 189 Implementations MAY include key agreement using X9.42 Ephemeral- 190 Static Diffie-Hellman. If ESDH is implemented, AES-KeyWrap MUST be 191 implemented. 193 A CMS implementation may support mixed key-encryption and content- 194 encryption algorithms. For example, a 128-bit AES content-encryption 195 key may be wrapped with 168-bit Triple DES key-encryption key. 196 Similarly, a 128-bit AES content-encryption key may be wrapped with 197 256-bit AES key-encryption key. 199 Key agreement algorithm identifiers are located in the EnvelopedData 200 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 201 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 202 keyEncryptionAlgorithm fields. 204 Key wrap algorithm identifiers are located in the KeyWrapAlgorithm 205 parameters within the EnvelopedData RecipientInfos 206 KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData 207 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. 209 Wrapped content-encryption keys are located in the EnvelopedData 210 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 211 encryptedKey field. Wrapped message-authentication keys are located 212 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 213 RecipientEncryptedKeys encryptedKey field. 215 Diffie-Hellman Key Wrap Key Derivation 217 Generation of the an AES key used in doing AES-KeyWrap is done using 218 the method in [DH] with the following modifications: 220 Schaad 4 221 Use of the AES Algorithm in CMS November 2000 223 The Hash function H will be [SHA-256] rather than SHA-1. 225 NOTE: 2 examples to be provided at this location. 227 6.3 Symmetric Key-Encryption Key Algorithms with AES 229 CMS implementations MAY include symmetric key-encryption key 230 management. Implementations compliant with this document MUST 231 include AES-256 key-encryption keys wrapping AES content-encryption 232 keys. A CMS implementation may support mixed key-encryption and 233 content-encryption algorithms. For example, a 128-bit AES content- 234 encryption key may be wrapped with 168-bit Triple-DES key-encryption 235 key or with a 256-bit AES key-encryption key. 237 Key wrap algorithm identifiers are located in the EnvelopedData 238 RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and 239 AuthenticatedData RecipientInfos KEKRecipientInfo 240 keyEncryptionAlgorithm fields. 242 Wrapped content-encryption keys are located in the EnvelopedData 243 RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- 244 authentication keys are located in the AuthenticatedData 245 RecipientInfos KEKRecipientInfo encryptedKey field. 247 The output of a key agreement algorithm is a key-encryption key, and 248 this key-encryption key is used to encrypt the content-encryption 249 key. In conjunction with key agreement algorithms, CMS 250 implementations must include encryption of content-encryption keys 251 with the pairwise key-encryption key generated using a key agreement 252 algorithm. To support key agreement, key wrap algorithm identifiers 253 are located in the KeyWrapAlgorithm parameter of the EnvelopedData 254 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 255 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 256 keyEncryptionAlgorithm fields. Wrapped content-encryption keys are 257 located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo 258 RecipientEncryptedKeys encryptedKey field, wrapped message- 259 authentication keys are located in the AuthenticatedData 260 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 261 encryptedKey field. 263 7. Security Considerations 265 To be supplied 267 Note on mix of OEAP and v1.5 RSA encryption from RFC 2437 269 8. Open Issues 271 - Key wrap algorithm is undetermined. 272 - Mandatory key sizes for Key Wrap 273 - Mandatory key sizes for AES algorithm 274 - Supplying any patent and licensing statements. 276 Schaad 5 277 Use of the AES Algorithm in CMS November 2000 279 - References to each algorithm that would be acceptable to the RFC 280 editor. 282 References 284 [DH] E. Rescorla, �Diffie-Hellman Key Agreement Method�, RFC 2631, 285 June 1999. 287 [IPR] See the "IETF Page of Intellectual Property Rights Notices", 288 http://www.ietf.cnri.reston.va.us/ipr.html 290 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 291 Levels", Internet Request for Comments RFC 2119, March 1997. 293 [CMS] R. Housley, "Cryptographic Message Syntax", Internet Request for 294 Comments RFC 2630, June 1999. 296 [RSA-OEAP] R. Housley, �Use of the RSAES-OEAP Key Transport Algorithm in 297 CMS�, draft-ietf-smime-cms-rsaes-oeap.txt, June 2000. 299 [SMIME3] B. Ramsdell, "S/MIME Version 3 Certificate Handling", Internet 300 Request for Comments RFC 2632, June 1999. 301 B. Ramsdell, "S/MIME Version 3 Message Specification", 302 Internet Request for Comments RFC 2633, June 1999. 304 11. Author's Addresses 306 Jim Schaad 307 Soaring Hawk Consulting 308 Email: jimsch@exmsft.com 310 Schaad 6