Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Replace obsolete RFC8152 with RFC9052 and RFC9053 #1804

Merged
merged 3 commits into from Oct 6, 2022
Merged

Replace obsolete RFC8152 with RFC9052 and RFC9053 #1804

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5d0cc61
Replace obsolete RFC8152 with RFC9052 and RFC9053
emlun Sep 22, 2022
6285f72
Fix reference to ECDSA+hash choice recommendation in RFC9053
emlun Sep 22, 2022
76e4a16
Mention RFC8152 for original COSE Algorithms registry
emlun Oct 5, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
57 changes: 32 additions & 25 deletions index.bs
View file
Open in desktop
Expand Up @@ -140,17 +140,21 @@ spec: ECMAScript; urlPrefix: https://tc39.github.io/ecma262/#
text: internal slot
text: own property; url: sec-own-property

spec: RFC8152; urlPrefix: https://tools.ietf.org/html/rfc8152
type: dfn
text: Section 7; url: section-7
text: Section 13.1; url: section-13.1
text: Section 8.1; url: section-8.1
text: kty; url: section-7.1
text: crv; url: section-13.1.1
text: COSE key; url: section-7
spec: RFC9052; urlPrefix: https://tools.ietf.org/html/rfc9052
type: dfn; for: RFC9052
text: COSE key; url: name-key-objects
text: kty; url: name-cose-key-common-parameters
text: section 7; url: section-7

spec: RFC9053; urlPrefix: https://tools.ietf.org/html/rfc9053
type: dfn; for: RFC9053
text: crv; url: name-double-coordinate-curves
text: section 2.1; url: section-2.1
text: section 2; url: section-2
text: section 7.1; url: section-7.1

spec: RFC8230; urlPrefix: https://tools.ietf.org/html/rfc8230
type: dfn
type: dfn; for: RFC8230
text: Section 4; url: section-4
text: Section 2; url: section-2

Expand Down Expand Up @@ -230,13 +234,13 @@ spec: FIDO-APPID; urlPrefix: https://fidoalliance.org/specs/fido-v2.0-id-2018022
text: determining if a caller's FacetID is authorized for an AppID; url: determining-if-a-caller-s-facetid-is-authorized-for-an-appid

spec: FIDO-U2F-Message-Formats; urlPrefix: https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-raw-message-formats-v1.1-id-20160915.html
type: dfn
type: dfn; for: FIDO-U2F-Message-Formats
text: application parameter; url: authentication-request-message---u2f_authenticate
text: Section 4.3; url: registration-response-message-success
text: Section 5.4; url: authentication-response-message-success

spec: FIDO-Registry; urlPrefix: https://fidoalliance.org/specs/common-specs/fido-registry-v2.1-ps-20191217.html
type: dfn
type: dfn; for: FIDO-Registry
text: Section 3.1 User Verification Methods; url: user-verification-methods
text: Section 3.2 Key Protection Types; url: key-protection-types
text: Section 3.3 Matcher Protection Types; url: matcher-protection-types
Expand Down Expand Up @@ -879,7 +883,8 @@ below and in [[#index-defined-elsewhere]].
:: This specification describes the syntax of all [=CBOR=]-encoded data using the CBOR Data Definition Language (<dfn>CDDL</dfn>) [[!RFC8610]].

: COSE
:: CBOR Object Signing and Encryption (COSE) [[!RFC8152]]. The IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]] established by this specification is also used.
:: CBOR Object Signing and Encryption (COSE) [[!RFC9052]] [[!RFC9053]].
The IANA COSE Algorithms registry [[!IANA-COSE-ALGS-REG]] originally established by [[!RFC8152 obsolete]] and updated by these specifications is also used.

: Credential Management
:: The API described in this document is an extension of the {{Credential}} concept defined in [[!CREDENTIAL-MANAGEMENT-1]].
Expand Down Expand Up @@ -2759,7 +2764,7 @@ during registration.

#### Easily accessing credential data #### {#sctn-public-key-easy}

Every user of the {{PublicKeyCredential/[[Create]](origin, options, sameOriginWithAncestors)}} method will need to parse and store the returned [=credential public key=] in order to verify future [=authentication assertions=]. However, the [=credential public key=] is in [[!RFC8152]] (COSE) format, inside the [=credentialPublicKey=] member of the [=attestedCredentialData=], inside the [=authenticator data=], inside the [=attestation object=] conveyed by {{AuthenticatorAttestationResponse}}.{{AuthenticatorAttestationResponse/attestationObject}}. [=[RPS]=] wishing to use [=attestation=] are obliged to do the work of parsing the {{AuthenticatorAttestationResponse/attestationObject}} and obtaining the [=credential public key=] because that public key copy is the one the [=authenticator=] [signed](#signing-procedure). However, many valid WebAuthn use cases do not require [=attestation=]. For those uses, user agents can do the work of parsing, expose the [=authenticator data=] directly, and translate the [=credential public key=] into a more convenient format.
Every user of the {{PublicKeyCredential/[[Create]](origin, options, sameOriginWithAncestors)}} method will need to parse and store the returned [=credential public key=] in order to verify future [=authentication assertions=]. However, the [=credential public key=] is in COSE format [[!RFC9052]], inside the [=credentialPublicKey=] member of the [=attestedCredentialData=], inside the [=authenticator data=], inside the [=attestation object=] conveyed by {{AuthenticatorAttestationResponse}}.{{AuthenticatorAttestationResponse/attestationObject}}. [=[RPS]=] wishing to use [=attestation=] are obliged to do the work of parsing the {{AuthenticatorAttestationResponse/attestationObject}} and obtaining the [=credential public key=] because that public key copy is the one the [=authenticator=] [signed](#signing-procedure). However, many valid WebAuthn use cases do not require [=attestation=]. For those uses, user agents can do the work of parsing, expose the [=authenticator data=] directly, and translate the [=credential public key=] into a more convenient format.

The {{AuthenticatorAttestationResponse/getPublicKey()}} operation thus returns the [=credential public key=] as a [=SubjectPublicKeyInfo=]. This {{ArrayBuffer}} can, for example, be passed to Java's `java.security.spec.X509EncodedKeySpec`, .NET's `System.Security.Cryptography.ECDsa.ImportSubjectPublicKeyInfo`, or Go's `crypto/x509.ParsePKIXPublicKey`.

Expand Down Expand Up @@ -3668,6 +3673,8 @@ Note: The {{AuthenticatorTransport}} enumeration is deliberately not referenced,
1. Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the [=crv=] parameter and MUST NOT use the compressed point form.
1. Keys with algorithm ES512 (-36) MUST specify P-521 (3) as the [=crv=] parameter and MUST NOT use the compressed point form.
1. Keys with algorithm EdDSA (-8) MUST specify Ed25519 (6) as the [=crv=] parameter. (These always use a compressed form in COSE.)

These restrictions align with the recommendation in [=Section 2.1=] of [[!RFC9053]].
</div>

Note: There are many checks neccessary to correctly implement signature verification using these algorithms. One of these is that, when processing uncompressed elliptic-curve points, implementations should check that the point is actually on the curve. This check is highlighted because it's judged to be at particular risk of falling through the gap between a cryptographic library and other code.
Expand Down Expand Up @@ -3928,7 +3935,7 @@ the requested [=public key credential|credential=] is [=scoped=] to exactly matc
The [=attested credential data=] (which is only present if the [=AT=] [=flag=] is set) describes its own length. If the [=authData/flags/ED=] [=flag=] is set, then the total length is 37 bytes plus the length of the [=attested credential data=] (if the [=AT=] [=flag=] is set), plus the length of the [=authData/extensions=] output (a [=CBOR=] map) that
follows.

Determining [=attested credential data=]'s length, which is variable, involves determining <code>[=credentialPublicKey=]</code>'s beginning location given the preceding <code>[=credentialid|credentialId=]</code>'s [=credentialidlength|length=], and then determining the <code>[=credentialPublicKey=]</code>'s length (see also [=Section 7=] of [[!RFC8152]]).
Determining [=attested credential data=]'s length, which is variable, involves determining <code>[=credentialPublicKey=]</code>'s beginning location given the preceding <code>[=credentialid|credentialId=]</code>'s [=credentialidlength|length=], and then determining the <code>[=credentialPublicKey=]</code>'s length (see also [=Section 7=] of [[!RFC9052]]).
</div>

### <dfn>Signature Counter</dfn> Considerations ### {#sctn-sign-counter}
Expand Down Expand Up @@ -4721,12 +4728,12 @@ object=] for a given credential. Its format is shown in <a href="#table-attested
<td>variable</td>
<td>
The [=credential public key=] encoded in COSE_Key format,
as defined in [=Section 7=] of [[!RFC8152]], using the [=CTAP2 canonical CBOR encoding form=].
as defined in [=Section 7=] of [[!RFC9052]], using the [=CTAP2 canonical CBOR encoding form=].
The COSE_Key-encoded [=credential public key=] MUST contain the "alg" parameter and MUST NOT
contain any other OPTIONAL parameters. The "alg" parameter MUST contain a {{COSEAlgorithmIdentifier}} value.
The encoded [=credential public key=] MUST also contain any additional REQUIRED parameters stipulated by the
relevant key type specification, i.e., REQUIRED for the key type "kty" and algorithm "alg" (see Section 8 of
[[!RFC8152]]).
relevant key type specification, i.e., REQUIRED for the key type "kty" and algorithm "alg"
(see [=RFC9053/Section 2=] of [[!RFC9053]]).
</td>
</tr>
</table>
Expand All @@ -4741,13 +4748,13 @@ object=] for a given credential. Its format is shown in <a href="#table-attested
This section provides examples of COSE_Key-encoded Elliptic Curve and RSA public keys for the ES256, PS256, and RS256
signature algorithms. These examples adhere to the rules defined above for the [=credentialPublicKey=] value, and are presented in CDDL [[!RFC8610]] for clarity.

