]> Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

OpenCA Labs

New York City, New York United States of America director@openca.org

Bundesdruckerei GmbH

Kommandantenstr. 18 Berlin 10969 Germany jan.klaussner@bdr.de

Cisco Systems

sfluhrer@cisco.com

Security LAMPS X.509 Post-Quantum KEM This document defines combinations of US NIST ML-KEM in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML-KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the LAMPS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The advent of quantum computing poses a significant threat to current cryptographic systems because traditional cryptographic key establishment algorithms such as RSA-OAEP, Diffie-Hellman and its elliptic curve variants will become vulnerable to quantum attacks. Unlike previous migrations between cryptographic algorithms, this migration gives us the foresight that traditional cryptographic algorithms will be broken in the future, but will remain strong in the interim, the only uncertainty is around the timing. But there are also some novel challenges. For instance, the aggressive migration timelines may require deploying PQC algorithms before their implementations have been fully hardened or certified, and dual-algorithm data protection may be desirable over a longer time period to hedge against security vulnerabilities and other implementation flaws in the new implementations. Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as "Post-Quantum / Traditional (PQ/T) Hybrids" . This specification defines a specific instantiation of the PQ/T Hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key encapsulation mechanism (KEM). The composite KEM presents a single public key and ciphertext such that it can be treated as a single atomic algorithm at the protocol level. This provides a property referred to as "protocol backwards compatibility" since it can be applied to protocols that are not explicitly hybrid-aware. The idea of a composite was first presented in . Composite algorithms retain some security even if one of their component algorithms is broken, which is discussed in detail in . This specification creates PQ/T Hybrids with the Module-Lattice-based Key Encapsulation Mechanism (ML-KEM), defined in as the PQ component. Instantiations of the composite ML-KEM scheme are provided based on ML-KEM, RSA-OAEP and ECDH. The full list of algorithms registered by this specification is in . Application backwards compatibility in the sense of upgraded systems continuing to interoperate with legacy systems is not provided by the mechanisms defined in in this specification; this is discussed further in . Certain jurisdictions have recommended that ML-KEM be used exclusively within a PQ/T hybrid framework. The use of a composite scheme provides a straightforward implementation of hybrid solutions compatible with (and advocated by) some governments and cybersecurity agencies , . In some situations it might be possible to add Post-Quantum, via a PQ/T Hybrid, to an already audited and compliant solution without invalidating the existing certification, whereas a full replacement of the traditional cryptography would almost certainly incur regulatory and compliance delays. In other words, PQ/T Hybrids can allow for deploying Post-Quantum Cryptography before the PQ modules and operational procedures are fully audited and certified. This, more than any other requirement, is what motivates the large number of algorithm combinations in this specification: The intention is to provide a stepping stone from which any cryptographic algorithm an organization has deployed today can evolve or transition. While this specification registers a large number of composite algorithms, it is expected that organizations will choose to deploy a single composite algorithm, or a small number of composite algorithms, that meets the needs of their environment, and very few implementers will need concern themselves with the entire list. This specification does not specify any mandatory-to-implement algorithms, but provides a short-list of recommended composite algorithms for common use-cases. Composite ML-KEM is applicable in any PKIX-related application that would otherwise use ML-KEM.

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 BCP 14 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 specification is consistent with all terminology from . Some relevant definitions from are copied here for easier reading. In addition, the following terms are used in this specification: ALGORITHM: The usage of the term "algorithm" within this specification generally refers to any function which has a registered Object Identifier (OID) for use within an ASN.1 AlgorithmIdentifier. APPLICATION BACKWARDS COMPATIBILITY: A property indicating whether an upgraded and non-upgraded application can successfully establish communication. COMBINER: A combiner specifies how multiple shared secret keys are combined into a single shared secret key. COMPOSITE CRYPTOGRAPHIC ELEMENT: defines composites as: A cryptographic element that incorporates multiple component cryptographic elements of the same type for use in a multi-algorithm scheme, such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements. For example this could be an asymmetric algorithm such as "ML-KEM-768" or "RSA-OAEP". DER: Distinguished Encoding Rules as defined in . ECDH: the Elliptic Curve Diffie-Hellman key agreement scheme defined in section 5.7.1.2 of . KEM: A key encapsulation mechanism as defined in . PKI: Public Key Infrastructure, as defined in . POST-QUANTUM TRADITIONAL (PQ/T) HYBRID SCHEME: defines a PQ/T Hybrid Scheme as: A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. PROTOCOL BACKWARDS COMPATIBILITY: A property whereby a new feature can be added to a protocol without requiring any changes to the protocol's specification and only minimal changes to its implementations (such as adding new identifiers). Typically this means that the new feature fits within a defined extension point of the protocol instead of requiring a structural change to the protocol. This is notable because many PQ/T Hybrids require modification of the protocol to make it "hybrid aware", whereas this specification presents as a standalone algorithm and thus can take advantage of existing cryptographic agility mechanisms. ML-KEM: The Module-Lattice-based Key Encapsulation Mechanism algorithm defined in RSA: The Rivest-Shamir-Adleman cryptosystem, used in this specification as the RSA-OAEP (Optimal Asymmetric Encryption Padding) scheme defined in . 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 specification is concerned with shared secrets established via public key cryptographic operations. X25519 and X448: The Edwards Curve Diffie-Hellman scheme defined in with pramater sets X25519 and X448.

Notation The algorithm descriptions use python-like syntax. The following symbols deserve special mention:

• || represents concatenation of two byte arrays.
• [:] represents byte array slicing.
• (a, b) represents a pair of values a and b. Typically this indicates that a function returns multiple values; the exact conveyance mechanism -- tuple, struct, output parameters, etc -- is left to the implementer.
• (a, _): represents a pair of values where one -- the second one in this case -- is ignored.
• func(a) -> b: represents a function named func that takes a as input and produces b.
• Func<TYPE>(): represents a function that is parametrized by <TYPE> meaning that the function's implementation will have minor differences depending on the underlying TYPE. Typically this means that a function will need to look up different constants or use different underlying cryptographic primitives depending on which composite algorithm it is implementing.

Composite Design Philosophy Composite algorithms, as defined in this specification, follow the definition in and should be regarded as a single algorithm that performs a single cryptographic operation typical of a key establishment mechanism.This generally means that the complexity of combining algorithms can and should be handled by the cryptographic library or cryptographic module. The design intent is that protocols such as PKCS#10 , CMP , X.509 , the CMS , and the Trust Anchor Format can treat composite algorithms as they would any other algorithm without the protocol layer to have any "hybrid-awareness". This is a property referred to as "protocol backwards-compatibility". Discussion of the specific choices of algorithm pairings can be found in .

Overview of the Composite ML-KEM Scheme Composite ML-KEM is a PQ/T hybrid Key Encapsulation Mechanism (KEM) which combines ML-KEM as specified in and with one of RSA-OAEP defined in , the Elliptic Curve Diffie-Hellman key agreement schemes ECDH defined in section 5.7.1.2 of , and X25519 / X448 defined in . A KEM combiner function is used to combine the two component shared secret keys into a single shared secret key. Composite Key Encapsulation Mechanisms are defined as cryptographic primitives that consist of three algorithms. These definitions are borrowed from .

• KeyGen() -> (pk, sk): A probabilistic key generation algorithm, which generates a public key pk and a secret key sk. Some cryptographic modules may also expose a KeyGen(seed) -> (pk, sk), which generates pk and sk deterministically from a seed. This specification assumes a seed-based keygen for ML-KEM.
• Encap(pk) -> (ss, ct): A probabilistic encapsulation algorithm, which takes as input a public key pk and outputs a ciphertext ct and shared secret key ss. Note: this specification uses Encap() to conform to , but uses Encaps().
• Decap(sk, ct) -> ss: A decapsulation algorithm, which takes as input a secret key sk and ciphertext ct and outputs a shared secret ss, or in some cases a distinguished error value. Note: this specification uses Decap() to conform to , but uses Decaps().

The KEM interface was chosen as the interface for a composite key establishment because it allows for arbitrary combinations of component algorithm types since both key transport and key agreement mechanisms can be promoted into KEMs as described in and below. The following algorithms are defined for serializing and deserializing component values. These algorithms are inspired by similar algorithms in .

• SerializePublicKey(mlkemPK, tradPK) -> bytes: Produce a byte string encoding of the component public keys.
• DeserializePublicKey(bytes) -> (mlkemPK, tradPK): Parse a byte string to recover the component public keys.
• SerializeCiphertext(mlkemCT, tradCT) -> bytes: Produce a byte string encoding of the component ciphertexts.
• DeserializeCiphertext(bytes) -> (mlkemCT, tradCT): Parse a byte string to recover the component ciphertexts.
• SerializePrivateKey(mlkemSeed, tradSK) -> bytes: Produce a byte string encoding of the component private keys.
• DeserializePrivateKey(bytes) -> (mlkemSeed, tradSK): Parse a byte string to recover the component private keys.

Full definitions of serialization and deserialization algorithms can be found in .

Promotion of RSA-OAEP into a KEM The RSA Optimal Asymmetric Encryption Padding (OAEP), as defined in section 7.1 of is a public key encryption algorithm used to transport key material from a sender to a receiver. A "key transport" type algorithm has the following API:

• Encrypt(pk, ss) -> ct: Take an existing shared secret key ss and encrypt it for pk.
• Decrypt(sk, ct) -> ss: Decrypt the ciphertext ct to recover ss.

Note the difference between the API of RSA.Encrypt(pk, ss) -> ct and KEM.Encap(pk) -> (ss, ct) presented above. For this reason, RSA-OAEP cannot be directly combined with ML-KEM. Fortunately, a key transport mechanism such as RSA-OAEP can be easily promoted into a KEM by having the sender generate a random 256 bit shared secret key and encrypt it. Note that the OAEP label L is left to its default value, which is the empty string as per . The shared secret key output by the overall Composite ML-KEM already binds a composite KEM Combiner Label, so there is no need to also use the component Label. The value of ss_len as well as concrete values for all the RSA-OAEP parameters used within this specification can be found in . Decap(sk, ct) -> ss is accomplished by direct use of OAEP Decrypt. The encodings for the public key (pkR), private key (skR), and ciphertext (enc) are described in . A quick note on the choice of RSA-OAEP as the supported RSA encryption primitive. RSA-KEM is cryptographically robust and is more straightforward to work with, but it has fairly limited adoption and therefore is of limited value as a PQ migration mechanism. Also, while RSA-PKCS#1v1.5 is still widely used, it is hard to make secure and no longer FIPS-approved as of the end of 2023 , so it is of limited forwards value. This leaves RSA-OAEP as the remaining choice. See for further discussion of algorithm choices. Note that, at least at the time of writing, the algorithm RSAOAEPKEM is not defined as a standalone algorithm within PKIX standards and it does not have an assigned algorithm OID, so it cannot be used directly with CMS KEMRecipientInfo ; it is merely a building block for the composite algorithm.

Promotion of ECDH into a KEM The elliptic curve Diffie-Hellman algorithm identified by the OID id-ecDH as defined in and is a key agreement algorithm requiring both parties to contribute an asymmetric keypair to the derivation of the shared secret key. A "key agreement" type algorithm has the following API:

• DH(skX, pkY) -> ss: Each party combines their secret key skX with the other party's public key pkY.

Note the difference between the API of DH(skX, pkY) -> ss and KEM.Encap(pk) -> (ss, ct) presented above. For this reason, a Diffie-Hellman key exchange cannot be directly combined with ML-KEM. Fortunately, a Diffie-Hellman key agreement can be easily promoted into a KEM Encap(pk) -> (ss, ct) by having the sender generate an ephemeral keypair for themself and sending their public key as the ciphertext ct. Composite ML-KEM uses a simplified version of the DHKEM definition from : Decap(sk, ct) -> ss is accomplished in the analogous way. This construction applies for all variants of elliptic curve Diffie-Hellman used in this specification: ECDH, X25519, and X448. For ECDH, DH() yields the value Z as described in section 5.7.1.2 of . For X25519 and X448, DH() yields the value K as described in section 6 of . The encodings for the public key (pkR), private key (skR), and ciphertext (pkE) are described in . The promotion of DH to a KEM is similar to the DHKEM functions in , but it is simplified in the following ways:

1. Notation has been aligned to the notation used in this specification.
2. Since a KEM Combiner Label is included explicitly in the Composite ML-KEM combiner, there is no need to perform the labeled steps of ExtractAndExpand().
3. Since the ciphertext and receiver's public key are included explicitly in the Composite ML-KEM combiner, there is no need to construct the kem_context object.

Note that here, SerializePublicKey() and DeserializePublicKey() refer to the underlying encoding of the DH primitive, and not to the composite serialization functions defined in . Note that, at least at the time of writing, the algorithm DHKEM is not defined as a standalone algorithm within PKIX standards and it does not have an assigned algorithm OID, so it cannot be used directly with CMS KEMRecipientInfo ; it is merely a building block for the composite algorithm.

Composite ML-KEM Functions This section describes the composite ML-KEM functions needed to instantiate the public API of a Key Encapsulation Mechanism as defined in .

Key Generation In order to maintain security properties of the composite, this specification strictly forbids re-using component key material between composite and non-composite keys, or between multiple composite keys. This means that an invocation of Composite-ML-KEM.KeyGen() MUST perform, or otherwise guarantee, fresh generation of the key material for both underlying algorithms and MUST NOT reuse existing key material. See for a discussion. To generate a new keypair for composite schemes, the KeyGen() -> (pk, sk) function is used. The KeyGen() function calls the two key generation functions of the component algorithms independently. Multi-threaded, multi-process, or multi-module applications might choose to execute the key generation functions in parallel for better key generation performance or architectural modularity. To generate an ML-KEM key pair this specification uses the function ML-KEM.KeyGen_internal(d, z). According to d and z are two random 32 Byte values. This document combines both values in mlkemSeed by concatenating them so that mlkemSeed = d || z. The following describes how to instantiate a KeyGen() function for a given composite algorithm represented by <OID>. .KeyGen() -> (pk, sk) Explicit Inputs: None Implicit Inputs mapped from : ML-KEM The underlying ML-KEM algorithm and parameter set, for example "ML-KEM-768". Trad The underlying traditional algorithm and parameter, for example "RSA-OAEP" or "X25519". Output: (pk, sk) The composite keypair. Key Generation Process: 1. Generate component keys mlkemSeed = Random(64) (mlkemPK, mlkemSK) = ML-KEM.KeyGen_internal( mlkemSeed[:32], mlkemSeed[32:] ) (tradPK, tradSK) = Trad.KeyGen() 2. Check for component key gen failure if NOT (mlkemPK, mlkemSK) or NOT (tradPK, tradSK): output "Key generation error" 3. Output the composite public and private keys pk = SerializePublicKey(mlkemPK, tradPK) sk = SerializePrivateKey(mlkemSeed, tradSK) return (pk, sk) ]]> In order to ensure fresh keys, the key generation functions MUST be executed for both component algorithms. Compliant parties MUST NOT use, import or export component keys that are used in other contexts, combinations, or by themselves as keys for standalone algorithm use. For more details on the security considerations around key reuse, see . If one of the component KeyGen() routines returns an error, then this error MUST be propagated by the Composite-ML-KEM.KeyGen() routine. Further discussion can be found below in .

Allowed Modifications to the Key Generation Process Key generation is a process that is entirely internal to a cryptographic module, and as such it is often customized to fit the performance or operational requirements of the module. In cases where the private keys never leave the module or are otherwise not required to interoperate with other cryptographic modules, it is not required for interoperability for the private keys to match the format described in this specification. Therefore, in general, implementations of Composite ML-KEM MAY use an alternate key generation process so long as it generates compatible public keys, and so long as both component keys are freshly-generated and not re-used in a standalone key or within another composite key. Below are some examples of modifications that an implementer MAY make to the key generation process. Implementations MAY modify this process to additionally output the expanded mlkemSK or to make use of ML-KEM.KeyGen_internal(d, z) as needed to expand the ML-KEM seed (d || z) into an expanded key prior to performing a signing operation. In cases where it is desirable to have a deterministic KeyGen of one or both component keys from a seed, this process MAY be modified to expose an interface of Composite-ML-KEM<OID>.KeyGen(seed) such that one component algorithm is generated from the seed and the other from random, or the input seed is cryptohraphically expanded to produce seeds for both components. Security analysis of such a modified key generation process is outside the scope of this document. Where interoperable private keys are not required, implementations MAY choose to use a different private key representation than the one given in . For example, the component keys MAY be stored in separate cryptographic modules, or MAY be stored in separate PKCS#8 objects, or MAY be stored in a format that preserves the ML-KEM expanded key instead of the ML-KEM seed. The required modifications to the key generation process, as well as the signature generation process below, to support these private key representations are considered compliant with this specification so long as they generate compatible public keys, and so long as both component keys are freshly-generated. Note that when implementing Composite ML-KEM with a private key format that does not preserve the ML-KEM seed, especially when implementing on top of a cryptographic module that does not support seeds, it will be impossible to reconstruct a compliant seed-based private key as described in

Encapsulation The Encap(pk) of a Composite ML-KEM algorithm is designed to behave exactly the same as ML-KEM.Encaps(ek) defined in Algorithm 20 in Section 7.2 of . Specifically, Composite-ML-KEM.Encap(pk) produces a 256-bit shared secret key that can be used directly with any symmetric-key cryptographic algorithm. In this way, Composite ML-KEM can be used as a direct drop-in replacement anywhere that ML-KEM is used. The following describes how to instantiate a Encap(pk) function for a given composite algorithm represented by <OID>. .Encap(pk) -> (ss, ct) Explicit Inputs: pk Composite public key consisting of encryption public keys for each component. Implicit inputs mapped from : ML-KEM The underlying ML-KEM algorithm and parameter set, for example "ML-KEM-768". Trad The underlying ML-KEM algorithm and parameter set, for example "RSA-OAEP" or "X25519". Label KEM Combiner Label value for binding the ciphertext to the Composite OID. See section on KEM Combiner Labels below. Output: ss The shared secret key, a 256-bit key suitable for use with symmetric cryptographic algorithms. ct The ciphertext, a byte string. Encap Process: 1. Separate the public keys. (mlkemPK, tradPK) = DeserializePublicKey(pk) 2. Perform the respective component Encap operations according to their algorithm specifications. (mlkemCT, mlkemSS) = ML-KEM.Encaps(mlkemPK) (tradCT, tradSS) = TradKEM.Encap(tradPK) 3. If either ML-KEM.Encaps() or TradKEM.Encap() return an error, then this process must return an error. if NOT (mlkemCT, mlkemSS) or NOT (tradCT, tradSS): output "Encapsulation error" 4. Encode the ciphertext ct = SerializeCiphertext(mlkemCT, tradCT) 5. Combine the KEM secrets and additional context to yield the composite shared secret key. ss = KemCombiner(mlkemSS, tradSS, tradCT, tradPK, Label) 6. Output composite shared secret key and ciphertext. return (ss, ct) ]]> The specific values for Label are defined per Composite ML-KEM algorithm in . Errors produced by the component Encaps() routines MUST be forwarded on to the calling application. Further discussion can be found below in .

