wdiff rfc9864xml2.original.xml rfc9864.xml

<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>

<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<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">

  <?rfc toc="yes"?>
  <?rfc tocompact="yes"?>
  <?rfc tocdepth="5"?>
  <?rfc tocindent="yes"?>
  <?rfc symrefs="yes"?>
  <?rfc sortrefs="yes"?>
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?> 9053" obsoletes="" tocInclude="true" tocDepth="5" symRefs="true" sortRefs="true" version="3" xml:lang="en">

  <front>
    <title abbrev="Fully-Specified Algorithms">Fully-Specified abbrev="Fully Specified Algorithms">Fully Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)</title>

<!-- [rfced] Please note that the document title has been updated as
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</title> 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">
      <organization>Self-Issued Consulting</organization>
      <address>
        <email>michael_b_jones@hotmail.com</email>
        <uri>https://self-issued.info/</uri>
      </address>
    </author>
    <author fullname="Orie Steele" initials="O." surname="Steele">
      <organization>Transmute</organization>
      <address>
        <email>orie@transmute.industries</email>
      </address>
    </author>
    <date day="10" month="May" year="2025" />

    <area>Security</area>
    <workgroup>JOSE Working Group</workgroup> month="September" year="2025"/>
    <area>SEC</area>
    <workgroup>jose</workgroup>

    <keyword>Cryptographic Algorithm Identifiers</keyword>
    <keyword>JSON Object Signing and Encryption (JOSE)</keyword>
    <keyword>CBOR Object Signing and Encryption (COSE)</keyword>
    <keyword>Polymorphic Algorithms</keyword>
    <keyword>Algorithm Cipher Suites</keyword>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>
	This specification refers to cryptographic algorithm identifiers
	that fully specify the cryptographic operations to be performed,
	including any curve, key derivation function (KDF), and hash functions,
	as being "fully specified".
	It refers to cryptographic algorithm identifiers
	that require additional information beyond the algorithm identifier
	to determine the cryptographic operations to be performed
	as being "polymorphic".
	This specification creates fully-specified fully specified algorithm identifiers for registered
	JSON Object Signing and Encryption (JOSE) and
	CBOR Object Signing and Encryption (COSE)
	polymorphic algorithm identifiers,
	enabling applications to use only fully-specified fully specified algorithm identifiers.
	It deprecates those polymorphic algorithm identifiers.
      </t>
      <t>
	This specification updates RFC RFCs 7518, RFC 8037, and RFC 9053.
	It deprecates polymorphic algorithms defined by RFC RFCs 8037 and RFC 9053
	and provides fully-specified fully specified replacements for them.
	It adds to the instructions to designated experts in RFC RFCs 7518 and RFC 9053.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> anchor="Introduction">
      <name>Introduction</name>
      <t>
	The IANA algorithm registries for
	JSON Object Signing and Encryption (JOSE) algorithms <xref target="IANA.JOSE"/> and
	CBOR Object Signing and Encryption (COSE) algorithms <xref target="IANA.COSE"/>
	contain two kinds of algorithm identifiers:
      </t>
      <t>
	<list style="hanging">

          <t hangText="Fully Specified">
	    <vspace/>
      <dl newline="true" spacing="normal">
        <dt>Fully Specified</dt>
        <dd>
	    Those that fully determine the cryptographic operations to be performed,
	    including any curve, key derivation function (KDF), and hash functions.
	    Examples are <spanx style="verb">RS256</spanx> <tt>RS256</tt> and <spanx style="verb">ES256K</spanx> <tt>ES256K</tt>
	    in both JOSE <xref target="IANA.JOSE"/> and COSE <xref target="IANA.COSE"/>
	    and <spanx style="verb">ES256</spanx> <tt>ES256</tt> in JOSE.
	  </t>

          <t hangText="Polymorphic">
	    <vspace/>
	  </dd>
        <dt>Polymorphic</dt>
        <dd>
	    Those requiring information beyond the algorithm identifier
	    to determine the cryptographic operations to be performed.
	    Such additional information could include the actual key value and a curve that it uses.
	    Examples are <spanx style="verb">EdDSA</spanx> the <tt>Edwards-curve Digital Signature Algorithm (EdDSA)</tt>
	    in both JOSE <xref target="IANA.JOSE"/> and COSE <xref target="IANA.COSE"/>
	    and <spanx style="verb">ES256</spanx> <tt>ES256</tt> in COSE.
	  </t>

	</list>
      </t>
	  </dd>
      </dl>
      <t>
	This matters because many protocols negotiate supported operations using only algorithm identifiers.
	For instance, OAuth Authorization Server Metadata <xref target="RFC8414"/>
	uses negotiation parameters like these (from an example in the that specification):
	<figure><artwork><![CDATA[
      </t>
      <artwork><![CDATA[
  "token_endpoint_auth_signing_alg_values_supported":
    ["RS256", "ES256"]
]]></artwork></figure>
      </t>
]]></artwork>
      <t>
	OpenID Connect Discovery <xref target="OpenID.Discovery"/> likewise negotiates supported algorithms
	using <spanx style="verb">alg</spanx> <tt>alg</tt> and <spanx style="verb">enc</spanx> <tt>enc</tt> values.
	W3C Web Authentication <xref target="WebAuthn"/> and
	the FIDO Client to Authenticator Protocol (CTAP) <xref target="FIDO2"/>
	negotiate using COSE <spanx style="verb">alg</spanx> <tt>alg</tt> numbers.
      </t>
      <t>
	This does not work for polymorphic algorithms.
	For instance, with <spanx style="verb">EdDSA</spanx>, <tt>EdDSA</tt>, it is not known which of the curves
	<spanx style="verb">Ed25519</spanx>
	<tt>Ed25519</tt> and/or <spanx style="verb">Ed448</spanx> <tt>Ed448</tt> are supported.
	This causes real problems in practice.
      </t>
      <t>
	WebAuthn contains this de-facto de facto algorithm definition to work around this problem:
	<figure><artwork><![CDATA[
      </t>
      <artwork><![CDATA[
  -8 (EdDSA), where crv is 6 (Ed25519)
]]></artwork></figure>
      </t>
]]></artwork>
      <t>
	This redefines the COSE <spanx style="verb">EdDSA</spanx> <tt>EdDSA</tt> algorithm identifier
	for the purposes of WebAuthn to restrict it to using
	the <spanx style="verb">Ed25519</spanx> <tt>Ed25519</tt> curve - -- making it non-polymorphic
	so that algorithm negotiation can succeed, but also effectively
	eliminating the possibility of using <spanx style="verb">Ed448</spanx>. <tt>Ed448</tt>.
	Other similar workarounds for polymorphic algorithm identifiers are used in practice.
      </t>
      <t>
	Note that using fully-specified fully specified algorithms is sometimes
	referred to as the "cipher suite" approach;
	using polymorphic algorithms is sometimes
	referred to as the "à la carte" approach.
      </t>
      <t>
	This specification creates fully-specified fully specified algorithm identifiers for registered
	polymorphic JOSE and COSE algorithms and their parameters,
	enabling applications to use only fully-specified fully specified algorithm identifiers.
	Furthermore, it deprecates the practice of registering polymorphic algorithm identifiers.
      </t>
      <section anchor="rnc" title="Requirements anchor="rnc">
        <name>Requirements Notation and Conventions">
        <t>
	  The Conventions</name>
         <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
         "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
         "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
         "<bcp14>SHOULD NOT</bcp14>",
         "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
         "<bcp14>MAY</bcp14>", and
	  "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
         are to be interpreted as described in
	  BCP 14 BCP&nbsp;14
         <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
         when, they appear in all capitals, as shown here.
	</t> here.</t>
      </section>
    </section>
    <section anchor="fully-specified-algs" title="Fully-Specified anchor="fully-specified-algs">
      <name>Fully Specified Digital Signature Algorithm Identifiers"> Identifiers</name>
      <t>
	This section creates fully-specified fully specified digital signature algorithm identifiers for a set of registered
	polymorphic JOSE and COSE algorithms and their parameters.
      </t>
      <section anchor="ECDSA" title="Elliptic anchor="ECDSA">
        <name>Elliptic Curve Digital Signature Algorithm (ECDSA)"> (ECDSA)</name>
        <t>
	  <xref target="RFC9053"/> defines a way to use
	  the Elliptic Curve Digital Signature Algorithm (ECDSA) with COSE.
	  The COSE algorithm registrations for ECDSA are polymorphic,
	  since they do not specify the curve used.
	  For instance, <spanx style="verb">ES256</spanx> <tt>ES256</tt> is defined as
	  "ECDSA w/ SHA-256" in Section 2.1 of <xref target="RFC9053"/>. target="RFC9053" section="2.1"/>.
	  (The corresponding JOSE registrations in <xref target="RFC7518"/> are fully specified.)

