Hi Guido! #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 http://www.comodo.com/home/email-security/free-email-certificate.php (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," http://pages.uoregon.edu/joe/maawg24/maawg24.pdf ) 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 certificates IMHO. Regards, Joe _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
