Follow-up on Privacy CA discussions.

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