Re: Follow-up on Privacy CA discussions.

On Sun, Nov 12, 2017 at 12:02 AM, =JeffH <Jeff.Hodges@kingsmountain.com>
wrote:

> > 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
consider.


> > 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.


Cheers

AGL