ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)
Extracted elements (24)
HashML-DSA (FIPS 204 Section 5.4) is not specified because its verify routines differ from pure ML-DSA, requiring additional algorithm registrations, and RFC 9881 Section 8.3 notes the increased complexity and compatibility concerns with existing implementations.
The AKP key type is intentionally generic, designed for use with algorithms beyond ML-DSA. AKP thumbprint computations are similarly suitable for any algorithm registered under the AKP key type.
This document specifies ML-DSA private keys using only the seed format (not the expanded private key format supported by RFC 9881) to provide a single, compact representation consistent across both COSE and JOSE, simplifying key management and reducing storage requirements.
ML-DSA produces significantly larger public keys and signatures compared to traditional algorithms (e.g., ML-DSA-87 public key is 2592 bytes, signature 4627 bytes). This may make ML-DSA unsuitable for deployments with limited bandwidth, memory, or processing capacity. Use of thumbprints per RFC 7638 and RFC 9679 can reduce the need to repeat public key representations.
Unlike RFC 9881 (X.509 ML-DSA), which supports the expanded private key format to maximize interoperability with existing implementations, this document uses only the seed format. Implementations interoperating with RFC 9881-based systems must handle the difference in private key representation.
For ML-DSA private keys, the priv parameter MUST be the seed and MUST have a length of 32 bytes. The expanded private key representation from FIPS 204 is intentionally not defined in order to maintain a single representation across COSE and JOSE.
The alg JWK parameter or COSE Key Common parameter is REQUIRED for all AKP keys.
The ctx parameter MUST be the empty string for ML-DSA-44, ML-DSA-65, and ML-DSA-87.
The priv parameter MUST NOT be present in public keys.
The pub parameter contains public information and is REQUIRED for AKP keys.
When an AKP algorithm requires or encourages key validation, all algorithm-related key parameters MUST be validated. For ML-DSA, the seed length check MUST be performed (256 bits / 32 bytes).
When the expanded priv parameter is used via KeyGen_internal, the skEncode and skDecode algorithms from FIPS 204 MUST be used.
AKP COSE Key Thumbprint requires kty (label 1, value 7), alg (label 3, int), and pub (label -1, bstr) as required parameters, computed per RFC 9679 Section 3. AKP JWK Thumbprint requires kty, alg, and pub in lexicographic order (alg, kty, pub), computed per RFC 7638 Section 3.
The Algorithm Key Pair (AKP) key type is a generic cryptographic key structure for expressing public and private keys for use with algorithms. It uses an 'alg' parameter to indicate the algorithm, a 'pub' parameter for public information, and an optional 'priv' parameter for private information. When expressed as JWKs, parameters are base64url encoded; in COSE keys, no encoding is needed.
Three ML-DSA parameter sets are defined: ML-DSA-44 (public key 1312 bytes, signature 2420 bytes), ML-DSA-65 (public key 1952 bytes, signature 3309 bytes), ML-DSA-87 (public key 2592 bytes, signature 4627 bytes). The priv seed is always 32 bytes regardless of parameter set.
New entry in the IANA 'COSE Key Types' registry: AKP with value 7, capabilities [kty(7)], for Algorithm Key Pairs.
New entry in the IANA 'JSON Web Key Types' registry: AKP (Algorithm Key Pair) with JOSE Implementation Requirements 'Optional'.
Three new entries added to the IANA 'COSE Algorithms' registry: ML-DSA-44 (value -48), ML-DSA-65 (value -49), and ML-DSA-87 (value -50), each with capabilities [kty] and Recommended: Yes.
Three new entries in the IANA 'JSON Web Signature and Encryption Algorithms' registry: ML-DSA-44, ML-DSA-65, ML-DSA-87, all with Algorithm Usage Location 'alg' and JOSE Implementation Requirements 'Optional'.
Two new entries in the IANA 'COSE Key Type Parameters' registry for key type 7 (AKP): pub (label -1, CBOR type bstr, public key) and priv (label -2, CBOR type bstr, private key).
Two new entries in the IANA 'JSON Web Key Parameters' registry for kty AKP: pub (Public information class) and priv (Private information class).
The ML-DSA seed and the private key expanded from the seed require the same level of protection. If an unauthorized party obtains the seed, they can forge signatures, undermining authenticity and integrity guarantees.
When using an AKP key with an algorithm, mismatched or tampered public and private information class parameters can range in consequence from operation failure to private key compromise depending on the algorithm and implementation.
When producing JSON Web Signatures, ML-DSA signature byte strings are base64url encoded, making the encoded signature larger than the raw byte sizes in Table 1. When producing COSE signatures, no encoding is needed; signatures are raw byte strings per RFC 9052 Section 4.