Encryption Key Derivation in the Cryptographic Message Syntax (CMS) using HKDF with SHA-256
draft-housley-lamps-cms-cek-hkdf-sha256-00

Network Working Group                                         R. Housley
Internet-Draft                                            Vigil Security
Intended status: Standards Track                        30 November 2023
Expires: 2 June 2024

  Encryption Key Derivation in the Cryptographic Message Syntax (CMS)
                        using HKDF with SHA-256
               draft-housley-lamps-cms-cek-hkdf-sha256-00

Abstract

   This document specifies the derivation of the content-encryption key
   or the content-authenticated-encryption key in the Cryptographic
   Message Syntax (CMS).  The use of this mechanism provides protection
   against where the attacker manipulates the content-encryption
   algorithm identifier or the content-authenticated-encryption
   algorithm identifier.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 2 June 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Housley                    Expires 2 June 2024                  [Page 1]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Use of of HKDF with SHA-256 to Derive Encryption Keys . . . .   4
   3.  The use-cms-cek-hkdf-sha256 Attribute . . . . . . . . . . . .   4
   4.  SMIMECapabilities Attribute Conventions . . . . . . . . . . .   5
   5.  Use of of HKDF with SHA-256 with CMS  . . . . . . . . . . . .   5
     5.1.  Enveloped-Data Content Type . . . . . . . . . . . . . . .   5
     5.2.  Encrypted-Data Content Type . . . . . . . . . . . . . . .   6
     5.3.  Authenticated-Enveloped-Data Content Type . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
   8.  Operations Considerations . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  11
   Appendix B.  CMS_CEK_HKDF_SHA256 Function Examples  . . . . . . .  13
     B.1.  CMS_CEK_HKDF_SHA256 with AES-128-GCM  . . . . . . . . . .  13
     B.2.  CMS_CEK_HKDF_SHA256 with AES-128-CBC  . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document specifies the derivation of the content-encryption key
   for the Cryptographic Message Syntax (CMS) enveloped-data content
   type [RFC5652], the content-encryption key for the CMS encrypted-data
   content type [RFC5652], or the content-authenticated-encryption key
   for the authenticated-enveloped-data content type [RFC5083].

   The use of this mechanism provides protection against where the
   attacker manipulates the content-encryption algorithm identifier or
   the content-authenticated-encryption algorithm identifier.  Johannes
   Roth and Falko Strenzke presented such an attack at IETF 118
   [RS2023], where:

Housley                    Expires 2 June 2024                  [Page 2]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   1.  The attacker intercepts a CMS Authenticated-Enveloped-Data
       content [RFC5083] that uses either AES-CCM or AES-GCM [RFC5084].

   2.  The attacker turns the intercepted content into a "garbage" CMS
       Enveloped-Data content Section 6 of [RFC5652] that is composed of
       AES-CBC guess blocks.

   3.  The attacker sends the "garbage" message to the victim, and the
       victim reveals the result of the decryption with the attacker.

   4.  If any of the transformed plaintext blocks match the guess for
       that block, then the attacker learns the plaintext for that
       block.

   With highly structured messages, one block can reveal the only
   sensitive part of the original message.

   This attack is thwarted if the encryption key depends upon the
   delivery of the unmodified algorithm identifier.

   The mitigation for this attack has three parts:

   *  Potential recipients include the object identifier for the use-
      cms-cek-hkdf-sha256 attribute (with no parameters) in S/MIME
      Capabilities to indicate support for this mitigation.

   *  As a flag to the recipient that this mitigation is being used,
      carry the use-cms-cek-hkdf-sha256 attribute in the unprotected
      attributes.

   *  Perform encryption with a derived content-encryption key or
      content-authenticated-encryption key:

         CEK' = HKDF(CEK, AlgorithmIdentifier)

1.1.  ASN.1

   CMS values are generated using ASN.1 [X680], using the Basic Encoding
   Rules (BER) and the Distinguished Encoding Rules (DER) [X690].

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Housley                    Expires 2 June 2024                  [Page 3]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

