| Internet-Draft | Composite ML-KEM CMS | December 2025 |
| Ounsworth, et al. | Expires 6 June 2026 | [Page] |
This document defines conventions for using Composite ML-KEM within the Cryptographic Message Syntax (CMS). This document is intended to be coupled with the CMS KEMRecipientInfo mechanism in [RFC9629].¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://lamps-wg.github.io/draft-composite-kem/draft-ietf-lamps-pq-composite-kem.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-composite-kem/.¶
Discussion of this document takes place on the LAMPS Working Group mailing list (mailto:spams@ietf.org), which is archived at https://datatracker.ietf.org/wg/lamps/about/. Subscribe at https://www.ietf.org/mailman/listinfo/spams/.¶
Source for this draft and an issue tracker can be found at https://github.com/lamps-wg/draft-composite-kem.¶
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 6 June 2026.¶
Copyright (c) 2025 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.¶
This document acts as a companion to [I-D.ietf-lamps-pq-composite-kem] by providing conventions for using the Composite ML-KEM algorithm within the Cryptographic Message Syntax (CMS).¶
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. These words may also appear in this document in lower case as plain English words, absent their normative meanings.¶
This document is consistent with all terminology from [RFC9794]. In addition, the following terms are used in this document:¶
ALGORITHM: The usage of the term "algorithm" within this document generally refers to any function which has a registered Object Identifier (OID) for use within an ASN.1 AlgorithmIdentifier. This loosely, but not precisely, aligns with the definitions of "cryptographic algorithm" and "cryptographic scheme" given in [RFC9794].¶
COMBINER: A combiner specifies how multiple shared secrets are combined into a single shared secret.¶
DER: Distinguished Encoding Rules as defined in [X.690].¶
KEM: A cryptographic key establishment mechanism, making no assumptions about which algorithm.¶
PKI: Public Key Infrastructure, as defined in [RFC5280].¶
SHARED SECRET KEY: A value established between two communicating parties for use as cryptographic key material suitable for direct use by symmetric cryptographic algorithms. This document is concerned with shared secrets established via public key cryptographic operations.¶
Composite ML-KEM algorithms 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 chosen Composite ML-KEM Algorithm to securely transfer the content-encryption key from the originator to the recipient.¶
All recommendations for using Composite ML-KEM in CMS are fully aligned with the use of ML-KEM in CMS [I-D.ietf-lamps-cms-kyber].¶
A compliant implementation MUST support the following algorithm combinations for the KEMRecipientInfo kdf and wrap fields when the corresponding Composite ML-KEM algorithm is listed in the KEMRecipientInfo kem field. The KDFs listed below align with the KDF used internally within the KEM combiner. An implementation MAY also support other key-derivation functions and other key-encryption algorithms within CMS KEMRecipientInfo and SHOULD use algorithms of equivalent strength or greater.¶
| Composite ML-KEM Algorithm | KDF | Wrap |
|---|---|---|
| id-MLKEM768-RSA2048-HKDF-SHA256 | id-alg-hkdf-with-sha256 | id-aes128-wrap |
| id-MLKEM768-RSA3072-HKDF-SHA256 | id-alg-hkdf-with-sha256 | id-aes128-wrap |
| id-MLKEM768-RSA4096-HKDF-SHA256 | id-alg-hkdf-with-sha256 | id-aes128-wrap |
| id-MLKEM768-X25519-SHA3-256 | id-kmac256 | id-aes128-wrap |
| id-MLKEM768-ECDH-P256-HKDF-SHA256 | id-alg-hkdf-with-sha256 | id-aes256-wrap |
| id-MLKEM768-ECDH-P384-HKDF-SHA256 | id-alg-hkdf-with-sha256 | id-aes256-wrap |
| id-MLKEM768-ECDH-brainpoolP256r1-HKDF-SHA256 | id-alg-hkdf-with-sha256 | id-aes256-wrap |
| id-MLKEM1024-ECDH-P384-HKDF-SHA384 | id-alg-hkdf-with-sha384 | id-aes256-wrap |
| id-MLKEM1024-ECDH-brainpoolP384r1-HKDF-SHA384 | id-kmac256 | id-aes256-wrap |
| id-MLKEM1024-X448-SHA3-256 | id-kmac256 | id-aes256-wrap |
Full specifications for the referenced algorithms can be found either further down in this section, or in Appendix D.¶
Note that here we differ slightly from the internal KDF used within the KEM combiner in Section 6 of [I-D.ietf-lamps-pq-composite-kem] because [RFC9629] requires that the KDF listed in the KEMRecipientInfo kdf field must have an interface which accepts KDF(IKM, L, info), so here we need to use KMAC and cannot directly use SHA3. Since we require 256-bits of (2nd) pre-image resistance, we use KMAC256 for the Composite ML-KEM algorithms with internally use SHA3-256, as aligned with Table 3 of [SP.800-57pt1r5].¶
Unlike within the Composite KEM Combiner function, When used as a KDF for CMS, HKDF requires use of the HKDF-Expand step so that it can accept the length parameter kekLength from CMS KEMRecipientInfo as the HKDF parameter L.¶
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:¶
optional salt value (a non-secret random value). In this document this parameter is left at its default value, which is the string of HashLen zeros.¶
input keying material. In this document this is the shared secret outputted from the Encaps() or Decaps() functions. This corresponds to the IKM KDF input from Section 5 of [RFC9629].¶
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.¶
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 and SHA-384 [FIPS.180-4]. The object identifier id-alg-hkdf-with-sha256 and id-alg-hkdf-with-sha384 are defined in [RFC8619], and specify the use of HKDF with SHA-256 and SHA-384. The parameter field MUST be absent when this algorithm identifier is used to specify the KDF for ML-KEM in KemRecipientInfo.¶
KMAC256-KDF is a KMAC-based KDF specified for use in CMS in [RFC9688]. The definition of KMAC is copied here for convenience. Here, KMAC# indicates the use of either KMAC128-KDF or KMAC256-KDF, although only KMAC256 is used in this specification.¶
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 Encaps() or Decaps() functions. This corresponds to the IKM KDF input from Section 5 of [RFC9629].¶
X: the context, corresponding to the info KDF input from Section 5 of [RFC9629]. 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 [RFC9629], 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 KMAC256-KDF is id-kmac256, as defined in [RFC9688].¶
Since the customization label to KMAC# is not used, the parameter field MUST be absent when id-kmac256 is used as part of an algorithm identifier specifying the KDF to use for Composite ML-KEM in KemRecipientInfo.¶
When Composite ML-KEM 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 the Composite ML-KEM identifiers listed in Section 6 of [I-D.ietf-lamps-pq-composite-kem].¶
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 (to calculate the RecipientInfo KEK key) MAY be different than the KDF used within the Composite ML-KEM algorithm (to calculate the shared secret ss) and MAY also be different from any KDFs used internally within a component 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.¶
encryptedKey is the result of encryptiong the CEK with the KEK.¶
The conventions specified in this section augment RFC 5280 [RFC5280].¶
The willingness to accept a Composite ML-KEM Algorithm MAY be signaled by the use of the SMIMECapabilities Attribute as specified in Section 2.5.2. of [RFC8551] or the SMIMECapabilities certificate extension as specified in [RFC4262].¶
The intended application for the public key MAY be indicated in the key usage certificate extension as specified in Section 4.2.1.3 of [RFC5280]. If the keyUsage extension is present in a certificate that conveys a Composite ML-KEM public key, then the key usage extension MUST contain only the following value:¶
keyEncipherment¶
The digitalSignature and dataEncipherment values MUST NOT be present. That is, a public key intended to be employed only with a Composite ML-KEM algorithm MUST NOT also be employed for data encryption or for digital signatures. This requirement does not carry any particular security consideration; only the convention that KEM keys be identified with the keyEncipherment key usage.¶
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 the RSA-OAEP Algorithm.¶
The SMIMECapability SEQUENCE representing a Composite ML-KEM Algorithm MUST include the appropriate object identifier as per Section 6 of [I-D.ietf-lamps-pq-composite-kem] in the capabilityID field.¶
<CODE STARTS>
Composite-MLKEM-CMS-2025
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-composite-mlkem-cms-2025(TBDMOD) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
SMIME-CAPS
FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
kema-MLKEM768-RSA2048, kema-MLKEM768-RSA3072, kema-MLKEM768-RSA4096,
kema-MLKEM768-ECDH-P384, kema-MLKEM768-ECDH-brainpoolP256r1,
kema-MLKEM768-X25519, kema-MLKEM1024-ECDH-P384,
kema-MLKEM1024-ECDH-brainpoolP384r1, kema-MLKEM1024-X448
FROM Composite-MLKEM-2025
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-composite-mlkem-2025(TBDCompositeMOD) }
;
--
-- Expand the S/MIME capabilities set used by CMS [RFC5911]
--
-- TODO: this doesn't compile, error:
-- "The referenced object in the 'ValueFromObject'
-- syntax with the field '&smimeCaps' is invalid or does not exist."
-- We need help from an SMIME expert
SMimeCaps SMIME-CAPS ::=
{ kema-MLKEM768-RSA2048.&smimeCaps |
kema-MLKEM768-RSA3072.&smimeCaps |
kema-MLKEM768-RSA4096.&smimeCaps |
kema-MLKEM768-ECDH-P384.&smimeCaps |
kema-MLKEM768-ECDH-brainpoolP256r1.&smimeCaps |
kema-MLKEM768-X25519.&smimeCaps |
kema-MLKEM1024-ECDH-P384.&smimeCaps |
kema-MLKEM1024-ECDH-brainpoolP384r1.&smimeCaps |
kema-MLKEM1024-X448.&smimeCaps,
... }
END
<CODE ENDS>
¶
IANA is requested to allocate a value from the "SMI Security for PKIX Module Identifier" registry [RFC7299] for the included ASN.1 module.¶
All security considerations from [I-D.ietf-lamps-pq-composite-kem] apply.¶
TODO: something about choices of CMS KDFs?¶
TODO - say something meaningful about backwards compatibility within the CMS context.¶
TODO - shorten this to the bit that's relevant to CMS.¶
ML-KEM always requires the public key in order to perform various steps of the Fujisaki-Okamoto decapsulation [FIPS.203], and for this reason the private key encoding specified in FIPS 203 includes the public key. Therefore it is not required to carry it in the OneAsymmetricKey.publicKey field, which remains optional, but is strictly speaking redundant since an ML-KEM public key can be parsed from an ML-KEM private key, and thus populating the OneAsymmetricKey.publicKey field would mean that two copies of the public key data are transmitted.¶
With regard to the traditional algorithms, RSA or Elliptic Curve, in order to achieve the public-key binding property the KEM combiner used to form the Composite ML-KEM, the combiner requires the traditional public key as input to the KDF that derives the output shared secret. Therefore it is required to carry the public key within the respective OneAsymmetricKey.publicKey as per the private key encoding given in Section 4.2 of [I-D.ietf-lamps-pq-composite-kem]. Implementers who choose to use a different private key encoding than the one specified in this document MUST consider how to provide the component public keys to the decapsulate routine. While some implementations might contain routines to computationally derive the public key from the private key, it is not guaranteed that all implementations will support this; for this reason the interoperable composite private key format given in this document in Section 4.2 of [I-D.ietf-lamps-pq-composite-kem] requires the public key of the traditional component to be included.¶
TODO - Fix this once we have test vectors.¶
The following test vectors are provided in a format similar to the NIST ACVP Known-Answer-Tests (KATs).¶
The structure is that a global cacert is provided which is used to sign each KEM certificate.
Within each test case there are the following values:¶
tcId the name of the algorithm.¶
ek the encapsulation public key.¶
x5c the X.509 certificate of the encapsulation key, signed by the cacert.¶
dk the decapsulation private key.¶
c the ciphertext.¶
k the derived shared secret key.¶
Implementers should be able to perform the following tests using the test vectors below:¶
Load the public key ek or certificate x5c and perform an encapsulation for it.¶
Load the decapsulation private key dk and the ciphertext c and ensure that the same shared secret key k can be derived.¶
Test vectors are provided for each underlying component in isolation for the purposes of debugging.¶
Due to the length of the test vectors, you may prefer to retrieve them from GitHub. The reference implementation that generated them is also available:¶
https://github.com/lamps-wg/draft-composite-kem/tree/main/src¶
#{::include src/testvectors_wrapped.json} #~~~¶
TODO: trim this down to only the ones we use in this CMS doc.¶
This section provides references to the full specification of the algorithms used in the composite constructions.¶
| Component KEM Algorithm ID | OID | Specification |
|---|---|---|
| id-ML-KEM-768 | 2.16.840.1.101.3.4.4.2 | [FIPS.203] |
| id-ML-KEM-1024 | 2.16.840.1.101.3.4.4.3 | [FIPS.203] |
| id-X25519 | 1.3.101.110 | [RFC7748], [RFC8410] |
| id-X448 | 1.3.101.111 | [RFC7748], [RFC8410] |
| id-ecDH | 1.3.132.1.12 | [RFC5480], [RFC5915], [SEC1] |
| id-RSAES-OAEP | 1.2.840.113549.1.1.7 | [RFC8017] |
| Elliptic CurveID | OID | Specification |
|---|---|---|
| secp256r1 | 1.2.840.10045.3.1.7 | [RFC6090], [SEC2] |
| secp384r1 | 1.3.132.0.34 | [RFC6090], [SEC2] |
| secp521r1 | 1.3.132.0.35 | [RFC6090], [SEC2] |
| brainpoolP256r1 | 1.3.36.3.3.2.8.1.1.7 | [RFC5639] |
| brainpoolP384r1 | 1.3.36.3.3.2.8.1.1.11 | [RFC5639] |
| HashID | OID | Specification |
|---|---|---|
| id-sha3-256 | 2.16.840.1.101.3.4.2.8 | [FIPS.202] |
This document incorporates contributions and comments from a large group of experts. The Editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past year in pursuit of this document:¶
Serge Mister (Entrust), Ali Noman (Entrust), Peter C. (UK NCSC), Sophie Schmieg (Google), Deirdre Connolly (SandboxAQ), Falko Strenzke (MTG AG), Dan van Geest (Crypto Next), Piotr Popis (Enigma), and Douglas Stebila (University of Waterloo).¶
Thanks to Giacomo Pope (github.com/GiacomoPope) whose ML-DSA and ML-KEM implementation was used to generate the test vectors.¶
We are grateful to all, including any contributors who may have been inadvertently omitted from this list.¶
This document borrows text from similar documents, including those referenced below. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - [RFC8411].¶