Internet-Draft ML-KEM in CMS December 2024
Prat, et al. Expires 16 June 2025 [Page]
Workgroup:
LAMPS
Internet-Draft:
draft-ietf-lamps-cms-kyber-07
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Prat
CryptoNext Security
M. Ounsworth
Entrust
D. Van Geest
CryptoNext Security

Use of ML-KEM in the Cryptographic Message Syntax (CMS)

Abstract

Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant key-encapsulation mechanism (KEM). Three parameters sets for the ML-KEM algorithm are specified by NIST in FIPS 203. 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 the KEMRecipientInfo structure.

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/cms-kyber.

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 16 June 2025.

▲

Table of Contents

1. Introduction

ML-KEM is an IND-CCA2-secure key-encapsulation mechanism (KEM) standardized in [FIPS203] by the US NIST PQC Project [NIST-PQ]. Prior to standardization, the algorithm was known as Kyber. ML-KEM and Kyber are not compatible.

Native support for Key Encapsulation Mechanisms (KEMs) was added to CMS in [RFC9629], 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. The parameters for each of the security levels were chosen to be at least as secure as a generic block cipher of 128, 192, or 256 bits, 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.

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

Encapsulate():

ML-KEM.Encaps() from section 7.2.

Decapsulate():

ML-KEM.Decaps() from section 7.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 [RFC9629] 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 [RFC9629]. 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 [RFC9629].

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-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024. These identifiers are reproduced in Section 3.

  • kemct is the ciphertext produced for this recipient.

  • 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-encryption 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 [RFC9629].

info:

optional context and application specific information. In this document this corresponds to the info KDF input from Section 5 of [RFC9629]. 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 [RFC9629], which is identified in the kekLength value from KEMRecipientInfo. Implementations MUST confirm that this value is consistent with the key size of the key-encryption algorithm.

HKDF may be used with different hash functions, including SHA-256 [FIPS180]. The object identifier id-alg-hkdf-with-sha256 is defined in [RFC8619], and specifies the use of HKDF with SHA-256. The parameter field MUST be absent when this algorithm identifier is used to specify the KDF for ML-KEM in KemRecipientInfo.

2.2.2. Components for ML-KEM in CMS

A compliant implementation MUST support HKDF with SHA-256, using the id-alg-hkdf-with-sha256 KDF object identifier, as the KemRecipientInfo KDF for all ML-KEM parameter sets. 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, an implementation must support the AES-Wrap-128 [RFC3394] key-encryption algorithm using the id-aes128-wrap key-encryption algorithm object identifier [RFC3565].

For ML-KEM-768 and ML-KEM-1024, an implementation must support the AES-Wrap-256 [RFC3394] key-encryption algorithm using the id-aes256-wrap key-encryption algorithm object identifier [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 [RFC9629]:

  • ML-KEM-512 SHOULD be used with a KDF capable of outputting a key with at least 128 bits of preimage strength 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 preimage strength 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 preimage strength 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-alg-ml-kem-512, id-alg-ml-kem-768, or id-alg-ml-kem-1024 object identifiers following the conventions specified in [I-D.ietf-lamps-kyber-certificates].

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 to indicate ML-KEM within CMS are defined elsewhere but reproduced here for convenience:

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

  id-alg-ml-kem-512 OBJECT IDENTIFIER ::= { kems 1 }

  id-alg-ml-kem-768 OBJECT IDENTIFIER ::= { kems 2 }

  id-alg-ml-kem-1024 OBJECT IDENTIFIER ::= { kems 3 }

  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 }

  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

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

For ML-KEM-specific security considerations refer to [I-D.sfluhrer-cfrg-ml-kem-security-considerations].

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 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 preimage strength, and the symmetric key-encryption algorithm SHOULD have a security strength of at least 128 bits. To achieve 192-bit security, ML-KEM-768 SHOULD be used, the key-derivation function SHOULD provide at least 192 bits of preimage strength, and the symmetric key-encryption algorithm SHOULD have a security strength of at least 192 bits. In the case of AES Key Wrap, a 256-bit key is typically 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 preimage strength, and the symmetric key-encryption algorithm SHOULD have a security strength of at least 256 bits.

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 for well-formed inputs. 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 of [FIPS203] and reproduced here in Table 1.

Table 1: ML-KEM decapsulation failure rates
Parameter set Decapsulation failure rate
ML-KEM-512 2^(-138.8)
ML-KEM-768 2^(-164.8)
ML-KEM-1024 2^(-174.8)

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

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

For the ASN.1 Module in Appendix A, IANA is requested to assign an object identifier (OID) for the module identifier (TBD1) with a Description of "id-mod-cms-ml-kem-2024". 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).

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, Jonathan Hammel, and Sean Turner for the detailed review and Carl Wallace for interoperability testing.

7. References

7.1. Normative References

[FIPS203]
"Module-lattice-based key-encapsulation mechanism standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.203, , <https://doi.org/10.6028/nist.fips.203>.
[I-D.ietf-lamps-kyber-certificates]
Turner, S., Kampanakis, P., Massimo, J., and B. Westerbaan, "Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)", Work in Progress, Internet-Draft, draft-ietf-lamps-kyber-certificates-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-06>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3394]
Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, , <https://www.rfc-editor.org/rfc/rfc3394>.
[RFC3565]
Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, , <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, , <https://www.rfc-editor.org/rfc/rfc5083>.
[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, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5652]
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8619>.
[RFC9629]
Housley, R., Gray, J., and T. Okubo, "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)", RFC 9629, DOI 10.17487/RFC9629, , <https://www.rfc-editor.org/rfc/rfc9629>.
[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, , <https://www.itu.int/rec/T-REC-X.680>.

7.2. Informative References

[CMVP]
National Institute of Standards and Technology, "Cryptographic Module Validation Program", , <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, , <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-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5990bis-10>.
[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-09, , <https://datatracker.ietf.org/doc/html/draft-kampanakis-ml-kem-ikev2-09>.
[I-D.sfluhrer-cfrg-ml-kem-security-considerations]
Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D. Shiu, "ML-KEM Security Considerations", Work in Progress, Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security-considerations-02, , <https://datatracker.ietf.org/doc/html/draft-sfluhrer-cfrg-ml-kem-security-considerations-02>.
[NIST-PQ]
National Institute of Standards and Technology, "Post-Quantum Cryptography Project", , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc4086>.
[RFC5911]
Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, DOI 10.17487/RFC5911, , <https://www.rfc-editor.org/rfc/rfc5911>.

Appendix A. ASN.1 Module

This appendix includes the ASN.1 module [X680] for ML-KEM. This module imports objects from [RFC5911], [RFC9629], [RFC8619], [I-D.ietf-lamps-kyber-certificates].

RFC EDITOR: Please replace TBD2 with the value assigned by IANA during the publication of [I-D.ietf-lamps-kyber-certificates]. Also please replace [I-D.ietf-lamps-kyber-certificates] in the module with a reference to the published RFC.

<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
  SMIME-CAPS
    FROM AlgorithmInformation-2009  -- [RFC5911]
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-algorithmInformation-02(58) }

  KEM-ALGORITHM
    FROM KEMAlgorithmInformation-2023  -- [RFC9629]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-kemAlgorithmInformation-2023(109) }

  kda-hkdf-with-sha256
    FROM HKDF-OID-2019  -- [RFC8619]
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-hkdf-oid-2019(68) }

  kwa-aes128-wrap, kwa-aes256-wrap
    FROM CMSAesRsaesOaep-2009  -- [RFC5911]
       { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0)
       id-mod-cms-aes-02(38) }

  id-alg-ml-kem-512, id-alg-ml-kem-768, id-alg-ml-kem-1024,
  pk-ml-kem-512, pk-ml-kem-768, pk-ml-kem-1024
    FROM X509-ML-KEM-2024 -- [I-D.ietf-lamps-kyber-certificates]
       { iso(1) identified-organization(3) dod(6)
         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-x509-ml-kem-2024(TBD2) };

--
-- ML-KEM Key Encapsulation Mechanism Algorithms
--

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

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

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

-- Updates for the SMIME-CAPS Set from RFC 5911