2.  Use of of HKDF with SHA-256 to Derive Encryption Keys

   The mitigation uses the HMAC-based Extract-and-Expand Key Derivation
   Function (HKDF) [RFC5869] to derive output keying materiam (OKM) from
   input key material (IKM).  HKDF is used with the SHA-256 hash
   function [FIPS180].  The derivation includes the DER-encoded
   AlgoritmIdentifier as the optional info input value.  If an attacker
   were to change the originator-provided AlgoritmIdentifier, then the
   recipient will derive a different content-encryption key or content-
   authenticated-encryption key.

   The CMS_CEK_HKDF_SHA256 function uses the HKDF-Extract and HKDF-
   Expand functions to derive the OKM from the IKM:

   Inputs:
      IKM      input keying material
      info     DER-encoded AlgoritmIdentifier

   Output:
      OKM      output keying material (same size as IKM)

   The output OKM is calculated as follows:

      OKM_SIZE = len(IKM)
      IF OKM_SIZE > 8160 THEN raise error

      salt = "The Cryptographic Message Syntax"
      PRK = HKDF-Extract(salt, IKM)

      OKM = HKDF-Expand(PRK, info, OKM_SIZE)

3.  The use-cms-cek-hkdf-sha256 Attribute

   The use-cms-cek-hkdf-sha256 attribute specifies that the
   CMS_CEK_HKDF_SHA256 function defined in Section 2 to derive the
   content-encryption key or the content-authenticated-encryption key.

   The use-cms-cek-hkdf-sha256 attribute MUST be a unprotected attribute
   or an unauthenticated attribute; it MUST NOT be an signed attribute,
   authenticated attribute, or protected attribute.

   The following object identifier identifies the use-cms-cek-hkdf-
   sha256 attribute:

      id-aa-use-cms-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { TBD1 }

   The use-cms-cek-hkdf-sha256 attribute values have ASN.1 type of NULL.

Housley                    Expires 2 June 2024                  [Page 4]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   Using the conventions from [RFC5911], the use-cms-cek-hkdf-sha256
   attribute is defined as:

     aa-useCMSCEKHKDFSHA256 ATTRIBUTE ::=
         { TYPE NULL IDENTIFIED BY id-aa-use-cms-cek-hkdf-sha256 }

4.  SMIMECapabilities Attribute Conventions

   The SMIMECapabilities Attribute is defined in Section 2.5.2 of
   [RFC8551].  An S/MIME client announces the set of cryptographic
   functions it supports using the SMIMECapabilities attribute.

   If an S/MIME client is supports the mechanism in this document, the
   id-use-cms-cek-hkdf-sha256 OID SHOULD be included in the set of
   cryptographic functions.  The parameter with this encoding MUST be
   absent.

   The encoding for id-use-cms-cek-hkdf-sha256, in hexadecimal, is:

      30 TBD

5.  Use of of HKDF with SHA-256 with CMS

   This section describe the originator and recipient processing to
   implement this mitigation for each of the CMS encrypting content
   types.

5.1.  Enveloped-Data Content Type

   As specified in Section 6 of [RFC5652], the fourth step of
   constructing an Enveloped-data is:

   4.  The content is encrypted with the content-encryption key.
       Content encryption may require that the content be padded to a
       multiple of some block size; see Section 6.3 of [RFC5652].

   To implement this mitigation, the originator expands this step as
   follows:

   *  Include the use-cms-cek-hkdf-sha256 attribute in the
      UnprotectedAttributes.

   *  Derive the new content-encryption key (CEK') from the original
      content-encryption key (CEK) and the
      ContentEncryptionAlgorithmIdentifier:

   CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier)

