]> 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 Internet-Draft This document defines combinations of ML-DSA in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-DSA is applicable in any application that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. 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 .

Changes since -07 (WGLC) Interop-affecting changes:

• Removed the randomizer, reverting the signature combiner construction to be similar to the HashComposite construction from -05.
• Fixed the ASN.1 module for the pk-CompositeSignature and sa-CompositeSignature to indicate no ASN.1 wrapping is used. This simply clarifies the intended encoding but could be an interop-affecting change for implementations that built encoders / decoders from the ASN.1 and ended up with a non-intended encoding.
• Aligned the hash function used for the RSA component to the RSA key size (Thanks Dan!).
• Changed the OID-based Domain Separators into HPKE-style signature label strings to match draft-irtf-cfrg-concrete-hybrid-kems-00.
• Updated to new prototype OIDs since it is not binary compatible with the previous release.

Editorial changes:

• Incorporated the feedback from IETF 123, clarifying the pubic, private key and signature encodings.
• Many minor editorial fixes based on comments from the working group.
• Adjusted the Security Considerations about EUF-CMA and Non-Separability to match the removal of the randomizer.

Introduction The advent of quantum computing poses a significant threat to current cryptographic systems. Traditional cryptographic signature algorithms such as RSA, DSA and its elliptic curve variants are vulnerable to quantum attacks. During the transition to post-quantum cryptography (PQC), there is considerable uncertainty regarding the robustness of both existing and new cryptographic algorithms. While we can no longer fully trust traditional cryptography, we also cannot immediately place complete trust in post-quantum replacements until they have undergone extensive scrutiny and real-world testing to uncover and rectify both algorithmic weaknesses as well as implementation flaws across all the new implementations. Unlike previous migrations between cryptographic algorithms, this migration gives us the foresight that Traditional cryptographic algorithms will be broken in the future, with the Traditional algorithms remaining 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 CVEs and other implementation flaws in the new implementations. Cautious implementers may opt to combine cryptographic algorithms in such a way that an adversary 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 . Certain jurisdictions are already recommending or mandating that PQC lattice schemes 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 , . Another motivation for using PQ/T Hybrids is regulatory compliance; for example, 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 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 off of which ever cryptographic algorithm(s) an organization might have deployed today. This specification defines a specific instantiation of the PQ/T Hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single signature algorithm presenting a single public key and signature value such that it can be treated as a single atomic algorithm at the protocol level; a property referred to as "protocol backwards compatibility" since it can be applied to protocols that are not explicitly hybrid-aware. Composite algorithms address algorithm strength uncertainty because the composite algorithm remains strong so long as one of its components remains strong. Concrete instantiations of composite ML-DSA algorithms are provided based on ML-DSA, RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. Backwards compatibility in the sense of upgraded systems continuing to inter-operate with legacy systems is not directly covered in this specification, but is the subject of . The idea of a composite was first presented in . Composite ML-DSA is applicable in any PKIX-related application that would otherwise use ML-DSA.

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 the terminology defined in . In addition, the following terminology is used throughout 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. This loosely, but not precisely, aligns with the definitions of "cryptographic algorithm" and "cryptographic scheme" given in . COMPONENT / PRIMITIVE: The words "component" or "primitive" are used interchangeably to refer to an asymmetric cryptographic algorithm that is used internally within a composite algorithm. For example this could be an asymmetric algorithm such as "ML-DSA-65" or "RSASSA-PSS". DER: Distinguished Encoding Rules as defined in . PKI: Public Key Infrastructure, as defined in . SIGNATURE: A digital cryptographic signature, making no assumptions about which algorithm. 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<TYPE>(): represents a function that is parameterized 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 defines composites as:

• Composite Cryptographic Element: A cryptographic element that incorporates multiple component cryptographic elements of the same type in a multi-algorithm scheme.

Composite algorithms, as defined in this specification, follow this definition and should be regarded as a single key that performs a single cryptographic operation typical of a digital signature algorithm, such as key generation, signing, or verifying -- using its internal sequence of component keys as if they form a single key. This generally means that the complexity of combining algorithms can and should be handled by the cryptographic library or cryptographic module, and the single composite public key, private key, and signature value can be carried in existing fields in protocols such as PKCS#10 , CMP , X.509 , the CMS , and the Trust Anchor Format . In this way, composites achieve "protocol backwards-compatibility" in that they will drop cleanly into any protocol that accepts an analogous single-algorithm cryptographic scheme without requiring any modification of the protocol to handle multiple algorithms. Discussion of the specific choices of algorithm pairings can be found in . In terms of security properties, Composite ML-DSA is SUF-CMA secure only if both components are SUF-CMA secure. Specifically, that means the ML-DSA and EdDSA combinations are SUF-CMA, but the ML-DSA and RSA or ECDSA combinations are only EUF-CMA. This means that replacing an ML-DSA signature with a Composite ML-DSA signature with RSA or ECDSA could be considered a reduction in security if your application is sensitive to the difference between SUF and EUF security. Applications requiring SUF-CMA security are RECOMMENDED to use the ML-DSA + EdDSA combinations. Further discussion can be found in .

Overview of the Composite ML-DSA Signature Scheme Composite ML-DSA is a Post-Quantum / Traditional hybrid signature scheme which combines ML-DSA as specified in and with one of RSASSA-PKCS1-v1_5 or RSASSA-PSS algorithms defined in , the Elliptic Curve Digital Signature Algorithm ECDSA scheme defined in section 6 of , or Ed25519 / Ed448 defined in . The two component signatures are combined into a composite algorithm via a "signature combiner" function which performs pre-hashing and prepends several signature label values to the message prior to passing it to the component algorithms. Composite ML-DSA achieves weak non-separability as well as several other security properties which are described in the Security Considerations in . Composite signature schemes are defined as cryptographic primitives that match the API of a generic signature scheme, which consists of three algorithms:

• 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-DSA.
• Sign(sk, M) -> s: A signing algorithm which takes as input a secret key sk and a message M, and outputs a signature s. Signing routines may take additional parameters such as a context string or a hash function to use for pre-hashing the message.
• Verify(pk, M, s) -> true or false: A verification algorithm which takes as input a public key pk, a message M and a signature s, and outputs true if the signature verifies correctly and false or an error otherwise. Verification routines may take additional parameters such as a context string or a hash function to use for pre-hashing the message.

The following algorithms are defined for serializing and deserializing component values and are provided as internal functions for use by the public functions KeyGen(), Sign(), and Verify(). These algorithms are inspired by similar algorithms in .

• SerializePublicKey(mlkdsaPK, tradPK) -> bytes: Produce a byte string encoding of the component public keys.
• DeserializePublicKey(bytes) -> (mldsaPK, tradPK): Parse a byte string to recover the component public keys.
• SerializePrivateKey(mldsaSeed, tradSK) -> bytes: Produce a byte string encoding of the component private keys. Note that the keygen seed is used as the interoperable private key format for ML-DSA.
• DeserializePrivateKey(bytes) -> (mldsaSeed, tradSK): Parse a byte string to recover the component private keys.
• SerializeSignatureValue(mldsaSig, tradSig) -> bytes: Produce a byte string encoding of the component signature values.
• DeserializeSignatureValue(bytes) -> (mldsaSig, tradSig): Parse a byte string to recover the component signature values.

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

Pre-hashing In NIST defines separate algorithms for pure and pre-hashed modes of ML-DSA, referred to as "ML-DSA" and "HashML-DSA" respectively. This specification defines a single mode which is similar in construction to HashML-DSA. This design provides a compromised balance between performance and security. Since pre-hashing is done at the composite level, "pure" ML-DSA is used as the underlying ML-DSA primitive. The primary design motivation behind pre-hashing is to perform only a single pass over the potentially large input message M, compared to passing the full message to both component primitives, and to allow for optimizations in cases such as signing the same message digest with multiple keys. The actual length of the to-be-signed message M' depends on the application context ctx provided at runtime but since ctx has a maximum length of 255 bytes, M' has a fixed maximum length which depends on the output size of the hash function chosen as PH, but can be computed per composite algorithm. This simplification into a single strongly-pre-hashed algorithm avoids the need for duplicate sets of "Composite-ML-DSA" and "Hash-Composite-ML-DSA" algorithms. See for a discussion of externalizing the pre-hashing step.

