S/MIME Working Group                                         J. Schaad
Internet Draft                                 Soaring Hawk Consulting
Document: draft-ietf-smime-aes-alg-04.txt                   R. Housley draft-ietf-smime-aes-alg-05.txt
Expires: July 2002                                    RSA Laboratories
                                                          January May 2003                                        November 2002

               Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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 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.

Abstract

   This document specifies the conventions for using the Advanced
   Encryption Standard (AES) algorithm [AES] for encryption and the
   RSAES-OAEP key transport algorithm [PKCS#1v2.0] for key management with the
   Cryptographic Message Syntax (CMS) [CMS].

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
   [MUSTSHOULD].

1  Overview

   This document specifies the conventions for using the RSAES-OAEP key
   transport algorithm and Advanced Encryption

   Standard (AES) content encryption algorithm with the Cryptographic
   Message Syntax [CMS] enveloped-data and encrypted-data content types.

Schaad, Housley                                                      1 
                   Use of the AES Algorithm in CMS      February 2002

   This document presents the use of the two algorithms together, since
   we anticipate that they will be used together.  However, the two
   algorithms can be used independently.  For example, RSA-OAEP could be

   used to transport Triple-DES keys, and AES keys could be distributed
   out-of-band for use with mail lists.

   CMS values are generated using ASN.1 [X.208-88], using the Basic
   Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules
   (DER) [X.509-88].

1.1  AES
Schaad                                                               1 
                   Use of the AES Algorithm in CMS          July 2002

   The Advanced Encryption Standard (AES) [AES] was developed to replace

   DES [DES].  The AES Federal Information Processing Standard (FIPS)
   Publication specifies a cryptographic algorithm for use by U.S.
   Government organizations.  However, the AES will also be widely used
   by organizations, institutions, and individuals outside of the U.S.
   Government.

   Two researchers who developed and submitted the Rijndael algorithm
   for consideration are both cryptographers from Belgium: Dr. Joan
   Daemen of Proton World International and Dr. Vincent Rijmen, a
   postdoctoral researcher in the Electrical Engineering Department of
   Katholieke Universiteit Leuven.

   The National Institute of Standards and technology (NIST) selected
   the Rijndael algorithm for AES because it offers a combination of
   security, performance, efficiency, ease of implementation, and
   flexibility.  Specifically, Rijndael appears to be consistently a
   very good performer in both hardware and software across a wide range

   of computing environments regardless of its use in feedback or non-
   feedback modes.  Its key setup time is excellent, and its key agility

   is good.  The very low memory requirements of the Rijndael algorithm
   make it very well suited for restricted-space environments, in which
   it also demonstrates excellent performance.  The Rijndael algorithm
   operations are among the easiest to defend against power and timing
   attacks.  Additionally, it appears that some defense can be provided
   against such attacks without significantly impacting the algorithm's
   performance.  Finally, the algorithm's internal round structure
   appears to have good potential to benefit from instruction-level
   parallelism.

   The AES specifies three key sizes: 128, 192 and 256 bits.

1.2  RSA-OAEP

   When the variant

2  Enveloped-data Conventions

   The CMS enveloped-data content type consists of the RSA key transport encrypted content and

   wrapped content-encryption keys for one or more recipients.  The AES
   algorithm specified in PKCS

   #1 Version 1.5 [PKCS#1v1.5] is used to encrypt the content.

   Compliant software MUST meet the requirements for constructing an
   enveloped-data content type stated in [CMS] Section 6, "Enveloped-
   data Content Type".

   The AES content-encryption key MUST be randomly generated for each
   instance of an enveloped-data content type.  The content-encryption
   key management, it (CEK) is
   vulnerable used to adaptive chosen ciphertext attacks.  This attack is
   described in [RSALAB] and [CRYPTO98].  The use encrypt the content.

   AES can be used with the enveloped-data content type using any of PKCS #1 Version 1.5 the

   following key transport management techniques defined in interactive applications [CMS] Section 6.

   1) Key Transport: The AES CEK is especially vulnerable,
   but countermeasures are described in [MMA].  Exploitation of this
   identified vulnerability, revealing uniquely wrapped for each recipient
   using the result of a particular recipient's public RSA
   decryption, requires access to an oracle which will respond to
 Schaad, Housley key and other values.  Section 2.2
   provides additional details.

 Schaad                                                                2
                   Use of the AES Algorithm in CMS      February          July 2002

   hundreds of thousands of ciphertexts, which are constructed
   adaptively in response to previously-received replies providing
   information on the successes or failures of attempted decryption
   operations.

   2) Key Agreement: The attack appears significantly less feasible in store-and-forward
   environments, such as S/MIME.  When PKCS #1 Version 1.5 key transport AES CEK is applied as an intermediate encryption layer within an interactive
   request-response communications environment, exploitation could be
   more feasible.  However, Secure Sockets Layer (SSL) [SSL] and
   Transport Layer Security (TLS) [TLS] protocol implementations could
   include countermeasures that detect and prevent Bleichenbacher's uniquely wrapped for each recipient
   using a pairwise symmetric key-encryption key (KEK) generated using
   DH-ES [DH] using the originator's randomly generated private key, the

   recipient's public DH key, and other chosen-ciphertext attacks, without changing the way values.  Section 2.3 provides
   additional details.

   3) Previously Distributed Symmetric KEK:  The AES CEK is wrapped
   using a previously distributed symmetric KEK (such as a Mail List
   Key).  The methods by which the RSA key

   transport algorithm symmetric KEK is used.  These countermeasures generated and
   distributed are performed
   within the protocol level.  In beyond the interest scope of long-term security
   assurance, it this document.  Section 2.4
   provides additional details.

   4) Password Encryption:  The AES CEK is prudent to adopt an improved cryptographic technique

   rather than embedding countermeasures in protocols.

   An updated version of PKCS #1 has been published: PKCS #1 Version 2.0

   [PKCS#1v2.0].  This new document supersedes RFC 2313 [PKCS#1v1.5].
   PKCS #1 Version 2.0 preserves support for the encryption padding
   format defined in PKCS #1 Version 1.5 [PKCS#1v1.5], and it also
   defines wrapped using a new alternative.  To resolve the adaptive chosen ciphertext

   vulnerability, KEK derived
   from a password or other shared secret.  Section 2.5 provides
   additional details.

   Documents defining the PKCS #1 Version 2.0 specifies and recommends use of Optimal Asymmetric Encryption Padding (OAEP) when RSA encryption
   is used the Other Recipient Info structure will

   need to provide confidentiality, such as key transport.

   This document specifies define the proper use of RSAES-OAEP key transport for the AES algorithm

   in if desired.

2.1  EnvelopedData Fields

   The enveloped-data content type is ASN.1 encoded using the Cryptographic Message Syntax (CMS) [CMS].  CMS can
   EnvelopedData syntax.  The fields of the EnvelopedData syntax MUST be used in
   either

   populated as follows:

   The EnvelopedData version is determined based on a store-and-forward or an interactive request-response
   environment.

   CMS supports variety number of architectures factors.

   See [CMS] section 6.1 for certificate-based key
   management, particularly the one defined by the PKIX working group
   [PROFILE].  PKCS #1 Version 1.5 and PKCS #1 Version 2.0 require algorithm to determine this value.

   The EnvelopedData recipientInfos CHOICE is dependent on the
   same RSA public key
   management technique used.  Section 2.2, 2.3, 2.4 and 2.5 provide
   additional information.  Thus,

   The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm
   field MUST specify a certified RSA public key
   may be used symmetric encryption algorithm.  Implementations

   MUST support content encryption with either RSA key transport technique.

2  Enveloped-data Conventions AES, but implementations MAY
   support other algorithms as well.

   The EnvelopedData unprotectedAttrs MAY be present.

2.2  KeyTransRecipientInfo Fields

   The CMS enveloped-data content type consists of encrypted content and

   wrapped content-encryption keys for one or more recipients.  The
   RSAES-OAEP key transport algorithm is used to wrap ASN.1 encoded using the content-
   encryption key for one recipient.
   EnvelopedData syntax.  The AES algorithm fields of the EnvelopedData syntax MUST be

   populated as follows:

   The KeyTransRecipientInfo version MUST be either 0 or 2.  If the
   RecipientIdentifier is used to
   encrypt the content.

   Compliant software CHOICE issuerAndSerialNumber, then the
   version MUST meet be 0.  If the requirements for constructing an
   enveloped-data content type stated in [CMS] Section 6, "Enveloped-
   data Content Type".

   An AES content-encryption key RecipientIdentifier is
   subjectKeyIdentifier, then the version MUST be randomly generated 2.

   The KeyTransRecipientInfo RecipientIdentifier provides two
   alternatives for each
   instance of an enveloped-data content type. specifying the recipient's certificate, and thereby
   the recipient's public key.  The content-encryption
   key (CEK) recipient's certificate MUST contain

   a RSA public key.  The CEK is used to encrypt encrypted with the content.

 Schaad, Housley recipient's RSA
 Schaad                                                                3
                   Use of the AES Algorithm in CMS      February          July 2002

   AES can be used with

   public key.  The issuerAndSerialNumber alternative identifies the enveloped-data content type using any of
   recipient's certificate by the

   following key management techniques defined in [CMS] Section 6.

   1) Key Transport: The AES CEK is uniquely wrapped for each recipient
   using issuer's distinguished name and the
   certificate serial number; the subjectKeyIdentifier identifies the
   recipient's public RSA certificate by the X.509 subjectKeyIdentifier extension
   value.

   The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies the
   key transport algorithm (i.e. RSAES-OAEP [RSA-OAEP]), and other values.  Section 2.2
   provides additional details.

   2) Key Agreement: The AES the
   associated parameters used to encrypt the CEK is uniquely wrapped for each recipient
   using a pairwise symmetric key-encryption key (KEK) generated using
   DH-ES [DH] using the originator's randomly generated private key, recipient.

   The KeyTransRecipientInfo encryptedKey is the result of encrypting
   the CEK with the recipient's RSA public DH key, and other values.  Section key.

