Now that the waters have been muddied (by several of us). My point was that 3D-Secure (and SET and whatever else comes along) covers a different position in the system than SSL does (or can). As such they do have a purpose, even though they may be horribly bloated and nearly non-functional. Visa at least seems to be supporting the 3D-Secure concept (they should, they developed it), and looks like anyone can grab the spec from
... while SET, 3d-secure, etc may have been designed for all sorts of reasons .... I guess my point was that w/o a adequately specified threat model .... for the primary vulnerabilities ... there turned out to be little effective difference between the use of SET and the use of SSL (regardless of what the designers may have original thot). Also technology adoption/uptake typically requires the transition to be less painful than the problem it is fixing. SSL was already in the market space ... so SET had to demonstrate that it was incrementally better (not effectively the "same as" for the major vulnerabilities) in order to justify its significantly more difficult and costly deployment.
The other issue that has been the bane of major PKI/certificate deployments (and I've repeatedly raised the issue) ... is that certificate-based operations typically have the key owner paying for the certificate .... while the major benefit accrues to the relying-party ... the the key/certificate owner. In the case of SET ... there was the consumer payng for their certificate .... and the merchant not only receiving a better than MOTO-discount (making interchange transactions with the "SET" flag turned on ... somewhat suspecious) ... but also the possibility that the transaction would be treated as "authenticated" and potentially shifting the burden of proof in a dispute from the merchant to the consumer. There was the possibility that not only would the consumer be footing the bill (buying their own certificate) for the sole benefit of reducing what the merchant paid on the transaction .... but there was also speculation that it might also be used to make it more difficult for the consumer (there was sporadic mention of shifting the burden of proof from the merchant to the consumer in a dispute).
At least in the SSL domain name certificate, the merchant pays because of some belief that it will help attracted (internet) consumers/business.
In the SET/PKI scenario ... it was nearly impossible to figure out a value proposition for the consumer .... where the consumer is footing the (certificate) bill ... that turns out to be totally for the benefit of the merchant. It wasn't so much that "cryptography took a wrong branch" ... but many of the PKI business models don't conform to any sane business operation .... with the entity (key-owner) footing the bill not getting any benefit ... and all the benefit going to the relying-party.
The other generalized PKI issue (again not just SET) ... is "any" contract tends to be between the CA?PKI and the consumer .... aka the entity in a contract that purchases something. Frequently is no contractual relationship between the relying-parties .... who effectively the sole reason that the certificates exist ... and the CA/PKI. As mentioned elsewhere, the GSA PKI has attempted to somewhat address this by having all relying-parties sign contracts with the GSA .... and all the CA/PKI certificate issuing entities have a contract with the GSA where they are effectively issuing certificates on behalf of the GSA. Those set of contracts then preovide the legal foundation for some generic reason for relying-parties to do anything with certificates (since the relying-parties and the CA/PKI agency, aka GSA ... have contractual relationship and therefor a legal reason to deal with certificates). The slightly different SET scenario ... the associations just told the merchants that they would be charged less per transaction ... aka instead of MOTO (mail order, telephone order) discount, they could get something closer to card present discount.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
