[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3565

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


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/