<!-- [rfced] Section 2.1:  Because it appears that "full-specified"
means "fully specified", we updated this text accordingly.  If this
is incorrect, please let us know what "full-specified" means
(possibly "specified in full"?).

Original:
 (The corresponding JOSE registrations in [RFC7518] are
 full-specified.)

Currently:
 (The corresponding JOSE registrations in [RFC7518] are
 fully specified.) -->

        </t>
        <t>
	  The following fully-specified fully specified COSE ECDSA algorithms are defined by this specification:
        </t>
	<texttable

        <table anchor="ecdsa-algs" title="ECDSA align="center">
          <name>ECDSA Algorithm Values" suppress-title="false" align="center" style="full">
	  <ttcol align="left">Name</ttcol>
	  <ttcol Values</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">COSE Value</ttcol>
	  <ttcol align="left">Description</ttcol>
	  <ttcol Value</th>
              <th align="left">Description</th>
              <th align="left">COSE Recommended</ttcol>

	  <c>ESP256</c>
	  <c>TBD (requested assignment -9)</c>
	  <c>ECDSA 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</c>
	  <c>Yes</c>

	  <c>ESP384</c>
	  <c>TBD (requested assignment -51)</c>
	  <c>ECDSA 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</c>
	  <c>Yes</c>

	  <c>ESP512</c>
	  <c>TBD (requested assignment -52)</c>
	  <c>ECDSA 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</c>
	  <c>Yes</c>

	  <c>ESB256</c>
	  <c>TBD (requested assignment -265)</c>
	  <c>ECDSA 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</c>
	  <c>No</c>

	  <c>ESB320</c>
	  <c>TBD (requested assignment -266)</c>
	  <c>ECDSA 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</c>
	  <c>No</c>

	  <c>ESB384</c>
	  <c>TBD (requested assignment -267)</c>
	  <c>ECDSA 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</c>
	  <c>No</c>

	  <c>ESB512</c>
	  <c>TBD (requested assignment -268)</c>
	  <c>ECDSA 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</c>
	  <c>No</c>

	</texttable> SHA-512</td>
              <td align="left">No</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="EdDSA" title="Edwards-Curve anchor="EdDSA">
        <name>Edwards-curve Digital Signature Algorithm (EdDSA)"> (EdDSA)</name>
        <t>
	  <xref target="RFC8037"/> defines a way to use
	  the Edwards-Curve Digital Signature Algorithm (EdDSA)
	  EdDSA
	  with JOSE JOSE, and <xref target="RFC9053"/> defines a way to use it with COSE.
	  Both register polymorphic <spanx style="verb">EdDSA</spanx> <tt>EdDSA</tt> algorithm identifiers.
        </t>
        <t>
	  The following fully-specified fully specified JOSE and COSE EdDSA algorithms are defined by this specification:
        </t>
	<texttable
        <table anchor="eddsa-algs" title="EdDSA align="center">
          <name>EdDSA Algorithm Values" suppress-title="false" align="center" style="full">
	  <ttcol align="left">Name</ttcol>
	  <ttcol Values</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">COSE Value</ttcol>
	  <ttcol align="left">Description</ttcol>
	  <ttcol Value</th>
              <th align="left">Description</th>
              <th align="left">JOSE Implementation Requirements</ttcol>
	  <ttcol Requirements</th>
              <th align="left">COSE Recommended</ttcol>

	  <c>Ed25519</c>
	  <c>TBD (requested assignment -19)</c>
	  <c>EdDSA Recommended</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Ed25519</td>
              <td align="left">-19</td>
              <td align="left">EdDSA using Ed25519 curve</c>
	  <c>Optional</c>
	  <c>Yes</c>

	  <c>Ed448</c>
	  <c>TBD (requested assignment -53)</c>
	  <c>EdDSA curve</td>
              <td align="left">Optional</td>
              <td align="left">Yes</td>
            </tr>
            <tr>
              <td align="left">Ed448</td>
              <td align="left">-53</td>
              <td align="left">EdDSA using Ed448 curve</c>
	  <c>Optional</c>
	  <c>Yes</c>

	</texttable> curve</td>
              <td align="left">Optional</td>
              <td align="left">Yes</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="fully-specified-enc" title="Fully-Specified Encryption"> anchor="fully-specified-enc">
      <name>Fully Specified Encryption</name>
      <t>
	This section describes the construction of fully-specified fully specified encryption algorithm 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
	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>
	Using fully-specified fully specified encryption algorithms enables the sender and receiver
	to agree on all mandatory security parameters.
	They also enable protocols to specify an allow list of
	algorithm combinations that does not include polymorphic combinations,
	preventing problems
	such as cross-curve key establishment,
	cross-protocol symmetric encryption,
	or mismatched KDF size to symmetric key scenarios.
      </t>
      <t>
	Both JOSE and COSE have operations that take multiple algorithms as parameters.
	Encrypted objects in JOSE <xref target="RFC7516"/> use two algorithm identifiers:
	the first in the "alg" (Algorithm) Header Parameter,
	which specifies how to determine the content encryption key, and
	the second in the "enc" (Encryption Algorithm) Header Parameter,
	which specifies the content encryption algorithm.
	Likewise, encrypted COSE objects can use multiple algorithms
	for corresponding purposes.
	This section describes how to fully specify encryption algorithms
	for JOSE and COSE.
      </t>
      <t>
	To perform fully-specified fully specified encryption in JOSE,
	the "alg" value MUST <bcp14>MUST</bcp14> specify all parameters for key establishment
	or derive some of them from the accompanying "enc" value value, and
	the "enc" value MUST <bcp14>MUST</bcp14> specify all parameters for symmetric encryption.
	For example, JWE encryption via JWE using
	an "alg" value of "A128KW" (AES Key Wrap using 128-bit key) and
	an "enc" value of "A128GCM" (AES GCM using 128-bit key)
	uses fully-specified fully specified algorithms.
      </t>
      <t>
	Note that in JOSE, there is the option to derive some cryptographic parameters
	used in the "alg" computation from the accompanying "enc" value.
	An example of this is that
	For example, the keydatalen KDF parameter value
	for "ECDH-ES" is determined from the "enc" value,
	as described in Section 4.6.2 of <xref target="RFC7518"/>. target="RFC7518" section="4.6.2"/>.
	For the purposes of an "alg" value being fully-specified, fully specified,
	deriving parameters from "enc" does not make the algorithm polymorphic,
	as the computation is still fully determined by the algorithm identifiers used.
	This option is not present in COSE.
      </t>
      <t>
	To perform fully-specified fully specified encryption in COSE,
	the outer "alg" value MUST <bcp14>MUST</bcp14> specify all parameters for key establishment establishment, and
	the inner "alg" value must specify all parameters for symmetric encryption.
	For example, COSE encryption via COSE using
	an outer "alg" value of A128KW "A128KW" and
	an inner "alg" value of A128GCM "A128GCM"
	uses fully-specified fully specified algorithms.
	Note that when using COSE_Encrypt,
	as specified in Section 5.1 of <xref target="RFC9052"/>, target="RFC9052" section="5.1"/>,
	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 object.