Decapsulation The Decap(sk, ct) -> ss of a Composite ML-KEM algorithm is designed to behave exactly the same as ML-KEM.Decaps(dk, c) defined in Algorithm 21 in Section 7.3 of . Specifically, Composite-ML-KEM.Decap(sk, ct) produces a 256-bit shared secret key that can be used directly with any symmetric-key cryptographic algorithm. In this way, Composite ML-KEM can be used as a direct drop-in replacement anywhere that ML-KEM is used. The following describes how to instantiate a Decap(sk, ct) function for a given composite algorithm represented by <OID>. .Decap(sk, ct) -> ss Explicit inputs sk Composite private key consisting of decryption private keys for each component. ct The ciphertext, a byte string. Implicit inputs mapped from : ML-KEM The underlying ML-KEM algorithm and parameter set, for example "ML-KEM-768". Trad The underlying traditional algorithm and parameter set, for example "RSA-OAEP" or "X25519". Label KEM Combiner Label value for binding the ciphertext to the Composite ML-KEM OID. See section on KEM Combiner Labels below. Implicit inputs looked up from SK: tradPK The traditional public key is required for the KEM combiner. For discussion of where to get this value, see the Decapsulation Requires the Public Key section. Output: ss The shared secret key, a 256-bit key suitable for use with symmetric cryptographic algorithms. Decap Process: 1. Separate the private keys and ciphertexts (mlkemSeed, tradSK) = DeserializePrivateKey(sk) (_, mlkemSK) = ML-KEM.KeyGen(mlkemSeed[:32], mlkemSeed[32:]) (mlkemCT, tradCT) = DeserializeCiphertext(ct) 2. Perform the respective component Decap operations according to their algorithm specifications. mlkemSS = ML-KEM.Decaps(mlkemSK, mlkemCT) tradSS = TradKEM.Decap(tradSK, tradCT) 3. If either ML-KEM.Decaps() or TradKEM.Decap() return an error, then this process must return an error. if NOT mlkemSS or NOT tradSS: output "Decapsulation error" 4. Combine the KEM secrets and additional context to yield the composite shared secret key. ss = KemCombiner(mlkemSS, tradSS, tradCT, tradPK, Label) 5. Output composite shared secret key. return ss ]]> Steps 2 and 4 SHOULD be performed in a timing-invariant way to prevent side-channel attackers from learning any of the inputs or output of the KEM combiner. Step 4 requires the Decaps() process to have access to tradPK, which is not carried in the private key format and therefore the implementation is required to acquire it from some out-of-band means. The Operational Considerations provides further discussion on this. It is possible to use component private keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this specification so long as it produces the same output and error handling as the process sketched above. In order to properly achieve its security properties, the KEM combiner requires that all inputs are fixed-length or length-encoded. Since each Composite ML-KEM algorithm fully specifies its component algorithms, including key sizes, all inputs should be fixed-length in non-error scenarios except for minor variations introduced by encoding. In the cases where there are minor variations introduced by encoding, those encodings already have a fixed-length prefix followed by length-encoded data, so the requirements for the KEM combiner security properties hold (namely that the input is injective). However some implementations may choose to perform additional checking to handle certain error conditions. In particular, the KEM combiner step should not be performed if either of the component decapsulations returned an error condition indicating malformed inputs. RSA-based composites MUST ensure that the modulus size (i.e. the size of tradCT and tradPK) matches that specified for the given Composite ML-KEM algorithm in ; depending on the cryptographic library used, this check may be done by the library or may require an explicit check as part of the Composite-ML-KEM.Decap() routine. Implementers should keep in mind that some instances of tradCT and tradPK will be DER-encoded which could introduce minor length variations such as dropping leading zeroes; since the underlying KEMs are assumed to be IND-CCA secure, decapsulation against tampered ciphertexts or public keys is assumed to fail, these length differences are considered benign to the KEM combiner. Errors produced by the component Decaps() routines MUST be forwarded on to the calling application. Further discussion can be found below in .

KEM Combiner Function This specification provides a combiner construction with SHA3-256 for all combinations of algorithms. ss Explicit inputs: The list of input values to be combined. Output: ss The shared secret key, a 256-bit key suitable for use with symmetric cryptographic algorithms. Process: ss = SHA3-256(mlkemSS || tradSS || tradCT || tradPK || Label) return ss ]]>

Error Handling and Explicit Rejection ML-KEM, particularly its Decaps() defined in Algorithms 18 and 21 of , is designed to be implicitly rejecting, meaning that a failure within the underlying PKE scheme due to a mangled ciphertext will not cause ML-KEM.Decaps() to return an error, but instead any errors encountered during decapsulation are handled by producing a pseudo-random shared secret. ML-KEM.Decaps() can, however return errors for example if the provided ciphertext or decapsulation private key is the wrong size. In Composite ML-KEM, not all component algorithms will be implicitly rejecting, for example RSA-OAEP's Decrypt() can return an error if the padding is incorrect. In general, in the case that one of the component primitives generates an error during Composite ML-KEM KeyGen, Encaps, or Decaps, Composite ML-KEM MUST clear all buffers containing key material and forward the error to its caller; i.e. Composite ML-KEM MUST be explicitly rejecting whenever one of its components is. The same applies to Composite ML-KEM KeyGen() and Encaps(): Composite KEM MUST forward any errors produced by component algorithms.

Serialization This section presents routines for serializing and deserializing composite public keys, private keys, and ciphertext values to bytes. The functions defined in this section are considered internal implementation details and are referenced from within the public API definitions in . Deserialization is possible because ML-KEM has fixed-length public keys, private keys (seeds), and ciphertext values as shown in the following table, which is similar to Table 3 from , but with a different private key representation. ML-KEM Sizes in bytes

Algorithm	Public Key	Private Key	Ciphertext
ML-KEM-768	1184	64	1088
ML-KEM-1024	1568	64	1568

For all serialization routines below, when these values are required to be carried in an ASN.1 structure, they are wrapped as described in . While ML-KEM has a single fixed-size representation for each of public key, private key, and ciphertext, the traditional component might allow multiple valid encodings; for example an elliptic curve public key, and therefore also ciphertext, might be validly encoded as either compressed or uncompressed , or an RSA private key could be encoded in Chinese Remainder Theorem form . In order to obtain interoperability, composite algorithms MUST use the following encodings of the underlying components:

• ML-KEM: MUST be encoded as specified in sections 7.1 and 7.2 of , using a 64-byte seed (d || z) as the private key.
• RSA: the public key MUST be encoded as RSAPublicKey with the (n,e) public key representation as specified in A.1.1 of and the private key representation as RSAPrivateKey specified in A.1.2 of with version 0 and 'otherPrimeInfos' absent. An RSA-OAEP ciphertext MUST be encoded as specified in section 7.1.1 of
• ECDH: public key MUST be encoded as an uncompressed elliptic curve point as in section 2.2 of , including the leading byte 0x04 indicating uncompressed encoding and without the ASN.1 OCTET STRING wrapper. This is consistent with the encoding of EC public keys in X9.62 . The private key MUST be encoded as ECPrivateKey specified in with 'NamedCurve' parameter set to the OID of the curve, but without the 'publicKey' field. The ciphertext MUST be encoded in the same manner as the public key.
• X25519 and X448: the public key MUST be encoded as per section 5 of and the private key is a 32 or 56 byte raw value for X25519 and X448 respectively. The ciphertext MUST be encoded in the same manner as the public key.

All ASN.1 objects SHALL be encoded using DER on serialization. Even with fixed encodings for the traditional component, there may be slight differences in size of the encoded value due to, for example, encoding rules that drop leading zeroes. See for further discussion of encoded size of each composite algorithm. The deserialization routines described below do not check for well-formedness of the cryptographic material they are recovering. It is assumed that underlying cryptographic primitives will catch malformed values and raise an appropriate error.

