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

Allow platform-based self attestation with non-zero AAGUID when AttestationConveyancePreferenceOption "none" is used #2146

Open
zacknewman opened this issue Sep 11, 2024 · 3 comments · May be fixed by #2150

Comments

@zacknewman
Copy link
Contributor

In L3 platform-based authenticators are allowed AAGUIDs that are not all-zero even when credentialCreationData.attestationConveyancePreferenceOption is "none". As a result, there is no additional privacy obtained by replacing self attestation with none attestation. Specifically the steps describing constructCredentialAlg in § 5.1.3. should be changed from:

  1. If the aaguid in the attested credential data is 16 zero bytes, credentialCreationData.attestationObjectResult.fmt is "packed", and "x5c" is absent from credentialCreationData.attestationObjectResult, then self attestation is being used and no further action is needed.

to

  1. If the aaguid in the attested credential data is 16 zero bytes or authenticator is a platform authenticator, credentialCreationData.attestationObjectResult.fmt is "packed", and "x5c" is absent from credentialCreationData.attestationObjectResult, then self attestation is being used and no further action is needed.
@zacknewman
Copy link
Contributor Author

zacknewman commented Sep 12, 2024

Thinking of this more, if platform authenticators are excluded from the privacy-preserving practice of having their AAGUID replaced with all zeros when passed a "none" AttestationConveyancePreferenceOption, what is the point of replacing the attestation when self attestation is not used? Is AAGUID not strictly more privacy-disrespecting than any X.509 v3 certificate chain? Specifically, I'm thinking the following also seems to work:

  1. If authenticator is a platform authenticator, then no further action is needed.
  2. If the aaguid in the attested credential data is 16 zero bytes, credentialCreationData.attestationObjectResult.fmt is "packed", and "x5c" is absent from credentialCreationData.attestationObjectResult; then self attestation is being used and no further action is needed.

@pascoej
Copy link
Contributor

pascoej commented Sep 24, 2024

I think this is the same as #1962.

@zacknewman
Copy link
Contributor Author

zacknewman commented Sep 25, 2024

Yeah, I think it is. I didn't know #1962 was still open until after I opened this and submitted a PR. #2058 added:

  1. If authenticator is not a platform authenticator then replace the aaguid in the attested credential data with 16 zero bytes.

however that PR did not address the attestation aspect which #2150 does.

@nadalin nadalin added the @Risk Items that are at risk for L3 label Oct 30, 2024
@timcappalli timcappalli self-assigned this Nov 13, 2024
@timcappalli timcappalli removed the @Risk Items that are at risk for L3 label Nov 13, 2024
@timcappalli timcappalli added this to the Futures (catch-all) milestone Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants