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.

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

Resolve conflicts between spk (#1957) and PR #1970 #1996

Closed
wants to merge 2 commits into from

Conversation

emlun
Copy link
Member

@emlun emlun commented Nov 15, 2023

PR #1970 made [=AAGUID=] autolinks ambiguous, requiring them to be disamgiguated as either [=AAGUID=] or [=authData/attestedCredentialData/aaguid=]. This PR resolves the conflicts with PR #1957 caused by this.

Conflicts:

diff --git a/index.bs b/index.bs
index 2ea7e3d..966772e 100644
--- a/index.bs
+++ b/index.bs
@@ -7356,9 +7356,17 @@ The weight that [=[RPS]=] give to the presence of a signature from a supplementa
 
     1. [=map/For each=] |scope| in |scopes|:
 
+<<<<<<< HEAD
         1. If a supplemental key with scope |scope| does not already exist for this {[=public key credential source/id|Credential ID=], [=public key credential source/rpId|RP ID=], [=public key credential source/rpId|userHandle=]} tuple on the [=authenticator=], create it using the same public key algorithm as that used by the [=user credential=]'s [=credential key pair=], otherwise locate the existing supplemental key.
 
         1. Let |attFormat| be the chosen [=attestation statement format=], and |attAaguid| be a 16-byte value, based on the value of {{AuthenticationExtensionsSupplementalPublicKeysInputs/attestation}} in the extension input:
+=======
+            : indirect, direct
+            :: |attFormat| is an [=attestation statement format=] appropriate for this [=authenticator=] based on {{AuthenticationExtensionsDevicePublicKeyInputs/attestationFormats}}, and |attAaguid| is the [=authenticator's=] [=/AAGUID=]. (Since the [=hardware-bound device key pair=] is specific to a particular authenticator, its attestation can be tied to hardware roots of trust, although they do not have to be. This is in contrast to the associated [=user credential=]'s attestation, if it is a [=multi-device credential=].)
+
+            : enterprise
+            :: The [=[RP]=] wants to receive an [=attestation statement=] that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. [=Authenticators=] MUST NOT provide such an attestation unless the user agent or authenticator configuration expressly permits it for the requested [=RP ID=]. If <i>not</i> permitted, then |attFormat| is "none" and |attAaguid| is 16 zero bytes. Otherwise |attFormat| is an [=attestation statement format=] appropriate for this [=authenticator=] based on {{AuthenticationExtensionsDevicePublicKeyInputs/attestationFormats}}, and |attAaguid| is the [=authenticator's=] [=/AAGUID=]. (Again, since the [=hardware-bound device key pair=] is specific to a particular authenticator, the attestation may be tied to hardware roots of trust.)
+>>>>>>> main
 
             <dl class="switch">
                 : none
@@ -7403,7 +7411,11 @@ The weight that [=[RPS]=] give to the presence of a signature from a supplementa
 
         1. Let |spkSig| be the result of signing the [=assertion signature=] [input](#fig-signature) with the supplemental private key.
 
+<<<<<<< HEAD
             Note: the [=assertion signature=] [input](#fig-signature), and thus |spkSig|, covers the [=[RP]=]'s {{PublicKeyCredentialCreationOptions/challenge}} because it includes the [=hash of the serialized client data=]. Thus the [=[RP]=] knows that |spkSig| is a fresh signature.
+=======
+The [=/AAGUID=] included in the <code>[=devicePubKey=]</code> extension output, if non-zero, identifies the make or model of hardware that is storing the [=device-bound key=]. This is distinct from the [=authData/attestedCredentialData/aaguid=] in the [=attested credential data=] of a [=multi-device credential=], which likely identifies something broader since such credentials are not bound to a single device. Thus the two AAGUIDs MAY be different in a single response and either, or both, may be zero depending on the options requested and authenticator behaviour.
+>>>>>>> main
 
         1. Append |spkSig| to |spkSigs|.
 
@@ -7445,8 +7457,13 @@ The [=supplementalPubKeys=] extension adds the following [=struct/item=] to [=cr
 
         <dl dfn-for="supplementalPubKeys record" dfn-type="abstract-op">
             :   <dfn>aaguid</dfn>
+<<<<<<< HEAD
             ::  The [=AAGUID=] included with the supplemental public key.
                 This MAY be different from the [=AAGUID=] in the [$credential record/attestationObject$], if any, of the containing [=credential record=].
+=======
+            ::  The [=/AAGUID=] of the [=device-bound key=]'s [=managing authenticator=].
+                This MAY be different from the [=authData/attestedCredentialData/aaguid=] in the [$credential record/attestationObject$], if any, of the containing [=credential record=].
+>>>>>>> main
 
             :   <dfn>spk</dfn>
             ::  The public key portion of the supplemental public key.

Resolution:

diff --git a/index.bs b/index.bs
index c0fc031..fe14aee 100644
--- a/index.bs
+++ b/index.bs
@@ -7291,10 +7365,10 @@ The weight that [=[RPS]=] give to the presence of a signature from a supplementa
                 :: |attFormat| is "none" or "self", at the authenticator's discretion, and |attAaguid| is 16 zero bytes. (Note that, since the [=supplemental public key=] is already exercised during {{CredentialsContainer/create()|navigator.credentials.create()}} calls, the proof-of-possession property provided by "self" attestation is superfluous in that context.)
 
                 : indirect, direct
-                :: |attFormat| is an [=attestation statement format=] appropriate for this [=authenticator=] based on {{AuthenticationExtensionsSupplementalPublicKeysInputs/attestationFormats}}, and |attAaguid| is the corresponding [=AAGUID=], which MAY be the [=authenticator's=] AAGUID. (Since the [=supplemental public key=]'s scope is different from the [=user credential=], it will often have a different attestation. For example, the attestation for a [=supplemental public key=] with &ldquo;device&rdquo; scope can be tied to hardware roots of trust, although it does not have to be.)
+                :: |attFormat| is an [=attestation statement format=] appropriate for this [=authenticator=] based on {{AuthenticationExtensionsSupplementalPublicKeysInputs/attestationFormats}}, and |attAaguid| is the corresponding [=/AAGUID=], which MAY be the [=authenticator's=] AAGUID. (Since the [=supplemental public key=]'s scope is different from the [=user credential=], it will often have a different attestation. For example, the attestation for a [=supplemental public key=] with &ldquo;device&rdquo; scope can be tied to hardware roots of trust, although it does not have to be.)
 
                 : enterprise
-                :: The [=[RP]=] wants to receive an [=attestation statement=] that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. [=Authenticators=] MUST NOT provide such an attestation unless the user agent or authenticator configuration expressly permits it for the requested [=RP ID=]. If <i>not</i> permitted, then follow the steps for `direct` attestation. Otherwise |attFormat| is an [=attestation statement format=] appropriate for this [=authenticator=] based on {{AuthenticationExtensionsSupplementalPublicKeysInputs/attestationFormats}}, and |attAaguid| is the corresponding [=AAGUID=], which MAY be the [=authenticator's=] AAGUID.
+                :: The [=[RP]=] wants to receive an [=attestation statement=] that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. [=Authenticators=] MUST NOT provide such an attestation unless the user agent or authenticator configuration expressly permits it for the requested [=RP ID=]. If <i>not</i> permitted, then follow the steps for `direct` attestation. Otherwise |attFormat| is an [=attestation statement format=] appropriate for this [=authenticator=] based on {{AuthenticationExtensionsSupplementalPublicKeysInputs/attestationFormats}}, and |attAaguid| is the corresponding [=/AAGUID=], which MAY be the [=authenticator's=] AAGUID.
 
                     Note: CTAP2 does not currently provide for an <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#makecred-enterpriseattestation">enterpriseAttestation</a> signal during an <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#authenticatorGetAssertion">authenticatorGetAssertion</a> call. Until that is changed, <a href="https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#platform-managed-enterprise-attestation">platform-managed enterprise attestation</a> will not work in that context with CTAP2 [=authenticators=].
             </dl>
@@ -7341,7 +7415,7 @@ The weight that [=[RPS]=] give to the presence of a signature from a supplementa
 
 ##### AAGUIDs ##### {#sctn-supplemental-public-keys-attestation-aaguid}
 
-The [=AAGUID=] included in the <code>[=supplementalPubKeys=]</code> extension output, if non-zero, aids a [=[RP]=] in validating the [=attestation statement=] of the supplemental public key. Its interpretation depends on the scope of the key. It may differ from the [=AAGUID=] in the [=attested credential data=] of a [=multi-device credential=]. Thus the AAGUID of [=supplemental public key=] MAY be different in a single response and either, or both, may be zero depending on the options requested and authenticator behaviour.
+The [=/AAGUID=] included in the <code>[=supplementalPubKeys=]</code> extension output, if non-zero, aids a [=[RP]=] in validating the [=attestation statement=] of the supplemental public key. Its interpretation depends on the scope of the key. It may differ from the [=authData/attestedCredentialData/aaguid=] in the [=attested credential data=] of a [=multi-device credential=]. Thus the AAGUID of [=supplemental public key=] MAY be different in a single response and either, or both, may be zero depending on the options requested and authenticator behaviour.
 
 ##### Attestation calculations ##### {#sctn-supplemental-public-keys-attestation-calculations}
 
@@ -7371,8 +7445,8 @@ The [=supplementalPubKeys=] extension adds the following [=struct/item=] to [=cr
 
         <dl dfn-for="supplementalPubKeys record" dfn-type="abstract-op">
             :   <dfn>aaguid</dfn>
-            ::  The [=AAGUID=] included with the supplemental public key.
-                This MAY be different from the [=AAGUID=] in the [$credential record/attestationObject$], if any, of the containing [=credential record=].
+            ::  The [=/AAGUID=] included with the supplemental public key.
+                This MAY be different from the [=authData/attestedCredentialData/aaguid=] in the [$credential record/attestationObject$], if any, of the containing [=credential record=].
 
             :   <dfn>spk</dfn>
             ::  The public key portion of the supplemental public key.

Preview | Diff

@emlun emlun added the process:meta-pr Pull requests into other pull requests rather than main label Nov 15, 2023
@emlun emlun requested a review from agl November 15, 2023 13:27
Base automatically changed from spk to main November 15, 2023 22:20
@emlun
Copy link
Member Author

emlun commented Nov 16, 2023

Obsoleted by commits 462113c, b2cba32 and e168d78 in #1957.

@emlun emlun closed this Nov 16, 2023
@emlun emlun deleted the spk-pr-1970-conflicts branch November 16, 2023 12:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
process:meta-pr Pull requests into other pull requests rather than main
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant