rfc9864v1.txt   rfc9864.txt 
Internet Engineering Task Force (IETF) M.B. Jones Internet Engineering Task Force (IETF) M.B. Jones
Request for Comments: 9864 Self-Issued Consulting Request for Comments: 9864 Self-Issued Consulting
Updates: 7518, 8037, 9053 O. Steele Updates: 7518, 8037, 9053 O. Steele
Category: Standards Track Transmute Category: Standards Track Transmute
ISSN: 2070-1721 September 2025 ISSN: 2070-1721 September 2025
Fully Specified Algorithms for JSON Object Signing and Encryption (JOSE) Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE)
and CBOR Object Signing and Encryption (COSE) 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 RFCs 7518, 8037, and 9053. It deprecates This specification updates RFCs 7518, 8037, and 9053. It deprecates
polymorphic algorithms defined by RFCs 8037 and 9053 and provides polymorphic algorithms defined by RFCs 8037 and 9053 and provides
fully specified replacements for them. It adds to the instructions fully-specified replacements for them. It adds to the instructions
to designated experts in RFCs 7518 and 9053. to designated experts in RFCs 7518 and 9053.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
skipping to change at line 64 skipping to change at line 64
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
2. Fully Specified Digital Signature Algorithm Identifiers 2. Fully-Specified Digital Signature Algorithm Identifiers
2.1. Elliptic Curve Digital Signature Algorithm (ECDSA) 2.1. Elliptic Curve Digital Signature Algorithm (ECDSA)
2.2. Edwards-curve Digital Signature Algorithm (EdDSA) 2.2. Edwards-curve Digital Signature Algorithm (EdDSA)
3. Fully Specified Encryption 3. Fully-Specified Encryption
3.1. Fully Specified Encryption Algorithms 3.1. Fully-Specified Encryption Algorithms
3.2. Polymorphic Encryption Algorithms 3.2. Polymorphic Encryption Algorithms
4. IANA Considerations 4. IANA Considerations
4.1. JOSE Algorithm Registrations 4.1. JOSE Algorithm Registrations
4.1.1. Fully Specified JOSE Algorithm Registrations 4.1.1. Fully-Specified JOSE Algorithm Registrations
4.1.2. Deprecated Polymorphic JOSE Algorithm Registration 4.1.2. Deprecated Polymorphic JOSE Algorithm Registration
4.2. COSE Algorithm Registrations 4.2. COSE Algorithm Registrations
4.2.1. Fully Specified COSE Algorithm Registrations 4.2.1. Fully-Specified COSE Algorithm Registrations
4.2.2. Deprecated Polymorphic COSE Algorithm Registrations 4.2.2. Deprecated Polymorphic COSE Algorithm Registrations
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
4.3.2. COSE Algorithms 4.3.2. COSE Algorithms
4.4. Defining "Deprecated" and "Prohibited" 4.4. Defining "Deprecated" and "Prohibited"
5. Key Representations 5. Key Representations
6. Notes on Algorithms Not Updated 6. Notes on Algorithms Not Updated
6.1. RSA Signing Algorithms 6.1. RSA Signing Algorithms
6.2. ECDH Key Agreement Algorithms 6.2. ECDH Key Agreement Algorithms
6.3. HSS/LMS Hash-Based Digital Signature Algorithm 6.3. HSS/LMS Hash-Based Digital Signature Algorithm
skipping to change at line 143 skipping to change at line 143
-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 "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.
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
fully 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 | -9 | ECDSA using P-256 curve and | Yes | | ESP256 | -9 | ECDSA using P-256 curve and | Yes |
| | | SHA-256 | | | | | SHA-256 | |
+--------+------------+-----------------------------+-------------+ +--------+------------+-----------------------------+-------------+
| ESP384 | -51 | ECDSA using P-384 curve and | Yes | | ESP384 | -51 | ECDSA using P-384 curve and | Yes |
skipping to change at line 213 skipping to change at line 213
+--------+------------+-----------------------------+-------------+ +--------+------------+-----------------------------+-------------+
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 EdDSA with JOSE, and [RFC9053] defines [RFC8037] defines a way to use EdDSA with JOSE, and [RFC9053] defines
a way to use it with COSE. Both register polymorphic EdDSA algorithm a way to use it 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 | Description | JOSE | COSE | | Name | COSE | Description | JOSE | COSE |
| | Value | | Implementation | Recommended | | | Value | | Implementation | Recommended |
| | | | Requirements | | | | | | Requirements | |
+=========+=======+=============+=====================+=============+ +=========+=======+=============+=====================+=============+
| Ed25519 | -19 | EdDSA using | Optional | Yes | | Ed25519 | -19 | EdDSA using | Optional | Yes |
| | | Ed25519 | | | | | | Ed25519 | | |
| | | curve | | | | | | curve | | |
+---------+-------+-------------+---------------------+-------------+ +---------+-------+-------------+---------------------+-------------+
| Ed448 | -53 | EdDSA using | Optional | Yes | | Ed448 | -53 | EdDSA using | Optional | Yes |
| | | Ed448 curve | | | | | | Ed448 curve | | |
+---------+-------+-------------+---------------------+-------------+ +---------+-------+-------------+---------------------+-------------+
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 Encrypt, 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, encryption via all parameters for symmetric encryption. For example, encryption via
JWE using an "alg" value of "A128KW" (AES Key Wrap using 128-bit key) JWE using an "alg" value of "A128KW" (AES Key Wrap using 128-bit key)
and an "enc" value of "A128GCM" (AES GCM using 128-bit key) uses and an "enc" value of "A128GCM" (AES GCM using 128-bit key) uses
fully 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. For example, the keydatalen KDF parameter value for "ECDH-ES" value. For example, the keydatalen KDF parameter value for "ECDH-ES"
is determined from the "enc" value, as described in Section 4.6.2 of is determined from the "enc" value, as described in Section 4.6.2 of
[RFC7518]. For the purposes of an "alg" value being fully specified, [RFC7518]. For the purposes of an "alg" value being fully specified,
deriving parameters from "enc" does not make the algorithm deriving parameters from "enc" does not make the algorithm
polymorphic, as the computation is still fully determined by the polymorphic, as the computation is still fully determined by the
algorithm identifiers used. This option is not present in COSE. algorithm identifiers used. This option is not present in 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 MUST specify all parameters for key establishment, and the inner
"alg" value must specify all parameters for symmetric encryption. "alg" value must specify all parameters for symmetric encryption.
For example, encryption via COSE using an outer "alg" value of For example, encryption via COSE using an outer "alg" value of
"A128KW" and an inner "alg" value of "A128GCM" uses fully specified "A128KW" and an inner "alg" value of "A128GCM" uses fully-specified
algorithms. Note that when using COSE_Encrypt, as specified in algorithms. Note that when using COSE_Encrypt, as specified in
Section 5.1 of [RFC9052], the outer "alg" is communicated in the Section 5.1 of [RFC9052], the outer "alg" is communicated in the
headers of the COSE_Encrypt object and the inner "alg" is headers of the COSE_Encrypt object and the inner "alg" is
communicated in the 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 key wrapping with AES GCM algorithms. An
example of a fully specified key wrapping algorithm is "A128KW" (AES example of a fully-specified key wrapping algorithm is "A128KW" (AES
Key Wrap using 128-bit key). 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 Key Encryption with PBES2 algorithms 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
skipping to change at line 330 skipping to change at line 330
4. IANA Considerations 4. IANA Considerations
4.1. JOSE Algorithm Registrations 4.1. JOSE Algorithm Registrations
IANA has registered the values in this section in the "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 [RFC7518] and has listed this document as an additional reference by [RFC7518] and has listed this document as an additional reference
for the registry. 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 Ed25519 curve
Algorithm Usage Locations: alg Algorithm Usage Locations: alg
JOSE Implementation Requirements: Optional JOSE Implementation Requirements: Optional
Change Controller: IETF Change Controller: IETF
Reference: Section 2.2 of RFC 9864 Reference: Section 2.2 of RFC 9864
Algorithm Analysis Document(s): [RFC8032] Algorithm Analysis Document(s): [RFC8032]
Algorithm Name: Ed448 Algorithm Name: Ed448
skipping to change at line 367 skipping to change at line 367
Change Controller: IETF Change Controller: IETF
Reference: Section 2.2 of RFC 9864 Reference: Section 2.2 of RFC 9864
Algorithm Analysis Document(s): [RFC8032] Algorithm Analysis Document(s): [RFC8032]
4.2. COSE Algorithm Registrations 4.2. COSE Algorithm Registrations
IANA has registered the following values in the "COSE Algorithms" IANA has registered the following values in the "COSE Algorithms"
registry [IANA.COSE] established by [RFC9053] and [RFC9054] and has registry [IANA.COSE] established by [RFC9053] and [RFC9054] and has
added this document as an additional reference for the registry. 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: -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 RFC 9864 Reference: Section 2.1 of RFC 9864
Recommended: Yes Recommended: Yes
Name: ESP384 Name: ESP384
skipping to change at line 487 skipping to change at line 487
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
The review instructions for the designated experts [RFC8126] for the The review instructions for the designated experts [RFC8126] for the
"JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE] "JSON Web Signature and Encryption Algorithms" registry [IANA.JOSE]
in Section 7.1 of [RFC7518] have been updated to include an in Section 7.1 of [RFC7518] have been updated to include an
additional review criterion: 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
The review instructions for the designated experts [RFC8126] for the The review instructions for the designated experts [RFC8126] for the
"COSE Algorithms" registry [IANA.COSE] in Section 10.4 of [RFC9053] "COSE Algorithms" registry [IANA.COSE] in Section 10.4 of [RFC9053]
have been updated to include an additional review criterion: 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". This section defines these terms for use by both JOSE
and COSE IANA registrations in a consistent manner, eliminating this and COSE IANA registrations in a consistent manner, eliminating this
skipping to change at line 556 skipping to change at line 556
"MUST NOT be used". "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
skipping to change at line 578 skipping to change at line 578
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 ECDH algorithms, but it This specification does not update the ECDH algorithms, but it
describes how to potentially do so in the future, if needed. The describes how to potentially do so in the future, if needed. The
registered JOSE and COSE ECDH algorithms are polymorphic because they registered JOSE and COSE ECDH algorithms are polymorphic because they
do not specify the curve to be used for the ephemeral key. do not specify the curve to be used for the 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 curve algorithm performing ECDH-ES using the Concat KDF and the P-256 curve
would be fully specified and could be defined and registered. While would be fully specified and could be defined and registered. While
this specification does not define and register such replacement this specification does not define and register such replacement
algorithms, other specifications could do so in the future, if algorithms, other specifications could do so in the 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
skipping to change at line 627 skipping to change at line 627
The security considerations for preventing cross-protocol attacks The security considerations for preventing cross-protocol attacks
described in [RFC9459] apply. described in [RFC9459] apply.
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 three different keys, For example, ES384 in COSE might be used with three different keys,
each 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
 End of changes. 35 change blocks. 
36 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.48.