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

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

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

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

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]

Reply via email to