How many wrongs do you need to make a right?

Anne & Lynn Wheeler lynn at garlic.com
Wed Aug 17 11:52:14 EDT 2005


Peter Gutmann wrote:
> In the 1950s we had cheque blacklists, which were used in an attempt to manage
> bad cheques.
> 
>   They didn't work well, and were abandoned as soon as better mechanisms
>   became available.
> 
> In the 1960s and 70s we had credit card blacklists, which were used in an
> attempt to manage bad credit cards.
> 
>   They didn't work well, and were abandoned as soon as better mechanisms
>   became available.

basically you can have offline & non-electronic, offline & electronic,
online & non-electronic (maybe null), and online & electronic.

the credit card model of the 60s was a manual credential in an offline
environment (aka offline & non-electronic). they started by mailing
monthly booklets (push model) to all registered merchants, as system
grew, the size of the booklets grew, the number of registered merchants
grew, and the aggregate risk grew ... so they started reducing the risk
window by pushing out booklets more frequently. this was growing
enormously cumbersumb and obviously couldn't continue scalling.

in the 70s, they started deploying an online system and added a
magstripe to the plastic ... the plastic could continue to operate in
the old-fashion offline credential mode ... but the magstripe would act
as "something you have" authentication for the online paradigm (aka
online & electronic). the online infrastructure could scale much easier
as well as significantly reducing the risk and adding function

1) any cancelation was effective immediate for all relying-parties

2) was able to add credit limit function which involved real-time
aggregated information ... which is possible in an online environment
put enormously difficult with offline, stale, static certificates.

3) real-time patterns of use that could indicate other kinds of fraud
or possibly lost/stolen

so long ago and far away ... the payment gateway and e-commerce
infrastructure
hhtp://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

added ssl domain name certificates as a countermeasure for various
MITM-attacks (but almost totally "certificate manufactoring" w/o
bothering with revokation)
http://www.garlic.com/~lynn/subpubkey.html#sslcert

there were some efforts in the following time-frame that was advocating
consumer PKI digital certificate deployment as a mechanism for moving
electronic payments into the modern world (aka offline & electronic).

I repeatedly observed that the stale, static PKI digital certificate
paradigm actually would regress the electronic payments environment to
the ancient 60s (a fundamental issue was giving up the scallable online
functions).

If you went purely with the offline stale, static PKI digital
certificate paradigm you lost 1) scallable immediate concelation for all
relying-parties and 2) credit limit real-time aggregated information,
3) real-time patterns of use.

If you kept the scallable online transaction infrastructure ... it would
be possible to upgrade the magstripe "something you have" authentication
by registering the public key for the account and doing digital
signatures verification (using the onfile public key in the account
record). This kept the online & electronic paradigm with upgrading
the magstripe technology to something that was more counterfeit
resistant
http://www.garlic.com/~lynn/subpubkey.html#certless

but not requiring a certification authority to produce a stale, static,
redundant and superfluous certification for use by other parties..

as I recently posted in another thread
http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for
offline solution
http://www.garlic.com/~lynn/2005o.html#7 X509 digital certificate for
offline solution

that a fundamental characteristic of a PKI certification authority
infrastructure is that the certification authority is certifying the
validity of some information for use by other parties ... where the
other parties lack any means of otherwise determining the validity of
the information aka don't have their own copy and/or don't have online
access to the authoritative agency responsible for the information
and/or don't have online access to a related certification authority.

There was some effort in the mid-90s for relying-party-only certifcates
... where the relying-party registered the public key, stored it in an
account record, generated a digital certificate, stored that in the
account record ... and finally provided the key owner with a copy of the
digital certificate
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, it is trivially shown that such relying-party-only certificates
are redundant and superfluous since the relying-party has both the
original ceritifcate as well as real-time copy of all the related
information.

the other way of looking at it is that this violates the fundamental
requirements justifying the use of PKI digital certificates.

some old posts mentioning PKI digital certificates would be throwing the
payment card industry back into the 60s.
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead
... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment
Transaction?
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#31 More Phishing scams, still no
SSL being used
http://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no
SSL being used

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



More information about the cryptography mailing list