2.3 provides
   additional details.

   3) Previously Distributed Symmetric KEK:  The AES CEK is wrapped
   using a previously distributed symmetric KEK (such as a Mail List
   Key).  The methods by which  KeyAgreeRecipientInfo Fields

   This section describes the symmetric KEK is generated conventions for using ES-DH and
   distributed are beyond the scope of this document.  Section 2.4
   provides additional details.

   4) Password Encryption:  The AES CEK is wrapped using a KEK derived
   from a password or other shared secret.  Section 2.5 provides
   additional details.

2.1  EnvelopedData Fields

   The with
   the CMS enveloped-data content type to support key agreement.  When
   key agreement is ASN.1 encoded using the
   EnvelopedData syntax.  The fields of used, then the EnvelopedData syntax RecipientInfo keyAgreeRecipientInfo
   CHOICE MUST be

   populated as follows: used.

   The EnvelopedData KeyAgreeRecipient version is determined based on a number of factors.

   See [CMS] section 6.1 for the algorithm to determine this value. MUST be 3.

   The EnvelopedData originatorInfo field is not used for the RSAES-OAEP

   key transport algorithm.  However, this field MAY MUST be present to
   support recipients using other key management algorithms.

   The EnvelopedData recipientInfos CHOICE is dependent on the key
   management technique used.  Section 2.2, 2.3, 2.4 and 2.5 provide
   additional information. originatorKey
   alternative.  The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm
   field MUST specify a symmetric encryption algorithm.  Implementations originatorKey algorithm fields MUST support content encryption contain the dh-
   public-number object identifier with AES, but implementations MAY
   support other algorithms as well. absent parameters.  The
   originatorKey publicKey MUST contain the originator's ephemeral
   public key.

   The EnvelopedData unprotectedAttrs ukm MAY be present.