SMimeCapsSet SMIME-CAPS ::=
   { kema-ml-kem-512.&smimeCaps |
     kema-ml-kem-768.&smimeCaps |
     kema-ml-kem-1024.&smimeCaps |
     kda-hkdf-with-sha256.&smimeCaps |
     kwa-aes128-wrap.&smimeCaps |
     kwa-aes256-wrap.&smimeCaps,
     ... }

END

<CODE ENDS>

Appendix B. Security Strengths

Instead of defining the strength of a quantum algorithm in a traditional manner using the imprecise notion of bits of security, NIST has defined security levels by picking a reference scheme, which NIST expects to offer notable levels of resistance to both quantum and classical attack. To wit, a KEM algorithm that achieves NIST PQC security must require computational resources to break IND-CCA2 security comparable or greater than that required for key search on AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference.

Table 2: ML-KEM security strengths and sized
Level Parameter Set Encap. Key Decap. Key Ciphertext Secret
1 ML-KEM-512 800 1632 768 32
3 ML-KEM-768 1184 2400 1952 32
5 ML-KEM-1024 1568 3168 2592 32

Appendix C. ML-KEM CMS Enveloped-Data Example

This example shows the establishment of an AES-128 content-encryption key using:

In real-world use, the originator would encrypt the content- encryption key in a manner that would allow decryption with their own private key as well as the recipient's private key. This is omitted in an attempt to simplify the example.

C.1. Originator CMS Processing

Alice obtains Bob's ML-KEM-512 public key:

-----BEGIN PUBLIC KEY-----
MIIDMjALBglghkgBZQMEBAEDggMhADmVgV5ZfRBDVc8pqlMzyTJRhp1bzb5IcST2
Ari2pmwWxHYWSK12XPXYAGtRXpBafwrAdrDGLvoygVPnylcBaZ8TBfHmvG+QsOSb
aTUSts6ZKouAFt38GmYsfj+WGcvYad13GvMIlszVkYrGy3dGbF53mZbWf/mqvJdQ
Pyx7fi0ADYZFD7GAfKTKvaRlgloxx4mht6SRqzhydl0yDQtxkg+iE8lAk0Frg7gS
Tmn2XmLLUADcw3qpoP/3OXDEdy81fSQYnKb1MFVowOI3ajdipoxgXlY8XSCVcuD8
dTLKKUcpU1VntfxBPF6HktJGRTbMgI+YrddGZPFBVm+QFqkKVBgpqYoEZM5BqLtE
wtT6PCwglGByjvFKGnxMm5jRIgO0zDUpFgqasteDj3/2tTrgWqMafWRrevpsRZMl
JqPDdVYZvplMIRwqMcBbNEeDbLIVC+GCna5rBMVTXP9Ubjkrp5dBFyD5JPSQpaxU
lfITVtVQt4KmTBaItrZVvMeEIZekNML2Vjtbfwmni8xIgjJ4NWHRb0y6tnVUAAUH
gVcMZmBLgXrRJSKUc26LAYYaS1p0UZuLb+UUiaUHI5Llh2JscTd2V10zgGocjicy
r5fCaA9RZmMxxOuLvAQxxPloMtrxs8RVKPuhU/bHixwZhwKUfM0zdyekb7U7oR3l
y0GRNGhZUWy2rXJADzzyCbI2rvNaWArIfrPjD6/WaXPKin3SZ1r0H3oXthQzzRr4
D3cIhp9mVIhJeYCxrBCgzctjagDthoGzXkKRJMqANQcluF+DperDpKPMFgCQPmUp
NWC5szblrw1SnawaBIEZMCy3qbzBELlIUb8CEX8ZncSFqFK3Rz8JuDGmgx1bVMC3
kNIlz2u5LZRiomzbM92lEjx6rw4moLg2Ve6ii/OoB0clAY/WuuS2Ac9huqtxp6PT
UZejQ+dLSicsEl1UCJZCbYW3lY07OKa6mH7DciXHtEzbEt3kU5tKsII2NoPwS/eg
nMXEHf6DChsWLgsyQzQ2LwhKFEZ3IzRLrdAA+NjFN8SPmY8FMHzr0e3guBw7xZoG
WhttY7Js
-----END PUBLIC KEY-----

