]> Tradeverifyd

mprorock@mesur.io

Tradeverifyd

orie@or13.io

Security CBOR Object Signing and Encryption JOSE COSE PQC DILITHIUM ML-DSA This document describes 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 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 describes how to use ML-DSA keys and signatures as described in 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 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 describes 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. When registering new algorithms, use of multiple key type parameters for private information is NOT RECOMMENDED. Some algorithms might require or encourage additional structure or length checks for associated key type parameters. When AKP keys are expressed in JWK, key parameters are base64url encoded. When AKP keys are expressed as COSE keys, no encoding is needed. This document requests the registration of the following key types in : Algorithm Key Pair Type for JOSE

Name	kty	Description
Algorithm Key Pair	AKP	JSON Web Key Type for the Algorithm Key Pair.

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 requests the registration of the following key type in : Algorithm Key Pair Type for COSE

Name	kty	Description
AKP	TBD (requested assignment 7)	COSE Key Type for the Algorithm Key Pair.

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 FIPS 204 defines 2 expressions for private keys: a seed, and a private key that is expanded from the seed. Unlike , this document specifies ML-DSA private key information using only the seed. 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 NIST 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 FIPS-204. This document requests the registration of the following algorithms in : JOSE algorithms for ML-DSA

Name	value	Description
ML-DSA-44	ML-DSA-44	JSON Web Signature Algorithm for ML-DSA-44
ML-DSA-65	ML-DSA-65	JSON Web Signature Algorithm for ML-DSA-65
ML-DSA-87	ML-DSA-87	JSON Web Signature Algorithm for ML-DSA-87

This document requests the registration of the following algorithms in : COSE algorithms for ML-DSA

Name	value	Description
ML-DSA-44	TBD (requested assignment -48)	CBOR Object Signing Algorithm for ML-DSA-44
ML-DSA-65	TBD (requested assignment -49)	CBOR Object Signing Algorithm for ML-DSA-65
ML-DSA-87	TBD (requested assignment -50)	CBOR Object Signing Algorithm for ML-DSA-87

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 FIPS-204. The size of "pub", and the associated signature for each of these algorithms is defined in Table 2 of FIPS-204, 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 the ML-DSA Private Keys section of this document for more details. These algorithms are used to produce signatures as described in Algorithm 2 of FIPS-204. 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 FIPS-204. 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 FIPS-204 describes the ML-DSA key and signature sizes. ML-DSA might not be the best choice for use cases that require 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 describes 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.

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 FIPS-204. As the verify routines are different, future support for HashML-DSA would require the registration of additional algorithms. See for discussion regarding HashML-DSA in the context of certificates.

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 FIPS-204 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, only a 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. FIPS-204 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 templates are provided as described in RFC 9053 and RFC 9054.

ML-DSA-44

• Name: ML-DSA-44
• Value: TBD (requested assignment -48)
• Description: CBOR Object Signing Algorithm for ML-DSA-44
• Capabilities: [kty]
• 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]
• 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]
• 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)]
• 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 registration templates are provided as described in RFC 7518.

ML-DSA-44

• Algorithm Name: ML-DSA-44
• Algorithm Description: ML-DSA-44 as described in FIPS 204.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Value registry: Algorithms
• 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 FIPS 204.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Value registry: Algorithms
• 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 FIPS 204.
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Value registry: Algorithms
• 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 registration templates are provided as described in RFC 7518 and RFC 7638.

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 registration templates are provided as described in RFC 7517 and RFC 7638.

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 IANA IANA 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. 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. SECOM CO., LTD. University of Applied Sciences Bonn-Rhein-Sieg Transmute 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 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. n.d.

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