The CC number is clearly not hidden if there is a MITM. I think the "I got my money so who cares
where it came from" argument is not entirely a fair representation. Someone ends up paying for
abuses, even if it is us in CC fees, otherwise why bother encrypting at all? But that is besides
the point.
the statement was SSL domain name certificate is
1) am i really talking to who I think I'm talking to 2) encrypted channel
obviously #1 addresses MITM (am i really talking to who I think I'm talking to).
The issue for CC is that it really is a "shjared secret" and is extremely vulnerable ... as I've commented before
1) CC needs to be in the clear in a dozen or so business processes
2) much simpler to harvest a whole merchant file with possibly millions of CC numbers in about the same effort to evesdrop one off the net (even if there was no SSL) return on investment .... for approx. same amount of effort get one CC number or get millions
3) all the instances in the press are in fact involved with harvesting large files of numbers ... not one or two at a time off the wire
4) burying the earth in miles of crypto still wouldn't eliminate the current shared-secret CC problem
slightly related .... security proportional to risk: http://www.garlic.com/~lynn/2001h.html#61
so the requirement given the X9 financial standards working group X9A10 http://www.x9.org/
was to preserve the integrity of the financial infrastructure for all electronic retail payment (regardless of kind, origin, method, etc). The result was X9.59 standard
http://www.garlic.com/~lynn/index.html#x959
which effectively defines a digitally signed, authenticated transaction .... no certificate required ... and the CC number used in X9.59 authenticated transactions shouldn't be used in non-authenticated transactions. Since the transaction is now digitally signed transactions and the CC# can't be used in non-authenticated transactions .... you can listen in on X9.59 transactions and harvest all the CC# that you want to and it doesn't help with doing fraudulent transactions. In effect, X9.59 changes the business rules so that CC# no longer need to be treated as shared secrets.
misc. past stuff about ssl domain name certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert
misc. past stuff about relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo
misc. past stuff about using certificateless digital signatures in radius authentication
http://www.garlic.com/~lynn/subpubkey.html#radius
misc. past stuff about using certificateless digital signatures in kerberos authentication
http://www.garlic.com/~lynn/subpubkey.html#kerberos
misc. fraud & exploits (including some number of cc related press announcements)
http://www.garlic.com/~lynn/subtopic.html#fraud
some discussion of early SSL deployment for what is now referred to as electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
--
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]
