It's also worth remembering that an SSL-like solution -- cryptographically protecting the transmission of credit card number, instead of digitally signing a funds transfer authorization linked to some account -- was more or less the only thing possible at the time. The Internet as a medium of commerce was too new for the banks to have developed something SET-like, and there wasn't an overwhelmingly-dominant client platform at the time for which custom software could be developed. (Remember that Windows 95 was the first version with an integral TCP/IP stack.) *All* that Netscape could deploy was something that lived in just the browser and Web server. SET itself failed because the incentives were never there -- consumers didn't perceive any benefit to installing funky software, and merchants weren't given much incentive to encourage it.
SET couldn't replace online transaction ... the encryption was effectively there for hiding credit card while in-flight ... which SSL was already doing ... but SET was doing at an order to two-orders increase in complexity and overhead. SET didn't provide any additional countermeasure against the major exploits/vulnerabilities (vis-a-vis SSL) ... even with all that complexity.
the transaction was still online ... since there are a bunch of other factors involved in authorization ... like credit limit ... not just whether there is impersonation with lost/stoleln numbers.
there was still the enormous payload bloat (certificates and signatures increase the size of typical 8583 transaction by two-orders of magnitude) which prevent true end-to-end security operation. As a result the signature was verified at some internet boundary, then the signature and certificate(s) were stripped off and traditional 8583 packet forwarded to the consumer/issuing financial institution. Later at some ISO standards meeting, one of the association business people presented numbers on number of 8583 packets with the signature bit turned on and they positively knew no digital signature was involved.
It wasn't even a real PKI ...
1) i.e. the x.509 identity certificates from the early 90s had been depreciated because of the privacy and liability issues ... and the certificates effectively were issuing relying-party-only certificates with the account number and public key.
2) there was no revocation and/or other types of process (which could be considered minimum requirement for a PKI operation) ... they were simply manufactored certificates (a term we coined to describe the SET and SSL infrastructure; contrasting it to PKI). SET specifically stated that the transaction would be online and rely on the existing online infrastructure for determining lost, stolen, revoked, canceled, etc ... as well as all the other stuff an online infrastructure can do with timely and aggregated information (like credit limit)
3) it is trivial to show that for relying-party-only certificates requiring online infrastructure ... that the certificates themselves are redundant and superfluous ... aka the key is registered with the issuing party ... and the transaction is performed by the issuing party. The transaction can be digitally signed (w/o the enormous payload bloat of carrying a certificate) and the issuing party verify the digital signature with an onfile public key .... w/o having to resort to dealing with a certificate (that the issuing party would have originally generated from the onfile information).
From an incentive standpoint the PKI model is effectively orthogonal to standard business processes.
The key owner pays something to the issuing party (or at best, the issuing party absorbs the costs). The standard business process has any sort of contract between the key owner and the issuing party.
This totally leaves out the relying-party ... which is the primary beneficiary of the PKI model from being a part of the contractual business process ... which would imply little or no legal recourse if something went wrong. GAO has created a facade to address this issue by making the TTP certification authorities sort of agents of the GAO ... and having all relying-parties signed contracts with the GAO., The PKI frequently creates a total disconnect between the parties of the certification "contract" ... and the relying parties ... which should have recourse in case something went wrong aren't even a part of it.
In the specifics of the SET deployment ... the primary potential beneficiaries theoritically were the merchants (from the thoery that SET signed transactions would be considered card-present & card-owner present ... and lower the merchants cost for doing the transactions). However the parties "paying" for the certificates and most of the infrastructure were the issuers and the consumers. Not only may a traditional TTP PKI create legal disconnect for relying parties .... but in the SET case there was major disconnect between who paid for most of the infrastructure and who benefited (i.e. need some sort of mechanism to get the merchants to pay for the consumer's certificate .... even tho the certificates were functionally redundant and superfluous).
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]