draft-ietf-cose-webauthn-algorithms-08.txt | rfc8812.txt | |||
---|---|---|---|---|

COSE Working Group M. Jones | Internet Engineering Task Force (IETF) M. Jones | |||

Internet-Draft Microsoft | Request for Comments: 8812 Microsoft | |||

Intended status: Standards Track June 11, 2020 | Category: Standards Track August 2020 | |||

Expires: December 13, 2020 | ISSN: 2070-1721 | |||

COSE and JOSE Registrations for WebAuthn Algorithms | CBOR Object Signing and Encryption (COSE) and JSON Object Signing and | |||

draft-ietf-cose-webauthn-algorithms-08 | Encryption (JOSE) Registrations for Web Authentication (WebAuthn) | |||

Algorithms | ||||

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 FIDO2 Client to Authenticator Protocol (CTAP) specification | |||

CBOR Object Signing and Encryption (COSE) algorithm identifiers. | use CBOR Object Signing and Encryption (COSE) algorithm identifiers. | |||

This specification registers the following algorithms in the IANA | This specification registers the following algorithms (which are used | |||

"COSE Algorithms" registry, which are used by WebAuthn and CTAP | by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" | |||

implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, | registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA- | |||

and SHA-1, and ECDSA using the secp256k1 curve and SHA-256. It | 1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the | |||

registers the secp256k1 elliptic curve in the IANA "COSE Elliptic | secp256k1 curve and SHA-256. It registers the secp256k1 elliptic | |||

Curves" registry. Also, for use with JSON Object Signing and | curve in the IANA "COSE Elliptic Curves" registry. Also, for use | |||

Encryption (JOSE), it registers the algorithm ECDSA using the | with JSON Object Signing and Encryption (JOSE), it registers the | |||

secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and | algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA | |||

Encryption Algorithms" registry and the secp256k1 elliptic curve in | "JSON Web Signature and Encryption Algorithms" registry and the | |||

the IANA "JSON Web Key Elliptic Curve" registry. | secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" | |||

registry. | ||||

Status of This Memo | Status of This Memo | |||

This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||

provisions of BCP 78 and BCP 79. | ||||

Internet-Drafts are working documents of the Internet Engineering | ||||

Task Force (IETF). Note that other groups may also distribute | ||||

working documents as Internet-Drafts. The list of current Internet- | ||||

Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||

Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||

and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||

time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||

material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||

Internet Standards is available in Section 2 of RFC 7841. | ||||

This Internet-Draft will expire on December 13, 2020. | Information about the current status of this document, any errata, | |||

and how to provide feedback on it may be obtained at | ||||

https://www.rfc-editor.org/info/rfc8812. | ||||

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

carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||

to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||

include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||

the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||

described in the Simplified BSD License. | described in the Simplified BSD License. | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||

1.1. Requirements Notation and Conventions . . . . . . . . . . 3 | 1.1. Requirements Notation and Conventions | |||

2. RSASSA-PKCS1-v1_5 Signature Algorithm . . . . . . . . . . . . 3 | 2. RSASSA-PKCS1-v1_5 Signature Algorithm | |||

3. Using secp256k1 with JOSE and COSE . . . . . . . . . . . . . 4 | 3. Using secp256k1 with JOSE and COSE | |||

3.1. JOSE and COSE secp256k1 Curve Key Representations . . . . 5 | 3.1. JOSE and COSE secp256k1 Curve Key Representations | |||

3.2. ECDSA Signature with secp256k1 Curve . . . . . . . . . . 5 | 3.2. ECDSA Signature with secp256k1 Curve | |||

3.3. Other Uses of the secp256k1 Elliptic Curve . . . . . . . 7 | 3.3. Other Uses of the secp256k1 Elliptic Curve | |||

4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 4. IANA Considerations | |||

4.1. COSE Algorithms Registrations . . . . . . . . . . . . . . 7 | 4.1. COSE Algorithms Registrations | |||

4.2. COSE Elliptic Curves Registrations . . . . . . . . . . . 8 | 4.2. COSE Elliptic Curves Registrations | |||

4.3. JOSE Algorithms Registrations . . . . . . . . . . . . . . 8 | 4.3. JOSE Algorithms Registrations | |||

4.4. JSON Web Key Elliptic Curves Registrations . . . . . . . 9 | 4.4. JSON Web Key Elliptic Curves Registrations | |||

5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 5. Security Considerations | |||

5.1. RSA Key Size Security Considerations . . . . . . . . . . 9 | 5.1. RSA Key Size Security Considerations | |||

5.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations . . 9 | 5.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations | |||

5.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations . . 9 | 5.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations | |||

5.4. secp256k1 Security Considerations . . . . . . . . . . . . 9 | 5.4. secp256k1 Security Considerations | |||

6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. References | |||

6.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 6.1. Normative References | |||

6.2. Informative References . . . . . . . . . . . . . . . . . 11 | 6.2. Informative References | |||

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 | Acknowledgements | |||

Document History . . . . . . . . . . . . . . . . . . . . . . . . 12 | Author's Address | |||

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 3, line 12 ¶ | skipping to change at line 102 ¶ | |||

corresponding algorithm for use with JSON Object Signing and | corresponding algorithm for use with JSON Object Signing and | |||

Encryption (JOSE) [RFC7515] in the IANA "JSON Web Signature and | Encryption (JOSE) [RFC7515] in the IANA "JSON Web Signature and | |||

Encryption Algorithms" registry [IANA.JOSE.Algorithms] and registers | Encryption Algorithms" registry [IANA.JOSE.Algorithms] and registers | |||

an elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry | an elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry | |||

[IANA.JOSE.Curves]. | [IANA.JOSE.Curves]. | |||

1.1. Requirements Notation and Conventions | 1.1. Requirements Notation and Conventions | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||

"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||

14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||

capitals, as shown here. | capitals, as shown here. | |||

2. RSASSA-PKCS1-v1_5 Signature Algorithm | 2. RSASSA-PKCS1-v1_5 Signature Algorithm | |||

The RSASSA-PKCS1-v1_5 signature algorithm is defined in [RFC8017]. | The RSASSA-PKCS1-v1_5 signature algorithm is defined in [RFC8017]. | |||

The RSASSA-PKCS1-v1_5 signature algorithm is parameterized with a | The RSASSA-PKCS1-v1_5 signature algorithm is parameterized with a | |||

hash function (h). | hash function (h). | |||

A key of size 2048 bits or larger MUST be used with these algorithms. | A key of size 2048 bits or larger MUST be used with these algorithms. | |||

Implementations need to check that the key type is 'RSA' when | Implementations need to check that the key type is 'RSA' when | |||

creating or verifying a signature. | creating or verifying a signature. | |||

The RSASSA-PKCS1-v1_5 algorithms specified in this document are in | The RSASSA-PKCS1-v1_5 algorithms specified in this document are in | |||

the following table. | the following table. | |||

+-------+---------------+---------+-------------------+-------------+ | +=======+========+=========+===================+=============+ | |||

| Name | Value | Hash | Description | Recommended | | | Name | Value | Hash | Description | Recommended | | |||

+-------+---------------+---------+-------------------+-------------+ | +=======+========+=========+===================+=============+ | |||

| RS256 | TBD | SHA-256 | RSASSA-PKCS1-v1_5 | No | | | RS256 | -257 | SHA-256 | RSASSA-PKCS1-v1_5 | No | | |||

| | (temporary | | using SHA-256 | | | | | | | using SHA-256 | | | |||

| | assignment | | | | | +-------+--------+---------+-------------------+-------------+ | |||

| | -257 already | | | | | | RS384 | -258 | SHA-384 | RSASSA-PKCS1-v1_5 | No | | |||

| | in place) | | | | | | | | | using SHA-384 | | | |||

| RS384 | TBD | SHA-384 | RSASSA-PKCS1-v1_5 | No | | +-------+--------+---------+-------------------+-------------+ | |||

| | (temporary | | using SHA-384 | | | | RS512 | -259 | SHA-512 | RSASSA-PKCS1-v1_5 | No | | |||

| | assignment | | | | | | | | | using SHA-512 | | | |||

| | -258 already | | | | | +-------+--------+---------+-------------------+-------------+ | |||

| | in place) | | | | | | RS1 | -65535 | SHA-1 | RSASSA-PKCS1-v1_5 | Deprecated | | |||

| RS512 | TBD | SHA-512 | RSASSA-PKCS1-v1_5 | No | | | | | | using SHA-1 | | | |||

| | (temporary | | using SHA-512 | | | +-------+--------+---------+-------------------+-------------+ | |||

| | assignment | | | | | ||||

| | -259 already | | | | | ||||

| | in place) | | | | | ||||

| RS1 | TBD | SHA-1 | RSASSA-PKCS1-v1_5 | Deprecated | | ||||

| | (temporary | | using SHA-1 | | | ||||

| | assignment | | | | | ||||

| | -65535 | | | | | ||||

| | already in | | | | | ||||

| | place) | | | | | ||||

+-------+---------------+---------+-------------------+-------------+ | ||||

Table 1: RSASSA-PKCS1-v1_5 Algorithm Values | Table 1: RSASSA-PKCS1-v1_5 Algorithm Values | |||

Security considerations for use of the first three algorithms are in | Security considerations for use of the first three algorithms are in | |||

Section 5.2. Security considerations for use of the last algorithm | Section 5.2. Security considerations for use of the last algorithm | |||

are in Section 5.3. | are in Section 5.3. | |||

Note that these algorithms are already present in the IANA "JSON Web | Note that these algorithms are already present in the IANA "JSON Web | |||

Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms], | Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms], | |||

