On 08/01/2010 01:51 PM, Jeffrey I. Schiller wrote:
I remember them well. Indeed these protocols, presumably you are
talking about Secure Electronic Transactions (SET), were a major
improvement over SSL, but adoption was killed by not only failing the
give the merchants a break on the fraud surcharge, but also requiring
the merchants to pick up the up-front cost of upgrading all of their
systems to use these new protocols. And there was the risk that it
would turn off consumers because it required the consumers setup
credentials ahead of time. So if a customer arrived at my SET
protected store-front, they might not be able to make a purchase if
they had not already setup their credentials. Many would just go to a
competitor that doesn't require SET rather then establish the

SET specification predated these (as also internet specific, from the mid-90s, went on 
currently with x9a10 financial standards work ... which had requirement to preserve the 
integrity for *ALL* retail payments) ... the decade past efforts were later were much 
simpler and practical ... and tended to be various kinds of "something you 
have" authentication. I'm unaware of any publicity and/or knowledge about these 
payment products (from a decade ago) outside the payment industry and select high volume 

The mid-90s, PKI/certificate-based specifications tended to hide behind a large 
amount of complexity ... and provide no effective additional benefit over & 
above SSL (aka with all the additional complexity ... did little more than hide the 
transaction during transit on the internet).  They also would strip all the PKI 
gorp off at the Internet boundary (because of the 100 times payload size and 
processing bloat that the certificate processing represented) and send the 
transaction thru the payment network with just a flag indicating that certificate 
processing had occurred (end-to-end security was not feasible). Various past posts 
mentioning the 100 times payload size and processing bloat that certificates added 
to typical payment transactions

In the time-frame of some of the pilots, there were then presentation by payment network 
business people at ISO standards meetings that they were seeing transactions come thru 
the network with the "certificate processed" flag on ... but could prove that 
no certificate processing actually occurred (there was financial motivation to lie since 
turning the flag on lowered the interchange fee).

The certificate processing overhead also further increased the merchant 
processing overhead ... in large part responsible for the low uptake ... even 
with some benefit of lowered interchange fee. The associations looked at 
providing additional incentive (somewhat similar to more recent point-of-sale, 
hardware token incentives in europe), effectively changing the burden of proof 
in dispute (rather than the merchant having to prove the consumer was at fault, 
the consumer would have to prove they weren't at fault; of course this would 
have met with some difficulty in the US with regard to regulation-E).

Old past thread interchange with members of that specification team regarding 
the specification was (effectively) never intended to do more than hide the 
transaction during transnmission:
http://www.garlic.com/~lynn/aepay7.htm#norep5 non-repudiation, was re: crypto 
flaw in secure mail standards

aka high-overhead and convoluted, complex processing of the specification 
provided little practical added benefit over and above what was already being 
provided by SSL.

oblique reference to that specification in recent post in this thread regarding 
having done both a PKI-operation benchmark (using BSAFE library) profile as 
well as business benefit profile of the specification (when it was initially 
published ... before any operational pilots):
http://www.garlic.com/~lynn/2010l.html#59 A mighty fortress is our PKI

with regard specifically to BSAFE processing bloat referenced in the above ... 
there is folklore that one of the people, working on the specification, 
admitted to a adding a huge number of additional PKI-operations (and message 
interchanges) to the specification ... effectively for no other reason than the 
added complexity and use of PKI-operations.

virtualization experience starting Jan1968, online at home since Mar1970

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to