- From: Dirk Balfanz <balfanz@google.com>
- Date: Sat, 11 Nov 2017 23:37:42 +0000
- To: John Bradley <jbradley@yubico.com>, "Jeff Hodges (JeffH)" <Jeff.Hodges@kingsmountain.com>, Rolf Lindemann <rlindemann@noknok.com>, Jeffrey Yasskin <jyasskin@google.com>
- Cc: Adam Langley <agl@google.com>, W3C Web Authn WG <public-webauthn@w3.org>
- Message-ID: <CADHfa2DUm+pLv-e4CNYoeofHXwBZ9bnTeMvafuFsKKjHcqqxwQ@mail.gmail.com>
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 >> >>
Received on Saturday, 11 November 2017 23:38:18 UTC