Re: Follow-up on Privacy CA discussions.

 > On 11/11/17, 8:50 AM, "Adam Langley" <agl@google.com> wrote:
 >
 > Thank you for the frank discussion yesterday around the proposed
 > Privacy CA.

And thanks to you and your colleagues for listening to our various 
thoughts and concerns.

 > Chrome feels that the PR #636 3-value enum is valuable

Great, thanks.

 > and we very much hope that the vast majority of sites using webauthn
 > stick with the default and do not request attestation.

Agreed.

[...]> I’ve decided that when RPs request direct attestation using
 > that enum, Chrome plans on honouring that request by passing on the
 > actual attestation from the authenticator.

Great, thank you.
 > We are no longer requesting any changes to the CTAP2 specification.

Ok.

 > The discussion around proof-of-possession was interesting, however,
 > and we would certainly have no objection if a proof-of-possession
 > could be generated in the no-attestation case—maybe by adding that in
 > a future version of the specification.

Ok.

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


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


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


 > We continue to believe that the state of the MDS,

For readers who might not be familiar with the MDS (FIDO Metadata 
Service), see [2].

 > and the complexity
 > of verifying against it, will lead sites who wish to enforce
 > attestation towards solutions that are bad for the health of the
 > overall ecosystem and user experience. As an agent of the user,
 > Chrome cares deeply about such things.
 >
 > Since we will not be using a Privacy CA in the case that a site has
 > requested direct attestation, we are considering other plans to
 > ameliorate those concerns, such as denying attestation for any token
 > that’s not included in the MDS.

That sounds like an interesting idea for holding authenticator vendors 
accountable.

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?


 > We urge vendors to take the MDS more
 > seriously and preemptively eliminate the need for such measures.

Agreed. Perhaps a way we should think about the MDS is as "authenticator 
transparency" similar (in some high-level conceptual ways) to 
"certificate transparency"?

Thank you for your thoughts and considerations on all of this.

=JeffH

[1] FIDO Authenticator Certification
 
<https://fidoalliance.org/certification/authenticator-certification-levels/>


[2] FIDO Metadata Service
     <https://fidoalliance.org/mds/>
     <https://fido-mds-parser.appspot.com/>
 
<https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-metadata-service-v1.2-ps-20170411.html>

Received on Sunday, 12 November 2017 08:02:41 UTC