<!-- [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>
	While this specification provides a definition of what
	fully-specified
	fully specified encryption algorithm identifiers are for both JOSE and COSE,
	it does not deprecate any polymorphic encryption algorithms,
	since replacements for them are not provided by this specification.
	This is discussed in <xref target="ECDH"/>.
      </t>
      <section anchor="fully-spec-enc-algs" title="Fully-Specified anchor="fully-spec-enc-algs">
        <name>Fully Specified Encryption Algorithms"> Algorithms</name>
        <t>
	  Many of the registered JOSE and COSE algorithms used for encryption
	  are already fully-specified. fully specified.  This section discusses them.
        </t>
        <t>
	  All the symmetric encryption algorithms registered by <xref target="RFC7518"/>
	  and <xref target="RFC9053"/> are fully-specified. fully specified.
	  An example of a fully-specified fully specified symmetric encryption algorithm is
	  "A128GCM" (AES GCM using 128-bit key).
        </t>
        <t>
	  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).

<!-- [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 COSE direct+HKDF algorithms are fully specified.
        </t>
        <t>
	  The JOSE Key Encryption with PBES2 algorithms are fully specified.
        </t>
      </section>
      <section anchor="polymorphic-enc-algs" title="Polymorphic anchor="polymorphic-enc-algs">
        <name>Polymorphic Encryption Algorithms"> Algorithms</name>
        <t>
	  Some of the registered JOSE and COSE algorithms used for encryption
	  are polymorphic.  This section discusses them.
        </t>
        <t>
	  The ECDH Elliptic Curve Diffie-Hellman (ECDH) key establishment algorithms in both JOSE and COSE
	  are polymorphic because they do not specify the elliptic curve
	  to be used for the key.
	  This is true of the ephemeral key for the Ephemeral-Static (ES) algorithms
	  registered for JOSE and COSE and of the static key for
	  the Static-Static (SS) algorithms registered by COSE.
	  See more discussion of ECDH algorithms in <xref target="ECDH"/>.
        </t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
      <section anchor="jose-algorithm-registration" title="JOSE Algorithms Registrations">
        <t> 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 additional reference for the registry.

<!-- [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.

 "JSON Web Signature and Encryption Algorithms" registry:
   https://www.iana.org/assignments/jose

 "COSE Algorithms" registry:
   https://www.iana.org/assignments/cose

a) Section 4.1: As the "JSON Web Signature and Encryption Algorithms"
registry was established by RFC 7518, we have replaced RFC 7515 with
RFC 7518 as shown below. We have also removed RFC 7515 from the
normative references section as it was only mentioned in Section 4.1.
Note that RFC 7518 is listed as an informative reference;
please let us know if this is okay as is or if it should be
normative.

We also included that this document was listed as an additional
reference for the registry at the end of the sentence below
(and have removed the related text from Section 4.3, which
describes the updates to the review instructions for the DEs).
Note that a similar change was made to Section 4.2 for the "COSE
Algorithms" registry, as shown below.

Please review and let us know of any objections.

Original (Section 4.1):
 This section registers the following values in the IANA "JSON Web
 Signature and Encryption Algorithms" registry <xref target="IANA.JOSE"/> [IANA.JOSE] established
 by <xref target="RFC7515"/>. [RFC7515].

Currently:
 IANA has registered the values in this section in the "JSON Web
 Signature and Encryption Algorithms" registry [IANA.JOSE]
 established by [RFC7518] and has listed this document as
 an additional reference for the registry.

...
Original (Section 4.2):
 This section registers the following values in the IANA "COSE
 Algorithms" registry [IANA.COSE].

Currently:
 IANA has registered the following values in the "COSE Algorithms"
 registry [IANA.COSE] established by [RFC9053] and [RFC9054]
 and has added this document as an additional reference for the
 registry.

b) Per the changes noted in a) above, we will ask IANA to update
the reference for the "COSE Algorithms" registry as shown below
(i.e., update the section number listed for this document).

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 for:
 ESP256
 ESP384
 ESP512
 ESB256
 ESB320
 ESB384
 ESB512