SerializePublicKey and DeserializePublicKey The serialization routine for keys simply concatenates the public keys of the component algorithms, as defined below: bytes Explicit inputs: mlkemPK The ML-KEM public key, which is bytes. tradPK The traditional public key in the appropriate encoding for the underlying component algorithm. Implicit inputs: None Output: bytes The encoded composite public key. Serialization Process: 1. Combine and output the encoded public key output mlkemPK || tradPK ]]> Deserialization reverses this process. Each component key is deserialized according to their respective specification as shown in . The following describes how to instantiate a DeserializePublicKey(bytes) function for a given composite algorithm represented by <OID>. .DeserializePublicKey(bytes) ->(mlkemPK, tradPK) Explicit inputs: bytes An encoded composite public key. Implicit inputs mapped from : ML-KEM The underlying ML-KEM algorithm and parameter, for example, could be "ML-KEM-768". Output: mlkemPK The ML-KEM public key, which is bytes. tradPK The traditional public key in the appropriate encoding for the underlying component algorithm. Deserialization Process: 1. Parse each constituent encoded public key. The length of the mlkemPK is known based on the size of the ML-KEM component key length specified by the Object ID. switch ML-KEM do case ML-KEM-768: mlkemPK = bytes[:1184] tradPK = bytes[1184:] case ML-KEM-1024: mlkemPK = bytes[:1568] tradPK = bytes[1568:] Note that while ML-KEM has fixed-length keys, RSA may not, depending on encoding, so rigorous length-checking of the overall composite key is not always possible. 2. Output the component public keys output (mlkemPK, tradPK) ]]>

SerializePrivateKey and DeserializePrivateKey The serialization routine for keys simply concatenates the private keys of the component algorithms, as defined below: bytes Explicit inputs: mlkemSeed The ML-KEM private key, which consists of a 32 Byte seed value d concatenated with a 32 Byte seed value z. tradSK The traditional private key in the appropriate encoding for the underlying component algorithm. Implicit inputs: None Output: bytes The encoded composite private key. Serialization Process: 1. Combine and output the encoded private key. output mlkemSeed || tradSK ]]> Deserialization reverses this process. Each component key is deserialized according to their respective specification as shown in . The following describes how to instantiate a DeserializePrivateKey(bytes) function. Since ML-KEM private keys are 64 bytes for all parameter sets, this function does not need to be parametrized. (mlkemSeed, tradSK) Explicit inputs: bytes An encoded composite private key. Implicit inputs: That an ML-KEM private key is 64 bytes for all parameter sets. Output: mlkemSeed The ML-KEM private key, which consists of a 32 Byte seed value d concatenated with a 32 Byte seed value z. tradSK The traditional private key in the appropriate encoding for the underlying component algorithm. Deserialization Process: 1. Parse the ML-KEM seed, which is always a 64 byte seed for all parameter sets. mlkemSeed = bytes[:64] tradSK = bytes[64:] 2. Output the component private keys output (mlkemSeed,tradSK) ]]>

SerializeCiphertext and DeserializeCiphertext The serialization routine for the composite ciphertext value simply concatenates the fixed-length ML-KEM ciphertext with the ciphertext from the traditional algorithm, as defined below: bytes Explicit inputs: mlkemCT The ML-KEM ciphertext, which is bytes. tradCT The traditional ciphertext in the appropriate encoding for the underlying component algorithm. Implicit inputs: None Output: bytes The encoded composite ciphertext value. Serialization Process: 1. Combine and output the encoded composite ciphertext output mlkemCT || tradCT ]]> Deserialization reverses this process. Each component ciphertext is deserialized according to their respective specification as shown in . The following describes how to instantiate a DeserializeCiphertext(bytes) function for a given composite algorithm represented by <OID>. .DeserializeCiphertext(bytes) -> (mlkemCT, tradCT) Explicit inputs: bytes An encoded composite ciphertext value. Implicit inputs mapped from : ML-KEM The underlying ML-KEM algorithm and parameter, for example, could be "ML-KEM-768". Output: mlkemCT The ML-KEM ciphertext, which is bytes. tradCT The traditional ciphertext in the appropriate encoding for the underlying component algorithm. Deserialization Process: 1. Parse each constituent encoded ciphertext. The length of the mlkemCT is known based on the size of the ML-KEM component ciphertext length specified by the Object ID. switch ML-KEM do case ML-KEM-768: mlkemCT = bytes[:1088] tradCT = bytes[1088:] case ML-KEM-1024: mlkemCT= bytes[:1568] tradCT = bytes[1568:] 2. Output the component ciphertext values output (mlkemCT, tradCT) ]]>

Use within X.509 and PKIX The following sections provide processing logic and the necessary ASN.1 modules necessary to use composite ML-KEM within X.509 and PKIX protocols. Use within the Cryptographic Message Syntax (CMS) will be covered in a separate specification. While composite ML-KEM keys and ciphertext values MAY be used raw, the following sections provide conventions for using them within X.509 and other PKIX protocols such that Composite ML-KEM can be used as a drop-in replacement for KEM algorithms in PKCS#10 , CMP , X.509 , and related protocols.

Encoding to DER The serialization routines presented in produce raw binary values. When these values are required to be carried within a DER-encoded message format such as an X.509's subjectPublicKey or a OneAsymmetricKey.privateKey OCTET STRING , then the BIT STRING or OCTET STRING contains this raw byte string output of the appropriate serialization routine from without further encoding. When a Composite ML-KEM public key appears outside of a SubjectPublicKeyInfo type in an environment that uses ASN.1 encoding, it could be encoded as an OCTET STRING by using the Composite-ML-KEM-PublicKey type defined below. Size constraints MAY be enforced, as appropriate as per .

Key Usage Bits When any Composite ML-KEM Object Identifier appears within the SubjectPublicKeyInfo.AlgorithmIdentifier field of an X.509 certificate , the key usage certificate extension MUST only contain: Composite ML-KEM keys MUST NOT be used in a "dual usage" mode because even if the traditional component key supports both signing and encryption, the post-quantum algorithms do not and therefore the overall composite algorithm does not. Implementations MUST NOT use one component of the composite for the purposes of digital signature and the other component for the purposes of encryption or key establishment.

ASN.1 Definitions Composite ML-KEM uses a substantially non-ASN.1 based encoding, as specified in . However, as composite algorithms will be used within ASN.1-based X.509 and PKIX protocols, some conventions for ASN.1 wrapping are necessary. The following ASN.1 Information Object Classes are defined to allow for compact definitions of each composite algorithm, leading to a smaller overall ASN.1 module.

ASN.1 Object Information Classes for Composite ML-KEM

As an example, the public key and KEM algorithm types associated with id-MLKEM768-ECDH-P256-SHA3-256 are defined as: The full set of key types defined by this specification can be found in the ASN.1 Module in . Use cases that require an interoperable encoding for composite private keys will often need to place a composite private key inside a OneAsymmetricKey structure defined in , such as when private keys are carried in PKCS #12 , CMP or CRMF . The definition of OneAsymmetricKey is copied here for convenience:

OneAsymmetricKey as defined in [RFC5958]

When a composite private key is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) , the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to and its parameters field MUST be absent. The privateKey field SHALL contain the OCTET STRING representation of the serialized composite private key as per . The publicKey field remains OPTIONAL. If the publicKey field is present, it MUST be a composite public key as per . Some applications might need to reconstruct the SubjectPublicKeyInfo or OneAsymmetricKey objects corresponding to each component key individually, for example if this is required for invoking the underlying primitive. provides the necessary mapping between composite and their component algorithms for doing this reconstruction. Component keys of a composite private key MUST NOT be used in any other type of key or as a standalone key. For more details on the security considerations around key reuse, see .

Algorithm Identifiers and Parameters This section lists the algorithm identifiers and parameters for all Composite ML-KEM algorithms. Full specifications for the referenced algorithms can be found in . As the number of algorithms can be daunting to implementers, see for a discussion of choosing a subset to support. Each Composite ML-KEM algorithm has a unique Label which is used in constructing the KEM combiner in (). This helps protect against a different algorithm arriving at the same shared secret key even if all inputs are the same. Label values are provided in two forms: where the label value is alphanumeric ASCII, they are represented below as strings. For example, "MLKEM768-RSAOAEP2048" below is equivalent to the hexadecimal value 4D4C4B454D3736382D5253414F41455032303438. Some of the label values contain problematic characters, such as backslashes, that can cause issues displaying correctly in rendered documents or even in source code when the compiler interprets it as an escape character. Below, these are represented directly in hexadecimal. For example, the label for id-MLKEM768-X25519-SHA3-256 is "\.//^\", but to avoid transcription errors it is provided only in hexadecimal as 5c2e2f2f5e5c. Composite KEM algorithm list:

• id-MLKEM768-RSA2048-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.55
  • Label: "MLKEM768-RSAOAEP2048"
  • ML-KEM variant: ML-KEM-768
  • Traditional Algorithm: RSA
    • Traditional KEM Algorithm: id-RSAES-OAEP
    • RSA size: 2048
    • RSAES-OAEP parameters: See
• id-MLKEM768-RSA3072-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.56
  • Label: "MLKEM768-RSAOAEP3072"
  • ML-KEM variant: ML-KEM-768
  • Traditional Algorithm: RSA
    • Traditional KEM Algorithm: id-RSAES-OAEP
    • RSA size: 3072
    • RSAES-OAEP parameters: See
• id-MLKEM768-RSA4096-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.57
  • Label: "MLKEM768-RSAOAEP4096"
  • ML-KEM variant: ML-KEM-768
  • Traditional Algorithm: RSA
    • Traditional KEM Algorithm: id-RSAES-OAEP
    • RSA size: 4096
    • RSAES-OAEP parameters: See
• id-MLKEM768-X25519-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.58
  • Label: "5c2e2f2f5e5c" (hex)
  • ML-KEM variant: ML-KEM-768
  • Traditional Algorithm: X25519
    • Traditional KEM Algorithm: id-X25519
