]> Huawei

lucas.prabel@huawei.com

Huawei

sunshuzhou@huawei.com

Entrust Limited

john.gray@entrust.com

Nokia

Bangalore Karnataka India kondtir@gmail.com

Security Javascript Object Signing and Encryption JOSE COSE PQC ML-DSA Signature Hybrid This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. 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 Javascript Object Signing and Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The impact of a potential Cryptographically Relevant Quantum Computer (CRQC) on algorithms whose security is based on mathematical problems such as integer factorisation or discrete logarithms over finite fields or elliptic curves raises the need for new algorithms that are perceived to be secure against CRQC as well as classical computers. Such algorithms are called post-quantum, while algorithms based on integer factorisation or discrete logarithms are called traditional. While switching from a traditional algorithm to a post-quantum one intends to strengthen the security against an adversary possessing a quantum computer, the lack of maturing time of post-quantum algorithms compared to traditional algorithms raises uncertainty about their security. Thus, the joint use of a traditional algorithm and a post-quantum algorithm in protocols represents a solution to this problem by providing security as long as at least one of the traditional or post-quantum components remains secure. This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component.

Conventions and Definitions 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. This document follows the terminology for post-quantum hybrid schemes defined in . This section recalls some of this terminology, but also adds other definitions used throughout the whole document: "Asymmetric Traditional Cryptographic Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. A related mathematical problem is one that can be solved by solving the integer factorisation, finite field discrete logarithm or elliptic curve discrete logarithm problem. Where there is little risk of confusion asymmetric traditional cryptographic algorithms can also be referred to as traditional algorithms for brevity. "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is intended to be secure against attacks using quantum computers as well as classical computers. As with all cryptography, it always remains the case that attacks, either quantum or classical, may be found against post-quantum algorithms. Therefore it should not be assumed that just because an algorithm is designed to provide post-quantum security it will not be compromised. "Post-Quantum Traditional (PQ/T) Hybrid Scheme": A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. "PQ/T Hybrid Digital Signature": A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm. "Composite Algorithm": An algorithm which is a sequence of two component algorithms, as defined in . "Component Algorithm": Each cryptographic algorithm that forms part of a cryptographic scheme.

Algorithm Key Pair (AKP) Type This document makes use of the Algorithm Key Pair (AKP) type which is defined in . As a reminder, the AKP type is used to express public and private keys for use with algorithms. The parameters for public and private keys contain byte strings. This document makes use of the serialization routines defined in to obtain the byte string encodings of the composite public and private keys. The process to compute JWK Thumbprint and COSE Key Thumbprint as described in and is detailed in .

Composite Signature Algorithm The structures of the composite keys and composite signatures follow an approach similar to . The composite design is chosen so that composite keys and signatures can be used as a drop-in replacement in JOSE / COSE object formats. This section gives some details about their construction.

Composite Key Generation Composite public and private keys are generated by calling the key generation functions of the two component algorithms and concatenating the keys in an order given by the registered composite algorithm. Composite Public Key <- Public Key of the 1st Algorithm || Public Key of the 2nd Algorithm and Composite Private Key <- Private Key of the 1st Algorithm || Private Key of the 2nd Algorithm For the composite algorithms described in this document (ML-DSA with ECDSA or EdDSA), the Key Generation process is as follows: (pk, sk) 1. Generate component keys mldsaSeed = Random(32) (mldsaPK, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed) (tradPK, tradSK) = Trad.KeyGen() 2. Check for component key generation failure if NOT (mldsaPK, mldsaSK) or NOT (tradPK, tradSK): output "Key generation error" 3. Serialize keys into composite form pk <- SerializePublicKey(mldsaPK, tradPK) sk <- SerializePrivateKey(mldsaSeed, tradSK) 4. Output the composite public and private keys return (pk, sk) ]]> As in , this keygen routine uses the seed-based ML-DSA.KeyGen_internal defined in Algorithm 6 of . This document makes use of the serialization routines from to obtain the byte string encodings of the composite public and private keys. These encodings are then directly used with the AKP Key Type. For more information, see the SerializePublicKey, DeserializePublicKey, SerializePrivateKey and DeserializePrivateKey algorithms from . Point compression for the ECDSA or EdDSA component is not performed for the AKP JSON Web Key Type but can be performed for the AKP COSE Key Type. In this document, as in , the ML-DSA private key MUST be a 32-bytes seed.

