Re: Proposal: Chrome privacy CA

On Tue, Nov 7, 2017 at 2:03 AM, Denis Pinkas <denis.w3c@free.fr> wrote:

> With the Privacy CA infrastructure, Google would be introducing a
> potential *spying component* in the model. The Privacy CA infrastructure
> would allow
> to gather information like the identity of the token vendors and the rate
> of use of such hardware tokens. That information could then be used to
> perform
> a market survey for the benefits of Google and/or be sold to some
> unspecified parties. Google would be the only one able to perform such a
> market survey.
>

If we could have viably implemented this as a non-interactive,
zero-knowledge proof in the browser, we would have done so, but I could not
make those numbers even close to viable. It would also add a substantial
burden to RPs trying to validate tokens.

Thus the amount of information provided to the Privacy CA is the minimum.
If the aggregate information about token popularity is considered sensitive
then the model of direct attestation by default would have given it to
essentially all non-trivial sites (and probably still will, since Chrome is
not the only browser). Presumably that wasn't considered a problem
previously.

You said: "*many RPs will ask for attestation just because they can*". No,
> this is not as simple. In order to verify a certificate attestation,
> the RP needs to get at least one root key per hardware token vendor and to
> make sure that the root keys are the right ones.
> Presently, there is no specification that tells them where from they can
> (securely) get these root keys.
>

I believe the MDS is intended to solve this problem. However, it is
currently significantly incomplete and so we believe that your expectation
of the problems is essentially accurate in the medium term.

Our worry is then that RPs will use ad-hoc and varying processes for
verifying tokens, which will not be updated over time. That will lead to a
poor user experience as different keys will function with different sites.
Attestation will also become a significant barrier to entry for future
token vendors who will need a multitude of sites to update their
attestation roots to accept their tokens.

While this might get sorted out over the course of years, it takes far less
time than that for a technology to acquire a poor reputation. Consumers
have a compelling interest in being able to select from a number of vendors
and to be reasonably sure that a purchased token will function across the
vast majority of sites.

The easiest for RPs will be to use self-attestations *and to verify these
> self-attestations* because with the current protocol this is currently
> the only way to get a proof of possession (PoP) of the private key at
> registration time.
>
> You also said: "*identify batches of tokens if revocation is ever needed*".
> In case of revocation, the first need is NOT to revoke a batch of tokens
> but to *revoke an individual token*. The Privacy CA model will be of no
> help to achieve such an objective.
>

Attestation certificates are required to be deployed in batches of at least
100K already, so identification and revocation of a specific token is
already a non-goal of FIDO.

That is a balance between the wider interests of common users (who do not
wish to have a tracking token) and the interests of closed, enterprise
deployments, who might like to be able to identify specific tokens, track
them in inventory systems etc. Item #5 in our requests attempts to
reconcile this a little differently and envisions a signal to tokens that
they are being used in a context where individual attestation is
appropriate, and might thus return a different, unique attestation
certificate. In Chrome, that signal would be wired up to our enterprise
policy to allow administrators to enable direct attestation for enumerated
RP IDs.


Cheers

AGL