Yes, client certificates are unusable unless they become mobile. How are they going to get mobile?
I have thought a bit on that and the only reasonable short-term solution is to use [slightly enhanced] USB memory sticks that already are owned by hundreds of millions of people. Unfortunately it won't happen without a major effort by both browser-vendors and memory stick vendors. However, the security people have concluded that storing "keys" (in contrast to passwords...) requires very sophisticated tamper proof HW, existing memory stick controllers are disqualified in spite of being perfectly adequate for most commercial and in-house apps. Due to that we have to rely on completely proprietary solutions like Entrust's TruePass. Some of the short-comings are also due to the fact that the key-provisioning schemes available in browsers do not even support PIN policy settings by issuers. It has been claimed that this cannot be done in a safe manner but that is actually not entirely correct because if you extend http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf to also include PIN policies in the key-attestation signature, the issuer gets a verifiable evidence that its policies are known and enforced by hardware (rather than potentially corrupt middleware), before it issues any credentials. I'm personally unconvinced that client-cert-TLS auth is the way ahead. HTTP-basic was killed by forms and quite a few schemes out there including Entrust's use a similar paradigm for PKI which works better with web servers (sessions). Just doing logout seems to be close to black magic using client-cert-TLS auth. I don't know at least, and based on quite a few sites I have tested, I'm not the only moron on the planet :-) Anders ----- Original Message ----- From: "Kyle Hamilton" <aerow...@gmail.com> To: "mozilla's crypto code discussion list" <dev-tech-crypto@lists.mozilla.org> Sent: Tuesday, March 17, 2009 21:42 Subject: Re: client certificates unusable? On Tue, Mar 17, 2009 at 12:35 PM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 03/17/2009 02:45 PM, Johnathan Nightingale: >> >> I think the implicit 4th step there is evangelism, because I think they're >> a much more robust identification/authentication technology than login+pw, >> or most of login+pw's would-be replacements. But I also think there's no >> point evangelizing the current state of affairs, for the reasons and >> frustrations you've already outlined. :) > > A certain CA has been doing a lot of evangelism with client certs despite > the brokenness of the session handling (whoever is to blame for this - which > reminds me about some theory about what happens exactly when the browser > opens multiple connections at once with the server...). User name / pass > word pairs are one of the sources of the current problems on the net, being > it for web sites authentication (phishing, weak passwords) or other > services like mail, ssh and so forth. If client certificates aren't evangelized, the brokenness will never come to light. If the brokenness never comes to light, it's a huge amount of resource investment for absolutely zero gain. >> Need there be? Certainly we should avoid annoying our users with endless >> prompts AND we should avoid compromising our users by enabling new forms of >> invisible tracking, but there's a healthy middle ground of user choice that >> can be clearly understood and communicated ("Always use this certificate for >> this site") that seems to me, perhaps naively, not to be overloaded on >> policy. What am I overlooking? > > One note here. I'd prefer to decide at least once per browser session (until > restart) to decide which certificate to use - with a "Forget" button a must > in such an implementation. IE7 has this. "Clear cached sessions" I think. I'm going to go out on a limb and add my two cents here: my experience with the process for signing up for the USPTO electronic submission program has made me aware of something: the fact that there's a "user certificate store" with a full import/export process is considered a downside. Users don't want to have to deal with PKCS#11. Administrators don't *understand* PKCS#11. Users migrate between machines. Machines die. Things break. Having a known-good copy of the certificate and key file that they can take with them on their own removable media is a Good Thing. THAT, more than anything else, is why client-side certificates aren't useful. The UI for getting to them, and using them, is MUCH more treacherous (to the user) than the file-open dialog box. If you want to see more about this, look at the software that the USPTO settled on: Entrust TruePass. Its FAQ ( http://www.entrust.com/internet-security-software/faqs.htm , especially number 5) explains many of the problems that users see, and why they developed the software that they did. (Oh, wait, the fact that it doesn't use TLS authentication has already diminished at least Nelson's interest in it. My bad, carry on with the design that you currently have, that nobody uses, that requires huge amounts of effort to maintain, and is a rather severe waste of resources that could be better spent on making something that both works and can be widely adopted.) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