Housley                    Expires 2 June 2024                  [Page 5]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   *  The content is encrypted with the new content-encryption key
      (CEK').  Content encryption may require that the content be padded
      to a multiple of some block size; see Section 6.3 of [RFC5652].

   If the use-cms-cek-hkdf-sha256 attribute is present in the
   UnprotectedAttributes of an Enveloped-Data Content Type, then the
   recipient derives the new content-encryption key (CEK') as shown
   above, and uses it for decryption of the EncryptedContent.  If the
   use-cms-cek-hkdf-sha256 attribute is not present in the
   UnprotectedAttributes, then the recipient uses the original content-
   encryption key (CEK) for decryption of the EncryptedContent.

5.2.  Encrypted-Data Content Type

   As specified in Section 8 of [RFC5652], the content-encryption key is
   managed by other means.

   To implement this mitigation, the originator performs the following:

   *  Include the use-cms-cek-hkdf-sha256 attribute in the
      UnprotectedAttributes.

   *  Derive the new content-encryption key (CEK') from the original
      content-encryption key (CEK) and the
      ContentEncryptionAlgorithmIdentifier:

   CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier)

   *  The content is encrypted with the new content-encryption key
      (CEK').  Content encryption may require that the content be padded
      to a multiple of some block size; see Section 6.3 of [RFC5652].

   If the use-cms-cek-hkdf-sha256 attribute is present in the
   UnprotectedAttributes of an Encrypted-Data Content Type, then the
   recipient derives the new content-encryption key (CEK') as shown
   above, and uses it for decryption of the EncryptedContent.  If the
   use-cms-cek-hkdf-sha256 attribute is not present in the
   UnprotectedAttributes, then the recipient uses the original content-
   encryption key (CEK) for decryption of the EncryptedContent.

5.3.  Authenticated-Enveloped-Data Content Type

   As specified in Section 2 of [RFC5083], the fifth step of
   constructing an Authenticated-Enveloped-Data is:

Housley                    Expires 2 June 2024                  [Page 6]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   5.  The attributes collected in step 4 are authenticated and the CMS
       content is authenticated and encrypted with the content-
       authenticated-encryption key.  If the authenticated encryption
       algorithm requires either the additional authenticated data (AAD)
       or the content to be padded to a multiple of some block size,
       then the padding is added as described in Section 6.3 of
       [RFC5652].

   To implement this mitigation, the originator expands this step as
   follows:

   *  Include the use-cms-cek-hkdf-sha256 attribute in the
      UnauthAttributes.

   *  Derive the new content-authenticated-encryption key (CEK') from
      the original content-authenticated-encryption key (CEK) and the
      ContentEncryptionAlgorithmIdentifier:

   CEK' = CMS_CEK_HKDF_SHA256(CEK, ContentEncryptionAlgorithmIdentifier)

   *  The attributes collected in step 4 are authenticated and the CMS
      content is authenticated and encrypted with the new content-
      authenticated-encryption key (CEK').  If the authenticated
      encryption algorithm requires either the additional authenticated
      data (AAD) or the content to be padded to a multiple of some block
      size, then the padding is added as described in Section 6.3 of
      [RFC5652].

   If the use-cms-cek-hkdf-sha256 attribute is present in the
   UnauthAttributes of an Enveloped-Data Content Type, then the
   recipient derives the new content-authenticated-encryption key (CEK')
   as shown above, and uses it for authenticated decryption of the
   EncryptedContent and the authentication of the AAD.  If the use-cms-
   cek-hkdf-sha256 attribute is not present in the UnauthAttributes,
   then the recipient uses the original content-authenticated-encryption
   (CEK) for decryption and authentication of the EncryptedContent and
   the authentication of the AAD.

6.  Security Considerations

   This mitigation always uses HKDF with SHA-256.  One KDF algorithm was
   selected to avoid the need for negotiation.  In the future, if a
   weakness is found in the KDF algorithm, a new attribute will need to
   be assigned for use with an alternative KDF algorithm.

Housley                    Expires 2 June 2024                  [Page 7]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   If the attacker removes the use-cms-cek-hkdf-sha256 attribute from
   the unprotected attributes or unauthenticated attributes, then the
   recipient will derive a different CEK', which will not assist the
   attacker in recovering the plaintext content.

   If the attacker changes the ContentEncryptionAlgorithmIdentifier,
   then the recipient will derive a different CEK', which will not
   assist the attacker in recovering the plaintext content.  The
   AlgorithmIdentifier object identifier is sufficient to mitigate the
   attack described in [RS2023], but this mitigation includes the object
   identifier and the parameters to protect against some yet-to-be-
   discovered attack that only manipulates the parameters.

   Implementations MUST protect the content-encryption keys and content-
   authenticated-encryption keys, this includes the CEK and CEK'.
   Compromise of a content-encryption key may result in disclosure of
   the associated encrypted content.  Compromise of a content-
   authenticated-encryption key may result in disclosure of the
   associated encrypted content or allow modification of the
   authenticated content and the additional authenticated data (AAD).

   Implementations MUST randomly generate content-encryption keys and
   content-authenticated-encryption keys.  Using an inadequate pseudo-
   random number generator (PRNG) to generate cryptographic keys can
   result in little or no security.  An attacker may find it much easier
   to reproduce the PRNG environment that produced the keys, and then
   searching the resulting small set of possibilities, rather than brute
   force searching the whole key space.  The generation of quality
   random numbers is difficult.  [RFC4086] offers important guidance on
   this topic.

7.  Privacy Considerations

   If the message-digest attribute is included in the AuthAttributes,
   then the attribute value will contain the unencrypted one-way hash
   value of the plaintext of the content.  Disclosure of this hash value
   enables content tracking, and it can be used to determine if the
   plaintext matches one or more candidate contents.  For these reasons,
   the AuthAttributes SHOULD NOT contain the message-digest attribute.

8.  Operations Considerations

   CMS is often used to provide encryption in messaging environments,
   where various forms of unsolicited messages (such as spam and
   phishing) represent a significant volume of unwanted traffic.
   Mitigation strategies for unwanted message traffic involve analysis
   of message plaintext.  When recipients accept unsolicited encrypted
   messages, they become even more vulnerable to unwanted traffic since

Housley                    Expires 2 June 2024                  [Page 8]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   many mitigation strategies will be unable to access the message
   plaintext.  Therefore, software that receives messages that have been
   encrypted using CMS ought to provide alternate mechanisms to handle
   the unwanted message traffic.  One approach that does not require
   disclosure of keying material to a server is to reject or discard
   encrypted messages unless they purport to come from a member of a
   previously approve originator list.

9.  IANA Considerations

   For the ASN.1 Module in the Appendix A of this document, IANA is
   requested to assign an object identifier (OID) for the module
   identifier (TBD0) with a Description of "id-mod-CMS-CEK-HKDF-
   SHA256-2023".  The OID for the module should be allocated in the "SMI
   Security for S/MIME Module Identifier" registry
   (1.2.840.113549.1.9.16.0).

   For the use-cms-cek-hkdf-sha256 attribute definition in Section 3 of
   this document, IANA is requested to assign an object identifier (OID)
   (TBD1) with a Description of "id-aa-use-cms-cek-hkdf-sha256".  The
   OID for the module should be allocated in the "SMI Security for
   S/MIME Attributes" registry (1.2.840.113549.1.9.16.2).

10.  Acknowledgements

   Thanks to Mike Ounsworth for his careful review and constructive
   comments.

11.  References

11.1.  Normative References

   [FIPS180]  National Institute of Standards and Technology (NIST),
              "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC5083]  Housley, R., "Cryptographic Message Syntax (CMS)
              Authenticated-Enveloped-Data Content Type", RFC 5083,
              DOI 10.17487/RFC5083, November 2007,
              <https://www.rfc-editor.org/rfc/rfc5083>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5652>.

Housley                    Expires 2 June 2024                  [Page 9]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/rfc/rfc5869>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

   [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
              One (ASN.1): Specification of basic notation", ITU-T
              Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
              <https://www.itu.int/rec/T-REC-X.680>.

   [X690]     ITU-T, "Information technology -- ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
              February 2021, <https://www.itu.int/rec/T-REC-X.690>.

11.2.  Informative References

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC5084]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              RFC 5084, DOI 10.17487/RFC5084, November 2007,
              <https://www.rfc-editor.org/rfc/rfc5084>.

   [RFC5911]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for
              Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
              DOI 10.17487/RFC5911, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5911>.

   [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
              DOI 10.17487/RFC5912, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5912>.

Housley                    Expires 2 June 2024                 [Page 10]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   [RS2023]   Roth, J. and F. Strenzke, "AEAD-to-CBC Downgrade Attacks
              on CMS", 8 November 2023,
              <https://datatracker.ietf.org/meeting/118/materials/
              slides-118-lamps-attack-against-aead-in-cms>.

Appendix A.  ASN.1 Module

   This ASN.1 Module builds upon the conventions established in
   [RFC5911] and [RFC5912].

Housley                    Expires 2 June 2024                 [Page 11]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

   <CODE STARTS>

   CMS-CEK-HKDF-SHA256-Module-2023
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       id-smime(16) id-mod(0) id-mod-CMS-CEK-HKDF-SHA256-2023(TBD0) }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   EXPORTS ALL;

   IMPORTS
     ATTRIBUTE
     FROM PKIX-CommonTypes-2009   -- in [FRC5912]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkixCommon-02(57) }

     SMIME-CAPS
     FROM AlgorithmInformation-2009 -- in [FRC5911]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-algorithmInformation-02(58) } ;

   --
   -- use-CMS-CEK-HKDF-SHA256 Attribute
   --

   UnprotectedAttrs ATTRIBUTE ::= { aa-useCMSCEKHKDFSHA256, ... }

   id-aa-use-cms-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { TBD1 }

   aa-useCMSCEKHKDFSHA256 ATTRIBUTE ::=
       { TYPE NULL IDENTIFIED BY id-aa-use-cms-cek-hkdf-sha256 }

   --
   -- S/MIIME Capability for use-CMS-CEK-HKDF-SHA256
   --

   SMimeCaps SMIME-CAPS ::= { cap-useCMSCEKHKDFSHA256, ... }

   cap-useCMSCEKHKDFSHA256 SMIME-CAPS ::=
       { -- No value -- IDENTIFIED BY id-aa-use-cms-cek-hkdf-sha256 }

   END

   <CODE ENDS>

Housley                    Expires 2 June 2024                 [Page 12]
Internet-Draft      Encryption Key Derivation in CMS       November 2023

Appendix B.  CMS_CEK_HKDF_SHA256 Function Examples

   This appendix provides two test vectores for the CMS_CEK_HKDF_SHA256
   function.

B.1.  CMS_CEK_HKDF_SHA256 with AES-128-GCM

   This test vector uses includes an AlgorithmIdentifier for
   AES-128-GCM.

   IKM = c702e7d0a9e064b09ba55245fb733cf3

   The AES-128-CGM AlgorithmIdentifier:
    algorithm=2.16.840.1.101.3.4.1.6
    parameters=GCMParameters:
     aes-nonce=0x5c79058ba2f43447639d29e2
     aes-ICVlen is ommited; it indicates the DEFAULT of 12

   DER-encoded AlgorithmIdentifier:
     301b0609608648016503040106300e040c5c79058ba2f43447639d29e2

   OKM = 2124ffb29fac4e0fbbc7d5d87492bff3

B.2.  CMS_CEK_HKDF_SHA256 with AES-128-CBC

   This test vector uses includes an AlgorithmIdentifier for
   AES-128-CBC.

   IKM = c702e7d0a9e064b09ba55245fb733cf3

   The AES-128-CBC AlgorithmIdentifier:
    algorithm=2.16.840.1.101.3.4.1.2
    parameters=AES-IV=0x651f722ffd512c52fe072e507d72b377

   DER-encoded AlgorithmIdentifier:
     301d06096086480165030401020410651f722ffd512c52fe072e507d72b377

   OKM = 9cd102c52f1e19ece8729b35bfeceb50

Author's Address

   Russ Housley
   Vigil Security, LLC
   Herndon, VA,
   United States of America
   Email: housley@vigilsec.com

Housley                    Expires 2 June 2024                 [Page 13]