Composite Sign When signing a message M with the composite Sign algorithm, the signature combiner prepends a prefix as well as a label value specific to the composite algorithm used to bind the two component signatures to the composite algorithm and achieve weak non-separability, as defined in . However, only the pure ML-DSA component algorithm is used internally. A composite signature's value MUST include the two signature components and the two components MUST be in the same order as the components from the corresponding signing key. A composite signature for the message M is generated by:

• computing the pre-hash of the message M;
• concatenating the prefix, the label, a byte 0x00 and the pre-hash;
• encoding the resulting message;
• calling the two signature component algorithms on this new message;
• concatenating the two output signatures.

For the composite algorithms described in this document (ML-DSA with ECDSA or EdDSA), the signature process of a message M is as follows: s 1. Compute the Message representative M' M' <- Prefix || Label || 0x00 || PH(M) M' <- Encode(M') 2. Separate the private key sk into component keys and re-generate the ML-DSA key from seed (mldsaSeed, tradSK) = DeserializePrivateKey(sk) (_, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed) 3. Generate the two component signatures mldsaSig <- ML-DSA.Sign(mldsaSK, M', ctx=Label) tradSig <- Trad.Sign(tradSK, M') 4. 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" 5. Output the encoded composite signature value. s <- SerializeSignatureValue(mldsaSig, tradSig) return s ]]> The serialization routines from are again used to obtain the byte string encoding of the composite signature. The SerializeSignatureValue routine simply concatenates the fixed-length ML-DSA signature value and the signature value from the traditional algorithm. For more information, see the SerializeSignatureValue and DeserializeSignatureValue algorithms from . The prefix "Prefix" string is defined as in as the byte encoding of the string "CompositeAlgorithmSignatures2025", which in hex is 436F6D706F73697465416C676F726974686D5369676E61747572657332303235. It can be used by a traditional verifier to detect if the composite signature has been stripped apart. A signature label "Label" is defined in the same way as . It is specific to each composite algorithm. Additionally, the composite label is passed into the underlying ML-DSA primitive as the ctx. Signature Label values can be found in . Similarly to which indicates that the ctx parameter MUST be the empty string, the application context passed in to the composite signature algorithm MUST be the empty string. To align with the structure of the combiner, the byte 0x00 is appended in the message M' after the label to indicate the context has length 0. However, a second non-empty context, defined as the label, is passed down into the underlying pure ML-DSA component algorithm, to bind the Composite-ML-DSA algorithm used. (resp. ) indicates the pre-hash algorithms to use for JOSE (resp. COSE). For JOSE (resp. COSE), M' is base64url-encoded (resp. binary encoded) before signature computations.

Composite Verify The Verify algorithm MUST validate a signature only if all component signatures were successfully validated. The verification process of a signature sig is as follows:

• separate the composite public key into the component public keys;
• separate the composite signature into its 2 component signatures;
• compute the message M' from the message M whose signature is to be verified;
• encode the resulting message M';
• verify each component signature.

true or false 1. 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. 2. Compute the message representative M' M' <- Prefix || Label || 0x00 || PH(M) M' <- Encode(M') 3. Check each component signature individually, according to its algorithm specification. if NOT ML-DSA.Verify(mldsaPK, M', ctx=Label) output "Invalid signature" if NOT Trad.Verify(tradPK, M') output "Invalid signature" if all succeeded, then output "Valid signature" ]]> The DeserializePublicKey and DeserializeSignatureValue serialization routines from are used to get the component public keys and the component signatures. For more information, see the DeserializePublicKey and DeserializeSignatureValue algorithms from .

Encoding Rules In each combination, the byte streams of the keys and of the signatures are directly concatenated. Signature of the 1st Algorithm || Signature of the 2nd Algorithm Since all combinations presented in this document start with the ML-DSA algorithm and the key or signature sizes are fixed as defined in , it is unambiguous to encode or decode a composite key or signature. lists sizes of the three parameter sets of the ML-DSA algorithm. Sizes (in bytes) of keys and signatures of ML-DSA

	Private Key (seed)	Private Key	Public Key	Signature Size
