]> 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 US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use 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, and where existential unforgeability (EUF-CMA) level security is acceptable. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the LAMPS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The advent of quantum computing poses a significant threat to current cryptographic systems because traditional cryptographic signature algorithms such as RSA, DSA, and its elliptic curve variants will become vulnerable to quantum attacks (). Unlike previous migrations between cryptographic algorithms, this migration gives us the foresight that traditional cryptographic algorithms will be broken in the future, but will remain strong in the interim, the only uncertainty is around the timing. But there are also some novel challenges. For instance, the aggressive migration timelines may require deploying Post-Quantum Cryptography (PQC) algorithms before their implementations have been fully hardened or certified, and dual-algorithm data protection may be desirable over a longer time period to hedge against security vulnerabilities and other implementation flaws in the new implementations. Cautious implementers may opt to combine cryptographic algorithms in such a way that an 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" . 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. The composite algorithm presents a single public key and signature value such that it can be treated as a single atomic algorithm at the protocol level. This provides a property referred to as "protocol backwards compatibility" since it can be applied to protocols that are not explicitly hybrid-aware. The idea of a composite was first presented in . Composite algorithms retain some security even if one of their component algorithms is broken, which is discussed in detail in . This specification creates PQ/T Hybrids with the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), defined in as the Post-Quantum (PQ) component. Instantiations of the composite ML-DSA scheme are provided based on ML-DSA, RSA-PSS, RSA-PKCS#1v1.5, ECDSA, Ed25519, and Ed448. The full list of algorithms registered by this specification is provided in . Backwards compatibility in the sense of upgraded systems continuing to interoperate with legacy systems is not directly covered in this specification, but is the subject of . Certain jurisdictions have recommended that ML-DSA be used exclusively within a PQ/T hybrid framework. The use of a composite scheme provides a straightforward implementation of hybrid solutions compatible with (and advocated by) some governments and cybersecurity agencies , . In some situations it might be possible to add Post-Quantum, via a PQ/T Hybrid, to an already audited and compliant solution without invalidating the existing certification, whereas a full replacement of the traditional cryptography would almost certainly incur regulatory and compliance delays. In other words, PQ/T Hybrids can allow for deploying PQC 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 goal is to provide a stepping stone from which any cryptographic algorithm an organization has deployed today can evolve or transition. While this specification registers a large number of composite algorithms, it is expected that organizations will choose to deploy a single composite algorithm, or a small number of composite algorithms, that meets the needs of their environment and operational constraints, and very few implementers will need concern themselves with the entire list. This specification does not specify any mandatory-to-implement algorithms, but provides a short-list of recommended composite algorithms for common use-cases. Composite ML-DSA is applicable in PKIX-related applications that would otherwise use ML-DSA but where it is acceptable to have a signature primitive with the weaker property of existential unforgeability (EUF-CMA) security is acceptable, instead of the stronger property of strong existential unforgeability (SUF-CMA), which Composite ML-DSA does not offer.

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 . Some relevant definitions from are copied here for easier reading. 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. APPLICATION BACKWARDS COMPATIBILITY: A property indicating whether an upgraded and non-upgraded application can successfully establish communication. COMPOSITE CRYPTOGRAPHIC ELEMENT: defines composites as: A cryptographic element that incorporates multiple component cryptographic elements of the same type for use in a multi-algorithm scheme, such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements. For example this could be an asymmetric algorithm such as "ML-DSA-65" or "RSASSA-PSS". DER: Distinguished Encoding Rules as defined in . ECDSA: The Elliptic Curve Digital Signature Algorithm defined in . EdDSA, Ed25519 and Ed448: Edwards-curve Digital Signature Algorithm (EdDSA) defined in with two parameter sets: Ed25519 and Ed448. ML-DSA: The Module-Lattice-Based Digital Signature Standard defined in . PKI: Public Key Infrastructure, as defined in . POST-QUANTUM TRADITIONAL (PQ/T) HYBRID SCHEME: defines a PQ/T Hybrid Scheme as: A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. PROTOCOL BACKWARDS COMPATIBILITY: A property whereby a new feature can be added to a protocol without requiring any changes to the protocol's specification and only minimal changes to its implementations. Typically this means that the new feature fits within a defined extension point of the protocol instead of requiring a structural change to the protocol. This is notable because many PQ/T Hybrids require modification of the protocol to make it "hybrid aware", whereas this specification presents as a standalone algorithm and thus can take advantage of existing cryptographic agility mechanisms. RSA: The Rivest-Shamir-Adleman cryptosystem, used in this specification as the Probabilistic Signature Scheme (RSA-PSS) defined in . SIGNATURE: A digital cryptographic signature, making no assumptions about which algorithm.

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

• || represents concatenation of two-byte arrays.
• [:] represents byte array slicing.
• (a, b) represents a pair of values a and b. Typically, this indicates that a function returns multiple values; the exact conveyance mechanism -- tuple, struct, output parameters, etc. -- is left to the implementer.
• (a, _): represents a pair of values where one -- the second one in this case -- is ignored.
• func(a) -> b: represents a function named func that takes a as input and produces b.
• Func<TYPE>(): represents a function that is 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 Composite algorithms, as defined in this specification, follow the definition in and should be regarded as a single algorithm that performs a single cryptographic operation typical of a digital signature algorithm. This generally means that the complexity of combining algorithms can and should be handled by the cryptographic library or cryptographic module. The design intent is that protocols such as PKCS#10 , Certificate Management Protocol (CMP) , X.509 , the Cryptographic Message Syntax (CMS) , and the Trust Anchor Format can treat composite algorithms as they would any other algorithm without the protocol layer to have any "hybrid-awareness". This is a property referred to as "protocol backwards-compatibility". Discussion of the specific choices of algorithm pairings can be found in . In terms of security properties, the document considers the two security properties existential forgery against a chosen message attack (EUF-CMA) and strong unforgeability against a chosen message attack (SUF-CMA), which are treated more rigorously in and . As a simplified summary, Composite ML-DSA will be EUF-CMA secure if at least one of its component algorithms is EUF-CMA secure and the pre-hashed message representative PH is collision resistant. SUF-CMA security of Composite ML-DSA is more complicated. While some of the algorithm combinations defined in this specification are likely to be SUF-CMA secure against classical adversaries, none are SUF-CMA secure against a quantum adversary. This means that replacing an ML-DSA signature with a Composite ML-DSA signature is a reduction in security and should not be used in applications sensitive to the difference between SUF-CMA and EUF-CMA security. Composite ML-DSA is NOT RECOMMENDED for use in applications where it is has not been shown that EUF-CMA is acceptable. Further discussion can be found in .