2.2  KeyTransRecipientInfo Fields

   The enveloped-data content type EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH
   algorithm identifier [CMSALG].

2.3.1  ES-DH/AES Key Derivation

   Generation of the AES KEK to be used with the AES-key wrap algorithm
   is ASN.1 encoded done using the
   EnvelopedData syntax. method described in [DH].

2.3.1.1  Example 1

   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
                      0a 0b 0c 0d 0e 0f 10 11 12 13

   The fields key wrap algorithm is AES-128 wrap, so we need 128 bits (16
   bytes) of keying material.

   No partyAInfo is used.

   Consequently, the EnvelopedData syntax MUST be

   populated as follows:

 Schaad, Housley input to SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
   30 1b
      30 11
         06 09 60 86 48 01 65 03 04 01 05           ; AES-128 wrap OID
 Schaad                                                                4
                   Use of the AES Algorithm in CMS      February          July 2002

   The KeyTransRecipientInfo version MUST be either 0 or 2.  If

         04 04
            00 00 00 01                             ; Counter
      a2 06
         04 04
         00 00 00 80                                ; key length

   And the
   RecipientIdentifier output is the CHOICE issuerAndSerialNumber, then the
   version MUST be 0.  If the RecipientIdentifier is
   subjectKeyIdentifier, then the version MUST be 2.

   The KeyTransRecipientInfo RecipientIdentifier provides two
   alternatives for specifying the recipient's certificate, and thereby
   the recipient's public key.  The recipient's certificate MUST contain

   a RSA public key.  The CEK 32 bytes:

   d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9

   Consenquently,

   K= d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64

