rfc9864xml2.original.xml   rfc9864.xml 
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/r
fc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "http://xml2rfc.tools.ietf.org/
authoring/rfc2629.dtd">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" <!DOCTYPE rfc [
category="std" ipr="trust200902" <!ENTITY nbsp "&#160;">
docName="draft-ietf-jose-fully-specified-algorithms-13" <!ENTITY zwsp "&#8203;">
updates="7518, 8037, 9053"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
<?rfc tocompact="yes"?> submissionType="IETF" consensus="true" docName="draft-ietf-jose-fully-specified
<?rfc tocdepth="5"?> -algorithms-13" number="9864" updates="7518, 8037, 9053" obsoletes="" tocInclude
<?rfc tocindent="yes"?> ="true" tocDepth="5" symRefs="true" sortRefs="true" version="3" xml:lang="en">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front> <front>
<title abbrev="Fully-Specified Algorithms">Fully-Specified Algorithms for JS
<title abbrev="Fully-Specified Algorithms">Fully-Specified Algorithms for JO ON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (
SE and COSE</title> COSE)</title>
<seriesInfo name="RFC" value="9864"/>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones"> <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization>Self-Issued Consulting</organization> <organization>Self-Issued Consulting</organization>
<address> <address>
<email>michael_b_jones@hotmail.com</email> <email>michael_b_jones@hotmail.com</email>
<uri>https://self-issued.info/</uri> <uri>https://self-issued.info/</uri>
</address> </address>
</author> </author>
<author fullname="Orie Steele" initials="O." surname="Steele"> <author fullname="Orie Steele" initials="O." surname="Steele">
<organization>Transmute</organization> <organization>Tradeverifyd</organization>
<address> <address>
<email>orie@transmute.industries</email> <email>orie@or13.io</email>
</address> </address>
</author> </author>
<date month="October" year="2025"/>
<date day="10" month="May" year="2025" /> <area>SEC</area>
<workgroup>jose</workgroup>
<area>Security</area>
<workgroup>JOSE Working Group</workgroup>
<keyword>Cryptographic Algorithm Identifiers</keyword> <keyword>Cryptographic Algorithm Identifiers</keyword>
<keyword>JSON Object Signing and Encryption (JOSE)</keyword> <keyword>JSON Object Signing and Encryption (JOSE)</keyword>
<keyword>CBOR Object Signing and Encryption (COSE)</keyword> <keyword>CBOR Object Signing and Encryption (COSE)</keyword>
<keyword>Polymorphic Algorithms</keyword> <keyword>Polymorphic Algorithms</keyword>
<keyword>Algorithm Cipher Suites</keyword> <keyword>Algorithm Cipher Suites</keyword>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t> <t>
This specification refers to cryptographic algorithm identifiers This specification refers to cryptographic algorithm identifiers
that fully specify the cryptographic operations to be performed, that fully specify the cryptographic operations to be performed,
including any curve, key derivation function (KDF), and hash functions, including any curve, key derivation function (KDF), and hash functions,
as being "fully specified". as being "fully specified".
It refers to cryptographic algorithm identifiers It refers to cryptographic algorithm identifiers
that require additional information beyond the algorithm identifier that require additional information beyond the algorithm identifier
to determine the cryptographic operations to be performed to determine the cryptographic operations to be performed
as being "polymorphic". as being "polymorphic".
This specification creates fully-specified algorithm identifiers for regi stered This specification creates fully-specified algorithm identifiers for regi stered
JSON Object Signing and Encryption (JOSE) and JSON Object Signing and Encryption (JOSE) and
CBOR Object Signing and Encryption (COSE) CBOR Object Signing and Encryption (COSE)
polymorphic algorithm identifiers, polymorphic algorithm identifiers,
enabling applications to use only fully-specified algorithm identifiers. enabling applications to use only fully-specified algorithm identifiers.
It deprecates those polymorphic algorithm identifiers. It deprecates those polymorphic algorithm identifiers.
</t> </t>
<t> <t>
This specification updates RFC 7518, RFC 8037, and RFC 9053. This specification updates RFCs 7518, 8037, and 9053.
It deprecates polymorphic algorithms defined by RFC 8037 and RFC 9053 It deprecates polymorphic algorithms defined by RFCs 8037 and 9053
and provides fully-specified replacements for them. and provides fully-specified replacements for them.
It adds to the instructions to designated experts in RFC 7518 and RFC 905 3. It adds to the instructions to designated experts in RFCs 7518 and 9053.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction">
<section anchor="Introduction" title="Introduction"> <name>Introduction</name>
<t> <t>
The IANA algorithm registries for The IANA algorithm registries for
JSON Object Signing and Encryption (JOSE) algorithms <xref target="IANA.J OSE"/> and JSON Object Signing and Encryption (JOSE) algorithms <xref target="IANA.J OSE"/> and
CBOR Object Signing and Encryption (COSE) algorithms <xref target="IANA.C OSE"/> CBOR Object Signing and Encryption (COSE) algorithms <xref target="IANA.C OSE"/>
contain two kinds of algorithm identifiers: contain two kinds of algorithm identifiers:
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>Fully Specified</dt>
<dd>
<t hangText="Fully Specified">
<vspace/>
Those that fully determine the cryptographic operations to be perform ed, Those that fully determine the cryptographic operations to be perform ed,
including any curve, key derivation function (KDF), and hash function s. including any curve, key derivation function (KDF), and hash function s.
Examples are <spanx style="verb">RS256</spanx> and <spanx style="verb ">ES256K</spanx> Examples are <tt>RS256</tt> and <tt>ES256K</tt>
in both JOSE <xref target="IANA.JOSE"/> and COSE <xref target="IANA.C OSE"/> in both JOSE <xref target="IANA.JOSE"/> and COSE <xref target="IANA.C OSE"/>
and <spanx style="verb">ES256</spanx> in JOSE. and <tt>ES256</tt> in JOSE.
</t> </dd>
<dt>Polymorphic</dt>
<t hangText="Polymorphic"> <dd>
<vspace/>
Those requiring information beyond the algorithm identifier Those requiring information beyond the algorithm identifier
to determine the cryptographic operations to be performed. to determine the cryptographic operations to be performed.
Such additional information could include the actual key value and a curve that it uses. Such additional information could include the actual key value and a curve that it uses.
Examples are <spanx style="verb">EdDSA</spanx> Examples are the Edwards-curve Digital Signature Algorithm (EdDSA)
in both JOSE <xref target="IANA.JOSE"/> and COSE <xref target="IANA.C OSE"/> in both JOSE <xref target="IANA.JOSE"/> and COSE <xref target="IANA.C OSE"/>
and <spanx style="verb">ES256</spanx> in COSE. and <tt>ES256</tt> in COSE.
</t> </dd>
</dl>
</list>
</t>
<t> <t>
This matters because many protocols negotiate supported operations using only algorithm identifiers. This matters because many protocols negotiate supported operations using only algorithm identifiers.
For instance, OAuth Authorization Server Metadata <xref target="RFC8414"/ > For instance, OAuth Authorization Server Metadata <xref target="RFC8414"/ >
uses negotiation parameters like these (from an example in the specificat uses negotiation parameters like these (from an example in that specifica
ion): tion):
<figure><artwork><![CDATA[ </t>
<artwork><![CDATA[
"token_endpoint_auth_signing_alg_values_supported": "token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"] ["RS256", "ES256"]
]]></artwork></figure> ]]></artwork>
</t>
<t> <t>
OpenID Connect Discovery <xref target="OpenID.Discovery"/> likewise negot iates supported algorithms OpenID Connect Discovery <xref target="OpenID.Discovery"/> likewise negot iates supported algorithms
using <spanx style="verb">alg</spanx> and <spanx style="verb">enc</spanx> values. using <tt>"alg"</tt> and <tt>"enc"</tt> values.
W3C Web Authentication <xref target="WebAuthn"/> and W3C Web Authentication <xref target="WebAuthn"/> and
FIDO Client to Authenticator Protocol (CTAP) <xref target="FIDO2"/> the FIDO Client to Authenticator Protocol (CTAP) <xref target="FIDO2"/>
negotiate using COSE <spanx style="verb">alg</spanx> numbers. negotiate using COSE <tt>"alg"</tt> numbers.
</t> </t>
<t> <t>
This does not work for polymorphic algorithms. This does not work for polymorphic algorithms.
For instance, with <spanx style="verb">EdDSA</spanx>, it is not known whi For instance, with <tt>EdDSA</tt>, it is not known which of the curves
ch of the curves <tt>Ed25519</tt> and/or <tt>Ed448</tt> are supported.
<spanx style="verb">Ed25519</spanx> and/or <spanx style="verb">Ed448</spa
nx> are supported.
This causes real problems in practice. This causes real problems in practice.
</t> </t>
<t> <t>
WebAuthn contains this de-facto algorithm definition to work around this WebAuthn contains this de facto algorithm definition to work around this
problem: problem:
<figure><artwork><![CDATA[
-8 (EdDSA), where crv is 6 (Ed25519)
]]></artwork></figure>
</t> </t>
<artwork><![CDATA[
-8 (EdDSA), where crv is 6 (Ed25519)
]]></artwork>
<t> <t>
This redefines the COSE <spanx style="verb">EdDSA</spanx> algorithm ident ifier This redefines the COSE <tt>EdDSA</tt> algorithm identifier
for the purposes of WebAuthn to restrict it to using for the purposes of WebAuthn to restrict it to using
the <spanx style="verb">Ed25519</spanx> curve - making it non-polymorphic the <tt>Ed25519</tt> curve -- making it non-polymorphic
so that algorithm negotiation can succeed, but also effectively so that algorithm negotiation can succeed, but also effectively
eliminating the possibility of using <spanx style="verb">Ed448</spanx>. eliminating the possibility of using <tt>Ed448</tt>.
Other similar workarounds for polymorphic algorithm identifiers are used in practice. Other similar workarounds for polymorphic algorithm identifiers are used in practice.
</t> </t>
<t> <t>
Note that using fully-specified algorithms is sometimes Note that using fully-specified algorithms is sometimes
referred to as the "cipher suite" approach; referred to as the "cipher suite" approach;
using polymorphic algorithms is sometimes using polymorphic algorithms is sometimes
referred to as the "à la carte" approach. referred to as the "à la carte" approach.
</t> </t>
<t> <t>
This specification creates fully-specified algorithm identifiers for regi stered This specification creates fully-specified algorithm identifiers for regi stered
polymorphic JOSE and COSE algorithms and their parameters, polymorphic JOSE and COSE algorithms and their parameters,
enabling applications to use only fully-specified algorithm identifiers. enabling applications to use only fully-specified algorithm identifiers.
Furthermore, it deprecates the practice of registering polymorphic algori thm identifiers. Furthermore, it deprecates the practice of registering polymorphic algori thm identifiers.
</t> </t>
<section anchor="rnc">
<section anchor="rnc" title="Requirements Notation and Conventions"> <name>Requirements Notation and Conventions</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>SHOULD NOT</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</t> are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="fully-specified-algs">
<section anchor="fully-specified-algs" title="Fully-Specified Digital Signat <name>Fully-Specified Digital Signature Algorithm Identifiers</name>
ure Algorithm Identifiers">
<t> <t>
This section creates fully-specified digital signature algorithm identifi ers for a set of registered This section creates fully-specified digital signature algorithm identifi ers for a set of registered
polymorphic JOSE and COSE algorithms and their parameters. polymorphic JOSE and COSE algorithms and their parameters.
</t> </t>
<section anchor="ECDSA">
<section anchor="ECDSA" title="Elliptic Curve Digital Signature Algorithm <name>Elliptic Curve Digital Signature Algorithm (ECDSA)</name>
(ECDSA)"> <t>
<t>
<xref target="RFC9053"/> defines a way to use <xref target="RFC9053"/> defines a way to use
the Elliptic Curve Digital Signature Algorithm (ECDSA) with COSE. the Elliptic Curve Digital Signature Algorithm (ECDSA) with COSE.
The COSE algorithm registrations for ECDSA are polymorphic, The COSE algorithm registrations for ECDSA are polymorphic,
since they do not specify the curve used. since they do not specify the curve used.
For instance, <spanx style="verb">ES256</spanx> is defined as For instance, <tt>ES256</tt> is defined as
"ECDSA w/ SHA-256" in Section 2.1 of <xref target="RFC9053"/>. "ECDSA w/ SHA-256" in <xref target="RFC9053" section="2.1"/>.
(The corresponding JOSE registrations in <xref target="RFC7518"/> are f (The corresponding JOSE registrations in <xref target="RFC7518"/> are f
ull-specified.) ully specified.)
</t> </t>
<t> <t>
The following fully-specified COSE ECDSA algorithms are defined by this specification: The following fully-specified COSE ECDSA algorithms are defined by this specification:
</t> </t>
<texttable anchor="ecdsa-algs" title="ECDSA Algorithm Values" suppress-ti
tle="false" align="center" style="full">
<ttcol align="left">Name</ttcol>
<ttcol align="left">COSE Value</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">COSE Recommended</ttcol>
<c>ESP256</c>
<c>TBD (requested assignment -9)</c>
<c>ECDSA using P-256 curve and SHA-256</c>
<c>Yes</c>
<c>ESP384</c>
<c>TBD (requested assignment -51)</c>
<c>ECDSA using P-384 curve and SHA-384</c>
<c>Yes</c>
<c>ESP512</c>
<c>TBD (requested assignment -52)</c>
<c>ECDSA using P-521 curve and SHA-512</c>
<c>Yes</c>
<c>ESB256</c>
<c>TBD (requested assignment -265)</c>
<c>ECDSA using BrainpoolP256r1 curve and SHA-256</c>
<c>No</c>
<c>ESB320</c>
<c>TBD (requested assignment -266)</c>
<c>ECDSA using BrainpoolP320r1 curve and SHA-384</c>
<c>No</c>
<c>ESB384</c>
<c>TBD (requested assignment -267)</c>
<c>ECDSA using BrainpoolP384r1 curve and SHA-384</c>
<c>No</c>
<c>ESB512</c>
<c>TBD (requested assignment -268)</c>
<c>ECDSA using BrainpoolP512r1 curve and SHA-512</c>
<c>No</c>
</texttable> <table anchor="ecdsa-algs" align="center">
<name>ECDSA Algorithm Values</name>
<thead>
<tr>
<th align="left">Name</th>
<th align="left">COSE Value</th>
<th align="left">Description</th>
<th align="left">COSE Recommended</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">ESP256</td>
<td align="left">-9</td>
<td align="left">ECDSA using P-256 curve and SHA-256</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">ESP384</td>
<td align="left">-51</td>
<td align="left">ECDSA using P-384 curve and SHA-384</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">ESP512</td>
<td align="left">-52</td>
<td align="left">ECDSA using P-521 curve and SHA-512</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">ESB256</td>
<td align="left">-265</td>
<td align="left">ECDSA using BrainpoolP256r1 curve and SHA-256</td
>
<td align="left">No</td>
</tr>
<tr>
<td align="left">ESB320</td>
<td align="left">-266</td>
<td align="left">ECDSA using BrainpoolP320r1 curve and SHA-384</td
>
<td align="left">No</td>
</tr>
<tr>
<td align="left">ESB384</td>
<td align="left">-267</td>
<td align="left">ECDSA using BrainpoolP384r1 curve and SHA-384</td
>
<td align="left">No</td>
</tr>
<tr>
<td align="left">ESB512</td>
<td align="left">-268</td>
<td align="left">ECDSA using BrainpoolP512r1 curve and SHA-512</td
>
<td align="left">No</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="EdDSA">
<section anchor="EdDSA" title="Edwards-Curve Digital Signature Algorithm ( <name>Edwards-curve Digital Signature Algorithm (EdDSA)</name>
EdDSA)"> <t>
<t>
<xref target="RFC8037"/> defines a way to use <xref target="RFC8037"/> defines a way to use
the Edwards-Curve Digital Signature Algorithm (EdDSA) EdDSA
with JOSE and <xref target="RFC9053"/> defines a way to use it with COS with JOSE, and <xref target="RFC9053"/> defines a way to use it with CO
E. SE.
Both register polymorphic <spanx style="verb">EdDSA</spanx> algorithm i Both register polymorphic <tt>EdDSA</tt> algorithm identifiers.
dentifiers. </t>
</t> <t>
<t>
The following fully-specified JOSE and COSE EdDSA algorithms are define d by this specification: The following fully-specified JOSE and COSE EdDSA algorithms are define d by this specification:
</t> </t>
<texttable anchor="eddsa-algs" title="EdDSA Algorithm Values" suppress-ti <table anchor="eddsa-algs" align="center">
tle="false" align="center" style="full"> <name>EdDSA Algorithm Values</name>
<ttcol align="left">Name</ttcol> <thead>
<ttcol align="left">COSE Value</ttcol> <tr>
<ttcol align="left">Description</ttcol> <th align="left">Name</th>
<ttcol align="left">JOSE Implementation Requirements</ttcol> <th align="left">COSE Value</th>
<ttcol align="left">COSE Recommended</ttcol> <th align="left">Description</th>
<th align="left">JOSE Implementation Requirements</th>
<c>Ed25519</c> <th align="left">COSE Recommended</th>
<c>TBD (requested assignment -19)</c> </tr>
<c>EdDSA using Ed25519 curve</c> </thead>
<c>Optional</c> <tbody>
<c>Yes</c> <tr>
<td align="left">Ed25519</td>
<c>Ed448</c> <td align="left">-19</td>
<c>TBD (requested assignment -53)</c> <td align="left">EdDSA using the Ed25519 parameter set in <xref ta
<c>EdDSA using Ed448 curve</c> rget="RFC8032" section="5.1"/></td>
<c>Optional</c> <td align="left">Optional</td>
<c>Yes</c> <td align="left">Yes</td>
</tr>
</texttable> <tr>
<td align="left">Ed448</td>
<td align="left">-53</td>
<td align="left">EdDSA using the Ed448 parameter set in <xref targ
et="RFC8032" section="5.2"/></td>
<td align="left">Optional</td>
<td align="left">Yes</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="fully-specified-enc">
<section anchor="fully-specified-enc" title="Fully-Specified Encryption"> <name>Fully-Specified Encryption</name>
<t> <t>
This section describes the construction of fully-specified encryption alg orithm identifiers in the context of the JOSE and COSE encryption schemes This section describes the construction of fully-specified encryption alg orithm identifiers in the context of the JOSE and COSE encryption schemes
JSON Web Encryption (JWE), as described in <xref target="RFC7516"/> and < JSON Web Encryption (JWE), as described in <xref target="RFC7516"/> and <
xref target="RFC7518"/>, and xref target="RFC7518"/>, and COSE
COSE Encrypt, as described in <xref target="RFC9052"/> and <xref target=" encryption, as described in <xref target="RFC9052"/> and <xref target="RF
RFC9053"/>. C9053"/>.
</t> </t>
<t> <t>
Using fully-specified encryption algorithms enables the sender and receiv er Using fully-specified encryption algorithms enables the sender and receiv er
to agree on all mandatory security parameters. to agree on all mandatory security parameters.
They also enable protocols to specify an allow list of They also enable protocols to specify an allow list of
algorithm combinations that does not include polymorphic combinations, algorithm combinations that does not include polymorphic combinations,
preventing problems preventing problems
such as cross-curve key establishment, such as cross-curve key establishment,
cross-protocol symmetric encryption, cross-protocol symmetric encryption,
or mismatched KDF size to symmetric key scenarios. or mismatched KDF size to symmetric key scenarios.
skipping to change at line 296 skipping to change at line 301
which specifies how to determine the content encryption key, and which specifies how to determine the content encryption key, and
the second in the "enc" (Encryption Algorithm) Header Parameter, the second in the "enc" (Encryption Algorithm) Header Parameter,
which specifies the content encryption algorithm. which specifies the content encryption algorithm.
Likewise, encrypted COSE objects can use multiple algorithms Likewise, encrypted COSE objects can use multiple algorithms
for corresponding purposes. for corresponding purposes.
This section describes how to fully specify encryption algorithms This section describes how to fully specify encryption algorithms
for JOSE and COSE. for JOSE and COSE.
</t> </t>
<t> <t>
To perform fully-specified encryption in JOSE, To perform fully-specified encryption in JOSE,
the "alg" value MUST specify all parameters for key establishment the "alg" value <bcp14>MUST</bcp14> specify all parameters for key establ
or derive some of them from the accompanying "enc" value and ishment
the "enc" value MUST specify all parameters for symmetric encryption. or derive some of them from the accompanying "enc" value, and
For example, JWE encryption using the "enc" value <bcp14>MUST</bcp14> specify all parameters for symmetric
encryption.
For example, encryption via JWE using
an "alg" value of "A128KW" (AES Key Wrap using 128-bit key) and an "alg" value of "A128KW" (AES Key Wrap using 128-bit key) and
an "enc" value of "A128GCM" (AES GCM using 128-bit key) an "enc" value of "A128GCM" (AES GCM using 128-bit key)
uses fully-specified algorithms. uses fully-specified algorithms.
</t> </t>
<t> <t>
Note that in JOSE, there is the option to derive some cryptographic param eters Note that in JOSE, there is the option to derive some cryptographic param eters
used in the "alg" computation from the accompanying "enc" value. used in the "alg" computation from the accompanying "enc" value.
An example of this is that the keydatalen KDF parameter value For example, the keydatalen KDF parameter value
for "ECDH-ES" is determined from the "enc" value, for "ECDH-ES" is determined from the "enc" value,
as described in Section 4.6.2 of <xref target="RFC7518"/>. as described in <xref target="RFC7518" section="4.6.2"/>.
For the purposes of an "alg" value being fully-specified, For the purposes of an "alg" value being fully specified,
deriving parameters from "enc" does not make the algorithm polymorphic, deriving parameters from "enc" does not make the algorithm polymorphic,
as the computation is still fully determined by the algorithm identifiers used. as the computation is still fully determined by the algorithm identifiers used.
This option is not present in COSE. This option is not present in COSE.
</t> </t>
<t> <t>
To perform fully-specified encryption in COSE, To perform fully-specified encryption in COSE,
the outer "alg" value MUST specify all parameters for key establishment a the outer "alg" value <bcp14>MUST</bcp14> specify all parameters for key
nd establishment, and
the inner "alg" value must specify all parameters for symmetric encryptio the inner "alg" value <bcp14>MUST</bcp14> specify all parameters for symm
n. etric encryption.
For example, COSE encryption using For example, encryption via COSE using
an outer "alg" value of A128KW and an outer "alg" value of "A128KW" and
an inner "alg" value of A128GCM an inner "alg" value of "A128GCM"
uses fully-specified algorithms. uses fully-specified algorithms.
Note that when using COSE_Encrypt, Note that when using COSE_Encrypt,
as specified in Section 5.1 of <xref target="RFC9052"/>, as specified in <xref target="RFC9052" section="5.1"/>,
the outer "alg" is communicated in the headers of the COSE_Encrypt object and the outer "alg" is communicated in the headers of the COSE_Encrypt object and
the inner "alg" is communicated in the headers of the COSE_recipient obje ct. the inner "alg" is communicated in the headers of the COSE_recipient obje ct.
</t> </t>
<t> <t>
While this specification provides a definition of what While this specification provides a definition of what
fully-specified encryption algorithm identifiers are for both JOSE and CO SE, fully-specified encryption algorithm identifiers are for both JOSE and CO SE,
it does not deprecate any polymorphic encryption algorithms, 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 <xref target="ECDH"/>. This is discussed in <xref target="ECDH"/>.
</t> </t>
<section anchor="fully-spec-enc-algs">
<section anchor="fully-spec-enc-algs" title="Fully-Specified Encryption Al <name>Fully-Specified Encryption Algorithms</name>
gorithms"> <t>
<t>
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.
</t> </t>
<t> <t>
All the symmetric encryption algorithms registered by <xref target="RFC 7518"/> All the symmetric encryption algorithms registered by <xref target="RFC 7518"/>
and <xref target="RFC9053"/> are fully-specified. and <xref target="RFC9053"/> are fully specified.
An example of a fully-specified symmetric encryption algorithm is An example of a fully-specified symmetric encryption algorithm is
"A128GCM" (AES GCM using 128-bit key). "A128GCM" (AES GCM using 128-bit key).
</t> </t>
<t> <t>
In both JOSE and COSE, In both JOSE and COSE,
all registered key wrapping algorithms are fully specified, all registered key wrapping algorithms are fully specified,
as are the key wrapping with AES GCM algorithms. as are the algorithms performing key wrapping using AES GCM.
An example of a fully-specified key wrapping algorithm is An example of a fully-specified key wrapping algorithm is
"A128KW" (AES Key Wrap using 128-bit key). "A128KW" (AES Key Wrap using 128-bit key).
</t> </t>
<t> <t>
The JOSE "dir" and COSE "direct" algorithms are fully specified. The JOSE "dir" and COSE "direct" algorithms are fully specified.
The COSE direct+HKDF algorithms are fully specified. The COSE direct+HKDF algorithms are fully specified.
</t> </t>
<t> <t>
The JOSE Key Encryption with PBES2 algorithms are fully specified. The JOSE algorithms performing Key Encryption with PBES2 are fully spec
</t> ified.
</t>
</section> </section>
<section anchor="polymorphic-enc-algs">
<section anchor="polymorphic-enc-algs" title="Polymorphic Encryption Algor <name>Polymorphic Encryption Algorithms</name>
ithms"> <t>
<t>
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.
</t> </t>
<t> <t>
The ECDH key establishment algorithms in both JOSE and COSE The Elliptic Curve Diffie-Hellman (ECDH) key establishment algorithms i
n both JOSE and COSE
are polymorphic because they do not specify the elliptic curve are polymorphic because they do not specify the elliptic curve
to be used for the key. to be used for the key.
This is true of the ephemeral key for the Ephemeral-Static (ES) algorit hms This is true of the ephemeral key for the Ephemeral-Static (ES) algorit hms
registered for JOSE and COSE and of the static key for registered for JOSE and COSE and of the static key for
the Static-Static (SS) algorithms registered by COSE. the Static-Static (SS) algorithms registered by COSE.
See more discussion of ECDH algorithms in <xref target="ECDH"/>. See more discussion of ECDH algorithms in <xref target="ECDH"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="IANA">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<section anchor="jose-algorithm-registration">
<section anchor="jose-algorithm-registration" title="JOSE Algorithms Regis <name>JOSE Algorithm Registrations</name>
trations"> <t>IANA has registered the values in this section in the "JSON Web
<t> Signature and Encryption Algorithms" registry <xref target="IANA.JOSE"/>
This section registers the following values in the established by <xref target="RFC7518"/> and has listed this document as an addi
IANA "JSON Web Signature and Encryption Algorithms" registry <xref targ tional reference for the registry.
et="IANA.JOSE"/> </t>
established by <xref target="RFC7515"/>. <section anchor="new-jose-regs">
</t> <name>Fully-Specified JOSE Algorithm Registrations</name>
<dl newline="false" spacing="compact">
<section anchor="new-jose-regs" title="Fully-Specified JOSE Algorithm Reg <dt>Algorithm Name:</dt><dd>Ed25519</dd>
istrations"> <dt>Algorithm Description:</dt><dd>EdDSA using the Ed25519 parameter
<t> set in <xref target="RFC8032" section="5.1"/></dd>
<?rfc subcompact="yes"?> <dt>Algorithm Usage Locations:</dt><dd>alg</dd>
<list style="symbols"> <dt>JOSE Implementation Requirements:</dt><dd>Optional</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Algorithm Name: Ed25519 <dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
</t> <dt>Algorithm Analysis Document(s):</dt><dd><xref target="RFC8032"/><
<t> /dd>
Algorithm Description: EdDSA using Ed25519 curve </dl>
</t> <dl newline="false" spacing="compact">
<t> <dt>Algorithm Name:</dt><dd>Ed448</dd>
Algorithm Usage Locations: alg <dt>Algorithm Description:</dt><dd>EdDSA using the Ed448 parameter se
</t> t in <xref target="RFC8032" section="5.2"/></dd>
<t> <dt>Algorithm Usage Locations:</dt><dd>alg</dd>
JOSE Implementation Requirements: Optional <dt>JOSE Implementation Requirements:</dt><dd>Optional</dd>
</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t> <dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
Change Controller: IETF <dt>Algorithm Analysis Document(s):</dt><dd><xref target="RFC8032"/><
</t> /dd>
<t> </dl>
Reference: <xref target="EdDSA"/> of [[ this specification ]] </section>
</t> <section anchor="deprecated-jose-regs">
<t> <name>Deprecated Polymorphic JOSE Algorithm Registration</name>
Algorithm Analysis Document(s): <xref target="RFC8032"/> <t>
</t> IANA has updated the status to "Deprecated" for the following registr
</list> ation.
</t> </t>
<t> <dl newline="false" spacing="compact">
&#xA0; <dt>Algorithm Name:</dt><dd>EdDSA</dd>
</t> <dt>Algorithm Description:</dt><dd>EdDSA signature algorithms</dd>
<t> <dt>Algorithm Usage Locations:</dt><dd>alg</dd>
<list style="symbols"> <dt>JOSE Implementation Requirements:</dt><dd>Deprecated</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Algorithm Name: Ed448 <dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
</t> <dt>Algorithm Analysis Document(s):</dt><dd><xref target="RFC8032"/><
<t> /dd>
Algorithm Description: EdDSA using Ed448 curve </dl>
</t> </section>
<t>
Algorithm Usage Locations: alg
</t>
<t>
JOSE Implementation Requirements: Optional
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: <xref target="EdDSA"/> of [[ this specification ]]
</t>
<t>
Algorithm Analysis Document(s): <xref target="RFC8032"/>
</t>
</list>
</t>
<?rfc subcompact="no"?>
</section>
<section anchor="deprecated-jose-regs" title="Deprecated Polymorphic JOSE
Algorithm Registrations">
<t>
The following registration is updated to change its status to Depreca
ted.
</t>
<t>
<?rfc subcompact="yes"?>
<list style="symbols">
<t>
Algorithm Name: EdDSA
</t>
<t>
Algorithm Description: EdDSA signature algorithms
</t>
<t>
Algorithm Usage Locations: alg
</t>
<t>
JOSE Implementation Requirements: Deprecated
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: <xref target="EdDSA"/> of [[ this specification ]]
</t>
<t>
Algorithm Analysis Document(s): <xref target="RFC8032"/>
</t>
</list>
</t>
<?rfc subcompact="no"?>
</section>
</section> </section>
<section anchor="cose-algorithms-registrations">
<section anchor="cose-algorithms-registrations" title="COSE Algorithms Reg <name>COSE Algorithm Registrations</name>
istrations">
<t> <t>
This section registers the following values in the IANA has registered the following values in the
IANA "COSE Algorithms" registry <xref target="IANA.COSE"/>. "COSE Algorithms" registry <xref target="IANA.COSE"/> established by <x
</t> ref target="RFC9053"/> and <xref target="RFC9054"/> and has added this document
as an additional reference for the registry.
<section anchor="new-cose-regs" title="Fully-Specified COSE Algorithm Reg </t>
istrations"> <section anchor="new-cose-regs">
<t> <name>Fully-Specified COSE Algorithm Registrations</name>
<?rfc subcompact="yes"?> <dl newline="false" spacing="compact">
<list style="symbols"> <dt>Name:</dt><dd>ESP256</dd>
<t> <dt>Value:</dt><dd>-9</dd>
Name: ESP256 <dt>Description:</dt><dd>ECDSA using P-256 curve and SHA-256</dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Value: TBD (requested assignment -9) <dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
</t> <dt>Recommended:</dt><dd>Yes</dd>
<t> </dl>
Description: ECDSA using P-256 curve and SHA-256 <dl newline="false" spacing="compact">
</t> <dt>Name:</dt><dd>ESP384</dd>
<t> <dt>Value:</dt><dd>-51</dd>
Capabilities: [kty] <dt>Description:</dt><dd>ECDSA using P-384 curve and SHA-384</dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Change Controller: IETF <dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
</t> <dt>Recommended:</dt><dd>Yes</dd>
<t> </dl>
Reference: <xref target="ECDSA"/> of [[ this specification ]] <dl newline="false" spacing="compact">
</t> <dt>Name:</dt><dd>ESP512</dd>
<t> <dt>Value:</dt><dd>-52</dd>
Recommended: Yes <dt>Description:</dt><dd>ECDSA using P-521 curve and SHA-512</dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
</list> <dt>Change Controller:</dt><dd>IETF</dd>
</t> <dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<t> <dt>Recommended:</dt><dd>Yes</dd>
&#xA0; </dl>
</t> <dl newline="false" spacing="compact">
<t> <dt>Name:</dt><dd>ESB256</dd>
<list style="symbols"> <dt>Value:</dt><dd>-265</dd>
<t> <dt>Description:</dt><dd>ECDSA using BrainpoolP256r1 curve and SHA-25
Name: ESP384 6</dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Value: TBD (requested assignment -51) <dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
</t> <dt>Recommended:</dt><dd>No</dd>
<t> </dl>
Description: ECDSA using P-384 curve and SHA-384 <dl newline="false" spacing="compact">
</t> <dt>Name:</dt><dd>ESB320</dd>
<t> <dt>Value:</dt><dd>-266</dd>
Capabilities: [kty] <dt>Description:</dt><dd>ECDSA using BrainpoolP320r1 curve and SHA-38
</t> 4</dd>
<t> <dt>Capabilities:</dt><dd>[kty]</dd>
Change Controller: IETF <dt>Change Controller:</dt><dd>IETF</dd>
</t> <dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<t> <dt>Recommended:</dt><dd>No</dd>
Reference: <xref target="ECDSA"/> of [[ this specification ]] </dl>
</t> <dl newline="false" spacing="compact">
<t> <dt>Name:</dt><dd>ESB384</dd>
Recommended: Yes <dt>Value:</dt><dd>-267</dd>
</t> <dt>Description:</dt><dd>ECDSA using BrainpoolP384r1 curve and SHA-38
</list> 4</dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
&#xA0; <dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
</t> <dt>Recommended:</dt><dd>No</dd>
<t> </dl>
<list style="symbols"> <dl newline="false" spacing="compact">
<t> <dt>Name:</dt><dd>ESB512</dd>
Name: ESP512 <dt>Value:</dt><dd>-268</dd>
</t> <dt>Description:</dt><dd>ECDSA using BrainpoolP512r1 curve and SHA-51
<t> 2</dd>
Value: TBD (requested assignment -52) <dt>Capabilities:</dt><dd>[kty]</dd>
</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t> <dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
Description: ECDSA using P-521 curve and SHA-512 <dt>Recommended:</dt><dd>No</dd>
</t> </dl>
<t> <dl newline="false" spacing="compact">
Capabilities: [kty] <dt>Name:</dt><dd>Ed25519</dd>
</t> <dt>Value:</dt><dd>-19</dd>
<t> <dt>Description:</dt><dd>EdDSA using the Ed25519 parameter set in <xr
Change Controller: IETF ef target="RFC8032" section="5.1"/></dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Reference: <xref target="ECDSA"/> of [[ this specification ]] <dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
</t> <dt>Recommended:</dt><dd>Yes</dd>
<t> </dl>
Recommended: Yes <dl newline="false" spacing="compact">
</t> <dt>Name:</dt><dd>Ed448</dd>
</list> <dt>Value:</dt><dd>-53</dd>
</t> <dt>Description:</dt><dd>EdDSA using the Ed448 parameter set in <xref
<t> target="RFC8032" section="5.2"/></dd>
&#xA0; <dt>Capabilities:</dt><dd>[kty]</dd>
</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t> <dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
<list style="symbols"> <dt>Recommended:</dt><dd>Yes</dd>
<t> </dl>
Name: ESB256 </section>
</t> <section anchor="deprecated-cose-regs">
<t> <name>Deprecated Polymorphic COSE Algorithm Registrations</name>
Value: TBD (requested assignment -261) <t>
</t> IANA has updated the status to "Deprecated" and has added this docume
<t> nt as a reference for the following registrations.
Description: ECDSA using BrainpoolP256r1 curve and SHA-256 </t>
</t> <dl newline="false" spacing="compact">
<t> <dt>Name:</dt><dd>ES256</dd>
Capabilities: [kty] <dt>Value:</dt><dd>-7</dd>
</t> <dt>Description:</dt><dd>ECDSA w/ SHA-256</dd>
<t> <dt>Capabilities:</dt><dd>[kty]</dd>
Change Controller: IETF <dt>Change Controller:</dt><dd>IETF</dd>
</t> <dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
<t> <dt>Recommended:</dt><dd>Deprecated</dd>
Reference: <xref target="ECDSA"/> of [[ this specification ]] </dl>
</t> <dl newline="false" spacing="compact">
<t> <dt>Name:</dt><dd>ES384</dd>
Recommended: No <dt>Value:</dt><dd>-35</dd>
</t> <dt>Description:</dt><dd>ECDSA w/ SHA-384</dd>
</list> <dt>Capabilities:</dt><dd>[kty]</dd>
</t> <dt>Change Controller:</dt><dd>IETF</dd>
<t> <dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
&#xA0; <dt>Recommended:</dt><dd>Deprecated</dd>
</t> </dl>
<t> <dl newline="false" spacing="compact">
<list style="symbols"> <dt>Name:</dt><dd>ES512</dd>
<t> <dt>Value:</dt><dd>-36</dd>
Name: ESB320 <dt>Description:</dt><dd>ECDSA w/ SHA-512</dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Value: TBD (requested assignment -262) <dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
</t> <dt>Recommended:</dt><dd>Deprecated</dd>
<t> </dl>
Description: ECDSA using BrainpoolP320r1 curve and SHA-384 <dl newline="false" spacing="compact">
</t> <dt>Name:</dt><dd>EdDSA</dd>
<t> <dt>Value:</dt><dd>-8</dd>
Capabilities: [kty] <dt>Description:</dt><dd>EdDSA</dd>
</t> <dt>Capabilities:</dt><dd>[kty]</dd>
<t> <dt>Change Controller:</dt><dd>IETF</dd>
Change Controller: IETF <dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
</t> <dt>Recommended:</dt><dd>Deprecated</dd>
<t> </dl>
Reference: <xref target="ECDSA"/> of [[ this specification ]] </section>
</t>
<t>
Recommended: No
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: ESB384
</t>
<t>
Value: TBD (requested assignment -263)
</t>
<t>
Description: ECDSA using BrainpoolP384r1 curve and SHA-384
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: <xref target="ECDSA"/> of [[ this specification ]]
</t>
<t>
Recommended: No
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: ESB512
</t>
<t>
Value: TBD (requested assignment -264)
</t>
<t>
Description: ECDSA using BrainpoolP512r1 curve and SHA-512
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: <xref target="ECDSA"/> of [[ this specification ]]
</t>
<t>
Recommended: No
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: Ed25519
</t>
<t>
Value: TBD (requested assignment -19)
</t>
<t>
Description: EdDSA using Ed25519 curve
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: <xref target="EdDSA"/> of [[ this specification ]]
</t>
<t>
Recommended: Yes
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: Ed448
</t>
<t>
Value: TBD (requested assignment -53)
</t>
<t>
Description: EdDSA using Ed448 curve
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: <xref target="EdDSA"/> of [[ this specification ]]
</t>
<t>
Recommended: Yes
</t>
</list>
</t>
<?rfc subcompact="no"?>
</section>
<section anchor="deprecated-cose-regs" title="Deprecated Polymorphic COSE
Algorithm Registrations">
<t>
The following registrations are updated to change their status to Dep
recated.
</t>
<t>
<?rfc subcompact="yes"?>
<list style="symbols">
<t>
Name: ES256
</t>
<t>
Value: -7
</t>
<t>
Description: ECDSA w/ SHA-256
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: RFC 9053
</t>
<t>
Recommended: Deprecated
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: ES384
</t>
<t>
Value: -35
</t>
<t>
Description: ECDSA w/ SHA-384
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: RFC 9053
</t>
<t>
Recommended: Deprecated
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: ES512
</t>
<t>
Value: -36
</t>
<t>
Description: ECDSA w/ SHA-512
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: RFC 9053
</t>
<t>
Recommended: Deprecated
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: EdDSA
</t>
<t>
Value: -8
</t>
<t>
Description: EdDSA
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: RFC 9053
</t>
<t>
Recommended: Deprecated
</t>
</list>
</t>
<?rfc subcompact="no"?>
</section>
</section> </section>
<section anchor="UpdatedInstructions">
<section anchor="UpdatedInstructions" title="Updated Review Instructions for Des <name>Updated Review Instructions for Designated Experts</name>
ignated Experts"> <section anchor="UpdatedInstructions1">
<section anchor="UpdatedInstructions1" title="JSON Web Signature and Encryptio <name>JSON Web Signature and Encryption Algorithms</name>
n Algorithms"> <t>
<t> The review instructions for the designated experts <xref target="RFC812
IANA is directed to preserve the current reference to RFC 7518, 6"/> for the
and to add a reference to this section of this specification. "JSON Web Signature and Encryption Algorithms" registry <xref target="I
</t> ANA.JOSE"/>
<t> in <xref target="RFC7518" section="7.1"/>
The review instructions for the designated experts for the
IANA "JSON Web Signature and Encryption Algorithms" registry <xref targ
et="IANA.JOSE"/>
in Section 7.1 of <xref target="RFC7518"/>
have been updated to include an additional review criterion: have been updated to include an additional review criterion:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
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.
</t> </t>
</list> </li>
</t> </ul>
</section> </section>
<section anchor="UpdatedInstructions2" title="COSE Algorithms"> <section anchor="UpdatedInstructions2">
<t> <name>COSE Algorithms</name>
IANA is directed to preserve the current references to RFC 9053 a <t>
nd RFC 9054, The review instructions for the designated experts <xref target="RFC812
and to add a reference to this section of this specification. 6"/> for the
</t> "COSE Algorithms" registry <xref target="IANA.COSE"/>
<t> in <xref target="RFC9053" section="10.4"/>
The review instructions for the designated experts for the
IANA "COSE Algorithms" registry <xref target="IANA.COSE"/>
in Section 10.4 of <xref target="RFC9053"/>
have been updated to include an additional review criterion: have been updated to include an additional review criterion:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
<t>
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.
</t> </t>
</list> </li>
</t> </ul>
</section> </section>
</section> </section>
<section anchor="DeprecatedProhibited">
<section title="Defining Deprecated and Prohibited" anchor="DeprecatedProh <name>Defining &quot;Deprecated&quot; and &quot;Prohibited&quot;</name>
ibited"> <t>
<t>
The terms "Deprecated" and "Prohibited" The terms "Deprecated" and "Prohibited"
as used by JOSE and COSE registrations are currently undefined. as used by JOSE and COSE registrations are currently undefined.
Furthermore, while in <xref target="RFC7518"/> JOSE specifies that both Furthermore, while in <xref target="RFC7518"/> JOSE specifies that both
"Deprecated" and "Prohibited" can be used, "Deprecated" and "Prohibited" can be used,
in <xref target="RFC8152"/> COSE specifies in <xref target="RFC8152"/> COSE specifies
the use of "Deprecated" but not "Prohibited". the use of "Deprecated" but not "Prohibited".
(Note that <xref target="RFC8152"/> has been obsoleted by <xref target ="RFC9052"/>.)
This section defines these terms for use by both This section defines these terms for use by both
JOSE and COSE IANA registrations in a consistent manner, JOSE and COSE IANA registrations in a consistent manner,
eliminating this potentially confusing inconsistency. eliminating this potentially confusing inconsistency.
</t> </t>
<t> <t>
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 <xref target="IANA.JOSE"/> and in the IANA JOSE registries <xref target="IANA.JOSE"/> and
in the "Recommended" columns in the "Recommended" columns
in the IANA COSE registries <xref target="IANA.COSE"/>, in the IANA COSE registries <xref target="IANA.COSE"/>,
these terms are defined as follows: these terms are defined as follows:
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>Deprecated</dt>
<dd>
<t hangText="Deprecated"> There is a preferred mechanism to achieve functionality
<vspace/> similar to that referenced by the identifier;
There is a preferred mechanism to achieve similar functionality this replacement functionality <bcp14>SHOULD</bcp14> be utilized in
to that referenced by the identifier; new deployments
this replacement functionality SHOULD be utilized in new deployment
s
in preference to the deprecated identifier, unless there exist docu mented operational in preference to the deprecated identifier, unless there exist docu mented operational
or regulatory requirements that prevent migration away from the dep recated identifier. or regulatory requirements that prevent migration away from the dep recated identifier.
</t> </dd>
<dt>Prohibited</dt>
<t hangText="Prohibited"> <dd>
<vspace/> The identifier and the functionality that it references <bcp14>MUST
The identifier and the functionality that it references MUST NOT be NOT</bcp14> be used.
used.
(Identifiers may be designated as "Prohibited" due to security flaw s, (Identifiers may be designated as "Prohibited" due to security flaw s,
for instance.) for instance.)
</t> </dd>
</dl>
</list> <t>
</t>
<t>
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 for use in the "Recommended" columns
in the IANA COSE registries <xref target="IANA.COSE"/> to in the IANA COSE registries <xref target="IANA.COSE"/> to
"Yes" <xref target="RFC8152"/>, "Yes" <xref target="RFC8152"/>,
"No" <xref target="RFC8152"/>, "No" <xref target="RFC8152"/>,
"Filter Only" <xref target="RFC9054"/>, "Filter Only" <xref target="RFC9054"/>,
"Prohibited", "Prohibited",
and and
"Deprecated". "Deprecated".
This updates the definitions of the "Recommended" columns This updates the definitions of the "Recommended" columns
in these registries to be: in these registries to be:
<list style="hanging"> </t>
<t hangText="Recommended:"> <dl newline="true" spacing="normal">
<dt>Recommended</dt>
<dd>
Does the IETF have a consensus recommendation to use the algorithm? Does the IETF have a consensus recommendation to use the algorithm?
The legal values are The legal values are
"Yes", "Yes",
"No", "No",
"Filter Only", "Filter Only",
"Prohibited", "Prohibited",
and and
"Deprecated". "Deprecated".
</t> </dd>
</list> </dl>
</t> <t>
<t>
</t>
<t>
The set of defined terms The set of defined terms
for use in the "JOSE Implementation Requirements" columns for use in the "JOSE Implementation Requirements" columns
in the IANA JOSE registries <xref target="IANA.JOSE"/> in the IANA JOSE registries <xref target="IANA.JOSE"/>
are unchanged. are unchanged.
</t> </t>
<t> <t>
Note that the terms "Deprecated" and "Prohibited" have been used Note that the terms "Deprecated" and "Prohibited" have been used
with a multiplicity of different meanings in various specifications, with 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 title of
<xref target="RFC8996"/>, but the actual specification text <xref target="RFC8996"/>, but the actual specification text
uses the terminology "MUST NOT be used". uses the terminology "<bcp14>MUST NOT</bcp14> be used".
</t> </t>
<t> <t>
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; all existing registrations in both JOSE and COSE;
none will need to change. none will need to change.
Furthermore, they are consistent with their existing usage in JOSE. Furthermore, they are consistent with their existing usage in JOSE.
The only net change is to enable a clear distinction between The only net change is to enable a clear distinction between
"Deprecated" and "Prohibited" in future COSE registrations. "Deprecated" and "Prohibited" in future COSE registrations.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Keys">
<section anchor="Keys" title="Key Representations"> <name>Key Representations</name>
<t> <t>
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, polymorphic algorithms that they replace,
other than the <spanx style="verb">alg</spanx> value, if included. other than the <tt>"alg"</tt> value, if included.
For instance, the representation for a key used with the For instance, the representation for a key used with the
<spanx style="verb">Ed25519</spanx> algorithm is the same as that specifi <tt>Ed25519</tt> algorithm is the same as that specified
ed in <xref target="RFC8037"/>, except that the <tt>"alg"</tt>
in <xref target="RFC8037"/>, except that the <spanx style="verb">alg</spa value would be <tt>Ed25519</tt> rather than
nx> <tt>EdDSA</tt>, if included.
value would be <spanx style="verb">Ed25519</spanx> rather than
<spanx style="verb">EdDSA</spanx>, if included.
</t> </t>
</section> </section>
<section anchor="NotUpdated">
<section anchor="NotUpdated" title="Notes on Algorithms Not Updated"> <name>Notes on Algorithms Not Updated</name>
<t> <t>
Some existing polymorphic algorithms Some existing polymorphic algorithms
are not updated by this specification. are not updated by this specification.
This section discusses why they have not been updated. This section discusses why they have not been updated.
</t> </t>
<section anchor="RSA">
<section anchor="RSA" title="RSA Signing Algorithms"> <name>RSA Signing Algorithms</name>
<t> <t>
There are different points of view on whether the There are different points of view on whether the
<spanx style="verb">RS256</spanx>, <tt>RS256</tt>,
<spanx style="verb">RS384</spanx>, and <tt>RS384</tt>, and
<spanx style="verb">RS512</spanx> algorithms <tt>RS512</tt> algorithms
should be considered fully-specified or not, should be considered fully specified or not,
because they can operate on keys of different sizes. because they can operate on keys of different sizes.
For instance, they can use both 2048- and 4096-bit keys. For instance, they can use both 2048- and 4096-bit keys.
The same is true of the <spanx style="verb">PS*</spanx> algorithms. The same is true of the <tt>PS*</tt> algorithms.
</t> </t>
<t> <t>
This document does not describe or request registration of any fully sp This document does not describe or request registration of any
ecified RSA algorithms. Some RSA signing implementations, such as fully-specified RSA algorithms. Some RSA signing implementations, such as
FIPS-compliant Hardware Security Modules (HSMs) <xref target="FIPS.140- 3"/> FIPS-compliant Hardware Security Modules (HSMs) <xref target="FIPS.140- 3"/>
limit RSA key parameters to specific values with acceptable security ch aracteristics. limit RSA key parameters to specific values with acceptable security ch aracteristics.
This approach could be extended to define fully-specified RSA algorithm s in the future. This approach could be extended to define fully-specified RSA algorithm s in the future.
</t> </t>
<t> <t>
That said, should it be useful at some point to have That said, should it be useful at some point to have
RSA algorithm identifiers that are specific to particular key character istics, RSA algorithm identifiers that are specific to particular key character istics,
a future specification could always register them. a future specification could always register them.
</t> </t>
</section> </section>
<section anchor="ECDH">
<section anchor="ECDH" title="ECDH Key Agreement Algorithms"> <name>ECDH Key Agreement Algorithms</name>
<t> <t>
This specification does not update the This specification does not update the
Elliptic Curve Diffie-Hellman (ECDH) algorithms, ECDH algorithms,
but describes how to potentially do so in the future, if needed. but it describes how to potentially do so in the future, if needed.
The registered JOSE and COSE ECDH algorithms are polymorphic The registered JOSE and COSE ECDH algorithms are polymorphic
because they do not specify the curve to be used for the ephemeral key. because they do not specify the curve to be used for the ephemeral key.
</t> </t>
<t> <t>
Fully-specified versions of these algorithms would specify all choices Fully-specified versions of these algorithms would specify all choices
needed, including the KDF and the curve. needed, including the KDF and the curve.
For instance, an algorithm performing For instance, an algorithm performing
ECDH-ES using the Concat KDF and the P-256 curve, ECDH-ES using the Concat KDF and the P-256 curve
would be fully-specified and could be defined and registered. would be fully specified and could be defined and registered.
While this specification does not While this specification does not
define and register such replacement algorithms, define and register such replacement algorithms,
other specifications could do so in the future, if desired. other specifications could do so in the future, if desired.
</t> </t>
</section> </section>
<section anchor="HSS-LMS">
<section anchor="HSS-LMS" title="HSS/LMS Hash-Based Digital Signature Algo <name>HSS/LMS Hash-Based Digital Signature Algorithm</name>
rithm"> <t>
<t>
The HSS-LMS algorithm registered by COSE is polymorphic. The HSS-LMS algorithm registered by COSE is polymorphic.
It is polymorphic because the algorithm identifier does not specify It is polymorphic because the algorithm identifier does not specify
the hash function to be used. the hash function to be used.
Like ECDH, this specification does not register replacement Like ECDH, this specification does not register replacement
algorithms, but future specifications could do so. algorithms, but future specifications could do so.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Security">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
The security considerations for ECDSA in <xref target="RFC7518"/>, The security considerations for ECDSA in <xref target="RFC7518"/>,
for EdDSA in <xref target="RFC8037"/>, and for EdDSA in <xref target="RFC8037"/>, and
for ECDSA and EdDSA in <xref target="RFC9053"/> apply. for ECDSA and EdDSA in <xref target="RFC9053"/> apply.
</t> </t>
<t> <t>
The security considerations for preventing cross-protocol attacks The security considerations for preventing cross-protocol attacks
described in <xref target="RFC9459"/> apply. described in <xref target="RFC9459"/> apply.
</t> </t>
<t>
<t>
An "attack signature" is a unique pattern or characteristic used to ident ify malicious activity, enabling systems to detect and respond to known threats. An "attack signature" is a unique pattern or characteristic used to ident ify malicious activity, enabling systems to detect and respond to known threats.
The digital signature and key establishment algorithms used by software c an contribute to an attack signature. The digital signature and key establishment algorithms used by software c an contribute to an attack signature.
By varying the identifier used for an algorithm, some software systems ma y attempt to evade rule-based detection and classification. By varying the identifier used for an algorithm, some software systems ma y attempt to evade rule-based detection and classification.
Rule-based detection and classification systems may need to update their rules to account for fully-specified algorithms. Rule-based detection and classification systems may need to update their rules to account for fully-specified algorithms.
These systems should be aware that writing rules for polymorphic algorith ms is more difficult, as each variant of the algorithm must be accounted for. These systems should be aware that writing rules for polymorphic algorith ms is more difficult, as each variant of the algorithm must be accounted for.
For example, ES384 in COSE might be used with 3 different keys, each with a different curve. For example, ES384 in COSE might be used with three different keys, each with a different curve.
</t> </t>
<t> <t>
A cryptographic key MUST be used with only a single algorithm A cryptographic key <bcp14>MUST</bcp14> be used with only a single algorithm
unless the use of the same key with different algorithms is proven secure. unless the use of the same key with different algorithms is proven secure.
See <xref target="Reuse25519"/> for an example of such a proof. See <xref target="Reuse25519"/> for an example of such a proof.
As a result, it is RECOMMENDED that the algorithm parameter of JSON Web Keys and As a result, it is <bcp14>RECOMMENDED</bcp14> that the algorithm parameter of JS
COSE Keys be present, ON Web Keys and COSE Keys be present,
unless there exists some other mechanism for ensuring the key is used as intende unless there exists some other mechanism for ensuring that the key is used as in
d. tended.
</t> </t>
<t> <t>
In COSE, preventing cross-protocol attacks, In COSE, preventing cross-protocol attacks,
such as those described in <xref target="RFC9459"/>, such as those described in <xref target="RFC9459"/>,
can be accomplished in two ways: can be accomplished in two ways:
<list style="numbers"> </t>
<t> <ol spacing="normal" type="1"><li>
Allow only authenticated content encryption (AEAD) algorithms. <t>
</t> Allow only authenticated content encryption (Authenticated Encryption
<t> with Associated Data (AEAD)) algorithms.
</t>
</li>
<li>
<t>
Bind the potentially unauthenticated content encryption algorithm 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 encryption keys. content encryption algorithms result in different content encryption keys.
</t> </t>
</list> </li>
</ol>
<t>
Which choice to use in which circumstances is beyond the scope of this sp ecification. Which choice to use in which circumstances is beyond the scope of this sp ecification.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
516.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
037.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
053.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
052.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
518.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
152.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
414.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
996.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
054.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
459.xml"/>
<reference anchor="IANA.JOSE" target="https://www.iana.org/assignments/j
ose/">
<front>
<title>JSON Object Signing and Encryption (JOSE)</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA.COSE" target="https://www.iana.org/assignments/c
ose/">
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="OpenID.Discovery" target="https://openid.net/specs/op
enid-connect-discovery-1_0.html">
<front>
<title>OpenID Connect Discovery 1.0 incorporating errata set 2</titl
e>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting<
/organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico (was at Ping Identity)">Yubico</organ
ization>
</author>
<author fullname="Michael B. Jones" initials="M." surname="Jones">
<organization abbrev="Self-Issued Consulting (was at Microsoft)">S
elf-Issued Consulting</organization>
</author>
<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization abbrev="Illumila">Illumila</organization>
</author>
<date day="15" month="December" year="2023"/>
</front>
</reference>
<reference anchor="WebAuthn" target="https://www.w3.org/TR/2021/REC-weba
uthn-2-20210408/">
<front>
<title>Web Authentication: An API for accessing Public Key Credentia
ls - Level 2</title>
<author initials="J." surname="Hodges" fullname="Jeff Hodges" role="
editor">
<organization>PayPal</organization>
<address>
<email>jdhodges@google.com</email>
</address>
</author>
<author initials="J.C." surname="Jones" fullname="J.C. Jones" role="
editor">
<organization>Mozilla</organization>
<address>
<email>jc@mozilla.com</email>
</address>
</author>
<author initials="M.B." surname="Jones" fullname="Michael B. Jones"
role="editor">
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author initials="A." surname="Kumar" fullname="Akshay Kumar" role="
editor">
<organization>Microsoft</organization>
<address>
<email>akshayku@microsoft.com</email>
</address>
</author>
<author initials="E." surname="Lundberg" fullname="Emil Lundberg" ro
le="editor">
<organization>Yubico</organization>
<address>
<email>emil@yubico.com</email>
</address>
</author>
<date day="8" month="April" year="2021"/>
</front>
<refcontent>W3C Recommendation</refcontent>
</reference>
<reference anchor="FIDO2" target="https://fidoalliance.org/specs/fido-v2
.2-ps-20250714/fido-client-to-authenticator-protocol-v2.2-ps-20250714.html">
<front>
<title>Client to Authenticator Protocol (CTAP)</title>
<author initials="J." surname="Bradley" fullname="John Bradley">
<organization>Yubico</organization>
<address>
<email>jbradley@yubico.com</email>
</address>
</author>
<author initials="M.B." surname="Jones" fullname="Michael B. Jones">
<organization>independent</organization>
<address>
<email>michael_b_jones@hotmail.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author initials="A." surname="Kumar" fullname="Akshay Kumar">
<organization>Microsoft</organization>
<address>
<email>akshayku@microsoft.com</email>
</address>
</author>
<author initials="R." surname="Lindemann" fullname="Rolf Lindemann">
<organization>Nok Nok Labs</organization>
<address>
<email>rolf@noknok.com</email>
</address>
</author>
<author initials="J." surname="Verrept" fullname="Johan Verrept">
<organization>OneSpan</organization>
<address>
<email>johan.verrept@onespan.com</email>
</address>
</author>
<author initials="D." surname="Waite" fullname="David Waite">
<organization>Ping Identity</organization>
<address>
<email>dwaite@pingidentity.com</email>
</address>
</author>
<date day="14" month="July" year="2025"/>
</front>
<refcontent>FIDO Alliance Proposed Standard</refcontent>
</reference>
<reference anchor="FIPS.140-3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NI
ST.FIPS.140-3.pdf">
<front>
<title>Security Requirements for Cryptographic Modules</title>
<author>
<organization>NIST</organization>
</author>
<date month="March" year="2019"/>
</front>
<seriesInfo name="NIST FIPS" value="140-3"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.140-3"/>
</reference>
<references title="Normative References"> <reference anchor="Reuse25519" target="https://eprint.iacr.org/2021/509.
pdf">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211 <front>
9.xml"/> <title>On using the same key pair for Ed25519 and an X25519 based KE
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.751 M</title>
5.xml"/> <author fullname="Erik Thormarker" initials="E." surname="Thormarker
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.751 ">
6.xml"/> <organization abbrev="Ericsson">Ericsson</organization>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803 </author>
7.xml"/> <date day="23" month="April" year="2021"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817 </front>
4.xml"/> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.905 </references>
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/
reference.RFC.9052.xml"/>
</references>
<references title="Informative References">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.751
8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.815
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.841
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.899
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.905
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.945
9.xml"/>
<reference anchor="IANA.JOSE" target="https://www.iana.org/assignments/jos
e/">
<front>
<title>JSON Object Signing and Encryption (JOSE)</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA.COSE" target="https://www.iana.org/assignments/cos
e/">
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="OpenID.Discovery" target="https://openid.net/specs/open
id-connect-discovery-1_0.html">
<front>
<title>OpenID Connect Discovery 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</or
ganization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico (was at Ping Identity)">Yubico</organiza
tion>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Self-Issued Consulting (was at Microsoft)">Self
-Issued Consulting</organization>
</author>
<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization abbrev="Illumila">Illumila</organization>
</author>
<date day="15" month="December" year="2023"/>
</front>
</reference>
<reference anchor="WebAuthn" target="https://www.w3.org/TR/2021/REC-webaut
hn-2-20210408/">
<front>
<title>Web Authentication: An API for accessing Public Key Credentials
- Level 2</title>
<seriesInfo name="World Wide Web Consortium (W3C)" value="Recommendati
on"/>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization>PayPal</organization>
<address>
<email>jdhodges@google.com</email>
</address>
</author>
<author initials="J.C." surname="Jones" fullname="J.C. Jones">
<organization>Mozilla</organization>
<address>
<email>jc@mozilla.com</email>
</address>
</author>
<author initials="M.B." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author initials="A." surname="Kumar" fullname="Akshay Kumar">
<organization>Microsoft</organization>
<address>
<email>akshayku@microsoft.com</email>
</address>
</author>
<author initials="E." surname="Lundberg" fullname="Emil Lundberg">
<organization>Yubico</organization>
<address>
<email>emil@yubico.com</email>
</address>
</author>
<date day="8" month="April" year="2021"/>
</front>
</reference>
<reference anchor="FIDO2" target="https://fidoalliance.org/specs/fido-v2.2
-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html">
<front>
<title>Client to Authenticator Protocol (CTAP)</title>
<seriesInfo name="FIDO Alliance" value="Proposed Standard"/>
<author initials="J." surname="Bradley" fullname="John Bradley">
<organization>Yubico</organization>
<address>
<email>jbradley@yubico.com</email>
</address>
</author>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>independent</organization>
<address>
<email>michael_b_jones@hotmail.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author initials="A." surname="Kumar" fullname="Akshay Kumar">
<organization>Microsoft</organization>
<address>
<email>akshayku@microsoft.com</email>
</address>
</author>
<author initials="R." surname="Lindemann" fullname="Rolf Lindemann">
<organization>Nok Nok Labs</organization>
<address>
<email>rolf@noknok.com</email>
</address>
</author>
<author initials="J." surname="Johan" fullname="Johan Verrept">
<organization>OneSpan</organization>
<address>
<email>johan.verrept@onespan.com</email>
</address>
</author>
<author initials="D." surname="David" fullname="David Waite">
<organization>Ping Identity</organization>
<address>
<email>dwaite@pingidentity.com</email>
</address>
</author>
<date day="28" month="February" year="2025"/>
</front>
</reference>
<reference anchor="FIPS.140-3" target="https://nvlpubs.nist.gov/nistpubs/F
IPS/NIST.FIPS.140-3.pdf">
<front>
<title>Security Requirements for Cryptographic Modules</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</
organization>
</author>
<date day="22" month="March" year="2019" />
</front>
<seriesInfo name="FIPS" value="PUB 140-3" />
</reference>
<reference anchor="Reuse25519" target="https://eprint.iacr.org/2021/509.pd
f">
<front>
<title>On using the same key pair for Ed25519 and an X25519 based KEM<
/title>
<author fullname="Erik Thormarker" initials="E." surname="Thormarker">
<organization abbrev="Ericsson">Ericsson</organization>
</author>
<date day="23" month="April" year="2021"/>
</front>
</reference>
</references> </references>
<section title="Document History" anchor="History"> <section anchor="Acknowledgements" numbered="false">
<t> <name>Acknowledgements</name>
[[ to be removed by the RFC Editor before publication as an RFC ]]
</t>
<t>
-13
<list style="symbols">
<t>
Applied suggestions by Mike Bishop and Paul Wouters.
</t>
</list>
</t>
<t>
-12
<list style="symbols">
<t>
Changed requested COSE assignments for ESP384, ESP512, Ed25519, and E
d448
due to conflicts with the new ML-DSA assignments.
</t>
</list>
</t>
<t>
-11
<list style="symbols">
<t>
Stated in the abstract that the specification deprecates
some polymorphic algorithm identifiers, as suggested by Éric Vyncke.
</t>
</list>
</t>
<t>
-10
<list style="symbols">
<t>
Provided a complete list of the Recommended column terms for
COSE registrations, as suggested by Mohamed Boucadair.
</t>
<t>
Applied suggestions to improve the exposition received during IESG re
view.
</t>
</list>
</t>
<t>
-09
<list style="symbols">
<t>
Addressed comments from secdir review by Kathleen Moriarty.
</t>
</list>
</t>
<t>
-08
<list style="symbols">
<t>
Updated requested Brainpool algorithm numbers to match those chosen b
y Sean Turner.
</t>
<t>
Incorporated wording suggestions by Vijay Gurbani.
</t>
</list>
</t>
<t>
-07
<list style="symbols">
<t>
Addressed Deb Cooley's Area Director feedback. Specifically:
<list style="symbols">
<t>
Significantly simplified the encryption description.
</t>
<t>
Removed the appendix on polymorphic ECDH algorithms.
</t>
</list>
</t>
<t>
Stated that HSS-LMS is not fully specified,
as suggested by John Preuß Mattsson.
</t>
</list>
</t>
<t>
-06
<list style="symbols">
<t>
Corrected inconsistencies identified during the 2nd WGLC.
</t>
<t>
Added terminology remark about the "cipher suite" and
"à la carte" approaches.
</t>
</list>
</t>
<t>
-05
<list style="symbols">
<t>
Applied IANA early review comments.
</t>
</list>
</t>
<t>
-04
<list style="symbols">
<t>
Removed ECDH registrations and proposed fully-specified ECDH algorith
m identifiers, per feedback at IETF 120.
</t>
<t>
Tightened descriptive text for fully-specified encryption algorithms.
</t>
<t>
Applied John Mattsson's suggestion for the RSA section title.
</t>
</list>
</t>
<t>
-03
<list style="symbols">
<t>
Acknowledged contributions made during Working Group Last Call.
</t>
<t>
Addressed security considerations feedback from WGLC.
</t>
<t>
Made COSE Recommended status for Ed25519 and Ed448 "yes".
</t>
<t>
Registered COSE algorithms for using Brainpool curves with ECDSA.
</t>
<t>
Removed text on KEMs, since currently registered algorithms don't use
them.
</t>
<t>
Enabled use of fully-specified ECDH algorithms.
</t>
<t>
Defined the terms "Deprecated" and "Prohibited" for both JOSE and COS
E registrations.
</t>
</list>
</t>
<t>
-02
<list style="symbols">
<t>
Expanded references for KEMs.
</t>
<t>
Added example of a fully-specified KEM.
</t>
</list>
</t>
<t>
-01
<list style="symbols">
<t>
Included additional instructions for IANA.
</t>
<t>
Added text on KEMs and Encapsulated keys.
</t>
<t>
Added the section Fully-Specified Computations Using Multiple Algorit
hms.
</t>
</list>
</t>
<t>
-00
<list style="symbols">
<t>
Created initial working group version based on draft-jones-jose-fully
-specified-algorithms-02.
</t>
</list>
</t>
</section>
<section title="Acknowledgements" anchor="Acknowledgements" numbered="no">
<t> <t>
The authors thank The authors thank <contact fullname="Mike Bishop"/>, <contact
Mike Bishop, fullname="Carsten Bormann"/>, <contact fullname="Mohamed Boucadair"/>,
Carsten Bormann, <contact fullname="John Bradley"/>, <contact fullname="Tim Bray"/>,
Mohamed Boucadair, <contact fullname="Brian Campbell"/>, <contact fullname="Deb
John Bradley, Cooley"/>, <contact fullname="Roman Danyliw"/>, <contact
Tim Bray, fullname="Stephen Farrell"/>, <contact fullname="Vijay Gurbani"/>,
Brian Campbell, <contact fullname="Ilari Liusvaara"/>, <contact fullname="Tobias
Deb Cooley, Looker"/>, <contact fullname="Neil Madden"/>, <contact fullname="Kathleen
Roman Danyliw, Moriarty"/>, <contact
Stephen Farrell, fullname="Jeremy O'Donoghue"/>, <contact fullname="John Preuß Mattsson"/>
Vijay Gurbani, , <contact fullname="Anders Rundgren"/>,
Ilari Liusvaara, <contact fullname="Göran Selander"/>, <contact fullname="Filip
Tobias Looker, Skokan"/>, <contact fullname="Oliver Terbu"/>, <contact
Neil Madden, fullname="Hannes Tschofenig"/>, <contact fullname="Sean Turner"/>,
John Preuß Mattsson, <contact fullname="Éric Vyncke"/>, <contact fullname="David Waite"/>,
Kathleen Moriarty, <contact fullname="Paul Wouters"/>, and <contact fullname="Jiankang
Jeremy O'Donoghue, Yao"/> for their contributions to this specification.
Anders Rundgren,
Göran Selander,
Filip Skokan,
Oliver Terbu,
Hannes Tschofenig,
Sean Turner,
Éric Vyncke,
David Waite,
Paul Wouters,
and
Jiankang Yao
for their contributions to this specification.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 112 change blocks. 
1278 lines changed or deleted 760 lines changed or added

This html diff was produced by rfcdiff 1.48.