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

Move extension processing to after signature verification, and modernize it #2167

Merged
merged 6 commits into from
Nov 13, 2024
Merged

Move extension processing to after signature verification, and modernize it #2167

Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
3fb838e
Move extension processing to after signature verification
emlun Oct 1, 2024
cf7202b
Fix reference to step 22 in Create()
emlun Oct 1, 2024
1ba9322
Modernize extension processing step of RP ops
emlun Oct 1, 2024
560fe0e
Remove NOTE from normative caveats on extension processing
emlun Oct 1, 2024
4866b13
Fix reference to extensions input in get()
emlun Oct 1, 2024
34b98ec
Merge branch 'main' into issue-1711-ext-proc-before-sig-verify
emlun Nov 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 48 additions & 44 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5775,7 +5775,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 @@ -5974,25 +5974,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 @@ -6021,12 +6002,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 @@ -6079,7 +6060,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 @@ -6088,7 +6090,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 @@ -6205,25 +6207,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 @@ -6265,6 +6248,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 @@ -7568,7 +7572,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]]()}}.
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]]()}}) then,
1. If a [=create/candidate authenticator=] becomes available ([step 22](#CreateCred-async-loop) of {{PublicKeyCredential/[[Create]]()}}) 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