2.3.1.2  Example 2

   ZZ is encrypted with the recipient's RSA
   public key.  The issuerAndSerialNumber alternative identifies the
   recipient's certificate by the issuer's distinguished name and the
   certificate serial number; the subjectKeyIdentifier identifies the
   recipient's certificate by the X.509 subjectKeyIdentifier extension
   value.

   The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies the
   RSAES-OAEP algorithm, and the associated parameters used to encrypt the CEK for the recipient. 20 bytes 00 01 02 03 04 05 06 07 08 09
                      0a 0b 0c 0d 0e 0f 10 11 12 13

   The key encryption process is described
   in [PKCS#1v2.0].  See section 4.2 of this document for the wrap algorithm
   identifier and the parameter syntax.

   The KeyTransRecipientInfo encryptedKey is the result of encrypting
   the CEK with the recipient's RSA public AES-256 key using the RSAES-OAEP
   algorithm.

   Note: When using a Triple-DES CEK, implementations MUST adjust the
   parity wrap, so we need 256 bits for each DES key comprising the Triple-DES key prior to
   RSAES-OAEP encryption.

   Note: (32
   bytes) of keying material.

   The same key wrap algorithm is partyAInfo used for both Two-key Triple-DES

   and Three-key Triple-DES CEK keys.  When a Two-key Triple-DES key is
   to be wrapped, a third DES key with the same value as the first DES
   key is created.  Thus, all wrapped Triple-DES keys include three DES
   keys.

2.3  KeyAgreeRecipientInfo Fields

   This section describes the conventions for using ES-DH and AES with
   the CMS enveloped-data content type to support key agreement.  When
   key agreement is used, then the RecipientInfo keyAgreeRecipientInfo
   CHOICE MUST be used.

   The KeyAgreeRecipient version MUST be 3.

   The EnvelopedData originatorInfo field MUST be the originatorKey
   alternative.  The originatoryKey algorithm fields MUST contain the
   dh-public-number object identifier with absent parameters.  The
   originatorKey publicKey MUST contain the originator's ephemeral
   public key.

   The EnvelopedData ukm MAY be present.

   The EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH
   algorithm identifier [CMSALG].
 Schaad, Housley                5 
                   Use of the AES Algorithm in CMS      February 2002

2.3.1  ES-DH/AES Key Derivation

   Generation of the AES KEK to be used with the AES -key wrap algorithm

   is done using the method described in [DH].

2.3.1.1  Example 1

   ZZ is the 20 64 bytes 00

   01 02 03 04 05 06 07 08 09
                      0a 0b 0c 0d 0e 0f 10 11 12 13

   The key wrap algorithm is AES-128 wrap, so we need 128 bits (16
   bytes) of keying material.

   No partyAInfo is used. 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01

   Consequently, the input to first invocation of SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
   30 1b 5f
      30 11
         06 09 60 86 48 01 65 03 04 01 05 2c            ; AES-128 AES-256 wrap OID
         04 04
            00 00 00 01                              ; Counter
      a2 06
         04 04
         00 00 00 80                                ; key length

   And the output is the 32 bytes:

   d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9

   Consenquently,

   K= d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64

2.3.1.2  Example 2

   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
                      0a 0b 0c 0d 0e 0f 10 11 12 13

   The key wrap algorithm is AES-256 key wrap, so we need 256 bits (32
   bytes) of keying material.

   The partyAInfo used is the 64 bytes

   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01

   Consequently, the input to first invocation of SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
 Schaad, Housley                6 
                   Use of the AES Algorithm in CMS      February 2002

   30 5f
      30 11
         06 09 60 86 48 01 65 03 04 01 2c            ; AES-256 wrap OID
         04 04
            00 00 00 01                              ; Counter
      a0 42
      a0 42
         04 40
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo

            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
      a2 06
         04 04
            00 00 01 00                              ; key length

   And the output is the 20 bytes:

   6f da b9 fa 67 09 30 3e 7e 2f 68 50 29 6f 28 fb 1b a6 4e 2a

   The input to second invocation of SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
 Schaad                                                                5
                   Use of the AES Algorithm in CMS          July 2002

   30 5f
      30 11
         06 09 60 86 48 01 65 03 04 01 2c            ; AES-256 wrap OID
         04 04
            00 00 00 02                              ; Counter
      a0 42
         04 40
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo

            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
      a2 06
         04 04
            00 00 01 00                              ; key length

   And the output is the 20 bytes:

   73 36 a5 ae 90 33 31 39 cb 3f 0e 90 cd d8 03 96 66 36 61 b0

   Consequently,

   K = 6f da b9 fa 67 09 30 3e 7e 2f 68 50 29 6f 28 fb 1b a6 4e 2a
       73 36 a5 ae 90 33 31 39 cb 3f 0e 90

2.3.2  AES CEK Wrap Process

   The AES key wrap algorithm encrypts one AES key in another AES key.
   The algorithm produces an output 64-bits longer than the input AES
   CEK, the additional bits are a checksum.  The algorithm uses 6*n AES
   encryption/decryption operations where n is number of 64-bit blocks

 Schaad, Housley                7 
                   Use of the AES Algorithm in CMS      February 2002

   in the AES CEK.  Full details of the AES key wrap algorithm are
   available at [AES-WRAP].

   NIST has assigned the following OIDs to define the AES key wrap
   algorithm.

        id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
        id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
        id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }

   In all cases the parameters field MUST be absent.  The OID gives the
   KEK key size, but does not make any statements as to the size of the
   wrapped AES CEK.  Implementations MAY use different KEK and CEK
   sizes.  Implements MUST support the CEK and the KEK having the same
   length.  If different lengths are supported, the KEK MUST be of equal

   or greater length than the CEK.

2.4  KEKRecipientInfo Fields

   This section describes the conventions for using AES with the CMS
   enveloped-data content type to support previously distributed
   symmetric KEKs.  When a previously distributed symmetric KEK is used
   to wrap the AES CEK, then the RecipientInfo KEKRecipientInfo CHOICE
   MUST be used.  The methods used to generate and distribute the
   symmetric KEK are beyond the scope of this document.  One possible
   method of distributing keys is documented in [SYMKEYDIST].

   The KEKRecipientInfo fields MUST be populated as specified in [CMS]
   Section 6.2.3, KEKRecipientInfo Type.

   The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be
   one of the OIDs defined in section 2.3.2 indicating that the AES wrap

   function is used to wrap the AES CEK. The KEKRecipientInfo
   keyEncryptionAlgorithm parameters field MUST be absent.

   The KEKRecipientInfo encryptedKey field MUST include the AES CEK
   wrapped using the previously distributed symmetric KEK as input to
   the AES wrap function.

2.5  PasswordRecipientInfo Fields

   This section describes the conventions for using AES with the CMS
   enveloped-data content type to support password-based key management.

   When a password derived KEK is used to wrap the AES CEK, then the
   RecipientInfo PasswordRecipientInfo CHOICE MUST be used.

   The keyEncryptionAlgorithm algorithm field MUST be one of the OIDs
   defined in section 2.3.2 indicating fe dc ba 98 76 54 32 01
      a2 06
         04 04
            00 00 01 00                              ; key length

   And the AES wrap function output is used to
   wrap the 20 bytes:

   73 36 a5 ae 90 33 31 39 cb 3f 0e 90 cd d8 03 96 66 36 61 b0

   Consequently,

   K = 6f da b9 fa 67 09 30 3e 7e 2f 68 50 29 6f 28 fb 1b a6 4e 2a
       73 36 a5 ae 90 33 31 39 cb 3f 0e 90

