Re: Proposal: Chrome privacy CA

On Wed, Nov 8, 2017 at 9:02 AM, Denis Pinkas <denis.w3c@free.fr> wrote:

> By default, self-attestations should be used. So nothing at all would be
> given away. This is what comes out when you apply "Privacy by Design" and
> "Privacy by Default" rules.
>

By "self-attestation" I'm assuming that you have in mind that the private
key itself signs the registration data, as opposed to some attestation key
in the token. This would show possession of the private key.

However, no U2F device that I'm aware of does this and the CTAP2 spec
doesn't have this either, I think. So, while I'd be very happy for tokens
to do that by default, that ship may have sailed.

But we might agree that privacy by default makes sense. Our requests (2)
and (3) say that, by default, RPs should not get attestation data. In that
case, no information need be sent to any Privacy CA.


> Revocation of a specific token is currently impossible in FIDO since all
> RPs are considered to be equal. If you remove this equality, then a new
> bunch of possibilities emerges.
> So saying that is is a "non-goal of FIDO" may not be an appropriate
> statement. From a functional point of view, it would be nice to be able to
> revoke a specific token
> and this is possible as soon as you introduce a distinction between :
>
>    - RPs that need to know whether an authenticator conforms to some
>    security and functional requirements,
>    and in this case the use of an attestation certificate will be
>    required.
>
>    - RPs that don't need to know whether an authenticator conforms to
>    some security and functional requirements,
>    and in this case the use of an self-signed certificate will be
>    required.
>
> This means that a given hardware token should be able either to generate a
> self-signed certificate or to use its attestation certificate upon the
> request from the client.
>

I think we're in agreement there, although we do have to deal with the
existing population of tokens in the world. Thus we're asking for a flag
from RPs to indicate which of those two groups that they're in (point #5)
and we'll have Chrome generate a dummy attestation certificate for RPs that
don't care about requirements. That's not as good as having the token sign
the registration message with the registration private key, but it's the
best that we can do with the current population of tokens. If CTAP2 were to
define a "no-op" attestation form that tokens would use on request, we
would happy with that.

If you want to remain compatible with the current situation, you always
> request the use of an attestation certificate, ... if some way or another
> you know that the same certificate is being used for a batch of at least
> 100K tokens. BTW, today there is no mean being defined to know whether the
> attestation certificate
> applies to a single token or a batch of tokens.
>
> Making the distinction between two kinds of RPs opens the door to new
> possibilities, in particular, the revocation of a specific token.
>
> 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.
>
>
> The balance is simply not between two parties (common users and RPs) but
> between three parties :
>
>    - common users,
>    - RPs that need to know whether an authenticator conforms to some
>    security and functional requirements, and
>    - RPs that don't need to know whether an authenticator conforms to
>    some security and functional requirements.
>
> 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.
>
>
> By default, the use of an attestation certificate (whether unique or
> shared) would be inappropriate. By exception (i.e. upon request), it would
> be.
>
> In Chrome, that signal would be wired up to our enterprise policy to allow
> administrators to enable direct attestation for enumerated RP IDs.
>
>
> FIDO is intended to be usable on the Internet, I mean not only within an
> enterprise environment.
> Within an enterprise environment the added value of FIDO will be "ease of
> use" and "security", it will not be "privacy".
> Within an enterprise environment privacy is not the major concern, but on
> the Internet it is.
>

I do not object to any of that. While I don't think tokens should use
individual attestation certificates by default (because not all browsers
will use a Privacy CA in all likelihood), we've no problem with them doing
so when signalled that they're in an enterprise environment.


Cheers

AGL