Anne & Lynn Wheeler wrote: > as referenced in the above ... x9.59 > http://www.garlic.com/~lynn/index.html#x959 > > has countermeasure against the harvesting vulnerability (w/o > requiring any encryption) which is so attractive to attackers because > the return is so enormous for the amount of effort > http://www.garlic.com/~lynn/subpubkey.html#harvest
note that while x9.59 allows for digital signature (as method of strong-authentication) ... and even co-signing by both the consumer and the terminal ... it doesn't mandate certificate-based operation and allows for certificate-less digital signature authentication. http://www.garlic.com/~lynn/subpubkey.html#certless we had worked on the original payment gateway for what was becoming e-commerce http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 before starting in the x9a10 financial standards working group on x9.59 standard http://www.garlic.com/~lynn/index.html#x959 in that time frame there were some number of specifications for financial transactions that involved digital signatures and mandated a fairly large collection of digital certificates and pki. the financial industry in the mid-90s was one of the industries that was starting to realize that the x.509 certificates, somewhat from the early 90s, representing significant privacy and liability issues ... especially when grossly overloaded with personal information. they had retrenched to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo which effectively bound a public key to an account number or some other form of database lookup value (where the real and relavant information was actually stored). note that it was relatively trivial to show that such digital certificates were redundant and superfluous (repeatedly sending back database lookup value to the institution that had issued the certificate and had direct access to all the real information). the other issue we saw with some of the financial transactions mandating digital certificates (especially redundant and superfluous relying-party-only certificates) was the enormous payload bloat in typical payment network transaction. A typical payment network transaction has been on the order of 60-80 bytes ... the typical relying-party-only digital certificate for these programs ran 4k to 12k bytes ... which represented an enormous payload bloat of a factor of one hundred times. Some of the programs realizing that it really wasn't practical to transmit such a redundant and superfluous digital certificate over the typical payment network ... were having an internet boundary gateway validate any digital signature (with the public key in the digital certificate) ... and then transmitting a normal payment network transaction with simply a bit turned on indicating if the digital signature had verified. Besides violating kindergarten security 101 regarding end-to-end security (or because of it) ... there was an ISO standards meeting where a business person from one of the payment networks gave statistics on there being quite a few payment transactions flowing thru the network with the digital signature verified flag turned on ... and they could prove that there hadn't been any digital signature technology involved (one possibly motivation given was that they were talking about lowering the discount rate for digital signature verified transactions based on presumption of lower fraud rate). The scenario is that the consumer's issuing bank is the financial responsible party ... and fundamental end-to-end security principles would dictate that the responsible party for authorizing the transaction should also be the responsible party for authenticating the transaction (rather than possible organizations that might have interests quite different from that of the consumer's issuing financial institution). A side issue with some of the payment digital signature specifications from the period was that they provided no countermeasure for the growing harvesting/skimming problem ... aka the sam PAN in a digital signed transaction could be harvested and used in a non-authenticated transaction http://www.garlic.com/~lynn/subpubkey.html#harvest --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
