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 [EMAIL PROTECTED]
