Use of ML-KEM in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-kyber-04

LAMPS                                                            J. Prat
Internet-Draft                                       CryptoNext Security
Intended status: Standards Track                            M. Ounsworth
Expires: 6 January 2025                                          Entrust
                                                            D. Van Geest
                                                     CryptoNext Security
                                                             5 July 2024

        Use of ML-KEM in the Cryptographic Message Syntax (CMS)
                     draft-ietf-lamps-cms-kyber-04

Abstract

   The Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM)
   algorithm is a one-pass (store-and-forward) cryptographic mechanism
   for an originator to securely send keying material to a recipient
   using the recipient's ML-KEM public key.  Three parameters sets for
   the ML-KEM algorithm are specified by NIST in [FIPS203-ipd] [EDNOTE:
   Change to [FIPS203] when it is published].  In order of increasing
   security strength (and decreasing performance), these parameter sets
   are ML-KEM-512, ML-KEM-768, and ML-KEM-1024.  This document specifies
   the conventions for using ML-KEM with the Cryptographic Message
   Syntax (CMS) using KEMRecipientInfo as specified in
   [I-D.ietf-lamps-cms-kemri].

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber/.

   Discussion of this document takes place on the Limited Additional
   Mechanisms for PKIX and SMIME (lamps) Working Group mailing list
   (mailto:spasm@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/spasm/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/spasm/.

   Source for this draft and an issue tracker can be found at
   https://github.com/lamps-wg/kyber-certificates.

Status of This Memo

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

Prat, et al.             Expires 6 January 2025                 [Page 1]
Internet-Draft                ML-KEM in CMS                    July 2024

   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 6 January 2025.

Copyright Notice

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

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
     1.2.  ML-KEM  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Use of the ML-KEM Algorithm in CMS  . . . . . . . . . . . . .   4
     2.1.  RecipientInfo Conventions . . . . . . . . . . . . . . . .   4
     2.2.  Underlying Components . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Use of the HKDF-based Key Derivation Function . . . .   5
       2.2.2.  Use of the KMAC-based Key Derivation Function . . . .   6
       2.2.3.  Components for ML-KEM in CMS  . . . . . . . . . . . .   7
     2.3.  Certificate Conventions . . . . . . . . . . . . . . . . .   8
     2.4.  SMIME Capabilities Attribute Conventions  . . . . . . . .   8
   3.  Identifiers . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  14
     A.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  15

Prat, et al.             Expires 6 January 2025                 [Page 2]
Internet-Draft                ML-KEM in CMS                    July 2024

   Appendix B.  Revision History . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   ML-KEM is an IND-CCA2-secure key-encapsulation mechanism (KEM)
   standardized in [FIPS203] by the US NIST PQC Project [NIST-PQ].

   Native support for Key Encapsulation Mechanisms (KEMs) was added to
   CMS in [I-D.ietf-lamps-cms-kemri], which defines the KEMRecipientInfo
   structure for the use of KEM algorithms for the CMS enveloped-data
   content type, the CMS authenticated-data content type, and the CMS
   authenticated-enveloped-data content type.  This document specifies
   the direct use of ML-KEM in the KEMRecipientInfo structure in CMS
   using each of the three parameter sets from [FIPS203], namely MK-KEM-
   512, ML-KEM-768, and ML-KEM-1024.  It does not address or preclude
   the use of ML-KEM as part of any hybrid scheme.

1.1.  Conventions and 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
   BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  ML-KEM

   ML-KEM is a lattice-based key encapsulation mechanism using Module
   Learning with Errors as its underlying primitive, which is a
   structured lattices variant that offers good performance and
   relatively small and balanced key and ciphertext sizes.  ML-KEM was
   standardized with three parameter sets: ML-KEM-512, ML-KEM-768, and
   ML-KEM-1024.  These were mapped by NIST to the three security levels
   defined in the NIST PQC Project, Level 1, 3, and 5.  These levels
   correspond to the hardness of breaking AES-128, AES-192 and AES-256
   respectively.

   Like all KEM algorithms, ML-KEM provides three functions: KeyGen(),
   Encapsulate(), and Decapsulate().

   KeyGen() -> (pk, sk):  Generate the public key (pk) and a private key
      (sk).

   Encapsulate(pk) -> (ct, ss):  Given the recipient's public key (pk),
      produce a ciphertext (ct) to be passed to the recipient and a
      shared secret (ss) for use by the originator.

Prat, et al.             Expires 6 January 2025                 [Page 3]
Internet-Draft                ML-KEM in CMS                    July 2024

   Decapsulate(sk, ct) -> ss:  Given the private key (sk) and the
      ciphertext (ct), produce the shared secret (ss) for the recipient.

   The KEM functions defined above correspond to the following functions
   in [FIPS203]:

   KeyGen():  ML-KEM.KeyGen() from section 6.1.

   Encapsulate():  ML-KEM.Encaps() from section 6.2.

   Decapsulate():  ML-KEM.Decaps() from section 6.3.

   All security levels of ML-KEM use SHA3-256, SHA3-512, SHAKE256, and
   SHAKE512 internally.

2.  Use of the ML-KEM Algorithm in CMS

   The ML-KEM algorithm MAY be employed for one or more recipients in
   the CMS enveloped-data content type [RFC5652], the CMS authenticated-
   data content type [RFC5652], or the CMS authenticated-enveloped-data
   content type [RFC5083].  In each case, the KEMRecipientInfo
   [I-D.ietf-lamps-cms-kemri] is used with the ML-KEM algorithm to
   securely transfer the content-encryption key from the originator to
   the recipient.

   Processing ML-KEM with KEMRecipientInfo follows the same steps as
   Section 2 of [I-D.ietf-lamps-cms-kemri].  To support the ML-KEM
   algorithm, a CMS originator MUST implement the Encapsulate() function
   and a CMS responder MUST implement the Decapsulate() function.

2.1.  RecipientInfo Conventions

   When the ML-KEM algorithm is employed for a recipient, the
   RecipientInfo alternative for that recipient MUST be
   OtherRecipientInfo using the KEMRecipientInfo structure as defined in
   [I-D.ietf-lamps-cms-kemri].  The fields of the KEMRecipientInfo MUST
   have the following values:

      version is the syntax version number; it MUST be 0.

      rid identifies the recipient's certificate or public key.

      kem identifies the KEM algorithm; it MUST contain one of id-ML-
      KEM-512, id-ML-KEM-768, or id-ML-KEM-1024.  These identifiers are
      reproduced in Section 3.

      kemct is the ciphertext produced for this recipient.

Prat, et al.             Expires 6 January 2025                 [Page 4]
Internet-Draft                ML-KEM in CMS                    July 2024

      kdf identifies the key-derivation algorithm.  Note that the Key
      Derivation Function (KDF) used for CMS RecipientInfo process MAY
      be different than the KDF used within the ML-KEM algorithm.

      kekLength is the size of the key-encryption key in octets.

      ukm is an optional random input to the key-derivation function.
      ML-KEM doesn't place any requirements on the ukm contents.

      wrap identifies a key wrapping algorithm used to encrypt the
      content-encryption key.

2.2.  Underlying Components

   When ML-KEM is employed in CMS, the security levels of the different
   underlying components used within the KEMRecipientInfo structure
   SHOULD be consistent.

2.2.1.  Use of the HKDF-based Key Derivation Function

   The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is
   defined in [RFC5869].

   The HKDF function is a composition of the HKDF-Extract and HKDF-
   Expand functions.

   HKDF(salt, IKM, info, L)
     = HKDF-Expand(HKDF-Extract(salt, IKM), info, L)

   HKDF(salt, IKM, info, L) takes the following parameters:

   salt:  optional salt value (a non-secret random value).  In this
      document this parameter is unused, that is it is the zero-length
      string "".

   IKM:  input keying material.  In this document this is the shared
      secret outputted from the Encapsulate() or Decapsulate()
      functions.  This corresponds to the IKM KDF input from Section 5
      of [I-D.ietf-lamps-cms-kemri].

   info:  optional context and application specific information.  In
      this document this corresponds to the info KDF input from
      Section 5 of [I-D.ietf-lamps-cms-kemri].  This is the ASN.1 DER
      encoding of CMSORIforKEMOtherInfo.

   L:  length of output keying material in octets.  This corresponds to
      the L KDF input from Section 5 of [I-D.ietf-lamps-cms-kemri],
      which is identified in the kekLength value from KEMRecipientInfo.

Prat, et al.             Expires 6 January 2025                 [Page 5]
Internet-Draft                ML-KEM in CMS                    July 2024

   HKDF may be used with different hash functions, including SHA2-256 or
   SHA2-512 [FIPS180].  The object identifiers id-alg-hkdf-with-sha256
   and id-alg-hkdf-with-sha512 are defined in [RFC8619] (see Section 3),
   and specify the use of HKDF with SHA2-256 and SHA2-512 respectively.
   The parameter field MUST be absent when one of these algorithm
   identifiers is used to specify the KDF for ML-KEM in
   KemRecipientInfo.

2.2.2.  Use of the KMAC-based Key Derivation Function

   KMAC128-KDF and KMAC256-KDF are KMAC-based KDFs specified for use in
   CMS in [I-D.ietf-lamps-cms-sha3-hash].  Here, KMAC# indicates the use
   of either KMAC128-KDF or KMAC256-KDF.

   KMAC#(K, X, L, S) takes the following parameters:

   K:  the input key-derivation key.  In this document this is the
      shared secret outputted from the Encapsulate() or Decapsulate()
      functions.  This corresponds to the IKM KDF input from Section 5
      of [I-D.ietf-lamps-cms-kemri].

   X:  the context, corresponding to the info KDF input from Section 5
      of [I-D.ietf-lamps-cms-kemri].  This is the ASN.1 DER encoding of
      CMSORIforKEMOtherInfo.

   L:  the output length, in bits.  This corresponds to the L KDF input
      from Section 5 of [I-D.ietf-lamps-cms-kemri], which is identified
      in the kekLength value from KEMRecipientInfo.  The L KDF input and
      kekLength values are specified in octets while this L parameter is
      specified in bits.

   S:  the optional customization label.  In this document this
      parameter is unused, that is it is the zero-length string "".

   The object identifier for KMAC128-KDF is id-kmac128 (see Section 3).

   The object identifier for KMAC256-KDF is id-kmac256 (see Section 3).

   Since the customization label to KMAC# is not used, the parameter
   field MUST be absent when id-kmac128 or id-kmac256 is used as part of
   an algorithm identifier specifying the KDF to use for ML-KEM in
   KemRecipientInfo.

Prat, et al.             Expires 6 January 2025                 [Page 6]
Internet-Draft                ML-KEM in CMS                    July 2024

2.2.3.  Components for ML-KEM in CMS

   An implementation MUST support at least one of KMAC# or HMAC as the
   KDF for ML-KEM in KemRecipientInfo.  It is RECOMMENDED that a CMS
   recipient supports both.  KMAC# is given as an option because ML-KEM
   uses SHA3 and SHAKE as internal functions, so an implementation may
   want to use these to reduce code size.  HMAC is given as an option
   because SHA2 is widely supported and the CMS-level code may not have
   access to underlying KECCAK-based implementations.  Note that the KDF
   used to process the KEMRecipientInfo structure MAY be different from
   the KDF used in the ML-KEM algorithm.

   For ML-KEM-512, the following underlying components MUST be
   supported:

      KDF: KMAC128-KDF using id-kmac128 or HMAC with SHA2-256 using id-
      alg-hkdf-with-sha256

      Key wrapping: 128-bit AES key wrapping using id-aes128-wrap
      [RFC3565]

   For ML-KEM-768, the following underlying components MUST be
   supported:

      KDF: KMAC256-KDF using id-kmac256 or HMAC with SHA2-512 using id-
      alg-hkdf-with-sha512

      Key wrapping: 256-bit AES key wrapping using id-aes256-wrap
      [RFC3565]

   For ML-KEM-1024, the following underlying components MUST be
   supported:

      KDF: KMAC256-KDF using id-kmac256 or HMAC with SHA2-512 using id-
      alg-hkdf-with-sha512

      Key wrapping: 256-bit AES key wrapping using id-aes256-wrap
      [RFC3565]

   The above object identifiers are reproduced for convenience in
   Section 3.

   An implementation MAY also support other key-derivation functions and
   other key-encryption algorithms.

   If underlying components other than those specified above are used,
   then the following KDF requirements are in effect in addition to
   those asserted in [I-D.ietf-lamps-cms-kemri]:

Prat, et al.             Expires 6 January 2025                 [Page 7]
Internet-Draft                ML-KEM in CMS                    July 2024

      ML-KEM-512 SHOULD be used with a KDF capable of outputting a key
      with at least 128 bits of security and with a key wrapping
      algorithm with a key length of at least 128 bits.

      ML-KEM-768 SHOULD be used with a KDF capable of outputting a key
      with at least 192 bits of security and with a key wrapping
      algorithm with a key length of at least 192 bits.

      ML-KEM-1024 SHOULD be used with a KDF capable of outputting a key
      with at least 256 bits of security and with a key wrapping
      algorithm with a key length of at least 256 bits.

2.3.  Certificate Conventions

   The conventions specified in this section augment [RFC5280].

   A recipient who employs the ML-KEM algorithm with a certificate MUST
   identify the public key in the certificate using the id-ML-KEM-512,
   id-ML-KEM-768, or id-ML-KEM-1024 object identifiers following the
   conventions specified in [I-D.ietf-lamps-kyber-certificates] and
   reproduced in Section 3.

   In particular, the key usage certificate extension MUST only contain
   keyEncipherment (Section 4.2.1.3 of [RFC5280]).

2.4.  SMIME Capabilities Attribute Conventions

   Section 2.5.2 of [RFC8551] defines the SMIMECapabilities attribute to
   announce a partial list of algorithms that an S/MIME implementation
   can support.  When constructing a CMS signed-data content type
   [RFC5652], a compliant implementation MAY include the
   SMIMECapabilities attribute that announces support for one or more of
   the ML-KEM algorithm identifiers.

   The SMIMECapability SEQUENCE representing the ML-KEM algorithm MUST
   include one of the ML-KEM object identifiers in the capabilityID
   field.  When the one of the ML-KEM object identifiers appears in the
   capabilityID field, the parameters MUST NOT be present.

3.  Identifiers

   All identifiers used by ML-KEM in CMS are defined elsewhere but
   reproduced here for convenience:

Prat, et al.             Expires 6 January 2025                 [Page 8]
Internet-Draft                ML-KEM in CMS                    July 2024

     id-TBD-NIST-KEM OBJECT IDENTIFIER ::= { TBD }

     id-ML-KEM-512 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }
     id-ML-KEM-768 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }
     id-ML-KEM-1024 OBJECT IDENTIFIER ::= { id-TBD-NIST-KEM TBD }

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

     id-alg-hkdf-with-sha256 OBJECT IDENTIFIER ::= { iso(1)
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) alg(3) 28 }
     id-alg-hkdf-with-sha512 OBJECT IDENTIFIER ::= { iso(1)
         member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) alg(3) 30 }

     id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 }
     id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 }

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

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

