draft-ietf-cose-webauthn-algorithms.xml

<?xml version='1.0' encoding='UTF-8'?>

<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="std" 
     ipr="trust200902" 
     docName="draft-ietf-cose-webauthn-algorithms-02">
  <front>

    <title>COSE and JOSE Registrations for WebAuthn Algorithms</title>

    <author fullname="Michael B. Jones" surname="Jones" initials="M.B.">
      <organization>Microsoft</organization>
      <address>
	<email>mbj@microsoft.com</email>
	<uri>http://self-issued.info/</uri>
      </address>
    </author>

    <date day="24" month="October" year="2019" />

    <area>Security</area>
    <workgroup>COSE Working Group</workgroup>

    <keyword>Cryptography</keyword>
    <keyword>Digital Signature</keyword>
    <keyword>Encryption</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>W3C</keyword>
    <keyword>World Wide Web Consortium</keyword>
    <keyword>WebAuthn</keyword>
    <keyword>Web Authentication</keyword>
    <keyword>FIDO Alliance</keyword>
    <keyword>FIDO</keyword>
    <keyword>FIDO2</keyword>
    <keyword>CTAP</keyword>
    <keyword>CTAP2</keyword>

    <abstract>
      <t>
	The W3C Web Authentication (WebAuthn) specification
	and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification
	use CBOR Object Signing and Encryption (COSE) algorithm identifiers.
	This specification registers the following algorithms in the IANA "COSE Algorithms" registry,
	which are used by WebAuthn and CTAP implementations:
	RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1,
	and ECDSA using the secp256k1 curve and SHA-256.
	It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry.
	Also, for use with JSON Object Signing and Encryption (JOSE),
	it registers the algorithm ECDSA using the secp256k1 curve and SHA-256
	in the IANA "JSON Web Signature and Encryption Algorithms" registry
	and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>
	This specification defines how to use several algorithms with
	CBOR Object Signing and Encryption (COSE) <xref target="RFC8152"/>
	that are used by implementations of the
	W3C Web Authentication (WebAuthn) <xref target="WebAuthn"/>
	and FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) <xref target="CTAP"/> specifications.
	These specification registers these algorithms in
	the IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms"/>
	and registers a related elliptic curve in the
	IANA "COSE Elliptic Curves" registry <xref target="IANA.COSE.Curves"/>.
	This specification also registers a corresponding algorithm
	for use with JSON Object Signing and Encryption (JOSE) <xref target="RFC7515"/> in
	the IANA "JSON Web Signature and Encryption Algorithms" registry <xref target="IANA.JOSE.Algorithms"/>
	and registers a related elliptic curve in the
	IANA "JSON Web Key Elliptic Curve" registry <xref target="IANA.JOSE.Curves"/>.
      </t>

      <section anchor="rnc" title="Requirements Notation and Conventions">
        <t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	  "OPTIONAL" in this document are to be interpreted as described in
	  BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
	  only when, they appear in all capitals, as shown here.
	</t>
      </section>
    </section>

    <section title="RSASSA-PKCS1-v1_5 Signature Algorithm" anchor="RSASSA-PKCS1-v1_5">
      <t>
	The RSASSA-PKCS1-v1_5 signature algorithm is defined in <xref target="RFC8017"/>.
	The RSASSA-PKCS1-v1_5 signature algorithm is parameterized with a hash function (h).
      </t>
      <t>
	A key of size 2048 bits or larger MUST be used with these algorithms.
	Implementations need to check that the key type is 'RSA' when creating or verifying a signature.
      </t>
      <t>
	The RSASSA-PKCS1-v1_5 algorithms specified in this document are in the following table.
      </t>
      <texttable anchor="table-rsa-algs" title="RSASSA-PKCS1-v1_5 Algorithm Values" suppress-title="false" align="center" style="full">
	<ttcol align="left">Name</ttcol>
	<ttcol align="left">Value</ttcol>
	<ttcol align="left">Hash</ttcol>
	<ttcol align="left">Description</ttcol>
	<ttcol align="left">Recommended</ttcol>

	<c>RS256</c>
	<c>TBD (temporary assignment -257 already in place)</c>
	<c>SHA-256</c>
	<c>RSASSA-PKCS1-v1_5 using SHA-256</c>
	<c>No</c>

	<c>RS384</c>
	<c>TBD (temporary assignment -258 already in place)</c>
	<c>SHA-384</c>
	<c>RSASSA-PKCS1-v1_5 using SHA-384</c>
	<c>No</c>

	<c>RS512</c>
	<c>TBD (temporary assignment -259 already in place)</c>
	<c>SHA-512</c>
	<c>RSASSA-PKCS1-v1_5 using SHA-512</c>
	<c>No</c>

	<c>RS1</c>
	<c>TBD (temporary assignment -65535 already in place)</c>
	<c>SHA-1</c>
	<c>RSASSA-PKCS1-v1_5 using SHA-1</c>
	<c>Deprecated</c>

      </texttable>
      <t>
	Note that these algorithms are already present in the
	IANA "JSON Web Signature and Encryption Algorithms" registry <xref target="IANA.JOSE.Algorithms"/>,
	and so these registrations are only for the
	IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms"/>.
      </t>
    </section>


    <section title="Using secp256k1 with JOSE and COSE" anchor="secp256k1">
      <t>
	This section defines algorithm encodings and representations enabling the
	Standards for Efficient Cryptography Group (SECG) elliptic curve
	secp256k1 <xref target="SEC2"/> to be used for
	JOSE <xref target="RFC7515"/> and
	COSE <xref target="RFC8152"/> messages.
      </t>

      <section title="JOSE and COSE secp256k1 Curve Key Representations" anchor="secp256k1_curve">
	<t>
	  The Standards for Efficient Cryptography Group (SECG) elliptic curve
	  secp256k1 <xref target="SEC2"/> is represented in
	  a JSON Web Key (JWK) <xref target="RFC7517"/> using these values:
	</t>
	<t>
	  <?rfc subcompact="yes"?>
	  <list style="symbols">  
	    <t><spanx style="verb">kty</spanx>: <spanx style="verb">EC</spanx></t>
	    <t><spanx style="verb">crv</spanx>: <spanx style="verb">secp256k1</spanx></t>
	  </list>
	  <?rfc subcompact="no"?>
	</t>
	<t>
	  plus the values needed to represent the curve point,
	  as defined in Section 6.2.1 of <xref target="RFC7518"/>.
	  As a compressed point encoding representation is not defined for JWK elliptic curve points,
	  the uncompressed point encoding defined there MUST be used.
	  The <spanx style="verb">x</spanx> and <spanx style="verb">y</spanx> values
	  represented MUST both be exactly 256 bits, with any leading zeros preserved.
	  Other optional values such as <spanx style="verb">alg</spanx> MAY also be present.
	</t>
	<t>
	  It is represented in a COSE_Key <xref target ="RFC8152"/> using these values:
	</t>
	<t>
	  <?rfc subcompact="yes"?>
	  <list style="symbols">  
	    <t><spanx style="verb">kty</spanx> (1): <spanx style="verb">EC2</spanx> (2)</t>
	    <t><spanx style="verb">crv</spanx> (-1): <spanx style="verb">secp256k1</spanx> (TBD - requested assignment 8)</t>
	  </list>
	  <?rfc subcompact="no"?>
	</t>
	<t>
	  plus the values needed to represent the curve point,
	  as defined in Section 13.1.1 of <xref target="RFC8152"/>.
	  Either the uncompressed or compressed point encoding representations defined there can be used.
	  The <spanx style="verb">x</spanx> value
	  represented MUST be exactly 256 bits, with any leading zeros preserved.
	  If the uncompressed representation is used, the <spanx style="verb">y</spanx> value
	  represented MUST likewise be exactly 256 bits, with any leading zeros preserved;
	  if the compressed representation is used, the <spanx style="verb">y</spanx> value
	  MUST be a boolean value, as specified in Section 13.1.1 of <xref target="RFC8152"/>.
	  Other optional values such as <spanx style="verb">alg</spanx> (3) MAY also be present.
	</t>
      </section>

      <section title="ECDSA Signature with secp256k1 Curve" anchor="secp256k1_ECDSA">
	<t>
	  The ECDSA signature algorithm is defined in <xref target="DSS"/>.
	  This specification defines the <spanx style="verb">ES256K</spanx> algorithm identifier,
	  which is used to specify the use of ECDSA with the secp256k1 curve
	  and the SHA-256 <xref target="DSS"/> cryptographic hash function.
	  Implementations need to check that the key type is <spanx style="verb">EC</spanx> for JOSE or
	  <spanx style="verb">EC2</spanx> (2) for COSE
	  and that the curve of the key is secp256k1
	  when creating or verifying a signature.
	</t>
	<t>
	  The ECDSA secp256k1 SHA-256 digital signature is generated as follows:

	  <list style="numbers">
	    <t>
	      Generate a digital signature of the JWS Signing Input
	      or the COSE Sig_structure
	      using ECDSA secp256k1 SHA-256 with
	      the desired private key. The output will be the pair
	      (R, S), where R and S are 256-bit unsigned integers.
	    </t>
	    <t>
	      Turn R and S into octet sequences in big-endian order,
	      with each array being be 32 octets long.
	      The octet sequence representations MUST NOT be shortened
	      to omit any leading zero octets contained in the values.
	    </t>
	    <t>
	      Concatenate the two octet sequences in the order R and then S.
	      (Note that many ECDSA implementations will directly produce
	      this concatenation as their output.)
	    </t>
	    <t>
	      The resulting 64-octet sequence is the JWS Signature or COSE signature value.
	    </t>
	  </list>
	</t>
	<t>
	  Implementations SHOULD use a deterministic algorithm to generate
	  the ECDSA nonce, k, such as <xref target="RFC6979"/>.
	  However, in situations where devices are vulnerable to physical attacks,
	  deterministic ECDSA has been shown to be susceptible to fault injection attacks
	  <xref target="Kudelski17"/> <xref target="EuroSP18"/>.
	  Where this is a possibility, implementations SHOULD implement appropriate countermeasures.
	  Where there are specific certification requirements (such as FIPS approval),
	  implementors should check whether deterministic ECDSA is an approved nonce generation method.
	</t>
	<t>
	  The ECDSA secp256k1 SHA-256 algorithm specified in this document uses these identifiers:
	</t>
	<texttable anchor="table-ec-algs" title="ECDSA Algorithm Values" suppress-title="false" align="center" style="full">
	  <ttcol align="left">JOSE Alg Name</ttcol>
	  <ttcol align="left">COSE Alg Value</ttcol>
	  <ttcol align="left">Description</ttcol>
	  <ttcol align="left">Recommended</ttcol>

	  <c>ES256K</c>
	  <c>TBD (requested assignment -46)</c>
	  <c>ECDSA using secp256k1 curve and SHA-256</c>
	  <c>Yes</c>

	</texttable>
	<t>
	  Implementation of this algorithm is RECOMMENDED because of its widespread use
	  in decentralized systems and those that chose it over the NIST curves.
	</t>
	<t>
	  When using a JWK or COSE_Key for this algorithm, the following checks are made:
	</t>
	<t>
	  <list style='symbols'>
	    <t>
	      The <spanx style="verb">kty</spanx> field MUST be present and
	      it MUST be <spanx style="verb">EC</spanx> for JOSE
	      or <spanx style="verb">EC2</spanx> for COSE.
	    </t>
	    <t>
	      The <spanx style="verb">crv</spanx> field MUST be present and
	      it MUST represent the <spanx style="verb">secp256k1</spanx> elliptic curve.
	    </t>
	    <t>
	      If the <spanx style="verb">alg</spanx> field is present,
	      it MUST represent the <spanx style="verb">ES256K</spanx> algorithm.
	    </t>
	    <t>
	      If the <spanx style="verb">key_ops</spanx> field is present,
	      it MUST include <spanx style="verb">sign</spanx> when creating an ECDSA signature.
	    </t>
	    <t>
	      If the <spanx style="verb">key_ops</spanx> field is present,
	      it MUST include <spanx style="verb">verify</spanx> when verifying an ECDSA signature.
	    </t>
	    <t>
	      If the JWK <spanx style="use">use</spanx> field is present,
	      its value MUST be <spanx style="verb">sig</spanx>.
	    </t>
	  </list>
	</t>
      </section>

      <section anchor="other-uses-of-secp256k1" title="Other Uses of the secp256k1 Elliptic Curve">
	<t>
	  This specification defines how to use the secp256k1 curve for ECDSA signatures
	  for both JOSE and COSE implementations.
	  While in theory, the curve could also be used for ECDH-ES key agreement,
	  it is beyond the scope of this specification to state whether this is or is not advisable.
	  Thus, whether to recommend its use with ECDH-ES is left for experts to decide in future specifications.
	</t>
	<t>
	  When used for ECDSA, the secp256k1 curve MUST be used only with the
	  <spanx style="verb">ES256K</spanx> algorithm identifier and not any others,
	  including not with <spanx style="verb">ES256</spanx>.
	</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">

      <section anchor="cose-algorithms-registrations" title="COSE Algorithms Registrations">
        <t>
	  This section registers the following values in the
	  IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms"/>.
	</t>
	<t>
	  <?rfc subcompact="yes"?>
	  <list style='symbols'>
	    <t>
	      Name: RS256
	    </t>
	    <t>
	      Value: TBD (temporary assignment -257 already in place)
	    </t>
	    <t>
	      Description: RSASSA-PKCS1-v1_5 using SHA-256
	    </t>
	    <t>
	      Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document 
	    </t>
	    <t>
	      Recommended: No
	    </t>
	  </list>
	</t>
	<t>
	  <list style='symbols'>
	    <t>
	      Name: RS384
	    </t>
	    <t>
	      Value: TBD (temporary assignment -258 already in place)
	    </t>
	    <t>
	      Description: RSASSA-PKCS1-v1_5 using SHA-384
	    </t>
	    <t>
	      Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document
	    </t>
	    <t>
	      Recommended: No
	    </t>
	  </list>
	</t>
	<t>
	  <list style='symbols'>
	    <t>
	      Name: RS512
	    </t>
	    <t>
	      Value: TBD (temporary assignment -259 already in place)
	    </t>
	    <t>
	      Description: RSASSA-PKCS1-v1_5 using SHA-512
	    </t>
	    <t>
	      Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document 
	    </t>
	    <t>
	      Recommended: No
	    </t>
	  </list>
	</t>
	<t>
	  <list style='symbols'>
	    <t>
	      Name: RS1
	    </t>
	    <t>
	      Value: TBD (temporary assignment -65535 already in place)
	    </t>
	    <t>
	      Description: RSASSA-PKCS1-v1_5 using SHA-1
	    </t>
	    <t>
	      Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document 
	    </t>
	    <t>
	      Recommended: Deprecated
	    </t>
	  </list>
	</t>
	<t>
	  <list style='symbols'>
	    <t>
	      Name: ES256K
	    </t>
	    <t>
	      Value: TBD (requested assignment -46)
	    </t>
	    <t>
	      Description: ECDSA using secp256k1 curve and SHA-256
	    </t>
	    <t>
	      Reference: <xref target="secp256k1_ECDSA"/> of this document
	    </t>
	    <t>
	      Recommended: Yes
	    </t>
	  </list>
	</t>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="cose-curve-registration" title="COSE Elliptic Curves Registrations">
	<t>
	  This section registers the following value in the
	  IANA "COSE Elliptic Curves" registry <xref target="IANA.COSE.Curves"/>.
	</t>
	<t>
	  <?rfc subcompact="yes"?>
	  <list style='symbols'>
	    <t>
	      Name: secp256k1
	    </t>
	    <t>
	      Value: TBD (requested assignment 8)
	    </t>
	    <t>
	      Key Type: EC2
	    </t>
	    <t>
	      Description: SECG secp256k1 curve
	    </t>
	    <t>
	      Change Controller: IESG
	    </t>
	    <t>
	      Reference: <xref target="secp256k1_curve"/> of [[ this specification ]]
	    </t>
	    <t>
	      Recommended: Yes
	    </t>
	  </list>
	</t>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="jose-algorithm-registration" title="JOSE Algorithms Registrations">
        <t>
	  This section registers the following value in the
	  IANA "JSON Web Signature and Encryption Algorithms" registry <xref target="IANA.JOSE.Algorithms"/>.
	</t>
	<t>
	  <?rfc subcompact="yes"?>
	  <list style='symbols'>
	    <t>
	      Algorithm Name: ES256K
	    </t>
	    <t>
	      Algorithm Description: ECDSA using secp256k1 curve and SHA-256
	    </t>
	    <t>
	      Algorithm Usage Locations: alg
	    </t>
	    <t>
	      JOSE Implementation Requirements: Optional
	    </t>
	    <t>
	      Change Controller: IESG
	    </t>
	    <t>
	      Reference: <xref target="secp256k1_ECDSA"/> of [[ this specification ]]
	    </t>
	    <t>
	      Algorithm Analysis Document(s): <xref target="SEC2"/>
	    </t>
	  </list>
	</t>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="jose-curve-registration" title="JSON Web Key Elliptic Curves Registrations">
	<t>
	  This section registers the following value in the
	  IANA "JSON Web Key Elliptic Curve" registry <xref target="IANA.JOSE.Curves"/>.
	</t>
	<t>
	  <?rfc subcompact="yes"?>
	  <list style='symbols'>
	    <t>
	      Curve Name: secp256k1
	    </t>
	    <t>
	      Curve Description: SECG secp256k1 curve
	    </t>
	    <t>
	      JOSE Implementation Requirements: Optional
	    </t>
	    <t>
	      Change Controller: IESG
	    </t>
	    <t>
	      Specification Document(s): <xref target="secp256k1_curve"/> of [[ this specification ]]
	    </t>
	  </list>
	</t>
	<?rfc subcompact="no"?>
      </section>

    </section>

    <section anchor="Security" title="Security Considerations">

      <section title="RSA Key Size Security Considerations" anchor="KeySize-considerations">
	<t>
	  The security considerations on key sizes for RSA algorithms
	  from Section 6.1 of <xref target="RFC8230"/> also apply to the RSA algorithms
	  in this specification.
	</t>
      </section>

      <section title="RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations" anchor="RSASSA-PKCS1-v1_5_SHA-2_considerations">
	<t>
	  The security considerations on the use of RSASSA-PKCS1-v1_5 with SHA-2 hash functions
	  from Section 8.3 of <xref target="RFC7518"/> also apply to their use
	  in this specification.
	  For that reason, these algorithms are registered as being "Not Recommended".
	</t>
      </section>

      <section title="RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations" anchor="RSASSA-PKCS1-v1_5_SHA-1_considerations">
	<t>
	  The security considerations on the use of the SHA-1 hash function
	  from <xref target="RFC6194"/> apply in this specification.
	  For that reason, the "RS1" algorithm is registered as "Deprecated".
	  Likewise, the exponent restrictions described in
	  Section 8.3 of <xref target="RFC7518"/> also apply.
	</t>
	<t>
	  A COSE algorithm identifier for this algorithm is nonetheless being registered
	  because deployed TPMs continue to use it, and therefore WebAuthn implementations
	  need a COSE algorithm identifier for "RS1" when TPM attestations using
	  this algorithm are being represented.
	  New COSE applications MUST NOT use this algorithm.
	</t>
      </section>

      <section title="secp256k1 Security Considerations" anchor="secp256k1_considerations">
	<t>
	  Care should be taken that a secp256k1 key is not mistaken for a P-256 <xref target="RFC7518"/> key,
	  given that their representations are the same
	  except for the <spanx style="verb">crv</spanx> value.
	</t>
	<t>
	  The procedures and security considerations described in the
	  <xref target="SEC1"/>, <xref target="SEC2"/>, and <xref target="DSS"/>
	  specifications apply to implementations of this specification.
	</t>
      </section>

    </section>

  </middle>

  <back>
    <references title="Normative References">

      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.6194.xml"?>
      <?rfc include="reference.RFC.7049.xml"?>
      <?rfc include="reference.RFC.7515.xml"?>
      <?rfc include="reference.RFC.7517.xml"?>
      <?rfc include="reference.RFC.7518.xml"?>
      <?rfc include="reference.RFC.8017.xml"?>
      <?rfc include="reference.RFC.8152.xml"?>
      <?rfc include="reference.RFC.8174.xml"?>
      <?rfc include="reference.RFC.8230.xml"?>

      <reference anchor="DSS" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">
        <front>
          <title>Digital Signature Standard (DSS)</title>

          <author>
            <organization>National Institute of Standards and
            Technology (NIST)</organization>
          </author>

          <date month="July" year="2013" />
        </front>
        <seriesInfo name="FIPS" value="PUB 186-4" />
      </reference>

      <reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
        <front>
          <title>SEC 1: Elliptic Curve Cryptography</title>
          <author>
            <organization>Standards for Efficient Cryptography Group</organization>
          </author>
          <date day="21" month="May" year="2009" />
        </front>
        <seriesInfo name="Version" value="2.0" />
      </reference>

      <reference anchor="SEC2" target="http://www.secg.org/sec2-v2.pdf">
        <front>
          <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
          <author>
            <organization>Standards for Efficient Cryptography Group</organization>
          </author>
          <date day="27" month="January" year="2010" />
        </front>
        <seriesInfo name="Version" value="2.0" />
      </reference>

    </references>

    <references title="Informative References">

      <?rfc include="reference.RFC.6979.xml"?>

      <reference anchor="WebAuthn" target="https://www.w3.org/TR/2019/REC-webauthn-1-20190304/">
        <front>
          <title>Web Authentication: An API for accessing Public Key Credentials - Level 1</title>
          <author initials="D." surname="Balfanz" fullname="Dirk Balfanz">
            <organization>Google</organization>
            <address>
              <email>balfanz@google.com</email>
            </address>
          </author>

          <author initials="A." surname="Czeskis" fullname="Alexei Czeskis">
            <organization>Google</organization>
            <address>
              <email>aczeskis@google.com</email>
            </address>
          </author>

          <author initials="J." surname="Hodges" fullname="Jeff Hodges">
            <organization>Google</organization>
            <address>
              <email>Jeff.Hodges@paypal.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="A." surname="Liao" fullname="Angelo Liao">
            <organization>Microsoft</organization>
            <address>
              <email>huliao@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="E." surname="Lundberg" fullname="Emil Lundberg">
            <organization>Yubico</organization>
            <address>
              <email>emil@yubico.com</email>
            </address>
          </author>

          <date month="March" day="4" year="2019" />
        </front>
        <seriesInfo name="World Wide Web Consortium (W3C)" value="Recommendation" />
      </reference>

      <reference anchor="CTAP" target="https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html">
        <front>
          <title>Client to Authenticator Protocol (CTAP)</title>
          <author initials="C." surname="Brand" fullname="Christiaan Brand">
            <organization>Google</organization>
            <address>
              <email>cbrand@google.com</email>
            </address>
          </author>

          <author initials="A." surname="Czeskis" fullname="Alexei Czeskis">
            <organization>Google</organization>
            <address>
              <email>aczeskis@google.com</email>
            </address>
          </author>

          <author initials="J." surname="Ehrensvärd" fullname="Jakob Ehrensvärd">
            <organization>Yubico</organization>
            <address>
              <email>jakob@yubico.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="R." surname="Lindemann" fullname="Rolf Lindemann">
            <organization>Nok Nok Labs</organization>
            <address>
              <email>rolf@noknok.com</email>
            </address>
          </author>

          <author initials="A." surname="Powers" fullname="Adam Powers">
            <organization>FIDO Alliance</organization>
            <address>
              <email>adam@fidoalliance.org</email>
            </address>
          </author>

          <author initials="J." surname="Verrept" fullname="Johan Verrept">
            <organization>OneSpan</organization>
            <address>
              <email>johan.verrept@onespan.com</email>
            </address>
          </author>

          <date month="January" day="30" year="2019" />
        </front>
        <seriesInfo name="FIDO Alliance" value="Proposed Standard" />
      </reference>

      <reference anchor="IANA.COSE.Algorithms" target="https://www.iana.org/assignments/cose/cose.xhtml#algorithms">
        <front>
          <title>COSE Algorithms</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

      <reference anchor="IANA.COSE.Curves" target="https://www.iana.org/assignments/cose/cose.xhtml#elliptic-curves">
        <front>
          <title>COSE Elliptic Curves</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>


      <reference anchor="IANA.JOSE.Algorithms" target="https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms">
        <front>
          <title>JSON Web Signature and Encryption Algorithms</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

      <reference anchor="IANA.JOSE.Curves" target="https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve">
        <front>
          <title>JSON Web Key Elliptic Curve</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

      <reference anchor="Kudelski17"
		 target="https://research.kudelskisecurity.com/2017/10/04/defeating-eddsa-with-faults/">
	<front>
	  <title>How to defeat Ed25519 and EdDSA using faults</title>
	  <author fullname="Yolan Romailler" surname="Romailler" initials="Y.">
	    <organization>Kudelski Security</organization>
	  </author>

	  <date day="4" month="October" year="2017"/>
	</front>
      </reference>

      <reference anchor="EuroSP18"
		 target="https://eprint.iacr.org/2017/1014.pdf">
	<front>
	  <title>Attacking Deterministic Signature Schemes using Fault Attacks</title>
	  <author fullname="Damian Poddebniak" surname="Poddebniak" initials="D.">
	    <organization>Münster University of Applied Sciences</organization>
	  </author>
	  <author fullname="Juraj Somorovsky" surname="Somorovsky" initials="J.">
	    <organization>Ruhr University Bochum</organization>
	  </author>
	  <author fullname="Sebastian Schinzel" surname="Schinzel" initials="S.">
	    <organization>Münster University of Applied Sciences</organization>
	  </author>
	  <author fullname="Manfred Lochter" surname="Lochter" initials="M.">
	    <organization>Federal Office for Information Security</organization>
	  </author>
	  <author fullname="Paul Rösler" surname="Rösler" initials="P.">
	    <organization>Ruhr University Bochum</organization>
	  </author>

	  <date day="1" month="April" year="2018"/>
	</front>
	<seriesInfo name="IEEE European Symposium on Security and Privacy (EuroS&amp;P)" value="2018"/>
      </reference>

    </references>

    <section title="Acknowledgements" anchor="Acknowledgements" numbered="no">

      <t>
	Thanks to
	Stephen Farrell,
	John Fontana,
	Jeff Hodges,
	Kevin Jacobs,
	J.C. Jones,
	Benjamin Kaduk,
	Neil Madden,
	John Mattsson,
	Tony Nadalin,
	Matt Palmer,
	Jim Schaad,
	Göran Selander,
	Wendy Seltzer,
	Sean Turner,
	and
	Samuel Weiler
	for their roles in registering these algorithm identifiers.
      </t>
    </section>

    <section title="Document History" anchor="History">
      <t>
        [[ to be removed by the RFC Editor before publication as an RFC ]]
      </t>

      <t>
        -02
        <list style='symbols'>
          <t>
	    Addressed working group last call comments.
	    Thanks to J.C. Jones, Kevin Jacobs, Jim Schaad, Neil Madden, and Benjamin Kaduk
	    for their useful feedback.
	  </t>
        </list>
      </t>

      <t>
        -01
        <list style='symbols'>
          <t>
	    Changed the JOSE curve identifier from <spanx style="verb">P-256K</spanx>
	    to <spanx style="verb">secp256k1</spanx>.
          </t>
	  <t>
	    Specified that secp256k1 signing is done using the SHA-256 hash function.
	  </t>
        </list>
      </t>

      <t>
        -00
        <list style='symbols'>
          <t>
	    Created the initial working group draft from draft-jones-cose-additional-algorithms-00,
	    changing only the title, date, and history entry.
          </t>
        </list>
      </t>

    </section>

  </back>
</rfc>