> > So what purpose would client certificates address? Almost all of the use > of SSL domain name certs is to hide a credit card number when a consumer > is buying something. There is no requirement for the merchant to > identify and/or authenticate the client .... the payment infrastructure > authenticates the financial transaction and the server is concerned > primarily with getting paid (which comes from the financial institution) > not who the client is. >
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. > So, there are some infrastructures that have web servers that want to > authenticate clients (for instance online banking). They currently > establish the SSL session and then authenticate the user with > userid/password against an online database. > These are, I think, more important examples and again, if there is a MITM, then doing additional authentication post-channel setup is irrelevant. These can be easily replayed after the attack has completed. The authentication *should* be deeply tied to channel setup, should it not? Or stated another way, having chained authentication where the first link in the chain is demonstrably weak doesn't seem to achieve an awful lot. > > There was an instance of a bank issuing client certificates for use in > online banking. At one time they claimed to have the largest issued PKI > client certificates (aka real PKI as opposed to manufactured > certificates). > > However, they discovered > > 1) the certificates had to be reduced back to relying-party-only > certificates with nothing but an account number (because of numerous > privacy and liability concerns) > > 2) the certificates quickly became stale > > 3) they had to look up the account and went ahead and did a separate > password authentication .... in part because the certificates were > stale. > > They somewhat concluded that the majority of client certificate > authentication aren't being done because they want the certificates .... > it is because the available COTS software implements it that way (if you > want to use public key) ... but not because certificates are in anyway > useful to them (in fact, it turns out that the certificates are > redundant and superfluous ... and because of the staleness issue > resulted in them also requiring passwords). > Fascinating! Can you please tell me what bank that was? -- tomo --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
