Anders Rundgren wrote: > Today I was in a meeting with Swedish bank-people. They > told me that they are planning exodus from TLS-client-cert-auth > because it (in their opinion) works really bad. The banks will > replace TLS-client-cert-auth with a proprietary auth client that > is very similar to their current signature client.
:-( It's very different in terms of MITM protection. > [...] > So what's the problem with TLS-client-cert-auth? Maybe because Hum, don't they have something much more precise than a *maybe* ? > - it matches poorly with web sessions including logout > - the GUI look like c--p > - it offers no branding capability I think the problem is almost exactly the same as the one that has caused form/cookie based authentication to replace "Basic Authentication". > - it require PIN caching for smart cards Enhancement session cache management should make that not a problem. With the application, they have application level control on how long the initial authentication is considered valid, here they loose it. All of these could be solved IMO, but it would require a joined browser/server effort, and to build bridges between the applicative level and the ssl session management on the web server. > - it is poorly implemented in many browsers with respect to path building > - it offers very limited filtering capability I'm not sure I very well understand this two points, but I suspect the solution boils down to offering much more flexible, application level control on the client certificate selection. While I clearly understand it's a required added value for the application, it would rises some privacy protection concerns. You don't want random applications to know the exact number and content of all the cert you own, but it would more or less need to be able to see that to help you choose the correct one properly. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