• id-MLKEM768-ECDH-P256-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.59
  • Label: "MLKEM768-P256"
  • ML-KEM variant: ML-KEM-768
  • Traditional Algorithm: ECDH
    • Traditional KEM Algorithm: id-ecDH
    • ECDH curve: secp256r1
• id-MLKEM768-ECDH-P384-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.60
  • Label: "MLKEM768-P384"
  • ML-KEM variant: ML-KEM-768
  • Traditional Algorithm: ECDH
    • Traditional KEM Algorithm: id-ecDH
    • ECDH curve: secp384r1
• id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.61
  • Label: "MLKEM768-BP256"
  • ML-KEM variant: ML-KEM-768
  • Traditional Algorithm: ECDH
    • Traditional KEM Algorithm: id-ecDH
    • ECDH curve: brainpoolP256r1
• id-MLKEM1024-RSA3072-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.62
  • Label: "MLKEM1024-RSAOAEP3072"
  • ML-KEM variant: ML-KEM-1024
  • Traditional Algorithm: RSA
    • Traditional KEM Algorithm: id-RSAES-OAEP
    • RSA size: 3072
    • RSAES-OAEP parameters: See
• id-MLKEM1024-ECDH-P384-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.63
  • Label: "MLKEM1024-P384"
  • ML-KEM variant: ML-KEM-1024
  • Traditional Algorithm: ECDH
    • Traditional KEM Algorithm: id-ecDH
    • ECDH curve: secp384r1
• id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.64
  • Label: "MLKEM1024-BP384"
  • ML-KEM variant: ML-KEM-1024
  • Traditional Algorithm: ECDH
    • Traditional KEM Algorithm: id-ecDH
    • ECDH curve: brainpoolP384r1
• id-MLKEM1024-X448-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.65
  • Label: "MLKEM1024-X448"
  • ML-KEM variant: ML-KEM-1024
  • Traditional Algorithm: X448
    • Traditional KEM Algorithm: id-X448
• id-MLKEM1024-ECDH-P521-SHA3-256
  • OID: 1.3.6.1.5.5.7.6.66
  • Label: "MLKEM1024-P521"
  • ML-KEM variant: ML-KEM-1024
  • Traditional Algorithm: ECDH
    • Traditional KEM Algorithm: id-ecDH
    • ECDH curve: secp521r1

In alignment with ML-KEM , Composite KEM algorithms output a 256-bit shared secret key at all security levels. For all RSA key types and sizes, the exponent is RECOMMENDED to be 65537. Implementations MAY support only 65537 and reject other exponent values. Legacy RSA implementations that use other values for the exponent MAY be used within a composite, but need to be careful when interoperating with other implementations. SHA3-256 is used as the KDF for all Composite ML-KEM algorithms.

RSA-OAEP Parameters Use of RSA-OAEP requires additional parameters to be specified. The RSA component keys MUST be generated at the specified 2048-bit, 3072-bit, 4096-bit key sizes respectively (up to small differences such as dropping leading zeros); intermediate sizes are not acceptable. As with the other Composite ML-KEM algorithms, AlgorithmIdentifier parameters MUST be absent. The RSA-OAEP primitive SHALL be instantiated with the following hard-coded parameters which are the same for the 2048, 3072 and 4096 bit key sizes since the objective is to carry and output a 256-bit shared secret key at all security levels. RSA-OAEP Parameters

RSAES-OAEP-params	Value
hashAlgorithm	id-sha256
MaskGenAlgorithm.algorithm	id-mgf1
maskGenAlgorithm.parameters	id-sha256
pSourceAlgorithm	pSpecifiedEmpty
ss_len	256 bits

Full specifications for the referenced algorithms can be found in . Note: The mask length, according to , is k - hLen - 1, where k is the size of the RSA modulus. Since the choice of hash function and the RSA key size is fixed for each composite algorithm, implementations could choose to pre-compute and hard-code the mask length.

Rationale for choices In generating the list of composite algorithms, the idea was to provide composite algorithms at various security levels with varying performance characteristics. The main design consideration in choosing pairings is to prioritize providing pairings of each ML-KEM security level with commonly-deployed traditional algorithms. This supports the design goal of using composites as a stepping stone to efficiently deploy post-quantum on top of existing hardened and certified traditional algorithm implementations. This was prioritized rather than attempting to exactly match the security level of the post-quantum and traditional components -- which in general is difficult to do since there is no academic consensus on how to compare the "bits of security" against classical attackers and "qubits of security" against quantum attackers. While it may seem odd to use 256-bit outputs at all security levels, this aligns with ML-KEM which produces a 256-bit shared secret key at all security levels. SHA3-256 has 256 bits of (2nd) pre-image resistance, which is the required property for a KDF to provide 128 bits of security, as allowed in Table 3 of .

ASN.1 Module 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(TBDMOD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS PUBLIC-KEY, AlgorithmIdentifier{}, 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) } KEM-ALGORITHM FROM KEMAlgorithmInformation-2023 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-kemAlgorithmInformation-2023(109) } ; -- -- Object Identifiers -- -- -- Information Object Classes -- pk-CompositeKEM {OBJECT IDENTIFIER:id} PUBLIC-KEY ::= { IDENTIFIER id -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE { keyEncipherment } -- PRIVATE-KEY no ASN.1 wrapping -- } kema-CompositeKEM { OBJECT IDENTIFIER:id, PUBLIC-KEY:publicKeyType } KEM-ALGORITHM ::= { IDENTIFIER id -- VALUE no ASN.1 wrapping -- PARAMS ARE absent PUBLIC-KEYS { publicKeyType } SMIME-CAPS { IDENTIFIED BY id } } -- -- Composite KEM Algorithms -- -- Composite ML-KEM id-MLKEM768-RSA2048-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 55 } pk-MLKEM768-RSA2048-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM768-RSA2048-SHA3-256 } kema-MLKEM768-RSA2048-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM768-RSA2048-SHA3-256, pk-MLKEM768-RSA2048-SHA3-256 } id-MLKEM768-RSA3072-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 56 } pk-MLKEM768-RSA3072-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM768-RSA3072-SHA3-256 } kema-MLKEM768-RSA3072-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM768-RSA3072-SHA3-256, pk-MLKEM768-RSA3072-SHA3-256 } id-MLKEM768-RSA4096-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 57 } pk-MLKEM768-RSA4096-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM768-RSA4096-SHA3-256 } kema-MLKEM768-RSA4096-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM768-RSA4096-SHA3-256, pk-MLKEM768-RSA4096-SHA3-256 } id-MLKEM768-X25519-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 58 } pk-MLKEM768-X25519-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM768-X25519-SHA3-256 } kema-MLKEM768-X25519-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM768-X25519-SHA3-256, pk-MLKEM768-X25519-SHA3-256 } id-MLKEM768-ECDH-P256-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 59 } pk-MLKEM768-ECDH-P256-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM768-ECDH-P256-SHA3-256 } kema-MLKEM768-ECDH-P256-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM768-ECDH-P256-SHA3-256, pk-MLKEM768-ECDH-P256-SHA3-256 } id-MLKEM768-ECDH-P384-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 60 } pk-MLKEM768-ECDH-P384-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM768-ECDH-P384-SHA3-256 } kema-MLKEM768-ECDH-P384-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM768-ECDH-P384-SHA3-256, pk-MLKEM768-ECDH-P384-SHA3-256 } id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 61 } pk-MLKEM768-ECDH-brainpoolP256r1-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256 } kema-MLKEM768-ECDH-brainpoolP256r1-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256, pk-MLKEM768-ECDH-brainpoolP256r1-SHA3-256 } id-MLKEM1024-RSA3072-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 62 } pk-MLKEM1024-RSA3072-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM1024-RSA3072-SHA3-256 } kema-MLKEM1024-RSA3072-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM1024-RSA3072-SHA3-256, pk-MLKEM1024-RSA3072-SHA3-256 } id-MLKEM1024-ECDH-P384-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 63 } pk-MLKEM1024-ECDH-P384-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM1024-ECDH-P384-SHA3-256 } kema-MLKEM1024-ECDH-P384-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM1024-ECDH-P384-SHA3-256, pk-MLKEM1024-ECDH-P384-SHA3-256 } id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 64 } pk-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM{ id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256 } kema-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256, pk-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256 } id-MLKEM1024-X448-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 65 } pk-MLKEM1024-X448-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM1024-X448-SHA3-256 } kema-MLKEM1024-X448 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM1024-X448-SHA3-256, pk-MLKEM1024-X448-SHA3-256 } id-MLKEM1024-ECDH-P521-SHA3-256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 66 } pk-MLKEM1024-ECDH-P521-SHA3-256 PUBLIC-KEY ::= pk-CompositeKEM { id-MLKEM1024-ECDH-P521-SHA3-256 } kema-MLKEM1024-ECDH-P521-SHA3-256 KEM-ALGORITHM ::= kema-CompositeKEM{ id-MLKEM1024-ECDH-P521-SHA3-256, pk-MLKEM1024-ECDH-P521-SHA3-256 } PublicKeys PUBLIC-KEY ::= { -- This expands PublicKeyAlgorithms from [RFC 5912] pk-MLKEM768-RSA2048-SHA3-256 | pk-MLKEM768-RSA3072-SHA3-256 | pk-MLKEM768-RSA4096-SHA3-256 | pk-MLKEM768-X25519-SHA3-256 | pk-MLKEM768-ECDH-P256-SHA3-256 | pk-MLKEM768-ECDH-P384-SHA3-256 | pk-MLKEM768-ECDH-brainpoolP256r1-SHA3-256 | pk-MLKEM1024-RSA3072-SHA3-256 | pk-MLKEM1024-ECDH-P384-SHA3-256 | pk-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256 | pk-MLKEM1024-X448-SHA3-256 | pk-MLKEM1024-ECDH-P521-SHA3-256, ... } END ]]>

