Internet-Draft | jose-cose-dilithium | December 2024 |
Prorock, et al. | Expires 21 June 2025 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://cose-wg.github.io/draft-ietf-cose-dilithium/draft-ietf-cose-dilithium.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/.¶
Discussion of this document takes place on the CBOR Object Signing and Encryption Working Group mailing list (mailto:cose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/cose/.¶
Source for this draft and an issue tracker can be found at https://github.com/cose-wg/draft-ietf-cose-dilithium.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 June 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes how to use ML-DSA keys and signatures as described in [FIPS-204] with JOSE and COSE.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Some examples in this specification are truncated using "..." for readability.¶
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. When this key type is used the "alg" JSON Web Key Parameter or COSE Key Common Parameter is REQUIRED.¶
The "pub" parameter contains a public key, this parameter contains public information. The "priv" parameter contains a private key, sometimes called a secret key, this parameter contains private information. The concept of public and private information classes originates from Section 8.1 of [RFC7517].¶
The "pub" and "priv" parameters contain byte strings in a format specified by the "alg" value. The values of "pub" and "priv" MAY have additional structure or length checks depending on the associated "alg" parameter and its requirements.¶
When AKP keys are expressed in JWK, "pub" and "priv" are base64url encoded.¶
This document requests the registration of the following key types in [IANA.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:¶
This document requests the registration of the following key type in [IANA.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 AKP key type and thumbprint computation for the AKP key type is generic, and suitable for use with algorithms other than ML-DSA.¶
Note that FIPS 204 defines 2 expressions for private keys: a seed, and a private key that is expanded from the seed. For the algorithms defined in this document, the "priv" parameter is always the seed, and never the expanded expression. This definition mirrors the one used in Section 6 of [I-D.draft-ietf-lamps-dilithium-certificates].¶
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 [IANA.jose]:¶
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 [IANA.cose]:¶
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, when present in AKP Keys the "pub" and "priv" 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:¶
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 private key sizes 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 th 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 computing the COSE Key Thumbprint as described in [I-D.draft-ietf-cose-key-thumbprint], 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 Section 3 of [I-D.draft-ietf-cose-key-thumbprint].¶
When computing the JWK Thumbprint as described in [RFC7638], the required parameters for algorithm key pairs are:¶
Their lexicographic order, per Section 3.3 of [RFC7638], is:¶
The JWK Key Thumbprint is produced according to the process described in Section 3 of [RFC7638].¶
See the kid
values in the JSON Web Key and COSE Key examples in the appendix for examples of AKP thumbprints.¶
The security considerations of [RFC7515], [RFC7517] and [RFC9053] applies to this specification as well.¶
A detailed security analysis of ML-DSA is beyond the scope of this specification, see [FIPS-204] for additional details.¶
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 [RFC7638] and [I-D.draft-ietf-cose-key-thumbprint] can reduce the need to repeat public key representations.¶
This document does not specify algorithms for use with HashML-DSA as described in Section 5.4 of FIPS-204.¶
When an AKP algorithm requires or encourages that a key be validated before being used, the "pub" and "priv" 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 "priv" 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 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".¶
When using an AKP key with an algorithm, it is possible that the "pub" and "priv" 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 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
We would like to thank Simo Sorce, Ilari Liusvaara, Neil Madden, Anders Rundgren, David Waite, Russ Housley, and Lucas Prabel for their comments and reviews of this document.¶