rfc8812xml2.original.xml   rfc8812.xml 
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/r nsus="true" docName="draft-ietf-cose-webauthn-algorithms-08" indexInclude="true"
fc2629.xslt' ?> ipr="trust200902" number="8812" prepTime="2020-08-14T16:14:44" scripts="Common,
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocIncl
ude="true" xml:lang="en">
<?rfc toc="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-cose-webauthn-algorith
<?rfc tocompact="yes"?> ms-08" rel="prev"/>
<?rfc tocdepth="4"?> <link href="https://dx.doi.org/10.17487/rfc8812" rel="alternate"/>
<?rfc tocindent="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
ipr="trust200902"
docName="draft-ietf-cose-webauthn-algorithms-08">
<front> <front>
<title abbrev="COSE &amp; JOSE Registrations for WebAuthn Algs">CBOR Object
<title abbrev="COSE &amp; JOSE Registrations for WebAuthn Algs">COSE and JOS Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Regi
E Registrations for WebAuthn Algorithms</title> strations for Web Authentication (WebAuthn) Algorithms</title>
<seriesInfo name="RFC" value="8812" stream="IETF"/>
<author fullname="Michael B. Jones" surname="Jones" initials="M.B."> <author fullname="Michael B. Jones" surname="Jones" initials="M">
<organization>Microsoft</organization> <organization showOnFrontPage="true">Microsoft</organization>
<address> <address>
<email>mbj@microsoft.com</email> <email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri> <uri>https://self-issued.info/</uri>
</address> </address>
</author> </author>
<date month="08" year="2020"/>
<date day="11" month="June" year="2020" />
<area>Security</area> <area>Security</area>
<workgroup>COSE Working Group</workgroup> <workgroup>COSE Working Group</workgroup>
<keyword>Cryptography</keyword> <keyword>Cryptography</keyword>
<keyword>Digital Signature</keyword> <keyword>Digital Signature</keyword>
<keyword>Encryption</keyword> <keyword>Encryption</keyword>
<keyword>Internet-Draft</keyword>
<keyword>W3C</keyword> <keyword>W3C</keyword>
<keyword>World Wide Web Consortium</keyword> <keyword>World Wide Web Consortium</keyword>
<keyword>WebAuthn</keyword> <keyword>WebAuthn</keyword>
<keyword>Web Authentication</keyword> <keyword>Web Authentication</keyword>
<keyword>FIDO Alliance</keyword> <keyword>FIDO Alliance</keyword>
<keyword>FIDO</keyword> <keyword>FIDO</keyword>
<keyword>FIDO2</keyword> <keyword>FIDO2</keyword>
<keyword>CTAP</keyword> <keyword>CTAP</keyword>
<keyword>CTAP2</keyword> <keyword>CTAP2</keyword>
<abstract pn="section-abstract">
<abstract> <t pn="section-abstract-1">
<t> The W3C Web Authentication (WebAuthn) specification and the FIDO
The W3C Web Authentication (WebAuthn) specification Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use
and the FIDO Alliance Client to Authenticator Protocol (CTAP) specificati CBOR Object Signing and Encryption (COSE) algorithm identifiers. This
on specification registers the following algorithms (which are used by
use CBOR Object Signing and Encryption (COSE) algorithm identifiers. WebAuthn and CTAP implementations) in the IANA "COSE Algorithms"
This specification registers the following algorithms in the IANA "COSE A registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and
lgorithms" registry, SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA)
which are used by WebAuthn and CTAP implementations: using the secp256k1 curve and SHA-256. It registers the secp256k1
RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1, elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for
and ECDSA using the secp256k1 curve and SHA-256. use with JSON Object Signing and Encryption (JOSE), it registers the
It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curv algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON
es" registry. Web Signature and Encryption Algorithms" registry and the secp256k1
Also, for use with JSON Object Signing and Encryption (JOSE), elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.
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> </t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8812" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-requirements-
notation-and-c">Requirements Notation and Conventions</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-rsassa-pkcs1-v1_5-signatu
re">RSASSA-PKCS1-v1_5 Signature Algorithm</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter
" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-using-secp256k1-with-jose-a">Using secp256k1
with JOSE and COSE</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" forma
t="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-jose-and-cose-secp256k1-cur">JOSE
and COSE secp256k1 Curve Key Representations</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" forma
t="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-ecdsa-signature-with-secp25">ECDS
A Signature with secp256k1 Curve</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" forma
t="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-other-uses-of-the-secp256k1">Othe
r Uses of the secp256k1 Elliptic Curve</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter
" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xre
f></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" forma
t="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-cose-algorithms-registratio">COSE
Algorithms Registrations</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" forma
t="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-cose-elliptic-curves-regist">COSE
Elliptic Curves Registrations</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" forma
t="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-jose-algorithms-registratio">JOSE
Algorithms Registrations</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" forma
t="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-json-web-key-elliptic-curve">JSON
Web Key Elliptic Curves Registrations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter
" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-security-considerations">Security Considerati
ons</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" forma
t="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-rsa-key-size-security-consi">RSA
Key Size Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" forma
t="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-rsassa-pkcs1-v1_5-with-sha-">RSAS
SA-PKCS1-v1_5 with SHA-2 Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" forma
t="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-rsassa-pkcs1-v1_5-with-sha-1">RSA
SSA-PKCS1-v1_5 with SHA-1 Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" forma
t="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-secp256k1-security-consider">secp
256k1 Security Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter
" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" forma
t="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-normative-references">Normative R
eferences</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" forma
t="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-informative-references">Informati
ve References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" se
ctionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="ti
tle" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></
t>
</li>
<li pn="section-toc.1-1.8">
<t pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" se
ctionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="ti
tle" sectionFormat="of" target="name-authors-address">Author's Address</xref></t
>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="include" removeInRFC="fa
<t> lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
This specification defines how to use several algorithms with This specification defines how to use several algorithms with
CBOR Object Signing and Encryption (COSE) <xref target="RFC8152"/> CBOR Object Signing and Encryption (COSE) <xref target="RFC8152" format=" default" sectionFormat="of" derivedContent="RFC8152"/>
that are used by implementations of the that are used by implementations of the
W3C Web Authentication (WebAuthn) <xref target="WebAuthn"/> W3C Web Authentication (WebAuthn) <xref target="WebAuthn" format="default
and FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) <xref tar " sectionFormat="of" derivedContent="WebAuthn"/>
get="CTAP"/> specifications. and FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) <xref tar
get="CTAP" format="default" sectionFormat="of" derivedContent="CTAP"/> specifica
tions.
This specification registers these algorithms in This specification registers these algorithms in
the IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms"/> the IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms" f ormat="default" sectionFormat="of" derivedContent="IANA.COSE.Algorithms"/>
and registers an elliptic curve in the and registers an elliptic curve in the
IANA "COSE Elliptic Curves" registry <xref target="IANA.COSE.Curves"/>. IANA "COSE Elliptic Curves" registry <xref target="IANA.COSE.Curves" form at="default" sectionFormat="of" derivedContent="IANA.COSE.Curves"/>.
This specification also registers a corresponding algorithm This specification also registers a corresponding algorithm
for use with JSON Object Signing and Encryption (JOSE) <xref target="RFC7 for use with JSON Object Signing and Encryption (JOSE) <xref target="RFC7
515"/> in 515" format="default" sectionFormat="of" derivedContent="RFC7515"/> in
the IANA "JSON Web Signature and Encryption Algorithms" registry <xref ta the IANA "JSON Web Signature and Encryption Algorithms" registry <xref ta
rget="IANA.JOSE.Algorithms"/> rget="IANA.JOSE.Algorithms" format="default" sectionFormat="of" derivedContent="
IANA.JOSE.Algorithms"/>
and registers an elliptic curve in the and registers an elliptic curve in the
IANA "JSON Web Key Elliptic Curve" registry <xref target="IANA.JOSE.Curve s"/>. IANA "JSON Web Key Elliptic Curve" registry <xref target="IANA.JOSE.Curve s" format="default" sectionFormat="of" derivedContent="IANA.JOSE.Curves"/>.
</t> </t>
<section anchor="rnc" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="rnc" title="Requirements Notation and Conventions"> ="section-1.1">
<t> <name slugifiedName="name-requirements-notation-and-c">Requirements Nota
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", tion and Conventions</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t pn="section-1.1-1">
"OPTIONAL" in this document are to be interpreted as described in The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
only when, they appear in all capitals, as shown here. ",
</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP 14 <xref target="RFC2119" format="default" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
ear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section anchor="RSASSA-PKCS1-v1_5" numbered="true" toc="include" removeInRF
<section title="RSASSA-PKCS1-v1_5 Signature Algorithm" anchor="RSASSA-PKCS1- C="false" pn="section-2">
v1_5"> <name slugifiedName="name-rsassa-pkcs1-v1_5-signature">RSASSA-PKCS1-v1_5 S
<t> ignature Algorithm</name>
The RSASSA-PKCS1-v1_5 signature algorithm is defined in <xref target="RFC <t pn="section-2-1">
8017"/>. The RSASSA-PKCS1-v1_5 signature algorithm is defined in <xref target="RFC
8017" format="default" sectionFormat="of" derivedContent="RFC8017"/>.
The RSASSA-PKCS1-v1_5 signature algorithm is parameterized with a hash fu nction (h). The RSASSA-PKCS1-v1_5 signature algorithm is parameterized with a hash fu nction (h).
</t> </t>
<t> <t pn="section-2-2">
A key of size 2048 bits or larger MUST be used with these algorithms. A key of size 2048 bits or larger <bcp14>MUST</bcp14> be used with these
algorithms.
Implementations need to check that the key type is 'RSA' when creating or verifying a signature. Implementations need to check that the key type is 'RSA' when creating or verifying a signature.
</t> </t>
<t> <t pn="section-2-3">
The RSASSA-PKCS1-v1_5 algorithms specified in this document are in the fo llowing table. The RSASSA-PKCS1-v1_5 algorithms specified in this document are in the fo llowing table.
</t> </t>
<texttable anchor="table-rsa-algs" title="RSASSA-PKCS1-v1_5 Algorithm Valu <table anchor="rsa-algs" align="center" pn="table-1">
es" suppress-title="false" align="center" style="full"> <name slugifiedName="name-rsassa-pkcs1-v1_5-algorithm">RSASSA-PKCS1-v1_5
<ttcol align="left">Name</ttcol> Algorithm Values</name>
<ttcol align="left">Value</ttcol> <thead>
<ttcol align="left">Hash</ttcol> <tr>
<ttcol align="left">Description</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<ttcol align="left">Recommended</ttcol> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Hash</th>
<c>RS256</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>TBD (temporary assignment -257 already in place)</c> <th align="left" colspan="1" rowspan="1">Recommended</th>
<c>SHA-256</c> </tr>
<c>RSASSA-PKCS1-v1_5 using SHA-256</c> </thead>
<c>No</c> <tbody>
<tr>
<c>RS384</c> <td align="left" colspan="1" rowspan="1">RS256</td>
<c>TBD (temporary assignment -258 already in place)</c> <td align="left" colspan="1" rowspan="1">-257</td>
<c>SHA-384</c> <td align="left" colspan="1" rowspan="1">SHA-256</td>
<c>RSASSA-PKCS1-v1_5 using SHA-384</c> <td align="left" colspan="1" rowspan="1">RSASSA-PKCS1-v1_5 using SHA
<c>No</c> -256</td>
<td align="left" colspan="1" rowspan="1">No</td>
<c>RS512</c> </tr>
<c>TBD (temporary assignment -259 already in place)</c> <tr>
<c>SHA-512</c> <td align="left" colspan="1" rowspan="1">RS384</td>
<c>RSASSA-PKCS1-v1_5 using SHA-512</c> <td align="left" colspan="1" rowspan="1">-258</td>
<c>No</c> <td align="left" colspan="1" rowspan="1">SHA-384</td>
<td align="left" colspan="1" rowspan="1">RSASSA-PKCS1-v1_5 using SHA
<c>RS1</c> -384</td>
<c>TBD (temporary assignment -65535 already in place)</c> <td align="left" colspan="1" rowspan="1">No</td>
<c>SHA-1</c> </tr>
<c>RSASSA-PKCS1-v1_5 using SHA-1</c> <tr>
<c>Deprecated</c> <td align="left" colspan="1" rowspan="1">RS512</td>
<td align="left" colspan="1" rowspan="1">-259</td>
</texttable> <td align="left" colspan="1" rowspan="1">SHA-512</td>
<t> <td align="left" colspan="1" rowspan="1">RSASSA-PKCS1-v1_5 using SHA
-512</td>
<td align="left" colspan="1" rowspan="1">No</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">RS1</td>
<td align="left" colspan="1" rowspan="1">-65535</td>
<td align="left" colspan="1" rowspan="1">SHA-1</td>
<td align="left" colspan="1" rowspan="1">RSASSA-PKCS1-v1_5 using SHA
-1</td>
<td align="left" colspan="1" rowspan="1">Deprecated</td>
</tr>
</tbody>
</table>
<t pn="section-2-5">
Security considerations for use of the first three algorithms Security considerations for use of the first three algorithms
are in <xref target="RSASSA-PKCS1-v1_5_SHA-2_considerations"/>. are in <xref target="RSASSA-PKCS1-v1_5_SHA-2_considerations" format="defa ult" sectionFormat="of" derivedContent="Section 5.2"/>.
Security considerations for use of the last algorithm Security considerations for use of the last algorithm
are in <xref target="RSASSA-PKCS1-v1_5_SHA-1_considerations"/>. are in <xref target="RSASSA-PKCS1-v1_5_SHA-1_considerations" format="defa ult" sectionFormat="of" derivedContent="Section 5.3"/>.
</t> </t>
<t> <t pn="section-2-6">
Note that these algorithms are already present in the Note that these algorithms are already present in the
IANA "JSON Web Signature and Encryption Algorithms" registry <xref target ="IANA.JOSE.Algorithms"/>, IANA "JSON Web Signature and Encryption Algorithms" registry <xref target ="IANA.JOSE.Algorithms" format="default" sectionFormat="of" derivedContent="IANA .JOSE.Algorithms"/>,
and so these registrations are only for the and so these registrations are only for the
IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms"/>. IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms" forma t="default" sectionFormat="of" derivedContent="IANA.COSE.Algorithms"/>.
</t> </t>
</section> </section>
<section anchor="secp256k1" numbered="true" toc="include" removeInRFC="false
<section title="Using secp256k1 with JOSE and COSE" anchor="secp256k1"> " pn="section-3">
<t> <name slugifiedName="name-using-secp256k1-with-jose-a">Using secp256k1 wit
h JOSE and COSE</name>
<t pn="section-3-1">
This section defines algorithm encodings and representations enabling the This section defines algorithm encodings and representations enabling the
Standards for Efficient Cryptography Group (SECG) elliptic curve Standards for Efficient Cryptography Group (SECG) elliptic curve
secp256k1 <xref target="SEC2"/> to be used for secp256k1 <xref target="SEC2" format="default" sectionFormat="of" derived
JOSE <xref target="RFC7515"/> and Content="SEC2"/> to be used for
COSE <xref target="RFC8152"/> messages. JOSE <xref target="RFC7515" format="default" sectionFormat="of" derivedCo
ntent="RFC7515"/> and
COSE <xref target="RFC8152" format="default" sectionFormat="of" derivedCo
ntent="RFC8152"/> messages.
</t> </t>
<section anchor="secp256k1_curve" numbered="true" toc="include" removeInRF
<section title="JOSE and COSE secp256k1 Curve Key Representations" anchor= C="false" pn="section-3.1">
"secp256k1_curve"> <name slugifiedName="name-jose-and-cose-secp256k1-cur">JOSE and COSE sec
<t> p256k1 Curve Key Representations</name>
The Standards for Efficient Cryptography Group (SECG) elliptic curve <t pn="section-3.1-1">
secp256k1 <xref target="SEC2"/> is represented in The SECG elliptic curve
a JSON Web Key (JWK) <xref target="RFC7517"/> using these values: secp256k1 <xref target="SEC2" format="default" sectionFormat="of" deriv
</t> edContent="SEC2"/> is represented in
<t> a JSON Web Key (JWK) <xref target="RFC7517" format="default" sectionFor
<?rfc subcompact="yes"?> mat="of" derivedContent="RFC7517"/> using these values:
<list style="symbols"> </t>
<t><spanx style="verb">kty</spanx>: <spanx style="verb">EC</spanx></t <ul spacing="compact" bare="false" empty="false" pn="section-3.1-2">
> <li pn="section-3.1-2.1">
<t><spanx style="verb">crv</spanx>: <spanx style="verb">secp256k1</sp <tt>kty</tt>: <tt>EC</tt></li>
anx></t> <li pn="section-3.1-2.2">
</list> <tt>crv</tt>: <tt>secp256k1</tt></li>
<?rfc subcompact="no"?> </ul>
</t> <t pn="section-3.1-3">
<t> plus the values needed to represent the curve point, as defined in
plus the values needed to represent the curve point, <xref target="RFC7518" section="6.2.1" sectionFormat="of" format="defau
as defined in Section 6.2.1 of <xref target="RFC7518"/>. lt" derivedLink="https://rfc-editor.org/rfc/rfc7518#section-6.2.1" derivedConten
As a compressed point encoding representation is not defined for JWK el t="RFC7518"/>. As a
liptic curve points, compressed point encoding representation is not defined for JWK
the uncompressed point encoding defined there MUST be used. elliptic curve points, the uncompressed point encoding defined there
The <spanx style="verb">x</spanx> and <spanx style="verb">y</spanx> val <bcp14>MUST</bcp14> be used. The <tt>x</tt> and <tt>y</tt> values
ues represented <bcp14>MUST</bcp14> both be exactly 256 bits, with any
represented MUST both be exactly 256 bits, with any leading zeros prese leading zeros preserved. Other optional values such as <tt>alg</tt>
rved. <bcp14>MAY</bcp14> also be present.
Other optional values such as <spanx style="verb">alg</spanx> MAY also </t>
be present. <t pn="section-3.1-4">
</t> It is represented in a COSE_Key <xref target="RFC8152" format="default"
<t> sectionFormat="of" derivedContent="RFC8152"/> using these values:
It is represented in a COSE_Key <xref target ="RFC8152"/> using these v </t>
alues: <ul spacing="compact" bare="false" empty="false" pn="section-3.1-5">
</t> <li pn="section-3.1-5.1">
<t> <tt>kty</tt> (1): <tt>EC2</tt> (2)</li>
<?rfc subcompact="yes"?> <li pn="section-3.1-5.2">
<list style="symbols"> <tt>crv</tt> (-1): <tt>secp256k1</tt> (8)</li>
<t><spanx style="verb">kty</spanx> (1): <spanx style="verb">EC2</span </ul>
x> (2)</t> <t pn="section-3.1-6">
<t><spanx style="verb">crv</spanx> (-1): <spanx style="verb">secp256k plus the values needed to represent the curve point, as defined in
1</spanx> (TBD - requested assignment 8)</t> <xref target="RFC8152" section="13.1.1" sectionFormat="of" format="defa
</list> ult" derivedLink="https://rfc-editor.org/rfc/rfc8152#section-13.1.1" derivedCont
<?rfc subcompact="no"?> ent="RFC8152"/>.
</t> Either the uncompressed or compressed point encoding representations
<t> defined there can be used. The <tt>x</tt> value represented
plus the values needed to represent the curve point, <bcp14>MUST</bcp14> be exactly 256 bits, with any leading zeros
as defined in Section 13.1.1 of <xref target="RFC8152"/>. preserved. If the uncompressed representation is used, the
Either the uncompressed or compressed point encoding representations de <tt>y</tt> value represented <bcp14>MUST</bcp14> likewise be exactly
fined there can be used. 256 bits, with any leading zeros preserved; if the compressed
The <spanx style="verb">x</spanx> value representation is used, the <tt>y</tt> value is a boolean value, as
represented MUST be exactly 256 bits, with any leading zeros preserved. specified in <xref target="RFC8152" section="13.1.1" sectionFormat="of"
If the uncompressed representation is used, the <spanx style="verb">y</ format="default" derivedLink="https://rfc-editor.org/rfc/rfc8152#section-13.1.1
spanx> value " derivedContent="RFC8152"/>. Other optional values such as <tt>alg</tt>
represented MUST likewise be exactly 256 bits, with any leading zeros p (3) <bcp14>MAY</bcp14> also be present.
reserved; </t>
if the compressed representation is used, the <spanx style="verb">y</sp
anx> value
is a boolean value, as specified in Section 13.1.1 of <xref target="RFC
8152"/>.
Other optional values such as <spanx style="verb">alg</spanx> (3) MAY a
lso be present.
</t>
</section> </section>
<section anchor="secp256k1_ECDSA" numbered="true" toc="include" removeInRF
<section title="ECDSA Signature with secp256k1 Curve" anchor="secp256k1_EC C="false" pn="section-3.2">
DSA"> <name slugifiedName="name-ecdsa-signature-with-secp25">ECDSA Signature w
<t> ith secp256k1 Curve</name>
The ECDSA signature algorithm is defined in <xref target="DSS"/>. <t pn="section-3.2-1">
This specification defines the <spanx style="verb">ES256K</spanx> algor The ECDSA signature algorithm is defined in <xref target="DSS" format="
ithm identifier, default" sectionFormat="of" derivedContent="DSS"/>. This specification defines
which is used to specify the use of ECDSA with the secp256k1 curve the <tt>ES256K</tt>
and the SHA-256 <xref target="DSS"/> cryptographic hash function. algorithm identifier, which is used to specify the use of ECDSA with
Implementations need to check that the key type is <spanx style="verb"> the secp256k1 curve and the SHA-256 <xref target="DSS" format="default"
EC</spanx> for JOSE or sectionFormat="of" derivedContent="DSS"/> cryptographic hash function. Impleme
<spanx style="verb">EC2</spanx> (2) for COSE ntations
and that the curve of the key is secp256k1 need to check that the key type is <tt>EC</tt> for JOSE or
<tt>EC2</tt> (2) for COSE and that the curve of the key is secp256k1
when creating or verifying a signature. when creating or verifying a signature.
</t> </t>
<t> <t pn="section-3.2-2">
The ECDSA secp256k1 SHA-256 digital signature is generated as follows: The ECDSA secp256k1 SHA-256 digital signature is generated as follows:
<list style="numbers"> </t>
<t> <ol spacing="normal" type="1" start="1" pn="section-3.2-3">
<li pn="section-3.2-3.1" derivedCounter="1.">
Generate a digital signature of the JWS Signing Input Generate a digital signature of the JWS Signing Input
or the COSE Sig_structure or the COSE Sig_structure
using ECDSA secp256k1 SHA-256 with using ECDSA secp256k1 SHA-256 with
the desired private key. The output will be the pair the desired private key. The output will be the pair
(R, S), where R and S are 256-bit unsigned integers. (R, S), where R and S are 256-bit unsigned integers.
</t> </li>
<t> <li pn="section-3.2-3.2" derivedCounter="2.">
Turn R and S into octet sequences in big-endian order, Turn R and S into octet sequences in big-endian order,
with each array being be 32 octets long. with each array being 32 octets long.
The octet sequence representations MUST NOT be shortened The octet sequence representations <bcp14>MUST NOT</bcp14> be short
ened
to omit any leading zero octets contained in the values. to omit any leading zero octets contained in the values.
</t> </li>
<t> <li pn="section-3.2-3.3" derivedCounter="3.">
Concatenate the two octet sequences in the order R and then S. Concatenate the two octet sequences in the order R and then S.
(Note that many ECDSA implementations will directly produce (Note that many ECDSA implementations will directly produce
this concatenation as their output.) this concatenation as their output.)
</t> </li>
<t> <li pn="section-3.2-3.4" derivedCounter="4.">
The resulting 64-octet sequence is the JWS Signature or COSE signat ure value. The resulting 64-octet sequence is the JWS Signature or COSE signat ure value.
</t> </li>
</list> </ol>
</t> <t pn="section-3.2-4">
<t> Implementations <bcp14>SHOULD</bcp14> use a deterministic algorithm
Implementations SHOULD use a deterministic algorithm to generate to generate the ECDSA nonce, k, such as the algorithm defined in
the ECDSA nonce, k, such as <xref target="RFC6979"/>. <xref target="RFC6979" format="default" sectionFormat="of" derivedConte
However, in situations where devices are vulnerable to physical attacks nt="RFC6979"/>. However, in situations
, where devices are vulnerable to physical attacks, deterministic
deterministic ECDSA has been shown to be susceptible to fault injection ECDSA has been shown to be susceptible to fault injection attacks
attacks <xref target="KUDELSKI17" format="default" sectionFormat="of" derivedCo
<xref target="Kudelski17"/> <xref target="EuroSP18"/>. ntent="KUDELSKI17"/> <xref target="EURO-SP18" format="default" sectionFormat="of
Where this is a possibility, implementations SHOULD implement appropria " derivedContent="EURO-SP18"/>. Where this is a possibility,
te countermeasures. implementations <bcp14>SHOULD</bcp14> implement appropriate
Where there are specific certification requirements (such as FIPS appro countermeasures. Where there are specific certification
val), requirements (such as FIPS approval), implementors should check
implementors should check whether deterministic ECDSA is an approved no whether deterministic ECDSA is an approved nonce generation method.
nce generation method. </t>
</t> <t pn="section-3.2-5">
<t>
The ECDSA secp256k1 SHA-256 algorithm specified in this document uses t hese identifiers: The ECDSA secp256k1 SHA-256 algorithm specified in this document uses t hese identifiers:
</t> </t>
<texttable anchor="table-ec-algs" title="ECDSA Algorithm Values" suppress <table anchor="ec-algs" align="center" pn="table-2">
-title="false" align="center" style="full"> <name slugifiedName="name-ecdsa-algorithm-values">ECDSA Algorithm Valu
<ttcol align="left">JOSE Alg Name</ttcol> es</name>
<ttcol align="left">COSE Alg Value</ttcol> <thead>
<ttcol align="left">Description</ttcol> <tr>
<ttcol align="left">Recommended</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<th align="left" colspan="1" rowspan="1">Value</th>
<c>ES256K</c> <th align="left" colspan="1" rowspan="1">Description</th>
<c>TBD (requested assignment -47)</c> <th align="left" colspan="1" rowspan="1">Recommended</th>
<c>ECDSA using secp256k1 curve and SHA-256</c> </tr>
<c>No</c> </thead>
<tbody>
</texttable> <tr>
<t> <td align="left" colspan="1" rowspan="1">ES256K</td>
<td align="left" colspan="1" rowspan="1">-47</td>
<td align="left" colspan="1" rowspan="1">ECDSA using secp256k1 cur
ve and SHA-256</td>
<td align="left" colspan="1" rowspan="1">No</td>
</tr>
</tbody>
</table>
<t pn="section-3.2-7">
When using a JWK or COSE_Key for this algorithm, the following checks a re made: When using a JWK or COSE_Key for this algorithm, the following checks a re made:
</t> </t>
<t> <ul spacing="normal" bare="false" empty="false" pn="section-3.2-8">
<list style='symbols'> <li pn="section-3.2-8.1">
<t> The <tt>kty</tt> field <bcp14>MUST</bcp14> be present, and
The <spanx style="verb">kty</spanx> field MUST be present and it <bcp14>MUST</bcp14> be <tt>EC</tt> for JOSE
it MUST be <spanx style="verb">EC</spanx> for JOSE or <tt>EC2</tt> for COSE.
or <spanx style="verb">EC2</spanx> for COSE. </li>
</t> <li pn="section-3.2-8.2">
<t> The <tt>crv</tt> field <bcp14>MUST</bcp14> be present, and
The <spanx style="verb">crv</spanx> field MUST be present and it <bcp14>MUST</bcp14> represent the <tt>secp256k1</tt> elliptic cu
it MUST represent the <spanx style="verb">secp256k1</spanx> ellipti rve.
c curve. </li>
</t> <li pn="section-3.2-8.3">
<t> If the <tt>alg</tt> field is present,
If the <spanx style="verb">alg</spanx> field is present, it <bcp14>MUST</bcp14> represent the <tt>ES256K</tt> algorithm.
it MUST represent the <spanx style="verb">ES256K</spanx> algorithm. </li>
</t> <li pn="section-3.2-8.4">
<t> If the <tt>key_ops</tt> field is present,
If the <spanx style="verb">key_ops</spanx> field is present, it <bcp14>MUST</bcp14> include <tt>sign</tt> when creating an ECDSA
it MUST include <spanx style="verb">sign</spanx> when creating an E signature.
CDSA signature. </li>
</t> <li pn="section-3.2-8.5">
<t> If the <tt>key_ops</tt> field is present,
If the <spanx style="verb">key_ops</spanx> field is present, it <bcp14>MUST</bcp14> include <tt>verify</tt> when verifying an EC
it MUST include <spanx style="verb">verify</spanx> when verifying a DSA signature.
n ECDSA signature. </li>
</t> <li pn="section-3.2-8.6">
<t> If the JWK <tt>use</tt> field is present,
If the JWK <spanx style="use">use</spanx> field is present, its value <bcp14>MUST</bcp14> be <tt>sig</tt>.
its value MUST be <spanx style="verb">sig</spanx>. </li>
</t> </ul>
</list>
</t>
</section> </section>
<section anchor="other-uses-of-secp256k1" numbered="true" toc="include" re
<section anchor="other-uses-of-secp256k1" title="Other Uses of the secp256 moveInRFC="false" pn="section-3.3">
k1 Elliptic Curve"> <name slugifiedName="name-other-uses-of-the-secp256k1">Other Uses of the
<t> secp256k1 Elliptic Curve</name>
This specification defines how to use the secp256k1 curve for ECDSA sig <t pn="section-3.3-1">
natures This specification defines how to use the secp256k1 curve for ECDSA
for both JOSE and COSE implementations. signatures for both JOSE and COSE implementations. While in theory
While in theory, the curve could also be used for ECDH-ES key agreement 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
it is beyond the scope of this specification to state whether this is o advisable. Thus, whether or not to recommend its use with ECDH-ES is l
r is not advisable. eft
Thus, whether to recommend its use with ECDH-ES is left for experts to for experts to decide in future specifications.
decide in future specifications. </t>
</t> <t pn="section-3.3-2">
<t> When used for ECDSA, the secp256k1 curve <bcp14>MUST</bcp14> be used
When used for ECDSA, the secp256k1 curve MUST be used only with the only with the <tt>ES256K</tt> algorithm identifier and not any
<spanx style="verb">ES256K</spanx> algorithm identifier and not any oth others, including not with the COSE <tt>ES256</tt> identifier. Note
ers, that the <tt>ES256K</tt> algorithm identifier needed to be
including not with the COSE <spanx style="verb">ES256</spanx> identifie introduced for JOSE to sign with the secp256k1 curve because the
r. JOSE <tt>ES256</tt> algorithm is defined to be used only with the
Note that the <spanx style="verb">ES256K</spanx> algorithm identifier n P-256 curve. The COSE treatment of how to sign with secp256k1 is
eeded to be introduced intentionally parallel to that for JOSE, where the secp256k1 curve
for JOSE to sign with the secp256k1 curve because the JOSE <spanx style <bcp14>MUST</bcp14> be used with the <tt>ES256K</tt> algorithm
="verb">ES256</spanx> algorithm identifier.
is defined to be used only with the P-256 curve. </t>
The COSE treatment of how to sign with secp256k1 is intentionally paral
lel to that for JOSE,
where the secp256k1 curve MUST be used with the <spanx style="verb">ES2
56K</spanx> algorithm identifier.
</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="IANA" title="IANA Considerations"> "section-4">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="cose-algorithms-registrations" title="COSE Algorithms Reg <section anchor="cose-algorithms-registrations" numbered="true" toc="inclu
istrations"> de" removeInRFC="false" pn="section-4.1">
<t> <name slugifiedName="name-cose-algorithms-registratio">COSE Algorithms R
This section registers the following values in the egistrations</name>
IANA "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms"/>. <t pn="section-4.1-1">
</t> IANA has registered the following values in the
<t> "COSE Algorithms" registry <xref target="IANA.COSE.Algorithms" format="
<?rfc subcompact="yes"?> default" sectionFormat="of" derivedContent="IANA.COSE.Algorithms"/>.
<list style='symbols'> </t>
<t> <dl spacing="compact" newline="false" pn="section-4.1-2">
Name: RS256 <dt pn="section-4.1-2.1">Name:</dt>
</t> <dd pn="section-4.1-2.2">RS256
<t> </dd>
Value: TBD (temporary assignment -257 already in place) <dt pn="section-4.1-2.3">Value:</dt>
</t> <dd pn="section-4.1-2.4">-257
<t> </dd>
Description: RSASSA-PKCS1-v1_5 using SHA-256 <dt pn="section-4.1-2.5">Description:</dt>
</t> <dd pn="section-4.1-2.6">RSASSA-PKCS1-v1_5 using SHA-256
<t> </dd>
Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document <dt pn="section-4.1-2.7">Change Controller:
</t> </dt>
<t> <dd pn="section-4.1-2.8">IESG
Recommended: No </dd>
</t> <dt pn="section-4.1-2.9">Reference:</dt>
</list> <dd pn="section-4.1-2.10">
</t> <xref target="RSASSA-PKCS1-v1_5" format="default" sectionFormat="of"
<t> derivedContent="Section 2"/> of RFC 8812
<list style='symbols'> </dd>
<t> <dt pn="section-4.1-2.11">Recommended:</dt>
Name: RS384 <dd pn="section-4.1-2.12"> No
</t> </dd>
<t> </dl>
Value: TBD (temporary assignment -258 already in place) <dl spacing="compact" newline="false" pn="section-4.1-3">
</t> <dt pn="section-4.1-3.1">
<t> Name:</dt>
Description: RSASSA-PKCS1-v1_5 using SHA-384 <dd pn="section-4.1-3.2">RS384
</t> </dd>
<t> <dt pn="section-4.1-3.3">
Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document Value:</dt>
</t> <dd pn="section-4.1-3.4">-258
<t> </dd>
Recommended: No <dt pn="section-4.1-3.5">
</t> Description:</dt>
</list> <dd pn="section-4.1-3.6">RSASSA-PKCS1-v1_5 using SHA-384
</t> </dd>
<t> <dt pn="section-4.1-3.7">Change Controller:
<list style='symbols'> </dt>
<t> <dd pn="section-4.1-3.8">IESG
Name: RS512 </dd>
</t> <dt pn="section-4.1-3.9">
<t> Reference:</dt>
Value: TBD (temporary assignment -259 already in place) <dd pn="section-4.1-3.10">
</t> <xref target="RSASSA-PKCS1-v1_5" format="default" sectionFormat="of"
<t> derivedContent="Section 2"/> of RFC 8812
Description: RSASSA-PKCS1-v1_5 using SHA-512 </dd>
</t> <dt pn="section-4.1-3.11">
<t> Recommended:</dt>
Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document <dd pn="section-4.1-3.12">No
</t> </dd>
<t> </dl>
Recommended: No <dl spacing="compact" newline="false" pn="section-4.1-4">
</t> <dt pn="section-4.1-4.1">
</list> Name:</dt>
</t> <dd pn="section-4.1-4.2">RS512
<t> </dd>
<list style='symbols'> <dt pn="section-4.1-4.3">
<t> Value:</dt>
Name: RS1 <dd pn="section-4.1-4.4">-259
</t> </dd>
<t> <dt pn="section-4.1-4.5">
Value: TBD (temporary assignment -65535 already in place) Description:</dt>
</t> <dd pn="section-4.1-4.6">RSASSA-PKCS1-v1_5 using SHA-512
<t> </dd>
Description: RSASSA-PKCS1-v1_5 using SHA-1 <dt pn="section-4.1-4.7">Change Controller:
</t> </dt>
<t> <dd pn="section-4.1-4.8">IESG
Reference: <xref target="RSASSA-PKCS1-v1_5"/> of this document </dd>
</t> <dt pn="section-4.1-4.9">
<t> Reference:</dt>
Recommended: Deprecated <dd pn="section-4.1-4.10">
</t> <xref target="RSASSA-PKCS1-v1_5" format="default" sectionFormat="of"
</list> derivedContent="Section 2"/> of RFC 8812
</t> </dd>
<t> <dt pn="section-4.1-4.11">
<list style='symbols'> Recommended:</dt>
<t> <dd pn="section-4.1-4.12"> No
Name: ES256K </dd>
</t> </dl>
<t> <dl spacing="compact" newline="false" pn="section-4.1-5">
Value: TBD (requested assignment -47) <dt pn="section-4.1-5.1">
</t> Name:</dt>
<t> <dd pn="section-4.1-5.2">RS1
Description: ECDSA using secp256k1 curve and SHA-256 </dd>
</t> <dt pn="section-4.1-5.3">
<t> Value:</dt>
Reference: <xref target="secp256k1_ECDSA"/> of this document <dd pn="section-4.1-5.4">-65535
</t> </dd>
<t> <dt pn="section-4.1-5.5">
Recommended: No Description:</dt>
</t> <dd pn="section-4.1-5.6">RSASSA-PKCS1-v1_5 using SHA-1
</list> </dd>
</t> <dt pn="section-4.1-5.7">Change Controller:
<?rfc subcompact="no"?> </dt>
<dd pn="section-4.1-5.8">IESG
</dd>
<dt pn="section-4.1-5.9">
Reference:</dt>
<dd pn="section-4.1-5.10">
<xref target="RSASSA-PKCS1-v1_5" format="default" sectionFormat="of"
derivedContent="Section 2"/> of RFC 8812
</dd>
<dt pn="section-4.1-5.11">
Recommended:</dt>
<dd pn="section-4.1-5.12">Deprecated
</dd>
</dl>
<dl spacing="compact" newline="false" pn="section-4.1-6">
<dt pn="section-4.1-6.1">
Name:</dt>
<dd pn="section-4.1-6.2">ES256K
</dd>
<dt pn="section-4.1-6.3">
Value:</dt>
<dd pn="section-4.1-6.4">-47
</dd>
<dt pn="section-4.1-6.5">
Description:</dt>
<dd pn="section-4.1-6.6">ECDSA using secp256k1 curve and SHA-256
</dd>
<dt pn="section-4.1-6.7">Change Controller:
</dt>
<dd pn="section-4.1-6.8">IESG
</dd>
<dt pn="section-4.1-6.9">
Reference:</dt>
<dd pn="section-4.1-6.10">
<xref target="secp256k1_ECDSA" format="default" sectionFormat="of" d
erivedContent="Section 3.2"/> of RFC 8812
</dd>
<dt pn="section-4.1-6.11">
Recommended:</dt>
<dd pn="section-4.1-6.12">No
</dd>
</dl>
</section> </section>
<section anchor="cose-curve-registration" numbered="true" toc="include" re
<section anchor="cose-curve-registration" title="COSE Elliptic Curves Regi moveInRFC="false" pn="section-4.2">
strations"> <name slugifiedName="name-cose-elliptic-curves-regist">COSE Elliptic Cur
<t> ves Registrations</name>
This section registers the following value in the <t pn="section-4.2-1">
IANA "COSE Elliptic Curves" registry <xref target="IANA.COSE.Curves"/>. IANA has registered the following value in the
</t> "COSE Elliptic Curves" registry <xref target="IANA.COSE.Curves" format=
<t> "default" sectionFormat="of" derivedContent="IANA.COSE.Curves"/>.
<?rfc subcompact="yes"?> </t>
<list style='symbols'> <dl spacing="compact" newline="false" pn="section-4.2-2">
<t> <dt pn="section-4.2-2.1">
Name: secp256k1 Name:</dt>
</t> <dd pn="section-4.2-2.2">secp256k1
<t> </dd>
Value: TBD (requested assignment 8) <dt pn="section-4.2-2.3">
</t> Value:</dt>
<t> <dd pn="section-4.2-2.4">8
Key Type: EC2 </dd>
</t> <dt pn="section-4.2-2.5">
<t> Key Type:</dt>
Description: SECG secp256k1 curve <dd pn="section-4.2-2.6">EC2
</t> </dd>
<t> <dt pn="section-4.2-2.7">
Change Controller: IESG Description:</dt>
</t> <dd pn="section-4.2-2.8">SECG secp256k1 curve
<t> </dd>
Reference: <xref target="secp256k1_curve"/> of [[ this specificatio <dt pn="section-4.2-2.9">
n ]] Change Controller:</dt>
</t> <dd pn="section-4.2-2.10">IESG
<t> </dd>
Recommended: No <dt pn="section-4.2-2.11">
</t> Reference:</dt>
</list> <dd pn="section-4.2-2.12">
</t> <xref target="secp256k1_curve" format="default" sectionFormat="of" d
<?rfc subcompact="no"?> erivedContent="Section 3.1"/> of RFC 8812
</dd>
<dt pn="section-4.2-2.13">
Recommended:</dt>
<dd pn="section-4.2-2.14">No
</dd>
</dl>
</section> </section>
<section anchor="jose-algorithm-registration" numbered="true" toc="include
<section anchor="jose-algorithm-registration" title="JOSE Algorithms Regis " removeInRFC="false" pn="section-4.3">
trations"> <name slugifiedName="name-jose-algorithms-registratio">JOSE Algorithms R
<t> egistrations</name>
This section registers the following value in the <t pn="section-4.3-1">
IANA "JSON Web Signature and Encryption Algorithms" registry <xref targ IANA has registered the following value in the
et="IANA.JOSE.Algorithms"/>. "JSON Web Signature and Encryption Algorithms" registry <xref target="I
</t> ANA.JOSE.Algorithms" format="default" sectionFormat="of" derivedContent="IANA.JO
<t> SE.Algorithms"/>.
<?rfc subcompact="yes"?> </t>
<list style='symbols'> <dl spacing="compact" newline="false" pn="section-4.3-2">
<t> <dt pn="section-4.3-2.1">
Algorithm Name: ES256K Algorithm Name:</dt>
</t> <dd pn="section-4.3-2.2"> ES256K
<t> </dd>
Algorithm Description: ECDSA using secp256k1 curve and SHA-256 <dt pn="section-4.3-2.3">
</t> Algorithm Description:</dt>
<t> <dd pn="section-4.3-2.4"> ECDSA using secp256k1 curve and SHA-256
Algorithm Usage Locations: alg </dd>
</t> <dt pn="section-4.3-2.5">
<t> Algorithm Usage Location(s):</dt>
JOSE Implementation Requirements: Optional <dd pn="section-4.3-2.6"> alg
</t> </dd>
<t> <dt pn="section-4.3-2.7">
Change Controller: IESG JOSE Implementation Requirements:</dt>
</t> <dd pn="section-4.3-2.8"> Optional
<t> </dd>
Reference: <xref target="secp256k1_ECDSA"/> of [[ this specificatio <dt pn="section-4.3-2.9">
n ]] Change Controller:</dt>
</t> <dd pn="section-4.3-2.10"> IESG
<t> </dd>
Algorithm Analysis Document(s): <xref target="SEC2"/> <dt pn="section-4.3-2.11">
</t> Reference:</dt>
</list> <dd pn="section-4.3-2.12">
</t> <xref target="secp256k1_ECDSA" format="default" sectionFormat="of" d
<?rfc subcompact="no"?> erivedContent="Section 3.2"/> of RFC 8812
</dd>
<dt pn="section-4.3-2.13">
Algorithm Analysis Document(s):</dt>
<dd pn="section-4.3-2.14">
<xref target="SEC2" format="default" sectionFormat="of" derivedConte
nt="SEC2"/>
</dd>
</dl>
</section> </section>
<section anchor="jose-curve-registration" numbered="true" toc="include" re
<section anchor="jose-curve-registration" title="JSON Web Key Elliptic Cur moveInRFC="false" pn="section-4.4">
ves Registrations"> <name slugifiedName="name-json-web-key-elliptic-curve">JSON Web Key Elli
<t> ptic Curves Registrations</name>
This section registers the following value in the <t pn="section-4.4-1">
IANA "JSON Web Key Elliptic Curve" registry <xref target="IANA.JOSE.Cur IANA has registered the following value in the
ves"/>. "JSON Web Key Elliptic Curve" registry <xref target="IANA.JOSE.Curves"
</t> format="default" sectionFormat="of" derivedContent="IANA.JOSE.Curves"/>.
<t> </t>
<?rfc subcompact="yes"?> <dl spacing="compact" newline="false" pn="section-4.4-2">
<list style='symbols'> <dt pn="section-4.4-2.1">
<t> Curve Name:</dt>
Curve Name: secp256k1 <dd pn="section-4.4-2.2"> secp256k1
</t> </dd>
<t> <dt pn="section-4.4-2.3">
Curve Description: SECG secp256k1 curve Curve Description:</dt>
</t> <dd pn="section-4.4-2.4"> SECG secp256k1 curve
<t> </dd>
JOSE Implementation Requirements: Optional <dt pn="section-4.4-2.5">
</t> JOSE Implementation Requirements:</dt>
<t> <dd pn="section-4.4-2.6"> Optional
Change Controller: IESG </dd>
</t> <dt pn="section-4.4-2.7">
<t> Change Controller:</dt>
Specification Document(s): <xref target="secp256k1_curve"/> of [[ t <dd pn="section-4.4-2.8"> IESG
his specification ]] </dd>
</t> <dt pn="section-4.4-2.9">
</list> Specification Document(s):</dt>
</t> <dd pn="section-4.4-2.10">
<?rfc subcompact="no"?> <xref target="secp256k1_curve" format="default" sectionFormat="of" d
erivedContent="Section 3.1"/> of RFC 8812
</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
<section anchor="Security" title="Security Considerations"> pn="section-5">
<name slugifiedName="name-security-considerations">Security Considerations
<section title="RSA Key Size Security Considerations" anchor="KeySize-cons </name>
iderations"> <section anchor="KeySize-considerations" numbered="true" toc="include" rem
<t> oveInRFC="false" pn="section-5.1">
<name slugifiedName="name-rsa-key-size-security-consi">RSA Key Size Secu
rity Considerations</name>
<t pn="section-5.1-1">
The security considerations on key sizes for RSA algorithms The security considerations on key sizes for RSA algorithms
from Section 6.1 of <xref target="RFC8230"/> also apply to the RSA algo rithms from <xref target="RFC8230" section="6.1" sectionFormat="of" format="de fault" derivedLink="https://rfc-editor.org/rfc/rfc8230#section-6.1" derivedConte nt="RFC8230"/> also apply to the RSA algorithms
in this specification. in this specification.
</t> </t>
</section> </section>
<section anchor="RSASSA-PKCS1-v1_5_SHA-2_considerations" numbered="true" t
<section title="RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations" anch oc="include" removeInRFC="false" pn="section-5.2">
or="RSASSA-PKCS1-v1_5_SHA-2_considerations"> <name slugifiedName="name-rsassa-pkcs1-v1_5-with-sha-">RSASSA-PKCS1-v1_5
<t> with SHA-2 Security Considerations</name>
<t pn="section-5.2-1">
The security considerations on the use of RSASSA-PKCS1-v1_5 with SHA-2 hash functions The security considerations on the use of RSASSA-PKCS1-v1_5 with SHA-2 hash functions
(SHA-256, SHA-384, and SHA-512) (SHA-256, SHA-384, and SHA-512)
from Section 8.3 of <xref target="RFC7518"/> also apply to their use from <xref target="RFC7518" section="8.3" sectionFormat="of" format="de fault" derivedLink="https://rfc-editor.org/rfc/rfc7518#section-8.3" derivedConte nt="RFC7518"/> also apply to their use
in this specification. in this specification.
For that reason, these algorithms are registered as being "Not Recommen ded". For that reason, these algorithms are registered as being "Not Recommen ded".
Likewise, the exponent restrictions described in Likewise, the exponent restrictions described in
Section 8.3 of <xref target="RFC7518"/> also apply. <xref target="RFC7518" section="8.3" sectionFormat="of" format="defaul
</t> t" derivedLink="https://rfc-editor.org/rfc/rfc7518#section-8.3" derivedContent="
RFC7518"/> also apply.
</t>
</section> </section>
<section anchor="RSASSA-PKCS1-v1_5_SHA-1_considerations" numbered="true" t
<section title="RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations" anch oc="include" removeInRFC="false" pn="section-5.3">
or="RSASSA-PKCS1-v1_5_SHA-1_considerations"> <name slugifiedName="name-rsassa-pkcs1-v1_5-with-sha-1">RSASSA-PKCS1-v1_
<t> 5 with SHA-1 Security Considerations</name>
<t pn="section-5.3-1">
The security considerations on the use of the SHA-1 hash function The security considerations on the use of the SHA-1 hash function
from <xref target="RFC6194"/> apply in this specification. from <xref target="RFC6194" format="default" sectionFormat="of" derived Content="RFC6194"/> apply in this specification.
For that reason, the "RS1" algorithm is registered as "Deprecated". For that reason, the "RS1" algorithm is registered as "Deprecated".
Likewise, the exponent restrictions described in Likewise, the exponent restrictions described in
Section 8.3 of <xref target="RFC7518"/> also apply. <xref target="RFC7518" section="8.3" sectionFormat="of" format="defaul
</t> t" derivedLink="https://rfc-editor.org/rfc/rfc7518#section-8.3" derivedContent="
<t> RFC7518"/> also apply.
A COSE algorithm identifier for this algorithm is nonetheless being reg </t>
istered <t pn="section-5.3-2">
because deployed TPMs continue to use it, and therefore WebAuthn implem A COSE algorithm identifier for this algorithm is nonetheless being
entations registered because deployed Trusted Platform Modules (TPMs) continue
need a COSE algorithm identifier for "RS1" when TPM attestations using to use it; therefore, WebAuthn implementations need a COSE algorithm
this algorithm are being represented. identifier for "RS1" when TPM attestations using this algorithm are
New COSE applications and protocols MUST NOT use this algorithm. being represented. New COSE applications and protocols <bcp14>MUST NOT
</t> </bcp14> use this algorithm.
</t>
</section> </section>
<section anchor="secp256k1_considerations" numbered="true" toc="include" r
<section title="secp256k1 Security Considerations" anchor="secp256k1_consi emoveInRFC="false" pn="section-5.4">
derations"> <name slugifiedName="name-secp256k1-security-consider">secp256k1 Securit
<t> y Considerations</name>
Care should be taken that a secp256k1 key is not mistaken for a P-256 < <t pn="section-5.4-1">
xref target="RFC7518"/> key, Care should be taken that a secp256k1 key is not mistaken for a P-256 <
xref target="RFC7518" format="default" sectionFormat="of" derivedContent="RFC751
8"/> key,
given that their representations are the same given that their representations are the same
except for the <spanx style="verb">crv</spanx> value. except for the <tt>crv</tt> value.
As described in Section 8.1.1 of <xref target="RFC8152"/>, As described in <xref target="RFC8152" section="8.1.1" sectionFormat="
of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8152#section-8.1
.1" derivedContent="RFC8152"/>,
we currently do not have any way to deal with this we currently do not have any way to deal with this
attack except to restrict the set of curves that can be used. attack except to restrict the set of curves that can be used.
</t> </t>
<t> <t pn="section-5.4-2">
The procedures and security considerations described in the The procedures and security considerations described in the
<xref target="SEC1"/>, <xref target="SEC2"/>, and <xref target="DSS"/> <xref target="SEC1" format="default" sectionFormat="of" derivedContent= "SEC1"/>, <xref target="SEC2" format="default" sectionFormat="of" derivedContent ="SEC2"/>, and <xref target="DSS" format="default" sectionFormat="of" derivedCon tent="DSS"/>
specifications apply to implementations of this specification. specifications apply to implementations of this specification.
</t> </t>
<t> <t pn="section-5.4-3">
Timing side-channel attacks are possible if the implementation of scala r multiplication Timing side-channel attacks are possible if the implementation of scala r multiplication
over the curve does not execute in constant time. over the curve does not execute in constant time.
</t> </t>
<t> <t pn="section-5.4-4">
There are theoretical weaknesses with this curve that could result in f uture attacks. There are theoretical weaknesses with this curve that could result in f uture attacks.
While these potential weaknesses are not unique to this curve, While these potential weaknesses are not unique to this curve,
they are the reason that this curve is registered as "Recommended: No". they are the reason that this curve is registered as "Recommended: No".
</t> </t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-6">
<name slugifiedName="name-references">References</name>
<?rfc include="reference.RFC.2119.xml"?> <references pn="section-6.1">
<?rfc include="reference.RFC.6194.xml"?> <name slugifiedName="name-normative-references">Normative References</na
<?rfc include="reference.RFC.7515.xml"?> me>
<?rfc include="reference.RFC.7517.xml"?> <reference anchor="DSS" quoteTitle="true" target="https://doi.org/10.602
<?rfc include="reference.RFC.7518.xml"?> 8/NIST.FIPS.186-4" derivedAnchor="DSS">
<?rfc include="reference.RFC.8017.xml"?> <front>
<?rfc include="reference.RFC.8152.xml"?> <title>Digital Signature Standard (DSS)</title>
<?rfc include="reference.RFC.8174.xml"?> <author>
<?rfc include="reference.RFC.8230.xml"?> <organization showOnFrontPage="true">National Institute of Standar
ds and Technology (NIST)</organization>
<reference anchor="DSS" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST </author>
.FIPS.186-4.pdf"> <date month="July" year="2013"/>
<front> </front>
<title>Digital Signature Standard (DSS)</title> <seriesInfo name="FIPS PUB" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
<author> </reference>
<organization>National Institute of Standards and <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
Technology (NIST)</organization> 119" quoteTitle="true" derivedAnchor="RFC2119">
</author> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
<date month="July" year="2013" /> le>
</front> <author initials="S." surname="Bradner" fullname="S. Bradner">
<seriesInfo name="FIPS" value="PUB 186-4" /> <organization showOnFrontPage="true"/>
</reference> </author>
<date year="1997" month="March"/>
<reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf"> <abstract>
<front> <t>In many standards track documents several words are used to sig
<title>SEC 1: Elliptic Curve Cryptography</title> nify the requirements in the specification. These words are often capitalized.
<author> This document defines these words as they should be interpreted in IETF document
<organization>Standards for Efficient Cryptography Group</organizati s. This document specifies an Internet Best Current Practices for the Internet
on> Community, and requests discussion and suggestions for improvements.</t>
</author> </abstract>
<date day="21" month="May" year="2009" /> </front>
</front> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="Version" value="2.0" /> <seriesInfo name="RFC" value="2119"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="SEC2" target="http://www.secg.org/sec2-v2.pdf"> <reference anchor="RFC6194" target="https://www.rfc-editor.org/info/rfc6
<front> 194" quoteTitle="true" derivedAnchor="RFC6194">
<title>SEC 2: Recommended Elliptic Curve Domain Parameters</title> <front>
<author> <title>Security Considerations for the SHA-0 and SHA-1 Message-Diges
<organization>Standards for Efficient Cryptography Group</organizati t Algorithms</title>
on> <author initials="T." surname="Polk" fullname="T. Polk">
</author> <organization showOnFrontPage="true"/>
<date day="27" month="January" year="2010" /> </author>
</front> <author initials="L." surname="Chen" fullname="L. Chen">
<seriesInfo name="Version" value="2.0" /> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="S." surname="Turner" fullname="S. Turner">
</references> <organization showOnFrontPage="true"/>
</author>
<references title="Informative References"> <author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
<?rfc include="reference.RFC.6979.xml"?> </author>
<date year="2011" month="March"/>
<reference anchor="WebAuthn" target="https://www.w3.org/TR/2019/REC-webaut <abstract>
hn-1-20190304/"> <t>This document includes security considerations for the SHA-0 an
<front> d SHA-1 message digest algorithm. This document is not an Internet Standards T
<title>Web Authentication: An API for accessing Public Key Credentials rack specification; it is published for informational purposes.</t>
- Level 1</title> </abstract>
<author initials="D." surname="Balfanz" fullname="Dirk Balfanz"> </front>
<organization>Google</organization> <seriesInfo name="RFC" value="6194"/>
<address> <seriesInfo name="DOI" value="10.17487/RFC6194"/>
<email>balfanz@google.com</email> </reference>
</address> <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7
</author> 515" quoteTitle="true" derivedAnchor="RFC7515">
<front>
<author initials="A." surname="Czeskis" fullname="Alexei Czeskis"> <title>JSON Web Signature (JWS)</title>
<organization>Google</organization> <author initials="M." surname="Jones" fullname="M. Jones">
<address> <organization showOnFrontPage="true"/>
<email>aczeskis@google.com</email> </author>
</address> <author initials="J." surname="Bradley" fullname="J. Bradley">
</author> <organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges"> <author initials="N." surname="Sakimura" fullname="N. Sakimura">
<organization>Google</organization> <organization showOnFrontPage="true"/>
<address> </author>
<email>Jeff.Hodges@paypal.com</email> <date year="2015" month="May"/>
</address> <abstract>
</author> <t>JSON Web Signature (JWS) represents content secured with digita
l signatures or Message Authentication Codes (MACs) using JSON-based data struct
<author initials="J.C." surname="Jones" fullname="J.C. Jones"> ures. Cryptographic algorithms and identifiers for use with this specification
<organization>Mozilla</organization> are described in the separate JSON Web Algorithms (JWA) specification and an IAN
<address> A registry defined by that specification. Related encryption capabilities are d
<email>jc@mozilla.com</email> escribed in the separate JSON Web Encryption (JWE) specification.</t>
</address> </abstract>
</author> </front>
<seriesInfo name="RFC" value="7515"/>
<author initials="M.B." surname="Jones" fullname="Michael B. Jones"> <seriesInfo name="DOI" value="10.17487/RFC7515"/>
<organization>Microsoft</organization> </reference>
<address> <reference anchor="RFC7517" target="https://www.rfc-editor.org/info/rfc7
<email>mbj@microsoft.com</email> 517" quoteTitle="true" derivedAnchor="RFC7517">
<uri>http://self-issued.info/</uri> <front>
</address> <title>JSON Web Key (JWK)</title>
</author> <author initials="M." surname="Jones" fullname="M. Jones">
<organization showOnFrontPage="true"/>
<author initials="A." surname="Kumar" fullname="Akshay Kumar"> </author>
<organization>Microsoft</organization> <date year="2015" month="May"/>
<address> <abstract>
<email>akshayku@microsoft.com</email> <t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) dat
</address> a structure that represents a cryptographic key. This specification also define
</author> s a JWK Set JSON data structure that represents a set of JWKs. Cryptographic al
gorithms and identifiers for use with this specification are described in the se
<author initials="A." surname="Liao" fullname="Angelo Liao"> parate JSON Web Algorithms (JWA) specification and IANA registries established b
<organization>Microsoft</organization> y that specification.</t>
<address> </abstract>
<email>huliao@microsoft.com</email> </front>
</address> <seriesInfo name="RFC" value="7517"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC7517"/>
</reference>
<author initials="R." surname="Lindemann" fullname="Rolf Lindemann"> <reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7
<organization>Nok Nok Labs</organization> 518" quoteTitle="true" derivedAnchor="RFC7518">
<address> <front>
<email>rolf@noknok.com</email> <title>JSON Web Algorithms (JWA)</title>
</address> <author initials="M." surname="Jones" fullname="M. Jones">
</author> <organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Lundberg" fullname="Emil Lundberg"> <date year="2015" month="May"/>
<organization>Yubico</organization> <abstract>
<address> <t>This specification registers cryptographic algorithms and ident
<email>emil@yubico.com</email> ifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE),
</address> and JSON Web Key (JWK) specifications. It defines several IANA registries for t
</author> hese identifiers.</t>
</abstract>
<date month="March" day="4" year="2019" /> </front>
</front> <seriesInfo name="RFC" value="7518"/>
<seriesInfo name="World Wide Web Consortium (W3C)" value="Recommendation <seriesInfo name="DOI" value="10.17487/RFC7518"/>
" /> </reference>
</reference> <reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8
017" quoteTitle="true" derivedAnchor="RFC8017">
<reference anchor="CTAP" target="https://fidoalliance.org/specs/fido-v2.0- <front>
ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html"> <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<front> <author initials="K." surname="Moriarty" fullname="K. Moriarty" role
<title>Client to Authenticator Protocol (CTAP)</title> ="editor">
<author initials="C." surname="Brand" fullname="Christiaan Brand"> <organization showOnFrontPage="true"/>
<organization>Google</organization> </author>
<address> <author initials="B." surname="Kaliski" fullname="B. Kaliski">
<email>cbrand@google.com</email> <organization showOnFrontPage="true"/>
</address> </author>
</author> <author initials="J." surname="Jonsson" fullname="J. Jonsson">
<organization showOnFrontPage="true"/>
<author initials="A." surname="Czeskis" fullname="Alexei Czeskis"> </author>
<organization>Google</organization> <author initials="A." surname="Rusch" fullname="A. Rusch">
<address> <organization showOnFrontPage="true"/>
<email>aczeskis@google.com</email> </author>
</address> <date year="2016" month="November"/>
</author> <abstract>
<t>This document provides recommendations for the implementation o
<author initials="J." surname="Ehrensvärd" fullname="Jakob Ehrensvärd" f public-key cryptography based on the RSA algorithm, covering cryptographic pri
> mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
<organization>Yubico</organization> or representing keys and for identifying the schemes.</t>
<address> <t>This document represents a republication of PKCS #1 v2.2 from R
<email>jakob@yubico.com</email> SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
</address> this RFC, change control is transferred to the IETF.</t>
</author> <t>This document also obsoletes RFC 3447.</t>
</abstract>
<author initials="M.B." surname="Jones" fullname="Michael B. Jones"> </front>
<organization>Microsoft</organization> <seriesInfo name="RFC" value="8017"/>
<address> <seriesInfo name="DOI" value="10.17487/RFC8017"/>
<email>mbj@microsoft.com</email> </reference>
<uri>http://self-issued.info/</uri> <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8
</address> 152" quoteTitle="true" derivedAnchor="RFC8152">
</author> <front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials="A." surname="Kumar" fullname="Akshay Kumar"> <author initials="J." surname="Schaad" fullname="J. Schaad">
<organization>Microsoft</organization> <organization showOnFrontPage="true"/>
<address> </author>
<email>akshayku@microsoft.com</email> <date year="2017" month="July"/>
</address> <abstract>
</author> <t>Concise Binary Object Representation (CBOR) is a data format de
signed for small code size and small message size. There is a need for the abil
<author initials="R." surname="Lindemann" fullname="Rolf Lindemann"> ity to have basic security services defined for this data format. This document
<organization>Nok Nok Labs</organization> defines the CBOR Object Signing and Encryption (COSE) protocol. This specificat
<address> ion describes how to create and process signatures, message authentication codes
<email>rolf@noknok.com</email> , and encryption using CBOR for serialization. This specification additionally
</address> describes how to represent cryptographic keys using CBOR.</t>
</author> </abstract>
</front>
<author initials="A." surname="Powers" fullname="Adam Powers"> <seriesInfo name="RFC" value="8152"/>
<organization>FIDO Alliance</organization> <seriesInfo name="DOI" value="10.17487/RFC8152"/>
<address> </reference>
<email>adam@fidoalliance.org</email> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
</address> 174" quoteTitle="true" derivedAnchor="RFC8174">
</author> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
<author initials="J." surname="Verrept" fullname="Johan Verrept"> tle>
<organization>OneSpan</organization> <author initials="B." surname="Leiba" fullname="B. Leiba">
<address> <organization showOnFrontPage="true"/>
<email>johan.verrept@onespan.com</email> </author>
</address> <date year="2017" month="May"/>
</author> <abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
<date month="January" day="30" year="2019" /> l specifications. This document aims to reduce the ambiguity by clarifying tha
</front> t only UPPERCASE usage of the key words have the defined special meanings.</t>
<seriesInfo name="FIDO Alliance" value="Proposed Standard" /> </abstract>
</reference> </front>
<seriesInfo name="BCP" value="14"/>
<reference anchor="IANA.COSE.Algorithms" target="https://www.iana.org/assi <seriesInfo name="RFC" value="8174"/>
gnments/cose/cose.xhtml#algorithms"> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
<front> </reference>
<title>COSE Algorithms</title> <reference anchor="RFC8230" target="https://www.rfc-editor.org/info/rfc8
<author> 230" quoteTitle="true" derivedAnchor="RFC8230">
<organization>IANA</organization> <front>
</author> <title>Using RSA Algorithms with CBOR Object Signing and Encryption
<date/> (COSE) Messages</title>
</front> <author initials="M." surname="Jones" fullname="M. Jones">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="IANA.COSE.Curves" target="https://www.iana.org/assignme <date year="2017" month="September"/>
nts/cose/cose.xhtml#elliptic-curves"> <abstract>
<front> <t>The CBOR Object Signing and Encryption (COSE) specification def
<title>COSE Elliptic Curves</title> ines cryptographic message encodings using Concise Binary Object Representation
<author> (CBOR). This specification defines algorithm encodings and representations enab
<organization>IANA</organization> ling RSA algorithms to be used for COSE messages. Encodings are specified for t
</author> he use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryp
<date/> tion Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and
</front> RSA keys.</t>
</reference> </abstract>
</front>
<reference anchor="IANA.JOSE.Algorithms" target="https://www.iana.org/assi <seriesInfo name="RFC" value="8230"/>
gnments/jose/jose.xhtml#web-signature-encryption-algorithms"> <seriesInfo name="DOI" value="10.17487/RFC8230"/>
<front> </reference>
<title>JSON Web Signature and Encryption Algorithms</title> <reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf" quote
<author> Title="true" derivedAnchor="SEC1">
<organization>IANA</organization> <front>
</author> <title>SEC 1: Elliptic Curve Cryptography</title>
<date/> <author>
</front> <organization showOnFrontPage="true">Standards for Efficient Crypt
</reference> ography Group</organization>
</author>
<reference anchor="IANA.JOSE.Curves" target="https://www.iana.org/assignme <date month="May" year="2009"/>
nts/jose/jose.xhtml#web-key-elliptic-curve"> </front>
<front> <seriesInfo name="Version" value="2.0"/>
<title>JSON Web Key Elliptic Curve</title> </reference>
<author> <reference anchor="SEC2" target="https://www.secg.org/sec2-v2.pdf" quote
<organization>IANA</organization> Title="true" derivedAnchor="SEC2">
</author> <front>
<date/> <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
</front> <author>
</reference> <organization showOnFrontPage="true">Standards for Efficient Crypt
ography Group</organization>
<reference anchor="Kudelski17" </author>
target="https://research.kudelskisecurity.com/2017/10/04/defeati <date month="January" year="2010"/>
ng-eddsa-with-faults/"> </front>
<front> <seriesInfo name="Version" value="2.0"/>
<title>How to defeat Ed25519 and EdDSA using faults</title> </reference>
<author fullname="Yolan Romailler" surname="Romailler" initials="Y."> </references>
<organization>Kudelski Security</organization> <references pn="section-6.2">
</author> <name slugifiedName="name-informative-references">Informative References
</name>
<date day="4" month="October" year="2017"/> <reference anchor="CTAP" target="https://fidoalliance.org/specs/fido-v2.
</front> 0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html" quote
</reference> Title="true" derivedAnchor="CTAP">
<front>
<reference anchor="EuroSP18" <title>Client to Authenticator Protocol (CTAP)</title>
target="https://eprint.iacr.org/2017/1014.pdf"> <author initials="C." surname="Brand" fullname="Christiaan Brand">
<front> <organization showOnFrontPage="true">Google</organization>
<title>Attacking Deterministic Signature Schemes using Fault Attacks</t <address>
itle> <email>cbrand@google.com</email>
<author fullname="Damian Poddebniak" surname="Poddebniak" initials="D." </address>
> </author>
<organization>Münster University of Applied Sciences</organization> <author initials="A." surname="Czeskis" fullname="Alexei Czeskis">
</author> <organization showOnFrontPage="true">Google</organization>
<author fullname="Juraj Somorovsky" surname="Somorovsky" initials="J."> <address>
<organization>Ruhr University Bochum</organization> <email>aczeskis@google.com</email>
</author> </address>
<author fullname="Sebastian Schinzel" surname="Schinzel" initials="S."> </author>
<organization>Münster University of Applied Sciences</organization> <author initials="J." surname="Ehrensvärd" fullname="Jakob Ehrensvär
</author> d">
<author fullname="Manfred Lochter" surname="Lochter" initials="M."> <organization showOnFrontPage="true">Yubico</organization>
<organization>Federal Office for Information Security</organization> <address>
</author> <email>jakob@yubico.com</email>
<author fullname="Paul Rösler" surname="Rösler" initials="P."> </address>
<organization>Ruhr University Bochum</organization> </author>
</author> <author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization showOnFrontPage="true">Microsoft</organization>
<date day="1" month="April" year="2018"/> <address>
</front> <email>mbj@microsoft.com</email>
<seriesInfo name="IEEE European Symposium on Security and Privacy (EuroS& <uri>http://self-issued.info/</uri>
amp;P)" value="2018"/> </address>
</reference> </author>
<author initials="A." surname="Kumar" fullname="Akshay Kumar">
<organization showOnFrontPage="true">Microsoft</organization>
<address>
<email>akshayku@microsoft.com</email>
</address>
</author>
<author initials="R." surname="Lindemann" fullname="Rolf Lindemann">
<organization showOnFrontPage="true">Nok Nok Labs</organization>
<address>
<email>rolf@noknok.com</email>
</address>
</author>
<author initials="A." surname="Powers" fullname="Adam Powers">
<organization showOnFrontPage="true">FIDO Alliance</organization>
<address>
<email>adam@fidoalliance.org</email>
</address>
</author>
<author initials="J." surname="Verrept" fullname="Johan Verrept">
<organization showOnFrontPage="true">OneSpan</organization>
<address>
<email>johan.verrept@onespan.com</email>
</address>
</author>
<date month="January" year="2019"/>
</front>
<refcontent>FIDO Alliance Proposed Standard</refcontent>
</reference>
<reference anchor="EURO-SP18" target="https://ieeexplore.ieee.org/docume
nt/8406609" quoteTitle="true" derivedAnchor="EURO-SP18">
<front>
<title>Attacking Deterministic Signature Schemes using Fault Attacks
</title>
<seriesInfo name="DOI" value="10.1109/EuroSP.2018.00031"/>
<author fullname="Damian Poddebniak" surname="Poddebniak" initials="
D.">
<organization showOnFrontPage="true">Münster University of Applied
Sciences</organization>
</author>
<author fullname="Juraj Somorovsky" surname="Somorovsky" initials="J
.">
<organization showOnFrontPage="true">Ruhr University Bochum</organ
ization>
</author>
<author fullname="Sebastian Schinzel" surname="Schinzel" initials="S
.">
<organization showOnFrontPage="true">Münster University of Applied
Sciences</organization>
</author>
<author fullname="Manfred Lochter" surname="Lochter" initials="M.">
<organization showOnFrontPage="true">Federal Office for Informatio
n Security</organization>
</author>
<author fullname="Paul Rösler" surname="Rösler" initials="P.">
<organization showOnFrontPage="true">Ruhr University Bochum</organ
ization>
</author>
<date month="April" year="2018"/>
</front>
<refcontent>2018 IEEE European Symposium on Security and Privacy (Euro
S&amp;P)
</refcontent>
</reference>
<reference anchor="IANA.COSE.Algorithms" target="https://www.iana.org/as
signments/cose" quoteTitle="true" derivedAnchor="IANA.COSE.Algorithms">
<front>
<title>COSE Algorithms</title>
<author>
<organization showOnFrontPage="true">IANA</organization>
</author>
</front>
</reference>
<reference anchor="IANA.COSE.Curves" target="https://www.iana.org/assign
ments/cose" quoteTitle="true" derivedAnchor="IANA.COSE.Curves">
<front>
<title>COSE Elliptic Curves</title>
<author>
<organization showOnFrontPage="true">IANA</organization>
</author>
</front>
</reference>
<reference anchor="IANA.JOSE.Algorithms" target="https://www.iana.org/as
signments/jose" quoteTitle="true" derivedAnchor="IANA.JOSE.Algorithms">
<front>
<title>JSON Web Signature and Encryption Algorithms</title>
<author>
<organization showOnFrontPage="true">IANA</organization>
</author>
</front>
</reference>
<reference anchor="IANA.JOSE.Curves" target="https://www.iana.org/assign
ments/jose" quoteTitle="true" derivedAnchor="IANA.JOSE.Curves">
<front>
<title>JSON Web Key Elliptic Curve</title>
<author>
<organization showOnFrontPage="true">IANA</organization>
</author>
</front>
</reference>
<reference anchor="KUDELSKI17" target="https://research.kudelskisecurity
.com/2017/10/04/defeating-eddsa-with-faults/" quoteTitle="true" derivedAnchor="K
UDELSKI17">
<front>
<title>How to Defeat Ed25519 and EdDSA Using Faults</title>
<author fullname="Yolan Romailler" surname="Romailler" initials="Y."
>
</author>
<date month="October" year="2017"/>
</front>
<refcontent>Kudelski Security Research</refcontent>
</reference>
<reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6
979" quoteTitle="true" derivedAnchor="RFC6979">
<front>
<title>Deterministic Usage of the Digital Signature Algorithm (DSA)
and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author initials="T." surname="Pornin" fullname="T. Pornin">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="August"/>
<abstract>
<t>This document defines a deterministic digital signature generat
ion procedure. Such signatures are compatible with standard Digital Signature A
lgorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital si
gnatures and can be processed with unmodified verifiers, which need not be aware
of the procedure described therein. Deterministic signatures retain the crypto
graphic security features associated with digital signatures but can be more eas
ily implemented in various environments, since they do not need access to a sour
ce of high-quality randomness.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6979"/>
<seriesInfo name="DOI" value="10.17487/RFC6979"/>
</reference>
<reference anchor="WebAuthn" target="https://www.w3.org/TR/2019/REC-weba
uthn-1-20190304/" quoteTitle="true" derivedAnchor="WebAuthn">
<front>
<title>Web Authentication: An API for accessing Public Key Credentia
ls - Level 1</title>
<author initials="D." surname="Balfanz" fullname="Dirk Balfanz">
<organization showOnFrontPage="true">Google</organization>
<address>
<email>balfanz@google.com</email>
</address>
</author>
<author initials="A." surname="Czeskis" fullname="Alexei Czeskis">
<organization showOnFrontPage="true">Google</organization>
<address>
<email>aczeskis@google.com</email>
</address>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization showOnFrontPage="true">Google</organization>
<address>
<email>Jeff.Hodges@paypal.com</email>
</address>
</author>
<author initials="J.C." surname="Jones" fullname="J.C. Jones">
<organization showOnFrontPage="true">Mozilla</organization>
<address>
<email>jc@mozilla.com</email>
</address>
</author>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization showOnFrontPage="true">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 showOnFrontPage="true">Microsoft</organization>
<address>
<email>akshayku@microsoft.com</email>
</address>
</author>
<author initials="A." surname="Liao" fullname="Angelo Liao">
<organization showOnFrontPage="true">Microsoft</organization>
<address>
<email>huliao@microsoft.com</email>
</address>
</author>
<author initials="R." surname="Lindemann" fullname="Rolf Lindemann">
<organization showOnFrontPage="true">Nok Nok Labs</organization>
<address>
<email>rolf@noknok.com</email>
</address>
</author>
<author initials="E." surname="Lundberg" fullname="Emil Lundberg">
<organization showOnFrontPage="true">Yubico</organization>
<address>
<email>emil@yubico.com</email>
</address>
</author>
<date month="March" year="2019"/>
</front>
<refcontent>W3C Recommendation</refcontent>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRF
<section title="Acknowledgements" anchor="Acknowledgements" numbered="no"> C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t> <t pn="section-appendix.a-1">
Thanks to Thanks to
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Linda Dunbar, <contact fullname="Linda Dunbar"/>,
Stephen Farrell, <contact fullname="Stephen Farrell"/>,
John Fontana, <contact fullname="John Fontana"/>,
Jeff Hodges, <contact fullname="Jeff Hodges"/>,
Kevin Jacobs, <contact fullname="Kevin Jacobs"/>,
J.C. Jones, <contact fullname="J.C. Jones"/>,
Benjamin Kaduk, <contact fullname="Benjamin Kaduk"/>,
Murray Kucherawy, <contact fullname="Murray Kucherawy"/>,
Neil Madden, <contact fullname="Neil Madden"/>,
John Mattsson, <contact fullname="John Mattsson"/>,
Matthew Miller, <contact fullname="Matthew Miller"/>,
Tony Nadalin, <contact fullname="Tony Nadalin"/>,
Matt Palmer, <contact fullname="Matt Palmer"/>,
Eric Rescorla, <contact fullname="Eric Rescorla"/>,
Rich Salz, <contact fullname="Rich Salz"/>,
Jim Schaad, <contact fullname="Jim Schaad"/>,
Göran Selander, <contact fullname="Goeran Selander"/>,
Wendy Seltzer, <contact fullname="Wendy Seltzer"/>,
Sean Turner, <contact fullname="Sean Turner"/>,
and and
Samuel Weiler <contact fullname="Samuel Weiler"/>
for their roles in registering these algorithm identifiers. for their roles in registering these algorithm identifiers.
</t> </t>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<section title="Document History" anchor="History"> ="include" pn="section-appendix.b">
<t> <name slugifiedName="name-authors-address">Author's Address</name>
[[ to be removed by the RFC Editor before publication as an RFC ]] <author fullname="Michael B. Jones" surname="Jones" initials="M">
</t> <organization showOnFrontPage="true">Microsoft</organization>
<address>
<t> <email>mbj@microsoft.com</email>
-08 <uri>https://self-issued.info/</uri>
<list style='symbols'> </address>
<t> </author>
Addressed IESG review comments by Benjamin Kaduk and Roman Danyliw,
primarily completing the edits to register secp256k1 and ES256K as "R
ecommended: No" for COSE.
Some additional security considerations were also added.
</t>
</list>
</t>
<t>
-07
<list style='symbols'>
<t>
Addressed editorial SecDir review comment by Linda Dunbar about SHA-2
algorithms.
</t>
<t>
Addressed IETF last call comments by Jim Schaad, Rich Salz, and Eric
Rescorla,
now registering secp256k1 and ES256K as "Recommended: No" for COSE.
</t>
</list>
</t>
<t>
-06
<list style='symbols'>
<t>
Addressed Area Director review comment by Murray Kucherawy (which req
uested an editorial correction).
</t>
<t>
Changed requested assignment for ES256K from -46 to -47, due to an as
signment conflict.
</t>
</list>
</t>
<t>
-05
<list style='symbols'>
<t>
Removed unused reference to RFC 7049.
</t>
</list>
</t>
<t>
-04
<list style='symbols'>
<t>
Added explanatory comments on design decisions made that were discuss
ed on the mailing list
that Jim Schaad requested be added to the draft.
</t>
</list>
</t>
<t>
-03
<list style='symbols'>
<t>
Addressed review of -02 by Jim Schaad.
</t>
</list>
</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 Benj
amin 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</sp
anx>
to <spanx style="verb">secp256k1</spanx>.
</t>
<t>
Specified that secp256k1 signing is done using the SHA-256 hash funct
ion.
</t>
</list>
</t>
<t>
-00
<list style='symbols'>
<t>
Created the initial working group draft from draft-jones-cose-additio
nal-algorithms-00,
changing only the title, date, and history entry.
</t>
</list>
</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 69 change blocks. 
993 lines changed or deleted 1366 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/