AW: Follow-up on Privacy CA discussions.

I have added my comments.

 

Von: Dirk Balfanz [mailto:balfanz@google.com] 
Gesendet: Sonntag, 12. November 2017 00:38
An: John Bradley; Jeff Hodges (JeffH); Rolf Lindemann; Jeffrey Yasskin
Cc: Adam Langley; W3C Web Authn WG
Betreff: Re: Follow-up on Privacy CA discussions.

 

H there, 

 

I updated PR 636 according to this consensus: https://github.com/w3c/webauthn/pull/636

 

Jeff, Rolf - can you take another look?

 

Jeffrey Y - can you take a look at the client processing rules I added? I'm not sure I'm doing that right.

 

Dirk

 

On Sat, Nov 11, 2017 at 9:39 AM John Bradley <jbradley@yubico.com> wrote:

Thanks Adam.  

 

I do also agree that developing a improved attestation format for a future release of CTAP eg 2.1 should also be on the table.  We have a bunch of formats now as it is.  

 

I think a format that contains a self signed part without the AAGUID, and a separate cert or JWS signed by the batch cert containing the public key and AAGUID may have advantages without significant overhead.  

 

I am happy to work on that with you.  

 

Regards 

John B.

 

On Nov 10, 2017 4:52 PM, "Adam Langley" <agl@google.com> wrote:

Dear all,

 

Thank you for the frank discussion yesterday around the proposed Privacy CA. Chrome feels that the PR #636 3-value enum is valuable and we very much hope that the vast majority of sites using webauthn stick with the default and do not request attestation. The web has a tradition of openness where the barrier to entry was simply implementing the specs and departing from that with attestation should give pause to anyone at the W3C.

 

In light of the lack of support from other browsers and other factors, 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.

 

We are no longer requesting any changes to the CTAP2 specification. 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.

 

We are aware of tokens on the market today that do not appear to be complying with the 100K batch rules for attestation certificates. 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). If a site has requested direct attestation in such a case, the request will fail.

 

We continue to believe that the state of the MDS, 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. We urge vendors to take the MDS more seriously and preemptively eliminate the need for such measures.

 

 

Thank you

 

AGL