|  |  |  |  |  |  |  |  |  |  |  |  | 
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post | 
From: Thomas Hardjono <hardjono@MIT.EDU> To: Ben Laurie <benl@google.com>, Cryptography <cryptography@metzdowd.com> CC: "hardjono@mit.edu" <hardjono@mit.edu> Date: Thu, 6 Aug 2009 17:21:08 -0400 In-Reply-To: <1b587cab0908050658s4f247bf3j8428d3b7b005a5c6@mail.gmail.com> Ben, Having worked at a large CA for along time (trying to push for client-side = certs with little luck), here are some thoughts on what Chrome could provid= e: (a) Association with net identities: Provide some way for the user to assoc= iate his/her X.509 cert with an "internet identity" string (eg. OpenID, ema= il address, etc etc) in the browser. (Yes, we could add such an identity in= the SubjAltName, but that's outside the control of the end-user). This wou= ld allow the user to choose which cert to deliver to the server when the us= er is engaging the server using one of his/her identities.=20 (PS. being able to associate with a small image/icon/photo of the user woul= d also be nice). The UI should be a simple as click cert and click identity, and then click = associate. (b) Export of certs: Provide an easy way to export client-certs to other ap= ps. Currently some CAs use the browser as the primary means for cert enrol= lment. Currently in IE this is somewhat a lengthy process and the response = (ie. export of cert successful or not) is also not very clear to the end-us= er. The UI should not even talk about "export". It should say something along t= he lines of "Do you want to make your certificate available to the followin= g Apps". (c) Lock showing which cert/identity used: It would be useful if in additio= n to the Lock symbol (ie. SSL session established) there is a string (next = to the Lock symbol) showing which client-side cert the browser is using for= that SSL session. This is related to item (a) above, where a human-readabl= e net identity is associate with the cert. This helps the user in distinguishing which identity he/she is using when c= onnecting to a Bank versus a Blog versus a corporate web-mail (all of which= could be using distinct cert/identity). If there is a mismatch, the user c= an see this visually. (d) Notification of expired certs: It would be good if the browser could s= omehow notify the user if there are some expired certs (belonging to the us= er) in the browser. I'm finding that some browsers deliver the first cert i= n the list even when it has expired (thus causing the server to reject). (e) Better notification/alerts of errors regarding server-certs: This is a= hard one as the average user (eg. my Mom) does not understand about certs = to begin with. Since one of the main aims of SSL server-certs today is to p= revent phishing, perhaps those messages should be "phishing-oriented". This one need further thought, but perhaps a third button/option could be p= rovided (in addition to the Cancel and Continue buttons). This third button= could provide the user with some alternate sites with similar sounding dom= ain names but with proven/valid server-certs. (f) Better graphical representation of cert hierarchy: Perhaps not crucial,= but a nice graphical representation of the cert hierarchy/tree might help = educate the average user (my Mom/Dad) about what a CA is and where the user= is located in the hierarchy. This would even help the average employee whe= n his/her company is using a subordinate CA off a public CA. When the user clicks on a node in the tree, it should show the organization= name and other human friendly details. (g) Easy check button for server-certs: It would be great if I could right-= click the Lock symbol on the browser and be able to choose an action along = the lines of "Validate Server Certificate". The browser would then hit the = corresponding OCSP Responder (as denoted in the server-cert) and report the= status to the user using some graphical notation (eg. icon of server with = a big X if the server-cert is invalid or status unknown). That's all for now. Will send more thoughts if any come up :) /thomas/ > -----Original Message----- > From: owner-cryptography@metzdowd.com [mailto:owner- > cryptography@metzdowd.com] On Behalf Of Ben Laurie > Sent: Wednesday, August 05, 2009 9:59 AM > To: Cryptography > Subject: Client Certificate UI for Chrome? >=20 > So, I've heard many complaints over the years about how the UI for > client certificates sucks. Now's your chance to fix that problem - > we're in the process of thinking about new client cert UI for Chrome, > and welcome any input you might have. Obviously fully-baked proposals > are more likely to get attention than vague suggestions. >=20 > I imagine I may well hear "what about the UI around server > certificates?" - fair enough, feel free, and I'll see what I can do. >=20 > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > majordomo@metzdowd.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
|  |  |  |  |  |  |  |  |  |  |  |  | 
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |