Reputedly, chargeback rates and fees in the fringe industries - adult for example - can reach 50%. But, instead of denying those uses of the card - hygiene - issuers have encouraged it (...until recently. There is now a movement, over the last year, to withdraw service from the fringe industries, but, it is because of additional risks being added, not the risks of fraud or user loss. Visa is doing it, Mastercard is "waiting and seeing.")
a webhosting company presented some numbers at some standards meeting that they handled ten websites (all with monthly hits higher than the number one in the published monthly "hit" rankings) ... five were adult-type downloads and five were various kinds of (non-adult) software downloads. The adult-type charge backs were comparable to mainstream brick&mortar upscale retail outlets .... while the mainstream software downloads was on the order of fifty percent. It seemed that the people that download software are much more "fringe" than the types that download adult material (i believe they threw in some snide comments about the character f people that download software).
as I've mentioned before .... ipsec had been progressing very slowly in ietf for some time. in '94 ... you saw VPN being introduced at router working group (fall san jose meeting?) and introduction of SSL. both could be considered the domain of ipsec. Several of the router vendors didn't have processors capable of doing the crypto for VPN ... so you somewhat saw vaporware product announcements following the san jose meeting and VPN didn't make much progress until more router vendors had processors capable of handling the crypto load. the ipsec people seemed to evnetually come to terms with vpn by referring to it as lightweight ipsec (so the vpn people got to refer to ipsec as heavyweight ipsec). also in 94 you started to see SSL deployment .... basically a transport level ipsec feature implemented by applications (could be considered because ipsec was having such a hard time progressing).
minor past refs:
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec
what i remember from the time was that SSL was thought as handling all of the shopping experience .... not just the credit card part but the feedback was that doing everything thru SSL cut the thruput capacity by about a factor of five (or you could handle five times as much traffic on the same hardware not using SSL).. The result was rather than using SSL for all commercial activity ... it was cut back to just handling the credit card part.
Basically, SSL was being used for hiding the credit card number while in transit (over the internet). However, almost all the exploits have been from harvesting credit card files .... even when it would be possible to "sniff" non-encrypted credit card transmission. That issue is somewhat that you can be very targeted and quickly get possibly hundred thousand credit card numbers .... or you could put up a listening post and hope that you run across several a day (or maybe even an hour).
SET came out after SSL ... and made extensive use of public key operations. I reported a public key operation performance profile for SET within a couple weeks after the original specification ... which several people working on SET claimed to be one hundred times too slow. It was probably just wishful thinking on their part since when they had some running prototype ... the profile was within a couple percent of measured. An issue was that SET was at least an order of magnitude more resource intensive than SSL ... and the only thing it did was protect credit card information in transit; basically it was only addressing the same (credit card) threat model as SSL .... but with significantly more overhead (having possibly hundred times more PKI didn't actually make things more secure).
lots of past comments about what SSL does for credit card transactions: http://www.garlic.com/~lynn/subpubkey.html#sslcerts
lots of recent comments in sci.crypt about eliminating certificates from SSL by collapsing the public key stuff into DNS:
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#44 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#46 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#50 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#52 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#54 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#55 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#57 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)
--
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]