2.3.2  AES CEK.  The keyEncryptionAlgorithm parameters field MUST
   be absent. CEK Wrap Process

   The encryptedKey field MUST be the result of the AES key wrap algorithm applied to the AES CEK value.

 Schaad, Housley                8 
                   Use of the AES Algorithm in CMS      February 2002

3  Encrypted-data Conventions

   The encrypted-data content type is ASN.1 encoded using the
   EncryptededData syntax.  The fields of the EncryptedData syntax MUST
   be populated as follows:

   The EncryptedData version is determined based on a number of factors.

   See [CMS] section 9.1 for the algorithm to determine this value.

   The EncryptedData encryptedContentInfo contentEncryptionAlgorithm
   field MUST specify a symmetric encryption algorithm.  Implementations

   MUST support encryption using AES, but implementations MAY support
   other algorithms as well.

   The EncryptedData unprotectedAttrs MAY be present.

4  Algorithm Identifiers and Parameters

   This section specified algorithm identifiers for the encrypts one AES encryption
   algorithm and the RSAES-OAEP key transport algorithm.

4.1 in another AES Algorithm Identifiers and Parameters key.
   The AES algorithm is defined in [AES].  RSA #1 v1.5 [PKCS#1v1.5]
   MUST NOT be used to transport AES keys.  RSAES-OAEP [PKCS#1v2.0] MAY
   be used to transport produces an output 64-bits longer than the input AES keys.
   CEK, the additional bits are a checksum.  The algorithm uses 6*n AES
   encryption/decryption operations where n is added to the set number of symmetric content encryption algorithms
   defined 64-bit blocks
   in [CMSALG].  The the AES content-encryption algorithm, in Cipher

   Block Chaining (CBC) mode, for CEK.  Full details of the three different AES key sizes wrap algorithm are
   identified by
   available at [AES-WRAP].

   NIST has assigned the following object identifiers:

       id-aes128-CBC OIDs to define the AES key wrap
   algorithm.

        id-aes128-wrap OBJECT IDENTIFIER ::= { aes 2 5 }
       id-aes192-CBC
        id-aes192-wrap OBJECT IDENTIFIER ::= { aes 22 25 }
       id-aes256-CBC
        id-aes256-wrap OBJECT IDENTIFIER ::= { aes 42 45 }

   The AlgorithmIdentifier

   In all cases the parameters field MUST be present, and absent.  The OID gives the
   parameters field
   KEK key size, but does not make any statements as to the size of the
   wrapped AES CEK.  Implementations MAY use different KEK and CEK
   sizes.  Implements MUST contain a AES-IV:

       AES-IV ::= OCTET STRING (SIZE(16))

   Content encryption algorithm identifiers are located in support the
   EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm CEK and the

   EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.

   Content encryption algorithms KEK having the same
   length.  If different lengths are supported, the KEK MUST be of equal

   or greater length than the CEK.

2.4  KEKRecipientInfo Fields

   This section describes the conventions for using AES with the CMS
   enveloped-data content type to support previously distributed
   symmetric KEKs.  When a previously distributed symmetric KEK is used
   to encrypt wrap the content located

   in AES CEK, then the EnvelopedData EncryptedContentInfo encryptedContent and RecipientInfo KEKRecipientInfo CHOICE
 Schaad                                                                6
                   Use of the
   EncryptedData EncryptedContentInfo encryptedContent fields.

4.2  RSAES-OAEP AES Algorithm Identifiers in CMS          July 2002

   MUST be used.  The methods used to generate and Parameters distribute the
   symmetric KEK are beyond the scope of this document.  One possible
   method of distributing keys is documented in [SYMKEYDIST].

   The RSAES-OAEP key transport KEKRecipientInfo fields MUST be populated as specified in [CMS]
   Section 6.2.3, KEKRecipientInfo Type.

   The KEKRecipientInfo keyEncryptionAlgorithm algorithm is field MUST be
   one of the RSA encryption scheme OIDs defined in RFC 2437 [PKCS#1v2.0], where section 2.3.2 indicating that the message to be encrypted AES wrap

   function is the content-encryption key.
 Schaad, Housley                9 
                   Use of used to wrap the AES Algorithm in CMS      February 2002 CEK. The RSA key is identified in a certificate KEKRecipientInfo
   keyEncryptionAlgorithm parameters field MUST be absent.

   The KEKRecipientInfo encryptedKey field MUST include the AES CEK
   wrapped using the rsaEncryption
   object identifier:

      pkcs-1  OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) }

      rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }

   Note: This is previously distributed symmetric KEK as input to
   the same algorithm identifier used by RSAES-PKCS1-v1_5. AES wrap function.