Bob's ML-KEM-512 public key has the following key identifier:

599788C37AED400EE405D1B2A3366AB17D824A51

Alice generates a shared secret and ciphertext using Bob's ML-KEM-512 public key, derives the key-encryption key from the shared secret and CMSORIforKEMOtherInfo using HKDF with SHA-256, randomly generates a 128-bit content-encryption key, uses AES-128-KEYWRAP to encrypt the content-encryption key with the key-encryption key, encrypts the plaintext content with the content-encryption key and encodes the EnvelopedData (using KEMRecipientInfo) and ContentInfo, and then sends the result to Bob.

The Base64-encoded result is:

-----BEGIN CMS-----
MIID8gYLKoZIhvcNAQkQARegggPhMIID3QIBADGCA4ikggOEBgsqhkiG9w0BCRAN
AzCCA3MCAQCAFFmXiMN67UAO5AXRsqM2arF9gkpRMAsGCWCGSAFlAwQEAQSCAwDz
6kG2NhIUhlAHMA3HCeC8G9o0Ey8HMa//d2N7a7e92ba+Xrwfp9NKfiwH3r26CvqG
Aj5LgU/hbzNkFGw1AfgXDQTcpHEjfPB2R/x6OxiuV6KPxOjqHbjDvyRoclHHrGfG
i4uBkgPSAXrBlzXop9n7F4sxae2grAJIWX8sl/Vs6BRcKmuAIXbriZTQnEoojgyr
ncDz3owBMBdLvA7STNEJ9vt3WaGV07/3qjSCHsxynDwWpiHYwf3Q++/VlZNrPnzZ
B/ulQtAWweHxgTpvX0k8WnCKSl9S5qGIMK2Tc4KBMSqb02pkSMDV/YEKCwPyFgIO
hEleCys+umJmUAbGm0cmH0Kev0sHAnYvg02uebvK2xFW6uboTy0Txj8okoy5sP6h
mRekF6qgrEEa3/CjkSAxW9iv986h64UUU0cWZeEaEl0eYR6LOf3e16ZPSYDC8Xo7
VjAZvYuf8QuLlqDCw73Rp+PT+fkFqfY4dxGXwZYMU/UOuQqi2IsT86W8gmsQPhEv
7EvSScX8TJSDsrQOVrGoHc5OymRmuepkn17ORYyrR8iKEDVJEDCGesJbgcCoi2VT
LFdDYOzMn1T6gSsmyg3KGWLqdn8csG/mPjKblyBmlYbM8KT4ICqQx1nBngGUfMIV
+v4wY9s0vcLSTBI5QCbgPRrIzz0B97sZdcp29uXA4Qlz2riuRpn38up1G90BGxvo
lukVQ8djNhhGgC60UJwA3bRn+O2xo/cSBkMSLJIIqA5QSY+zcPu90MqvN1JFkbO6
YJQbtuFvQ9hAmHJNrWRaXRGLJuH8gxUhG2bhOn5jjtgmVdKHx8gFDxHs13IQMHAU
//u5JHvJOnC8HLWPIbMTXa0giC7H22Gf7GMdYVG0pNr37wEJkfd7D4OKM5S0fXH3
4moC701Bgypt0D+inpqd+Vdyzylg5KkkoLcQqiE1tAPYc2FCSJNhZe/xA4/WOkoO
HS6/FvFcNaIxkwmNDl9BM4J+Zv4zxqcrqjSUuRM9r/IepBU22+EltUGXug15v+Mw
DQYLKoZIhvcNAQkQAxwCASAwCwYJYIZIAWUDBAEtBCgSWjJGbANW6249qJezunw8
TekPnqeXQxQsCApolNdBREvHJzVFD8fxMDoGCSqGSIb3DQEHATAeBglghkgBZQME
AS4wEQQM09P1v4RTaKUfxd6/AgEQgA0W/2sAf/+wpWYbxab8BBAcFxeZJbrC7Ifl
jQHB7vah
-----END CMS-----

