Re: Proposal: Chrome privacy CA

Hi Christiaan,

Some extracts of the proposal:

"Many consumers services in reality don’t care about provenance of 
authenticators".

"We do acknowledge that there are other relying parties out there that 
have an obligation to ensure that
the authenticators they accept meet a certain security "(...).

"These relying parties rarely (if ever) have the need to uniquely 
identify authenticators or even authenticator vendors,
but rather are interested in being able to tell whether an authenticator 
conforms to some minimum requirement".


All these statements are fully correct, but the solution that is 
presented to address these statements is rather complex,
time consuming and mandates the deployment of another infrastructure 
(i.e. the Privacy CAs).

There is a simpler solution able to address the same concerns:

-For those RPs that need to know whether an authenticator conforms to 
some security and functional requirements,
the use of an attestation certificate will be required.

-For those RPs that don't need to know whether an authenticator conforms 
to some security and functional requirements,
the use of an self-signed certificate will be required.

This means that a given hardware authenticator should be able to 
support, upon the request from the user or the client,
either an attestation certificate or a self-signed certificate.

There would be no need to introduce the concept of an "enterprise 
environment".

There would be no need to support Privacy CAs.

This would eliminate privacy concerns with the Privacy CA which would 
otherwise be able to gather information
about the use of the authenticators. This would also eliminate 
bottlenecks to the Privacy CAs.

The third sentence from the extract states:

These relying parties rarely (if ever) have the need to *uniquely* 
*identify* authenticators.

As soon as the use of attestation certificates will be limited to RPs 
that really have the need to know that an authenticator
conforms to some security and functional requirements, it will be 
possible to avoid batch certificates and to allow authenticators
to be individually revoked.

It should be observed that RPs that need to know whether an 
authenticator conforms to some security and functional requirements
usually already "know their customers" with their family name, first 
name, address and even birth date, so using an hardware authenticator
that can be individually identified would not be a major problem.

This would simplify the overall model rather than adding an extra level 
of complexity.

Denis


> Hi folks,
>
> Please see attached a proposal from Google regarding the "Privacy CA" 
> model that Chrome will be adopting. The idea is to open this up for 
> discussion (maybe on the call today, but definitely at TPAC next week).
>
> Please note that this document is a WIP, but I wanted to make sure we 
> give everyone an early glimpse into our thinking so we could refine 
> the proposal as we go along while making sure we have the necessary 
> plumbing in WebAuthN to support this model.
>
> I'll also be cross-posting this to the FIDO2 TWG.
>
> Regards,
> Christiaan