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