Overview of the Composite ML-DSA Signature Scheme Composite ML-DSA is a PQ/T 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(mldsaPK, 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 The ML-DSA algorithm as specified in is not pre-hashed, meaning that the entire to-be-signed message is passed into ML-DSA.Sign(sk, M, ctx) ( Algorithm 2). While there are some cryptographic advantages to designing a signature algorithm this way, it also has some operational drawbacks; namely the performance and privacy implications of needing to stream the entire to-be-signed message to the signing module or service, which is doubled in the context of a composite since the to-be-signed message needs to be streamed to both underlying component algorithms. Also, "pure" (aka not pre-hashed) modes lack support for digesting the message once and then signing the digest with multiple different keys or multiple different context ctx values. Composite ML-DSA takes a design approach which mirrors that of Algorithm 2 in that the to-be-signed message representative M' in contains a hash of the message PH( M ) instead of the full message M. which closely mirrors the construction of M' in Algorithm 4. Given this design of Composite ML-DSA, it is possible to split the pre-hashing step out from the signature generation process -- see for further discussion and sample algorithms. Note that while the overall construction of Composite ML-DSA is similar to that of HashML-DSA, the ML-DSA component inside the composite is "pure" ML-DSA; implementing this specification does not require an implementation of HashML-DSA.

Prefix, Label, and CTX The to-be-signed message representative M', defined in 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. 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. The 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.

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, this specification strictly forbids re-using component key material between composite and non-composite keys, or between multiple composite keys. This means that an invocation of Composite-ML-DSA.KeyGen() MUST perform, or otherwise guarantee, fresh generation of the key material for both underlying algorithms and MUST NOT reuse existing key material. See for further discussion of the security implications. 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 process makes 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 . If one of the component KeyGen() routines returns an error, then the Composite-ML-DSA.KeyGen() routine MUST also return an error.

Allowed Modifications to the Key Generation Process Key generation is a process that is entirely internal to a cryptographic module, and as such it is often customized to fit the performance or operational requirements of the module. In cases where the private keys never leave the module or are otherwise not required to interoperate with other cryptographic modules, it is not required for interoperability for the private keys to match the format described in this specification. Therefore, in general, implementations of Composite ML-DSA MAY use an alternate key generation process so long as it generates compatible public keys, and so long as both component keys are freshly-generated and not re-used in a standalone key or within another composite key. Below are some examples of modifications that an implementer MAY make to the key generation process. The following are some examples of modifications that an implementation could make to the key generation process without affecting interoperability. Modifying the process to additionally output the expanded mldsaSK or to make 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. Modifying the process to have a deterministic KeyGen of one or both component keys from a seed; for example exposing an interface of Composite-ML-DSA<OID>.KeyGen(seed) such that one component algorithm is generated from the seed and the other from random, or the input seed is cryptographically expanded to produce seeds for both components. Implementation details and security analysis of such a modified key generation process is outside the scope of this document. Where interoperable private keys are not required, using a different private key representation than the one given in . For example, storing the component keys in separate cryptographic modules, or in separate PKCS#8 objects, or in a format that preserves the ML-DSA expanded key instead of the ML-DSA seed. The required modifications to the key generation process, as well as the signature generation process below, to support these private key representations are considered compliant with this specification so long as they generate compatible public keys, and so long as both component keys are freshly-generated. Note that when implementing Composite ML-DSA with a private key format that does not preserve the ML-DSA seed, especially when implementing on top of a cryptographic module that does not support seeds, it will be impossible to reconstruct a compliant seed-based private key as described in .

Sign The Sign() algorithm of Composite ML-DSA mirrors the construction of ML-DSA.Sign(sk, M, ctx) defined in Algorithm 2 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', mldsa_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. Note that there are two different context strings ctx at play: the first is the application context ctx that is passed in to Composite-ML-DSA.Sign and bound to the to-be-signed message M' in Step 2. The second is the mldsa-ctx that is passed down into the underlying ML-DSA.Sign(sk, M, ctx) as defined in Algorithm 2, in Step 4 and here Composite ML-DSA itself is the application that we wish to bind and so the per-algorithm Label is used as the ctx for the underlying ML-DSA primitive. Some implementations of the EdDSA component primitive can also expose a ctx parameter, but even if present, this is not used by Composite ML-DSA. 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, mldsa_ctx=Label ) then output "Invalid signature" if not Trad.Verify( tradPK, M', tradSig ) then output "Invalid signature" if all succeeded, then output "Valid signature" ]]> As with Composite-ML-DSA.Sign(), there are two different context strings ctx at play: the application context ctx and the mldsa-ctx which behave the same in verify() as they do in sign().

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 , which is similar to Table 2 from , but with a different private key representation. ML-DSA Sizes in bytes

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, standardized encodings exist for RSA keys as both a single private exponen d or in Chinese Remainder Theorem form Section A.1.2 of . 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 Appendix 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 Sections 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 X9.62 , including the leading byte 0x04 indicating uncompressed. This is consistent with the encoding of ECPoint as specified in Section 2.2 of when no ASN.1 OCTET STRING wrapping is present. 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 with the 'NamedCurve' parameter set to the OID of the curve, but without the 'publicKey' field.
• EdDSA: public key and signature MUST be encoded as per Section 3 of and the private key is a 32- or 57-byte raw value for Ed25519 and Ed448 respectively, which can be converted to a CurvePrivateKey specified in by the addition of an OCTET STRING wrapper.

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 zeros. 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 output of the appropriate serialization routine from without further encoding. 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 The intended application for the key is indicated in the keyUsage certificate extension; see . If the keyUsage extension is present in a certificate that includes an OID indicating a composite ML-DSA algorithm in the SubjectPublicKeyInfo, then the subject public key can only be used for verifying digital signatures on certificates or CRLs, or those used in an entity authentication service, a data origin authentication service, an integrity service, and/or a non-repudiation service that protects against the signing entity falsely denying some action. This means that the keyUsage extension MUST have at least one of the following bits set: ML-DSA subject public keys cannot be used to establish keys or encrypt data, so the keyUsage extension MUST NOT have any of following bits set: Requirements about the keyUsage extension bits defined in still apply. 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 according to their ASCII values prior to concatenating them with other byte values as described in .

• id-MLDSA44-RSA2048-PSS-SHA256
  • OID: 1.3.6.1.5.5.7.6.37
  • 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: 1.3.6.1.5.5.7.6.38
  • 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: 1.3.6.1.5.5.7.6.39
  • 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: 1.3.6.1.5.5.7.6.40
  • 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: 1.3.6.1.5.5.7.6.41
  • 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: 1.3.6.1.5.5.7.6.42
  • 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: 1.3.6.1.5.5.7.6.43
  • 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: 1.3.6.1.5.5.7.6.44
  • 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: 1.3.6.1.5.5.7.6.45
  • Label: COMPSIG-MLDSA65-ECDSA-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: 1.3.6.1.5.5.7.6.46
  • Label: COMPSIG-MLDSA65-ECDSA-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: 1.3.6.1.5.5.7.6.47
  • Label: COMPSIG-MLDSA65-ECDSA-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: 1.3.6.1.5.5.7.6.48
  • 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: 1.3.6.1.5.5.7.6.49
  • Label: COMPSIG-MLDSA87-ECDSA-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: 1.3.6.1.5.5.7.6.50
  • Label: COMPSIG-MLDSA87-ECDSA-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: 1.3.6.1.5.5.7.6.51
  • 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: 1.3.6.1.5.5.7.6.52
  • 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: 1.3.6.1.5.5.7.6.53
  • 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: 1.3.6.1.5.5.7.6.54
  • Label: COMPSIG-MLDSA87-ECDSA-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

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} SMIME-CAPS { IDENTIFIED BY id } } -- Composite ML-DSA id-MLDSA44-RSA2048-PSS-SHA256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 37 } 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 } id-MLDSA44-RSA2048-PKCS15-SHA256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 38 } 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 } id-MLDSA44-Ed25519-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 39 } 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 } id-MLDSA44-ECDSA-P256-SHA256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 40 } 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 } id-MLDSA65-RSA3072-PSS-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 41 } 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 } id-MLDSA65-RSA3072-PKCS15-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 42 } 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 } id-MLDSA65-RSA4096-PSS-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 43 } 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 } id-MLDSA65-RSA4096-PKCS15-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 44 } 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 } id-MLDSA65-ECDSA-P256-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 45 } 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 } id-MLDSA65-ECDSA-P384-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 46 } 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 } id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 47 } 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 } id-MLDSA65-Ed25519-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 48 } 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 } id-MLDSA87-ECDSA-P384-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 49 } 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 } id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 50 } 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 } id-MLDSA87-Ed448-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 51 } 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 } id-MLDSA87-RSA3072-PSS-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 52 } 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 } id-MLDSA87-RSA4096-PSS-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 53 } 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 } id-MLDSA87-ECDSA-P521-SHA512 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 54 } 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": Note to IANA / RPC: these were all early allocated on 2025-10-20, so they should all already be assigned to the values used above in and .

