Re: Privacy (was: "")

Mo,

> What I'm envisaging is along the lines of…
> 
> * Everybody has a long term self-signed CA cert, looked after
>   primarily by OS (or in some cases browser)-level tools ‚Äî along the
>   lines of a ‚ÄúMac OS X Keychain or GNOME Keyring on steroids‚Äù
> 
> * The long term CA is used to issue shorter-lifetime browser and
>   device certificates, which includes an attribute to indicate that
>   the issuer pubkey is the ‚Äúreal‚Äù identity of the user

This has a privacy drawback.  When the user presents one of the
"shorter-lifetime certificates" to a relying party, the user also
sends the "self-asserted CA cert" with the "issuer pubkey".  So the
relying party learns "the real identity of the user".

I know the "real identity" in this case is a meaningless public key.
But all the relying parties see the *same* public key, and this makes
it possible to track the user's activities.  For example, here in the
US where we have private medical insurance, a malicious insurance
company could set up a Web site that provides health information, and
find out that a user with a certain public key is looking for
information about cancer.  It could then find out the name and address
of the user by colluding with an online merchant site who knows the
name and address because the user has used the *same* public key to
log in to the site and has ordered merchandise to be shipped to the
address while logged in to the site.  Later, the insurance company may
deny insurance to the user based on a higher probability that the user
has cancer.

Preventing this kind of tracking is one of the goals of NSTIC.  In our
proposed architecture, in Section 4.6 ("User Authentication without
Third-Party Involvement"), each relying party issues its own "login
certificate" and each login certificate uses a different public key,
so no tracking is possible.  In Section 4.7 ("Using a Personal Data
Site") the personal data site issues a "privacy-enhanced (PE)"
credential that cannot be tracked, rather than a PKI certificate.
Actually, I just realized that we should have been more specific and
said an "Idemix credential" rather than a "PE credential", since the
other kind of PE credential, a U-Prove token, can be tracked by
colluding relying parties.

Best,

Francisco