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" <!-- pre-edited by ST 05/15/25 -->
category="std" ipr="trust200902" <!-- formatted by ST 05/19/25 -->
docName="draft-ietf-jose-fully-specified-algorithms-13"
updates="7518, 8037, 9053">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="5"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
submissionType="IETF" consensus="true" docName="draft-ietf-jose-fully-specified
-algorithms-13" number="9864" updates="7518, 8037, 9053" obsoletes="" tocInclude
="true" tocDepth="5" symRefs="true" sortRefs="true" version="3" xml:lang="en">
<front> <front>
<title abbrev="Fully Specified Algorithms">Fully Specified Algorithms for JS ON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption ( COSE)</title>
<title abbrev="Fully-Specified Algorithms">Fully-Specified Algorithms for JO <!-- [rfced] Please note that the document title has been updated as
SE and COSE</title> follows. The abbreviations "JOSE” and "COSE" have been expanded
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please let us
know any objections.
Original:
Fully-Specified Algorithms for JOSE and COSE
Currently:
Fully Specified Algorithms for JSON Object Signing and Encryption (JOSE)
and CBOR Object Signing and Encryption (COSE) -->
<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>Transmute</organization>
<address> <address>
<email>orie@transmute.industries</email> <email>orie@transmute.industries</email>
</address> </address>
</author> </author>
<date month="September" 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 It adds to the instructions to designated experts in RFCs 7518 and 9053.
3.
</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 <tt>Edwards-curve Digital Signature Algorithm (EdDSA )</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 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>
The following fully-specified COSE ECDSA algorithms are defined by this
specification:
</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> <!-- [rfced] Section 2.1: Because it appears that "full-specified"
<c>TBD (requested assignment -265)</c> means "fully specified", we updated this text accordingly. If this
<c>ECDSA using BrainpoolP256r1 curve and SHA-256</c> is incorrect, please let us know what "full-specified" means
<c>No</c> (possibly "specified in full"?).
<c>ESB320</c> Original:
<c>TBD (requested assignment -266)</c> (The corresponding JOSE registrations in [RFC7518] are
<c>ECDSA using BrainpoolP320r1 curve and SHA-384</c> full-specified.)
<c>No</c>
<c>ESB384</c> Currently:
<c>TBD (requested assignment -267)</c> (The corresponding JOSE registrations in [RFC7518] are
<c>ECDSA using BrainpoolP384r1 curve and SHA-384</c> fully specified.) -->
<c>No</c>
<c>ESB512</c> </t>
<c>TBD (requested assignment -268)</c> <t>
<c>ECDSA using BrainpoolP512r1 curve and SHA-512</c> The following fully specified COSE ECDSA algorithms are defined by this
<c>No</c> specification:
</t>
</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
The following fully-specified JOSE and COSE EdDSA algorithms are define d by this specification:
d by this specification: </t>
</t> <table anchor="eddsa-algs" align="center">
<texttable anchor="eddsa-algs" title="EdDSA Algorithm Values" suppress-ti <name>EdDSA Algorithm Values</name>
tle="false" align="center" style="full"> <thead>
<ttcol align="left">Name</ttcol> <tr>
<ttcol align="left">COSE Value</ttcol> <th align="left">Name</th>
<ttcol align="left">Description</ttcol> <th align="left">COSE Value</th>
<ttcol align="left">JOSE Implementation Requirements</ttcol> <th align="left">Description</th>
<ttcol align="left">COSE Recommended</ttcol> <th align="left">JOSE Implementation Requirements</th>
<th align="left">COSE Recommended</th>
<c>Ed25519</c> </tr>
<c>TBD (requested assignment -19)</c> </thead>
<c>EdDSA using Ed25519 curve</c> <tbody>
<c>Optional</c> <tr>
<c>Yes</c> <td align="left">Ed25519</td>
<td align="left">-19</td>
<c>Ed448</c> <td align="left">EdDSA using Ed25519 curve</td>
<c>TBD (requested assignment -53)</c> <td align="left">Optional</td>
<c>EdDSA using Ed448 curve</c> <td align="left">Yes</td>
<c>Optional</c> </tr>
<c>Yes</c> <tr>
<td align="left">Ed448</td>
</texttable> <td align="left">-53</td>
<td align="left">EdDSA using Ed448 curve</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 < xref target="RFC7518"/>, and JSON Web Encryption (JWE), as described in <xref target="RFC7516"/> and < xref target="RFC7518"/>, and
COSE Encrypt, as described in <xref target="RFC9052"/> and <xref target=" RFC9053"/>. COSE Encrypt, as described in <xref target="RFC9052"/> and <xref target=" RFC9053"/>.
<!-- [rfced] Section 3: We see "COSE_Encrypt" but not "COSE Encrypt"
in RFC 9052, and we do not see "COSE Encrypt" or "COSE_Encrypt" in
RFC 9053. Please let us know how/if this sentence should be updated
so that it is clear to readers. For example, we see "using
COSE_Encrypt, as specified in Section 5.1 of [RFC9052]" later in this
section.
Original:
This section describes the construction of fully-specified encryption
algorithm identifiers in the context of the JOSE and COSE encryption
schemes JSON Web Encryption (JWE), as described in [RFC7516] and
[RFC7518], and COSE Encrypt, as described in [RFC9052] and [RFC9053]. -->
</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.
</t> </t>
<t> <t>
Both JOSE and COSE have operations that take multiple algorithms as param eters. Both JOSE and COSE have operations that take multiple algorithms as param eters.
skipping to change at line 295 skipping to change at line 344
the first in the "alg" (Algorithm) Header Parameter, the first in the "alg" (Algorithm) Header Parameter,
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 n. the inner "alg" value must specify all parameters for symmetric encryptio n.
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.
<!-- [rfced] Section 3: Please confirm that "must specify" in this
sentence shouldn't be "MUST specify".
Original:
To perform fully-specified encryption in COSE, the outer "alg" value
MUST specify all parameters for key establishment and the inner "alg"
value must specify all parameters for symmetric encryption. -->
</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 key wrapping with AES GCM algorithms.
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> <!-- [rfced] Section 3.1: "as are the key wrapping with AES GCM
algorithms" reads oddly. Should "key wrapping with AES GCM" be
placed in quotes, per the quoted algorithm types in the next
paragraph?
We have the same question for "The JOSE Key Encryption with PBES2
algorithms" two paragraphs later.
Original (all three paragraphs included for context):
In both JOSE and COSE, all registered key wrapping algorithms are
fully specified, as are the key wrapping with AES GCM algorithms. An
example of a fully-specified key wrapping algorithm is "A128KW" (AES
Key Wrap using 128-bit key).
The JOSE "dir" and COSE "direct" algorithms are fully specified. The
COSE direct+HKDF algorithms are fully specified.
The JOSE Key Encryption with PBES2 algorithms are fully specified. -->
</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 Key Encryption with PBES2 algorithms are fully specified.
</t> </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">
<name>IANA Considerations</name>
<section anchor="jose-algorithm-registration">
<name>JOSE Algorithm Registrations</name>
<t>IANA has registered the values in this section in the "JSON Web
Signature and Encryption Algorithms" registry <xref target="IANA.JOSE"/>
established by <xref target="RFC7518"/> and has listed this document as an addi
tional reference for the registry.
<section anchor="IANA" title="IANA Considerations"> <!-- [rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.
<section anchor="jose-algorithm-registration" title="JOSE Algorithms Regis Note that the IANA registries can be viewed here:
trations"> https://www.iana.org/assignments/jose
<t> https://www.iana.org/assignments/cose
This section registers the following values in the
IANA "JSON Web Signature and Encryption Algorithms" registry <xref targ
et="IANA.JOSE"/>
established by <xref target="RFC7515"/>.
</t>
<section anchor="new-jose-regs" title="Fully-Specified JOSE Algorithm Reg a) Section 4.1: As the "JSON Web Signature and Encryption Algorithms"
istrations"> registry was established by RFC 7518, we have replaced RFC 7515 with
<t> RFC 7518 as shown below. We have also removed RFC 7515 from the
<?rfc subcompact="yes"?> normative references section as it was only mentioned in the text
<list style="symbols"> below. Note that RFC 7518 is listed as an informative reference;
<t> please let us know if this is okay as is or if it should be
Algorithm Name: Ed25519 normative.
</t>
<t>
Algorithm Description: EdDSA using Ed25519 curve
</t>
<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>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Algorithm Name: Ed448
</t>
<t>
Algorithm Description: EdDSA using Ed448 curve
</t>
<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 We also included that this document was listed as an additional
Algorithm Registrations"> reference for the registry at the end of the sentence below
<t> (and have removed the related text from Section 4.3, which
The following registration is updated to change its status to Depreca describes the updated review instructions for the DEs). Note
ted. that a similar change was made to Section 4.2 for the "COSE
</t> Algorithms" registry, as shown below.
<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 anchor="cose-algorithms-registrations" title="COSE Algorithms Reg Please review and let us know of any objections.
istrations">
<t>
This section registers the following values in the
IANA "COSE Algorithms" registry <xref target="IANA.COSE"/>.
</t>
<section anchor="new-cose-regs" title="Fully-Specified COSE Algorithm Reg Original (Section 4.1):
istrations"> This section registers the following values in the IANA "JSON Web
<t> Signature and Encryption Algorithms" registry [IANA.JOSE] established
<?rfc subcompact="yes"?> by [RFC7515].
<list style="symbols">
<t>
Name: ESP256
</t>
<t>
Value: TBD (requested assignment -9)
</t>
<t>
Description: ECDSA using P-256 curve and SHA-256
</t>
<t>
Capabilities: [kty]
</t>
<t>
Change Controller: IETF
</t>
<t>
Reference: <xref target="ECDSA"/> of [[ this specification ]]
</t>
<t>
Recommended: Yes
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: ESP384
</t>
<t>
Value: TBD (requested assignment -51)
</t>
<t>
Description: ECDSA using P-384 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: Yes
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: ESP512
</t>
<t>
Value: TBD (requested assignment -52)
</t>
<t>
Description: ECDSA using P-521 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: Yes
</t>
</list>
</t>
<t>
&#xA0;
</t>
<t>
<list style="symbols">
<t>
Name: ESB256
</t>
<t>
Value: TBD (requested assignment -261)
</t>
<t>
Description: ECDSA using BrainpoolP256r1 curve and SHA-256
</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: ESB320
</t>
<t>
Value: TBD (requested assignment -262)
</t>
<t>
Description: ECDSA using BrainpoolP320r1 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: 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 Currently:
Algorithm Registrations"> IANA has registered the values in this section in the "JSON Web
<t> Signature and Encryption Algorithms" registry [IANA.JOSE]
The following registrations are updated to change their status to Dep established by [RFC7518] and has listed this document as
recated. an additional reference for the registry.
</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 anchor="UpdatedInstructions" title="Updated Review Instructions for Des ...
ignated Experts"> Original (Section 4.2):
<section anchor="UpdatedInstructions1" title="JSON Web Signature and Encryptio This section registers the following values in the IANA "COSE
n Algorithms"> Algorithms" registry [IANA.COSE].
<t>
IANA is directed to preserve the current reference to RFC 7518, Currently:
and to add a reference to this section of this specification. IANA has registered the following values in the "COSE Algorithms"
</t> registry [IANA.COSE] established by [RFC9053] and [RFC9054]
<t> and has added this document as an additional reference for the
The review instructions for the designated experts for the registry.
IANA "JSON Web Signature and Encryption Algorithms" registry <xref targ
et="IANA.JOSE"/> b) Per the changes noted in a) above, we will ask IANA to update
in Section 7.1 of <xref target="RFC7518"/> the section number listed for this document for the
"COSE Algorithms" registry as shown below.
Original:
Reference
[RFC9053][RFC9054][draft-ietf-jose-fully-specified-algorithms-13,
Section 4.3.1]
Suggested:
Reference
[RFC9053][RFC9054][RFC9864, Section 4.2]
c) In Section 4.2.1, we note that this document lists section numbers
for the algorithms but the "COSE Algorithm" registry does not, so
there is a mismatch. Should "Section 2.1" and "Section 2.2" be removed
from this document for consistency with the registry, or should IANA
add "Section 2.1" and "Section 2.2" accordingly for consistency with
this document?
Section 2.1 listed in the document
but not in the registry:
ESP256
ESP384
ESP512
ESB256
ESB320
ESB384
ESB512
Section 2.2 listed in the document
but not in the registry:
Ed25519
Ed448
d) For "ES512" in the "COSE Algorithm" registry, we note that "IETF"
is not listed under "Change Controller". Should "IETF" be added to
the registry or removed from this document?
Current in this document:
Name: ES512
Value: -36
Description: ECDSA w/ SHA-512
Capabilities: [kty]
Change Controller: IETF
Reference: [RFC9053] and RFC 9864
Recommended: Deprecated
-->
</t>
<section anchor="new-jose-regs">
<name>Fully Specified JOSE Algorithm Registrations</name>
<dl newline="false" spacing="compact">
<dt>Algorithm Name:</dt><dd>Ed25519</dd>
<dt>Algorithm Description:</dt><dd>EdDSA using Ed25519 curve</dd>
<dt>Algorithm Usage Locations:</dt><dd>alg</dd>
<dt>JOSE Implementation Requirements:</dt><dd>Optional</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
<dt>Algorithm Analysis Document(s):</dt><dd><xref target="RFC8032"/><
/dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Algorithm Name:</dt><dd>Ed448</dd>
<dt>Algorithm Description:</dt><dd>EdDSA using Ed448 curve</dd>
<dt>Algorithm Usage Locations:</dt><dd>alg</dd>
<dt>JOSE Implementation Requirements:</dt><dd>Optional</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
<dt>Algorithm Analysis Document(s):</dt><dd><xref target="RFC8032"/><
/dd>
</dl>
</section>
<section anchor="deprecated-jose-regs">
<name>Deprecated Polymorphic JOSE Algorithm Registration</name>
<t>
IANA has updated the status to "Deprecated" for the following registr
ation.
</t>
<dl newline="false" spacing="compact">
<dt>Algorithm Name:</dt><dd>EdDSA</dd>
<dt>Algorithm Description:</dt><dd>EdDSA signature algorithms</dd>
<dt>Algorithm Usage Locations:</dt><dd>alg</dd>
<dt>JOSE Implementation Requirements:</dt><dd>Deprecated</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
<dt>Algorithm Analysis Document(s):</dt><dd><xref target="RFC8032"/><
/dd>
</dl>
</section>
</section>
<section anchor="cose-algorithms-registrations">
<name>COSE Algorithm Registrations</name>
<t>
IANA has registered the following values in the
"COSE Algorithms" registry <xref target="IANA.COSE"/> established by <x
ref target="RFC9053"/> and <xref target="RFC9054"/> and has added this document
as an additional reference for the registry.
</t>
<section anchor="new-cose-regs">
<name>Fully Specified COSE Algorithm Registrations</name>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ESP256</dd>
<dt>Value:</dt><dd>-9</dd>
<dt>Description:</dt><dd>ECDSA using P-256 curve and SHA-256</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>Yes</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ESP384</dd>
<dt>Value:</dt><dd>-51</dd>
<dt>Description:</dt><dd>ECDSA using P-384 curve and SHA-384</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>Yes</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ESP512</dd>
<dt>Value:</dt><dd>-52</dd>
<dt>Description:</dt><dd>ECDSA using P-521 curve and SHA-512</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>Yes</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ESB256</dd>
<dt>Value:</dt><dd>-265</dd>
<dt>Description:</dt><dd>ECDSA using BrainpoolP256r1 curve and SHA-25
6</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>No</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ESB320</dd>
<dt>Value:</dt><dd>-266</dd>
<dt>Description:</dt><dd>ECDSA using BrainpoolP320r1 curve and SHA-38
4</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>No</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ESB384</dd>
<dt>Value:</dt><dd>-267</dd>
<dt>Description:</dt><dd>ECDSA using BrainpoolP384r1 curve and SHA-38
4</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>No</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ESB512</dd>
<dt>Value:</dt><dd>-268</dd>
<dt>Description:</dt><dd>ECDSA using BrainpoolP512r1 curve and SHA-51
2</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="ECDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>No</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>Ed25519</dd>
<dt>Value:</dt><dd>-19</dd>
<dt>Description:</dt><dd>EdDSA using Ed25519 curve</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>Yes</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>Ed448</dd>
<dt>Value:</dt><dd>-53</dd>
<dt>Description:</dt><dd>EdDSA using Ed448 curve</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="EdDSA"/> of RFC 9864</dd>
<dt>Recommended:</dt><dd>Yes</dd>
</dl>
</section>
<section anchor="deprecated-cose-regs">
<name>Deprecated Polymorphic COSE Algorithm Registrations</name>
<t>
IANA has updated the status to "Deprecated" and has added this docume
nt as a reference for the following registrations.
</t>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ES256</dd>
<dt>Value:</dt><dd>-7</dd>
<dt>Description:</dt><dd>ECDSA w/ SHA-256</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
<dt>Recommended:</dt><dd>Deprecated</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ES384</dd>
<dt>Value:</dt><dd>-35</dd>
<dt>Description:</dt><dd>ECDSA w/ SHA-384</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
<dt>Recommended:</dt><dd>Deprecated</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ES512</dd>
<dt>Value:</dt><dd>-36</dd>
<dt>Description:</dt><dd>ECDSA w/ SHA-512</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
<dt>Recommended:</dt><dd>Deprecated</dd>
</dl>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>EdDSA</dd>
<dt>Value:</dt><dd>-8</dd>
<dt>Description:</dt><dd>EdDSA</dd>
<dt>Capabilities:</dt><dd>[kty]</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Reference:</dt><dd><xref target="RFC9053"/> and RFC 9864</dd>
<dt>Recommended:</dt><dd>Deprecated</dd>
</dl>
</section>
</section>
<section anchor="UpdatedInstructions">
<name>Updated Review Instructions for Designated Experts</name>
<section anchor="UpdatedInstructions1">
<name>JSON Web Signature and Encryption Algorithms</name>
<t>
The review instructions for the designated experts <xref target="RFC812
6"/> for the
"JSON Web Signature and Encryption Algorithms" registry <xref target="I
ANA.JOSE"/>
in <xref target="RFC7518" section="7.1"/>
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">
Only fully-specified algorithm identifiers may be <li>
registered. <t>
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
nd RFC 9054, <!--<t>IANA is directed to preserve the current references to <xref t
and to add a reference to this section of this specification. arget="RFC9053"/> and <xref target="RFC9054"/>
</t> and to add a reference to this section of this specification.</t>
<t> -->
The review instructions for the designated experts for the
IANA "COSE Algorithms" registry <xref target="IANA.COSE"/> <t>
in Section 10.4 of <xref target="RFC9053"/> The review instructions for the designated experts <xref target="RFC812
6"/> for the
"COSE Algorithms" registry <xref target="IANA.COSE"/>
in <xref target="RFC9053" section="10.4"/>
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">
Only fully-specified algorithm identifiers may be <li>
registered. <t>
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">
<name>Defining &quot;Deprecated&quot; and &quot;Prohibited&quot;</name>
<t>
<!-- [rfced] RFC 8152 has been obsoleted by RFC 9052. May we replace
all instances of RFC 8152 with RFC 9052, or may we add the
following sentence to the first mention of RFC 8152? Please let
us know your preference.
Original:
Furthermore, while in [RFC7518] JOSE specifies that both "Deprecated"
and "Prohibited" can be used, in [RFC8152] COSE specifies the use
of "Deprecated" but not "Prohibited".
Perhaps:
Furthermore, while in [RFC7518] JOSE specifies that both "Deprecated"
and "Prohibited" can be used, in [RFC8152] COSE specifies the use
of "Deprecated" but not "Prohibited" (note that [RFC8152] has been
obsoleted by [RFC9052]).
-->
<section title="Defining Deprecated and Prohibited" anchor="DeprecatedProh
ibited">
<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".
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="false" 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> <!-- [rfced] Section 4.4: We see that the entry for "Recommended"
</t> is formatted differently than the entries for "Deprecated" and
<t> "Prohibited" that appear just before it. Would you like all three
entries to be formatted in the same way?
Original:
Deprecated
There is a preferred mechanism to achieve similar functionality to
that referenced by the identifier; this replacement functionality
SHOULD be utilized in new deployments in preference to the
deprecated identifier, unless there exist documented operational
or regulatory requirements that prevent migration away from the
deprecated identifier.
Prohibited
The identifier and the functionality that it references MUST NOT
be used. (Identifiers may be designated as "Prohibited" due to
security flaws, for instance.)
...
Recommended: Does the IETF have a consensus recommendation to use
the algorithm? The legal values are "Yes", "No", "Filter Only",
"Prohibited", and "Deprecated".
Possibly:
Recommended
Does the IETF have a consensus recommendation to use the
algorithm? The legal values are "Yes", "No", "Filter Only",
"Prohibited", and "Deprecated". -->
<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, 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> <!-- [rfced] Section 4.4: Because the title of RFC 8996 is
"Deprecating TLS 1.0 and TLS 1.1", should 'the term "Deprecated" is
used in the title of [RFC8996]' be 'a variation of the term
"Deprecated" is used in the title of [RFC8996]'?
Original:
For instance, the term "Deprecated" is used in the title of
[RFC8996], but the actual specification text uses the terminology
"MUST NOT be used". -->
</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 ecified RSA algorithms. Some RSA signing implementations, such as This document does not describe or request registration of any fully sp ecified 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 This approach could be extended to define fully specified RSA algorithm
s in the future. 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.R
FC.7515.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.B." 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>
<references title="Normative References"> <!-- [rfced] [OpenID.Discovery]: We see "Jones, M.B." in this
document but "M. Jones" on the provided web page. We normally
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211 make the author listings in the document match what we see on
9.xml"/> the provided web page. Would it be possible for Mike to update
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.751 <https://openid.net/specs/openid-connect-discovery-1_0.html> and
5.xml"/> list his name as "M.B. Jones", or should we change "Jones, M.B." to
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.751 "Jones, M." here?
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.905
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"> Original:
<organization abbrev="Illumila">Illumila</organization> [OpenID.Discovery]
</author> Sakimura, N., Bradley, J., Jones, M.B., and E. Jay,
"OpenID Connect Discovery 1.0", 15 December 2023,
<https://openid.net/specs/openid-connect-discovery-
1_0.html>. -->
<date day="15" month="December" year="2023"/> <reference anchor="WebAuthn" target="https://www.w3.org/TR/2021/REC-weba
</front> uthn-2-20210408/">
</reference> <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-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.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." 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>
<refcontent>FIDO Alliance Proposed Standard</refcontent>
</reference>
<reference anchor="WebAuthn" target="https://www.w3.org/TR/2021/REC-webaut <!-- [rfced] The provided URL for [FIDO2] yields a 404. May we
hn-2-20210408/"> update as suggested (which includes correcting the names of the last
<front> two authors in the list)? If not, please provide a working URL and
<title>Web Authentication: An API for accessing Public Key Credentials correct information.
- 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 Original:
-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html"> [FIDO2] Bradley, J., Jones, M., Kumar, A., Lindemann, R., Johan,
<front> J., and D. David, "Client to Authenticator Protocol
<title>Client to Authenticator Protocol (CTAP)</title> (CTAP)", FIDO Alliance Proposed Standard, 28 February
<seriesInfo name="FIDO Alliance" value="Proposed Standard"/> 2025, <https://fidoalliance.org/specs/fido-v2.2-ps-
<author initials="J." surname="Bradley" fullname="John Bradley"> 20250228/fido-client-to-authenticator-protocol-v2.2-ps-
<organization>Yubico</organization> 20250228.html>.
<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 Suggested:
IPS/NIST.FIPS.140-3.pdf"> [FIDO2] Bradley, J., Jones, M.B., Kumar, A., Lindemann, R.,
<front> Verrept, J., and D. Waite, "Client to Authenticator
<title>Security Requirements for Cryptographic Modules</title> Protocol (CTAP)", FIDO Alliance Proposed Standard, 14
<author> July 2025, <https://fidoalliance.org/specs/
<organization>National Institute of Standards and Technology (NIST)</ fido-v2.2-ps-20250714/
organization> fido-client-to-authenticator-protocol-v2.2-ps-20250714.html>. -->
</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 <reference anchor="FIPS.140-3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NI
f"> ST.FIPS.140-3.pdf">
<front> <front>
<title>On using the same key pair for Ed25519 and an X25519 based KEM< <title>Security Requirements for Cryptographic Modules</title>
/title> <author>
<author fullname="Erik Thormarker" initials="E." surname="Thormarker"> <organization>NIST</organization>
<organization abbrev="Ericsson">Ericsson</organization> </author>
</author> <date month="March" year="2019"/>
<date day="23" month="April" year="2021"/> </front>
</front> <seriesInfo name="NIST FIPS" value="140-3"/>
</reference> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.140-3"/>
</reference>
<reference anchor="Reuse25519" target="https://eprint.iacr.org/2021/509.
pdf">
<front>
<title>On using the same key pair for Ed25519 and an X25519 based KE
M</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> </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> <t>
-13 The authors thank <contact fullname="Mike Bishop"/>, <contact
<list style="symbols"> fullname="Carsten Bormann"/>, <contact fullname="Mohamed Boucadair"/>,
<t> <contact fullname="John Bradley"/>, <contact fullname="Tim Bray"/>,
Applied suggestions by Mike Bishop and Paul Wouters. <contact fullname="Brian Campbell"/>, <contact fullname="Deb
</t> Cooley"/>, <contact fullname="Roman Danyliw"/>, <contact
</list> fullname="Stephen Farrell"/>, <contact fullname="Vijay Gurbani"/>,
</t> <contact fullname="Ilari Liusvaara"/>, <contact fullname="Tobias
Looker"/>, <contact fullname="Neil Madden"/>, <contact fullname="Kathleen
Moriarty"/>, <contact
fullname="Jeremy O'Donoghue"/>, <contact fullname="John Preuß Mattsson"/>
, <contact fullname="Anders Rundgren"/>,
<contact fullname="Göran Selander"/>, <contact fullname="Filip
Skokan"/>, <contact fullname="Oliver Terbu"/>, <contact
fullname="Hannes Tschofenig"/>, <contact fullname="Sean Turner"/>,
<contact fullname="Éric Vyncke"/>, <contact fullname="David Waite"/>,
<contact fullname="Paul Wouters"/>, and <contact fullname="Jiankang
Yao"/> for their contributions to this specification.
<t> <!-- [rfced] Acknowledgements: John Preuß Mattsson recently informed
-12 us that his last name is "Preuß Mattsson". Because it appears that
<list style="symbols"> the names should be listed in alphabetical order, we moved John's
<t> name in the list accordingly. Please let us know any concerns.
Changed requested COSE assignments for ESP384, ESP512, Ed25519, and E
d448
due to conflicts with the new ML-DSA assignments.
</t>
</list>
</t>
<t> Original:
-11 ...
<list style="symbols"> Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil
<t> Madden, John Preuß Mattsson, Kathleen Moriarty, Jeremy O'Donoghue,
Stated in the abstract that the specification deprecates Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes
some polymorphic algorithm identifiers, as suggested by Éric Vyncke. ...
</t>
</list>
</t>
<t> Currently:
-10 ...
<list style="symbols"> Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil
<t> Madden, Kathleen Moriarty, Jeremy O'Donoghue, John Preuß Mattsson,
Provided a complete list of the Recommended column terms for Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes
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>
</section>
</back>
<t> <!-- [rfced] Please review the "Inclusive Language" portion of the
-08 online Style Guide at
<list style="symbols"> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
<t> and let us know if any changes are needed. Updates of this nature
Updated requested Brainpool algorithm numbers to match those chosen b typically result in more precise language, which is helpful for
y Sean Turner. readers.
</t>
<t>
Incorporated wording suggestions by Vijay Gurbani.
</t>
</list>
</t>
<t> Note that our script did not flag any words in particular, but this
-07 should still be reviewed as a best practice. -->
<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> <!-- [rfced] Please let us know if any changes are needed for the
-06 following:
<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> a) The following term was used inconsistently in this document.
-05 We chose to use the latter form. Please let us know any objections.
<list style="symbols">
<t>
Applied IANA early review comments.
</t>
</list>
</t>
<t> fully-specified /
-04 fully specified (e.g., "are fully-specified", "are fully
<list style="symbols"> specified", "fully specified RSA algorithms")*
<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> * Per the Chicago Manual of Style
-03 ("Compounds formed by an adverb ending in ‑ly plus an adjective or
<list style="symbols"> participle (such as largely irrelevant or smartly dressed) are not
<t> hyphenated either before or after a noun, since ambiguity is
Acknowledged contributions made during Working Group Last Call. virtually impossible (a smartly dressed couple).")
</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> b) The following terms appear to be used inconsistently in this
-02 document. Please let us know which form is preferred.
<list style="symbols">
<t>
Expanded references for KEMs.
</t>
<t>
Added example of a fully-specified KEM.
</t>
</list>
</t>
<t> alg value (2 instances) / "alg" value (7 instances)
-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> enc value ("alg and enc values") / "enc" value (5 instances)
-00
<list style="symbols">
<t>
Created initial working group version based on draft-jones-jose-fully
-specified-algorithms-02.
</t>
</list>
</t>
</section> HSS/LMS / HSS-LMS ("HSS/LMS Hash-Based Digital Signature Algorithm",
"HSS-LMS algorithm")
<section title="Acknowledgements" anchor="Acknowledgements" numbered="no"> c) The following terms appear both with and without <tt> in the XML
<t> file. Please review, and let us know if the current applications of
The authors thank <tt> are correct and consistent.
Mike Bishop,
Carsten Bormann,
Mohamed Boucadair,
John Bradley,
Tim Bray,
Brian Campbell,
Deb Cooley,
Roman Danyliw,
Stephen Farrell,
Vijay Gurbani,
Ilari Liusvaara,
Tobias Looker,
Neil Madden,
John Preuß Mattsson,
Kathleen Moriarty,
Jeremy O'Donoghue,
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>
</section>
</back> <tt>Ed25519</tt> (no <tt>s in IANA Considerations section)
<tt>Ed448</tt> (no <tt>s in IANA Considerations section)
<tt>EdDSA</tt> usage of <tt> appears to be inconsistent (e.g., in
the XML file, we see
"This redefines the COSE <tt>EdDSA</tt> algorithm identifier" and
"The following fully specified JOSE and COSE EdDSA algorithms" -->
</rfc> </rfc>
 End of changes. 155 change blocks. 
1262 lines changed or deleted 1076 lines changed or added

This html diff was produced by rfcdiff 1.48.