IANA Considerations

Object Identifier Allocations IANA has registered the Object Identifiers in the "SMI Security for PKIX Algorithms" registry.

Module Registration The following is to be registered in "SMI Security for PKIX Module Identifier":

• Decimal: IANA Assigned - Replace TBDMOD
• Description: Composite-MLKEM-2025 - id-mod-composite-mlkem-2025
• References: This Document

Object Identifier Registrations The following are registered in the "SMI Security for PKIX Algorithms":

• id-MLKEM768-RSA2048-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.55
  • Description: id-MLKEM768-RSA2048-SHA3-256
  • References: This Document
• id-MLKEM768-RSA3072-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.56
  • Description: id-MLKEM768-RSA3072-SHA3-256
  • References: This Document
• id-MLKEM768-RSA4096-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.57
  • Description: id-MLKEM768-RSA4096-SHA3-256
  • References: This Document
• id-MLKEM768-X25519-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.58
  • Description: id-MLKEM768-X25519-SHA3-256
  • References: This Document
• id-MLKEM768-ECDH-P256-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.59
  • Description: id-MLKEM768-ECDH-P256-SHA3-256
  • References: This Document
• id-MLKEM768-ECDH-P384-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.60
  • Description: id-MLKEM768-ECDH-P384-SHA3-256
  • References: This Document
• id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.61
  • Description: id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256
  • References: This Document
• id-MLKEM1024-RSA3072-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.62
  • Description: id-MLKEM1024-RSA3072-SHA3-256
  • References: This Document
• id-MLKEM1024-ECDH-P384-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.63
  • Description: id-MLKEM1024-ECDH-P384-SHA3-256
  • References: This Document
• id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.64
  • Description: id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256
  • References: This Document
• id-MLKEM1024-X448-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.65
  • Description: id-MLKEM1024-X448-SHA3-256
  • References: This Document
• id-MLKEM1024-ECDH-P521-SHA3-256
  • Decimal: 1.3.6.1.5.5.7.6.66
  • Description: id-MLKEM1024-ECDH-P521-SHA3-256
  • References: This Document

Security Considerations As this specification uses ML-KEM as a component of all composite algorithms, all security considerations from and apply. Note in particular the "Encapsulation key check" in section 7.2 of and the "Decapsulation input check" in section 7.3 of which are required for correct and secure functioning of ML-KEM, but which are considered to be external to the Encaps() and Decaps() algorithms.

Why Hybrids? In broad terms, a PQ/T Hybrid can be used either to provide dual-algorithm security or to provide migration flexibility. Let's quickly explore both. Dual-algorithm security. The general idea is that the data is protected by two algorithms such that an attacker would need to break both in order to compromise the data. As with most of cryptography, this property is easy to state in general terms, but becomes more complicated when expressed in formalisms. The following sections go into more detail here. Migration flexibility. Some PQ/T hybrids exist to provide a sort of "OR" mode where the application can choose to use one algorithm or the other or both. The intention is that the PQ/T hybrid mechanism builds in application backwards compatibility to allow legacy and upgraded applications to co-exist and communicate. The composite algorithms presented in this specification do not provide this since they operate in a strict "AND" mode. They do, however, provide codebase migration flexibility. Consider that an organization has today a mature, validated, certified, hardened implementation of RSA or ECC; composites allow them to add an ML-KEM implementation which immediately starts providing benefits against harvest-now-decrypt-later attacks even if that ML-KEM implementation is still an experimental, non-validated, non-certified, non-hardened implementation. More details of obtaining FIPS certification of a composite algorithm can be found in .

KEM Combiner The KEM combiner from is reproduced here for reference.

KEM combiner construction

The primary security property of the KEM combiner is that it preserves indistinguishable (adaptive) chosen-ciphertext (IND-CCA2) security of the overall Composite ML-KEM so long as at least one component is IND-CCA2 . Additionally, we also need to consider the case where one of the component algorithms is completely broken; that the private key is known to an attacker. In this case, we rely on the construction of the KEM combiner to ensure that the value of the other shared secret key cannot be leaked or the combined shared secret key predicted via manipulation of the broken algorithm. Each registered Composite ML-KEM algorithm specifies a Label -- see . Given that each Composite ML-KEM algorithm fully specifies the component algorithms, including for example the size of the RSA modulus, all inputs to the KEM combiner are fixed-size and thus do not require length-prefixing.

• mlkemSS is always 32 bytes.
• tradSS in the case of DH this is derived by the decapsulator and therefore the length is not controlled by the attacker, however in the case of RSA-OAEP this value is directly chosen by the sender and both the length and content could be freely chosen by an attacker.
• tradCT is either an elliptic curve public key or an RSA-OAEP ciphertext which is required to have its length checked by step 1b of RSAES-OAEP-DECRYPT in .
• tradPK is the public key of the traditional component (elliptic curve or RSA) and therefore fixed-length.
• Label is a fixed value specified in this document.

IND-CCA2 Security of the hybrid scheme Informally, a Composite ML-KEM algorithm is secure if the combiner (SHA3) is secure, and either ML-KEM is secure or the traditional component (RSA-OAEP, ECDH, X25519 or X448) is secure. The security of ML-KEM and DH hybrids is covered in and requires that the first KEM component (ML-KEM in this construction) is IND-CCA2 and second ciphertext preimage resistant (C2PRI) and that the DH component is nominal group; i.e. a well-behaved elliptic curve DH group, but does not require the traditional component to be IND-CCA. This design choice improves performance by not including the large ML-KEM public key and ciphertext, but means that an implementation error in the ML-KEM component that affects the ciphertext check step of the FO transform could result in the overall composite no longer achieving IND-CCA2 security. This solution remains IND-CCA2 due to binding the tradPK and tradCT in the KEM combiner. The QSF framework presented in is extended to cover RSA-OAEP as the traditional algorithm in place of DH. Informally we note that that RSA-OAEP is IND-CCA2 secure but is not C2PRI(aka ciphertext binding) or public key binding since it is mathematically possibly to construct two RSA-OAEP ciphertexts that decapsulate to the same shared secret under the same public key or under different public keys. Binding the RSA-OAEP ciphertext and public key to the internal KDF restores these properties. Formally, ports the proof of to cover RSA-OAEP as the traditional compenent in a QSF construction. goes further, analyzing a range of different RSA-based KEMs, including the RSA-OAEP-KEM construction used in this specification, concluding that it achieves LEAK-BIND-K,PK-CT and C2PRI when the ciphertext is included in the post-processing KDF. The composite combiner cannot be assumed to be secure when used with different KEMs and a more cautious approach would bind the public key and ciphertext of the first KEM as well.

Second pre-image resistance of component KEMs The notion of a "ciphertext second pre-image resistant KEM" is defined in as being the property that it is computationally difficult to find two different ciphertexts c != c' that will decapsulate to the same shared secret key under the same public key. For the purposes of a hybrid KEM combiner, this property means that given two composite ciphertexts (c1, c2) and (c1', c2'), we must obtain a unique overall shared secret key so long as either c1 != c1' or c2 != c2' -- i.e. the overall Composite ML-KEM is ciphertext second pre-image resistant, and therefore secure so long as one of the component KEMs is secure. In it is proven that ML-KEM is a second pre-image resistant KEM and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and therefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the ML-KEM component and of the overall Composite ML-KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. However, since neither RSA-OAEP nor DH guarantee second pre-image resistance at all, even in a correct implementation, these ciphertexts are bound to the key derivation in order to guarantee that c != c' will yield a unique ciphertext, and thus restoring second pre-image resistance to the overall Composite ML-KEM.

Generifying this construction It should be clear that the security analysis of the presented KEM combiner construction relies heavily on the specific choices of component algorithms and combiner KDF, and this combiner construction SHOULD NOT by applied to any other combination of ciphers without performing the appropriate security analysis.

Key Reuse While conformance with this specification requires that both components of a composite key MUST be freshly generated, the designers are aware that some implementers may be forced to break this rule due to operational constraints. This section documents the implications of doing so. When using single-algorithm cryptography, the best practice is to always generate fresh keying material for each purpose, for example when renewing a certificate, or obtaining both a TLS and S/MIME certificate for the same device. However, in practice key reuse in such scenarios is not always catastrophic to security and therefore often tolerated. However this reasoning does not hold in the PQ/T hybrid setting. Within the broader context of PQ/T hybrids, we need to consider new attack surfaces that arise due to the hybrid constructions and did not exist in single-algorithm contexts. One of these is key reuse where the component keys within a hybrid are also used by themselves within a single-algorithm context. For example, it might be tempting for an operator to take already-deployed RSA keys and add an ML-KEM key to them to form a hybrid. Within a hybrid signature context this leads to a class of attacks referred to as "stripping attacks" where one component signature can be extracted and presented as a single-algorithm signature. Hybrid KEMs using a concatenation-style KEM combiner, as is done in this specification, do not have the analogous attack surface because even if an attacker is able to extract and decrypt one of the component ciphertexts, this will yield a different shared secret key than the overall shared secret key derived from the composite, so any subsequent symmetric cryptographic operations will fail. In addition, there is a further implication to key reuse regarding certificate revocation. Upon receiving a new certificate enrolment request, many certification authorities will check if the requested public key has been previously revoked due to key compromise. Often a CA will perform this check by using the public key hash. Therefore, if one, or even both, components of a composite have been previously revoked, the CA may only check the hash of the combined composite key and not find the revocations. Therefore, because the possibility of key reuse exists even though forbidden in this specification, CAs performing revocation checks on a composite key SHOULD also check both component keys independently to verify that the component keys have not been revoked.

