]> Tradeverifyd

mprorock@mesur.io

Tradeverifyd

orie@or13.io

Security CBOR Object Signing and Encryption JOSE COSE PQC DILITHIUM ML-DSA 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. 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 CBOR 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 This document specifies how to use ML-DSA keys and signatures as described in , in conjunction with JOSE and COSE. A new key type named Algorithm Key Pair (AKP) is defined to express public and private keys for use with algorithms not limited to those registered in this document. Similarly, a new thumbprint algorithm is defined for AKP, to ensure these keys can be compared according to the procedures defined in 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. Some examples in this specification are truncated using "..." for readability.

Algorithm Key Pair Type This section specifies a generic cryptographic key structure for use with algorithms not limited to those registered in this document. The Algorithm Key Pair (AKP) Type is used to express Public and Private Keys for use with Algorithms. The concept of public and private information classes for key pairs originates from . The parameters for public and private information classes contain byte strings in a format specified by the alg value. The alg JSON Web Key Parameter or COSE Key Common Parameter is REQUIRED for all AKP keys. The pub parameter contains public information and is REQUIRED. The priv parameter contains private information and MUST NOT be present in public keys. Some algorithms may require or recommend additional structure or length checks for associated key type parameters. When AKP keys are expressed as JSON Web Keys (JWK), the key parameters are base64url encoded. When AKP keys are expressed as COSE keys, no encoding is needed. This document introduces the AKP key type in : An example truncated private key for use with ML-DSA-44 in JWK format is provided below:

The all-zeros ML-DSA-44 JSON Web Key

This document introduces the AKP key type in : An example truncated private key for use with ML-DSA-44 in COSE_Key format is provided below:

The all-zeros ML-DSA-44 COSE Key

ML-DSA Private Keys Note that US NIST defines 2 expressions for private keys: a seed, and a private key that is expanded from the seed. Unlike , which supports the expanded private key format to maximize interoperability with existing implementations, this document specifies ML-DSA private key information using only the seed format. The seed format was chosen to provide a single, compact representation that is consistent across both COSE and JOSE, simplifying key management and reducing storage requirements. For the ML-DSA private keys described in this document, the priv parameter MUST be the seed, and MUST have a length of 32 bytes. This specification intentionally does not define a means of utilizing the expanded private key representation defined by US NIST FIPS so as to increase interoperability by having a single ML-DSA private key representation for COSE and JOSE. See Security Considerations of this document for details.

ML-DSA Algorithms The ML-DSA Signature Scheme is parameterized to support different security levels. In this document, the abbreviations ML-DSA-44, ML-DSA-65, and ML-DSA-87 are used to refer to ML-DSA with the parameter choices given in Table 1 of . This document has registered the ML-DSA-44, ML-DSA-65, and ML-DSA-87 algorithms in and . In accordance with Algorithm Key Pair Type section of this document, ML-DSA key parameters have the following additional constraints: The pub parameter is the ML-DSA public key, as described in Section 5.3 of US NIST . The size of pub, and the associated signature for each of these algorithms is defined in Table 2 of US NIST , and repeated here for convenience: Sizes (in bytes) of keys and signatures of ML-DSA

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

Note that priv size is always 32 bytes, and that KeyGen_internal is called to produce the expanded private keys for "Private Key" in the table above. See Section 4, ML-DSA Private Keys, for further details. These algorithms are used to produce signatures as described in Algorithm 2 of US NIST . The ctx parameter MUST be the empty string for ML-DSA-44, ML-DSA-65 and ML-DSA-87. Signatures are encoded as bytestrings using the algorithms defined in Section 7.2 of US NIST . When producing JSON Web Signatures, the signature bytestrings are base64url encoded, and the encoded signature size is larger than described in the table above. When producing COSE signatures, no encoding is needed; see for more details on how COSE signatures are created. Table 2 of describes the ML-DSA key and signature sizes. ML-DSA produces significantly larger public keys and signatures compared to traditional algorithms. This size increase can create challenges for deployments with limited bandwidth, memory, or processing capacity. ML-DSA may not be suitable for use cases requiring small keys or signatures. Use of thumbprints as described in and can reduce the need to repeat public key representations.

AKP Thumbprints Although this document specifies how to represent ML-DSA keys using AKP, the AKP key type and thumbprint computations are suitable for use with algorithms other than ML-DSA. When computing the COSE Key Thumbprint as described in , the required parameters for algorithm key pairs are:

• "kty" (label: 1, data type: int, value: 7)
• "alg" (label: 3, data type: int, value: int)
• "pub" (label: -1, value: bstr)

The COSE Key Thumbprint is produced according to the process described in . When computing the JWK Thumbprint as described in , the required parameters for algorithm key pairs are:

• "kty"
• "alg"
• "pub"

Their lexicographic order, per , is:

• "alg"
• "kty"
• "pub"

The JWK Key Thumbprint is produced according to the process described in . See the kid values in the JSON Web Key and COSE Key examples in the appendix for examples of AKP thumbprints.

Security Considerations The security considerations of , , and apply to this specification as well. A detailed security analysis of ML-DSA is beyond the scope of this specification; see for additional details. Implementers should also refer to the security considerations in for additional guidance on ML-DSA deployment considerations, including discussions on randomized versus deterministic signing approaches.