ML-DSA-44	32	2560	1312	2420
ML-DSA-65	32	4032	1952	3309
ML-DSA-87	32	4896	2592	4627

Note that the seed is always 32 bytes, and that ML-DSA.KeyGen_internal from is called to produce the expanded private key from the seed, whose size corresponds to the sizes of the private key in the table above.

Composite Signature Instantiations The ML-DSA signature scheme supports three possible parameter sets, each of which corresponding to a specific security strength. See for more considerations on that matter. The traditional signature algorithm for each combination in and was chosen to match the security level of the ML-DSA post-quantum component. The specification defines both pure and pre-hash modes for ML-DSA, referred to as "ML-DSA" and "HashML-DSA" respectively. This document only specifies a single mode which is similar in construction to HashML-DSA. However, because the pre-hashing is done at the composite level, only the pure ML-DSA algorithm is used as the underlying ML-DSA primitive.

JOSE algorithms The following table defines a list of algorithms associated with specific PQ/T combinations to be registered in . JOSE Composite Signature Algorithms for ML-DSA

Name	First Algorithm	Second Algorithm	Pre-Hash	Description
ML-DSA-44-ES256	ML-DSA-44	ecdsa-with-SHA256 with secp256r1	SHA256	Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA256
ML-DSA-65-ES256	ML-DSA-65	ecdsa-with-SHA256 with secp256r1	SHA512	Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA256
ML-DSA-87-ES384	ML-DSA-87	ecdsa-with-SHA384 with secp384r1	SHA512	Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA384
ML-DSA-44-Ed25519	ML-DSA-44	Ed25519	SHA512	Composite Signature with ML-DSA-44 and Ed25519
ML-DSA-65-Ed25519	ML-DSA-65	Ed25519	SHA512	Composite Signature with ML-DSA-65 and Ed25519
ML-DSA-87-Ed448	ML-DSA-87	Ed448	SHAKE256	Composite Signature with ML-DSA-87 and Ed448

Examples can be found in .

COSE algorithms The following table defines a list of algorithms associated with specific PQ/T combinations to be registered in . COSE Composite Signature Algorithms for ML-DSA

Name	COSE Value	First Algorithm	Second Algorithm	Pre-Hash	Description
ML-DSA-44-ES256	TBD (request assignment -51)	ML-DSA-44	ecdsa-with-SHA256 with secp256r1	SHA256	Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA256
ML-DSA-65-ES256	TBD (request assignment -52)	ML-DSA-65	ecdsa-with-SHA256 with secp256r1	SHA512	Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA256
ML-DSA-87-ES384	TBD (request assignment -53)	ML-DSA-87	ecdsa-with-SHA384 with secp384r1	SHA512	Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA384
ML-DSA-44-Ed25519	TBD (request assignment -54)	ML-DSA-44	Ed25519	SHA512	Composite Signature with ML-DSA-44 and Ed25519
ML-DSA-65-Ed25519	TBD (request assignment -55)	ML-DSA-65	Ed25519	SHA512	Composite Signature with ML-DSA-65 and Ed25519
ML-DSA-87-Ed448	TBD (request assignment -56)	ML-DSA-87	Ed448	SHAKE256	Composite Signature with ML-DSA-87 and Ed448

Examples can be found in .

Composite Labels for JOSE and COSE The JOSE and COSE composite label values are listed in . They are represented here as ASCII strings, but implementers MUST convert them to byte strings using the obvious ASCII conversions prior to concatenating them with other byte values, as in . JOSE/COSE Composite Label Values

