Collective answer to Jean-Marc and Michael. "Green messaging" :-)
Before going too deep into this you should be aware of the fact that Microsoft's recently introduced Information Card scheme also when using a local X.509 certificate to authenticate to the IdP does not specify TLS-client-cert-auth even as an option! Regarding the .SE banks and competency, the issue is rather that their *customers*, the e-governments do not have the necessary knowledge. Understanding TLS state in web- servers and browsers is BTW anyhthing but simple. >:-( It's very different in terms of MITM protection. Yes indeed it is, but the end-result is identical, full *RP* protection against on-the-wire MITM attacks assuming that server-side TLS is used in both cases. >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. Yes, but that is surely not going to happen because the alternatives are already in place and are anyway needed for the signature stuff that no browser vendor has shown any kind of interest in despite the fact that millions of people already use it on a daily basis. >> it matches poorly with web sessions including logout >Why should it match application sessions? Because the web application >developers are too dumb to get the session handling right for >themselves? Because the "logout" does not behave like they are >used with passwords? You essentially gave the answer yourself. In order to deploy TLS-client-cert-auth you must hire very special people. That MSIE has a button "Clear SSL State" is a pretty good indication that securing a static tunnel and browsing the web are two quite distinct applications. That Mozilla apparently works completely different (?) is not an argument for TLS-client-cert-auth, it is an argument *against* it. >> - it is poorly implemented in many browsers with respect to path building >Can you explain this? At least in FF 2.x, a PIV user had to *install* the entire cert-path in the browser trust store in order to authenticate since stuff like AIA ca issuers isn't supported in spite of being mandated in PIV. Hopefully this was fixed in FF 3.0 but of course this total misalignment has given TLS-client-cert-auth a *well-deserved* bad reputation. >> - it offers very limited filtering capability >What do you want to filter? At which point? Well, I think that Nelson can testify that there has been a rather long-lasting "bug" in FF regarding what certificate to show the user in the TLS selection GUI based on [for example] key usage. I don't consider this a bug in FF, but a deficiency in TLS- client-cert-auth which didn't take this issue in consideration. The "fat-app" alternatives usually offer much better selection facilities like in: http://tinyurl.com/6ot2vz Anders webpki.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
