Actually they do target very different aspects. SET, 3D-Secure, and any other similar have a different target then SSL. To understand this it is important to realize that instead of the usual view of two-party transactions, credit card transactions actually take 3 parties; Issuer, Seller, and Buyer. SSL covers the Seller-Buyer communication, and can also be applied to the Seller-Issuer communication, but on a transaction basis it offers nothing for the Issuer-Buyer (the important one for minimizing costs for the Issuer).
actually, physical credit card ... is a number of pair-wise communications .... card-holder to merchant terminal ... merchant terminal to merchant acquirer, merchant acquirer to interchange, interchange to issuer (credit card model is sometimes referred to as the 4-corner box .... with interchange trying to be transparent in the acquirer to issuer communication).
original electronic commerce with the netscape commerce server ... had SSL for the shopping experience ... with the credit card done at the end. Depending on the mall version of the commerce server had dedicated leased line directly to merchant acquirer. The wider userd commerce server had a SSL connection from the commerce server to the payment gateway (which then interfaced to the merchant acquirer) ... effectively emulating the real world (two pair-wise communcations).
In the real-world .... SSL use got cut-back to only handling the credit card part of the transaction ... and not being used for the rest of the shopping experience.
In any case, the SSL flows exactly emulate the physical world (effectively the front side of the virtual POS running at the merchant website ... and the backside of the virtual POS to the acquirer) . ... modulo previous comment that the merchant transaction file in the physical world wasn't accessable via the internet (even tho it directly doesn't show up in the flows). The major exploits haven't been in the transaction flow part of the operation .... but in the business mechanics .... the major exploits have been harvesting the merchant transaction file. Neither SSL, nor SET have counter-measure against the major exploit (harvesting the merchant transaction file). Both SSL and SET hid the credit card number while in transit.
SET had all this other certificates and PKI gorp ... that significantly increased the crypto-related burden ( much more so than SSL). In theory, SET had an opportunity for end-to-end authentication .... but even a single certificate represented on the order of two-orders of magnitude bloat increase for the payload in the standard payment network (aka a single PKI certificate tends to be one hundred times larger than the typical, base payment transaction). The SET burden was orders of magnitude worse than the SSL burden. This, in part is what gave way to the SET payment gateway .... all the PKI gorp would occur at the SET payment gateway ....then all SET related information would be thown away, a standard 8583/x9.15 transaction created .... with an additional flag indicating that digital signature authentication had been correctly performed ...and off it goes.
One of the VISA business people later gave a presentation at an ISO meeting about the number of 8583 transactions flowing thru the payment network with the SET-authenticated flag set ....but they could prove that no PKI technology was even remotely possible for the transaction .... aka a slight issue of end-to-end security was violated. The important issue here was that the vision for SET ... was that if SET-authenticated transaction were involved ... the merchant eventually would be eligible for card-holder present discount rates ... rather than MOTO discount rates (aka having SET authentication was proposed as being as safe as a) card-holder present, b) card-preset, and c) track 1&2 readable). It was therefor in the interest of the merchant side of the business to tell the issuing side of the business that transactions were SET authenticated and the mrechant could get a much better discount rate).
The claim was that SET enormously increased the complexity, overhead, and payload processing ... while having little practical impact on the major vulnerabilities.
Out of all this ... the X9A10 standards working group was giving the requirement to preserve the integrity of the financial infrastructure for all retail payments. The result is X9.59 which addresses all the major exploits at both POS as well as internet (and not just credit, but debit, stored-value, ACH, etc ... as well).
One of the things addressed by X9.59 was not the elimination of the ability to harvest the merchant transaction file ... but to make the account numbers in the merchant transaction file useless for fraud. slightly related discussion of the "security proportional to risk" and the vulnerability represented by the merchant transaction file
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
misc. recent SET refs:
http://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI
http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security took the wrong branch?
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]