Private key compromise The seed and the private key expanded from the seed require the same level of protection. If an unauthorized party obtains the seed, or the expanded private key, they can forge signatures. This undermines the authenticity and integrity guarantees provided by ML-DSA, as attackers could impersonate the legitimate signer or alter signed data without detection.

Rationale for not supporting HashML-DSA This document does not specify algorithms for use with HashML-DSA as described in Section 5.4 of . As the verify routines are different, future support for HashML-DSA would require the registration of additional algorithms. explains the rationale for disallowing HashML-DSA, including the increased complexity and compatibility concerns with existing implementations.

Validation of keys When an AKP algorithm requires or encourages that a key be validated before being used, all algorithm-related key parameters MUST be validated. Section 7.2 of describes the encoding of ML-DSA keys and signatures. For Algorithms 22 and 23 (pkEncode and pkDecode), the inputs need to be within the ranges given in the algorithms. For the ML-DSA algorithms registered in this document, the priv key parameter is the seed, and therefore, the seed length check MUST be performed. The length of the seed is 256 bits, which is 32 bytes. However, when the priv parameter is expanded using KeyGen_internal, the skEncode and skDecode algorithms MUST be used. notes, "skDecode should only be run on inputs that come from trusted sources" and that "as the seed can be used to compute the private key, it is sensitive data and shall be treated with the same safeguards as a private key".

Mismatched AKP parameters When using an AKP key with an algorithm, it is possible that the public and private information class parameters have been tampered with or mismatched. Depending on the algorithm and implementation, the consequences of using mismatched parameters can range from operations failing to private key compromise.

IANA Considerations

Additions to Existing Registries

New COSE Algorithms IANA is requested to add the following entries to the COSE Algorithms Registry. The following completed registration actions are provided as described in and .

ML-DSA-44

• Name: ML-DSA-44
• Value: TBD (requested assignment -48)
• Description: CBOR Object Signing Algorithm for ML-DSA-44
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: Yes

ML-DSA-65

• Name: ML-DSA-65
• Value: TBD (requested assignment -49)
• Description: CBOR Object Signing Algorithm for ML-DSA-65
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: Yes

ML-DSA-87

• Name: ML-DSA-87
• Value: TBD (requested assignment -50)
• Description: CBOR Object Signing Algorithm for ML-DSA-87
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: Yes

New COSE Key Types IANA is requested to add the following entries to the COSE Key Types Registry. The following completed registration templates are provided as described in RFC 9053.

AKP

• Name: AKP
• Value: TBD (requested assignment 7)
• Description: COSE Key Type for Algorithm Key Pairs
• Capabilities: [kty(7)]
• Change Controller: IETF
• Reference: RFC XXXX

New COSE Key Type Parameters IANA is requested to add the following entries to the COSE Key Type Parameters. The following completed registration templates are provided as described in RFC 9053.

AKP Public Key

• Key Type: TBD (requested assignment 7)
• Name: pub
• Label: -1
• CBOR Type: bstr
• Description: Public key
• Reference: RFC XXXX

AKP Private Key

• Key Type: TBD (requested assignment 7)
• Name: priv
• Label: -2
• CBOR Type: bstr
• Description: Private key
• Reference: RFC XXXX

New JOSE Algorithms IANA is requested to add the following entries to the JSON Web Signature and Encryption Algorithms Registry. The following completed registrations are provided as described in .

ML-DSA-44

• Algorithm Name: ML-DSA-44
• Algorithm Description: ML-DSA-44 as described in US NIST FIPS 204.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

ML-DSA-65

• Algorithm Name: ML-DSA-65
• Algorithm Description: ML-DSA-65 as described in US NIST FIPS 204.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

ML-DSA-87

• Algorithm Name: ML-DSA-87
• Algorithm Description: ML-DSA-87 as described in US NIST FIPS 204.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

New JOSE Key Types IANA is requested to add the following entries to the JSON Web Key Types Registry. The following completed registrations are provided as described in and .

AKP

• "kty" Parameter Value: AKP
• Key Type Description: Algorithm Key Pair
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX

New JSON Web Key Parameters IANA is requested to add the following entries to the JSON Web Key Parameters Registry. The following completed registrations are provided as described in and .

AKP Public Key

• Parameter Name: pub
• Parameter Description: Public key
• Used with "kty" Value(s): AKP
• Parameter Information Class: Public
• Change Controller: IETF
• Specification Document(s): RFC XXXX

AKP Private Key

• Parameter Name: priv
• Parameter Description: Private key
• Used with "kty" Value(s): AKP
• Parameter Information Class: Private
• Change Controller: IETF
• Specification Document(s): RFC XXXX

References Normative References 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. 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 the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. 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. 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. n.d. 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 IANA IANA AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, 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 certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described.

Examples

JOSE

ML_DSA_44

ML_DSA_65

ML_DSA_87

COSE

ML_DSA_44

ML_DSA_65

ML_DSA_87

Acknowledgments We would like to thank Simo Sorce, Ilari Liusvaara, Neil Madden, Anders Rundgren, David Waite, Russ Housley, Filip Skokan, Peter Yee, and Lucas Prabel for their comments and reviews of this document.

Contributors Google

rafaelmisoczki@google.com

IBM

osb@zurich.ibm.com

NXP

christine.cloostermans@nxp.com