S/MIME Working Group J. Schaad Internet Draft Soaring Hawk Consulting Document: draft-ietf-smime-aes-alg-00.txt November 2000 Expires: May 31, 20001 Use of the Advanced Encryption Algorithm in CMS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments or suggestions for improvement may be made on the "ietf- smime" mailing list, or directly to the author. 1. Abstract This document specifies how to incorporate the Advanced Encryption Standard (AES) candidate algorithm [AES] into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that the AES algorithms may be included in the CMS specification [CMS] for symmetric content and key encryption. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Overview S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME3] is a set of specifications for the secure transport of MIME objects. In Schaad 1 Use of the AES Algorithm in CMS November 2000 the current (S/MIME v3) specifications the mandatory-to-implement symmetric algorithm for content encryption and key encryption is triple-DES (3DES). The algorithm is considered to be both more secure and faster than 3DES. AES is an iterated block cipher with a variable block length and a variable key length. In the base algorithm, the block length and the key length can be independently specified to 128, 192 or 256 bits. AES has fixed the block length to be 128-bits. 4. AES Algorithm AES is a symmetric block cipher with a block size of 128 bits and a key size of 128, 198 or 256-bits. AES is free of intellectual property issues. Compliant implementations MUST support key sizes of 128 and 256 bits. Compliant implementation MAY support a key size of 196 bits. Compliant implementations MUST support a block size of 128- bits. 4.1 Content Encryption AES is added to the set of symmetric content encryption algorithms in CMS. The AES content-encryption algorithm in Cipher Block Chaining (CBC) mode for the three different key sizes are identified by the OID: id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 } id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 } id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 } The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain a AES-IV associated with this OID contains the initialization vector IV: AES-IV ::= OCTET STRING (SIZE(16)) 4.2 Key Wrap NOTE: This section is subject to change when the key wrap algorithm (see section 5) is selected. AES key wrap has the algorithm identifier: id-xxxxx-AESWrap ::= {TBD} The algorithm identifier parameter field MUST be present, and the parameter field MUST contain a AESCBCWrap object: AESCBCWrap ::= NULL The key wrap algorithm used to encrypt an AES content-encryption key with a AES key-encryption key is specified in section 2. Schaad 2 Use of the AES Algorithm in CMS November 2000 Out-of-band distribution of the AES key-encryption key used to encrypt the AES content-encryption key is beyond of the scope of this document. The key encryption key used with the wrapping algorithm MUST be 256- bits. 4.3 S/MIME Capability Attribute An S/MIME client SHOULD announce the set of cryptographic functions it supports by using the S/MIME capabilities attribute. This attribute provides a partial list of OIDs of cryptographic functions and MUST be signed by the client. The algorithm OIDs SHOULD be logically separated in functional categories and MUST be ordered with respect to their preference. If an S/MIME client is required to support symmetric encryption with AES, the capabilities attribute MUST contain the AES OID specified above in the category of symmetric algorithms. The parameter associated with this OID MUST is AESSMimeCapability. AESSMimeCapabilty ::= SEQUENCE KeySize INTEGER } The encodings for the mandatory key sizes are: Key Size Capability 128 30 XX 06 XX YY YY YY 30 04 02 02 00 80 196 30 XX 06 XX YY YY YY 30 04 02 02 00 C0 256 30 XX 06 XX YY YY YY 30 04 02 02 01 00 When a sending agent creates an encrypted message, it has to decide which type of encryption algorithm to use. In general the decision process involves information obtained from the capabilities lists included in messages received from the recipient, as well as other information such as private agreements, user preferences, legal restrictions, and so on. If users require AES for symmetric encryption, the S/MIME clients on both the sending and receiving side MUST support it, and it MUST be set in the user preferences. 5. AES Key Wrap Algorithm NOTE: Although no key wrap algorithms have been announced by NIST, a request has been submitted that they designate a key wrap algorithm as part of the AES standard. In the event that this is done, this entire section is to be replaced with the NIST designated algorithm. Should NIST decide not to provide a key wrap algorithm, it is expected we will develop one based on the current CMS key wrap algorithm. 6. Key Management for AES Schaad 3 Use of the AES Algorithm in CMS November 2000 CMS accommodates three general key management techniques: key transport, key agreement, and previously distributed symmetric key- encryption keys. 6.1 Key Transport for AES Key Transport using RSA-OEAP MUST be implemented to comply with this document. Key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm fields. Key transport encrypted content-encryption keys are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field. Key transport encrypted message-authentication keys are located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo encryptedKey field. 6.2 Key Agreement for AES Implementations MAY include key agreement using X9.42 Ephemeral- Static Diffie-Hellman. If ESDH is implemented, AES-KeyWrap MUST be implemented. A CMS implementation may support mixed key-encryption and content- encryption algorithms. For example, a 128-bit AES content-encryption key may be wrapped with 168-bit Triple DES key-encryption key. Similarly, a 128-bit AES content-encryption key may be wrapped with 256-bit AES key-encryption key. Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters within the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Diffie-Hellman Key Wrap Key Derivation Generation of the an AES key used in doing AES-KeyWrap is done using the method in [DH] with the following modifications: Schaad 4 Use of the AES Algorithm in CMS November 2000 The Hash function H will be [SHA-256] rather than SHA-1. NOTE: 2 examples to be provided at this location. 6.3 Symmetric Key-Encryption Key Algorithms with AES CMS implementations MAY include symmetric key-encryption key management. Implementations compliant with this document MUST include AES-256 key-encryption keys wrapping AES content-encryption keys. A CMS implementation may support mixed key-encryption and content-encryption algorithms. For example, a 128-bit AES content- encryption key may be wrapped with 168-bit Triple-DES key-encryption key or with a 256-bit AES key-encryption key. Key wrap algorithm identifiers are located in the EnvelopedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm fields. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message- authentication keys are located in the AuthenticatedData RecipientInfos KEKRecipientInfo encryptedKey field. The output of a key agreement algorithm is a key-encryption key, and this key-encryption key is used to encrypt the content-encryption key. In conjunction with key agreement algorithms, CMS implementations must include encryption of content-encryption keys with the pairwise key-encryption key generated using a key agreement algorithm. To support key agreement, key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameter of the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field, wrapped message- authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. 7. Security Considerations To be supplied Note on mix of OEAP and v1.5 RSA encryption from RFC 2437 8. Open Issues - Key wrap algorithm is undetermined. - Mandatory key sizes for Key Wrap - Mandatory key sizes for AES algorithm - Supplying any patent and licensing statements. Schaad 5 Use of the AES Algorithm in CMS November 2000 - References to each algorithm that would be acceptable to the RFC editor. References [DH] E. Rescorla, ôDiffie-Hellman Key Agreement Methodö, RFC 2631, June 1999. [IPR] See the "IETF Page of Intellectual Property Rights Notices", http://www.ietf.cnri.reston.va.us/ipr.html [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet Request for Comments RFC 2119, March 1997. [CMS] R. Housley, "Cryptographic Message Syntax", Internet Request for Comments RFC 2630, June 1999. [RSA-OEAP] R. Housley, ôUse of the RSAES-OEAP Key Transport Algorithm in CMSö, draft-ietf-smime-cms-rsaes-oeap.txt, June 2000. [SMIME3] B. Ramsdell, "S/MIME Version 3 Certificate Handling", Internet Request for Comments RFC 2632, June 1999. B. Ramsdell, "S/MIME Version 3 Message Specification", Internet Request for Comments RFC 2633, June 1999. 11. Author's Addresses Jim Schaad Soaring Hawk Consulting Email: jimsch@exmsft.com Schaad 6