[Cryptography] client certificates ... as opposed to password hashing

Tony Arcieri bascule at gmail.com
Tue May 27 12:15:16 EDT 2014


On Tue, May 27, 2014 at 8:04 AM, Joe St Sauver <joe at oregon.uoregon.edu>wrote:

> Tony commented:
>
> #That's great... so what's the problem? User experience
> #
> #Client certificate UX is terrible in all browsers. Worse, it's
> inconsistent
> #between browsers. Managing certificates is terrible. Hell, browsers can't
> #even decide whether or not they should use the system trust store or their
> #own.
>
> I'd distinguish between two phases when it comes to client certs:
> provisioning, and routine use.
>
> No question about it, provisioning is currently painful, although there are
> some commercial tools (Cloudpath ExpressConnect and SecureW2, for example)
> that have been putting a lot of effort into making cert installation a lot
> less painful, and the Internet2 community has also has been working on
> InCert, an open source option (see https://github.com/Internet2/incert and
>
> http://www.internet2.edu/vision-initiatives/initiatives/trusted-identity-education/incert/#incert-overview


Again, from a technological perspective, the prerequisites are already
there.

The <keygen> tag (
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen) will
generate a key within your browser and submit a CSR as part of an HTML
form. The remote side can then send down a signed cert for local
installation. This all happens through the browser UI... today. No
commercial software needed (although you do need to run a CA on the server
side, have fun there)

Good luck getting anyone to figure out how to go through this workflow, or
for that matter, manage their certificates among multiple browsers or
multiple computers.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140527/23d61457/attachment.html>


More information about the cryptography mailing list