Fixing SSL (was Re: Dutch Transport Card Broken)

Anne & Lynn Wheeler lynn at garlic.com
Fri Feb 1 10:13:32 EST 2008


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 majordomo at metzdowd.com



More information about the cryptography mailing list