[cryptography] Client TLS Certificates - why not?

[Joe St Sauver]

Hi,

strife asked:

#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
http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf

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 
of late.

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
purposes (yuck)

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...

Regards,

Joe

Disclaimer: all opinions strictly my own.
_______________________________________________
cryptography mailing list
cryptography at randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE