Pat Farrell wrote: > As others have said, and in the spirit of the subject > of this thread, SET failed for many reasons, many > of them economic. There was little effort made > to bribe the merchants, I think there was talk of > a 26 basis point change in the discount rate, > which the banks thought was huge and the merchants > thought was noise. What really killed it > was the billions it would have cost all > the banks to issue and manage all the > certificates.
this was some of the confusion between identification and authentication. The SET effort was smart enuf to not do x.509 identity certificates and instead do relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo and they even made comments about the enormous privacy and liability issues raised with x.509 identity certificates. They also avoided doing any sort of PKI infrastructure ... aka the management and administration of the certificates. The effectively were doing the same stuff as the original SSL domain name certificates ... for which we coined the term "certificate manufactoring" (to differentiate from a certificate administrative and management operation). They basically said that the certificate only contained the account number ... and the account number could be turned-off at the issuing financial institution ... making it redundant and superfluous to also have to have a separate infrastructure for invaliding the certifcate. So they have an online infrastructure with real-time transactions and real-time operation of the real information. It is an extremely trivial additional step to show that then the certificates themselves are redundant and superfluous. The cost of the certificates only become an issue if you are talking about having to pay a trusted third party, $100/annum for every certificate. So we can take this in incremental steps. 1) you have the consumer's financial infrastructure register the public key. they then can generate and issue a relying-party-only certificate to the consumer (containing the consumer's public key and account number). 2) there was work started in X9 financial standards body on compressed certificates. Even the SET relying-party-only certificate overhead ran 4k-12k bytes. The typical iso8583 financial message is on the order of 60-80 bytes. Even the trivial SET relying-party-only certificates represented a payload bloat of one hundred times (besides the RSA-ops inflating processing overhead by 3-4 orders of magnitude). 3) Because of the enormous payload bloat contributed by the certificates, the digital signature processing was being truncated at the internet boundary and a standard iso 8583 message was then generated with a flag turned on indicating that the internet had validated the digital signature. The merchants had an incentive to see that flag turned on since that was the basis on which a lower discount was calculated. At an ISO meeting in europe ... one of the association network people presented statistics on the number of iso 8583 messages that they found with the flag turned on and they could prove that no digital signature technology could have been involved 4) I presented an argument that a valid compressing technology is to eliminate all fields from the (certificate) contents that were known to already be in possession of the relying party. Since it could be proved that all fields in the SET relying-party-only certificate were already on file with at the consumer's financial institutions ... it would be possible to eliminate all fields from the relying-party-only certificates. If they preferred, i would start describing the process of appending zero byte digital certificates as an alternative to describing certificateless digital signature operation http://www.garlic.com/~lynn/subpubkey.html#certless 5) The consumer's financial institution could effectively use the existing business processes for registering PINs as a mechanism for registering public keys. That is not known to be an expensive business process. A consumer's financial institution then could set up a website where the consumer could later retrieve their (redundant and superfluous relying-party-only) digital certifcate. There is some integrity constraints here ... but since the purpose of a digital certificate is to spray it all over the world ... there isn't a lot of confidentiality constraints (i.e. it doesn't hurt a lot if other people pick up your digital certificate). However, since both the public key and the digital certificate would already be on file ... you could require people to perform digital signature authentication before picking up their redundant and superfluous digital certificate. This does have an unfortunate downside since it highlights that consumer digital signatures can be validated by onfile public keys w/o needing digital certificates 6) there were lots of comments that leaving all the PKI gorp in the hands of trusted third parties was a trade-off of the $100/annum/certificate against the upfront costs of modifying mainline production systems. The two problems was that only worked as long as the PKI stuff was being limited to toy demos. For any sort of producting roll-out, a) the $100/annum/certificate would exceed the costs of upgrading mainline production system, b) toy demos didn't have to worry about customer calls, if you wanted to provide a service, you have to take trouble/customer calls. To have integrated financial institution trouble/customer sevice ... you have to integrate the public key stuff into the production systems. aka ... the only scenario where you could use trusted third party trade-off of $100/annum/certificate against modifying production systems was in the toy demo stage. 7) concurrent with SET ... we were also working in the X9A10 financial standards working group ... which had been charged with preserving the integrity of the financial infrastructure for all retail payments. we had done many of the detailed business and technology issue examination coming up with x9.59 standard ... http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy which then made it much easier to spot them in the SET specification. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]