Forking thread as I fee compelled to discuss client certificates but I am not sure its related to the original thread.
I also worked on some moderately successful client certificate solutions, their success however was only possible because of the pain tolerance for the communities they served; by objective measures they just were not good enough and in my opinion the reasons are pretty straight forward, they are: 1. There is no way to "log out", by authenticating the user as part of the TLS session the authentication is cached with the session; browsers all (rightfully so) implement session caching, this means that to log out one in-essence needs to close the entire browser and in a world of tabs this is a total non-starter (as an FYI there is a hack to do this in IE but it's far from perfect - see http://www.unmitigatedrisk.com/archive/2007/03/12/29.aspx) 2. Usability, the bar for a usable system on the public internet is significantly different than that in a corporate or government environment; the basic separation of pin collection and credential selection alone makes the usability characteristics of the client authentication experience too poor to adopt broadly. 3. Theming and Branding, however hard it is for us as technologists to accept the ability for site the create an authentication experience that is consistent with the rest of their site is mandatory for adoption in these scenarios. 4. Reasonable certificate lifecycle management for un-managed environments, I think this has been solved to a great extent with Windows 7 and the WS-TRUST enrollment work they did; it works very well but that's just Window and just Windows 7. 5. Hardware support for smart cards, there is a resistance in the smart card community to normalize on a single card edge; PIV is probably the most reasonable one that is out there but it presumes management done in an environment like the DOD (admin keys, proprietary management apis, etc); There are lots of potential solutions but when at Microsoft I worked with folks on a specification (that is supported in Windows 7 and up) to try to address this - http://www.unmitigatedrisk.com/archive/2010/04/09/227.aspx On a related not, BrowerID goes a long way to address some of these concerns (though it has work to do yet). Ryan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Tuesday, February 07, 2012 2:26 PM To: Joe St Sauver Cc: [email protected] Subject: Re: [therightkey] Will the real RPF please stand up? At 12:05 PM -0800 2/7/12, Joe St Sauver wrote: >... > >This is actually a fascinating question, and one where the answer you >get for "Why don't people deploy client certs?" varies from person to >person. I attempt to capture a little of that in a talk I did a week or >so ago at Internet2/ESNet Joint Techs in Baton Rouge: > >"Client Cert Deployment Models and Hardware Tokens/Smart Cards" >http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf > >It wasn't possible to do an exhaustive analysis of that question in a >20 minute slot, but you can at least get an idea of what we're seeing... I think there are multiple reasons why client certs have not taken off, based on 20+ years of experience in the area. We provided a client cert system for a financial firm in the early 90's. It was easy to use, bootstrapped from the password-based system that the firm used. But, because there were no good tools to allow users to move certs and private keys among client machines, it was eventually turned off. >... > >FWIW, even the Feds issue multiple certs, if only because some need to >be non-repudiable (e.g., for signing) while others need to be escrowed >for potential recovery (or authorized monitoring) of encrypted content >(at least in a Federal environment). The 3-cert CAC is not what I was suggesting. (And the reasons there are separate certs for sigs vs. key transport is because users need to perform key recovery for themselves for old e-mail, rather than for monitoring.) What I was advocating is certs with different IDs, each appropriate for a well-defined set of contexts, issued by CAs that are authoritative for identity in specific contexts. >That said, given my druthers, I'd prefer a single client cert to use >for MOST purposes, just as I prefer to use a single PGP/GPG key -- it's >easier, and reduces correspondent confusion. It is easier, but is undermines privacy and raises the question of what CA is appropriate for ALL contexts. >... > >I'd also assert that the cost of the cert is trivial relative to the >cost of the secure storage device that might hold the cert (e.g., a USB >format hard token, or a smart card and reader). The cost of managing a cert has a lot to do with the nature of the relationship between the issuer and subject, and the liability that the CA incurs as a result of issuing the cert. For example, I have relationships with credit card issuers. They make money when I use my cards. If they issued certs to me, that could be used in lieu of plastic, because they believed the security could be better, I probably would not pay for the cert. >... >I concur that multiple certs equal user confusion unless you can really >make it pretty darn clear (e.g., [email protected] or >[email protected], for example). not the sort of IDs I had in mind. I have an identity with Visa, with Amex, with UA, US, Hertz, Avis, etc. Each is authorized to identify me in certain contexts, and my ID is context specific. I also have a relationship entities who provide e-mail services, and they are the best entities to act as CAs when my e-mail address is the subject name. It's not about signing vs. encryption, but more about what entity is authoritative for identifying me. >... > >An interesting approach, BTW, is the one that CILogon takes, leveraging >federated authentication to mint certs for secure access to cyber >infrastructure -- see http://www.cilogon.org/ for more information >about this approach, if interested. federated authentication systems using certs generally seem to be motivated because folks can make cross-certification work properly. other federated auth systems seem to be based on having one org trust another to assert and identity for a user know to the second, but not the first. that's a recipe for secruity problems. Steve _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