"alg" Header Parameter	Label (in ASCII)	Label (in Hex encoding)
ML-DSA-44-ES256	COMPSIG-MLDSA44-ECDSA-P256-SHA256	434F4D505349472D4D4C44534134342D45434453412D503235362D534841323536
ML-DSA-65-ES256	COMPSIG-MLDSA65-ECDSA-P256-SHA512	434F4D505349472D4D4C44534136352D45434453412D503235362D534841353132
ML-DSA-87-ES384	COMPSIG-MLDSA87-ECDSA-P384-SHA512	434F4D505349472D4D4C44534138372D45434453412D503338342D534841353132
ML-DSA-44-Ed25519	COMPSIG-MLDSA44-Ed25519-SHA512	434F4D505349472D4D4C44534134342D456432353531392D534841353132
ML-DSA-65-Ed25519	COMPSIG-MLDSA65-Ed25519-SHA512	434F4D505349472D4D4C44534136352D456432353531392D534841353132
ML-DSA-87-Ed448	COMPSIG-MLDSA87-Ed448-SHAKE256	434F4D505349472D4D4C44534138372D45643434382D5348414B45323536

Security Considerations The security considerations of the component algorithms (ML-DSA, ECDSA, and EdDSA) as described in , , and apply to this document. Similarly, the security considerations relative to the JWS, JWK, and COSE structures , and apply to this document. In addition, the following considerations specific to the composite design and its use in JOSE/COSE must be taken into account.

Hybrid Security and Quantum Resistance An important objective of Composite ML-DSA is to provide protection against CRQCs. Under a CRQC, traditional signature algorithms (RSA, ECDSA, and EdDSA) are vulnerable to private-key recovery, enabling attackers to forge arbitrary JWS objects or COSE_Sign/COSE_Sign1 structures and fully impersonate the signer. By requiring the successful verification of both the ML-DSA component and the traditional component, this construction ensures:

• Dual-Algorithm Security: An adversary that compromises only one of the component algorithms cannot produce cryptographically protected JOSE/COSE objects as long as the other component remains secure.
• Impersonation Prevention: In particular, this prevents JOSE/COSE signature spoofing and impersonation attacks even if the traditional signature component is compromised.
• EUF-CMA Security: The scheme provides existential unforgeability under chosen-message attack (EUF-CMA) provided that at least one component algorithm is EUF-CMA secure and the pre-hash function PH is collision-resistant. This is the case for all combinations present in this document.

Component Key Integrity and Reuse To maintain the security properties of the composite scheme, strict key management is required:

• No Key Reuse: To avoid key reuse, when generating a new composite key, the generation functions for both component algorithms MUST be executed. Moreover, compliant parties MUST NOT use, import, or export component keys that are used in other contexts, combinations, or as standalone keys.
• Certificate-Level Protection: The integrity of the composite public key is protected through mandatory validation of the certificate header (the x5c header in JOSE per or the x5chain header in COSE per ). Because the certificate itself is protected by a composite signature, an attacker cannot forge a fake certificate to swap a public key even if the traditional algorithm is broken. These specifications require the validation of the composite signature on the certificate itself.

Domain Separation and Non-Separability This document uses a signature combiner that prepends a fixed Prefix and a specific Label to the message representative M'.

• Non-separability: By binding the two component signatures to the specific composite algorithm, the composite scheme achieves "weak non-separability" as defined in .
• Cross-Algorithm Prevention: The unique label, specific to each composite algorithm, ensures that signatures cannot be removed from the composite and used in other contexts.

For more information about the security properties relative to the signature combiner, the user can read .

Security Objectives and Limitations In JOSE/COSE, the security objective of digital signatures is to ensure that only an authorized signer can produce a valid signature over a given protected header and payload. Therefore, users should be aware of specific scenarios where Composite ML-DSA may not be appropriate:

• SUF-CMA Security: While the construction is SUF-CMA secure against classical adversaries when paired with Ed25519 or Ed448, it is not SUF-CMA secure against quantum adversaries (who can break the traditional component). Consequently, applications for which SUF-CMA security is a strict requirement MUST NOT use Composite ML-DSA.
• Non-repudiation: Composite ML-DSA is not suitable for use cases that require non-repudiation or signature uniqueness guarantees. In the JOSE/COSE threat model described above, existential unforgeability under chosen-message attack (EUF-CMA) is sufficient to meet the intended security goals.
• Replay Protection: This is not handled by the signature itself but must be addressed through claims such as exp, nbf, and jti in JOSE () or the equivalent claims in COSE ().

IANA Considerations