4.  Security Considerations

   [EDNOTE: many of the security considerations below apply to ML-KEM in
   general and are not specific to ML-KEM within CMS.  As this document
   and draft-ietf-lamps-kyber-certificates approach WGLC, the two
   Security Consideration sections should be harmonized and duplicate
   text removed.]

   The Security Considerations sections of
   [I-D.ietf-lamps-kyber-certificates] and [I-D.ietf-lamps-cms-kemri]
   apply to this specification as well.

   The ML-KEM variant and the underlying components need to be selected
   consistent with the desired security level.  Several security levels
   have been identified in the NIST SP 800-57 Part 1
   [NIST.SP.800-57pt1r5].  To achieve 128-bit security, ML-KEM-512
   SHOULD be used, the key-derivation function SHOULD provide at least
   128 bits of security, and the symmetric key-encryption algorithm
   SHOULD be AES Key Wrap with a 128-bit key.  To achieve 192-bit
   security, ML-KEM-768 SHOULD be used, the key-derivation function
   SHOULD provide at least 192 bits of security, and the symmetric key-
   encryption algorithm SHOULD be AES Key Wrap with a 192-bit key or
   larger.  In this case AES Key Wrap with a 256-bit key is typically

Prat, et al.             Expires 6 January 2025                 [Page 9]
Internet-Draft                ML-KEM in CMS                    July 2024

   used because AES-192 is not as commonly deployed.  To achieve 256-bit
   security, ML-KEM-1024 SHOULD be used, the key-derivation function
   SHOULD provide at least 256 bits of security, and the symmetric key-
   encryption algorithm SHOULD be AES Key Wrap with a 256-bit key.

   Provided all inputs are well-formed, the key establishment procedure
   of ML-KEM will never explicitly fail.  Specifically, the ML-
   KEM.Encaps and ML-KEM.Decaps algorithms from [FIPS203] will always
   output a value with the same data type as a shared secret key, and
   will never output an error or failure symbol.  However, it is
   possible (though extremely unlikely) that the process will fail in
   the sense that ML-KEM.Encaps and ML-KEM.Decaps will produce different
   outputs, even though both of them are behaving honestly and no
   adversarial interference is present.  In this case, the sender and
   recipient clearly did not succeed in producing a shared secret key.
   This event is called a decapsulation failure.  Estimates for the
   decapsulation failure probability (or rate) for each of the ML-KEM
   parameter sets are provided in Table 1 [EDNOTE: make sure this
   doesn't change] of [FIPS203] and reproduced here in Table 1.

              +===============+============================+
              | Parameter set | Decapsulation failure rate |
              +===============+============================+
              | ML-KEM-512    | 2^(-139)                   |
              +---------------+----------------------------+
              | ML-KEM-768    | 2^(-164)                   |
              +---------------+----------------------------+
              | ML-KEM-1024   | 2^(-174)                   |
              +---------------+----------------------------+

               Table 1: ML-KEM decapsulation failures rates

   Implementations MUST protect the ML-KEM private key, the key-
   encryption key, the content-encryption key, message-authentication
   key, and the content-authenticated-encryption key.  Disclosure of the
   ML-KEM private key could result in the compromise of all messages
   protected with that key.  Disclosure of the key-encryption key, the
   content- encryption key, or the content-authenticated-encryption key
   could result in compromise of the associated encrypted content.
   Disclosure of the key-encryption key, the message-authentication key,
   or the content-authenticated-encryption key could allow modification
   of the associated authenticated content.

   Additional considerations related to key management may be found in
   [NIST.SP.800-57pt1r5].

Prat, et al.             Expires 6 January 2025                [Page 10]
Internet-Draft                ML-KEM in CMS                    July 2024

   The security of the ML-KEM algorithm depends on a quality random
   number generator.  For further discussion on random number
   generation, see [RFC4086].

   ML-KEM encapsulation and decapsulation only outputs a shared secret
   and ciphertext.  Implementations SHOULD NOT use intermediate values
   directly for any purpose.

   Implementations SHOULD NOT reveal information about intermediate
   values or calculations, whether by timing or other "side channels",
   otherwise an opponent may be able to determine information about the
   keying data and/or the recipient's private key.  Although not all
   intermediate information may be useful to an opponent, it is
   preferable to conceal as much information as is practical, unless
   analysis specifically indicates that the information would not be
   useful to an opponent.

   Generally, good cryptographic practice employs a given ML-KEM key
   pair in only one scheme.  This practice avoids the risk that
   vulnerability in one scheme may compromise the security of the other,
   and may be essential to maintain provable security.

   Parties MAY gain assurance that implementations are correct through
   formal implementation validation, such as the NIST Cryptographic
   Module Validation Program (CMVP) [CMVP].

5.  IANA Considerations

   None.

   Within the CMS, algorithms are identified by object identifiers
   (OIDs).  All of the OIDs used in this document were assigned in other
   IETF documents, in ISO/IEC standards documents, by the National
   Institute of Standards and Technology (NIST).

6.  Acknowledgements

   This document borrows heavily from [I-D.ietf-lamps-rfc5990bis],
   [FIPS203], and [I-D.kampanakis-ml-kem-ikev2].  Thanks go to the
   authors of those documents.  "Copying always makes things easier and
   less error prone" - RFC8411.

   Thanks to Carl Wallace and Jonathan Hammel for the detailed review
   and Carl Wallace for interoperability testing.

7.  References

7.1.  Normative References

Prat, et al.             Expires 6 January 2025                [Page 11]
Internet-Draft                ML-KEM in CMS                    July 2024

   [FIPS203]  "TBD", n.d..

   [FIPS203-ipd]
              National Institute of Standards and Technology (NIST),
              "Module-Lattice-based Key-Encapsulation Mechanism
              Standard", 24 August 2023,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.203.ipd.pdf>.

   [I-D.ietf-lamps-cms-kemri]
              Housley, R., Gray, J., and T. Okubo, "Using Key
              Encapsulation Mechanism (KEM) Algorithms in the
              Cryptographic Message Syntax (CMS)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-cms-kemri-08, 6 February
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lamps-cms-kemri-08>.

   [I-D.ietf-lamps-cms-sha3-hash]
              Housley, R., "Use of the SHA3 One-way Hash Functions in
              the Cryptographic Message Syntax (CMS)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-cms-sha3-hash-04, 16 May
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lamps-cms-sha3-hash-04>.

   [I-D.ietf-lamps-kyber-certificates]
              Turner, S., Kampanakis, P., Massimo, J., and B.
              Westerbaan, "Internet X.509 Public Key Infrastructure -
              Algorithm Identifiers for Module-Lattice-Based Key-
              Encapsulation Mechanism (ML-KEM)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-kyber-certificates-03, 3
              March 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-kyber-certificates-03>.

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

   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3565>.

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

Prat, et al.             Expires 6 January 2025                [Page 12]
Internet-Draft                ML-KEM in CMS                    July 2024

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

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

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

   [RFC8619]  Housley, R., "Algorithm Identifiers for the HMAC-based
              Extract-and-Expand Key Derivation Function (HKDF)",
              RFC 8619, DOI 10.17487/RFC8619, June 2019,
              <https://www.rfc-editor.org/rfc/rfc8619>.

7.2.  Informative References

   [CMVP]     National Institute of Standards and Technology,
              "Cryptographic Module Validation Program", 2016,
              <https://csrc.nist.gov/projects/cryptographic-module-
              validation-program>.

   [FIPS180]  Dang, Q. H. and NIST, "Secure Hash Standard", NIST Federal
              Information Processing Standards Publications 180-4,
              DOI 10.6028/NIST.FIPS.180-4, July 2015,
              <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

   [I-D.ietf-lamps-rfc5990bis]
              Housley, R. and S. Turner, "Use of the RSA-KEM Algorithm
              in the Cryptographic Message Syntax (CMS)", Work in
              Progress, Internet-Draft, draft-ietf-lamps-rfc5990bis-08,
              5 June 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-rfc5990bis-08>.

Prat, et al.             Expires 6 January 2025                [Page 13]
Internet-Draft                ML-KEM in CMS                    July 2024

   [I-D.kampanakis-ml-kem-ikev2]
              Kampanakis, P. and G. Ravago, "Post-quantum Hybrid Key
              Exchange with ML-KEM in the Internet Key Exchange Protocol
              Version 2 (IKEv2)", Work in Progress, Internet-Draft,
              draft-kampanakis-ml-kem-ikev2-03, 29 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-kampanakis-
              ml-kem-ikev2-03>.

   [NIST-PQ]  National Institute of Standards and Technology, "Post-
              Quantum Cryptography Project", 20 December 2016,
              <https://csrc.nist.gov/projects/post-quantum-
              cryptography>.

   [NIST.SP.800-57pt1r5]
              Barker, E. and NIST, "Recommendation for key
              management:part 1 - general", NIST Special Publications
              (General) 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5,
              May 2020,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-57pt1r5.pdf>.

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

Appendix A.  ASN.1 Module

   RFC EDITOR: Please replace TBD2 with the value assigned by IANA
   during the publication of [I-D.ietf-lamps-cms-kemri].

Prat, et al.             Expires 6 January 2025                [Page 14]
Internet-Draft                ML-KEM in CMS                    July 2024

   <CODE BEGINS>
   CMS-ML-KEM-2024
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
     pkcs-9(9) smime(16) modules(0) id-mod-cms-ml-kem-2024(TBD1) }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   EXPORTS ALL;

   IMPORTS
     KEM-ALGORITHM
       FROM KEMAlgorithmInformation-2023  -- [I-D.ietf-lamps-cms-kemri]
          { iso(1) identified-organization(3) dod(6) internet(1)
            security(5) mechanisms(5) pkix(7) id-mod(0)
            id-mod-kemAlgorithmInformation-2023(TBD2) };

   kema-ml-kem-512 KEM-ALGORITHM ::= {
      IDENTIFIER id-ML-KEM-512
      PARAMS ARE absent
      PUBLIC-KEYS { pk-ml-kem-512 }
      UKM ARE optional
      SMIME-CAPS { IDENTIFIED BY id-ML-KEM-512 } }

   kema-ml-kem-768 KEM-ALGORITHM ::= {
      IDENTIFIER id-ML-KEM-768
      PARAMS ARE absent
      PUBLIC-KEYS { pk-ml-kem-768 }
      UKM ARE optional
      SMIME-CAPS { IDENTIFIED BY id-ML-KEM-768 } }

   kema-ml-kem-1024 KEM-ALGORITHM ::= {
      IDENTIFIER id-ML-KEM-1024
      PARAMS ARE absent
      PUBLIC-KEYS { pk-ml-kem-1024 }
      UKM ARE optional
      SMIME-CAPS { IDENTIFIED BY id-ML-KEM-1024 } }

   SMimeCaps SMIME-CAPS ::=
      { kema-ml-kem-512.&smimeCaps |
        kema-ml-kem-768.&smimeCaps |
        kema-ml-kem-1024.&smimeCaps,
        ... }

   END
   <CODE ENDS>