2.5  PasswordRecipientInfo Fields

   This means that section describes the existence of an RSA conventions for using AES with the CMS
   enveloped-data content type to support password-based key in management.

   When a certificate cannot
   be password derived KEK is used to infer that a recipient can decrypt an RSAES-OAEP encrypted

   content-encryption key.

   The object identifier for RSAES-OAEP is:

      id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 } wrap the AES CEK, then the
   RecipientInfo PasswordRecipientInfo CHOICE MUST be used.

   The AlgorithmIdentifier parameters keyEncryptionAlgorithm algorithm field MUST be present, and one of the OIDs
   defined in section 2.3.2 indicating the AES wrap function is used to
   wrap the AES CEK.  The keyEncryptionAlgorithm parameters field MUST contain RSAES-OAEP-params.  RSAES-OAEP-params
   have the following syntax:

      RSAES-OAEP-params  ::=  SEQUENCE  {
         hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier,
         maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier,

         pSourceFunc [2] AlgorithmIdentifier
            DEFAULT pSpecifiedEmptyIdentifier  }

      sha1Identifier  ::=  AlgorithmIdentifier {
         id-sha1, NULL }

      mgf1SHA1Identifier  ::=  AlgorithmIdentifier  {
         id-mgf1, sha1Identifier }

      pSpecifiedEmptyIdentifier  ::=  AlgorithmIdentifier  {
         id-pSpecified, nullOctetString }

      id-sha1  OBJECT IDENTIFIER ::=  {
         iso(1) identified-organization(3) oiw(14) secsig(3)
         algorithms(2) 26 }

      id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }

      id-pSpecified  OBJECT IDENTIFIER  ::=  { pkcs-1 9 }

      nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }
   be absent.

   The fields encryptedKey field MUST be the result of type RSAES-OAEP-params have the following meanings:

   hashFunc identifies AES key wrap
   algorithm applied to the one-way hash function.  Implementations MUST
   support SHA-1 [SHA1]. AES CEK value.

