[cryptography] Allergy for client certificates

Guido Witmond guido at witmond.nl
Thu Oct 10 04:29:38 EDT 2013


On 10/09/13 15:50, Michael Rogers wrote:
> On 09/10/13 10:56, Guido Witmond wrote:
>> You might want to take a look at my experiments. It's a user agent
>> that does all the key management for you.
> 
>> It even does it with never asking anything more difficult than
>> what username you want to have at a site.
> 
> Hi Guido,
> 
> It looks like you've worked around the UX issues by inserting an
> EC-aware proxy between the client and server. Who would be responsible
> for deploying such proxies?

That proxy lives in the end user's computers. Right now, the user needs
to install the proxy. I hope to get time and funding to make it a
Firefox plug in. I hope that when it proofs useful browsers will adopt it.


> What happens if a user creates an EC account from a client machine
> with an EC-aware proxy and then wants to use the account from a client
> machine without a proxy?

You need a user agent that is aware of EC. The alternative is to do all
the rsa-calculations with grey cells. :-(


> This touches on another question I've been meaning to ask you: what
> happens if a user creates an account from a client machine, thus
> installing a client cert on that machine, and then wants to use the
> account from another machine?

Just share the certificate with Firefox Sync like you share password
accounts and bookmarks.


> Also, what happens if a user installs a client cert on a machine and
> then walks away, leaving their client cert exposed to the next user?
> With passwords there's an expectation that once you've logged out, the
> next user can't log into your account. But client certs break that
> expectation.

First, don't do that. Using public access computers (at a library) is a
bad idea anyway. Even if you can trust the library administrators, you
don't know was at that computer before you.

Second, I expect that every user has their own device. And that device
has enough protections against abuse by others. For example, a screen
lock that monitors if it is you who's using the phone and requests a
fingerprint scan and a pin code or swipe style to unlock. (Cypherpunk
Snowcrash style).

Third. You have many certificates. Some have more value than others. You
(the end user) has the option to encrypt certain private keys with a
passphrase and a short unlock-interval. While not bothering with that
for other keys.

Each certificate is a separate identity. You don't share certificates
over multiple web sites.

Would you leave your phone in a hurry then someone can use those keys
at their respective web sites to impersonate you. Until the screen saver
kicks in.

If your phone doesn't allow unprotected access to the filesystem where
the keys are stored, they can't copy any of the keys.


These are important usability questions that will need to be addressed
sooner or later in future. However, they are all client side decisions.
The server is not involved at all. So when the need comes, it can be
implemented quickly. And different people can have different solutions.

However, I want to keep it simple for now. I want to show how easy it
can be to use certificates, to break that horrible browser UX.


Regards, Guido.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20131010/79eba1be/attachment.asc>


More information about the cryptography mailing list