and so these registrations are only for the IANA "COSE Algorithms" | and so these registrations are only for the IANA "COSE Algorithms" | |||

registry [IANA.COSE.Algorithms]. | registry [IANA.COSE.Algorithms]. | |||

3. Using secp256k1 with JOSE and COSE | 3. Using secp256k1 with JOSE and COSE | |||

This section defines algorithm encodings and representations enabling | This section defines algorithm encodings and representations enabling | |||

the Standards for Efficient Cryptography Group (SECG) elliptic curve | the Standards for Efficient Cryptography Group (SECG) elliptic curve | |||

secp256k1 [SEC2] to be used for JOSE [RFC7515] and COSE [RFC8152] | secp256k1 [SEC2] to be used for JOSE [RFC7515] and COSE [RFC8152] | |||

messages. | messages. | |||

3.1. JOSE and COSE secp256k1 Curve Key Representations | 3.1. JOSE and COSE secp256k1 Curve Key Representations | |||

The Standards for Efficient Cryptography Group (SECG) elliptic curve | The SECG elliptic curve secp256k1 [SEC2] is represented in a JSON Web | |||

secp256k1 [SEC2] is represented in a JSON Web Key (JWK) [RFC7517] | Key (JWK) [RFC7517] using these values: | |||

using these values: | ||||