Section 2.2 listed in the document
but not in the registry for:
 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?

Currently 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" title="Fully-Specified anchor="new-jose-regs">
          <name>Fully Specified JOSE Algorithm Registrations">
	  <t>
	    <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>
		Algorithm Name: Ed25519
	      </t>
	      <t>
		Algorithm Description: EdDSA Registrations</name>
          <dl newline="false" spacing="compact">
	    <dt>Algorithm Name:</dt><dd>Ed25519</dd>
	    <dt>Algorithm Description:</dt><dd>EdDSA using Ed25519 curve
	      </t>
	      <t>
		Algorithm curve</dd>
	    <dt>Algorithm Usage Locations: alg
	      </t>
	      <t>
		JOSE Locations:</dt><dd>alg</dd>
	    <dt>JOSE Implementation Requirements: Optional
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref Requirements:</dt><dd>Optional</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><xref target="EdDSA"/> of [[ this specification ]]
	      </t>
	      <t>
		Algorithm RFC 9864</dd>
	    <dt>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 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
	      </t>
	      <t>
		Algorithm curve</dd>
	    <dt>Algorithm Usage Locations: alg
	      </t>
	      <t>
		JOSE Locations:</dt><dd>alg</dd>
	    <dt>JOSE Implementation Requirements: Optional
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref Requirements:</dt><dd>Optional</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><xref target="EdDSA"/> of [[ this specification ]]
	      </t>
	      <t>
		Algorithm RFC 9864</dd>
	    <dt>Algorithm Analysis Document(s): <xref target="RFC8032"/>
	      </t>
	    </list>
	  </t>
	  <?rfc subcompact="no"?> Document(s):</dt><dd><xref target="RFC8032"/></dd>
          </dl>
        </section>
        <section anchor="deprecated-jose-regs" title="Deprecated anchor="deprecated-jose-regs">
          <name>Deprecated Polymorphic JOSE Algorithm Registrations"> Registration</name>
          <t>
	    The following registration is
	    IANA has updated to change its the status to Deprecated.
	  </t>
	  <t>
	    <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>
		Algorithm Name: EdDSA "Deprecated" for the following registration.
          </t>
	      <t>
		Algorithm Description: EdDSA
          <dl newline="false" spacing="compact">
	    <dt>Algorithm Name:</dt><dd>EdDSA</dd>
	    <dt>Algorithm Description:</dt><dd>EdDSA signature algorithms
	      </t>
	      <t>
		Algorithm algorithms</dd>
	    <dt>Algorithm Usage Locations: alg
	      </t>
	      <t>
		JOSE Locations:</dt><dd>alg</dd>
	    <dt>JOSE Implementation Requirements: Deprecated
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref Requirements:</dt><dd>Deprecated</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><xref target="EdDSA"/> of [[ this specification ]]
	      </t>
	      <t>
		Algorithm RFC 9864</dd>
	    <dt>Algorithm Analysis Document(s): <xref target="RFC8032"/>
	      </t>
	    </list>
	  </t>
	  <?rfc subcompact="no"?> Document(s):</dt><dd><xref target="RFC8032"/></dd>
          </dl>
        </section>
      </section>
      <section anchor="cose-algorithms-registrations" title="COSE Algorithms Registrations"> anchor="cose-algorithms-registrations">
        <name>COSE Algorithm Registrations</name>
        <t>
	  This section registers
	  IANA has registered the following values in the
	  IANA
	  "COSE Algorithms" registry <xref target="IANA.COSE"/>. target="IANA.COSE"/> established by <xref target="RFC9053"/> and <xref target="RFC9054"/> and has added this document as an additional reference for the registry.
        </t>
        <section anchor="new-cose-regs" title="Fully-Specified anchor="new-cose-regs">
          <name>Fully Specified COSE Algorithm Registrations">
	  <t>
	    <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>
		Name: ESP256
	      </t>
	      <t>
		Value: TBD (requested assignment -9)
	      </t>
	      <t>
		Description: ECDSA 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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref SHA-256</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref SHA-384</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref SHA-512</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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-256
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref SHA-256</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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-384
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref SHA-384</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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-384
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref SHA-384</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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-512
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref SHA-512</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref curve</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><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 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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: <xref curve</dd>
	    <dt>Capabilities:</dt><dd>[kty]</dd>
	    <dt>Change Controller:</dt><dd>IETF</dd>
	    <dt>Reference:</dt><dd><xref target="EdDSA"/> of [[ this specification ]]
	      </t>
	      <t>
		Recommended: Yes
	      </t>
	    </list>
	  </t>
	  <?rfc subcompact="no"?> RFC 9864</dd>
	    <dt>Recommended:</dt><dd>Yes</dd>
          </dl>
        </section>
        <section anchor="deprecated-cose-regs" title="Deprecated anchor="deprecated-cose-regs">
          <name>Deprecated Polymorphic COSE Algorithm Registrations"> Registrations</name>
          <t>
	    The following registrations are
	    IANA has updated to change their the status to Deprecated.
	  </t>
	  <t>
	    <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>
		Name: ES256
	      </t>
	      <t>
		Value: -7 "Deprecated" and has added this document as a reference for the following registrations.
          </t>
	      <t>
		Description: ECDSA
          <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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: 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 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 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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: 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 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 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
	      </t>
	      <t>
		Capabilities: [kty]
	      </t>
	      <t>
		Change Controller: IETF
	      </t>
	      <t>
		Reference: 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 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: 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 9053
	      </t>
	      <t>
		Recommended: Deprecated
	      </t>
	    </list>
	  </t>
	  <?rfc subcompact="no"?> 9864</dd>
	    <dt>Recommended:</dt><dd>Deprecated</dd>
          </dl>
        </section>
      </section>
      <section anchor="UpdatedInstructions" title="Updated anchor="UpdatedInstructions">
        <name>Updated Review Instructions for Designated Experts"> Experts</name>
        <section anchor="UpdatedInstructions1" title="JSON anchor="UpdatedInstructions1">
          <name>JSON Web Signature and Encryption Algorithms">
	<t>
		IANA is directed to preserve the current reference to RFC 7518,
		and to add a reference to this section of this specification.
	</t> Algorithms</name>
          <t>
	  The review instructions for the designated experts <xref target="RFC8126"/> for the
	  IANA
	  "JSON Web Signature and Encryption Algorithms" registry <xref target="IANA.JOSE"/>
	  in Section 7.1 of <xref target="RFC7518"/> target="RFC7518" section="7.1"/>
	  have been updated to include an additional review criterion:
	  <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
				Only fully-specified fully specified algorithm identifiers may be registered.
	      Polymorphic algorithm identifiers must not be registered.
              </t>
	  </list>
	</t>
            </li>
          </ul>
        </section>
        <section anchor="UpdatedInstructions2" title="COSE Algorithms">
	<t>
		IANA is directed to preserve the current references to RFC 9053 and RFC 9054,
		and to add a reference to this section of this specification.
	</t> anchor="UpdatedInstructions2">
          <name>COSE Algorithms</name>
          <t>
	  The review instructions for the designated experts <xref target="RFC8126"/> for the
	  IANA
	  "COSE Algorithms" registry <xref target="IANA.COSE"/>
	  in Section 10.4 of <xref target="RFC9053"/> target="RFC9053" section="10.4"/>
	  have been updated to include an additional review criterion:
	  <list style="symbols">
          </t>
          <ul spacing="normal">
            <li>
              <t>
				Only fully-specified fully specified algorithm identifiers may be registered.
	      Polymorphic algorithm identifiers must not be registered.
              </t>
	  </list>
	</t>
            </li>
          </ul>
        </section>
      </section>
      <section title="Defining Deprecated and Prohibited" 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]).