JOSE Algorithms The following values of the JWS "alg" (algorithm) are requested to be added to the "JSON Web Signature and Encryption Algorithms" registry. They are represented following the registration template provided in .

ML-DSA-44-ES256

• Algorithm Name: ML-DSA-44-ES256
• Algorithm Description: Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA-256
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): n/a
• Algorithm Analysis Documents(s): TBD

ML-DSA-65-ES256

• Algorithm Name: ML-DSA-65-ES256
• Algorithm Description: Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA-256
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): n/a
• Algorithm Analysis Documents(s): TBD

ML-DSA-87-ES384

• Algorithm Name: ML-DSA-87-ES384
• Algorithm Description: Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA-384
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): n/a
• Algorithm Analysis Documents(s): TBD

ML-DSA-44-Ed25519

• Algorithm Name: ML-DSA-44-Ed25519
• Algorithm Description: Composite Signature with ML-DSA-44 and Ed25519 using SHA-512
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): n/a
• Algorithm Analysis Document(s): TBD

ML-DSA-65-Ed25519

• Algorithm Name: ML-DSA-65-Ed25519
• Algorithm Description: Composite Signature with ML-DSA-65 and Ed25519 using SHA-512
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): n/a
• Algorithm Analysis Document(s): TBD

ML-DSA-87-Ed448

• Algorithm Name: ML-DSA-87-Ed448
• Algorithm Description: Composite Signature with ML-DSA-87 and Ed448 using SHAKE-256
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): n/a
• Algorithm Analysis Document(s): TBD

COSE Algorithms The following values are requested to be added to the "COSE Algorithms" registry. They are represented following the registration template provided in , .

ML-DSA-44-ES256

• Name: ML-DSA-44-ES256
• Value: TBD (request assignment -51)
• Description: Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA-256
• Capabilities: [kty]
• Change Controller: IETF
• Reference: n/a
• Recommended: Yes

ML-DSA-65-ES256

• Name: ML-DSA-65-ES256
• Value: TBD (request assignment -52)
• Description: Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA-256
• Capabilities: [kty]
• Change Controller: IETF
• Reference: n/a
• Recommended: Yes

ML-DSA-87-ES384

• Name: ML-DSA-87-ES384
• Value: TBD (request assignment -53)
• Description: Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA-384
• Capabilities: [kty]
• Change Controller: IETF
• Reference: n/a
• Recommended: Yes

ML-DSA-44-Ed25519

• Name: ML-DSA-44-Ed25519
• Value: TBD (request assignment -54)
• Description: Composite Signature with ML-DSA-44 and Ed25519 using SHA-512
• Capabilities: [kty]
• Change Controller: IETF
• Reference: n/a
• Recommended: Yes

ML-DSA-65-Ed25519

• Name: ML-DSA-65-Ed25519
• Value: TBD (request assignment -55)
• Description: Composite Signature with ML-DSA-65 and Ed25519 using SHA-512
• Capabilities: [kty]
• Change Controller: IETF
• Reference: n/a
• Recommended: Yes

ML-DSA-87-Ed448

• Name: ML-DSA-87-Ed448
• Value: TBD (request assignment -56)
• Description: Composite Signature with ML-DSA-87 and Ed448 using SHAKE-256
• Capabilities: [kty]
• Change Controller: IETF
• Reference: n/a
• Recommended: Yes

References Normative References 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. 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. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. IANA n.d. IANA n.d. 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 Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST 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. Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where EUF-CMA-level security is acceptable. UK National Cyber Security Centre UK National Cyber Security Centre Naval Postgraduate School 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. Tradeverifyd Tradeverifyd This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204.

Examples

JOSE

ML-DSA-44-ES256

ML-DSA-44-Ed25519

ML-DSA-65-ES256

ML-DSA-65-Ed25519

ML-DSA-87-ES384

ML-DSA-87-Ed448

COSE

ML-DSA-44-ES256

ML-DSA-44-Ed25519

ML-DSA-65-ES256

ML-DSA-65-Ed25519

ML-DSA-87-ES384

ML-DSA-87-Ed448

Acknowledgments We thank Orie Steele for his valuable comments on this document.