Prefix, Label and CTX The to-be-signed message representative M' is created by concatenating several values, including the pre-hashed message.

Prefix:

A fixed octet string which is the byte encoding of the ASCII string "CompositeAlgorithmSignatures2025" which in hex is: 436F6D706F73697465416C676F726974686D5369676E61747572657332303235 See for more information on the prefix.

Label:

A signature label which is specific to each composite algorithm. The signature label binds the signature to the specific composite algorithm. Signature label values for each algorithm are listed in .

len(ctx):

A single unsigned byte encoding the length of the context.

ctx:

The context bytes, which allows for applications to bind the signature to an application context.

PH( M ):

The hash of the message to be signed.

Each Composite ML-DSA algorithm has a unique signature label value which is used in constructing the message representative M' in the Composite-ML-DSA.Sign() () and Composite-ML-DSA.Verify() (). This helps protect against component signature values being removed from the composite and used out of context of X.509, or if the prohibition on reusing key material between a composite and a non-composite, or between two composites is not adhered to. Note that there are two different context strings ctx at play: the first is the application context that is passed in to Composite-ML-DSA.Sign and bound to the to-be-signed message M'. The second is the ctx that is passed down into the underlying ML-DSA.Sign and here Composite ML-DSA itself is the application that we wish to bind and so per-algorithm Label is used as the ctx for the underlying ML-DSA primitive. The EdDSA component primitive can also expose a ctx parameter, but this is not used by Composite ML-DSA. Within Composite ML-DSA, values of Label are fully specified, and runtime-variable Label values are not allowed. For authors of follow-on specifications that allow Label to be runtime-variable, it should be pre-fixed with the length, len(Label) || Label to prevent using this as an injection site that could enable various cryptographic attacks.

Composite ML-DSA Functions This section describes the composite ML-DSA functions needed to instantiate the public API of a digital signature scheme as defined in .

Key Generation In order to maintain security properties of the composite, applications that use composite keys MUST always perform fresh key generations of both component keys and MUST NOT reuse existing key material. See for a discussion. To generate a new key pair 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. 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-DSA The underlying ML-DSA algorithm and parameter set, for example "ML-DSA-65". Trad The underlying traditional algorithm and parameter set, for example "RSASSA-PSS" or "Ed25519". Output: (pk, sk) The composite key pair. Key Generation Process: 1. Generate component keys mldsaSeed = Random(32) (mldsaPK, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed) (tradPK, tradSK) = Trad.KeyGen() 2. Check for component key gen failure if NOT (mldsaPK, mldsaSK) or NOT (tradPK, tradSK): output "Key generation error" 3. Output the composite public and private keys pk = SerializePublicKey(mldsaPK, tradPK) sk = SerializePrivateKey(mldsaSeed, tradSK) return (pk, sk) ]]> This keygen routine make use of the seed-based ML-DSA.KeyGen_internal(𝜉), which is defined in Algorithm 6 of . For FIPS-certification implications, see . 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 . Note that this keygen routine outputs a serialized composite key, which contains only the ML-DSA seed. Implementations should feel free to modify this routine to additionally output the expanded mldsaSK or to make free use of ML-DSA.KeyGen_internal(mldsaSeed) as needed to expand the ML-DSA seed into an expanded key prior to performing a signing operation. The above algorithm MAY be modified to expose an interface of Composite-ML-DSA<OID>.KeyGen(seed) if it is desirable to have a deterministic KeyGen that derives both component keys from a shared seed. Details of implementing this variation are not included in this document. Variations in the keygen process above and signature processes below to accommodate particular private key storage mechanisms or alternate interfaces to the underlying cryptographic modules are considered to be conformant to this specification so long as they produce the same output and error handling. For example, component private keys stored in separate software or hardware modules where it is not possible to do a joint simultaneous keygen would be considered compliant so long as both keys are freshly generated. It is also possible that the underlying cryptographic module does not expose a ML-DSA.KeyGen_internal(seed) that accepts an externally-generated seed, and instead an alternate keygen interface must be used. Note however that cryptographic modules that do not support seed-based ML-DSA key generation will be incapable of importing or exporting composite keys in the standard format since the private key serialization routines defined in only support ML-DSA keys as seeds.