-->

	  The terms "Deprecated" and "Prohibited"
	  as used by JOSE and COSE registrations are currently undefined.
	  Furthermore, while in <xref target="RFC7518"/> JOSE specifies that both
	  "Deprecated" and "Prohibited" can be used,
	  in <xref target="RFC8152"/> COSE specifies
	  the use of "Deprecated" but not "Prohibited".
	  This section defines these terms for use by both
	  JOSE and COSE IANA registrations in a consistent manner,
	  eliminating this potentially confusing inconsistency.
        </t>
        <t>
	  For purposes of use in the "JOSE Implementation Requirements" columns
	  in the IANA JOSE registries <xref target="IANA.JOSE"/> and
	  in the "Recommended" columns
	  in the IANA COSE registries <xref target="IANA.COSE"/>,
	  these terms are defined as follows:
        </t>
	<t>
	  <list style="hanging">

	    <t hangText="Deprecated">
	      <vspace/>
        <dl newline="true" spacing="normal">
          <dt>Deprecated</dt>
          <dd>
	      There is a preferred mechanism to achieve similar functionality
	      similar to that referenced by the identifier;
	      this replacement functionality SHOULD <bcp14>SHOULD</bcp14> 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.
	    </t>

	    <t hangText="Prohibited">
	      <vspace/>
	    </dd>
          <dt>Prohibited</dt>
          <dd>
	      The identifier and the functionality that it references MUST NOT <bcp14>MUST NOT</bcp14> be used.
	      (Identifiers may be designated as "Prohibited" due to security flaws,
	      for instance.)
	    </t>

	  </list>
	</t>
	    </dd>
        </dl>
        <t>
	  For completeness, these definitions bring the set of defined terms
	  for use in the "Recommended" columns
	  in the IANA COSE registries <xref target="IANA.COSE"/> to
	  "Yes" <xref target="RFC8152"/>,
	  "No" <xref target="RFC8152"/>,
	  "Filter Only" <xref target="RFC9054"/>,
	  "Prohibited",
	  and
	  "Deprecated".
	  This updates the definitions of the "Recommended" columns
	  in these registries to be:
	  <list style="hanging">
            <t hangText="Recommended:">
        </t>
        <dl newline="false" spacing="normal">
          <dt>Recommended:</dt>
          <dd>
	      Does the IETF have a consensus recommendation to use the algorithm?
	      The legal values are
	      "Yes",
	      "No",
	      "Filter Only",
	      "Prohibited",
	      and
	      "Deprecated".
	    </t>
	  </list>
	</t>
	<t>
	</t>
	    </dd>
        </dl>

