Eric Rescorla wrote:
(as if anyone uses client certificates anyway)?
Guess why so few people are using it ...
If it were secure, more people would be able to use it.
No, if it were *convenient* people would use it. I know of absolutely
zero evidence (nor have you presented any) that people choose not
to use certs because of this kind of privacy issue--but I know
of plenty that they find getting certs way too inconvenient.
In a CA I have something to do with, I'm observing a site
that just started experimenting with client certs (100
users, will reach 1000, maybe more).
When we discovered that the certificate includes PII
(personally identifying information) and the website stores
additional PII, the service was directed to drop all
additional PII, and some thought was put into the in-cert PII.
Current view is that the service must engage the user in a
contract to accept the storing of that in-cert PII,
otherwise it must not store the info in the cert (which
means no identity, no persistence, and no point to the
client certs).
Writing contracts and securing agreement of course is a
barrier, a burden. If this were a general requirement, then
this would be enough (imho) to not recommend client certs,
because contracts need lawyers, they cost real money, they
don't solve the problem, and not recommending them is
likewise unacceptable.
(Then, as you say, there are convenience issues.)
This is an experiment to force client certs to be used, so
they are plugging on. It's a CA so it is trying to prove
that there is value in these things.
So... there are two slight variations that could be
employed. Firstly, all data placed in the cert could be
declared public in advance, and then no contract is required
to use it in a context that is compatible with public data.
That is, the question of the contract is pushed to the CA/CPS.
(You mentioned that the premise is that it is all public
data...)
Another variation is to switch to username + password, of
course, in which case the username is freely given and
expected to be stored (certs being more or less invisible to
users, so we can presume no such).
(definately open to other ideas...)
The PII equation is particularly daunting, echoing Lynn's
early '90s experiences. I am told (but haven't really
verified) that the certificate serial number is PII and
therefore falls under the full weight of privacy law & regs
... this may sound ludicrous, but privacy and security are
different fields with different logics. If that is true,
the liability is far too high for something that should be
private, but is already public by dint of its exposure in
certificates. Privacy liabilities are sky-high in some
places, and not only that, they are incalculable,
unknowable, and vary with the person you are talking to.
So a superficial conclusion would be "don't use client
certificates because of the privacy issues" although the
issues are somewhat more complex than "PII revealed in SSL
key exchange."
As I say, they'll plug on, as they need to prove that the
cert is worth issuing. It's a data point, no more, and it
doesn't exactly answer your spec above. But I'm having fun
observing them trying to prove that client certs are worth
any amount of effort.
iang
PS: normal disclosures of interest + conflicts, included.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
