Ian G wrote:
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.
the problem that digital certificates were suppose to address was first
time communication
between strangers ... the electronic analogy of the letters of
credit/introduction from
sailing ship days. this harks back to the "offline" email days of the
early 80s ... dial-up
electronic post-office, exchange email, hangup, and now authenticate
first-time email
from total stranger.
the design point assumptions are invalidated if the relying party has
their own
repository of information about the party being dealt with (and therefor
can
included that party's public key) and/or has online, timely electronic
access to
such information.
one of my favorite exchanges from the mid-90s was somebody claiming that
adding digital certificates to the electronic payment transaction
infrastructure
would bring it into the modern age. my response was that it actually would
regress the infrastructure at least a couple decades to the time when
online, real-time transactions weren't being done. The online, real-time
transaction provides much higher quality and useful information than
a stale, static digital certificate (with an offline paradigm from before
modern communication). Having an available repository about the party
being dealt with ... including things like timely, aggregated information
(recent transactions) is significantly mover valuable than the stale,
static digital certificate environment (the only thing that it has going
for it, is it is better than nothing in the oldtime offline environment).
misc. past posts referencing "certificate-less" public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless
for some real topic drift ... i've mentioned x9.59 financial
standard protocol that can use digital signatures for
authentication w/o requiring digital certificates
http://www.garlic.com/~lynn/x959.html#x959
part of the issue included that digital certificates
(even relying party only digital certificates) can
add a factor of one hundred times payload bloat
to a typical payment transaction
http://www.garlic.com/~lynn/subpubkey.html#bloat
however, we were also got involved in co-authoring
the x9.99 privacy standard ... as part of that we had
to look at a number of things, HIPAA, GLBA ... as
well as EU-DPD. as part of that we had also done
a privacy merged taxonomy and glossary ... some
notes
http://www.garlic.com/~lynn/index.html#glosnote
EU had also made a statement in the mid-90s that
electronic retail payments should be as anonymous
as cash. The dominant use of SSL in the world
today is electronic commerce between a consumer
and a merchant. Passing a client certificate (with
PII information) within an encrypted SSL channel
to a merchant ... still exposes the information to
the merchant ... also violating making purchases
as anonymous as cash.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
