rfc9964.original   rfc9964.txt 
CBOR Object Signing and Encryption M. Prorock Internet Engineering Task Force (IETF) M. Prorock
Internet-Draft O. Steele Request for Comments: 9964 O. Steele
Intended status: Standards Track Tradeverifyd Category: Standards Track Tradeverifyd
Expires: 19 May 2026 15 November 2025 ISSN: 2070-1721 April 2026
ML-DSA for JOSE and COSE ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object
draft-ietf-cose-dilithium-11 Signing and Encryption (COSE)
Abstract Abstract
This document specifies JSON Object Signing and Encryption (JOSE) and This document specifies JSON Object Signing and Encryption (JOSE) and
CBOR Object Signing and Encryption (COSE) serializations for Module- CBOR Object Signing and Encryption (COSE) serializations for the
Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-
Cryptography (PQC) digital signature scheme defined in US NIST FIPS Quantum Cryptography (PQC) digital signature scheme defined in US
204. NIST FIPS 204.
About This Document
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9964.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 May 2026.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Algorithm Key Pair Type . . . . . . . . . . . . . . . . . . . 3 3. AKP Type
4. ML-DSA Private Keys . . . . . . . . . . . . . . . . . . . . . 4 4. ML-DSA Private Keys
5. ML-DSA Algorithms . . . . . . . . . . . . . . . . . . . . . . 5 5. ML-DSA Algorithms
6. AKP Thumbprints . . . . . . . . . . . . . . . . . . . . . . . 6 6. AKP Thumbprints
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations
7.1. Private key compromise . . . . . . . . . . . . . . . . . 7 7.1. Private Key Compromise
7.2. Rationale for not supporting HashML-DSA . . . . . . . . . 7 7.2. Rationale for Not Supporting HashML-DSA
7.3. Validation of keys . . . . . . . . . . . . . . . . . . . 7 7.3. Validation of Keys
7.4. Mismatched AKP parameters . . . . . . . . . . . . . . . . 8 7.4. Mismatched AKP Parameters
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations
8.1. Additions to Existing Registries . . . . . . . . . . . . 8 8.1. Additions to Existing Registries
8.1.1. New COSE Algorithms . . . . . . . . . . . . . . . . . 8 8.1.1. New COSE Algorithms
8.1.2. New COSE Key Types . . . . . . . . . . . . . . . . . 9 8.1.2. New COSE Key Types
8.1.3. New COSE Key Type Parameters . . . . . . . . . . . . 10 8.1.3. New COSE Key Type Parameters
8.1.4. New JOSE Algorithms . . . . . . . . . . . . . . . . . 10 8.1.4. New JOSE Algorithms
8.1.5. New JOSE Key Types . . . . . . . . . . . . . . . . . 12 8.1.5. New JOSE Key Types
8.1.6. New JSON Web Key Parameters . . . . . . . . . . . . . 12 8.1.6. New JWK Parameters
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Examples
A.1. JOSE . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.1. JOSE
A.2. COSE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.2. COSE
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses
1. Introduction 1. Introduction
This document specifies how to use ML-DSA keys and signatures as This document specifies how to use ML-DSA keys and signatures as
described in [FIPS-204], in conjunction with JOSE and COSE. A new described in [FIPS-204] in conjunction with JOSE and COSE. A new key
key type named Algorithm Key Pair (AKP) is defined to express public type named Algorithm Key Pair (AKP) is defined to express public and
and private keys for use with algorithms not limited to those private keys for use with algorithms not limited to those registered
registered in this document. Similarly, a new thumbprint algorithm in this document. Similarly, a new thumbprint algorithm is defined
is defined for AKP, to ensure these keys can be compared according to for AKP to ensure these keys can be compared according to the
the procedures defined in [RFC7638] and [RFC9679]. procedures defined in [RFC7638] and [RFC9679].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Some examples in this specification are truncated using "..." for Some examples in this specification are truncated using "..." for
readability. readability.
3. Algorithm Key Pair Type 3. AKP Type
This section specifies a generic cryptographic key structure for use This section specifies a generic cryptographic key structure for use
with algorithms not limited to those registered in this document. with algorithms not limited to those registered in this document.
The Algorithm Key Pair (AKP) Type is used to express Public and The Algorithm Key Pair (AKP) type is used to express public and
Private Keys for use with Algorithms. The concept of public and private keys for use with algorithms. The concept of public and
private information classes for key pairs originates from Section 8.1 private information classes for key pairs originates from Section 8.1
of [RFC7517]. The parameters for public and private information of [RFC7517]. The parameters for public and private information
classes contain byte strings in a format specified by the alg value. classes contain byte strings in a format specified by the alg value.
The alg JSON Web Key Parameter or COSE Key Common Parameter is The alg JSON Web Key (JWK) parameter or COSE Key Common parameter is
REQUIRED for all AKP keys. The pub parameter contains public REQUIRED for all AKP keys. The pub parameter contains public
information and is REQUIRED. The priv parameter contains private information and is REQUIRED. The priv parameter contains private
information and MUST NOT be present in public keys. Some algorithms information and MUST NOT be present in public keys. Some algorithms
may require or recommend additional structure or length checks for may require or recommend additional structure or length checks for
associated key type parameters. associated key type parameters.
When AKP keys are expressed as JSON Web Keys (JWK), the key When AKP keys are expressed as JWKs, the key parameters are base64url
parameters are base64url encoded. When AKP keys are expressed as encoded. When AKP keys are expressed as COSE keys, no encoding is
COSE keys, no encoding is needed. needed.
This document introduces the AKP key type in [IANA.jose]: This document introduces the AKP key type in [IANA.jose]:
An example truncated private key for use with ML-DSA-44 in JWK format An example truncated private key for use with ML-DSA-44 in JWK format
is provided below: is provided below:
{ {
"kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o", "kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o",
"kty": "AKP", "kty": "AKP",
"alg": "ML-DSA-44", "alg": "ML-DSA-44",
"pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ", "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ",
"priv": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" "priv": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
} }
Figure 1: The all-zeros ML-DSA-44 JSON Web Key Figure 1: The All-Zeros ML-DSA-44 JWK
This document introduces the AKP key type in [IANA.cose]: This document introduces the AKP key type in [IANA.cose]:
An example truncated private key for use with ML-DSA-44 in COSE_Key An example truncated private key for use with ML-DSA-44 in COSE_Key
format is provided below: format is provided below:
{ {
/ kid / 2: h'b8969ab4b37da9f068...6f0583bf5b8d3a8059a', / kid / 2: h'b8969ab4b37da9f068...6f0583bf5b8d3a8059a',
/ kty / 1: 7, / AKP / / kty / 1: 7, / AKP /
/ alg / 3: -48, / ML-DSA-44 / / alg / 3: -48, / ML-DSA-44 /
/ pub / -1: h'ba71f9f64e11baeb589...3830546b9dd8db0d', / pub / -1: h'ba71f9f64e11baeb589...3830546b9dd8db0d',
/ priv / -2: h'00000000000000...0000000000000000' / priv / -2: h'00000000000000...0000000000000000'
} }
Figure 2: The all-zeros ML-DSA-44 COSE Key Figure 2: The All-Zeros ML-DSA-44 COSE Key
4. ML-DSA Private Keys 4. ML-DSA Private Keys
Note that US NIST [FIPS-204] defines 2 expressions for private keys: Note that US NIST [FIPS-204] defines 2 expressions for private keys:
a seed, and a private key that is expanded from the seed. a seed, and a private key that is expanded from the seed.
Unlike [I-D.draft-ietf-lamps-dilithium-certificates], which supports Unlike [RFC9881], which supports the expanded private key format to
the expanded private key format to maximize interoperability with maximize interoperability with existing implementations, this
existing implementations, this document specifies ML-DSA private key document specifies ML-DSA private key information using only the seed
information using only the seed format. The seed format was chosen format. The seed format was chosen to provide a single, compact
to provide a single, compact representation that is consistent across representation that is consistent across both COSE and JOSE,
both COSE and JOSE, simplifying key management and reducing storage simplifying key management and reducing storage requirements.
requirements.
For the ML-DSA private keys described in this document, the priv 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. parameter MUST be the seed and MUST have a length of 32 bytes.
This specification intentionally does not define a means of utilizing This specification intentionally does not define a means of utilizing
the expanded private key representation defined by US NIST FIPS so as the expanded private key representation defined by US NIST FIPS so as
to increase interoperability by having a single ML-DSA private key to increase interoperability by having a single ML-DSA private key
representation for COSE and JOSE. representation for COSE and JOSE.
See Security Considerations of this document for details. See the Security Considerations of this document for details.
5. ML-DSA Algorithms 5. ML-DSA Algorithms
The ML-DSA Signature Scheme is parameterized to support different The ML-DSA Signature Scheme is parameterized to support different
security levels. security levels.
In this document, the abbreviations ML-DSA-44, ML-DSA-65, and ML- 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 DSA-87 are used to refer to ML-DSA with the parameter choices given
in Table 1 of [FIPS-204]. in Table 1 of [FIPS-204].
This document has registered the ML-DSA-44, ML-DSA-65, and ML-DSA-87 This document has registered the ML-DSA-44, ML-DSA-65, and ML-DSA-87
algorithms in [IANA.jose] and [IANA.cose]. algorithms in [IANA.jose] and [IANA.cose].
In accordance with Algorithm Key Pair Type section of this document, In accordance with Section 3 of this document, ML-DSA key parameters
ML-DSA key parameters have the following additional constraints: have the following additional constraints:
The pub parameter is the ML-DSA public key, as described in The pub parameter is the ML-DSA public key as described in
Section 5.3 of US NIST [FIPS-204]. Section 5.3 of US NIST [FIPS-204].
The size of pub, and the associated signature for each of these The size of pub and the associated signature for each of these
algorithms is defined in Table 2 of US NIST [FIPS-204], and repeated algorithms is defined in Table 2 of US NIST [FIPS-204] and repeated
here for convenience: here for convenience:
+===========+=============+============+================+ +===========+=============+============+================+
| Algorithm | Private Key | Public Key | Signature Size | | Algorithm | Private Key | Public Key | Signature Size |
+===========+=============+============+================+ +===========+=============+============+================+
| ML-DSA-44 | 2560 | 1312 | 2420 | | ML-DSA-44 | 2560 | 1312 | 2420 |
+-----------+-------------+------------+----------------+ +-----------+-------------+------------+----------------+
| ML-DSA-65 | 4032 | 1952 | 3309 | | ML-DSA-65 | 4032 | 1952 | 3309 |
+-----------+-------------+------------+----------------+ +-----------+-------------+------------+----------------+
| ML-DSA-87 | 4896 | 2592 | 4627 | | ML-DSA-87 | 4896 | 2592 | 4627 |
+-----------+-------------+------------+----------------+ +-----------+-------------+------------+----------------+
Table 1: Sizes (in bytes) of keys and signatures of Table 1: Sizes (in Bytes) of Keys and Signatures of
ML-DSA ML-DSA
Note that priv size is always 32 bytes, and that KeyGen_internal is 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 called to produce the expanded private keys for "Private Key" in the
table above. table above.
See Section 4, ML-DSA Private Keys, for further details. See Section 4 and ML-DSA Private Keys for further details.
These algorithms are used to produce signatures as described in These algorithms are used to produce signatures as described in
Algorithm 2 of US NIST [FIPS-204]. Algorithm 2 of US NIST [FIPS-204].
The ctx parameter MUST be the empty string for ML-DSA-44, ML-DSA-65 The ctx parameter MUST be the empty string for ML-DSA-44, ML-DSA-65,
and ML-DSA-87. and ML-DSA-87.
Signatures are encoded as bytestrings using the algorithms defined in Signatures are encoded as byte strings using the algorithms defined
Section 7.2 of US NIST [FIPS-204]. in Section 7.2 of US NIST [FIPS-204].
When producing JSON Web Signatures, the signature bytestrings are When producing JSON Web Signatures, the signature byte strings are
base64url encoded, and the encoded signature size is larger than base64url encoded and the encoded signature size is larger than
described in the table above. When producing COSE signatures, no described in the table above. When producing COSE signatures, no
encoding is needed; see Section 4 of [RFC9052] for more details on encoding is needed; see Section 4 of [RFC9052] for more details on
how COSE signatures are created. how COSE signatures are created.
Table 2 of [FIPS-204] describes the ML-DSA key and signature sizes. Table 2 of [FIPS-204] describes the ML-DSA key and signature sizes.
ML-DSA produces significantly larger public keys and signatures ML-DSA produces significantly larger public keys and signatures
compared to traditional algorithms. This size increase can create compared to traditional algorithms. This size increase can create
challenges for deployments with limited bandwidth, memory, or challenges for deployments with limited bandwidth, memory, or
processing capacity. ML-DSA may not be suitable for use cases processing capacity. ML-DSA may not be suitable for use cases
requiring small keys or signatures. Use of thumbprints as described requiring small keys or signatures. Use of thumbprints as described
in [RFC7638] and [RFC9679] can reduce the need to repeat public key in [RFC7638] and [RFC9679] can reduce the need to repeat public key
representations. representations.
6. AKP Thumbprints 6. AKP Thumbprints
Although this document specifies how to represent ML-DSA keys using Although this document specifies how to represent ML-DSA keys using
AKP, the AKP key type and thumbprint computations are suitable for AKP, the AKP key type and thumbprint computations are suitable for
use with algorithms other than ML-DSA. use with algorithms other than ML-DSA.
When computing the COSE Key Thumbprint as described in [RFC9679], the When computing the COSE Key Thumbprint as described in [RFC9679], the
required parameters for algorithm key pairs are: required parameters for AKPs are:
* "kty" (label: 1, data type: int, value: 7) * "kty" (label: 1, data type: int, value: 7)
* "alg" (label: 3, data type: int, value: int) * "alg" (label: 3, data type: int, value: int)
* "pub" (label: -1, value: bstr) * "pub" (label: -1, value: bstr)
The COSE Key Thumbprint is produced according to the process The COSE Key Thumbprint is produced according to the process
described in Section 3 of [RFC9679]. described in Section 3 of [RFC9679].
When computing the JWK Thumbprint as described in [RFC7638], the When computing the JWK Thumbprint as described in [RFC7638], the
required parameters for algorithm key pairs are: required parameters for AKPs are:
* "kty" * "kty"
* "alg" * "alg"
* "pub" * "pub"
Their lexicographic order, per Section 3.3 of [RFC7638], is: Their lexicographic order, per Section 3.3 of [RFC7638], is:
* "alg" * "alg"
skipping to change at page 7, line 4 skipping to change at line 266
* "kty" * "kty"
* "alg" * "alg"
* "pub" * "pub"
Their lexicographic order, per Section 3.3 of [RFC7638], is: Their lexicographic order, per Section 3.3 of [RFC7638], is:
* "alg" * "alg"
* "kty" * "kty"
* "pub" * "pub"
The JWK Key Thumbprint is produced according to the process described The JWK Key Thumbprint is produced according to the process described
in Section 3 of [RFC7638]. in Section 3 of [RFC7638].
See the kid values in the JSON Web Key and COSE Key examples in the See the kid values in the JWK and COSE Key examples in Appendix A for
appendix for examples of AKP thumbprints. examples of AKP thumbprints.
7. Security Considerations 7. Security Considerations
The security considerations of [RFC7515], [RFC7517], and [RFC9053] The security considerations of [RFC7515], [RFC7517], and [RFC9053]
apply to this specification as well. apply to this specification as well.
A detailed security analysis of ML-DSA is beyond the scope of this A detailed security analysis of ML-DSA is beyond the scope of this
specification; see [FIPS-204] for additional details. Implementers specification; see [FIPS-204] for additional details. Implementers
should also refer to the security considerations in should also refer to the security considerations in [RFC9881] for
[I-D.draft-ietf-lamps-dilithium-certificates] for additional guidance additional guidance on ML-DSA deployment considerations, including
on ML-DSA deployment considerations, including discussions on discussions on randomized versus deterministic signing approaches.
randomized versus deterministic signing approaches.
7.1. Private key compromise 7.1. Private Key Compromise
The seed and the private key expanded from the seed require the same The seed and the private key expanded from the seed require the same
level of protection. If an unauthorized party obtains the seed, or level of protection. If an unauthorized party obtains the seed, or
the expanded private key, they can forge signatures. This undermines the expanded private key, they can forge signatures. This undermines
the authenticity and integrity guarantees provided by ML-DSA, as the authenticity and integrity guarantees provided by ML-DSA, as
attackers could impersonate the legitimate signer or alter signed attackers could impersonate the legitimate signer or alter signed
data without detection. data without detection.
7.2. Rationale for not supporting HashML-DSA 7.2. Rationale for Not Supporting HashML-DSA
This document does not specify algorithms for use with HashML-DSA as 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 described in Section 5.4 of [FIPS-204]. As the verify routines are
different, future support for HashML-DSA would require the different, future support for HashML-DSA would require the
registration of additional algorithms. Section 8.3 of registration of additional algorithms. Section 8.3 of [RFC9881]
[I-D.draft-ietf-lamps-dilithium-certificates] explains the rationale explains the rationale for disallowing HashML-DSA, including the
for disallowing HashML-DSA, including the increased complexity and increased complexity and compatibility concerns with existing
compatibility concerns with existing implementations. implementations.
7.3. Validation of keys 7.3. Validation of Keys
When an AKP algorithm requires or encourages that a key be validated When an AKP algorithm requires or encourages that a key be validated
before being used, all algorithm-related key parameters MUST be before being used, all algorithm-related key parameters MUST be
validated. validated.
Section 7.2 of [FIPS-204] describes the encoding of ML-DSA keys and Section 7.2 of [FIPS-204] describes the encoding of ML-DSA keys and
signatures. For Algorithms 22 and 23 (pkEncode and pkDecode), the signatures. For Algorithms 22 and 23 (pkEncode and pkDecode), the
inputs need to be within the ranges given in the algorithms. For 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 ML-DSA algorithms registered in this document, the priv key parameter
is the seed, and therefore, the seed length check MUST be performed. 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 length of the seed is 256 bits, which is 32 bytes. However, when
the priv parameter is expanded using KeyGen_internal, the skEncode the priv parameter is expanded using KeyGen_internal, the skEncode
and skDecode algorithms MUST be used. [FIPS-204] notes, "skDecode and skDecode algorithms MUST be used. [FIPS-204] notes "skDecode
should only be run on inputs that come from trusted sources" and that 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 "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". data and shall be treated with the same safeguards as a private key".
7.4. Mismatched AKP parameters 7.4. Mismatched AKP Parameters
When using an AKP key with an algorithm, it is possible that the When using an AKP key with an algorithm, it is possible that the
public and private information class parameters have been tampered public and private information class parameters have been tampered
with or mismatched. Depending on the algorithm and implementation, with or mismatched. Depending on the algorithm and implementation,
the consequences of using mismatched parameters can range from the consequences of using mismatched parameters can range from
operations failing to private key compromise. operations failing to private key compromise.
8. IANA Considerations 8. IANA Considerations
8.1. Additions to Existing Registries 8.1. Additions to Existing Registries
8.1.1. New COSE Algorithms 8.1.1. New COSE Algorithms
IANA is requested to add the following entries to the COSE Algorithms IANA has registered the following entries in the "COSE Algorithms"
Registry. The following completed registration actions are provided registry. The following completed registration actions are provided
as described in [RFC9053] and [RFC9054]. as described in [RFC9053] and [RFC9054].
8.1.1.1. ML-DSA-44 8.1.1.1. ML-DSA-44
* Name: ML-DSA-44 Name: ML-DSA-44
* Value: TBD (requested assignment -48) Value: -48
* Description: CBOR Object Signing Algorithm for ML-DSA-44 Description: CBOR Object Signing Algorithm for ML-DSA-44
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: RFC XXXX Reference: RFC 9964
* Recommended: Yes Recommended: Yes
8.1.1.2. ML-DSA-65 8.1.1.2. ML-DSA-65
* Name: ML-DSA-65 Name: ML-DSA-65
* Value: TBD (requested assignment -49) Value: -49
* Description: CBOR Object Signing Algorithm for ML-DSA-65 Description: CBOR Object Signing Algorithm for ML-DSA-65
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: RFC XXXX Reference: RFC 9964
* Recommended: Yes Recommended: Yes
8.1.1.3. ML-DSA-87 8.1.1.3. ML-DSA-87
* Name: ML-DSA-87 Name: ML-DSA-87
* Value: TBD (requested assignment -50) Value: -50
* Description: CBOR Object Signing Algorithm for ML-DSA-87 Description: CBOR Object Signing Algorithm for ML-DSA-87
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: RFC XXXX Reference: RFC 9964
* Recommended: Yes Recommended: Yes
8.1.2. New COSE Key Types 8.1.2. New COSE Key Types
IANA is requested to add the following entries to the COSE Key Types IANA registered the following entry in the "COSE Key Types" registry.
Registry. The following completed registration templates are The following completed registration template is provided as
provided as described in RFC 9053. described in [RFC9053].
8.1.2.1. AKP 8.1.2.1. AKP
* Name: AKP Name: AKP
* Value: TBD (requested assignment 7) Value: 7
* Description: COSE Key Type for Algorithm Key Pairs Description: COSE Key Type for Algorithm Key Pairs
* Capabilities: [kty(7)] Capabilities: [kty(7)]
* Change Controller: IETF
* Reference: RFC XXXX Change Controller: IETF
Reference: RFC 9964
8.1.3. New COSE Key Type Parameters 8.1.3. New COSE Key Type Parameters
IANA is requested to add the following entries to the COSE Key Type IANA has registered the following entries in the "COSE Key Type
Parameters. The following completed registration templates are Parameters" registry. The following completed registration templates
provided as described in RFC 9053. are provided as described in [RFC9053].
8.1.3.1. AKP Public Key 8.1.3.1. AKP Public Key
* Key Type: TBD (requested assignment 7) Key Type: 7
* Name: pub Name: pub
* Label: -1 Label: -1
* CBOR Type: bstr CBOR Type: bstr
* Description: Public key Description: Public key
* Reference: RFC XXXX Reference: RFC 9964
8.1.3.2. AKP Private Key 8.1.3.2. AKP Private Key
* Key Type: TBD (requested assignment 7) Key Type: 7
* Name: priv Name: priv
* Label: -2 Label: -2
* CBOR Type: bstr CBOR Type: bstr
* Description: Private key Description: Private key
* Reference: RFC XXXX Reference: RFC 9964
8.1.4. New JOSE Algorithms 8.1.4. New JOSE Algorithms
IANA is requested to add the following entries to the JSON Web IANA has registered the following entries in the "JSON Web Signature
Signature and Encryption Algorithms Registry. The following and Encryption Algorithms" registry. The following completed
completed registrations are provided as described in [RFC7518]. registrations are provided as described in [RFC7518].
8.1.4.1. ML-DSA-44 8.1.4.1. ML-DSA-44
* Algorithm Name: 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 Algorithm Description: ML-DSA-44 as described in US NIST FIPS 204
* JOSE Implementation Requirements: Optional Algorithm Usage Location(s): alg
* Change Controller: IETF JOSE Implementation Requirements: Optional
* Specification Document(s): RFC XXXX Change Controller: IETF
* Algorithm Analysis Documents(s): [FIPS-204] Specification Document(s): RFC 9964
Algorithm Analysis Documents(s): [FIPS-204]
8.1.4.2. ML-DSA-65 8.1.4.2. ML-DSA-65
* Algorithm Name: ML-DSA-65 Algorithm Name: ML-DSA-65
* Algorithm Description: ML-DSA-65 as described in US NIST FIPS 204. Algorithm Description: ML-DSA-65 as described in US NIST FIPS 204
* Algorithm Usage Location(s): alg Algorithm Usage Location(s): alg
* JOSE Implementation Requirements: Optional JOSE Implementation Requirements: Optional
* Change Controller: IETF Change Controller: IETF
* Specification Document(s): RFC XXXX Specification Document(s): RFC 9964
* Algorithm Analysis Documents(s): [FIPS-204] Algorithm Analysis Documents(s): [FIPS-204]
8.1.4.3. ML-DSA-87 8.1.4.3. ML-DSA-87
* Algorithm Name: ML-DSA-87 Algorithm Name: ML-DSA-87
* Algorithm Description: ML-DSA-87 as described in US NIST FIPS 204. Algorithm Description: ML-DSA-87 as described in US NIST FIPS 204
* Algorithm Usage Location(s): alg Algorithm Usage Location(s): alg
* JOSE Implementation Requirements: Optional JOSE Implementation Requirements: Optional
* Change Controller: IETF Change Controller: IETF
* Specification Document(s): RFC XXXX Specification Document(s): RFC 9964
* Algorithm Analysis Documents(s): [FIPS-204] Algorithm Analysis Documents(s): [FIPS-204]
8.1.5. New JOSE Key Types 8.1.5. New JOSE Key Types
IANA is requested to add the following entries to the JSON Web Key IANA has registered the following entry in the "JSON Web Key Types"
Types Registry. The following completed registrations are provided registry. The following completed registration is provided as
as described in [RFC7518] and [RFC7638]. described in [RFC7518] and [RFC7638].
8.1.5.1. AKP 8.1.5.1. AKP
* "kty" Parameter Value: AKP "kty" Parameter Value: AKP
* Key Type Description: Algorithm Key Pair Key Type Description: Algorithm Key Pair
* JOSE Implementation Requirements: Optional JOSE Implementation Requirements: Optional
* Change Controller: IETF Change Controller: IETF
* Specification Document(s): RFC XXXX Specification Document(s): RFC 9964
8.1.6. New JSON Web Key Parameters 8.1.6. New JWK Parameters
IANA is requested to add the following entries to the JSON Web Key IANA has registered the following entry in the "JSON Web Key
Parameters Registry. The following completed registrations are Parameters" registry. The following completed registrations are
provided as described in [RFC7517] and [RFC7638]. provided as described in [RFC7517] and [RFC7638].
8.1.6.1. AKP Public Key 8.1.6.1. AKP Public Key
* Parameter Name: pub Parameter Name: pub
* Parameter Description: Public key Parameter Description: Public key
* Used with "kty" Value(s): AKP Used with "kty" Value(s): AKP
* Parameter Information Class: Public Parameter Information Class: Public
* Change Controller: IETF Change Controller: IETF
* Specification Document(s): RFC XXXX Specification Document(s): RFC 9964
8.1.6.2. AKP Private Key 8.1.6.2. AKP Private Key
* Parameter Name: priv Parameter Name: priv
* Parameter Description: Private key Parameter Description: Private key
* Used with "kty" Value(s): AKP Used with "kty" Value(s): AKP
* Parameter Information Class: Private Parameter Information Class: Private
* Change Controller: IETF
* Specification Document(s): RFC XXXX Change Controller: IETF
Specification Document(s): RFC 9964
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS-204] "Module-Lattice-Based Digital Signature Standard", n.d., [FIPS-204] NIST, "Module-Lattice-Based Digital Signature Standard",
<https://doi.org/10.6028/NIST.FIPS.204>. NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/rfc/rfc7638>. 2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>. <https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>. August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[RFC9054] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9054] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, August Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, August
2022, <https://www.rfc-editor.org/rfc/rfc9054>. 2022, <https://www.rfc-editor.org/info/rfc9054>.
[RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object [RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object
Signing and Encryption (COSE) Key Thumbprint", RFC 9679, Signing and Encryption (COSE) Key Thumbprint", RFC 9679,
DOI 10.17487/RFC9679, December 2024, DOI 10.17487/RFC9679, December 2024,
<https://www.rfc-editor.org/rfc/rfc9679>. <https://www.rfc-editor.org/info/rfc9679>.
9.2. Informative References 9.2. Informative References
[I-D.draft-ietf-lamps-dilithium-certificates]
Massimo, J., Kampanakis, P., Turner, S., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", Work in Progress, Internet-
Draft, draft-ietf-lamps-dilithium-certificates-13, 30
September 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-dilithium-certificates-13>.
[IANA.cose] [IANA.cose]
IANA, "CBOR Object Signing and Encryption (COSE)", IANA, "CBOR Object Signing and Encryption (COSE)",
<https://www.iana.org/assignments/cose>. <https://www.iana.org/assignments/cose>.
[IANA.jose] [IANA.jose]
IANA, "JSON Object Signing and Encryption (JOSE)", IANA, "JSON Object Signing and Encryption (JOSE)",
<https://www.iana.org/assignments/jose>. <https://www.iana.org/assignments/jose>.
[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/info/rfc9881>.
Appendix A. Examples Appendix A. Examples
A.1. JOSE A.1. JOSE
{ {
"priv": "0000000000000000000000000000000000000000000000000000000000000000", "priv": "0000000000000000000000000000000000000000000000000000000000000000",
"jwk": { "jwk": {
"kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o", "kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o",
"kty": "AKP", "kty": "AKP",
"alg": "ML-DSA-44", "alg": "ML-DSA-44",
 End of changes. 133 change blocks. 
243 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.48.