Sign The Sign() algorithm of Composite ML-DSA mirrors the construction of ML-DSA.Sign(sk, M, ctx) defined in Algorithm 3 of Section 5.2 of . Composite ML-DSA exposes an API similar to that of ML-DSA, despite the fact that it includes pre-hashing in a similar way to HashML-DSA. Internally it uses pure ML-DSA as the component algorithm since there is no advantage to pre-hashing twice. The following describes how to instantiate a Sign() function for a given Composite ML-DSA algorithm represented by <OID>. See for a discussion of the pre-hash function PH. See for a discussion on the signature label Label and application context ctx. See for a discussion of externalizing the pre-hashing step. .Sign(sk, M, ctx) -> s Explicit inputs: sk Composite private key consisting of signing private keys for each component. M The message to be signed, an octet string. ctx The application context string used in the composite signature combiner, which defaults to the empty string. Implicit inputs mapped from : ML-DSA The underlying ML-DSA algorithm and parameter set, for example "ML-DSA-65". Trad The underlying traditional algorithm and parameter set, for example "sha256WithRSAEncryption" or "Ed25519". Prefix The prefix octet string. Label A signature label which is specific to each composite algorithm. Additionally, the composite label is passed into the underlying ML-DSA primitive as the ctx. Signature Label values are defined in the "Signature Label Values" section below. PH The function used to pre-hash M. Output: s The composite signature value. Signature Generation Process: 1. If len(ctx) > 255: return error 2. Compute the Message representative M'. As in FIPS 204, len(ctx) is encoded as a single unsigned byte. M' := Prefix || Label || len(ctx) || ctx || PH( M ) 3. Separate the private key into component keys and re-generate the ML-DSA key from seed. (mldsaSeed, tradSK) = DeserializePrivateKey(sk) (_, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed) 4. Generate the two component signatures independently by calculating the signature over M' according to their algorithm specifications. mldsaSig = ML-DSA.Sign( mldsaSK, M', ctx=Label ) tradSig = Trad.Sign( tradSK, M' ) 5. If either ML-DSA.Sign() or Trad.Sign() return an error, then this process MUST return an error. if NOT mldsaSig or NOT tradSig: output "Signature generation error" 6. Output the encoded composite signature value. s = SerializeSignatureValue(mldsaSig, tradSig) return s ]]> Note that in step 4 above, both component signature processes are invoked, and no indication is given about which one failed. This SHOULD be done in a timing-invariant way to prevent side-channel attackers from learning which component algorithm failed. 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.

Verify The Verify() algorithm of Composite ML-DSA mirrors the construction of ML-DSA.Verify(pk, M, s, ctx) defined in Algorithm 3 Section 5.3 of . Composite ML-DSA exposes an API similar to that of ML-DSA, despite the fact that it includes pre-hashing in a similar way to HashML-DSA. Internally it uses pure ML-DSA as the component algorithm since there is no advantage to pre-hashing twice. Compliant applications MUST output "Valid signature" (true) if and only if all component signatures were successfully validated, and "Invalid signature" (false) otherwise. The following describes how to instantiate a Verify() function for a given composite algorithm represented by <OID>. See for a discussion of the pre-hash function PH. See for a discussion on the signature label Label and application context ctx. See for a discussion of externalizing the pre-hashing step. .Verify(pk, M, s, ctx) -> true or false Explicit inputs: pk Composite public key consisting of verification public keys for each component. M Message whose signature is to be verified, an octet string. s A composite signature value to be verified. ctx The application context string used in the composite signature combiner, which defaults to the empty string. Implicit inputs mapped from : ML-DSA The underlying ML-DSA algorithm and parameter set, for example "ML-DSA-65". Trad The underlying traditional algorithm and parameter set, for example "sha256WithRSAEncryption" or "Ed25519". Prefix The prefix octet string. Label A signature label which is specific to each composite algorithm. Additionally, the composite label is passed into the underlying ML-DSA primitive as the ctx. Signature Label values are defined in the "Signature Label Values" section below. PH The function used to pre-hash M. Output: Validity (bool) "Valid signature" (true) if the composite signature is valid, "Invalid signature" (false) otherwise. Signature Verification Process: 1. If len(ctx) > 255 return error 2. Separate the keys and signatures (mldsaPK, tradPK) = DeserializePublicKey(pk) (mldsaSig, tradSig) = DeserializeSignatureValue(s) If Error during deserialization, or if any of the component keys or signature values are not of the correct type or length for the given component algorithm then output "Invalid signature" and stop. 3. Compute a Hash of the Message. As in FIPS 204, len(ctx) is encoded as a single unsigned byte. M' = Prefix || Label || len(ctx) || ctx || PH( M ) 4. Check each component signature individually, according to its algorithm specification. If any fail, then the entire signature validation fails. if not ML-DSA.Verify( mldsaPK, M', mldsaSig, ctx=Label ) then output "Invalid signature" if not Trad.Verify( tradPK, M', tradSig ) then output "Invalid signature" if all succeeded, then output "Valid signature" ]]> Note that in step 4 above, the function fails early if the first component fails to verify. Since no private keys are involved in a signature verification, there are no timing attacks to consider, so this is ok.

Serialization This section presents routines for serializing and deserializing composite public keys, private keys, and signature values to bytes via simple concatenation of the underlying encodings of the component algorithms. 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-DSA has fixed-length public keys, private keys (seeds), and signature values as shown in the following table. ML-DSA Sizes

Algorithm	Public key	Private key	Signature
ML-DSA-44	1312	32	2420
ML-DSA-65	1952	32	3309
ML-DSA-87	2592	32	4627

While ML-DSA has a single fixed-size representation for each of public key, private key (seed), and signature, a traditional component algorithm might allow multiple valid encodings. For example, a stand-alone RSA private key can be encoded in Chinese Remainder Theorem form. In order to obtain interoperability, composite algorithms MUST use the following encodings of the underlying components:

• ML-DSA: MUST be encoded as specified in section 7.2 of , using a 32-byte seed as the private key. The signature and public key format are encoded as specified in section 7.2 of .
• 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 signature MUST be encoded as specified in section 8.1.1 (for RSASSA-PSS-SIGN) or 8.2.1 (for RSASSA-PCKS1-V1_5-SIGN) of .
• ECDSA: public key MUST be encoded as an uncompressed ECPoint as specified in section 2.2 of , including the leading 0x04 byte to indicate that it is uncompressed. A signature MUST be encoded as an Ecdsa-Sig-Value as specified in section 2.2.3 of . The private key MUST be encoded as ECPrivateKey specified in without 'NamedCurve' parameter and without 'publicKey' field.
• EdDSA: public key and signature MUST be encoded as per section 3 of and the private key as CurvePrivateKey specified in .

All ASN.1 objects SHALL be encoded using DER on serialization. For all serialization routines below, when their output values are required to be carried in an ASN.1 structure, they are wrapped as described in . Even with fixed encodings for the traditional component, there might be slight differences in size of the encoded value due to, for example, encoding rules that drop leading zeroes. See for a table of maximum sizes for each composite algorithm and further discussion of the reason for variations in these sizes. 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 signature algorithms, as defined below: bytes Explicit inputs: mldsaPK The ML-DSA 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 mldsaPK || 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) -> (mldsaPK, tradPK) Explicit inputs: bytes An encoded composite public key. Implicit inputs mapped from : ML-DSA The underlying ML-DSA algorithm and parameter set to use, for example "ML-DSA-65". Output: mldsaPK The ML-DSA 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 mldsaKey is known based on the size of the ML-DSA component key length specified by the Object ID. switch ML-DSA do case ML-DSA-44: mldsaPK = bytes[:1312] tradPK = bytes[1312:] case ML-DSA-65: mldsaPK = bytes[:1952] tradPK = bytes[1952:] case ML-DSA-87: mldsaPK = bytes[:2592] tradPK = bytes[2592:] Note that while ML-DSA has fixed-length keys, RSA and ECDSA 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 (mldsaPK, tradPK) ]]>

SerializePrivateKey and DeserializePrivateKey The serialization routine for keys simply concatenates the private keys of the component signature algorithms, as defined below: bytes Explicit inputs: mldsaSeed The ML-DSA private key, which is the bytes of the seed. 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 mldsaSeed || 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-DSA private keys are 32 bytes for all parameter sets, this function does not need to be parameterized. (mldsaSeed, tradSK) Explicit inputs: bytes An encoded composite private key. Implicit inputs: None Output: mldsaSeed The ML-DSA private key, which is the bytes of the seed. tradSK The traditional private key in the appropriate encoding for the underlying component algorithm. Deserialization Process: 1. Parse each constituent encoded key. mldsaSeed = bytes[:32] tradSK = bytes[32:] Note that while ML-DSA has fixed-length keys, RSA and ECDSA may not, depending on encoding, so rigorous length-checking of the overall composite key is not always possible. 2. Output the component private keys output (mldsaSeed, tradSK) ]]>

SerializeSignatureValue and DeserializeSignatureValue The serialization routine for the composite signature value simply concatenates the fixed-length ML-DSA signature value with the signature value from the traditional algorithm, as defined below: bytes Explicit inputs: mldsaSig The ML-DSA signature value, which is bytes. tradSig The traditional signature value in the appropriate encoding for the underlying component algorithm. Implicit inputs: None Output: bytes The encoded composite signature value. Serialization Process: 1. Combine and output the encoded composite signature output mldsaSig || tradSig ]]> Deserialization reverses this process, raising an error in the event that the input is malformed. Each component signature is deserialized according to their respective specification as shown in . The following describes how to instantiate a DeserializeSignatureValue(bytes) function for a given composite algorithm represented by <OID>. .DeserializeSignatureValue(bytes) -> (mldsaSig, tradSig) Explicit inputs: bytes An encoded composite signature value. Implicit inputs mapped from : ML-DSA The underlying ML-DSA algorithm and parameter set, for example "ML-DSA-65". Output: mldsaSig The ML-DSA signature value, which is bytes. tradSig The traditional signature value in the appropriate encoding for the underlying component algorithm. Deserialization Process: 1. Parse each constituent encoded signature. The length of the mldsaSig is known based on the size of the ML-DSA component signature length specified by the Object ID. switch ML-DSA do case ML-DSA-44: mldsaSig = bytes[:2420] tradSig = bytes[2420:] case ML-DSA-65: mldsaSig = bytes[:3309] tradSig = bytes[3309:] case ML-DSA-87: mldsaSig = bytes[:4627] tradSig = bytes[4627:] Note that while ML-DSA has fixed-length signatures, RSA and ECDSA may not, depending on encoding, so rigorous length-checking is not always possible here. 3. Output the component signature values output (mldsaSig, tradSig) ]]>

Use within X.509 and PKIX The following sections provide processing logic and the ASN.1 modules necessary to use composite ML-DSA within X.509 and PKIX protocols. Use within the Cryptographic Message Syntax (CMS) will be covered in a separate specification. While composite ML-DSA keys and signature values MAY be used raw, the following sections provide conventions for using them within X.509 and other PKIX protocols such that Composite ML-DSA can be used as a drop-in replacement for existing digital signature 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 and signatureValue BIT STRING or a OneAsymmetricKey.privateKey OCTET STRING , then the BIT STRING or OCTET STRING contains this raw byte string encoding of the public key. When a Composite ML-DSA 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-DSA-PublicKey type defined below. Size constraints MAY be enforced, as appropriate as per .

