Ben -
I am familiar with Google's Origin Bound Certificate (OBC) work, it in many respects is similar to the BrowserID proposal; and you are right that this happens at a layer below the user experience if there is no pin/password protecting the key. That said, unless something has changed recently (I have spent the last few years focusing on securing ad networks) since it's done as part of the TLS negotiation the authentication is persisted in the TLS session cache meaning a mechanism is still needed to "log-out" or "reset that session" and I don't believe one exists today. One problem I have with both BrowserID and OBC is that they don't really solve the initial authentication problem, this is true to a lesser extent for BrowserID because at least until recently they didn't even have a concept of a password. But as I understand OBC initial authentication happens via a traditional methods (aka passwords) and it is persisted via the "origin certificates"; this approach is better cryptographically than BrowserID in that you get the cryptographic binding of user authentication to the session-plus today BrowserID relies on Javascript based cryptography implementations which has a ton of shortcomings. With that said, on the surface OBC feels like it's not really trying to address authentication but a gap in cryptographic cookie support. One of the things I like about BrowserID as an approach is that I agree with others that the portability of key material in today's world is important and by them including the vetting of the ownership of an email in their key provisioning workflow they kind of address this problem. To be clear I am a fan of anything that moves the ball forward here, though I really wish as an industry we could align behind a problem statement and work towards it together instead of having so many competing approaches but it is human nature ;) Ryan From: Ben Laurie [mailto:[email protected]] Sent: Wednesday, February 08, 2012 9:49 AM To: Ryan Hurst Cc: Stephen Kent; Joe St Sauver; [email protected] Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) On 8 February 2012 17:18, Ryan Hurst <[email protected]> wrote: Steve, Thank you. I actually contributed to RFC 3709 and I believe made Windows the first platform to support it, that said the branding element I am referring to in this case is different. When designing a user experience one picks colors, typefaces, layout and workflow; for example consider Coke "red" and type typical Coke typography; if the authentication experience is not consistent with the design goals of a site adoption will only happen when security is seen more important that design and ease of use. As long as that is the case in this world of consumerization of IT I don't expect client certificates to be used outside of closed communities. Client certs do not need to interfere with the branding experience. For example, http://www.browserauth.net/ shows how to use them without touching the site's ability to fully control the user experience. Ryan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Wednesday, February 08, 2012 8:57 AM To: Ryan Hurst Cc: 'Joe St Sauver'; [email protected] Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) Ryan, That's a good list of additional problems associated with widespread use of client certs. Note that re the "branding" issue, there is a cert extension that allows for logos to be embedded in certs, although the focus for this is really server vs. client certs. 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
