[cryptography] Client TLS Certificates - why not?
Joe St Sauver
joe at oregon.uoregon.edu
Mon Mar 4 19:26:40 EST 2013
#Can anyone enlighten me why client TLS certificates are used so rarely? It
#used to be a hassle in the past, but now at least the major browsers offer
#quite decent client cert support,
Not quite seeing eye-to-eye with you on the "quite decent client cert
support" point, I'm afraid. Client cert user interaction still deserves
poor marks for complexity and user opacity, I think.
I did a preconference seminar for Educause Security Professionals 2012 on
client certificates, and it's actually sort of surprising how deeply buried
many bits of the current browser client cert implementation are. See
Or consider the level of native OS support for USB format PKI hard tokens
or smart cards on some operating systems, just to mention another example
of how client certificate support is still not really ready for prime time
at this point.
[In fact, if anyone's looking for a nice paper topic, I think a terrific
topic might be "Why Johnny Can't Ecrypt Using Client Certs, Either"
modeled on http://static.usenix.org/events/sec99/whitten.html ]
#and seeing how most people struggle with passwords, I don't see why
#client certs could not be beneficial even to "ordinary users".
Client certs *could* be hugely beneficial to even ordinary users --
imagine their use for EAP-TLS authentication, for example.
The devil, as always, is in the details.
Assume the average person has multiple devices these days -- maybe a
desktop at work, a laptop for travel, a tablet at home, a smartphone, etc.
If I want to use client certs for encryption/decryption, I need the *same*
cert on all of those devices, or on a portable device (such as a USB-format
PKI hard token, or a smart card) so I can take my credentials with me.
Sync'ing certs from one device to another isn't totally impossible, but
backing up, manually transfering and reinstalling certs on multiple devices
really isn't simple enough for most mere mortals. [Attempts to deploy a
unique client cert to each device have issues of their own that we'll
skip for the purposes of this note]
Smart cards or USB-format PKI hard tokens are a nice alternative, but
somewhat expensive, and you can't just run down to your favorite local
office supply store or neighborhood compute supply store and buy one.
Then there's the fact that not all devices easily accomodate USB-format
PKI hard tokens or smart cards, but if you *are* able to use a USB format
PKI hard token or smart card, at least the credentials stored on those
devices can be stored in a non-exportable format, which is good given
the uptick in malware's that has reportedly been scraping client certs
Smart cards or hard tokens are also required if you're shooting for the
highest NIST LOAs, but there's so much more that's required to get there
that in many ways the use of smart cards or hard tokens is a minor
matter relative to identity proofing requirements and all the rest of
what's require -- and it's hard to find anyone who actually needs LOA-4,
at least in higher ed.
Speaking of identity proofing, many times client certs only map to email
addresses, not to "real names," and not to guaranteed-unique and
never-to-be-reused arbitrary identifiers (like the EPPN). Some may find
that choice less than full satisfactory.
Or let's talk about key servers/directory models. Let me wave my magic
wand and magically create an Internet-wide directory for client certs,
perhaps modeled on PGP public key servers. Unfortunately, I don't see
much interest in fielding an animal of that sort, and w/o it, you're
either reduced to enterprise-level directories, or the painful process
of requesting a signed message to bootstrap key exchange for encryption
And the list goes on...
Bottom line, I think that there's still a lot of work ahead if you want
to do client certs at scale...
Disclaimer: all opinions strictly my own.
More information about the cryptography