o "kty": "EC" | * "kty": "EC" | |||

o "crv": "secp256k1" | * "crv": "secp256k1" | |||

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 6.2.1 of [RFC7518]. As a compressed point encoding | Section 6.2.1 of [RFC7518]. As a compressed point encoding | |||

representation is not defined for JWK elliptic curve points, the | representation is not defined for JWK elliptic curve points, the | |||

uncompressed point encoding defined there MUST be used. The "x" and | uncompressed point encoding defined there MUST be used. The "x" and | |||

"y" values represented MUST both be exactly 256 bits, with any | "y" values represented MUST both be exactly 256 bits, with any | |||

leading zeros preserved. Other optional values such as "alg" MAY | leading zeros preserved. Other optional values such as "alg" MAY | |||

also be present. | also be present. | |||

It is represented in a COSE_Key [RFC8152] using these values: | It is represented in a COSE_Key [RFC8152] using these values: | |||

o "kty" (1): "EC2" (2) | * "kty" (1): "EC2" (2) | |||

o "crv" (-1): "secp256k1" (TBD - requested assignment 8) | * "crv" (-1): "secp256k1" (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 is | preserved; if the compressed representation is used, the "y" value is | |||

a boolean value, as specified in Section 13.1.1 of [RFC8152]. Other | a boolean value, as specified in Section 13.1.1 of [RFC8152]. Other | |||

optional values such as "alg" (3) MAY also be present. | optional values such as "alg" (3) MAY also be present. | |||

skipping to change at page 6, line 8 ¶ | skipping to change at line 203 ¶ | |||

The ECDSA secp256k1 SHA-256 digital signature is generated as | The ECDSA secp256k1 SHA-256 digital signature is generated as | |||

follows: | follows: | |||

1. Generate a digital signature of the JWS Signing Input or the COSE | 1. Generate a digital signature of the JWS Signing Input or the COSE | |||

Sig_structure using ECDSA secp256k1 SHA-256 with the desired | Sig_structure using ECDSA secp256k1 SHA-256 with the desired | |||

private key. The output will be the pair (R, S), where R and S | private key. The output will be the pair (R, S), where R and S | |||

are 256-bit unsigned integers. | are 256-bit unsigned integers. | |||

2. Turn R and S into octet sequences in big-endian order, with each | 2. Turn R and S into octet sequences in big-endian order, with each | |||

array being be 32 octets long. The octet sequence | array being 32 octets long. The octet sequence representations | |||

representations MUST NOT be shortened to omit any leading zero | MUST NOT be shortened to omit any leading zero octets contained | |||

octets contained in the values. | in the values. | |||

3. Concatenate the two octet sequences in the order R and then S. | 3. Concatenate the two octet sequences in the order R and then S. | |||

(Note that many ECDSA implementations will directly produce this | (Note that many ECDSA implementations will directly produce this | |||

concatenation as their output.) | concatenation as their output.) | |||

4. The resulting 64-octet sequence is the JWS Signature or COSE | 4. The resulting 64-octet sequence is the JWS Signature or COSE | |||

signature value. | signature value. | |||

Implementations SHOULD use a deterministic algorithm to generate the | Implementations SHOULD use a deterministic algorithm to generate the | |||

ECDSA nonce, k, such as [RFC6979]. However, in situations where | ECDSA nonce, k, such as the algorithm defined in [RFC6979]. However, | |||

devices are vulnerable to physical attacks, deterministic ECDSA has | in situations where devices are vulnerable to physical attacks, | |||

been shown to be susceptible to fault injection attacks [Kudelski17] | deterministic ECDSA has been shown to be susceptible to fault | |||

[EuroSP18]. Where this is a possibility, implementations SHOULD | injection attacks [KUDELSKI17] [EURO-SP18]. Where this is a | |||

implement appropriate countermeasures. Where there are specific | possibility, implementations SHOULD implement appropriate | |||

certification requirements (such as FIPS approval), implementors | countermeasures. Where there are specific certification requirements | |||

should check whether deterministic ECDSA is an approved nonce | (such as FIPS approval), implementors should check whether | |||

generation method. | deterministic ECDSA is an approved nonce 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 | | | Name | Value | Description | Recommended | | |||

| Name | | | | | +========+=======+=======================+=============+ | |||

+----------+-------------------+----------------------+-------------+ | | ES256K | -47 | ECDSA using secp256k1 | No | | |||

| ES256K | TBD (requested | ECDSA using | No | | | | | curve and SHA-256 | | | |||

| | assignment -47) | secp256k1 curve and | | | +--------+-------+-----------------------+-------------+ | |||

| | | SHA-256 | | | ||||

+----------+-------------------+----------------------+-------------+ | ||||

Table 2: ECDSA Algorithm Values | Table 2: ECDSA Algorithm Values | |||

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 | * 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 | * 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" | * If the "alg" field is present, it MUST represent the "ES256K" | |||

algorithm. | algorithm. | |||

o If the "key_ops" field is present, it MUST include "sign" when | * If the "key_ops" field is present, it MUST include "sign" when | |||

creating an ECDSA signature. | creating an ECDSA signature. | |||

o If the "key_ops" field is present, it MUST include "verify" when | * If the "key_ops" field is present, it MUST include "verify" when | |||

verifying an ECDSA signature. | verifying an ECDSA signature. | |||

o If the JWK _use_ field is present, its value MUST be "sig". | * If the JWK "use" field is present, its value MUST be "sig". | |||

3.3. Other Uses of the secp256k1 Elliptic Curve | 3.3. Other Uses of the secp256k1 Elliptic Curve | |||

This specification defines how to use the secp256k1 curve for ECDSA | This specification defines how to use the secp256k1 curve for ECDSA | |||

signatures for both JOSE and COSE implementations. While in theory, | signatures for both JOSE and COSE implementations. While in theory | |||

the curve could also be used for ECDH-ES key agreement, it is beyond | the 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 | the scope of this specification to state whether this is or is not | |||

advisable. Thus, whether to recommend its use with ECDH-ES is left | advisable. Thus, whether or not to recommend its use with ECDH-ES is | |||

for experts to decide in future specifications. | left for experts to decide in future specifications. | |||

When used for ECDSA, the secp256k1 curve MUST be used only with the | When used for ECDSA, the secp256k1 curve MUST be used only with the | |||

"ES256K" algorithm identifier and not any others, including not with | "ES256K" algorithm identifier and not any others, including not with | |||

the COSE "ES256" identifier. Note that the "ES256K" algorithm | the COSE "ES256" identifier. Note that the "ES256K" algorithm | |||

identifier needed to be introduced for JOSE to sign with the | identifier needed to be introduced for JOSE to sign with the | |||

secp256k1 curve because the JOSE "ES256" algorithm is defined to be | secp256k1 curve because the JOSE "ES256" algorithm is defined to be | |||

used only with the P-256 curve. The COSE treatment of how to sign | used only with the P-256 curve. The COSE treatment of how to sign | |||

with secp256k1 is intentionally parallel to that for JOSE, where the | with secp256k1 is intentionally parallel to that for JOSE, where the | |||

secp256k1 curve MUST be used with the "ES256K" algorithm identifier. | secp256k1 curve MUST be used with the "ES256K" algorithm identifier. | |||

4. IANA Considerations | 4. IANA Considerations | |||

4.1. COSE Algorithms Registrations | 4.1. COSE Algorithms Registrations | |||

This section registers the following values in the IANA "COSE | IANA has registered the following values in the "COSE Algorithms" | |||

Algorithms" registry [IANA.COSE.Algorithms]. | registry [IANA.COSE.Algorithms]. | |||

o Name: RS256 | Name: RS256 | |||

o Value: TBD (temporary assignment -257 already in place) | Value: -257 | |||

o Description: RSASSA-PKCS1-v1_5 using SHA-256 | Description: RSASSA-PKCS1-v1_5 using SHA-256 | |||

o Reference: Section 2 of this document | Change Controller: IESG | |||

o Recommended: No | Reference: Section 2 of RFC 8812 | |||

Recommended: No | ||||

o Name: RS384 | Name: RS384 | |||

o Value: TBD (temporary assignment -258 already in place) | Value: -258 | |||

o Description: RSASSA-PKCS1-v1_5 using SHA-384 | Description: RSASSA-PKCS1-v1_5 using SHA-384 | |||

o Reference: Section 2 of this document | Change Controller: IESG | |||

o Recommended: No | Reference: Section 2 of RFC 8812 | |||

o Name: RS512 | Recommended: No | |||

o Value: TBD (temporary assignment -259 already in place) | ||||

o Description: RSASSA-PKCS1-v1_5 using SHA-512 | ||||

o Reference: Section 2 of this document | ||||

o Recommended: No | ||||

o Name: RS1 | Name: RS512 | |||

o Value: TBD (temporary assignment -65535 already in place) | Value: -259 | |||

o Description: RSASSA-PKCS1-v1_5 using SHA-1 | Description: RSASSA-PKCS1-v1_5 using SHA-512 | |||

o Reference: Section 2 of this document | Change Controller: IESG | |||

o Recommended: Deprecated | Reference: Section 2 of RFC 8812 | |||

Recommended: No | ||||

o Name: ES256K | Name: RS1 | |||

o Value: TBD (requested assignment -47) | Value: -65535 | |||

o Description: ECDSA using secp256k1 curve and SHA-256 | Description: RSASSA-PKCS1-v1_5 using SHA-1 | |||

o Reference: Section 3.2 of this document | Change Controller: IESG | |||

o Recommended: No | Reference: Section 2 of RFC 8812 | |||

Recommended: Deprecated | ||||

Name: ES256K | ||||

Value: -47 | ||||

Description: ECDSA using secp256k1 curve and SHA-256 | ||||

Change Controller: IESG | ||||

Reference: Section 3.2 of RFC 8812 | ||||

Recommended: No | ||||

4.2. COSE Elliptic Curves Registrations | 4.2. COSE Elliptic Curves Registrations | |||

This section registers the following value in the IANA "COSE Elliptic | IANA has registered the following value in the "COSE Elliptic Curves" | |||

Curves" registry [IANA.COSE.Curves]. | registry [IANA.COSE.Curves]. | |||

o Name: secp256k1 | Name: secp256k1 | |||

o Value: TBD (requested assignment 8) | Value: 8 | |||

o Key Type: EC2 | Key Type: EC2 | |||

o Description: SECG secp256k1 curve | Description: SECG secp256k1 curve | |||

o Change Controller: IESG | Change Controller: IESG | |||

o Reference: Section 3.1 of [[ this specification ]] | Reference: Section 3.1 of RFC 8812 | |||

o Recommended: No | Recommended: No | |||

4.3. JOSE Algorithms Registrations | 4.3. JOSE Algorithms Registrations | |||

This section registers the following value in the IANA "JSON Web | IANA has registered the following value in the "JSON Web Signature | |||

Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. | and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. | |||

o Algorithm Name: ES256K | Algorithm Name: ES256K | |||

o Algorithm Description: ECDSA using secp256k1 curve and SHA-256 | Algorithm Description: ECDSA using secp256k1 curve and SHA-256 | |||

o Algorithm Usage Locations: alg | Algorithm Usage Location(s): alg | |||

o JOSE Implementation Requirements: Optional | JOSE Implementation Requirements: Optional | |||

o Change Controller: IESG | Change Controller: IESG | |||

o Reference: Section 3.2 of [[ this specification ]] | Reference: Section 3.2 of RFC 8812 | |||

o Algorithm Analysis Document(s): [SEC2] | Algorithm Analysis Document(s): [SEC2] | |||

4.4. JSON Web Key Elliptic Curves Registrations | 4.4. JSON Web Key Elliptic Curves Registrations | |||

This section registers the following value in the IANA "JSON Web Key | IANA has registered the following value in the "JSON Web Key Elliptic | |||

Elliptic Curve" registry [IANA.JOSE.Curves]. | Curve" registry [IANA.JOSE.Curves]. | |||

o Curve Name: secp256k1 | Curve Name: secp256k1 | |||

o Curve Description: SECG secp256k1 curve | Curve Description: SECG secp256k1 curve | |||

o JOSE Implementation Requirements: Optional | JOSE Implementation Requirements: Optional | |||

o Change Controller: IESG | Change Controller: IESG | |||

o Specification Document(s): Section 3.1 of [[ this specification ]] | Specification Document(s): Section 3.1 of RFC 8812 | |||

5. Security Considerations | 5. Security Considerations | |||

5.1. RSA Key Size Security Considerations | 5.1. RSA Key Size Security Considerations | |||

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

skipping to change at page 9, line 42 ¶ | skipping to change at line 379 ¶ | |||

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 Trusted Platform Modules (TPMs) continue | |||

WebAuthn implementations need a COSE algorithm identifier for "RS1" | to use it; therefore, WebAuthn implementations need a COSE algorithm | |||

when TPM attestations using 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 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. As described in Section 8.1.1 of [RFC8152], we | 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 | currently do not have any way to deal with this attack except to | |||

restrict the set of curves that can be used. | 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], | |||

