SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number.
both SET & SSL encrypted data in transit. an issue is that SET is significantly more complex and provided no additional countermeasure (vis-a-vis SSL) against major remaining exploits .... like harvesting the merchant transaction file while at rest.
there was some issue that SSL was the incumbent ... so SET had to demonstrate significant better ROI to displace it ... rather than significantly higher "I" with little or no additional "R".
some SSL: http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3
the security proportional to risk reference (using merchant transaction file as example)
http://www.garlic.com/~lynn/2001h.html#61
couple minor past refs related to SET business operations
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
another SET issue was that it took a typical ISO 8583 transaction of 60-80 bytes and added a RSA 128 digital signature and issuing certificate of 4k-12k bytes .... effectively increasing the payload size by a factor of two orders of magnitude. it stripped all the SET overhead off at the internet boundary and transmitted a traditional 8583 message (in part because it was difficult to justify a 100-fold increase in payload size for no obvious benefit) with a flag indicating whether the signature had verified. There was some presentation at an ISO meeting by one of the association business people about the number of 8583 messages with the signature-verified flag turned on and they absolutely knew that there was no SET technology involved (some justification was association was proposing rules that transactions with the flag on would have lower merchant fees). missing is that typical authorization includes a lot of dynamic and aggregation factors (like credit limit) that are totally missing in a simple certificate-based (offline) authentication model. In fact, most infrastructures that involve transactions of any value have migrated and/or are migrating to online infrastructures that involve timely and/or aggregated information .... something that is missing from a purely offline, certificate-based, static, stale data infrastructure.
misc. implications
1) given an online transaction environment, it is then trivial to show that certificates are redundant and superfluous ... because it is possible to access the timely updated copy of the information rather than having to rely on the stale, static copy of the certificate information (designed to satisfy an offline environment requirement)
2) certificate market then becomes relegated to both offline and no/low value (as infrastructures of value migrate to online paradigms) ... there is little/no justification for paying money for certificates if only no/low value infrastructures are involved.
3) w/o significant funding for certificate-based infrastructure, there is little money to underwrite high-integrity certificate-based operations
4) with no high-integrity certificate-based operations, it is difficult to justify using certificates for high-value operations
5) go to #2
as has past frequently noted, the requirement given the x9a10 retail payments working group for the x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payment environments. one of the considerations was being able to accommodate end-to-end integrity ... aka the financial responsible entity for authorizing the transaction also performs the authentication. another issue x9a10 had to address was to address other kinds of risks .... like the merchant transaction file where the information traditionally has to occur in the clear to support normal business operations (offer something more than the encryption of data in-flight).
http://www.garlic.com/~lynn/index.html#x959
lots of posts about certificate infrastructures http://www.garlic.com/~lynn/subpubkey.html#sslcerts
misc. stuff on x9.59, identity, authentication, and privacy http://www.garlic.com/~lynn/subpubkey.html#x959
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
