Skip to content

Commit

Permalink
Merge pull request #2167 from w3c/issue-1711-ext-proc-before-sig-verify
Browse files Browse the repository at this point in the history 
Move extension processing to after signature verification, and modernize it
  • Loading branch information
@emlun
emlun authored Nov 13, 2024
2 parents 406ec42 + 34b98ec commit 92e1015
Showing 1 changed file with 48 additions and 44 deletions.
92 changes: 48 additions & 44 deletions index.bs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5784,7 +5784,7 @@ calling {{CredentialsContainer/create()|navigator.credentials.create()}} they se
[=attestation type=] as a part of [=verification procedure|verification=]. See the "Verification procedure" subsections of
[[#sctn-defined-attestation-formats]]. See also [[#sctn-attestation-privacy]]. For all [=attestation types=] defined in this
section other than [=self attestation|Self=] and [=None=], [=[RP]=] [=verification procedure|verification=] is followed by
matching the [=attestation trust path|trust path=] to an acceptable root certificate per [step 24](#reg-ceremony-assess-trust)
matching the [=attestation trust path|trust path=] to an acceptable root certificate per [step 23](#reg-ceremony-assess-trust)
of [[#sctn-registering-a-new-credential]].
Differentiating these [=attestation types=] becomes useful primarily as a means for determining if the [=attestation=] is acceptable
under [=[RP]=] policy.
Expand Down Expand Up @@ -5987,25 +5987,6 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
matches the {{PublicKeyCredentialParameters/alg}} attribute of one of the [=list/items=] in
<code>|pkOptions|.{{PublicKeyCredentialCreationOptions/pubKeyCredParams}}</code>.

<li id='reg-ceremony-verify-extension-outputs'>
Verify that the values of the [=client extension outputs=] in |clientExtensionResults| and the [=authenticator extension
outputs=] in the <code>[=authData/extensions=]</code> in |authData| are as expected, considering the [=client
extension input=] values that were given in <code>|pkOptions|.{{PublicKeyCredentialCreationOptions/extensions}}</code>
and any specific policy of the [=[RP]=] regarding unsolicited extensions, i.e., those that were not specified as part of
<code>|pkOptions|.{{PublicKeyCredentialCreationOptions/extensions}}</code>.
In the general case, the meaning of "are as expected" is specific to the [=[RP]=] and which extensions are in use.

Note: [=Client platforms=] MAY enact local policy that sets additional [=authenticator extensions=] or
[=client extensions=] and thus cause values to appear in the [=authenticator extension outputs=] or
[=client extension outputs=] that were not originally specified as part of
<code>|pkOptions|.{{PublicKeyCredentialCreationOptions/extensions}}</code>. [=[RPS]=] MUST be prepared to handle such
situations, whether it be to ignore the unsolicited extensions or reject the attestation. The [=[RP]=] can make this
decision based on local policy and the extensions in use.

Note: Since all extensions are OPTIONAL for both the [=client=] and the [=authenticator=], the [=[RP]=] MUST also be
prepared to handle cases where none or not all of the requested extensions were acted upon.
</li>

1. Determine the attestation statement format by performing a USASCII case-sensitive match on |fmt| against the set of
supported WebAuthn Attestation Statement Format Identifier values.
An up-to-date list of registered WebAuthn Attestation Statement Format Identifier values
Expand Down Expand Up @@ -6034,12 +6015,12 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
<!-- Note: this next step is actually a top-level step, but bikeshed wanted it indented this much in order to render it as
a numbered step. If outdented, it (today) is rendered as a bullet in the midst of a numbered list -->
<li id="reg-ceremony-assess-trust">
Assess the attestation trustworthiness using the outputs of the [=verification procedure=] in [step 22](#reg-ceremony-verify-attestation), as follows:
Assess the attestation trustworthiness using the outputs of the [=verification procedure=] in [step 21](#reg-ceremony-verify-attestation), as follows:
- If [=None|no attestation=] was provided, verify that [=None=] attestation is acceptable under [=[RP]=] policy.
- If [=self attestation=] was used, verify that [=self attestation=] is acceptable under [=[RP]=] policy.
- Otherwise, use the X.509 certificates returned as the [=attestation trust path=] from the [=verification procedure=]
to verify that the attestation public key either correctly chains up to an acceptable root certificate, or is itself an acceptable certificate
(i.e., it and the root certificate obtained in [step 23](#reg-ceremony-attestation-trust-anchors) may be the same).
(i.e., it and the root certificate obtained in [step 22](#reg-ceremony-attestation-trust-anchors) may be the same).
</li>

1. Verify that the <code>[=credentialId=]</code> is &le; 1023 bytes. Credential IDs larger than this many bytes SHOULD cause the RP to fail this [=registration ceremony=].
Expand Down Expand Up @@ -6100,7 +6081,28 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
</dl>
</li>

1. If the attestation statement |attStmt| successfully verified but is not trustworthy per [step 24](#reg-ceremony-assess-trust) above,
<!-- Note: this next step is actually a top-level step, but bikeshed wanted it indented this much in order to render it as a numbered step. If outdented, it (today) is rendered as a bullet in the midst of a numbered list -->
<li id='reg-ceremony-verify-extension-outputs'>
Process the [=client extension outputs=] in |clientExtensionResults|
and the [=authenticator extension outputs=] in the <code>[=authData/extensions=]</code> in |authData|
as required by the [=[RP]=].
Depending on each [=WebAuthn extensions|extension=],
processing steps may be concretely specified or it may be up to the [=[RP]=] what to do with extension outputs.
The [=[RP]=] MAY ignore any or all extension outputs.

[=Clients=] MAY set additional [=authenticator extensions=] or
[=client extensions=] and thus cause values to appear in the [=authenticator extension outputs=] or
[=client extension outputs=] that were not
requested by the [=[RP]=] in <code>|pkOptions|.{{PublicKeyCredentialCreationOptions/extensions}}</code>.
The [=[RP]=] MUST be prepared to handle such situations,
whether by ignoring the unsolicited extensions or by rejecting the attestation. The [=[RP]=] can make this
decision based on local policy and the extensions in use.

Since all extensions are OPTIONAL for both the [=client=] and the [=authenticator=], the [=[RP]=] MUST also be
prepared to handle cases where none or not all of the requested extensions were acted upon.
</li>

1. If the attestation statement |attStmt| successfully verified but is not trustworthy per [step 23](#reg-ceremony-assess-trust) above,
the [=[RP]=] SHOULD fail the [=registration ceremony=].

NOTE: However, if permitted by policy, the [=[RP]=] MAY register the [=credential ID=] and credential public key but treat the
Expand All @@ -6109,7 +6111,7 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
See [[FIDOSecRef]] and [[UAFProtocol]] for a more detailed discussion.

Verification of [=attestation objects=] requires that the [=[RP]=] has a trusted method of determining acceptable trust anchors
in [step 23](#reg-ceremony-attestation-trust-anchors) above.
in [step 22](#reg-ceremony-attestation-trust-anchors) above.
Also, if certificates are being used, the [=[RP]=] MUST have access to certificate status information for the
intermediate CA certificates. The [=[RP]=] MUST also be able to build the attestation certificate chain if the client did not
provide this chain in the attestation information.
Expand Down Expand Up @@ -6229,25 +6231,6 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o

Note: See [[#sctn-credential-backup]] for examples of how a [=[RP]=] might process the [=authData/flags/BS=] [=flag=] values.

<li id='authn-ceremony-verify-extension-outputs'>
Verify that the values of the [=client extension outputs=] in |clientExtensionResults| and the [=authenticator extension
outputs=] in the <code>[=authData/extensions=]</code> in |authData| are as expected, considering the [=client
extension input=] values that were given in <code>|pkOptions|.{{PublicKeyCredentialRequestOptions/extensions}}</code>
and any specific policy of the [=[RP]=] regarding unsolicited extensions, i.e., those that were not specified as part of
<code>|pkOptions|.{{PublicKeyCredentialRequestOptions/extensions}}</code>.
In the general case, the meaning of "are as expected" is specific to the [=[RP]=] and which extensions are in use.

Note: [=Client platforms=] MAY enact local policy that sets additional [=authenticator extensions=] or
[=client extensions=] and thus cause values to appear in the [=authenticator extension outputs=] or
[=client extension outputs=] that were not originally specified as part of
<code>|pkOptions|.{{PublicKeyCredentialRequestOptions/extensions}}</code>. [=[RPS]=] MUST be prepared to handle such
situations, whether it be to ignore the unsolicited extensions or reject the assertion. The [=[RP]=] can make this
decision based on local policy and the extensions in use.

Note: Since all extensions are OPTIONAL for both the [=client=] and the [=authenticator=], the [=[RP]=] MUST also be
prepared to handle cases where none or not all of the requested extensions were acted upon.
</li>

1. Let |hash| be the result of computing a hash over the |cData| using SHA-256.

1. Using <code>|credentialRecord|.[$credential record/publicKey$]</code>,
Expand Down Expand Up @@ -6296,6 +6279,27 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
the above state updates SHOULD be deferred to after those additional checks are completed successfully.
</li>

<!-- Note: this next step is actually a top-level step, but bikeshed wanted it indented this much in order to render it as a numbered step. If outdented, it (today) is rendered as a bullet in the midst of a numbered list -->
<li id='authn-ceremony-verify-extension-outputs'>
Process the [=client extension outputs=] in |clientExtensionResults|
and the [=authenticator extension outputs=] in the <code>[=authData/extensions=]</code> in |authData|
as required by the [=[RP]=].
Depending on each [=WebAuthn extensions|extension=],
processing steps may be concretely specified or it may be up to the [=[RP]=] what to do with extension outputs.
The [=[RP]=] MAY ignore any or all extension outputs.

[=Clients=] MAY set additional [=authenticator extensions=] or
[=client extensions=] and thus cause values to appear in the [=authenticator extension outputs=] or
[=client extension outputs=] that were not
requested by the [=[RP]=] in <code>|pkOptions|.{{PublicKeyCredentialRequestOptions/extensions}}</code>.
The [=[RP]=] MUST be prepared to handle such situations,
whether by ignoring the unsolicited extensions or by rejecting the assertion. The [=[RP]=] can make this
decision based on local policy and the extensions in use.

Since all extensions are OPTIONAL for both the [=client=] and the [=authenticator=], the [=[RP]=] MUST also be
prepared to handle cases where none or not all of the requested extensions were acted upon.
</li>

1. If all the above steps are successful, continue with the [=authentication ceremony=] as appropriate. Otherwise, fail the
[=authentication ceremony=].

Expand Down Expand Up @@ -7822,7 +7826,7 @@ However, [=authenticators=] that do not utilize [[!FIDO-CTAP]] do not necessaril
It occurs during extension processing in [step 12](#CreateCred-process-extensions) of {{PublicKeyCredential/[CREATE-METHOD]}}.
The {{AuthenticationExtensionsLargeBlobOutputs}} will be abandoned if no satisfactory authenticator becomes available.

1. If a [=create/candidate authenticator=] becomes available ([step 21](#CreateCred-async-loop) of {{PublicKeyCredential/[CREATE-METHOD]}}) then,
1. If a [=create/candidate authenticator=] becomes available ([step 22](#CreateCred-async-loop) of {{PublicKeyCredential/[CREATE-METHOD]}}) then,
before evaluating any <code>|options|</code>, [=iteration/continue=] (i.e. ignore the [=create/candidate authenticator=])
if the [=create/candidate authenticator=] is not capable of storing large blobs.
1. Otherwise (i.e. {{AuthenticationExtensionsLargeBlobInputs/support}} is absent or has the value {{LargeBlobSupport/preferred}}):
Expand Down

0 comments on commit 92e1015

Please sign in to comment.