• 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 As this specification uses ML-DSA as a component of all composite algorithms, all security considerations from apply.

Why Hybrids? In broad terms, a PQ/T Hybrid can be used either to provide dual-algorithm security or to provide migration flexibility. Both are discussed below. 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 application 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 .

EUF-CMA, SUF-CMA and Non-Separability 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 security model consideration 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.

EUF-CMA A signature algorithm is Existentially Unforgeable under Chosen-Message Attack (EUF-CMA) if an adversary that has access to a signing oracle cannot create a message-signature pair (M, Sig) that would be accepted by the verifier for any message M that was not an input to a signing oracle query. In general, Composite ML-DSA will be EUF-CMA secure if at least one of the component algorithms is EUF-CMA secure and PH is collision resistant. Any algorithm that creates an existential forgery (M, (mldsaSig, tradSig)) for Composite ML-DSA can be converted into a pair of algorithms that will either create existential forgeries (M', mldsaSig) and (M', tradSig) for the component algorithms or a collision in PH. However, the nature of the EUF-CMA security guarantee can still change if one of the component algorithms is broken:

• If the traditional component is broken, then Composite ML-DSA will remain EUF-CMA secure against quantum adversaries.
• If ML-DSA is broken, then Composite ML-DSA will only be EUF-CMA secure against classical adversaries.

