rfc9864.original   rfc9864.txt 
JOSE Working Group M.B. Jones Internet Engineering Task Force (IETF) M.B. Jones
Internet-Draft Self-Issued Consulting Request for Comments: 9864 Self-Issued Consulting
Updates: 7518, 8037, 9053 (if approved) O. Steele Updates: 7518, 8037, 9053 O. Steele
Intended status: Standards Track Transmute Category: Standards Track Tradeverifyd
Expires: 11 November 2025 10 May 2025 ISSN: 2070-1721 October 2025
Fully-Specified Algorithms for JOSE and COSE Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE)
draft-ietf-jose-fully-specified-algorithms-13 and CBOR Object Signing and Encryption (COSE)
Abstract Abstract
This specification refers to cryptographic algorithm identifiers that This specification refers to cryptographic algorithm identifiers that
fully specify the cryptographic operations to be performed, including fully specify the cryptographic operations to be performed, including
any curve, key derivation function (KDF), and hash functions, as any curve, key derivation function (KDF), and hash functions, as
being "fully specified". It refers to cryptographic algorithm being "fully specified". It refers to cryptographic algorithm
identifiers that require additional information beyond the algorithm identifiers that require additional information beyond the algorithm
identifier to determine the cryptographic operations to be performed identifier to determine the cryptographic operations to be performed
as being "polymorphic". This specification creates fully-specified as being "polymorphic". This specification creates fully-specified
algorithm identifiers for registered JSON Object Signing and algorithm identifiers for registered JSON Object Signing and
Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)
polymorphic algorithm identifiers, enabling applications to use only polymorphic algorithm identifiers, enabling applications to use only
fully-specified algorithm identifiers. It deprecates those fully-specified algorithm identifiers. It deprecates those
polymorphic algorithm identifiers. polymorphic algorithm identifiers.
This specification updates RFC 7518, RFC 8037, and RFC 9053. It This specification updates RFCs 7518, 8037, and 9053. It deprecates
deprecates polymorphic algorithms defined by RFC 8037 and RFC 9053 polymorphic algorithms defined by RFCs 8037 and 9053 and provides
and provides fully-specified replacements for them. It adds to the fully-specified replacements for them. It adds to the instructions
instructions to designated experts in RFC 7518 and RFC 9053. to designated experts in RFCs 7518 and 9053.
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
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 11 November 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9864.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 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
1.1. Requirements Notation and Conventions . . . . . . . . . . 4 1.1. Requirements Notation and Conventions
2. Fully-Specified Digital Signature Algorithm Identifiers . . . 4 2. Fully-Specified Digital Signature Algorithm Identifiers
2.1. Elliptic Curve Digital Signature Algorithm (ECDSA) . . . 4 2.1. Elliptic Curve Digital Signature Algorithm (ECDSA)
2.2. Edwards-Curve Digital Signature Algorithm (EdDSA) . . . . 5 2.2. Edwards-curve Digital Signature Algorithm (EdDSA)
3. Fully-Specified Encryption . . . . . . . . . . . . . . . . . 6 3. Fully-Specified Encryption
3.1. Fully-Specified Encryption Algorithms . . . . . . . . . . 7 3.1. Fully-Specified Encryption Algorithms
3.2. Polymorphic Encryption Algorithms . . . . . . . . . . . . 8 3.2. Polymorphic Encryption Algorithms
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations
4.1. JOSE Algorithms Registrations . . . . . . . . . . . . . . 8 4.1. JOSE Algorithm Registrations
4.1.1. Fully-Specified JOSE Algorithm Registrations . . . . 8 4.1.1. Fully-Specified JOSE Algorithm Registrations
4.1.2. Deprecated Polymorphic JOSE Algorithm 4.1.2. Deprecated Polymorphic JOSE Algorithm Registration
Registrations . . . . . . . . . . . . . . . . . . . . 8 4.2. COSE Algorithm Registrations
4.2. COSE Algorithms Registrations . . . . . . . . . . . . . . 9 4.2.1. Fully-Specified COSE Algorithm Registrations
4.2.1. Fully-Specified COSE Algorithm Registrations . . . . 9 4.2.2. Deprecated Polymorphic COSE Algorithm Registrations
4.2.2. Deprecated Polymorphic COSE Algorithm 4.3. Updated Review Instructions for Designated Experts
Registrations . . . . . . . . . . . . . . . . . . . . 11 4.3.1. JSON Web Signature and Encryption Algorithms
4.3. Updated Review Instructions for Designated Experts . . . 11 4.3.2. COSE Algorithms
4.3.1. JSON Web Signature and Encryption Algorithms . . . . 11 4.4. Defining "Deprecated" and "Prohibited"
4.3.2. COSE Algorithms . . . . . . . . . . . . . . . . . . . 12 5. Key Representations
4.4. Defining Deprecated and Prohibited . . . . . . . . . . . 12 6. Notes on Algorithms Not Updated
5. Key Representations . . . . . . . . . . . . . . . . . . . . . 13 6.1. RSA Signing Algorithms
6. Notes on Algorithms Not Updated . . . . . . . . . . . . . . . 13 6.2. ECDH Key Agreement Algorithms
6.1. RSA Signing Algorithms . . . . . . . . . . . . . . . . . 14 6.3. HSS/LMS Hash-Based Digital Signature Algorithm
6.2. ECDH Key Agreement Algorithms . . . . . . . . . . . . . . 14 7. Security Considerations
6.3. HSS/LMS Hash-Based Digital Signature Algorithm . . . . . 14 8. References
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 Acknowledgements
8.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses
Appendix A. Document History . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The IANA algorithm registries for JSON Object Signing and Encryption The IANA algorithm registries for JSON Object Signing and Encryption
(JOSE) algorithms [IANA.JOSE] and CBOR Object Signing and Encryption (JOSE) algorithms [IANA.JOSE] and CBOR Object Signing and Encryption
(COSE) algorithms [IANA.COSE] contain two kinds of algorithm (COSE) algorithms [IANA.COSE] contain two kinds of algorithm
identifiers: identifiers:
Fully Specified Fully Specified
Those that fully determine the cryptographic operations to be Those that fully determine the cryptographic operations to be
performed, including any curve, key derivation function (KDF), and performed, including any curve, key derivation function (KDF), and
hash functions. Examples are RS256 and ES256K in both JOSE hash functions. Examples are RS256 and ES256K in both JOSE
[IANA.JOSE] and COSE [IANA.COSE] and ES256 in JOSE. [IANA.JOSE] and COSE [IANA.COSE] and ES256 in JOSE.
Polymorphic Polymorphic
Those requiring information beyond the algorithm identifier to Those requiring information beyond the algorithm identifier to
determine the cryptographic operations to be performed. Such determine the cryptographic operations to be performed. Such
additional information could include the actual key value and a additional information could include the actual key value and a
curve that it uses. Examples are EdDSA in both JOSE [IANA.JOSE] curve that it uses. Examples are the Edwards-curve Digital
and COSE [IANA.COSE] and ES256 in COSE. Signature Algorithm (EdDSA) in both JOSE [IANA.JOSE] and COSE
[IANA.COSE] and ES256 in COSE.
This matters because many protocols negotiate supported operations This matters because many protocols negotiate supported operations
using only algorithm identifiers. For instance, OAuth Authorization using only algorithm identifiers. For instance, OAuth Authorization
Server Metadata [RFC8414] uses negotiation parameters like these Server Metadata [RFC8414] uses negotiation parameters like these
(from an example in the specification): (from an example in that specification):
"token_endpoint_auth_signing_alg_values_supported": "token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"] ["RS256", "ES256"]
OpenID Connect Discovery [OpenID.Discovery] likewise negotiates OpenID Connect Discovery [OpenID.Discovery] likewise negotiates
supported algorithms using alg and enc values. W3C Web supported algorithms using "alg" and "enc" values. W3C Web
Authentication [WebAuthn] and FIDO Client to Authenticator Protocol Authentication [WebAuthn] and the FIDO Client to Authenticator
(CTAP) [FIDO2] negotiate using COSE alg numbers. Protocol (CTAP) [FIDO2] negotiate using COSE "alg" numbers.
This does not work for polymorphic algorithms. For instance, with This does not work for polymorphic algorithms. For instance, with
EdDSA, it is not known which of the curves Ed25519 and/or Ed448 are EdDSA, it is not known which of the curves Ed25519 and/or Ed448 are
supported. This causes real problems in practice. supported. This causes real problems in practice.
WebAuthn contains this de-facto algorithm definition to work around WebAuthn contains this de facto algorithm definition to work around
this problem: this problem:
-8 (EdDSA), where crv is 6 (Ed25519) -8 (EdDSA), where crv is 6 (Ed25519)
This redefines the COSE EdDSA algorithm identifier for the purposes This redefines the COSE EdDSA algorithm identifier for the purposes
of WebAuthn to restrict it to using the Ed25519 curve - making it of WebAuthn to restrict it to using the Ed25519 curve -- making it
non-polymorphic so that algorithm negotiation can succeed, but also non-polymorphic so that algorithm negotiation can succeed, but also
effectively eliminating the possibility of using Ed448. Other effectively eliminating the possibility of using Ed448. Other
similar workarounds for polymorphic algorithm identifiers are used in similar workarounds for polymorphic algorithm identifiers are used in
practice. practice.
Note that using fully-specified algorithms is sometimes referred to Note that using fully-specified algorithms is sometimes referred to
as the "cipher suite" approach; using polymorphic algorithms is as the "cipher suite" approach; using polymorphic algorithms is
sometimes referred to as the "à la carte" approach. sometimes referred to as the "à la carte" approach.
This specification creates fully-specified algorithm identifiers for This specification creates fully-specified algorithm identifiers for
registered polymorphic JOSE and COSE algorithms and their parameters, registered polymorphic JOSE and COSE algorithms and their parameters,
enabling applications to use only fully-specified algorithm enabling applications to use only fully-specified algorithm
identifiers. Furthermore, it deprecates the practice of registering identifiers. Furthermore, it deprecates the practice of registering
polymorphic algorithm identifiers. polymorphic algorithm identifiers.
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
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 BCP "OPTIONAL" in this document are to be interpreted as described in
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.
2. Fully-Specified Digital Signature Algorithm Identifiers 2. Fully-Specified Digital Signature Algorithm Identifiers
This section creates fully-specified digital signature algorithm This section creates fully-specified digital signature algorithm
identifiers for a set of registered polymorphic JOSE and COSE identifiers for a set of registered polymorphic JOSE and COSE
algorithms and their parameters. algorithms and their parameters.
2.1. Elliptic Curve Digital Signature Algorithm (ECDSA) 2.1. Elliptic Curve Digital Signature Algorithm (ECDSA)
[RFC9053] defines a way to use the Elliptic Curve Digital Signature [RFC9053] defines a way to use the Elliptic Curve Digital Signature
Algorithm (ECDSA) with COSE. The COSE algorithm registrations for Algorithm (ECDSA) with COSE. The COSE algorithm registrations for
ECDSA are polymorphic, since they do not specify the curve used. For ECDSA are polymorphic, since they do not specify the curve used. For
instance, ES256 is defined as "ECDSA w/ SHA-256" in Section 2.1 of instance, ES256 is defined as "ECDSA w/ SHA-256" in Section 2.1 of
[RFC9053]. (The corresponding JOSE registrations in [RFC7518] are [RFC9053]. (The corresponding JOSE registrations in [RFC7518] are
full-specified.) fully specified.)
The following fully-specified COSE ECDSA algorithms are defined by The following fully-specified COSE ECDSA algorithms are defined by
this specification: this specification:
+========+==================+===================+=============+ +========+============+=============================+=============+
| Name | COSE Value | Description | COSE | | Name | COSE Value | Description | COSE |
| | | | Recommended | | | | | Recommended |
+========+==================+===================+=============+ +========+============+=============================+=============+
| ESP256 | TBD (requested | ECDSA using P-256 | Yes | | ESP256 | -9 | ECDSA using P-256 curve and | Yes |
| | assignment -9) | curve and SHA-256 | | | | | SHA-256 | |
+--------+------------------+-------------------+-------------+ +--------+------------+-----------------------------+-------------+
| ESP384 | TBD (requested | ECDSA using P-384 | Yes | | ESP384 | -51 | ECDSA using P-384 curve and | Yes |
| | assignment -51) | curve and SHA-384 | | | | | SHA-384 | |
+--------+------------------+-------------------+-------------+ +--------+------------+-----------------------------+-------------+
| ESP512 | TBD (requested | ECDSA using P-521 | Yes | | ESP512 | -52 | ECDSA using P-521 curve and | Yes |
| | assignment -52) | curve and SHA-512 | | | | | SHA-512 | |
+--------+------------------+-------------------+-------------+ +--------+------------+-----------------------------+-------------+
| ESB256 | TBD (requested | ECDSA using | No | | ESB256 | -265 | ECDSA using BrainpoolP256r1 | No |
| | assignment -265) | BrainpoolP256r1 | | | | | curve and SHA-256 | |
| | | curve and SHA-256 | | +--------+------------+-----------------------------+-------------+
+--------+------------------+-------------------+-------------+ | ESB320 | -266 | ECDSA using BrainpoolP320r1 | No |
| ESB320 | TBD (requested | ECDSA using | No | | | | curve and SHA-384 | |
| | assignment -266) | BrainpoolP320r1 | | +--------+------------+-----------------------------+-------------+
| | | curve and SHA-384 | | | ESB384 | -267 | ECDSA using BrainpoolP384r1 | No |
+--------+------------------+-------------------+-------------+ | | | curve and SHA-384 | |
| ESB384 | TBD (requested | ECDSA using | No | +--------+------------+-----------------------------+-------------+
| | assignment -267) | BrainpoolP384r1 | | | ESB512 | -268 | ECDSA using BrainpoolP512r1 | No |
| | | curve and SHA-384 | | | | | curve and SHA-512 | |
+--------+------------------+-------------------+-------------+ +--------+------------+-----------------------------+-------------+
| ESB512 | TBD (requested | ECDSA using | No |
| | assignment -268) | BrainpoolP512r1 | |
| | | curve and SHA-512 | |
+--------+------------------+-------------------+-------------+
Table 1: ECDSA Algorithm Values Table 1: ECDSA Algorithm Values
2.2. Edwards-Curve Digital Signature Algorithm (EdDSA) 2.2. Edwards-curve Digital Signature Algorithm (EdDSA)
[RFC8037] defines a way to use the Edwards-Curve Digital Signature [RFC8037] defines a way to use EdDSA with JOSE, and [RFC9053] defines
Algorithm (EdDSA) with JOSE and [RFC9053] defines a way to use it a way to use it with COSE. Both register polymorphic EdDSA algorithm
with COSE. Both register polymorphic EdDSA algorithm identifiers. identifiers.
The following fully-specified JOSE and COSE EdDSA algorithms are The following fully-specified JOSE and COSE EdDSA algorithms are
defined by this specification: defined by this specification:
+=======+============+=============+================+=============+ +=========+=======+================+================+=============+
|Name | COSE Value | Description | JOSE | COSE | | Name | COSE | Description | JOSE | COSE |
| | | | Implementation | Recommended | | | Value | | Implementation | Recommended |
| | | | Requirements | | | | | | Requirements | |
+=======+============+=============+================+=============+ +=========+=======+================+================+=============+
|Ed25519| TBD | EdDSA using | Optional | Yes | | Ed25519 | -19 | EdDSA using | Optional | Yes |
| | (requested | Ed25519 | | | | | | the Ed25519 | | |
| | assignment | curve | | | | | | parameter set | | |
| | -19) | | | | | | | in Section 5.1 | | |
+-------+------------+-------------+----------------+-------------+ | | | of [RFC8032] | | |
|Ed448 | TBD | EdDSA using | Optional | Yes | +---------+-------+----------------+----------------+-------------+
| | (requested | Ed448 curve | | | | Ed448 | -53 | EdDSA using | Optional | Yes |
| | assignment | | | | | | | the Ed448 | | |
| | -53) | | | | | | | parameter set | | |
+-------+------------+-------------+----------------+-------------+ | | | in Section 5.2 | | |
| | | of [RFC8032] | | |
+---------+-------+----------------+----------------+-------------+
Table 2: EdDSA Algorithm Values Table 2: EdDSA Algorithm Values
3. Fully-Specified Encryption 3. Fully-Specified Encryption
This section describes the construction of fully-specified encryption This section describes the construction of fully-specified encryption
algorithm identifiers in the context of the JOSE and COSE encryption algorithm identifiers in the context of the JOSE and COSE encryption
schemes JSON Web Encryption (JWE), as described in [RFC7516] and schemes JSON Web Encryption (JWE), as described in [RFC7516] and
[RFC7518], and COSE Encrypt, as described in [RFC9052] and [RFC9053]. [RFC7518], and COSE encryption, as described in [RFC9052] and
[RFC9053].
Using fully-specified encryption algorithms enables the sender and Using fully-specified encryption algorithms enables the sender and
receiver to agree on all mandatory security parameters. They also receiver to agree on all mandatory security parameters. They also
enable protocols to specify an allow list of algorithm combinations enable protocols to specify an allow list of algorithm combinations
that does not include polymorphic combinations, preventing problems that does not include polymorphic combinations, preventing problems
such as cross-curve key establishment, cross-protocol symmetric such as cross-curve key establishment, cross-protocol symmetric
encryption, or mismatched KDF size to symmetric key scenarios. encryption, or mismatched KDF size to symmetric key scenarios.
Both JOSE and COSE have operations that take multiple algorithms as Both JOSE and COSE have operations that take multiple algorithms as
parameters. Encrypted objects in JOSE [RFC7516] use two algorithm parameters. Encrypted objects in JOSE [RFC7516] use two algorithm
identifiers: the first in the "alg" (Algorithm) Header Parameter, identifiers: the first in the "alg" (Algorithm) Header Parameter,
which specifies how to determine the content encryption key, and the which specifies how to determine the content encryption key, and the
second in the "enc" (Encryption Algorithm) Header Parameter, which second in the "enc" (Encryption Algorithm) Header Parameter, which
specifies the content encryption algorithm. Likewise, encrypted COSE specifies the content encryption algorithm. Likewise, encrypted COSE
objects can use multiple algorithms for corresponding purposes. This objects can use multiple algorithms for corresponding purposes. This
section describes how to fully specify encryption algorithms for JOSE section describes how to fully specify encryption algorithms for JOSE
and COSE. and COSE.
To perform fully-specified encryption in JOSE, the "alg" value MUST To perform fully-specified encryption in JOSE, the "alg" value MUST
specify all parameters for key establishment or derive some of them specify all parameters for key establishment or derive some of them
from the accompanying "enc" value and the "enc" value MUST specify from the accompanying "enc" value, and the "enc" value MUST specify
all parameters for symmetric encryption. For example, JWE encryption all parameters for symmetric encryption. For example, encryption via
using an "alg" value of "A128KW" (AES Key Wrap using 128-bit key) and JWE using an "alg" value of "A128KW" (AES Key Wrap using 128-bit key)
an "enc" value of "A128GCM" (AES GCM using 128-bit key) uses fully- and an "enc" value of "A128GCM" (AES GCM using 128-bit key) uses
specified algorithms. fully-specified algorithms.
Note that in JOSE, there is the option to derive some cryptographic Note that in JOSE, there is the option to derive some cryptographic
parameters used in the "alg" computation from the accompanying "enc" parameters used in the "alg" computation from the accompanying "enc"
value. An example of this is that the keydatalen KDF parameter value value. For example, the keydatalen KDF parameter value for "ECDH-ES"
for "ECDH-ES" is determined from the "enc" value, as described in is determined from the "enc" value, as described in Section 4.6.2 of
Section 4.6.2 of [RFC7518]. For the purposes of an "alg" value being [RFC7518]. For the purposes of an "alg" value being fully specified,
fully-specified, deriving parameters from "enc" does not make the deriving parameters from "enc" does not make the algorithm
algorithm polymorphic, as the computation is still fully determined polymorphic, as the computation is still fully determined by the
by the algorithm identifiers used. This option is not present in algorithm identifiers used. This option is not present in COSE.
COSE.
To perform fully-specified encryption in COSE, the outer "alg" value To perform fully-specified encryption in COSE, the outer "alg" value
MUST specify all parameters for key establishment and the inner "alg" MUST specify all parameters for key establishment, and the inner
value must specify all parameters for symmetric encryption. For "alg" value MUST specify all parameters for symmetric encryption.
example, COSE encryption using an outer "alg" value of A128KW and an For example, encryption via COSE using an outer "alg" value of
inner "alg" value of A128GCM uses fully-specified algorithms. Note "A128KW" and an inner "alg" value of "A128GCM" uses fully-specified
that when using COSE_Encrypt, as specified in Section 5.1 of algorithms. Note that when using COSE_Encrypt, as specified in
[RFC9052], the outer "alg" is communicated in the headers of the Section 5.1 of [RFC9052], the outer "alg" is communicated in the
COSE_Encrypt object and the inner "alg" is communicated in the headers of the COSE_Encrypt object and the inner "alg" is
headers of the COSE_recipient object. communicated in the headers of the COSE_recipient object.
While this specification provides a definition of what fully- While this specification provides a definition of what fully-
specified encryption algorithm identifiers are for both JOSE and specified encryption algorithm identifiers are for both JOSE and
COSE, it does not deprecate any polymorphic encryption algorithms, COSE, it does not deprecate any polymorphic encryption algorithms,
since replacements for them are not provided by this specification. since replacements for them are not provided by this specification.
This is discussed in Section 6.2. This is discussed in Section 6.2.
3.1. Fully-Specified Encryption Algorithms 3.1. Fully-Specified Encryption Algorithms
Many of the registered JOSE and COSE algorithms used for encryption Many of the registered JOSE and COSE algorithms used for encryption
are already fully-specified. This section discusses them. are already fully specified. This section discusses them.
All the symmetric encryption algorithms registered by [RFC7518] and All the symmetric encryption algorithms registered by [RFC7518] and
[RFC9053] are fully-specified. An example of a fully-specified [RFC9053] are fully specified. An example of a fully-specified
symmetric encryption algorithm is "A128GCM" (AES GCM using 128-bit symmetric encryption algorithm is "A128GCM" (AES GCM using 128-bit
key). key).
In both JOSE and COSE, all registered key wrapping algorithms are In both JOSE and COSE, all registered key wrapping algorithms are
fully specified, as are the key wrapping with AES GCM algorithms. An fully specified, as are the algorithms performing key wrapping using
example of a fully-specified key wrapping algorithm is "A128KW" (AES AES GCM. An example of a fully-specified key wrapping algorithm is
Key Wrap using 128-bit key). "A128KW" (AES Key Wrap using 128-bit key).
The JOSE "dir" and COSE "direct" algorithms are fully specified. The The JOSE "dir" and COSE "direct" algorithms are fully specified. The
COSE direct+HKDF algorithms are fully specified. COSE direct+HKDF algorithms are fully specified.
The JOSE Key Encryption with PBES2 algorithms are fully specified. The JOSE algorithms performing Key Encryption with PBES2 are fully
specified.
3.2. Polymorphic Encryption Algorithms 3.2. Polymorphic Encryption Algorithms
Some of the registered JOSE and COSE algorithms used for encryption Some of the registered JOSE and COSE algorithms used for encryption
are polymorphic. This section discusses them. are polymorphic. This section discusses them.
The ECDH key establishment algorithms in both JOSE and COSE are The Elliptic Curve Diffie-Hellman (ECDH) key establishment algorithms
polymorphic because they do not specify the elliptic curve to be used in both JOSE and COSE are polymorphic because they do not specify the
for the key. This is true of the ephemeral key for the Ephemeral- elliptic curve to be used for the key. This is true of the ephemeral
Static (ES) algorithms registered for JOSE and COSE and of the static key for the Ephemeral-Static (ES) algorithms registered for JOSE and
key for the Static-Static (SS) algorithms registered by COSE. See COSE and of the static key for the Static-Static (SS) algorithms
more discussion of ECDH algorithms in Section 6.2. registered by COSE. See more discussion of ECDH algorithms in
Section 6.2.
4. IANA Considerations 4. IANA Considerations
4.1. JOSE Algorithms Registrations 4.1. JOSE Algorithm Registrations
This section registers the following values in the IANA "JSON Web IANA has registered the values in this section in the "JSON Web
Signature and Encryption Algorithms" registry [IANA.JOSE] established Signature and Encryption Algorithms" registry [IANA.JOSE] established
by [RFC7515]. by [RFC7518] and has listed this document as an additional reference
for the registry.
4.1.1. Fully-Specified JOSE Algorithm Registrations 4.1.1. Fully-Specified JOSE Algorithm Registrations
* Algorithm Name: Ed25519 Algorithm Name: Ed25519
* Algorithm Description: EdDSA using Ed25519 curve Algorithm Description: EdDSA using the Ed25519 parameter set in
* Algorithm Usage Locations: alg Section 5.1 of [RFC8032]
* JOSE Implementation Requirements: Optional Algorithm Usage Locations: alg
* Change Controller: IETF JOSE Implementation Requirements: Optional
* Reference: Section 2.2 of [[ this specification ]] Change Controller: IETF
* Algorithm Analysis Document(s): [RFC8032] Reference: Section 2.2 of RFC 9864
Algorithm Analysis Document(s): [RFC8032]
* Algorithm Name: Ed448 Algorithm Name: Ed448
* Algorithm Description: EdDSA using Ed448 curve Algorithm Description: EdDSA using the Ed448 parameter set in
* Algorithm Usage Locations: alg Section 5.2 of [RFC8032]
* JOSE Implementation Requirements: Optional Algorithm Usage Locations: alg
* Change Controller: IETF JOSE Implementation Requirements: Optional
* Reference: Section 2.2 of [[ this specification ]] Change Controller: IETF
* Algorithm Analysis Document(s): [RFC8032] Reference: Section 2.2 of RFC 9864
Algorithm Analysis Document(s): [RFC8032]
4.1.2. Deprecated Polymorphic JOSE Algorithm Registrations 4.1.2. Deprecated Polymorphic JOSE Algorithm Registration
The following registration is updated to change its status to IANA has updated the status to "Deprecated" for the following
Deprecated. registration.
* Algorithm Name: EdDSA Algorithm Name: EdDSA
* Algorithm Description: EdDSA signature algorithms Algorithm Description: EdDSA signature algorithms
* Algorithm Usage Locations: alg Algorithm Usage Locations: alg
* JOSE Implementation Requirements: Deprecated JOSE Implementation Requirements: Deprecated
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.2 of [[ this specification ]] Reference: Section 2.2 of RFC 9864
* Algorithm Analysis Document(s): [RFC8032] Algorithm Analysis Document(s): [RFC8032]
4.2. COSE Algorithms Registrations 4.2. COSE Algorithm Registrations
This section registers the following values in the IANA "COSE IANA has registered the following values in the "COSE Algorithms"
Algorithms" registry [IANA.COSE]. registry [IANA.COSE] established by [RFC9053] and [RFC9054] and has
added this document as an additional reference for the registry.
4.2.1. Fully-Specified COSE Algorithm Registrations 4.2.1. Fully-Specified COSE Algorithm Registrations
* Name: ESP256 Name: ESP256
* Value: TBD (requested assignment -9) Value: -9
* Description: ECDSA using P-256 curve and SHA-256 Description: ECDSA using P-256 curve and SHA-256
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]] Reference: Section 2.1 of RFC 9864
* Recommended: Yes Recommended: Yes
* Name: ESP384 Name: ESP384
* Value: TBD (requested assignment -51) Value: -51
* Description: ECDSA using P-384 curve and SHA-384 Description: ECDSA using P-384 curve and SHA-384
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]] Reference: Section 2.1 of RFC 9864
* Recommended: Yes Recommended: Yes
* Name: ESP512 Name: ESP512
* Value: TBD (requested assignment -52) Value: -52
* Description: ECDSA using P-521 curve and SHA-512 Description: ECDSA using P-521 curve and SHA-512
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]] Reference: Section 2.1 of RFC 9864
* Recommended: Yes Recommended: Yes
* Name: ESB256 Name: ESB256
* Value: TBD (requested assignment -261) Value: -265
* Description: ECDSA using BrainpoolP256r1 curve and SHA-256 Description: ECDSA using BrainpoolP256r1 curve and SHA-256
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]] Reference: Section 2.1 of RFC 9864
* Recommended: No Recommended: No
* Name: ESB320 Name: ESB320
* Value: TBD (requested assignment -262) Value: -266
* Description: ECDSA using BrainpoolP320r1 curve and SHA-384 Description: ECDSA using BrainpoolP320r1 curve and SHA-384
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]] Reference: Section 2.1 of RFC 9864
* Recommended: No Recommended: No
* Name: ESB384 Name: ESB384
* Value: TBD (requested assignment -263) Value: -267
* Description: ECDSA using BrainpoolP384r1 curve and SHA-384 Description: ECDSA using BrainpoolP384r1 curve and SHA-384
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]] Reference: Section 2.1 of RFC 9864
* Recommended: No Recommended: No
* Name: ESB512 Name: ESB512
* Value: TBD (requested assignment -264) Value: -268
* Description: ECDSA using BrainpoolP512r1 curve and SHA-512 Description: ECDSA using BrainpoolP512r1 curve and SHA-512
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: Section 2.1 of [[ this specification ]] Reference: Section 2.1 of RFC 9864
* Recommended: No Recommended: No
* Name: Ed25519 Name: Ed25519
* Value: TBD (requested assignment -19) Value: -19
* Description: EdDSA using Ed25519 curve Description: EdDSA using the Ed25519 parameter set in Section 5.1 of
* Capabilities: [kty] [RFC8032]
* Change Controller: IETF Capabilities: [kty]
* Reference: Section 2.2 of [[ this specification ]] Change Controller: IETF
* Recommended: Yes Reference: Section 2.2 of RFC 9864
Recommended: Yes
* Name: Ed448 Name: Ed448
* Value: TBD (requested assignment -53) Value: -53
* Description: EdDSA using Ed448 curve Description: EdDSA using the Ed448 parameter set in Section 5.2 of
* Capabilities: [kty] [RFC8032]
* Change Controller: IETF Capabilities: [kty]
* Reference: Section 2.2 of [[ this specification ]] Change Controller: IETF
* Recommended: Yes Reference: Section 2.2 of RFC 9864
Recommended: Yes
4.2.2. Deprecated Polymorphic COSE Algorithm Registrations 4.2.2. Deprecated Polymorphic COSE Algorithm Registrations
The following registrations are updated to change their status to IANA has updated the status to "Deprecated" and has added this
Deprecated. document as a reference for the following registrations.
* Name: ES256 Name: ES256
* Value: -7 Value: -7
* Description: ECDSA w/ SHA-256 Description: ECDSA w/ SHA-256
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: RFC 9053 Reference: [RFC9053] and RFC 9864
* Recommended: Deprecated Recommended: Deprecated
* Name: ES384 Name: ES384
* Value: -35 Value: -35
* Description: ECDSA w/ SHA-384 Description: ECDSA w/ SHA-384
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: RFC 9053 Reference: [RFC9053] and RFC 9864
* Recommended: Deprecated Recommended: Deprecated
* Name: ES512 Name: ES512
* Value: -36 Value: -36
* Description: ECDSA w/ SHA-512 Description: ECDSA w/ SHA-512
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: RFC 9053 Reference: [RFC9053] and RFC 9864
* Recommended: Deprecated Recommended: Deprecated
* Name: EdDSA Name: EdDSA
* Value: -8 Value: -8
* Description: EdDSA Description: EdDSA
* Capabilities: [kty] Capabilities: [kty]
* Change Controller: IETF Change Controller: IETF
* Reference: RFC 9053 Reference: [RFC9053] and RFC 9864
* Recommended: Deprecated Recommended: Deprecated
4.3. Updated Review Instructions for Designated Experts 4.3. Updated Review Instructions for Designated Experts
4.3.1. JSON Web Signature and Encryption Algorithms 4.3.1. JSON Web Signature and Encryption Algorithms
IANA is directed to preserve the current reference to RFC 7518, and The review instructions for the designated experts [RFC8126] for the
to add a reference to this section of this specification. "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE]
in Section 7.1 of [RFC7518] have been updated to include an
The review instructions for the designated experts for the IANA "JSON additional review criterion:
Web Signature and Encryption Algorithms" registry [IANA.JOSE] in
Section 7.1 of [RFC7518] have been updated to include an additional
review criterion:
* Only fully-specified algorithm identifiers may be registered. * Only fully-specified algorithm identifiers may be registered.
Polymorphic algorithm identifiers must not be registered. Polymorphic algorithm identifiers must not be registered.
4.3.2. COSE Algorithms 4.3.2. COSE Algorithms
IANA is directed to preserve the current references to RFC 9053 and The review instructions for the designated experts [RFC8126] for the
RFC 9054, and to add a reference to this section of this "COSE Algorithms" registry [IANA.COSE] in Section 10.4 of [RFC9053]
specification. have been updated to include an additional review criterion:
The review instructions for the designated experts for the IANA "COSE
Algorithms" registry [IANA.COSE] in Section 10.4 of [RFC9053] have
been updated to include an additional review criterion:
* Only fully-specified algorithm identifiers may be registered. * Only fully-specified algorithm identifiers may be registered.
Polymorphic algorithm identifiers must not be registered. Polymorphic algorithm identifiers must not be registered.
4.4. Defining Deprecated and Prohibited 4.4. Defining "Deprecated" and "Prohibited"
The terms "Deprecated" and "Prohibited" as used by JOSE and COSE The terms "Deprecated" and "Prohibited" as used by JOSE and COSE
registrations are currently undefined. Furthermore, while in registrations are currently undefined. Furthermore, while in
[RFC7518] JOSE specifies that both "Deprecated" and "Prohibited" can [RFC7518] JOSE specifies that both "Deprecated" and "Prohibited" can
be used, in [RFC8152] COSE specifies the use of "Deprecated" but not be used, in [RFC8152] COSE specifies the use of "Deprecated" but not
"Prohibited". This section defines these terms for use by both JOSE "Prohibited". (Note that [RFC8152] has been obsoleted by [RFC9052].)
and COSE IANA registrations in a consistent manner, eliminating this This section defines these terms for use by both JOSE and COSE IANA
potentially confusing inconsistency. registrations in a consistent manner, eliminating this potentially
confusing inconsistency.
For purposes of use in the "JOSE Implementation Requirements" columns For purposes of use in the "JOSE Implementation Requirements" columns
in the IANA JOSE registries [IANA.JOSE] and in the "Recommended" in the IANA JOSE registries [IANA.JOSE] and in the "Recommended"
columns in the IANA COSE registries [IANA.COSE], these terms are columns in the IANA COSE registries [IANA.COSE], these terms are
defined as follows: defined as follows:
Deprecated Deprecated
There is a preferred mechanism to achieve similar functionality to There is a preferred mechanism to achieve functionality similar to
that referenced by the identifier; this replacement functionality that referenced by the identifier; this replacement functionality
SHOULD be utilized in new deployments in preference to the SHOULD be utilized in new deployments in preference to the
deprecated identifier, unless there exist documented operational deprecated identifier, unless there exist documented operational
or regulatory requirements that prevent migration away from the or regulatory requirements that prevent migration away from the
deprecated identifier. deprecated identifier.
Prohibited Prohibited
The identifier and the functionality that it references MUST NOT The identifier and the functionality that it references MUST NOT
be used. (Identifiers may be designated as "Prohibited" due to be used. (Identifiers may be designated as "Prohibited" due to
security flaws, for instance.) security flaws, for instance.)
For completeness, these definitions bring the set of defined terms For completeness, these definitions bring the set of defined terms
for use in the "Recommended" columns in the IANA COSE registries for use in the "Recommended" columns in the IANA COSE registries
[IANA.COSE] to "Yes" [RFC8152], "No" [RFC8152], "Filter Only" [IANA.COSE] to "Yes" [RFC8152], "No" [RFC8152], "Filter Only"
[RFC9054], "Prohibited", and "Deprecated". This updates the [RFC9054], "Prohibited", and "Deprecated". This updates the
definitions of the "Recommended" columns in these registries to be: definitions of the "Recommended" columns in these registries to be:
Recommended: Does the IETF have a consensus recommendation to use Recommended
the algorithm? The legal values are "Yes", "No", "Filter Only", Does the IETF have a consensus recommendation to use the
algorithm? The legal values are "Yes", "No", "Filter Only",
"Prohibited", and "Deprecated". "Prohibited", and "Deprecated".
The set of defined terms for use in the "JOSE Implementation The set of defined terms for use in the "JOSE Implementation
Requirements" columns in the IANA JOSE registries [IANA.JOSE] are Requirements" columns in the IANA JOSE registries [IANA.JOSE] are
unchanged. unchanged.
Note that the terms "Deprecated" and "Prohibited" have been used with Note that the terms "Deprecated" and "Prohibited" have been used with
a multiplicity of different meanings in various specifications, a multiplicity of different meanings in various specifications,
sometimes without actually being defined in those specifications. sometimes without actually being defined in those specifications.
For instance, the term "Deprecated" is used in the title of For instance, a variation of the term "Deprecated" is used in the
[RFC8996], but the actual specification text uses the terminology title of [RFC8996], but the actual specification text uses the
"MUST NOT be used". terminology "MUST NOT be used".
The definitions above were chosen because they are consistent with The definitions above were chosen because they are consistent with
all existing registrations in both JOSE and COSE; none will need to all existing registrations in both JOSE and COSE; none will need to
change. Furthermore, they are consistent with their existing usage change. Furthermore, they are consistent with their existing usage
in JOSE. The only net change is to enable a clear distinction in JOSE. The only net change is to enable a clear distinction
between "Deprecated" and "Prohibited" in future COSE registrations. between "Deprecated" and "Prohibited" in future COSE registrations.
5. Key Representations 5. Key Representations
The key representations for the new fully-specified algorithms The key representations for the new fully-specified algorithms
defined by this specification are the same as those for the defined by this specification are the same as those for the
polymorphic algorithms that they replace, other than the alg value, polymorphic algorithms that they replace, other than the "alg" value,
if included. For instance, the representation for a key used with if included. For instance, the representation for a key used with
the Ed25519 algorithm is the same as that specified in [RFC8037], the Ed25519 algorithm is the same as that specified in [RFC8037],
except that the alg value would be Ed25519 rather than EdDSA, if except that the "alg" value would be Ed25519 rather than EdDSA, if
included. included.
6. Notes on Algorithms Not Updated 6. Notes on Algorithms Not Updated
Some existing polymorphic algorithms are not updated by this Some existing polymorphic algorithms are not updated by this
specification. This section discusses why they have not been specification. This section discusses why they have not been
updated. updated.
6.1. RSA Signing Algorithms 6.1. RSA Signing Algorithms
There are different points of view on whether the RS256, RS384, and There are different points of view on whether the RS256, RS384, and
RS512 algorithms should be considered fully-specified or not, because RS512 algorithms should be considered fully specified or not, because
they can operate on keys of different sizes. For instance, they can they can operate on keys of different sizes. For instance, they can
use both 2048- and 4096-bit keys. The same is true of the PS* use both 2048- and 4096-bit keys. The same is true of the PS*
algorithms. algorithms.
This document does not describe or request registration of any fully This document does not describe or request registration of any fully-
specified RSA algorithms. Some RSA signing implementations, such as specified RSA algorithms. Some RSA signing implementations, such as
FIPS-compliant Hardware Security Modules (HSMs) [FIPS.140-3] limit FIPS-compliant Hardware Security Modules (HSMs) [FIPS.140-3] limit
RSA key parameters to specific values with acceptable security RSA key parameters to specific values with acceptable security
characteristics. This approach could be extended to define fully- characteristics. This approach could be extended to define fully-
specified RSA algorithms in the future. specified RSA algorithms in the future.
That said, should it be useful at some point to have RSA algorithm That said, should it be useful at some point to have RSA algorithm
identifiers that are specific to particular key characteristics, a identifiers that are specific to particular key characteristics, a
future specification could always register them. future specification could always register them.
6.2. ECDH Key Agreement Algorithms 6.2. ECDH Key Agreement Algorithms
This specification does not update the Elliptic Curve Diffie-Hellman This specification does not update the ECDH algorithms, but it
(ECDH) algorithms, but describes how to potentially do so in the describes how to potentially do so in the future, if needed. The
future, if needed. The registered JOSE and COSE ECDH algorithms are registered JOSE and COSE ECDH algorithms are polymorphic because they
polymorphic because they do not specify the curve to be used for the do not specify the curve to be used for the ephemeral key.
ephemeral key.
Fully-specified versions of these algorithms would specify all Fully-specified versions of these algorithms would specify all
choices needed, including the KDF and the curve. For instance, an choices needed, including the KDF and the curve. For instance, an
algorithm performing ECDH-ES using the Concat KDF and the P-256 algorithm performing ECDH-ES using the Concat KDF and the P-256 curve
curve, would be fully-specified and could be defined and registered. would be fully specified and could be defined and registered. While
While this specification does not define and register such this specification does not define and register such replacement
replacement algorithms, other specifications could do so in the algorithms, other specifications could do so in the future, if
future, if desired. desired.
6.3. HSS/LMS Hash-Based Digital Signature Algorithm 6.3. HSS/LMS Hash-Based Digital Signature Algorithm
The HSS-LMS algorithm registered by COSE is polymorphic. It is The HSS-LMS algorithm registered by COSE is polymorphic. It is
polymorphic because the algorithm identifier does not specify the polymorphic because the algorithm identifier does not specify the
hash function to be used. Like ECDH, this specification does not hash function to be used. Like ECDH, this specification does not
register replacement algorithms, but future specifications could do register replacement algorithms, but future specifications could do
so. so.
7. Security Considerations 7. Security Considerations
skipping to change at page 15, line 18 skipping to change at line 643
An "attack signature" is a unique pattern or characteristic used to An "attack signature" is a unique pattern or characteristic used to
identify malicious activity, enabling systems to detect and respond identify malicious activity, enabling systems to detect and respond
to known threats. The digital signature and key establishment to known threats. The digital signature and key establishment
algorithms used by software can contribute to an attack signature. algorithms used by software can contribute to an attack signature.
By varying the identifier used for an algorithm, some software By varying the identifier used for an algorithm, some software
systems may attempt to evade rule-based detection and classification. systems may attempt to evade rule-based detection and classification.
Rule-based detection and classification systems may need to update Rule-based detection and classification systems may need to update
their rules to account for fully-specified algorithms. These systems their rules to account for fully-specified algorithms. These systems
should be aware that writing rules for polymorphic algorithms is more should be aware that writing rules for polymorphic algorithms is more
difficult, as each variant of the algorithm must be accounted for. difficult, as each variant of the algorithm must be accounted for.
For example, ES384 in COSE might be used with 3 different keys, each For example, ES384 in COSE might be used with three different keys,
with a different curve. each with a different curve.
A cryptographic key MUST be used with only a single algorithm unless A cryptographic key MUST be used with only a single algorithm unless
the use of the same key with different algorithms is proven secure. the use of the same key with different algorithms is proven secure.
See [Reuse25519] for an example of such a proof. As a result, it is See [Reuse25519] for an example of such a proof. As a result, it is
RECOMMENDED that the algorithm parameter of JSON Web Keys and COSE RECOMMENDED that the algorithm parameter of JSON Web Keys and COSE
Keys be present, unless there exists some other mechanism for Keys be present, unless there exists some other mechanism for
ensuring the key is used as intended. ensuring that the key is used as intended.
In COSE, preventing cross-protocol attacks, such as those described In COSE, preventing cross-protocol attacks, such as those described
in [RFC9459], can be accomplished in two ways: in [RFC9459], can be accomplished in two ways:
1. Allow only authenticated content encryption (AEAD) algorithms. 1. Allow only authenticated content encryption (Authenticated
Encryption with Associated Data (AEAD)) algorithms.
2. Bind the potentially unauthenticated content encryption algorithm 2. Bind the potentially unauthenticated content encryption algorithm
to be used into the key protection algorithm so that different to be used to the key protection algorithm so that different
content encryption algorithms result in different content content encryption algorithms result in different content
encryption keys. encryption keys.
Which choice to use in which circumstances is beyond the scope of Which choice to use in which circumstances is beyond the scope of
this specification. this specification.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/info/rfc8037>. <https://www.rfc-editor.org/info/rfc8037>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 16, line 29 skipping to change at line 700
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/info/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/info/rfc9053>. August 2022, <https://www.rfc-editor.org/info/rfc9053>.
8.2. Informative References 8.2. Informative References
[FIDO2] Bradley, J., Jones, M., Kumar, A., Lindemann, R., Johan, [FIDO2] Bradley, J., Jones, M.B., Kumar, A., Lindemann, R.,
J., and D. David, "Client to Authenticator Protocol Verrept, J., and D. Waite, "Client to Authenticator
(CTAP)", FIDO Alliance Proposed Standard, 28 February Protocol (CTAP)", FIDO Alliance Proposed Standard, 14 July
2025, <https://fidoalliance.org/specs/fido-v2.2-ps- 2025, <https://fidoalliance.org/specs/fido-v2.2-ps-
20250228/fido-client-to-authenticator-protocol-v2.2-ps- 20250714/fido-client-to-authenticator-protocol-v2.2-ps-
20250228.html>. 20250714.html>.
[FIPS.140-3] [FIPS.140-3]
National Institute of Standards and Technology (NIST), NIST, "Security Requirements for Cryptographic Modules",
"Security Requirements for Cryptographic Modules", NIST FIPS 140-3, DOI 10.6028/NIST.FIPS.140-3, March 2019,
FIPS PUB 140-3, 22 March 2019,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.140-3.pdf>. NIST.FIPS.140-3.pdf>.
[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/>.
[OpenID.Discovery] [OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M.B., and E. Jay, Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
"OpenID Connect Discovery 1.0", 15 December 2023, Connect Discovery 1.0 incorporating errata set 2", 15
<https://openid.net/specs/openid-connect-discovery- December 2023, <https://openid.net/specs/openid-connect-
1_0.html>. discovery-1_0.html>.
[Reuse25519] [Reuse25519]
Thormarker, E., "On using the same key pair for Ed25519 Thormarker, E., "On using the same key pair for Ed25519
and an X25519 based KEM", 23 April 2021, and an X25519 based KEM", 23 April 2021,
<https://eprint.iacr.org/2021/509.pdf>. <https://eprint.iacr.org/2021/509.pdf>.
[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/info/rfc7518>. <https://www.rfc-editor.org/info/rfc7518>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414, Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018, DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
skipping to change at page 17, line 47 skipping to change at line 768
[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/info/rfc9054>. 2022, <https://www.rfc-editor.org/info/rfc9054>.
[RFC9459] Housley, R. and H. Tschofenig, "CBOR Object Signing and [RFC9459] Housley, R. and H. Tschofenig, "CBOR Object Signing and
Encryption (COSE): AES-CTR and AES-CBC", RFC 9459, Encryption (COSE): AES-CTR and AES-CBC", RFC 9459,
DOI 10.17487/RFC9459, September 2023, DOI 10.17487/RFC9459, September 2023,
<https://www.rfc-editor.org/info/rfc9459>. <https://www.rfc-editor.org/info/rfc9459>.
[WebAuthn] Hodges, J., Jones, J.C., Jones, M.B., Kumar, A., and E. [WebAuthn] Hodges, J., Ed., Jones, J.C., Ed., Jones, M.B., Ed.,
Lundberg, "Web Authentication: An API for accessing Public Kumar, A., Ed., and E. Lundberg, Ed., "Web Authentication:
Key Credentials - Level 2", World Wide Web Consortium An API for accessing Public Key Credentials - Level 2",
(W3C) Recommendation, 8 April 2021, W3C Recommendation, 8 April 2021,
<https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>. <https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>.
Appendix A. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]]
-13
* Applied suggestions by Mike Bishop and Paul Wouters.
-12
* Changed requested COSE assignments for ESP384, ESP512, Ed25519,
and Ed448 due to conflicts with the new ML-DSA assignments.
-11
* Stated in the abstract that the specification deprecates some
polymorphic algorithm identifiers, as suggested by Éric Vyncke.
-10
* Provided a complete list of the Recommended column terms for COSE
registrations, as suggested by Mohamed Boucadair.
* Applied suggestions to improve the exposition received during IESG
review.
-09
* Addressed comments from secdir review by Kathleen Moriarty.
-08
* Updated requested Brainpool algorithm numbers to match those
chosen by Sean Turner.
* Incorporated wording suggestions by Vijay Gurbani.
-07
* Addressed Deb Cooley's Area Director feedback. Specifically:
- Significantly simplified the encryption description.
- Removed the appendix on polymorphic ECDH algorithms.
* Stated that HSS-LMS is not fully specified, as suggested by John
Preuß Mattsson.
-06
* Corrected inconsistencies identified during the 2nd WGLC.
* Added terminology remark about the "cipher suite" and "à la carte"
approaches.
-05
* Applied IANA early review comments.
-04
* Removed ECDH registrations and proposed fully-specified ECDH
algorithm identifiers, per feedback at IETF 120.
* Tightened descriptive text for fully-specified encryption
algorithms.
* Applied John Mattsson's suggestion for the RSA section title.
-03
* Acknowledged contributions made during Working Group Last Call.
* Addressed security considerations feedback from WGLC.
* Made COSE Recommended status for Ed25519 and Ed448 "yes".
* Registered COSE algorithms for using Brainpool curves with ECDSA.
* Removed text on KEMs, since currently registered algorithms don't
use them.
* Enabled use of fully-specified ECDH algorithms.
* Defined the terms "Deprecated" and "Prohibited" for both JOSE and
COSE registrations.
-02
* Expanded references for KEMs.
* Added example of a fully-specified KEM.
-01
* Included additional instructions for IANA.
* Added text on KEMs and Encapsulated keys.
* Added the section Fully-Specified Computations Using Multiple
Algorithms.
-00
* Created initial working group version based on draft-jones-jose-
fully-specified-algorithms-02.
Acknowledgements Acknowledgements
The authors thank Mike Bishop, Carsten Bormann, Mohamed Boucadair, The authors thank Mike Bishop, Carsten Bormann, Mohamed Boucadair,
John Bradley, Tim Bray, Brian Campbell, Deb Cooley, Roman Danyliw, John Bradley, Tim Bray, Brian Campbell, Deb Cooley, Roman Danyliw,
Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil
Madden, John Preuß Mattsson, Kathleen Moriarty, Jeremy O'Donoghue, Madden, Kathleen Moriarty, Jeremy O'Donoghue, John Preuß Mattsson,
Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes
Tschofenig, Sean Turner, Éric Vyncke, David Waite, Paul Wouters, and Tschofenig, Sean Turner, Éric Vyncke, David Waite, Paul Wouters, and
Jiankang Yao for their contributions to this specification. Jiankang Yao for their contributions to this specification.
Authors' Addresses Authors' Addresses
Michael B. Jones Michael B. Jones
Self-Issued Consulting Self-Issued Consulting
Email: michael_b_jones@hotmail.com Email: michael_b_jones@hotmail.com
URI: https://self-issued.info/ URI: https://self-issued.info/
Orie Steele Orie Steele
Transmute Tradeverifyd
Email: orie@transmute.industries Email: orie@or13.io
 End of changes. 79 change blocks. 
449 lines changed or deleted 339 lines changed or added

This html diff was produced by rfcdiff 1.48.