W3C home > Mailing lists > Public > public-webauthn@w3.org > November 2017

Re: Follow-up on Privacy CA discussions.

From: Adam Langley <agl@google.com>
Date: Mon, 13 Nov 2017 08:16:03 -0800
Message-ID: <CAL9PXLz+y3tKmiHO-Zy7p8UWasB03Pn2YEJGoQuLGgAfKxyk5w@mail.gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Cc: W3C Web Authn WG <public-webauthn@w3.org>
On Sun, Nov 12, 2017 at 12:02 AM, =JeffH <Jeff.Hodges@kingsmountain.com>

> > We are aware of tokens on the market today that do not appear to be
> > complying with the 100K batch rules for attestation certificates.
> I wonder whether any of these authenticators are "FIDO Certified"?
> Providing your testing results back to the FIDO Authenticator Certification
> program [1] would be a good ecosystem deed, I suspect. As would the
> certification program being able to make use of such information.

They claim to be. I have several additional tests that FIDO might wish to

> > We expect to be establishing a Chrome policy around security keys
> > and, based on that policy, blocklisting such tokens to solve the
> > resulting privacy problem. Thus such tokens can expect to have their
> > attestation certificates replaced with a random certificate. (This
> > random certificate will be generated within the Chrome process, not
> > via a Privacy CA).
> Hm. Absent such authenticator testing and assessment data being shared
> with all ecosystem participants, this sounds like Chrome&Android would be
> unilaterally behaving differently than other participants (e.g., other
> browser/platforms may or may not also "blind" such attestation
> certificates). I am not sure we would be comfortable with that.

Tokens are not supposed to be tracking devices. I would recommend that all
browsers protect their users from these tokens and our blocklist will
obviously be public (being open-source and all). But I cannot speak for
other browser's policies.

> If a site has requested direct attestation in such a case, the
> > request will fail.
> Are you saying here that Chrome will unilaterally fail the operation in
> this case, or that you advise Webauthn Relying Parties to fail the
> operation?
> We as a Relying Party would very much prefer to ourselves make the
> decision whether to fail the operation in such a case. We have requested
> "direct attestation", but have not stipulated a "level of assurance (LOA)"
> for the webauthn client (browser/platform) to _enforce_ on our behalf.
> Receiving "blinded attestation certificates", in such a direct attestation
> case, would be ok (I am thinking) if the blinding justification is publicly
> available and this behavior is openly specified such that all
> browsers/platforms have the opportunity to behave in the same manner.
> Having the blinded certificate identify themselves as such would be helpful
> it seems.

Ok, thanks for the input.

> By "denying attestation" do you mean "blinding" the attestation
> certificate (aka substituting a "random certificate") as discussed above?
> Or do you mean failing the operation?

I mean that Chrome is considering substituting a random certificate (or
similar behaviour that doesn't pass the token's attestation on). Whether
the operation fails I imagine would be consistent with our behaviour for
tokens with inappropriately identifying certificates. Above I suggested
that sites requesting direct attestation would only ever receive direct
attestation and so the request would fail in that case. You've suggested
that you would prefer a best-effort behaviour, which is a useful data point
so I think that has moved back to being an open question.


Received on Monday, 13 November 2017 16:16:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:44 UTC