Rich Salz wrote: > Wasn't that a goal of SET? there was an observation that SET possibly wouldn't divulge your account number until the merchant had been determined to be some entity registered as a merchant (akin to the SSL domain name infrastructure certificates ... if a spoofed site didn't use SSL until you hit the pay/checkout button, what is the probability that the spoofed site provide a URL that matched some valid certificate that they did have).
note, however, some of the participants even got confused about this issue. note that there are a lot of merchant business processes that require the account number ... and therefor you can't prevent the merchant from possessing the account number. some might be tempted to observe that there is a kind of conflict of interest ... using the same value for authentication purposes as well as widely needed for a large number of other purposes (akin to designing a system that widely uses your userid a basis for normal functioning ... as well as making your userid also your password). some past posts where the SET issue of divulging account number was disucssed. http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption 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 I thot the goal of SET was to maximize the number of RSA-ops being executed in the world. When I first obtained a copy of the initial SET specification, I did a RSA-ops profile and a business operation profile. An acquatance had done some work on the BSAFE library and improved the performance by a factor of four times. I got him to run timing tests on the SET RSA-ops profile across a number of different machines. I then communicated the results to a number of people that were part of the SET group. The reply from various members of the SET group was that the numbers were obviously one hundred times too slow (the correct answer should have been that the numbers were four times too fast). Six months later when the first prototype SET code was running ... their measured numbers were within a couple percent of my earlier profile numbers (aka the BSAFE enhancements had been given back to RSA). One possible observation was that SSL work http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 was already providing account number confidentiality for *data-in-flight*. The significantly much more complex, and heavyweight SET would have needed to provide countermeasures for significantly more threats and vulnerabilities ... like security for *data-at-rest* (aka data breaches) in order to make any headway against the (SSL) incumbant. I also made a couple comments to the SET group about the heavy-weight nature of SET (apparently the RSA-ops being one hundred times more onerous than they had anticipated). Effectively, the SET RSA-op profile was symmetrical .... but the standard processing is quite asymmetrical. In effect, the massive datacenters that are currently processing credit card transactions would have needed their computational facilities increased by at least one hundred times (SET RSA-op profile was looking at tens of seconds per transaction while many of these datacenters measure their thruput in thousands of transactions per second ... a four orders of magnitude gap). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]