Key Usage Bits When any Composite ML-DSA Object Identifier appears within the SubjectPublicKeyInfo.AlgorithmIdentifier field of an X.509 certificate , the key usage certificate extension MUST only contain signing-type key usages. The normal keyUsage rules for signing-type keys from apply, and are reproduced here for completeness. For Certification Authority (CA) certificates that carry a Composite ML-DSA public key, any combination of the following values MAY be present and any other values MUST NOT be present: For End Entity certificates, any combination of the following values MAY be present and any other values MUST NOT be present: Composite ML-DSA 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-DSA 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-DSA

As an example, the public key and signature algorithm types associated with id-MLDSA44-ECDSA-P256-SHA256 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 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-DSA algorithms. Full specifications for the referenced algorithms can be found in . As the number of algorithms can be daunting, implementers who wish to implement only a single composite algorithm should see for a discussion of the best algorithm for the most common use cases. Labels are represented here as ASCII strings, but implementers MUST convert them to byte strings using the obvious ASCII conversions prior to concatenating them with other byte values as described in . EDNOTE: the OIDs listed below are prototyping OIDs defined in Entrust's 2.16.840.1.114027.80.9.1 arc but will be replaced by IANA.

• id-MLDSA44-RSA2048-PSS-SHA256
  • OID: 2.16.840.1.114027.80.9.1.20
  • Label: COMPSIG-MLDSA44-RSA2048-PSS-SHA256
  • Pre-Hash function (PH): SHA256
  • ML-DSA variant: ML-DSA-44
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: id-RSASSA-PSS
    • RSA size: 2048
    • RSASSA-PSS parameters: See
• id-MLDSA44-RSA2048-PKCS15-SHA256
  • OID: 2.16.840.1.114027.80.9.1.21
  • Label: COMPSIG-MLDSA44-RSA2048-PKCS15-SHA256
  • Pre-Hash function (PH): SHA256
  • ML-DSA variant: ML-DSA-44
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: sha256WithRSAEncryption
    • RSA size: 2048
• id-MLDSA44-Ed25519-SHA512
  • OID: 2.16.840.1.114027.80.9.1.22
  • Label: COMPSIG-MLDSA44-Ed25519-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-44
  • Traditional Algorithm: Ed25519
    • Traditional Signature Algorithm: id-Ed25519
• id-MLDSA44-ECDSA-P256-SHA256
  • OID: 2.16.840.1.114027.80.9.1.23
  • Label: COMPSIG-MLDSA44-ECDSA-P256-SHA256
  • Pre-Hash function (PH): SHA256
  • ML-DSA variant: ML-DSA-44
  • Traditional Algorithm: ECDSA
    • Traditional Signature Algorithm: ecdsa-with-SHA256
    • ECDSA curve: secp256r1
• id-MLDSA65-RSA3072-PSS-SHA512
  • OID: 2.16.840.1.114027.80.9.1.24
  • Label: COMPSIG-MLDSA65-RSA3072-PSS-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: id-RSASSA-PSS
    • RSA size: 3072
    • RSASSA-PSS parameters: See
• id-MLDSA65-RSA3072-PKCS15-SHA512
  • OID: 2.16.840.1.114027.80.9.1.25
  • Label: COMPSIG-MLDSA65-RSA3072-PKCS15-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: sha256WithRSAEncryption
    • RSA size: 3072
• id-MLDSA65-RSA4096-PSS-SHA512
  • OID: 2.16.840.1.114027.80.9.1.26
  • Label: COMPSIG-MLDSA65-RSA4096-PSS-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: id-RSASSA-PSS
    • RSA size: 4096
    • RSASSA-PSS parameters: See
• id-MLDSA65-RSA4096-PKCS15-SHA512
  • OID: 2.16.840.1.114027.80.9.1.27
  • Label: COMPSIG-MLDSA65-RSA4096-PKCS15-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: sha384WithRSAEncryption
    • RSA size: 4096
• id-MLDSA65-ECDSA-P256-SHA512
  • OID: 2.16.840.1.114027.80.9.1.28
  • Label: COMPSIG-MLDSA65-P256-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: ECDSA
    • Traditional Signature Algorithm: ecdsa-with-SHA256
    • ECDSA curve: secp256r1
• id-MLDSA65-ECDSA-P384-SHA512
  • OID: 2.16.840.1.114027.80.9.1.29
  • Label: COMPSIG-MLDSA65-P384-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: ECDSA
    • Traditional Signature Algorithm: ecdsa-with-SHA384
    • ECDSA curve: secp384r1
• id-MLDSA65-ECDSA-brainpoolP256r1-SHA512
  • OID: 2.16.840.1.114027.80.9.1.30
  • Label: COMPSIG-MLDSA65-BP256-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: ECDSA
    • Traditional Signature Algorithm: ecdsa-with-SHA256
    • ECDSA curve: brainpoolP256r1
• id-MLDSA65-Ed25519-SHA512
  • OID: 2.16.840.1.114027.80.9.1.31
  • Label: COMPSIG-MLDSA65-Ed25519-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-65
  • Traditional Algorithm: Ed25519
    • Traditional Signature Algorithm: id-Ed25519
• id-MLDSA87-ECDSA-P384-SHA512
  • OID: 2.16.840.1.114027.80.9.1.32
  • Label: COMPSIG-MLDSA87-P384-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-87
  • Traditional Algorithm: ECDSA
    • Traditional Signature Algorithm: ecdsa-with-SHA384
    • ECDSA curve: secp384r1
• id-MLDSA87-ECDSA-brainpoolP384r1-SHA512
  • OID: 2.16.840.1.114027.80.9.1.33
  • Label: COMPSIG-MLDSA87-BP384-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-87
  • Traditional Algorithm: ECDSA
    • Traditional Signature Algorithm: ecdsa-with-SHA384
    • ECDSA curve: brainpoolP384r1
• id-MLDSA87-Ed448-SHAKE256
  • OID: 2.16.840.1.114027.80.9.1.34
  • Label: COMPSIG-MLDSA87-Ed448-SHAKE256
  • Pre-Hash function (PH): SHAKE256/64**
  • ML-DSA variant: ML-DSA-87
  • Traditional Algorithm: Ed448
    • Traditional Signature Algorithm: id-Ed448
• id-MLDSA87-RSA3072-PSS-SHA512
  • OID: 2.16.840.1.114027.80.9.1.35
  • Label: COMPSIG-MLDSA87-RSA3072-PSS-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-87
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: id-RSASSA-PSS
    • RSA size: 3072
    • RSASSA-PSS parameters: See
• id-MLDSA87-RSA4096-PSS-SHA512
  • OID: 2.16.840.1.114027.80.9.1.36
  • Label: COMPSIG-MLDSA87-RSA4096-PSS-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-87
  • Traditional Algorithm: RSA
    • Traditional Signature Algorithm: id-RSASSA-PSS
    • RSA size: 4096
    • RSASSA-PSS parameters: See
• id-MLDSA87-ECDSA-P521-SHA512
  • OID: 2.16.840.1.114027.80.9.1.37
  • Label: COMPSIG-MLDSA87-P521-SHA512
  • Pre-Hash function (PH): SHA512
  • ML-DSA variant: ML-DSA-87
  • Traditional Algorithm: ECDSA
    • Traditional Signature Algorithm: ecdsa-with-SHA512
    • ECDSA curve: secp521r1

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. **Note: The pre-hash functions were chosen to roughly match the security level of the stronger component. In the case of Ed25519 and Ed448 they match the hash function defined in ; SHA512 for Ed25519ph and SHAKE256(x, 64), which is SHAKE256 producing 64 bytes (512 bits) of output, for Ed448ph.

RSASSA-PSS Parameters Use of RSASSA-PSS requires extra parameters to be specified. The RSASSA-PSS-params ASN.1 type defined in is not used in Composite ML-DSA encodings since the parameter values are fixed by this specification. However, below refer to the named fields of the RSASSA-PSS-params ASN.1 type in order to provide a mapping between the use of RSASSA-PSS in Composite ML-DSA and When RSA-PSS is used at the 2048-bit or 3072-bit security level, RSASSA-PSS SHALL be instantiated with the following parameters: RSASSA-PSS 2048 and 3072 Parameters