A.1.  Examples

Prat, et al.             Expires 6 January 2025                [Page 15]
Internet-Draft                ML-KEM in CMS                    July 2024

   EDITOR'S NOTE' - TODO
   section to be completed

Appendix B.  Revision History

   [EDNOTE: remove before publishing]

   *  draft-ietf-lamps-cms-kyber-04:

      -  Add HMAC with SHA2 KDF.

      -  Address Jonathan Hammell's review:

         o  Remove section introducing KEMs, move relevant bits to ML-
            KEM section

         o  Remove kemri processing summary, move relevant bits
            elsewhere

         o  Minor editorial changes

      -  ASN.1 module

   *  draft-ietf-lamps-cms-kyber-03:

      -  Switch MTI KDF from HKDF to KMAC.

   *  draft-ietf-lamps-cms-kyber-02:

      -  Rearrange and rewrite to align with rfc5990bis and I-D.ietf-
         lamps-cms-kemri

      -  Move Revision History to end to avoid renumbering later

      -  Add Security Considerations

   *  draft-ietf-lamps-cms-kyber-01:

      -  Details of the KEMRecipientInfo content when using Kyber;

      -  Editorial changes.

   *  draft-ietf-lamps-cms-kyber-00:

      -  Use of KEMRecipientInfo to communicate algorithm info;

      -  Editorial changes.

Prat, et al.             Expires 6 January 2025                [Page 16]
Internet-Draft                ML-KEM in CMS                    July 2024

Authors' Addresses

   Julien Prat
   CryptoNext Security
   16, Boulevard Saint-Germain
   75005 Paris
   France
   Email: julien.prat@cryptonext-security.com

   Mike Ounsworth
   Entrust Limited
   2500 Solandt Road -- Suite 100
   Ottawa, Ontario  K2K 3G5
   Canada
   Email: mike.ounsworth@entrust.com

   Daniel Van Geest
   CryptoNext Security
   16, Boulevard Saint-Germain
   75005 Paris
   France
   Email: daniel.vangeest.ietf@gmail.com

Prat, et al.             Expires 6 January 2025                [Page 17]