[[!RFC8152]] [=Section 7=] defines the general framework for all COSE_Key-encoded keys.
Specific key types for specific algorithms are defined in other sections of [[!RFC8152]] as well as in other specifications,
[=Section 7=] of [[!RFC9052]] defines the general framework for all COSE_Key-encoded keys.
Specific key types for specific algorithms are defined in [[!RFC9053]] as well as in other specifications,
as noted below.

Below is an example of a COSE_Key-encoded Elliptic Curve public key in EC2 format (see [[!RFC8152]]
[=Section 13.1=]), on the P-256 curve, to be used with the ES256 signature
algorithm (ECDSA w/ SHA-256, see [[!RFC8152]] [=Section 8.1=]:
Below is an example of a COSE_Key-encoded Elliptic Curve public key in EC2 format (see [=Section 7.1=] of [[!RFC9053]]),
on the P-256 curve, to be used with the ES256 signature
algorithm (ECDSA w/ SHA-256, see [=Section 2.1=] of [[!RFC9053]]):

<pre class="example" highlight="json">
{
Expand Down Expand Up @@ -4780,7 +4787,7 @@ are included here for clarity and to match the CDDL [[!RFC8610]] presentation ab

Below is an example of a COSE_Key-encoded 2048-bit RSA public key (see [[RFC8230]] [=Section 4=],
to be used with the PS256 signature algorithm
(RSASSA-PSS with SHA-256, see [[RFC8230]] [=Section 2=]:
(RSASSA-PSS with SHA-256, see [=RFC8230/Section 2=] of [[RFC8230]]:

<pre class="example" highlight="json">
{
Expand Down Expand Up @@ -4948,7 +4955,7 @@ the [=authenticator=] MUST:

It is RECOMMENDED that any new attestation formats defined not use ASN.1 encodings,
but instead represent signatures as equivalent fixed-length byte arrays without internal structure,
using the same representations as used by COSE signatures as defined in [[!RFC8152]] and [[!RFC8230]].
using the same representations as used by COSE signatures as defined in [[!RFC9053]] and [[!RFC8230]].

The below signature format definitions satisfy this requirement and serve as examples for deriving the same for other signature algorithms not explicitly mentioned here:

Expand Down Expand Up @@ -5729,7 +5736,7 @@ This attestation statement format is used with FIDO U2F authenticators using the
key over the P-256 curve, terminate this algorithm and return an appropriate error.
1. Extract the claimed |rpIdHash| from |authenticatorData|, and the claimed |credentialId| and |credentialPublicKey| from
|authenticatorData|.<code>[=attestedCredentialData=]</code>.
1. Convert the COSE_KEY formatted |credentialPublicKey| (see [=Section 7=] of [[!RFC8152]]) to Raw ANSI X9.62 public key
1. Convert the COSE_KEY formatted |credentialPublicKey| (see [=Section 7=] of [[!RFC9052]]) to Raw ANSI X9.62 public key
format (see ALG_KEY_ECC_X962_RAW in [=Section 3.6.2 Public Key Representation Formats=] of [[!FIDO-Registry]]).
- Let |x| be the value corresponding to the "-2" key (representing x coordinate) in |credentialPublicKey|, and confirm its
size to be of 32 bytes.
Expand Down