RSASSA-PSS-params field	Value
hashAlgorithm	id-sha256
maskGenAlgorithm.algorithm	id-mgf1
maskGenAlgorithm.parameters	id-sha256
saltLength	32
trailerField	1

When RSA-PSS is used at the 4096-bit security level, RSASSA-PSS SHALL be instantiated with the following parameters: RSASSA-PSS 4096 Parameters

RSASSA-PSS-params field	Value
hashAlgorithm	id-sha384
maskGenAlgorithm.algorithm	id-mgf1
maskGenAlgorithm.parameters	id-sha384
saltLength	48
trailerField	1

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-DSA 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 adversaries and "qubits of security" against quantum adversaries. SHA2 is prioritized over SHA3 in order to facilitate implementations that do not have easy access to SHA3 outside of the ML-DSA module. However SHAKE256 is used with Ed448 since this is already the recommended hash functions chosen for ED448ph in . In some cases, multiple hash functions are used within the same composite algorithm. Consider for example id-MLDSA65-ECDSA-P256-SHA512 which requires SHA512 as the overall composite pre-hash in order to maintain the security level of ML-DSA-65, but uses SHA256 within the ecdsa-with-SHA256 with secp256r1 traditional component. While this increases the implementation burden of needing to carry multiple hash functions for a single composite algorithm, this aligns with the design goal of choosing commonly-implemented traditional algorithms since ecdsa-with-SHA256 with secp256r1 is far more common than, for example, ecdsa-with-SHA512 with secp256r1. Full specifications for the referenced algorithms can be found in .

ASN.1 Module Composite-MLDSA-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-composite-mldsa-2025(TBDMOD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS, AlgorithmIdentifier{} 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) } ; -- -- Object Identifiers -- -- -- Information Object Classes -- pk-CompositeSignature {OBJECT IDENTIFIER:id} PUBLIC-KEY ::= { IDENTIFIER id -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign} -- PRIVATE-KEY no ASN.1 wrapping -- } sa-CompositeSignature{OBJECT IDENTIFIER:id, PUBLIC-KEY:publicKeyType } SIGNATURE-ALGORITHM ::= { IDENTIFIER id -- VALUE no ASN.1 wrapping -- PARAMS ARE absent PUBLIC-KEYS {publicKeyType} } -- Composite ML-DSA which uses a PreHash Message -- TODO: OID to be replaced by IANA id-MLDSA44-RSA2048-PSS-SHA256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 20 } pk-MLDSA44-RSA2048-PSS-SHA256 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-RSA2048-PSS-SHA256} sa-MLDSA44-RSA2048-PSS-SHA256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA44-RSA2048-PSS-SHA256, pk-MLDSA44-RSA2048-PSS-SHA256 } -- TODO: OID to be replaced by IANA id-MLDSA44-RSA2048-PKCS15-SHA256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 21 } pk-MLDSA44-RSA2048-PKCS15-SHA256 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-RSA2048-PKCS15-SHA256} sa-MLDSA44-RSA2048-PKCS15-SHA256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA44-RSA2048-PKCS15-SHA256, pk-MLDSA44-RSA2048-PKCS15-SHA256 } -- TODO: OID to be replaced by IANA id-MLDSA44-Ed25519-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 22 } pk-MLDSA44-Ed25519-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-Ed25519-SHA512} sa-MLDSA44-Ed25519-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA44-Ed25519-SHA512, pk-MLDSA44-Ed25519-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA44-ECDSA-P256-SHA256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 23 } pk-MLDSA44-ECDSA-P256-SHA256 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA44-ECDSA-P256-SHA256} sa-MLDSA44-ECDSA-P256-SHA256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA44-ECDSA-P256-SHA256, pk-MLDSA44-ECDSA-P256-SHA256 } -- TODO: OID to be replaced by IANA id-MLDSA65-RSA3072-PSS-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 24 } pk-MLDSA65-RSA3072-PSS-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA3072-PSS-SHA512} sa-MLDSA65-RSA3072-PSS-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-RSA3072-PSS-SHA512, pk-MLDSA65-RSA3072-PSS-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA65-RSA3072-PKCS15-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 25 } pk-MLDSA65-RSA3072-PKCS15-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA3072-PKCS15-SHA512} sa-MLDSA65-RSA3072-PKCS15-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-RSA3072-PKCS15-SHA512, pk-MLDSA65-RSA3072-PKCS15-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA65-RSA4096-PSS-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 26 } pk-MLDSA65-RSA4096-PSS-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA4096-PSS-SHA512} sa-MLDSA65-RSA4096-PSS-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-RSA4096-PSS-SHA512, pk-MLDSA65-RSA4096-PSS-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA65-RSA4096-PKCS15-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 27 } pk-MLDSA65-RSA4096-PKCS15-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-RSA4096-PKCS15-SHA512} sa-MLDSA65-RSA4096-PKCS15-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-RSA4096-PKCS15-SHA512, pk-MLDSA65-RSA4096-PKCS15-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA65-ECDSA-P256-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 28 } pk-MLDSA65-ECDSA-P256-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-ECDSA-P256-SHA512} sa-MLDSA65-ECDSA-P256-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-ECDSA-P256-SHA512, pk-MLDSA65-ECDSA-P256-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA65-ECDSA-P384-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 29 } pk-MLDSA65-ECDSA-P384-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-ECDSA-P384-SHA512} sa-MLDSA65-ECDSA-P384-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-ECDSA-P384-SHA512, pk-MLDSA65-ECDSA-P384-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 30 } pk-MLDSA65-ECDSA-brainpoolP256r1-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-ECDSA-brainpoolP256r1-SHA512} sa-MLDSA65-ECDSA-brainpoolP256r1-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-ECDSA-brainpoolP256r1-SHA512, pk-MLDSA65-ECDSA-brainpoolP256r1-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA65-Ed25519-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 31 } pk-MLDSA65-Ed25519-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA65-Ed25519-SHA512} sa-MLDSA65-Ed25519-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA65-Ed25519-SHA512, pk-MLDSA65-Ed25519-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA87-ECDSA-P384-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 32 } pk-MLDSA87-ECDSA-P384-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-ECDSA-P384-SHA512} sa-MLDSA87-ECDSA-P384-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA87-ECDSA-P384-SHA512, pk-MLDSA87-ECDSA-P384-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 33 } pk-MLDSA87-ECDSA-brainpoolP384r1-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-ECDSA-brainpoolP384r1-SHA512} sa-MLDSA87-ECDSA-brainpoolP384r1-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA87-ECDSA-brainpoolP384r1-SHA512, pk-MLDSA87-ECDSA-brainpoolP384r1-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA87-Ed448-SHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 34 } pk-MLDSA87-Ed448-SHAKE256 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-Ed448-SHAKE256} sa-MLDSA87-Ed448-SHAKE256 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA87-Ed448-SHAKE256, pk-MLDSA87-Ed448-SHAKE256 } -- TODO: OID to be replaced by IANA id-MLDSA87-RSA3072-PSS-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 35 } pk-MLDSA87-RSA3072-PSS-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-RSA3072-PSS-SHA512} sa-MLDSA87-RSA3072-PSS-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA87-RSA3072-PSS-SHA512, pk-MLDSA87-RSA3072-PSS-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA87-RSA4096-PSS-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 36 } pk-MLDSA87-RSA4096-PSS-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-RSA4096-PSS-SHA512} sa-MLDSA87-RSA4096-PSS-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA87-RSA4096-PSS-SHA512, pk-MLDSA87-RSA4096-PSS-SHA512 } -- TODO: OID to be replaced by IANA id-MLDSA87-ECDSA-P521-SHA512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027) algorithm(80) composite-mldsa(9) signature(1) 37 } pk-MLDSA87-ECDSA-P521-SHA512 PUBLIC-KEY ::= pk-CompositeSignature{ id-MLDSA87-ECDSA-P521-SHA512} sa-MLDSA87-ECDSA-P521-SHA512 SIGNATURE-ALGORITHM ::= sa-CompositeSignature{ id-MLDSA87-ECDSA-P521-SHA512, pk-MLDSA87-ECDSA-P521-SHA512 } SignatureAlgorithmSet SIGNATURE-ALGORITHM ::= { sa-MLDSA44-RSA2048-PSS-SHA256 | sa-MLDSA44-RSA2048-PKCS15-SHA256 | sa-MLDSA44-Ed25519-SHA512 | sa-MLDSA44-ECDSA-P256-SHA256 | sa-MLDSA65-RSA3072-PSS-SHA512 | sa-MLDSA65-RSA3072-PKCS15-SHA512 | sa-MLDSA65-RSA4096-PSS-SHA512 | sa-MLDSA65-RSA4096-PKCS15-SHA512 | sa-MLDSA65-ECDSA-P256-SHA512 | sa-MLDSA65-ECDSA-P384-SHA512 | sa-MLDSA65-ECDSA-brainpoolP256r1-SHA512 | sa-MLDSA65-Ed25519-SHA512 | sa-MLDSA87-ECDSA-P384-SHA512 | sa-MLDSA87-ECDSA-brainpoolP384r1-SHA512 | sa-MLDSA87-Ed448-SHAKE256 | sa-MLDSA87-RSA3072-PSS-SHA512 | sa-MLDSA87-RSA4096-PSS-SHA512 | sa-MLDSA87-ECDSA-P521-SHA512, ... } END ]]>

