[cryptography] Client certificate crypto with a twist
Joe St Sauver
joe at oregon.uoregon.edu
Wed Oct 10 11:34:24 EDT 2012
#3. Don't use the few hundred global certificate authorities to sign
# the client certificates. These CA's require extensive identity
# validations before signing a certificate.
Not sure I believe the premise that "extensive identity validation"
always happens before a client cert gets issued. For example, consider
the free secure email certificates that Comodo offers at
(as used in the client cert S/MIME training I did for MAAWG a while back,
see "Client Certs and S/MIME Signing and Encryption: An Introduction,"
The mapping in that case is just from the cert to the associated
email address, not to a real meat space identity. That's fine for
the usage case envisioned, obviously, and not a problem, just an
example of the fact that extensive identity validation is not always
needed or employed.
# These certificates are only useful when the real identity is needed.
# Currently, passwords provide better privacy but lousy security;
I think that client certs have a lot of potential even when the binding
may only be to an email address, and not to a "meat space" identity, to
tell you the truth.
I'm also not sure I'd agree that passwords provide "better privacy"...
#Clients can choose the CN they wish to have, that is, they can chooose
#their own username under which they wish to be known to your site.
#The CA of the web site signs the request (at sign-up time) when the CN
#is unique for the site. That's the only requirement.
My problem with this scheme is that I don't want Yet Another Account.
I don't care if it uses a username and password or a client cert, I just
don't want Yet Another Account. If I need to create Yet Another Account,
I will likely avoid the site that requires me to get Yet Another Account.
I'd really far rather see folks do something like Shibboleth for federated
authentication, as the sites that participate in InCommon do (see
http://www.incommon.org, ob disclaimer: I'm involved with Internet2 and
InCommon (which is an Internet2 project), but not directly with Shibboleth
and the InCommon federation effort).
The nice part about Shib, from a privacy POV, is that you only release/get
the attributes that may be necessary (thereby preserving user privacy).
Coming back to the client cert issue...
I will also say that an un(der) appreciated issue with client cert-based
auth is managing those credentials accross multiple devices (and these
days is there *anyone* that doesn't have multiple devices, multiple
browsers on each of those devices, etc.?)
Most client certs are easily downloaded and installed onto a single browser
on a single device. The trick then becomes "backing up" and migrating those
credentials to all the *other* devices and credential stores where they
might also be needed. (That process is NOT one that's
random-friends-and-relatives-friendly out-of-the-box IMHO.)
Some browsers also do a less-than-stellar job of handling multiple client
More information about the cryptography