Re: Follow-up on Privacy CA discussions.

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