]> mesur.io

mprorock@mesur.io

Transmute

orie@transmute.industries

Google

rafaelmisoczki@google.com

IBM

osb@zurich.ibm.com

NXP

christine.cloostermans@nxp.com

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.

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. Some algorithm specifications, such as ML-DSA, might allow for use of multiple key type parameters for private information. When registering new algorithms, use of multiple key type parameters for private information is NOT RECOMMENDED. The "seed" parameter contains private information and MUST NOT be present in public keys. If the associated "alg" value does not define seed expansion, then "seed" parameter MUST NOT be present, and the "priv" parameter is used for the private key, if present. If both "seed" and "priv" parameters are present, then the seed in "seed" parameter MUST expand to the key in "priv" parameter following the seed expansion procedure for the associated "alg" value. Whether "seed" is allowed, and how it is related to "pub" and "priv" is algorithm specific and needs to be described as part of specifying the use of AKP for a given algorithm, see below for an example of how this is done for ML-DSA. 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. 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

The AKP key type and thumbprint computations are generic, and suitable for use with algorithms other than ML-DSA.

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. Similar to the following cases are possible:

1. Only the "seed" parameter is present.
2. Only the "priv" parameter is present.
3. Both parameters are present.

When "seed" is present, it MUST have a length of 32 bytes. When both "seed" and "priv" are present, the "seed" parameter MUST expand to the "priv" parameter. When "priv" is present, "seed" SHOULD be present to enable validation of the private key expansion process. Validation and expansion of private keys might be skipped in constrained environments. See Security Considerations of this document for details. Here is an elided example of the case where both "seed" and "priv" are present:

The all zeros ML-DSA-44 JSON Web Key with both seed and priv parameters

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 "seed" size is always 32 bytes, and that KeyGen_internal is called to produce the private key sizes for "priv" 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.

AKP Thumbprints 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 applies to this specification as well. A detailed security analysis of ML-DSA is beyond the scope of this specification, see for additional details.

Size of keys and signatures Table 2 of FIPS-204 describes the size of keys and signatures. 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.

Regarding HashML-DSA This document does not specify algorithms for use with HashML-DSA as described in Section 5.4 of FIPS-204.

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. The "pub" key parameter MUST be validated according to the pkEncode and pkDecode algorithms before being used. For the ML-DSA algorithms registered in this document, the "seed" key parameter is a seed, and as such only a length check MUST be performed. The length of the seed is 256 bits, which is 32 bytes. However, if the private key ("priv") is derived from the seed using KeyGen_internal is stored as part of some implementation, 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 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 RFC9053 and RFC9054.

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 RFC9053.

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 RFC9053.

AKP Seed

• Key Type: TBD (requested assignment 7)
• Name: seed
• Label: -3
• CBOR Type: bstr
• Description: Seed used to derive keys for an algorithm
• Reference: RFC XXXX

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 RFC7518.

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 RFC7518 RFC7638.

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 RFC7517, and RFC7638.

AKP Seed

• Parameter Name: seed
• Parameter Description: Seed used to derive keys for an algorithm
• Used with "kty" Value(s): AKP
• Parameter Information Class: Private
• Change Controller: IETF
• Specification Document(s): RFC XXXX

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 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. 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 describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. n.d. 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, and Lucas Prabel for their comments and reviews of this document.