draft-ietf-cose-webauthn-algorithms-07.txt   draft-ietf-cose-webauthn-algorithms-08.txt 
COSE Working Group M. Jones COSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track June 3, 2020 Intended status: Standards Track June 11, 2020
Expires: December 5, 2020 Expires: December 13, 2020
COSE and JOSE Registrations for WebAuthn Algorithms COSE and JOSE Registrations for WebAuthn Algorithms
draft-ietf-cose-webauthn-algorithms-07 draft-ietf-cose-webauthn-algorithms-08
Abstract Abstract
The W3C Web Authentication (WebAuthn) specification and the FIDO The W3C Web Authentication (WebAuthn) specification and the FIDO
Alliance Client to Authenticator Protocol (CTAP) specification use Alliance Client to Authenticator Protocol (CTAP) specification use
CBOR Object Signing and Encryption (COSE) algorithm identifiers. CBOR Object Signing and Encryption (COSE) algorithm identifiers.
This specification registers the following algorithms in the IANA This specification registers the following algorithms in the IANA
"COSE Algorithms" registry, which are used by WebAuthn and CTAP "COSE Algorithms" registry, which are used by WebAuthn and CTAP
implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, 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 and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2020. This Internet-Draft will expire on December 13, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. RSA Key Size Security Considerations . . . . . . . . . . 9 5.1. RSA Key Size Security Considerations . . . . . . . . . . 9
5.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations . . 9 5.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations . . 9
5.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations . . 9 5.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations . . 9
5.4. secp256k1 Security Considerations . . . . . . . . . . . . 9 5.4. secp256k1 Security Considerations . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Document History . . . . . . . . . . . . . . . . . . . . . . . . 12 Document History . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This specification defines how to use several algorithms with CBOR This specification defines how to use several algorithms with CBOR
Object Signing and Encryption (COSE) [RFC8152] that are used by Object Signing and Encryption (COSE) [RFC8152] that are used by
implementations of the W3C Web Authentication (WebAuthn) [WebAuthn] implementations of the W3C Web Authentication (WebAuthn) [WebAuthn]
and FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) and FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP)
[CTAP] specifications. This specification registers these algorithms [CTAP] specifications. This specification registers these algorithms
in the IANA "COSE Algorithms" registry [IANA.COSE.Algorithms] and in the IANA "COSE Algorithms" registry [IANA.COSE.Algorithms] and
registers an elliptic curve in the IANA "COSE Elliptic Curves" registers an elliptic curve in the IANA "COSE Elliptic Curves"
skipping to change at page 5, line 33 skipping to change at page 5, line 33
o "kty" (1): "EC2" (2) o "kty" (1): "EC2" (2)
o "crv" (-1): "secp256k1" (TBD - requested assignment 8) o "crv" (-1): "secp256k1" (TBD - requested assignment 8)
plus the values needed to represent the curve point, as defined in plus the values needed to represent the curve point, as defined in
Section 13.1.1 of [RFC8152]. Either the uncompressed or compressed Section 13.1.1 of [RFC8152]. Either the uncompressed or compressed
point encoding representations defined there can be used. The "x" point encoding representations defined there can be used. The "x"
value represented MUST be exactly 256 bits, with any leading zeros value represented MUST be exactly 256 bits, with any leading zeros
preserved. If the uncompressed representation is used, the "y" value preserved. If the uncompressed representation is used, the "y" value
represented MUST likewise be exactly 256 bits, with any leading zeros represented MUST likewise be exactly 256 bits, with any leading zeros
preserved; if the compressed representation is used, the "y" value preserved; if the compressed representation is used, the "y" value is
MUST be a boolean value, as specified in Section 13.1.1 of [RFC8152]. a boolean value, as specified in Section 13.1.1 of [RFC8152]. Other
Other optional values such as "alg" (3) MAY also be present. optional values such as "alg" (3) MAY also be present.
3.2. ECDSA Signature with secp256k1 Curve 3.2. ECDSA Signature with secp256k1 Curve
The ECDSA signature algorithm is defined in [DSS]. This The ECDSA signature algorithm is defined in [DSS]. This
specification defines the "ES256K" algorithm identifier, which is specification defines the "ES256K" algorithm identifier, which is
used to specify the use of ECDSA with the secp256k1 curve and the used to specify the use of ECDSA with the secp256k1 curve and the
SHA-256 [DSS] cryptographic hash function. Implementations need to SHA-256 [DSS] cryptographic hash function. Implementations need to
check that the key type is "EC" for JOSE or "EC2" (2) for COSE and check that the key type is "EC" for JOSE or "EC2" (2) for COSE and
that the curve of the key is secp256k1 when creating or verifying a that the curve of the key is secp256k1 when creating or verifying a
signature. signature.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
should check whether deterministic ECDSA is an approved nonce should check whether deterministic ECDSA is an approved nonce
generation method. generation method.
The ECDSA secp256k1 SHA-256 algorithm specified in this document uses The ECDSA secp256k1 SHA-256 algorithm specified in this document uses
these identifiers: these identifiers:
+----------+-------------------+----------------------+-------------+ +----------+-------------------+----------------------+-------------+
| JOSE Alg | COSE Alg Value | Description | Recommended | | JOSE Alg | COSE Alg Value | Description | Recommended |
| Name | | | | | Name | | | |
+----------+-------------------+----------------------+-------------+ +----------+-------------------+----------------------+-------------+
| ES256K | TBD (requested | ECDSA using | Yes | | ES256K | TBD (requested | ECDSA using | No |
| | assignment -47) | secp256k1 curve and | | | | assignment -47) | secp256k1 curve and | |
| | | SHA-256 | | | | | SHA-256 | |
+----------+-------------------+----------------------+-------------+ +----------+-------------------+----------------------+-------------+
Table 2: ECDSA Algorithm Values Table 2: ECDSA Algorithm Values
Implementation of this algorithm is recommended because of its
widespread use in decentralized systems and those that chose it over
the NIST curves.
When using a JWK or COSE_Key for this algorithm, the following checks When using a JWK or COSE_Key for this algorithm, the following checks
are made: are made:
o The "kty" field MUST be present and it MUST be "EC" for JOSE or o The "kty" field MUST be present and it MUST be "EC" for JOSE or
"EC2" for COSE. "EC2" for COSE.
o The "crv" field MUST be present and it MUST represent the o The "crv" field MUST be present and it MUST represent the
"secp256k1" elliptic curve. "secp256k1" elliptic curve.
o If the "alg" field is present, it MUST represent the "ES256K" o If the "alg" field is present, it MUST represent the "ES256K"
skipping to change at page 9, line 30 skipping to change at page 9, line 30
The security considerations on key sizes for RSA algorithms from The security considerations on key sizes for RSA algorithms from
Section 6.1 of [RFC8230] also apply to the RSA algorithms in this Section 6.1 of [RFC8230] also apply to the RSA algorithms in this
specification. specification.
5.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations 5.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations
The security considerations on the use of RSASSA-PKCS1-v1_5 with The security considerations on the use of RSASSA-PKCS1-v1_5 with
SHA-2 hash functions (SHA-256, SHA-384, and SHA-512) from Section 8.3 SHA-2 hash functions (SHA-256, SHA-384, and SHA-512) from Section 8.3
of [RFC7518] also apply to their use in this specification. For that of [RFC7518] also apply to their use in this specification. For that
reason, these algorithms are registered as being "Not Recommended". reason, these algorithms are registered as being "Not Recommended".
Likewise, the exponent restrictions described in Section 8.3 of
[RFC7518] also apply.
5.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations 5.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations
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 [RFC6194] apply in this specification. For that reason, the from [RFC6194] apply in this specification. For that reason, the
"RS1" algorithm is registered as "Deprecated". Likewise, the "RS1" algorithm is registered as "Deprecated". Likewise, the
exponent restrictions described in Section 8.3 of [RFC7518] also exponent restrictions described in Section 8.3 of [RFC7518] also
apply. apply.
A COSE algorithm identifier for this algorithm is nonetheless being A COSE algorithm identifier for this algorithm is nonetheless being
registered because deployed TPMs continue to use it, and therefore registered because deployed TPMs continue to use it, and therefore
WebAuthn implementations need a COSE algorithm identifier for "RS1" WebAuthn implementations need a COSE algorithm identifier for "RS1"
when TPM attestations using this algorithm are being represented. when TPM attestations using this algorithm are being represented.
New COSE applications MUST NOT use this algorithm. New COSE applications and protocols MUST NOT use this algorithm.
5.4. secp256k1 Security Considerations 5.4. secp256k1 Security Considerations
Care should be taken that a secp256k1 key is not mistaken for a P-256 Care should be taken that a secp256k1 key is not mistaken for a P-256
[RFC7518] key, given that their representations are the same except [RFC7518] key, given that their representations are the same except
for the "crv" value. for the "crv" value. As described in Section 8.1.1 of [RFC8152], we
currently do not have any way to deal with this attack except to
restrict the set of curves that can be used.
The procedures and security considerations described in the [SEC1], The procedures and security considerations described in the [SEC1],
[SEC2], and [DSS] specifications apply to implementations of this [SEC2], and [DSS] specifications apply to implementations of this
specification. specification.
Timing side-channel attacks are possible if the implementation of
scalar multiplication over the curve does not execute in constant
time.
There are theoretical weaknesses with this curve that could result in
future attacks. While these potential weaknesses are not unique to
this curve, they are the reason that this curve is registered as
"Recommended: No".
6. References 6. References
6.1. Normative References 6.1. Normative References
[DSS] National Institute of Standards and Technology (NIST), [DSS] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS PUB 186-4, July "Digital Signature Standard (DSS)", FIPS PUB 186-4, July
2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 12, line 31 skipping to change at page 12, line 41
[WebAuthn] [WebAuthn]
Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones,
M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg,
"Web Authentication: An API for accessing Public Key "Web Authentication: An API for accessing Public Key
Credentials - Level 1", World Wide Web Consortium Credentials - Level 1", World Wide Web Consortium
(W3C) Recommendation, March 2019, (W3C) Recommendation, March 2019,
<https://www.w3.org/TR/2019/REC-webauthn-1-20190304/>. <https://www.w3.org/TR/2019/REC-webauthn-1-20190304/>.
Acknowledgements Acknowledgements
Thanks to Linda Dunbar, Stephen Farrell, John Fontana, Jeff Hodges, Thanks to Roman Danyliw, Linda Dunbar, Stephen Farrell, John Fontana,
Kevin Jacobs, J.C. Jones, Benjamin Kaduk, Murray Kucherawy, Neil Jeff Hodges, Kevin Jacobs, J.C. Jones, Benjamin Kaduk, Murray
Madden, John Mattsson, Matthew Miller, Tony Nadalin, Matt Palmer, Kucherawy, Neil Madden, John Mattsson, Matthew Miller, Tony Nadalin,
Eric Rescorla, Rich Salz, Jim Schaad, Goeran Selander, Wendy Seltzer, Matt Palmer, Eric Rescorla, Rich Salz, Jim Schaad, Goeran Selander,
Sean Turner, and Samuel Weiler for their roles in registering these Wendy Seltzer, Sean Turner, and Samuel Weiler for their roles in
algorithm identifiers. registering these algorithm identifiers.
Document History Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-08
o Addressed IESG review comments by Benjamin Kaduk and Roman
Danyliw, primarily completing the edits to register secp256k1 and
ES256K as "Recommended: No" for COSE. Some additional security
considerations were also added.
-07 -07
o Addressed editorial SecDir review comment by Linda Dunbar about o Addressed editorial SecDir review comment by Linda Dunbar about
SHA-2 algorithms. SHA-2 algorithms.
o Addressed IETF last call comments by Jim Schaad, Rich Salz, and o Addressed IETF last call comments by Jim Schaad, Rich Salz, and
Eric Rescorla, now registering secp256k1 and ES256K as Eric Rescorla, now registering secp256k1 and ES256K as
"Recommended: No" for COSE. "Recommended: No" for COSE.
-06 -06
o Addressed Area Directory review comment by Murray Kucherawy (which
o Addressed Area Director review comment by Murray Kucherawy (which
requested an editorial correction). requested an editorial correction).
o Changed requested assignment for ES256K from -46 to -47, due to an o Changed requested assignment for ES256K from -46 to -47, due to an
assignment conflict. assignment conflict.
-05 -05
o Removed unused reference to RFC 7049. o Removed unused reference to RFC 7049.
-04 -04
 End of changes. 14 change blocks. 
22 lines changed or deleted 38 lines changed or added

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