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