Policy for Deprecated and Acceptable Algorithms Traditionally, a public key or certificate contains a single cryptographic algorithm. If and when an algorithm becomes deprecated (for example, RSA-512, or SHA1), the path to deprecating it through policy and removing it from operational environments is, at least is principle, straightforward. In the composite model this is less obvious since a PQ/T hybrid is expected to still be considered valid after the traditional component is deprecated for individual use. As such, a single composite public key or certificate may contain a mixture of deprecated and non-deprecated algorithms. In general this should be manageable through policy by removing OIDs for the standalone component algorithms while still allowing OIDs for composite algorithms. However, complications may arise when the composite implementation needs to invoke the cryptographic module for a deprecated component algorithm. In particular, this could lead to complex Cryptographic Bills of Materials that show implementations of deprecated algorithms still present and being used.

Operational Considerations

FIPS Certification The following sections give guidance to implementers wishing to FIPS-certify a composite implementation. This guidance is not authoritative and has not been endorsed by NIST. Implementers seeking FIPS certification of a composite KEM algorithm where only one of the component algorithms has been FIPS-validated or FIPS-approved should credit the FIPS-validated component algorithm with full security strength, the non-FIPS-validated component algorithm with zero security, and the overall composite should be considered at least as strong and thus FIPS-approved. The composite algorithm has been designed to treat the underlying primitives as "black-box implementations" and not impose any additional requirements on them that could require an existing implementation of an underlying primitive to run in a mode different from the one under which it was certified. For example, the KeyGen defined in invokes ML-KEM.KeyGen_internal(d, z) which might not be available in a cryptographic module running in FIPS-mode, but is only a suggested implementation and the composite KeyGen MAY be implemented using a different available interface for ML-KEM.KeyGen. The authors wish to note that composite algorithms provide a design pattern to provide utility in future situations that require care to remain FIPS-compliant, such as future cryptographic migrations as well as bridging across jurisdictions with non-intersecting cryptographic requirements. Successful FIPS certification will need to take into account the "Encapsulation key check" in section 7.2 of and the "Decapsulation input check" in section 7.3 of which are required for correct and secure functioning of ML-KEM, but which are considered to be external to the Encaps() and Decaps() algorithms. The following sections go into further detail on specific issues that relate to FIPS certification.

Combiner Function For reference, the KEM combiner used in Composite ML-KEM is: NIST SP 800-227 allows hybrid key combiners of the following form: Composite ML-KEM maps cleanly into this since it places the two shared secret keys mlkemSS || tradSS at the beginning of the KDF input such that all other inputs tradCT || tradPK || Label can be considered part of OtherInput for the purposes of FIPS certification. For the detailed steps of the Key Derivation Mechanism KDM, refers to . Compliance of the Composite ML-KEM variants is achieved in the following way: The Composite ML-KEM algorithms use SHA3, and so can be certified under One-Step Key Derivation Option 1: H(x) = hash(x). section 4 "One-Step Key Derivation" requires a counter which begins at the 4-byte value 0x00000001. However, the counter is allowed to be omitted when the hash function is executed only once, as specified on page 159 of the FIPS 140-3 Implementation Guidance .

Order of KDF inputs with Non-Approved Algorithms adds an important stipulation that was not present in earlier NIST specifications:

• This publication approves the use of the key combiner (14) for any t > 1, so long as at least one shared secret (i.e., S_j for some j) is a shared secret generated from the key- establishment methods of SP 800-56A or SP 800-56B, or an approved KEM.

This means that although Composite ML-KEM always places the shared secret key from ML-KEM in the first slot, a Composite ML-KEM can be FIPS certified so long as either component is FIPS certified. This is important for several reasons. First, in the early stages of PQC migration, composites allow for a non-FIPS certified ML-KEM implementation to be added to a module that already has a FIPS certified traditional component, and the resulting composite can be FIPS certified. Second, when eventually RSA and Elliptic Curve are no longer FIPS-allowed, the composite can retain its FIPS certified status on the strength of the ML-KEM component. Third, while this is outside the scope of this specification, the general composite construction could be used to create FIPS certified algorithms that contain a component algorithm from a different jurisdiction. Third, a composite where both components are FIPS-certified could allow an implementer to patch one component algorithm while awaiting re-certification while continuing to use the overall composite in FIPS mode. Note that before was in force, required the shared secret key from the certified algorithm to be in the first slot and therefore a Composite ML-KEM implementation using a FIPS-certified traditional component and a non-FIPS certified ML-KEM is not believed to be certifiable under alone, and requires the ammendments made by .

Backwards Compatibility The term "application backwards compatibility" is used here to mean that existing systems as they are deployed today can interoperate with the upgraded systems of the future. This draft explicitly does not provide application backwards compatibility, only upgraded systems will understand the OIDs defined in this specification. These migration and interoperability concerns need to be thought about in the context of various types of protocols that make use of X.509 and PKIX with relation to key establishment and content encryption, from online negotiated protocols such as TLS 1.3 and IKEv2 , to non-negotiated asynchronous protocols such as S/MIME signed email , as well as myriad other standardized and proprietary protocols and applications that leverage CMS encrypted structures.

Profiling down the number of options One daunting aspect of this specification is the number of composite algorithm combinations. Each option has been specified because there is a community that has a direct application for it; typically because the traditional component is already deployed in a change-managed environment, or because that specific traditional component is required for regulatory reasons. However, this large number of combinations leads either to fracturing of the ecosystem into non-interoperable sub-groups when different communities choose non-overlapping subsets to support, or on the other hand it leads to spreading development resources too thin when trying to support all options. This specification does not list any particular composite algorithm as mandatory-to-implement, however organizations that operate within specific application domains are encouraged to define profiles that select a small number of composites appropriate for that application domain. For applications that do not have any regulatory requirements or legacy implementations to consider, it is RECOMMENDED to focus implementation effort on: In applications that only allow NIST PQC Level 5, it is RECOMMENDED to focus implementation effort on:

Decapsulation Requires the Public Key ML-KEM always requires the public key in order to perform various steps of the Fujisaki-Okamoto decapsulation , and for this reason the private key encoding specified in FIPS 203 includes the public key. Moreover, the KEM combiner as specified in requires the public key of the traditional component in order to achieve the public-key binding property and ciphertext collision resistance as described in . Since tradPK is not carried in the composite private key encoding, the implementation is required to obtain it from some out-of-band mechanism. This section discusses several options, but is a non-normative, non-exhaustive list.

1. Derive or extract from private key. Many cryptographic modules expose functionality to obtain an RSA or EC public key from the corresponding private key. For applications where such functionality does not exist, and provide the suggested mechanisms for extracting the public keys from private keys for RSA and ECDH respectively. It is assumed that this is not required for X25519 or X448 since those private keys are seeds from which the public key can be obtained.
2. Fetch it from an external data source, for example from the public-key certificate corresponding to this private key.
3. If the composite KEM private key is being carried within a PKCS#8 OneAsymmetricKey object, place the full composite public key within the optional OneAsymmetricKey.publicKey field, which allows extracting the tradPK (and re-encode as necessary for correctly using it in the KEM Combiner).
4. Use an alternate private key encoding that explicitly carries the tradPK.

Extracting RSAPublicKey from RSAPrivateKey Assuming that the RSA component of the composite private key is encoded as an RSAPrivateKey, as required by this specification, then, quoting from you have: This can trivially be converted into an RSAPublicKey through simple DER decoding / re-encoding since both required values are already present.

Deriving the public ECPoint from ECPrivateKey Unlike RSA, the ECPrivateKey does not contain sufficient information to simply extract the public key. Note that in the interest of having a single unique encoding to foster interoperability, this specification forbids the optional publicKey field. That said, the EC public key can be derived from the private key in the following way: where a recommended implementation of ec_multiply_by_scalar() can be found in . Then encode pubKey as X9.62 uncompressed point.

Interoperability of legacy algorithms The legacy component algorithms, particularly RSA and ECDSA can themselves have interoperability issues which will propagate to become interoperability issues in the composite. For example, this specification RECOMMENDS an RSA expenent of 65537, but other values are possible. Similarly, due to the details of DER encoding, keys that happen to have leading zeros could appear to be smaller than the required key size even though they are actually acceptable. Implementations are encouraged to be lenient when parsing the key material of the legacy algorithm. In particilar, the recommendation is to use existing implementations of the legacy algorithms that already handle all the variation seen in the wild.