The same properties will hold for X.509 certificates that use Composite ML-DSA: a classical adversary cannot forge a Composite ML-DSA signed certificate if at least one component algorithm is classically EUF-CMA secure, and a quantum adversary cannot forge a Composite ML-DSA signed certificate if ML-DSA remains quantumly EUF-CMA secure.

SUF-CMA A signature algorithm is Strongly Unforgeable under Chosen-Message Attack (SUF-CMA) if an adversary that has access to a signing oracle cannot create a message-signature pair (M, Sig) that was not an output of a signing oracle query. This is a stronger property than EUF-CMA since the message M does not need to be different. SUF-CMA security is also more complicated for Composite ML-DSA than EUF-CMA. A SUF-CMA failure in one component algorithm can lead to a SUF-CMA failure in the composite. For example, an ECDSA signature can be trivially modified to produce a different signature that is still valid for the same message and this property passes directly through to Composite ML-DSA with ECDSA. Unfortunately, it is not generally sufficient for both component algorithms to be SUF-CMA secure. If repeated calls to the signing oracle produce two valid message-signature pairs (M, (mldsaSig1, tradSig1)) and (M, (mldsaSig2, tradSig2)) for the same message M, but where mldsaSig1 != mldsaSig2 and tradSig1 != tradSig2, then the adversary can construct a third pair (M, (mldsaSig1, tradSig2)) that will also be valid. Nevertheless, Composite ML-DSA will not be SUF-CMA secure, and Composite ML-DSA signed X.509 certificates will not be strongly unforgeable, against quantum adversaries since a quantum adversary will be able to break the SUF-CMA security of the traditional component. Consequently, applications where SUF-CMA security is critical SHOULD NOT use Composite ML-DSA.

Non-separability 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. Strong Non-Separability (SNS) is the stronger notion that an adversary cannot take a hybrid signature and produce a component signature, with a potentially different message, that will be accepted by the component verifier. Composite ML-DSA signs a message M by passing M' as defined in to the component signature primitives. Consider an adversary that takes a composite signature (M, (mldsaSig, tradSig)) and splits it into the component signatures (M', mldsaSig) and (M', tradSig). On the traditional side, (M', tradSig) will verify correctly, but the static Prefix defined in remains as evidence of the original composite. On the ML-DSA side, (M', mldsaSig) is signed with ML-DSA's context value equal to the composite algorithm's Label so will fail to verify under ML-DSA.Verify(M', ctx=""). Consequently, Composite ML-DSA will provide WNS for both components and a limited form of SNS for the ML-DSA component. It can achieve stronger non-separability in practice for both components if the prefix-based mitigation described in is applied. When used within X.509, the Label representing the signature algorithm is included in the signed object so if one of the component signatures is removed from the Composite ML-DSA signature then the signed-over Label will still indicate the composite algorithm, and this will fail at the X.509 processing layer. Composite ML-DSA therefore provides a version of SNS for X.509. The prohibition on key reuse between composite and single-algorithm contexts discussed in further strengthens the non-separability in practice.

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 so that the full implications of such a deviation can be considered. 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. But this reasoning does not hold in the PQ/T hybrid setting. Within the broader context of PQ/T hybrids, there are 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 applications 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.

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 in principle, straightforward. In the composite model this is less obvious since a PQ/T hybrid is expected to still be considered valid after the traditional component is deprecated for individual use. As such, a single composite public key or certificate may contain a mixture of deprecated and non-deprecated algorithms. In general this should be manageable through policy by removing OIDs for the standalone component algorithms while still allowing OIDs for composite algorithms. However, complications may arise when the composite implementation needs to invoke the cryptographic module for a deprecated component algorithm. In particular, this could lead to complex Cryptographic Bills of Materials that show implementations of deprecated algorithms still present and being used.