IANA Considerations IANA is requested to assign an object identifier (OID) for the module identifier (TBDMOD) with a Description of "id-mod-composite-mldsa-2025". The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). IANA is also requested to allocate values from the "SMI Security for PKIX Algorithms" registry (1.3.6.1.5.5.7.6) to identify the eighteen algorithms defined within.

Object Identifier Allocations EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in .

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

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

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

• id-MLDSA44-RSA2048-PSS-SHA256
  • Decimal: IANA Assigned
  • Description: id-MLDSA44-RSA2048-PSS-SHA256
  • References: This Document
• id-MLDSA44-RSA2048-PKCS15-SHA256
  • Decimal: IANA Assigned
  • Description: id-MLDSA44-RSA2048-PKCS15-SHA256
  • References: This Document
• id-MLDSA44-Ed25519-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA44-Ed25519-SHA512
  • References: This Document
• id-MLDSA44-ECDSA-P256-SHA256
  • Decimal: IANA Assigned
  • Description: id-MLDSA44-ECDSA-P256-SHA256
  • References: This Document
• id-MLDSA65-RSA3072-PSS-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-RSA3072-PSS-SHA512
  • References: This Document
• id-MLDSA65-RSA3072-PKCS15-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-RSA3072-PKCS15-SHA512
  • References: This Document
• id-MLDSA65-RSA4096-PSS-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-RSA4096-PSS-SHA512
  • References: This Document
• id-MLDSA65-RSA4096-PKCS15-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-RSA4096-PKCS15-SHA512
  • References: This Document
• id-MLDSA65-ECDSA-P256-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-ECDSA-P256-SHA512
  • References: This Document
• id-MLDSA65-ECDSA-P384-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-ECDSA-P384-SHA512
  • References: This Document
• id-MLDSA65-ECDSA-brainpoolP256r1-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-ECDSA-brainpoolP256r1-SHA512
  • References: This Document
• id-MLDSA65-Ed25519-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA65-Ed25519-SHA512
  • References: This Document
• id-MLDSA87-ECDSA-P384-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA87-ECDSA-P384-SHA512
  • References: This Document
• id-MLDSA87-ECDSA-brainpoolP384r1-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA87-ECDSA-brainpoolP384r1-SHA512
  • References: This Document
• id-MLDSA87-Ed448-SHAKE256
  • Decimal: IANA Assigned
  • Description: id-MLDSA87-Ed448-SHAKE256
  • References: This Document
• id-MLDSA87-RSA3072-PSS-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA87-RSA3072-PSS-SHA512
  • References: This Document
• id-MLDSA87-RSA4096-PSS-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA87-RSA4096-PSS-SHA512
  • References: This Document
• id-MLDSA87-ECDSA-P521-SHA512
  • Decimal: IANA Assigned
  • Description: id-MLDSA87-ECDSA-P521-SHA512
  • References: This Document

Security Considerations

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 adversary 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. goes into more detail here. One common counter-argument against PQ/T hybrid signatures is that if an adversary can forge one of the component algorithms, then why attack the hybrid-signed message at all when they could simply forge a completely new message? The answer to this question must be found outside the cryptographic primitives themselves, and instead in policy; once an algorithm is known to be broken it ought to be disallowed for single-algorithm use by cryptographic policy, while hybrids involving that algorithm may continue to be used and to provide value, and also in the fact that the composite public key could be trusted by the verifier while the component keys in isolation are not, thus requiring the adversary to forge a whole composite signature. 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 backwards compatibility to allow legacy and upgraded applications to co-exist and communicate. The composites 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-DSA implementation which immediately starts providing benefits against long-term document integrity attacks even if that ML-DSA 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 .