References Normative References This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652. ITU-T Certicom Research Certicom Research National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. [STANDARDS-TRACK] This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes. This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The RSA Key Encapsulation Mechanism (RSA-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 RSA public key. The RSA-KEM algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM algorithm as a standalone KEM algorithm and the conventions for using the RSA-KEM algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in RFC 9629. This document obsoletes RFC 5990. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912. The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism. This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. Cisco Systems National Institute of Standards and Technology Ericsson Quantinuum Arqit Quantum Inc NIST standardized ML-KEM as FIPS 203 in August 2024. This document discusses how to use ML-KEM and how to use it within protocols - that is, what problem it solves, and what you need to do to use it securely. n.d. Federal Office for Information Security (BSI) French Cybersecurity Agency (ANSSI) Federal Office for Information Security (BSI) Netherlands National Communications Security Agency (NLNCSA) Swedish National Communications Security Authority, Swedish Armed Forces n.d. National Institute of Standards and Technology (NIST) n.d. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) ETSI This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Maximum Key and Ciphertext Sizes The sizes listed below are maximum values: several factors could cause fluctuations in the size of the traditional component. For example, this could be due to:

• The RSA public key (n, e) allows e to vary in size between 3 and n - 1 . Note that the size table below assumes the recommended value of e = 65537, so for RSA combinations it is in fact not a true maximum.
• When the underlying RSA or EC value is itself DER-encoded, integer values could occasionally be shorter than expected due to leading zeros being dropped from the encoding.

By contrast, ML-KEM values are always fixed size, so composite values can always be correctly de-serialized based on the size of the ML-KEM component. Size values marked with an asterisk (*) in the table are not fixed but maximum possible values for the composite key or ciphertext. Implementations MUST NOT perform strict length checking based on such values. Non-hybrid ML-KEM is included for reference. Maximum size values of composite ML-KEM

Algorithm	Public key	Private key	Ciphertext	SS
id-alg-ml-kem-768	1184	64	1088	32
id-alg-ml-kem-1024	1568	64	1568	32
id-MLKEM768-RSA2048-SHA3-256	1454*	1258*	1344	32
id-MLKEM768-RSA3072-SHA3-256	1582*	1834*	1472	32
id-MLKEM768-RSA4096-SHA3-256	1710*	2415*	1600	32
id-MLKEM768-X25519-SHA3-256	1216	96	1120	32
id-MLKEM768-ECDH-P256-SHA3-256	1249	115	1153	32
id-MLKEM768-ECDH-P384-SHA3-256	1281	128	1185	32
id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256	1249	116	1153	32
id-MLKEM1024-RSA3072-SHA3-256	1966*	1834*	1952	32
id-MLKEM1024-ECDH-P384-SHA3-256	1665	128	1665	32
id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256	1665	132	1665	32
id-MLKEM1024-X448-SHA3-256	1624	120	1624	32
id-MLKEM1024-ECDH-P521-SHA3-256	1701	146	1701	32

Component Algorithm Reference This section provides references to the full specification of the algorithms used in the composite constructions. Component Encryption Algorithms used in Composite Constructions

Component KEM Algorithm ID	OID	Specification
id-ML-KEM-768	2.16.840.1.101.3.4.4.2
id-ML-KEM-1024	2.16.840.1.101.3.4.4.3
id-X25519	1.3.101.110	,
id-X448	1.3.101.111	,
id-ecDH	1.3.132.1.12	, ,
id-RSAES-OAEP	1.2.840.113549.1.1.7

Elliptic Curves used in Composite Constructions

Elliptic CurveID	OID	Specification
secp256r1	1.2.840.10045.3.1.7	,
secp384r1	1.3.132.0.34	,
secp521r1	1.3.132.0.35	,
brainpoolP256r1	1.3.36.3.3.2.8.1.1.7
brainpoolP384r1	1.3.36.3.3.2.8.1.1.11

Hash algorithms used in Composite Constructions

HashID	OID	Specification
id-sha3-256	2.16.840.1.101.3.4.2.8

Fixed Component Algorithm Identifiers Many cryptographic libraries are X.509-focused and do not expose interfaces to instantiate a public key from raw bytes, but only from a SubjectPublicKeyInfo structure as you would find in an X.509 certificate, therefore implementing Composite ML-KEM in those libraries requires reconstructing the SPKI for each component algorithm. In order to aid implementers and reduce interoperability issues, this section lists out the full public key for each component algorithm. ML-KEM-768 ML-KEM-1024 ASN.1: RSA-OAEP - all sizes ECDH NIST-P-256 ECDH NIST-P-384 ECDH NIST-P-521 ECDH Brainpool-256 ECDH Brainpool-384 X25519 X448

Comparison with other Hybrid KEMs

X-Wing This specification borrows extensively from the analysis and KEM combiner construction presented in . In particular, X-Wing and id-MLKEM768-X25519-SHA3-256 are largely interchangeable. The one difference is that X-Wing uses a combined KeyGen function to generate the two component private keys from the same seed, which gives some additional binding properties. In order to allow for re-use of existing hardeneded certified cryptographic modules (for example, getting the RSA component from an existing smartcard), this specification keeps the key generation for both components separate and only loosely-specified so that implementers are free to use an existing certified hardware or software module for one or both components.

ETSI CatKDF section 8.2.3 defines CatKDF as: The main difference between the Composite ML-KEM combiner and the ETSI CatKDF combiner is that CatKDF makes the more conservative choice to bind the public keys and ciphertexts of both components, while Composite ML-KEM follows the analysis presented in that while preserving the security properties of the traditional component requires binding the public key and ciphertext of the traditional component, it is not necessary to do so for ML-KEM thanks to the rejection sampling step of the Fujisaki-Okamoto transform. Additionally, ETSI CatKDF can be instantiated with either HMAC , KMAC or HKDF as KDF. Since this specification uses SHA3-256 as the KDF for all variants, there is no equivalent construction of CatKDF.

Examples of KEM Combiner Intermediate Values This section provides examples of constructing the input for the KEM Combiner, showing all intermediate values. This is intended to be useful for debugging purposes. See for additional information. Each input component is shown. Note that values are shown hex-encoded for display purposes only, they are actually raw binary values.

• mlkemSS is the shared secret produced by the ML-KEM encapsulate or decapsulate function which is always 32 bytes.
• tradSS is the shared secret produce by the traditional algorithm.
• tradCT is either an elliptic curve public key or an RSA-OAEP ciphertext depending on the algorithm chosen.
• tradPK is the public key of the traditional component (elliptic curve or RSA) and therefore fixed-length.
• Label is the specific KEM Combiner Label for this composite algorithm. See

Next, the Combined KDF Input is given, which is simply the concatenation of the above values. Finally, the KDF Function and the ss Output are shown as outputs. The ss is the Composite ML-KEM shared-secret generated by applying the KDF to the Combined KDF Input. Examples are given for each recommended Composite ML-KEM algorithm from . Example 1: Example 2: Example 3:

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 raw decapsulation private key.
• dk_pkcs8 the decapsulation private key in a PKCS#8 object.
• c the ciphertext.
• k the derived shared secret key.

Implementers should be able to perform the following tests using the test vectors below:

1. Load the public key ek or certificate x5c and perform an encapsulation for it (you should obtain valid ct and k values, but they will not match the ones in the test vector since Encap() is randomized.)
2. Load the decapsulation private key dk or dk_pkcs8 and the ciphertext c and perform a Decaps() operation to ensure that the same shared secret key k is derived.

Test vectors are provided for each underlying ML-KEM algorithm in isolation for the purposes of debugging. Due to the length of the test vectors, some readers will prefer to retrieve the non-word-wrapped copy from GitHub . The reference implementation written in python that generated them is also available.

Contributors and Acknowledgments This document represents the results of a many-year effort by the LAMPS working group. Over that time the following working group members provided valuable review and commentary on the document: Serge Mister (Entrust), Felipe Ventura (Entrust), Richard Kettlewell (Entrust), Ali Noman (Entrust), Peter C. (UK NCSC), Tim Hollebeek (Digicert), Sophie Schmieg (Google), Deirdre Connolly (SandboxAQ), Chris A. Wood (Apple), Bas Westerbaan (Cloudflare), Falko Strenzke (MTG AG), Piotr Popis (Enigma), Jean-Pierre Fiset (Crypto4A), Carl Wallace, Daniel Van Geest (CryptoNext Security), 陳志華 (Abel C. H. Chen, Chunghwa Telecom), 林邦曄 (Austin Lin, Chunghwa Telecom) and Douglas Stebila (University of Waterloo). We wish to acknowledge a few people who have made notable contributions to specific sections of this document. We wish to acknowledge particular effort from Carl Wallace and Daniel Van Geest (CryptoNext Security), who have implemented each successive version of the draft over multiple years to provide valuable implementation experience and hackathon testing. Thanks to Stepan Yakimovich for contributing to the reference implementation to be able to provide and verify hackathon artifacts. Thanks to Giacomo Pope (github.com/GiacomoPope) whose ML-DSA and ML-KEM implementations were used to generate the test vectors. We are grateful to all who have given feedback over the years, formally or informally, on mailing lists or in person, including any contributors who may have been inadvertently omitted from this list. Finally, we wish to thank the authors of all the referenced documents upon which this specification was built. "Copying always makes things easier and less error prone" - .