Operational Considerations

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 .

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 Deterministic Random Bit Generator (DRBG). 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 mechanisms specified in this document explicitly do not provide application backwards compatibility, only upgraded systems will understand the OIDs defined in this specification. If application 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 the following composite algorithm as it provides the best overall balance of performance and security: Below is listed 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. ]]>

Interoperability of legacy algorithms The legacy component algorithms, particularly RSA and ECDSA can themselves have interoperability issues which will propagate to become interoperability issues in the composite. For example, this specification RECOMMENDS an RSA exponent of 65537, but other values are possible. Implementations are encouraged to be lenient when parsing the key material of the legacy algorithm. In particilar, the recommendation is to use existing implementations of the legacy algorithms that already handle all the variation seen in the wild.

References Normative References This 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 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. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. 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 Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. This memo provides information for the Internet community. 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. This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912. 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. 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. n.d. Federal Office for Information Security (BSI) French Cybersecurity Agency (ANSSI) Federal Office for Information Security (BSI) Netherlands National Communications Security Agency (NLNCSA) Swedish National Communications Security Authority, Swedish Armed Forces n.d. European Parliament and Council n.d. CA/Browser Forum n.d. Nokia Nokia Nokia DigiCert Entrust Limited The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms.

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	64	2484
id-MLDSA44-ECDSA-P256-SHA256	1377	83	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	83	3381*
id-MLDSA65-ECDSA-P384-SHA512	2049	96	3413*
id-MLDSA65-ECDSA-brainpoolP256r1-SHA512	2017	84	3381*
id-MLDSA65-Ed25519-SHA512	1984	64	3373
id-MLDSA87-ECDSA-P384-SHA512	2689	96	4731*
id-MLDSA87-ECDSA-brainpoolP384r1-SHA512	2689	100	4731*
id-MLDSA87-Ed448-SHAKE256	2649	89	4741
id-MLDSA87-RSA3072-PSS-SHA512	2990*	1802*	5011
id-MLDSA87-RSA4096-PSS-SHA512	3118*	2383*	5139
id-MLDSA87-ECDSA-P521-SHA512	2725	114	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 it is suggested 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-ECDSA-P256-SHA512 len(ctx): 00 ctx: PH(M): 0f89ee1fcb7b0a4f7809d1267a029719004c5a5e5ec323a7c3523a20974f 9a3f202f56fadba4cd9e8d654ab9f2e96dc5c795ea176fa20ede8d854c342f90353 3 # Outputs: # M' = Prefix || Label || len(ctx) || ctx || PH(M) M': 436f6d706f73697465416c676f726974686d5369676e6174757265733230323 5434f4d505349472d4d4c44534136352d45434453412d503235362d534841353132 000f89ee1fcb7b0a4f7809d1267a029719004c5a5e5ec323a7c3523a20974f9a3f2 02f56fadba4cd9e8d654ab9f2e96dc5c795ea176fa20ede8d854c342f903533 ]]> 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." For all test vectors, a sample signature is provided computer over an empty ctx string, and also computed over the ctx string "The lethargic, colorless dog sat beneath the energetic, stationary fox.". Within each test case there are the following values:

• tcId the name of the algorithm.
• pk the raw 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 computed over m with an empty ctx string.
• sWithContext the signature value computed over m with the provided ctx string.

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.

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 Postgraduate School), Tim Hollebeek (Digicert), Panos Kampanakis (Amazon), Chris A. Wood (Apple), Christopher D. Wood (Apple), Sophie Schmieg (Google), Bas Westerbaan (Cloudflare), Chris Patton (Cloudflare), Deirdre Connolly (SandboxAQ), Richard Kisley (IBM), Piotr Popis (Enigma), François Rousseau, Falko Strenzke, Alexander Railean (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 to Dr. Hale along with Peter C and John Preuß Mattsson with analyzing the scheme with respect to EUF-CMA, SUF-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" - .