3  Encrypted-data Conventions

   The SHA-1 CMS encrypted-data content type consists of encrypted content
   with implicit key management.  The AES algorithm identifier is comprised of used to encrypt
   the id-sha1 object identifier and a parameter of NULL.
   Implementations that perform key encryption content.

   Compliant software MUST omit meet the hashFunc
   field when SHA-1 requirements for constructing an
   enveloped-data content type stated in [CMS] Section 8, "Encrypted-
   data Content Type".

   The encrypted-data content type is used, indicating that ASN.1 encoded using the default algorithm was
 Schaad, Housley                10 
                   Use
   EncryptededData syntax.  The fields of the AES Algorithm in CMS      February 2002

   used.  Implementations that perform key decryption EncryptedData syntax MUST recognize
   both the id-sha1 object identifier and an absent hashFunc field
   be populated as an

   indication that SHA-1 was used.

   maskGenFunc identifies the mask generation function. Implementations
   MUST support MFG1 [PKCS#1v2.0].  MFG1 requires a one-way hash
   function, and it follows:

   The EncryptedData version is identified in the parameter field determined based on a number of factors.

   See [CMS] section 9.1 for the MFG1 algorithm identifier. to determine this value.

   The EncryptedData encryptedContentInfo contentEncryptionAlgorithm
   field MUST specify a symmetric encryption algorithm.  Implementations

   MUST support SHA-1 [SHA1]. encryption using AES, but implementations MAY support
   other algorithms as well.

   The MFG1 algorithm identifier is comprised EncryptedData unprotectedAttrs MAY be present.
 Schaad                                                                7
                   Use of the id-mgf1 object
   identifier AES Algorithm in CMS          July 2002

4  Algorithm Identifiers and a parameter that contains the Parameters

   This section specified algorithm identifier of identifiers for the one-way hash function employed with MFG1. AES encryption
   algorithm.

4.1  AES Algorithm Identifiers and Parameters

   The SHA-1 AES algorithm
   identifier is comprised of the id-sha1 object identifier and a
   parameter of NULL.  Implementations that perform key encryption MUST
   omit the maskGenFunc field when MFG1 with SHA-1 defined in [AES].  RSAES-OAEP [RSA-OAEP] MAY be
   used to transport AES keys.

   AES is used, indicating
   that added to the default algorithm was used.  Implementations that perform set of symmetric content encryption algorithms
   defined in [CMSALG].  The AES content-encryption algorithm, in Cipher

   Block Chaining (CBC) mode, for the three different key decryption MUST recognize both sizes are
   identified by the id-mgf1 and id-sha1 following object
   identifiers as well as an absent maskGenFunc identifiers:

       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 as an indication
   that MFG1 with SHA-1 was used.

   pSourceFunc identifies the source (and possibly the value) of MUST be present, and the
   encoding parameters, commonly called P.  Implementations
   parameters field MUST
   represent P by an algorithm identifier, id-pSpecified, indicating
   that P is explicitly provided as an contain a AES-IV:

       AES-IV ::= OCTET STRING (SIZE(16))

   Content encryption algorithm identifiers are located in the parameters.
   The default value for P is an empty string.  In this case, pHash in
   EME-OAEP contains
   EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the hash of a zero length string.  Implementations
   MUST support a zero length P value.  Implementations that perform key

   EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.

   Content encryption MUST omit the pSourceFunc field when a zero length P value

   is used, indicating that algorithms are used to encrypt the default value was used.  Implementations

   that perform key decryption MUST recognize both content located

   in the id-pSpecified
   object identifier EnvelopedData EncryptedContentInfo encryptedContent and an absent pSourceFunc field as an indication
   that a zero length P value was used. the
   EncryptedData EncryptedContentInfo encryptedContent fields.

5  SMIMECapabilities Attribute Conventions

   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 object identifiers 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.

   RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed
   attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be
   used to specify a partial list of algorithms that the software
   announcing the SMIMECapabilities can support.

5.1  RSAES-OEAP SMIMECapability Attribute

   When constructing a signedData object, compliant software MAY include

   the SMIMECapabilities signed attribute announcing that it supports
   the RSAES-OAEP algorithm.

   The SMIMECapability SEQUENCE representing RSAES-OAEP MUST include the

   id-RSAES-OAEP object identifier in the capabilityID field and MUST
 Schaad, Housley                11 
                   Use of the AES Algorithm in CMS      February 2002

   include the RSAES-OAEP-Default-Identifier SEQUENCE in the parameters
   field.

      RSAES-OAEP-Default-Identifier  ::=  AlgorithmIdentifier  {
        id-RSAES-OAEP,  { sha1Identifier, mgf1SHA1Identifier,
                          pSpecifiedEmptyIdentifier  }  }

   When all list of algorithms that the default settings are selected, software
   announcing the SMIMECapability
   SEQUENCE representing RSAES-OAEP MUST be DER-encoded as:

         30 0D 06 09 2A 86 48 86 F7 0D 01 01 07 30 00

5.2 SMIMECapabilities can support.

5.1  AES S/MIME Capability Attributes

   If an S/MIME client is required to support symmetric encryption with
   AES, the capabilities attribute MUST contain the AES object
   identifier specified above in the category of symmetric algorithms.
   The parameter associated with this object identifier MUST is
   AESSMimeCapability.
 Schaad                                                                8
                   Use of the AES Algorithm in CMS          July 2002

       AESSMimeCapabilty ::= NULL

   The encodings for the mandatory key sizes are:

         Key Size                   Capability
          128          30 0D 06 09 60 86 48 01 65 03 04 01 02 30 00
          196          30 0D 06 09 60 86 48 01 65 03 04 01 16 30 00
          256          30 0D 06 09 60 86 48 01 65 03 04 01 2A 30 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.

6  Security Considerations

   If RSA-OAEP [PKCS#1v2.0] and RSA #1 v1.5 [RSA#1v1.5] are both used to

   transport the same CEK, then an attacker can still use the
   Bleichenbacher attack against the RSA #1 v1.5 encrypted key.  It is
   generally unadvisable to mix both RSA-OAEP and RSA #1 v1.5 in the
   same set of recipients.

   Implementations must protect the RSA private key and the CEK.
   Compromise of the RSA private key may result in the disclosure of all

   messages protected with that key.  Compromise of the CEK may result
   in disclosure of the associated encrypted content.

   The generation of AES CEKs, RSA public/private key pairs, and MGF
   seeds rely CEKs relies on random numbers.  The use of
   inadequate pseudo-random number generators (PRNGs) to generate these
   values can result in little or no security.  An attacker may find it
   much easier to
 Schaad, Housley                12 
                   Use of the AES Algorithm in CMS      February 2002 reproduce the PRNG environment that produced the keys,

   searching the resulting small set of possibilities, rather than brute

   force searching the whole key space.  The generation of quality
   random numbers is difficult.  RFC 1750 [RANDOM] offers important
   guidance in this area.

   When wrapping a CEK with a KEK, the KEK MUST always be at least the
   same length as the CEK.  An attacker will generally work at the
   weakest point in an encryption system.  This would be the smaller of
   the two key sizes for a brute force attack.

References

AES         National Institute of Standards.
            FIPS Pub 197: Advanced Encryption Standard (AES).
            26 November 2001.

AES-WRAP    Schaad, J., R. Housley, "AES "Advanced Encryption Standard (AES)
 Schaad                                                                9
                   Use of the AES Algorithm in CMS          July 2002

            Key Wrap Algorithm",
            Draft-ietf-smime-aes-key-wrap-00.txt RFC 3394, September 2002

CMS         Housley, R., Cryptographic "Cryptographic Message Syntax.
            draft-ietf-smime-rfc2630bis-06.txt. Syntax (CMS)", RFC
            3369, August 2002.

CMSALG      Housley, R., Cryptographic "Cryptographic Message Syntax (CMS)
            Algorithms,
            draft-ietf-smime-cmsalg-07.txt.

CRYPTO98    Bleichenbacher, D., "Chosen Ciphertext Attacks Against
            Protocols Based on the RSA Encryption Standard PKCS #1,"
            in H. Krawczyk (editor), Advances in Cryptology - CRYPTO'98
            Proceedings, Lecture Notes in Computer Science 1462 (1998),
            Springer-Verlag, pp. 1-12. RFC 3370, August 2002.

DES         National Institute of Standards and Technology.
            FIPS Pub 46: Data Encryption Standard.  15 January 1977.

DH          Rescorla, E., Diffie-Hellman Key Agreement Method, RFC
            2631, June 1999.

MUSTSHOULD  Bradner, S., Key Words for Use in RFCs to Indicate
            Requirement Levels.  BCP 14, RFC 2119.  March 1997.

MMA         Rescorla, E., Preventing the Million Message Attack
            on CMS, RFC 3218, January 2002.

MSG         Ramsdell, B., Editor.  S/MIME Version 3 Message
            Specification.  RFC 2633.  June 1999.

PKCS#1v1.5  Kaliski, B.  PKCS #1: RSA Encryption, Version 1.5.
            RFC 2313.  March 1998.

PKCS#1v2.0  Kaliski, B.  PKCS #1: RSA Encryption, Version 2.0.
            RFC 2437.  October 1998.

 Schaad, Housley                13 
                   Use of the AES Algorithm in CMS      February 2002

PROFILE     Housley, R., W. Ford, W. Polk, and D. Solo.  Internet
            X.509 Public Key Infrastructure: Certificate and CRL
            Profile.  <draft-ietf-smime-new-part1.txt>.

RANDOM      Eastlake, D., S. Crocker, and J. Schiller.  Randomness
            Recommendations for Security.  RFC 1750.  December 1994.

RSALABS     Bleichenbacher, D., B. Kaliski, and J. Staddon.
            Recent Results on PKCS #1: RSA Encryption Standard.
            RSA Laboratories' Bulletin No. 7, June 26, 1998.
            [At http://www.rsasecurity.com/rsalabs/bulletins]

SHA1        National Institute

RSA-OAEP    Housley, R. "Use of Standards and Technology.
            FIPS Pub 180-1: Secure Hash Standard.  17 April 1995.

SSL         Freier, A., P. Karlton, and P. Kocher.  The SSL Protocol,
            Version 3.0.  Netscape Communications.  November 1996.
            [At http://www.netscape.com/eng/ssl3/draft302.txt] the RSAES-OAEP Key Transport Algorithm
            in CMS", draft-ietf-smime-cms-rsaes-oaep-03.txt, June 2002.

SYMKEYDIST  Turner, S.  CMS Symmetric Key Management and Distribution.
            RFC TDB. Date TBD.
            <draft-ietf-smime-symkeydist-06.txt>

TLS         Dierks, T. and C. Allen.  The TLS Protocol Version 1.0.
            RFC 2246.  January 1999.

X.208-88    CCITT.  Recommendation X.208: Specification of Abstract
            Syntax Notation One (ASN.1).  1988.

X.209-88    CCITT.  Recommendation X.209: Specification of Basic
            Encoding Rules for Abstract Syntax Notation One (ASN.1).
            1988.

X.509-88    CCITT.  Recommendation X.509: The Directory -
            Authentication Framework.  1988.

Acknowledgements

   This document is the result of contributions from many
   professionals.  We appreciate the hard work of all members of the
   IETF S/MIME Working Group.  We wish to extend a special thanks to
   Burt Kaliski.

Author's Addresses

   Jim
 Schaad
   Soaring Hawk Consulting

   Email: jimsch@exmsft.com

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
 Schaad, Housley                14                                                               10
                   Use of the AES Algorithm in CMS      February          July 2002

   Herndon, VA 20170
   USA

   Jim Schaad
   Soaring Hawk Consulting

   Email: rhousley@rsasecurity.com jimsch@exmsft.com

Appendix A  ASN.1 Module

CMSAesRsaesOaep {iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0) aes-rsaes-oaep(19) id-mod-cms-aes(19) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

-- EXPORTS ALL --
IMPORTS
    -- PKIX
      AlgorithmIdentifier
          FROM PKIXExplicit88 {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-pkix1-explicit(18)};

-- AES information object identifiers --

aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
               organization(1) gov(101) csor(3)_ nistAlgorithms(4)  1 }

-- AES using CBC-chaining mode for key sizes of 128, 192, 256

id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }

-- AES-IV is a the parameter for all the above object identifiers.

AES-IV ::= OCTET STRING (SIZE(16))

--  AES S/MIME Capabilty parameter for all the above object identifiers

AESSMimeCapability ::= NULL

--  Definitions for RSA-OAEP

pkcs-1  OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
                   rsadsi(113549) pkcs(1) pkcs-1(1) }
id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 }

