[cryptography] Client TLS Certificates - why not?

ianG iang at iang.org
Mon Mar 4 03:08:05 EST 2013

On 4/03/13 10:22 AM, strife at riseup.net wrote:
> Hi,
> Can anyone enlighten me why client TLS certificates are used so rarely?

My thoughts only, not authoritative.

The big answer today is momentum, I would say.

In the past, I would say that forces were deployed against TLS 
certificates.  The CAs did not push them because the market for selling 
client-side certificates at a commercially sensible price wasn't there, 
it's a loss making proposition.  Still isn't/is.  But what they did do 
successfully is convince people that certificates not signed by 
browser-CAs were evil.  They got their cake and their still eating it.

The combination of these forces pushed all the developers over to 
passwords, and they've been on that since forever.  Same cake, now about 
18 years old, and causing predictable tummy aches.

> It
> used to be a hassle in the past, but now at least the major browsers offer
> quite decent client cert support, and seeing how most people struggle with
> passwords, I don't see why client certs could not be beneficial even to
> "ordinary users".

Browsers need a couple of things:  create a new cert on the fly, and to 
fix the certs on a per-site level.  But more than anything, they need to 
get their heads out of committee holes and start doing real security 
work for themselves.  Thankfully that seems to be happening over at google.

> With CAcert, there is even an excellent infrastructure in place that could
> allow people to generate signed pseudonymous client certificates. A
> service provider could limit the amount of certificates allowed per user
> (as validated by CAcert), maybe even the amount of points required etc.

As you mentioned it:  CAcert tried to move all its infra over to 
certificates.  The results were mixed.  Some things worked very well, 
somethings less well.  However, the places where things worked less well 
were pretty much all to do with the software just not evolving in that 

My personal experience is that writing the cert-based user 
authentication is easier and more robust than writing the password 
authentication system.  (I've done both in PHP.)  But it does require a 
bit more than copycat design :)  For example, one has to find a way to 
handle multiple certs for the same person, which requires one to stress 
the claims of the CA more than they are capable of being stressed.  In 
particular, if cert A says "John Smith" and cert B says the same "John 
Smith", are we happy?  I was... but I had to windmill it a little.

> That way, one could provide services without the requirement of
> registration, and still effectively limit abuse?

Certs solve the spam problem, and the password security problem.  And 
the phishing problem.  Oh, and the lost password problem, as a bonus :)

More or less, or, at least, certs lift the bar a long way.

What's more, if they were used more often, and client & server software 
were to evolve to respect them, we'd be halfway to a decent security 
model.  For example, properly used (afair, impossible in current 
browsers because we can't easily get general signing access to the certs 
from say javascript) we'd be able to use the certs for proper 
transaction signing, which would get us decent accounting software 
instead of the "don't click Pay twice" nonsense standard aka online banking.


More information about the cryptography mailing list