This result decodes to:

   0 1010: SEQUENCE {
   4   11:  OBJECT IDENTIFIER
         :   authEnvelopedData (1 2 840 113549 1 9 16 1 23)
  17  993:  [0] {
  21  989:   SEQUENCE {
  25    1:    INTEGER 0
  28  904:    SET {
  32  900:     [4] {
  36   11:      OBJECT IDENTIFIER '1 2 840 113549 1 9 16 13 3'
  49  883:      SEQUENCE {
  53    1:       INTEGER 0
  56   20:       [0]
         :    59 97 88 C3 7A ED 40 0E E4 05 D1 B2 A3 36 6A B1
         :    7D 82 4A 51
  78   11:       SEQUENCE {
  80    9:        OBJECT IDENTIFIER '2 16 840 1 101 3 4 4 1'
         :         }
  91  768:       OCTET STRING
         :    F3 EA 41 B6 36 12 14 86 50 07 30 0D C7 09 E0 BC
         :    1B DA 34 13 2F 07 31 AF FF 77 63 7B 6B B7 BD D9
         :    B6 BE 5E BC 1F A7 D3 4A 7E 2C 07 DE BD BA 0A FA
         :    86 02 3E 4B 81 4F E1 6F 33 64 14 6C 35 01 F8 17
         :    0D 04 DC A4 71 23 7C F0 76 47 FC 7A 3B 18 AE 57
         :    A2 8F C4 E8 EA 1D B8 C3 BF 24 68 72 51 C7 AC 67
         :    C6 8B 8B 81 92 03 D2 01 7A C1 97 35 E8 A7 D9 FB
         :    17 8B 31 69 ED A0 AC 02 48 59 7F 2C 97 F5 6C E8
         :    14 5C 2A 6B 80 21 76 EB 89 94 D0 9C 4A 28 8E 0C
         :    AB 9D C0 F3 DE 8C 01 30 17 4B BC 0E D2 4C D1 09
         :    F6 FB 77 59 A1 95 D3 BF F7 AA 34 82 1E CC 72 9C
         :    3C 16 A6 21 D8 C1 FD D0 FB EF D5 95 93 6B 3E 7C
         :    D9 07 FB A5 42 D0 16 C1 E1 F1 81 3A 6F 5F 49 3C
         :    5A 70 8A 4A 5F 52 E6 A1 88 30 AD 93 73 82 81 31
         :    2A 9B D3 6A 64 48 C0 D5 FD 81 0A 0B 03 F2 16 02
         :    0E 84 49 5E 0B 2B 3E BA 62 66 50 06 C6 9B 47 26
         :    1F 42 9E BF 4B 07 02 76 2F 83 4D AE 79 BB CA DB
         :    11 56 EA E6 E8 4F 2D 13 C6 3F 28 92 8C B9 B0 FE
         :    A1 99 17 A4 17 AA A0 AC 41 1A DF F0 A3 91 20 31
         :    5B D8 AF F7 CE A1 EB 85 14 53 47 16 65 E1 1A 12
         :    5D 1E 61 1E 8B 39 FD DE D7 A6 4F 49 80 C2 F1 7A
         :    3B 56 30 19 BD 8B 9F F1 0B 8B 96 A0 C2 C3 BD D1
         :    A7 E3 D3 F9 F9 05 A9 F6 38 77 11 97 C1 96 0C 53
         :    F5 0E B9 0A A2 D8 8B 13 F3 A5 BC 82 6B 10 3E 11
         :    2F EC 4B D2 49 C5 FC 4C 94 83 B2 B4 0E 56 B1 A8
         :    1D CE 4E CA 64 66 B9 EA 64 9F 5E CE 45 8C AB 47
         :    C8 8A 10 35 49 10 30 86 7A C2 5B 81 C0 A8 8B 65
         :    53 2C 57 43 60 EC CC 9F 54 FA 81 2B 26 CA 0D CA
         :    19 62 EA 76 7F 1C B0 6F E6 3E 32 9B 97 20 66 95
         :    86 CC F0 A4 F8 20 2A 90 C7 59 C1 9E 01 94 7C C2
         :    15 FA FE 30 63 DB 34 BD C2 D2 4C 12 39 40 26 E0
         :    3D 1A C8 CF 3D 01 F7 BB 19 75 CA 76 F6 E5 C0 E1
         :    09 73 DA B8 AE 46 99 F7 F2 EA 75 1B DD 01 1B 1B
         :    E8 96 E9 15 43 C7 63 36 18 46 80 2E B4 50 9C 00
         :    DD B4 67 F8 ED B1 A3 F7 12 06 43 12 2C 92 08 A8
         :    0E 50 49 8F B3 70 FB BD D0 CA AF 37 52 45 91 B3
         :    BA 60 94 1B B6 E1 6F 43 D8 40 98 72 4D AD 64 5A
         :    5D 11 8B 26 E1 FC 83 15 21 1B 66 E1 3A 7E 63 8E
         :    D8 26 55 D2 87 C7 C8 05 0F 11 EC D7 72 10 30 70
         :    14 FF FB B9 24 7B C9 3A 70 BC 1C B5 8F 21 B3 13
         :    5D AD 20 88 2E C7 DB 61 9F EC 63 1D 61 51 B4 A4
         :    DA F7 EF 01 09 91 F7 7B 0F 83 8A 33 94 B4 7D 71
         :    F7 E2 6A 02 EF 4D 41 83 2A 6D D0 3F A2 9E 9A 9D
         :    F9 57 72 CF 29 60 E4 A9 24 A0 B7 10 AA 21 35 B4
         :    03 D8 73 61 42 48 93 61 65 EF F1 03 8F D6 3A 4A
         :    0E 1D 2E BF 16 F1 5C 35 A2 31 93 09 8D 0E 5F 41
         :    33 82 7E 66 FE 33 C6 A7 2B AA 34 94 B9 13 3D AF
         :    F2 1E A4 15 36 DB E1 25 B5 41 97 BA 0D 79 BF E3
 863   13:       SEQUENCE {
 865   11:        OBJECT IDENTIFIER
         :         hkdfWithSha256 (1 2 840 113549 1 9 16 3 28)
         :         }
 878    1:       INTEGER 32
 881   11:       SEQUENCE {
 883    9:        OBJECT IDENTIFIER
         :         aes256-wrap (2 16 840 1 101 3 4 1 45)
         :         }
 894   40:       OCTET STRING
         :    12 5A 32 46 6C 03 56 EB 6E 3D A8 97 B3 BA 7C 3C
         :    4D E9 0F 9E A7 97 43 14 2C 08 0A 68 94 D7 41 44
         :    4B C7 27 35 45 0F C7 F1
         :        }
         :       }
         :      }
 936   58:    SEQUENCE {
 938    9:     OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
 949   30:     SEQUENCE {
 951    9:      OBJECT IDENTIFIER
         :       aes256-GCM (2 16 840 1 101 3 4 1 46)
 962   17:      SEQUENCE {
 964   12:       OCTET STRING D3 D3 F5 BF 84 53 68 A5 1F C5 DE BF
 978    1:       INTEGER 16
         :        }
         :       }
 981   13:     [0] 16 FF 6B 00 7F FF B0 A5 66 1B C5 A6 FC
         :      }
 996   16:    OCTET STRING
         :    1C 17 17 99 25 BA C2 EC 87 E5 8D 01 C1 EE F6 A1
         :     }
         :    }
         :   }

C.2. Recipient CMS Processing

Bob's ML-KEM-512 private key:

-----BEGIN PRIVATE KEY-----
MFICAQAwCwYJYIZIAWUDBAQBBEAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob
HB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/
-----END PRIVATE KEY-----

Bob decapsulates the ciphertext in the KEMRecipientInfo to get the ML-KEM-512 shared secret, derives the key-encryption key from the shared secret and CMSORIforKEMOtherInfo using HKDF with SHA-256, uses AES-128-KEYWRAP to decrypt the content-encryption key with the key-encryption key, and decrypts the encrypted contents with the content-encryption key, revealing the plaintext content:

Hello, world!

Authors' Addresses

Julien Prat
CryptoNext Security
16, Boulevard Saint-Germain
75005 Paris
France
Mike Ounsworth
Entrust Limited
2500 Solandt Road -- Suite 100
Ottawa, Ontario K2K 3G5
Canada
Daniel Van Geest
CryptoNext Security
16, Boulevard Saint-Germain
75005 Paris
France