skipping to change at page 10, line 25 ¶ | skipping to change at line 411 ¶ | |||

There are theoretical weaknesses with this curve that could result in | There are theoretical weaknesses with this curve that could result in | |||

future attacks. While these potential weaknesses are not unique to | future attacks. While these potential weaknesses are not unique to | |||

this curve, they are the reason that this curve is registered as | this curve, they are the reason that this curve is registered as | |||

"Recommended: No". | "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, | |||

2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ | DOI 10.6028/NIST.FIPS.186-4, July 2013, | |||

NIST.FIPS.186-4.pdf>. | <https://doi.org/10.6028/NIST.FIPS.186-4>. | |||

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||

DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||

<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||

[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security | [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security | |||

Considerations for the SHA-0 and SHA-1 Message-Digest | Considerations for the SHA-0 and SHA-1 Message-Digest | |||

Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, | Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, | |||

<https://www.rfc-editor.org/info/rfc6194>. | <https://www.rfc-editor.org/info/rfc6194>. | |||

skipping to change at page 11, line 25 ¶ | skipping to change at line 457 ¶ | |||

2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||

May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||

[RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing | [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing | |||

and Encryption (COSE) Messages", RFC 8230, | and Encryption (COSE) Messages", RFC 8230, | |||

DOI 10.17487/RFC8230, September 2017, | DOI 10.17487/RFC8230, September 2017, | |||

<https://www.rfc-editor.org/info/rfc8230>. | <https://www.rfc-editor.org/info/rfc8230>. | |||

[SEC1] Standards for Efficient Cryptography Group, "SEC 1: | [SEC1] Standards for Efficient Cryptography Group, "SEC 1: | |||

Elliptic Curve Cryptography", Version 2.0, May 2009, | Elliptic Curve Cryptography", Version 2.0, May 2009, | |||

<http://www.secg.org/sec1-v2.pdf>. | <https://www.secg.org/sec1-v2.pdf>. | |||

[SEC2] Standards for Efficient Cryptography Group, "SEC 2: | [SEC2] Standards for Efficient Cryptography Group, "SEC 2: | |||

Recommended Elliptic Curve Domain Parameters", | Recommended Elliptic Curve Domain Parameters", | |||

Version 2.0, January 2010, | Version 2.0, January 2010, | |||

<http://www.secg.org/sec2-v2.pdf>. | <https://www.secg.org/sec2-v2.pdf>. | |||

6.2. Informative References | 6.2. Informative References | |||

[CTAP] Brand, C., Czeskis, A., Ehrensvaerd, J., Jones, M., Kumar, | [CTAP] Brand, C., Czeskis, A., Ehrensvärd, J., Jones, M., Kumar, | |||

A., Lindemann, R., Powers, A., and J. Verrept, "Client to | A., Lindemann, R., Powers, A., and J. Verrept, "Client to | |||

Authenticator Protocol (CTAP)", FIDO Alliance Proposed | Authenticator Protocol (CTAP)", FIDO Alliance Proposed | |||

Standard, January 2019, <https://fidoalliance.org/specs/ | Standard, January 2019, <https://fidoalliance.org/specs/ | |||

fido-v2.0-ps-20190130/fido-client-to-authenticator- | fido-v2.0-ps-20190130/fido-client-to-authenticator- | |||

protocol-v2.0-ps-20190130.html>. | protocol-v2.0-ps-20190130.html>. | |||

[EuroSP18] | [EURO-SP18] | |||

Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M., | Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M., | |||

and P. Roesler, "Attacking Deterministic Signature Schemes | and P. Rösler, "Attacking Deterministic Signature Schemes | |||

using Fault Attacks", IEEE European Symposium on Security | using Fault Attacks", 2018 IEEE European Symposium on | |||

and Privacy (EuroS&P) 2018, April 2018, | Security and Privacy (EuroS&P), | |||

<https://eprint.iacr.org/2017/1014.pdf>. | DOI 10.1109/EuroSP.2018.00031, April 2018, | |||

<https://ieeexplore.ieee.org/document/8406609>. | ||||

[IANA.COSE.Algorithms] | [IANA.COSE.Algorithms] | |||

IANA, "COSE Algorithms", | IANA, "COSE Algorithms", | |||

<https://www.iana.org/assignments/cose/ | <https://www.iana.org/assignments/cose>. | |||

cose.xhtml#algorithms>. | ||||

[IANA.COSE.Curves] | [IANA.COSE.Curves] | |||

IANA, "COSE Elliptic Curves", | IANA, "COSE Elliptic Curves", | |||

<https://www.iana.org/assignments/cose/ | <https://www.iana.org/assignments/cose>. | |||

cose.xhtml#elliptic-curves>. | ||||

[IANA.JOSE.Algorithms] | [IANA.JOSE.Algorithms] | |||

IANA, "JSON Web Signature and Encryption Algorithms", | IANA, "JSON Web Signature and Encryption Algorithms", | |||

<https://www.iana.org/assignments/jose/jose.xhtml#web- | <https://www.iana.org/assignments/jose>. | |||

signature-encryption-algorithms>. | ||||

[IANA.JOSE.Curves] | [IANA.JOSE.Curves] | |||

IANA, "JSON Web Key Elliptic Curve", | IANA, "JSON Web Key Elliptic Curve", | |||

<https://www.iana.org/assignments/jose/jose.xhtml#web-key- | <https://www.iana.org/assignments/jose>. | |||

elliptic-curve>. | ||||

[Kudelski17] | [KUDELSKI17] | |||

Romailler, Y., "How to defeat Ed25519 and EdDSA using | Romailler, Y., "How to Defeat Ed25519 and EdDSA Using | |||

faults", October 2017, | Faults", Kudelski Security Research, October 2017, | |||

<https://research.kudelskisecurity.com/2017/10/04/ | <https://research.kudelskisecurity.com/2017/10/04/ | |||

defeating-eddsa-with-faults/>. | defeating-eddsa-with-faults/>. | |||

[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature | [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature | |||

Algorithm (DSA) and Elliptic Curve Digital Signature | Algorithm (DSA) and Elliptic Curve Digital Signature | |||

Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August | Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August | |||

2013, <https://www.rfc-editor.org/info/rfc6979>. | 2013, <https://www.rfc-editor.org/info/rfc6979>. | |||

[WebAuthn] | [WebAuthn] Balfanz, D., Czeskis, A., Hodges, J., Jones, J.C., 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", 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 Roman Danyliw, Linda Dunbar, Stephen Farrell, John Fontana, | Thanks to Roman Danyliw, Linda Dunbar, Stephen Farrell, John Fontana, | |||

Jeff Hodges, Kevin Jacobs, J.C. Jones, Benjamin Kaduk, Murray | Jeff Hodges, Kevin Jacobs, J.C. Jones, Benjamin Kaduk, Murray | |||

Kucherawy, Neil Madden, John Mattsson, Matthew Miller, Tony Nadalin, | Kucherawy, Neil Madden, John Mattsson, Matthew Miller, Tony Nadalin, | |||

Matt Palmer, Eric Rescorla, Rich Salz, Jim Schaad, Goeran Selander, | Matt Palmer, Eric Rescorla, Rich Salz, Jim Schaad, Goeran Selander, | |||

Wendy Seltzer, Sean Turner, and Samuel Weiler for their roles in | Wendy Seltzer, Sean Turner, and Samuel Weiler for their roles in | |||

registering these algorithm identifiers. | registering these algorithm identifiers. | |||

Document History | ||||

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

o Addressed editorial SecDir review comment by Linda Dunbar about | ||||

SHA-2 algorithms. | ||||

o Addressed IETF last call comments by Jim Schaad, Rich Salz, and | ||||

Eric Rescorla, now registering secp256k1 and ES256K as | ||||

"Recommended: No" for COSE. | ||||

-06 | ||||

o Addressed Area Director review comment by Murray Kucherawy (which | ||||

requested an editorial correction). | ||||

o Changed requested assignment for ES256K from -46 to -47, due to an | ||||

assignment conflict. | ||||

-05 | ||||

o Removed unused reference to RFC 7049. | ||||

-04 | ||||

o Added explanatory comments on design decisions made that were | ||||

discussed on the mailing list that Jim Schaad requested be added | ||||

to the draft. | ||||

-03 | ||||

o Addressed review of -02 by Jim Schaad. | ||||

-02 | ||||

o Addressed working group last call comments. Thanks to J.C. | ||||

Jones, Kevin Jacobs, Jim Schaad, Neil Madden, and Benjamin Kaduk | ||||

for their useful feedback. | ||||

-01 | ||||

o Changed the JOSE curve identifier from "P-256K" to "secp256k1". | ||||

o Specified that secp256k1 signing is done using the SHA-256 hash | ||||

function. | ||||

-00 | ||||

o Created the initial working group draft from draft-jones-cose- | ||||

additional-algorithms-00, changing only the title, date, and | ||||

history entry. | ||||

Author's Address | Author's Address | |||

Michael B. Jones | Michael B. Jones | |||

Microsoft | Microsoft | |||

Email: mbj@microsoft.com | Email: mbj@microsoft.com | |||

URI: http://self-issued.info/ | URI: https://self-issued.info/ | |||

End of changes. 53 change blocks. | ||||

260 lines changed or deleted | | 187 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/ |