Non-separability, EUF-CMA and SUF First, a note about the security model under which this analysis is performed. This specification strictly forbids re-using component key material between composite and non-composite keys, or between multiple composite keys. This specification also exists within the X.509 PKI architecture where trust in a public verification key is assumed to be established either directly via a trust store or via a certificate chain. That said, these are both policy mechanisms that are outside the formal definitions of EUF-CMA and SUF-CMA under which a signature primitive must be analysed, therefore this section considers attacks that may be mitigated partially or completely within a strictly-implemented PKI setting, but which need to be considered when considering Composite ML-DSA as a general-purpose signature primitive that could be used outside of the X.509 setting. The second securtiy model considiration is that composites are designed to provide value even if one algorithm is broken, even if you do not know which. However, the security properties offered by the composite signature can differ based on which algorithm you consider to be broken. The security notion of Weak Non-Separability (WNS) of a hybrid signature is defined in as the guarantee that an adversary cannot simply "remove" one of the component signatures without evidence left behind. We also position this as being a hybrid variant of the unforgeability game: given a composite signature (M, (mldsaSig, tradSig)), can an adversary with access to a signing oracle but not to the signing private keys, produce a (M', mldsaSig') or (M', tradSig') that will be accepted by the respective standalone primitives. If M' is different from M then this is "Hybrid EUF-CMA". If M' = M, but the signature is new, then this is "Hybrid SUF-CMA". The signature combiner defined in this specification is Weakly Non-Separable (WNS) when used within X.509 because all X.509 data structures include the OID of the signature algorithm inside the signed object; if a composite signature is split into two separate signatures, then the signed-over OID will still indicate a composite signature algorithm, and this will fail at the X.509 processing layer. Similar if two independent signatures are assempbled into a composite. This meets the definition of WNS. The prohibition on key reuse between composite and single-algorithm contexts discussed in further strengthens the non-separability in practice, but does not achieve Strong Non-Separability (SNS) since policy mechanisms such as this are outside the definition of SNS. Moreover, composite signatures have Hybrid EUF-CMA security built into the primitive, independent of any enforcement done at the protocol layer: if a signer wishes to sign a message M, it is instead M' as defined in which is passed to the component signature primitives. Consider that an adversary splits (M, (mldsaSig, tradSig)) into (M', mldsaSig) and (M', tradSig). On the ML-DSA side, (M', mldsaSig) will not be accepted by a standalone because the composite signed with ML-DSA's context value equal to the composite algorithm's Label which will fail to verify under ML-DSA.Verify(M, ctx=""). On the traditional side, (M', tradSig) would be accepted, but the static Prefix defined in provides a way to mitigate against this. So, to be precise, Composite ML-DSA achieves Hybrid EUF-CMA security on the ML-DSA side, and conditionally achieves it on the traditional side if the prefix-based mitigation described in is applied. The (non-hibred) unforgeability properties of the composite as a whole are somewhat more nuanced. We recall first the definitions of Existential Unforgeability under Chosen Message Attack (EUF-CMA) and Strong Unforgeability (SUF). The classic EUF-CMA game is in reference to a pair of algorithms ( Sign(), Verify() ) where the adversary has access to a signing oracle using the Sign() and must produce a message-signature pair (m', s') that is accepted by the verifier using Verify() and where m' was never signed by the oracle. SUF is similar but requires only that (m', s') != (m, s) for any honestly-generated (m, s), i.e. that the adversary cannot construct a new signature to an already-signed message. The pair ( CompositeML-DSA.Sign(), CompositeML-DSA.Verify() ) is EUF-CMA secure so long as at least one component algorithm is EUF-CMA secure since any attempt to modify the message would cause the EUF-CMA secure component to fail its Verify() which in turn will cause CompositeML-DSA.Verify() to fail. Composite ML-DSA only achieves SUF security if both components are SUF secure, but does not necessarily provide SUF if one component is compromised; the argument is that if the first component algorithm is not SUF secure then by definition it admits at least one (m, s1') pair where s1' was not produced by the honest signer, and the adversary can then combine it with an honestly-signed (m, s2) signature produced by the second algorithm over the same message m to create (m, (s1', s2)) which violates SUF for the composite algorithm. ML-DSA is SUF secure. Of the traditional signature component algorithms used in this specification, only Ed25519 and Ed448 are SUF secure and therefore applications that require SUF security SHOULD use the composite combinations with ML-DSA and either Ed25519 or Ed448. Additionally, within some protocol contexts, SUF security may be restored by properties of the protocol; for example within X.509 certificates , every signature produced by a CA will necessarily include a unique serial number, so the CA will never produce two different signatures over the same data, so the SUF property can be considered to be satisfied under realistic conditions.

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 key 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 that 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 an already-deployed RSA key pair and combine it with an ML-DSA key pair to form a hybrid key pair for use in a hybrid algorithm. Within a hybrid signature context this leads to a class of attacks referred to as "stripping attacks" discussed in and may also open up risks from further cross-protocol attacks. Despite the weak non-separability property offered by the composite signature combiner, key reuse MUST be avoided to prevent the introduction of EUF-CMA vulnerabilities. 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. Some application might disregard the requirements of this specification to not reuse key material between single-algorithm and composite contexts. While doing so is still a violation of this specification, the weakening of security from doing so can be mitigated by using an appropriate ctx value, such as ctx=Foobar-dual-cert-sig to indicate that this signature belongs to the Foobar protocol where two certificates were used to create a single composite signature. This specification does not endorse such uses, and per-application security analysis is needed.

Use of Prefix for attack mitigation The Prefix value specified in allows for cautious implementers to wrap their existing Traditional Verify() implementations with a guard that looks for messages starting with this string and fail with an error -- i.e. this can act as an extra protection against taking a composite signature and splitting it back into components. However, an implementation that does this will be unable to perform a Traditional signature and verification on a message which happens to start with this string. The designers accepted this trade-off.

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.

Implementation 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. One of the primary design goals of this specification is for the overall composite algorithm to be able to be considered FIPS-approved even when one of the component algorithms is not. Implementers seeking FIPS certification of a composite signature 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-DSA.KeyGen_internal(seed) 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-DSA.KeyGen. However, using an interface which doesn't support a seed will prevent the implementation from encoding the private key according to . Another example is pre-hashing; a pre-hash is inherent to RSA, ECDSA, and ML-DSA (μ), and composite makes no assumptions or requirements about whether component-specific pre-hashing is done locally as part of the composite, or remotely as part of the component primitive. Note also that also that depicts the generation of the seed as mldsaSeed = Random(), when implementing this for FIPS certification, this MUST be the direct output of a FIPS-approved DRBG. 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.

Backwards Compatibility The term "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 document explicitly does not provide backwards compatibility, only upgraded systems will understand the OIDs defined in this specification. If backwards compatibility is required, then additional mechanisms will be needed. 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 digital signature objects, from online negotiated protocols such as TLS 1.3 and IKEv2 , to non-negotiated asynchronous protocols such as S/MIME signed email , document signing such as in the context of the European eIDAS regulations , and publicly trusted code signing , as well as myriad other standardized and proprietary protocols and applications that leverage CMS signed structures. Composite simplifies the protocol design work because it can be implemented as a signature algorithm that fits into existing systems.

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 as it provides the best overall balance of performance and security. Below we list a few other recommendations for specific scenarios. In applications that require RSA, it is RECOMMENDED to focus implementation effort on: In applications that are performance and bandwidth-sensitive, 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: In applications that require the signature primitive to provide SUF-CMA, it is RECOMMENDED to focus implementation effort on:

External Pre-hashing Implementers MAY externalize the pre-hash computation outside the module that computes Composite-ML-DSA.Sign() in an analogous way to how pre-hash signing is used for RSA, ECDSA or HashML-DSA. Such a modification to the Composite-ML-DSA.Sign() algorithm is considered compliant to this specification so long as it produces the same output and error conditions. Below is a suggested implementation for splitting the pre-hashing and signing between two parties. .Prehash(M) -> ph Explicit inputs: M The message to be signed, an octet string. Implicit inputs mapped from : PH The hash function to use for pre-hashing. Output: ph The pre-hash which equals PH ( M ) Process: 1. Compute the Prehash of the message using the Hash function defined by PH ph = PH ( M ) 2. Output ph ]]> .Sign_ph(sk, ph, ctx) -> s Explicit inputs: sk Composite private key consisting of signing private keys for each component. ph The pre-hash digest over the message ctx The Message context string used in the composite signature combiner, which defaults to the empty string. Implicit inputs mapped from : ML-DSA The underlying ML-DSA algorithm and parameter set, for example "ML-DSA-65". Trad The underlying traditional algorithm and parameter set, for example "sha256WithRSAEncryption" or "Ed25519". Prefix The prefix octet string. Label A signature label which is specific to each composite algorithm. Additionally, the composite label is passed into the underlying ML-DSA primitive as the ctx. Signature Label values are defined in the "Signature Label Values" section below. Process: 1. Identical to Composite-ML-DSA.Sign (sk, M, ctx) but replace the internally generated PH( M ) from step 2 of Composite-ML-DSA.Sign (sk, M, ctx) with ph which is input into this function. ]]>

References Normative 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 specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK] 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 on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK] 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 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 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 the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK] 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 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. Federal Information Processing Standard, FIPS 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 describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. 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. ITU-T Certicom Research Certicom Research American National Standards Institute 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 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] 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. 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. 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. AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. SandboxAQ Naval Postgraduate School SandboxAQ UK National Cyber Security Centre This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards/forwards compatibility, hybrid generality, and simultaneous verification. Discussion of this work is encouraged to happen on the IETF PQUIP mailing list pqc@ietf.org or on the GitHub repository which contains the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid- signature-spectrums 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. European Parliament and Council n.d. CA/Browser Forum n.d.

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

• Compressed vs uncompressed EC point.
• The RSA public key (n, e) allows e to vary is 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.

Size values marked with an asterisk (*) in the table are not fixed but maximum possible values for the composite key or ciphertext. Implementations should be careful when performing length checking based on such values. Non-hybrid ML-DSA is included for reference. Maximum size values of composite ML-DSA

Algorithm	Public key	Private key	Signature
id-ML-DSA-44	1312	32	2420
id-ML-DSA-65	1952	32	3309
id-ML-DSA-87	2592	32	4627
id-MLDSA44-RSA2048-PSS-SHA256	1582*	1226*	2676
id-MLDSA44-RSA2048-PKCS15-SHA256	1582*	1226*	2676
id-MLDSA44-Ed25519-SHA512	1344	66	2484
id-MLDSA44-ECDSA-P256-SHA256	1377	71	2492*
id-MLDSA65-RSA3072-PSS-SHA512	2350*	1802*	3693
id-MLDSA65-RSA3072-PKCS15-SHA512	2350*	1802*	3693
id-MLDSA65-RSA4096-PSS-SHA512	2478*	2383*	3821
id-MLDSA65-RSA4096-PKCS15-SHA512	2478*	2383*	3821
id-MLDSA65-ECDSA-P256-SHA512	2017	71	3381*
id-MLDSA65-ECDSA-P384-SHA512	2049	87	3413*
id-MLDSA65-ECDSA-brainpoolP256r1-SHA512	2017	71	3381*
id-MLDSA65-Ed25519-SHA512	1984	66	3373
id-MLDSA87-ECDSA-P384-SHA512	2689	87	4731*
id-MLDSA87-ECDSA-brainpoolP384r1-SHA512	2689	87	4731*
id-MLDSA87-Ed448-SHAKE256	2649	91	4741
id-MLDSA87-RSA3072-PSS-SHA512	2990*	1802*	5011
id-MLDSA87-RSA4096-PSS-SHA512	3118*	2383*	5139
id-MLDSA87-ECDSA-P521-SHA512	2725	105	4766*

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

Component Signature Algorithm ID	OID	Specification
id-ML-DSA-44	2.16.840.1.101.3.4.3.17
id-ML-DSA-65	2.16.840.1.101.3.4.3.18
id-ML-DSA-87	2.16.840.1.101.3.4.3.19
id-Ed25519	1.3.101.112	,
id-Ed448	1.3.101.113	,
ecdsa-with-SHA256	1.2.840.10045.4.3.2	, , , , ,
ecdsa-with-SHA384	1.2.840.10045.4.3.3	, , , , ,
ecdsa-with-SHA512	1.2.840.10045.4.3.4	, , , , ,
sha256WithRSAEncryption	1.2.840.113549.1.1.11
sha384WithRSAEncryption	1.2.840.113549.1.1.12
id-RSASSA-PSS	1.2.840.113549.1.1.10

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 pre-hashed Composite Constructions to build PH element

HashID	OID	Specification
id-sha256	2.16.840.1.101.3.4.2.1
id-sha384	2.16.840.1.101.3.4.2.2
id-sha512	2.16.840.1.101.3.4.2.3
id-shake256	2.16.840.1.101.3.4.2.18
id-mgf1	1.2.840.113549.1.1.8

Component AlgorithmIdentifiers for Public Keys and Signatures 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 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 and signature AlgorithmIdentifiers for each component algorithm. For newer Algorithms like Ed25519 or ML-DSA the AlgorithmIdentifiers are the same for Public Key and Signature. Older Algorithms have different AlgorithmIdentifiers for keys and signatures and are specified separately here for each component. ML-DSA-44 AlgorithmIdentifier of Public Key and Signature ML-DSA-65 AlgorithmIdentifier of Public Key and Signature ML-DSA-87 AlgorithmIdentifier of Public Key and Signature RSASSA-PSS 2048 & 3072 AlgorithmIdentifier of Public Key Note that we suggest here to use id-RSASSA-PSS (1.2.840.113549.1.1.10) as the public key OID for RSA-PSS, although most implementations also would accept rsaEncryption (1.2.840.113549.1.1.1), and some might in fact prefer or require it. AlgorithmIdentifier of Signature RSASSA-PSS 4096 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature RSASSA-PKCS1-v1_5 2048 & 3072 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature RSASSA-PKCS1-v1_5 4096 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature ECDSA NIST P256 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature ECDSA NIST P384 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature ECDSA NIST P521 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature ECDSA Brainpool-P256 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature ECDSA Brainpool-P384 AlgorithmIdentifier of Public Key AlgorithmIdentifier of Signature Ed25519 AlgorithmIdentifier of Public Key and Signature Ed448 AlgorithmIdentifier of Public Key and Signature

Message Representative Examples This section provides examples of constructing the message representative M', showing all intermediate values. This is intended to be useful for debugging purposes. The input message for this example is the hex string "00 01 02 03 04 05 06 07 08 09". Each input component is shown. Note that values are shown hex-encoded for display purposes only, they are actually raw binary values.

• Prefix is the fixed constant defined in .
• Label is the specific signature label for this composite algorithm, as defined in .
• len(ctx) is the length of the Message context String which is 00 when no context is used.
• ctx is the Message context string used in the composite signature combiner. It is empty in this example.
• PH(M) is the output of hashing the message M.

Finally, the fully assembled M' is given, which is simply the concatenation of the above values. First is an example of constructing the message representative M' for MLDSA65-ECDSA-P256-SHA256 without a context string ctx. # Components of M': Prefix: 436f6d706f73697465416c676f726974686d5369676e61747572657332303235 Label: COMPSIG-MLDSA65-P256-SHA512 len(ctx): 00 ctx: PH(M): 0f89ee1fcb7b0a4f7809d1267a029719004c5a5e5ec323a7c3523a20974f 9a3f202f56fadba4cd9e8d654ab9f2e96dc5c795ea176fa20ede8d854c342f90353 3 # Outputs: # M' = Prefix || Label || len(ctx) || ctx || PH(M) M': 436f6d706f73697465416c676f726974686d5369676e6174757265733230323 5434f4d505349472d4d4c44534136352d503235362d534841353132000f89ee1fcb 7b0a4f7809d1267a029719004c5a5e5ec323a7c3523a20974f9a3f202f56fadba4c d9e8d654ab9f2e96dc5c795ea176fa20ede8d854c342f903533 ]]> Second is an example of constructing the message representative M' for MLDSA65-ECDSA-P256-SHA256 with a context string ctx. The inputs are similar to the first example with the exception that there is an 8 byte context string 'ctx'.

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 message m is signed over in all test cases. m is the ASCII string "The quick brown fox jumps over the lazy dog." Within each test case there are the following values:

• tcId the name of the algorithm.
• pk the verification public key.
• x5c a self-signed X.509 certificate of the public key.
• sk the raw signature private key.
• sk_pkcs8 the signature private key in a PKCS#8 object.
• s the signature value.

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

1. Load the public key pk or certificate x5c and use it to verify the signature s over the message m.
2. Validate the self-signed certificate x5c.
3. Load the signing private key sk or sk_pkcs8 and use it to produce a new signature which can be verified using the provided pk or x5c.

Test vectors are provided for each underlying ML-DSA 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: https://github.com/lamps-wg/draft-composite-sigs/tree/main/src TODO: lock this to a specific commit.

Intellectual Property Considerations The following IPR Disclosure relates to this document: https://datatracker.ietf.org/ipr/3588/

Contributors and Acknowledgements This document incorporates contributions and comments from a large group of experts. The editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past six years in pursuit of this document: Serge Mister (Entrust), Felipe Ventura (Entrust), Richard Kettlewell (Entrust), Ali Noman (Entrust), Dr. Britta Hale (Naval Postgraduade School), Tim Hollebeek (Digicert), Panos Kampanakis (Amazon), Chris A. Wood (Apple), Christopher D. Wood (Apple), Sophie Schmieg (Google), Bas Westerbaan (Cloudflare), Deirdre Connolly (SandboxAQ), Richard Kisley (IBM), Piotr Popis (Enigma), François Rousseau, Falko Strenzke, Alexander Ralien (Siemens), José Ignacio Escribano, Jan Oupický, 陳志華 (Abel C. H. Chen, Chunghwa Telecom), 林邦曄 (Austin Lin, Chunghwa Telecom), Zhao Peiduo (Seventh Sense AI), Phil Hallin (Microsoft), Samuel Lee (Microsoft), Alicja Kario (Red Hat), Jean-Pierre Fiset (Crypto4A), Varun Chatterji (Seventh Sense AI), Mojtaba Bisheh-Niasar and Douglas Stebila (University of Waterloo). We especially want to recognize the contributions of Dr. Britta Hale who has helped immensely with strengthening the signature combiner construction, and with analyzing the scheme with respect to EUF-CMA and Non-Separability properties. We wish to acknowledge particular effort from Carl Wallace and Daniel Van Geest (CryptoNext Security), who have put in sustained effort over multiple years both reviewing and implementing at the hackathon each iteration of this document. 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" - .