RSAES-OAEP-params  ::=  SEQUENCE  {
    hashFunc [0] AlgorithmIdentifier DEFAULT sha1Identifier,
    maskGenFunc [1] AlgorithmIdentifier DEFAULT mgf1SHA1Identifier,
    pSourceFunc [2] AlgorithmIdentifier
           DEFAULT pSpecifiedEmptyIdentifier }

sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }
 Schaad, Housley                15 
                   Use of the AES Algorithm in CMS      February 2002

mgf1SHA1Identifier AlgorithmIdentifier ::=  {id-mgf1, sha1Identifier }

nullOctetString OCTET STRING (SIZE (0)) ::= { ''H }

pSpecifiedEmptyIdentifier AlgorithmIdentifier ::=  { id-pSpecified,
                    nullOctetString }

id-sha1  OBJECT IDENTIFIER ::=  { iso(1) identified-organization(3)
              oiw(14) secsig(3) algorithms(2) 26 }

id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }

id-pSpecified  OBJECT IDENTIFIER  ::=  { pkcs-1 9 }

rSAES-OAEP-Default-Identifier  AlgorithmIdentifier ::=  {
        id-RSAES-OAEP,  { sha1Identifier, mgf1SHA1Identifier,
                          pSpecifiedEmptyIdentifier  }  }

END

 Schaad, Housley                16

 Schaad                                                               11