the limits of crypto and authentication

Anne & Lynn Wheeler lynn at garlic.com
Tue Jul 12 14:28:20 EDT 2005


Perry E. Metzger wrote:
> By the way, I note as an aside that this also means (in my opinion)
> that certificates are no longer an interesting technology for
> payments protocols, because in a purely online environment, you
> never need a third party x.509 certificate in the course of the
> payments protocol itself when there are no offline components of the
> protocol and all relationships are bilateral.

my impression of the 3party x.509 identity certificate model of the
early 90s ... was that every person would pay $100/annum for their
identity certificate grossly overloaded with personal information.

the certificate model has a design point from the early 80s, offline
email, where the receiver dials their local (electronic) postoffice,
exchanges email and hangs up. they then are faced with dealing with
first time email from total strangers. the x.509 identity certificates,
grossly overloaded with personal information ... were targeted at
(hopefully) including at least one piece of personal information (about
the sender), that the receiver might find useful when dealing with total
stranger.

moving into the early 90s, with a model where everybody would have
$100/annum identity certificates ... the apparent business model would
be that all established business relationships would be done away with
... and people would only be performing spontaneous business
transactions with total strangers ... supported by the x.509 identity
certificates. For instance, rather than depositing money in an
established bank account .... you would spontaneously contact a total
stranger to accept your large sums of money. The exchange of x.509
identity certificates with total strangers would provide sufficient
trust and integrity to safegard your large sums of money.

Moving into the mid-90s, some institutions started to realize that such
x.509 identity certificates represented huge privacy and liability
issues and there was some implementations by financial institutions of
relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

which only contained a public key and some sort of database lookup index
 (as unique information) along with a lot of CPS and other types of
certification accounting gorp. In this situation, it was trivial to show
that such relying-party-only certificates were redundant and
superfluous: the relying party already has all the necessary information
on file, which invalidates the certificate design point of providing
"letters of credit" type of information between two strangers in first
time communicate (where there is no other recourse for information about
the party you are dealing with).

of course, there was a side issue in these payment protocols from the
period. the typical iso8583 payment message is on the order of 60-80
bytes. the typical overhead for even the relying-party-only certificates
(attached to every payment message) was on the order of 4k-12k bytes ...
leading to an enormous payload bloat of one hundred times for something
that was totally redundant and superfluous.

In general, the design point of x.509 identity certificates were to turn
all transactions (regardless of kind, even the most lightweight
authentication transactions) into heavyweight identification operations.

You would even find some govs. passing legislation that was oriented
towards mandating x.509 identity certificate be appended to every
digital signed transaction ... even when you might be looking at purely
a lightweight "something you have" authentication operation.


misc. recent posts on the subject:
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big
problem with meaning
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list