<!-- [rfced] Section 4.4:  We see that the entry for "Recommended"
is formatted differently than the entries for "Deprecated" and
"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
	  for use in the "JOSE Implementation Requirements" columns
	  in the IANA JOSE registries <xref target="IANA.JOSE"/>
	  are unchanged.
        </t>
        <t>
	  Note that the terms "Deprecated" and "Prohibited" have been used
	  with a multiplicity of different meanings in various specifications,
	  sometimes without actually being defined in those specifications.
	  For instance, the term "Deprecated" is used in the title of
	  <xref target="RFC8996"/>, but the actual specification text
	  uses the terminology "<bcp14>MUST NOT</bcp14> be used".

<!-- [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
	  all existing registrations in both JOSE and COSE;
	  none will need to change.
	  Furthermore, they are consistent with their existing usage in JOSE.
	  The only net change is to enable a clear distinction between
	  "Deprecated" and "Prohibited" in future COSE registrations.
        </t>
      </section>
    </section>
    <section anchor="Keys" title="Key Representations"> anchor="Keys">
      <name>Key Representations</name>
      <t>
	The key representations for the new fully-specified fully specified algorithms
	defined by this specification are the same as those for the
	polymorphic algorithms that they replace,
	other than the <spanx style="verb">alg</spanx> <tt>alg</tt> value, if included.
	For instance, the representation for a key used with the
	<spanx style="verb">Ed25519</spanx>
	<tt>Ed25519</tt> algorithm is the same as that specified
	in <xref target="RFC8037"/>, except that the <spanx style="verb">alg</spanx> <tt>alg</tt>
	value would be <spanx style="verb">Ed25519</spanx> <tt>Ed25519</tt> rather than
	<spanx style="verb">EdDSA</spanx>,
	<tt>EdDSA</tt>, if included.
      </t>
    </section>
    <section anchor="NotUpdated" title="Notes anchor="NotUpdated">
      <name>Notes on Algorithms Not Updated"> Updated</name>
      <t>
	Some existing polymorphic algorithms
	are not updated by this specification.
	This section discusses why they have not been updated.
      </t>
      <section anchor="RSA" title="RSA anchor="RSA">
        <name>RSA Signing Algorithms"> Algorithms</name>
        <t>
	  There are different points of view on whether the
	  <spanx style="verb">RS256</spanx>,
	  <spanx style="verb">RS384</spanx>,
	  <tt>RS256</tt>,
	  <tt>RS384</tt>, and
	  <spanx style="verb">RS512</spanx>
	  <tt>RS512</tt> algorithms
	  should be considered fully-specified fully specified or not,
	  because they can operate on keys of different sizes.
	  For instance, they can use both 2048- and 4096-bit keys.
	  The same is true of the <spanx style="verb">PS*</spanx> <tt>PS*</tt> algorithms.
        </t>
        <t>
	  This document does not describe or request registration of any fully specified RSA algorithms. Some RSA signing implementations, such as
	  FIPS-compliant Hardware Security Modules (HSMs) <xref target="FIPS.140-3"/>
	  limit RSA key parameters to specific values with acceptable security characteristics.
	  This approach could be extended to define fully-specified fully specified RSA algorithms in the future.
        </t>
        <t>
	  That said, should it be useful at some point to have
	  RSA algorithm identifiers that are specific to particular key characteristics,
	  a future specification could always register them.
        </t>
      </section>
      <section anchor="ECDH" title="ECDH anchor="ECDH">
        <name>ECDH Key Agreement Algorithms"> Algorithms</name>
        <t>
	  This specification does not update the
	  Elliptic Curve Diffie-Hellman (ECDH)
	  ECDH algorithms,
	  but it describes how to potentially do so in the future, if needed.
	  The registered JOSE and COSE ECDH algorithms are polymorphic
	  because they do not specify the curve to be used for the ephemeral key.
        </t>
        <t>
	  Fully-specified
	  Fully specified versions of these algorithms would specify all choices
	  needed, including the KDF and the curve.
	  For instance, an algorithm performing
	  ECDH-ES using the Concat KDF and the P-256 curve, curve
	  would be fully-specified fully specified and could be defined and registered.
	  While this specification does not
	  define and register such replacement algorithms,
	  other specifications could do so in the future, if desired.
        </t>
      </section>
      <section anchor="HSS-LMS" title="HSS/LMS anchor="HSS-LMS">
        <name>HSS/LMS Hash-Based Digital Signature Algorithm"> Algorithm</name>
        <t>
	  The HSS-LMS algorithm registered by COSE is polymorphic.
	  It is polymorphic because the algorithm identifier does not specify
	  the hash function to be used.
	  Like ECDH, this specification does not register replacement
	  algorithms, but future specifications could do so.
        </t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>
	The security considerations for ECDSA in <xref target="RFC7518"/>,
	for EdDSA in <xref target="RFC8037"/>, and
	for ECDSA and EdDSA in <xref target="RFC9053"/> apply.
      </t>
      <t>
	The security considerations for preventing cross-protocol attacks
	described in <xref target="RFC9459"/> apply.
      </t>
      <t>
	An "attack signature" is a unique pattern or characteristic used to identify malicious activity, enabling systems to detect and respond to known threats.
	The digital signature and key establishment algorithms used by software can contribute to an attack signature.
	By varying the identifier used for an algorithm, some software systems may 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 fully specified algorithms.
	These systems should be aware that writing rules for polymorphic algorithms is more difficult, as each variant of the algorithm must be accounted for.
	For example, ES384 in COSE might be used with 3 three different keys, each with a different curve.
      </t>
      <t>
A cryptographic key MUST <bcp14>MUST</bcp14> be used with only a single algorithm
unless the use of the same key with different algorithms is proven secure.
See <xref target="Reuse25519"/> for an example of such a proof.
As a result, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the algorithm parameter of JSON Web Keys and COSE Keys be present,
unless there exists some other mechanism for ensuring that the key is used as intended.
      </t>
      <t>
	In COSE, preventing cross-protocol attacks,
	such as those described in <xref target="RFC9459"/>,
	can be accomplished in two ways:
	<list style="numbers">
      </t>
      <ol spacing="normal" type="1"><li>
          <t>
	    Allow only authenticated content encryption (AEAD) (Authenticated Encryption with Associated Data (AEAD)) algorithms.
          </t>
        </li>
        <li>
          <t>
	    Bind the potentially unauthenticated content encryption algorithm
	    to be used into to the key protection algorithm so that different
	    content encryption algorithms result in different content encryption keys.
          </t>
	</list>
        </li>
      </ol>
      <t>
	Which choice to use in which circumstances is beyond the scope of this specification.
      </t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
     <!--   <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml"/>-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8037.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9053.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/>
      </references>

    <references title="Informative References">
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8414.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9054.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9459.xml"/>
        <reference anchor="IANA.JOSE" target="https://www.iana.org/assignments/jose/">
          <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/cose/">
          <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/openid-connect-discovery-1_0.html">
          <front>
            <title>OpenID Connect Discovery 1.0</title> 1.0 incorporating errata set 2</title>
            <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</organization>
            </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>

<!-- [rfced] [OpenID.Discovery]:  We see "Jones, M.B." in this
document but "M. Jones" on the provided web page.  We normally
make the author listings in the document match what we see on
the provided web page.  Would it be possible for Mike to update
<https://openid.net/specs/openid-connect-discovery-1_0.html> and
list his name as "M.B. Jones", or should we change "Jones, M.B." to
"Jones, M." here?

Original:
 [OpenID.Discovery]
            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>. -->

        <reference anchor="WebAuthn" target="https://www.w3.org/TR/2021/REC-webauthn-2-20210408/">
          <front>
            <title>Web Authentication: An API for accessing Public Key Credentials - Level 2</title>
          <seriesInfo name="World Wide Web Consortium (W3C)" value="Recommendation"/>
            <author initials="J." surname="Hodges" fullname="Jeff Hodges"> Hodges" role="editor">
              <organization>PayPal</organization>
              <address>
                <email>jdhodges@google.com</email>
              </address>
            </author>
            <author initials="J.C." surname="Jones" fullname="J.C. Jones"> Jones" role="editor">
              <organization>Mozilla</organization>
              <address>
                <email>jc@mozilla.com</email>
              </address>
            </author>
            <author initials="M.B." surname="Jones" fullname="Michael B. Jones"> 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"> Kumar" role="editor">
              <organization>Microsoft</organization>
              <address>
                <email>akshayku@microsoft.com</email>
              </address>
            </author>
            <author initials="E." surname="Lundberg" fullname="Emil Lundberg"> Lundberg" role="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>
          <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>
          <refcontent>FIDO Alliance Proposed Standard</refcontent>
        </reference>

<!-- [rfced] The provided URL for [FIDO2] yields a 404.  May we
update as suggested (which includes correcting the names of the last
two authors in the list)?  If not, please provide a working URL and
correct information.

Original:
 [FIDO2]    Bradley, J., Jones, M., Kumar, A., Lindemann, R., Johan,
            J., and D. David, "Client to Authenticator Protocol
            (CTAP)", FIDO Alliance Proposed Standard, 28 February
            2025, <https://fidoalliance.org/specs/fido-v2.2-ps-
            20250228/fido-client-to-authenticator-protocol-v2.2-ps-
            20250228.html>.

Suggested:
 [FIDO2]    Bradley, J., Jones, M.B., Kumar, A., Lindemann, R.,
            Verrept, J., and D. Waite, "Client to Authenticator
            Protocol (CTAP)", FIDO Alliance Proposed Standard, 14
            July 2025, <https://fidoalliance.org/specs/
            fido-v2.2-ps-20250714/
            fido-client-to-authenticator-protocol-v2.2-ps-20250714.html>. -->

<reference anchor="FIPS.140-3" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf">
  <front>
    <title>Security Requirements for Cryptographic Modules</title>
    <author>
	    <organization>National Institute of Standards and Technology (NIST)</organization>
      <organization>NIST</organization>
    </author>
    <date day="22" month="March" year="2019" /> year="2019"/>
  </front>
  <seriesInfo name="FIPS" value="PUB 140-3" /> name="NIST FIPS" value="140-3"/>
  <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 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">
      <t>
        [[ 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 Ed448
	    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"> anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>
	    Provided a complete list of the Recommended column terms
	The authors thank <contact fullname="Mike Bishop"/>, <contact
	fullname="Carsten Bormann"/>, <contact fullname="Mohamed Boucadair"/>,
	<contact fullname="John Bradley"/>, <contact fullname="Tim Bray"/>,
	<contact fullname="Brian Campbell"/>, <contact fullname="Deb
	Cooley"/>, <contact fullname="Roman Danyliw"/>, <contact
	fullname="Stephen Farrell"/>, <contact fullname="Vijay Gurbani"/>,
	<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
	    COSE registrations, as suggested by Mohamed Boucadair.
	  </t>
	  <t>
	    Applied suggestions to improve the exposition received during IESG review.
	  </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 their contributions to match those chosen by 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 this specification.

<!-- [rfced] Acknowledgements:  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 algorithm 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 Mattsson recently informed
us that his last name is "Preuß Mattsson".  Because it appears that
the terms "Deprecated" and "Prohibited" for both JOSE and COSE 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 names should be listed in alphabetical order, we moved John's
name in the section Fully-Specified Computations Using Multiple Algorithms.
	  </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>
	The authors thank
	Mike Bishop,
	Carsten Bormann,
	Mohamed Boucadair,
	John Bradley,
	Tim Bray,
	Brian Campbell,
	Deb Cooley,
	Roman Danyliw, list accordingly.  Please let us know any concerns.

Original:
...
 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,
...

Currently:
...
 Stephen Farrell, Vijay Gurbani, Ilari Liusvaara, Tobias Looker, Neil
 Madden, Kathleen Moriarty, Jeremy O'Donoghue, John Preuß Mattsson,
 Anders Rundgren, Göran Selander, Filip Skokan, Oliver Terbu, Hannes
... -->

      </t>
    </section>
  </back>

<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and
	Jiankang Yao let us know if any changes are needed.  Updates of this nature
typically result in more precise language, which is helpful for their contributions
readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->

<!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following term was used inconsistently in this document.
We chose to use the latter form.  Please let us know any objections.

 fully-specified /
   fully specified (e.g., "are fully-specified", "are fully
   specified", "fully specified RSA algorithms")*

 * Per the Chicago Manual of Style
 ("Compounds formed by an adverb ending in ‑ly plus an adjective or
 participle (such as largely irrelevant or smartly dressed) are not
 hyphenated either before or after a noun, since ambiguity is
 virtually impossible (a smartly dressed couple).")

b) The following terms appear to be used inconsistently in this specification.
      </t>
    </section>

  </back>
document.  Please let us know which form is preferred.

 alg value (2 instances) / "alg" value (7 instances)

 enc value ("alg and enc values") / "enc" value (5 instances)

 HSS/LMS / HSS-LMS ("HSS/LMS Hash-Based Digital Signature Algorithm",
   "HSS-LMS algorithm")

c) The following terms appear both with and without <tt> in the XML
file.  Please review, and let us know if the current applications of
<tt> are correct and consistent.

 <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>