- From: Henry Story <henry.story@co-operating.systems>
- Date: Wed, 16 Sep 2015 20:36:17 +0100
- To: Tony Arcieri <bascule@gmail.com>
- Cc: Alex Russell <slightlyoff@google.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, Mike O'Neill <michael.oneill@baycloud.com>, Rigo Wenning <rigo@w3.org>, "public-web-security@w3.org" <public-web-security@w3.org>, WebAppSec WG <public-webappsec@w3.org>
> On 16 Sep 2015, at 20:12, Tony Arcieri <bascule@gmail.com> wrote: > > On Wed, Sep 16, 2015 at 12:06 PM, Henry Story <henry.story@co-operating.systems> wrote: > Before I discovered <keygen> we were adding keys to Firefox using the > puposefully difficult to find certificate properties file. To get users to do > this could be exceedingly difficult. Even if they did succeed it would increase > the likelyhood that they would mistakenly add Root Certificates to the keystore. > And even if they managed to place the keys in the right certificate slot the > danger would be that they would add client certificates with private keys known > to other entities, which is very bad practice. > > These are issues of Browser and OS design where ease of use is as important > as security of the crypto protocol. We can't say that the current situation is > great: it is a first step on which should have evolved a lot further over the > past years. > > Yes, that's true, but the UX of <keygen> is abysmal: > > 1) Browser generates key with <keygen> and sends it to the server to be signed > 2) The next response, the user is prompted to install the certificate. The page must now tell the user to acknowledge the browser wants to install the certificate, and do something like follow a link or refresh the page. This is a confusing and jarring workflow > 3) After the user has the certificate installed and makes another request, the user is now prompted for which certificate to use. They have to choose the certificate they just installed. Hopefully they're able to figure out what this is. If more than one site is using <keygen>, the user must pick the correct certificate for the site > > This is a terrible user experience. If client certificates were origin-bound, it would eliminate the need for the user to select the appropriate certificate for the site. > > Compare to something like a U2F token: > > 1) User enrolls the token by pushing a button > 2) User authenticates by pushing a button Yes, what FIDO has helped is to make progress by taking on only one use case. But it does not cover the use case of cross origin identification. For that some more User Interface innovation is needed. This would require something along the lines of what I posted to the TAG and I'll repost here: https://lists.w3.org/Archives/Public/www-tag/2015Sep/0063.html [[ So part of the problem is of course that since the inception of `<keygen>` JS has taken over and we end up with problems of which agent actually is responsible for which action. This has corrupted the intended meaning of the <keygen> tag. ( I have been thinking in my work about the intention of keygen - well aware that the reality of it had not been developed to the full ) In this case since the keystore is being affected and the user did not click the button - it makes sense that the toolbar indicating insertion of the certificate should allow the user to decide whether to accept that action. Of course you'll answer: how does one get the user to understand what that action means? This would require an intuitive Identity UI - based on a card and wallet metaphor perhaps - which has to be consistent throughout the web and even the OS experience. An action of adding a certificate to such a keystore has to make it visible as such a card being added to the wallet. This is only needed if the card is to be used cross origin. So for example the current FIDO UI would not need that. Addition of cards to the wallet should be sortable by origin in the wallet. Origins that add a lot of useless cards to spam the user, should be deselectable by the user in bulk, and he should be able to either limit their use to that origin, or delete them, and refuse further ones from them. It seems that making the origin of a card visisible is another important element of this. What this suggests is that the keygen tag during the process of calculating the public private key should open an empty card and have some way of indicating to the user that the action of producing one is in gear. This again is part of the chrome/OS and should not be something the page can hide. This is the type of thing that is needed to put the user in control. It's along the lines of the marketing that is going into fingerprint authentication making its way into phones. This would be required whatever the type of support for the card. (X509 is just an accident here ). From the User's point of view: the card UI is what is real, meaning that better formats can change under the hood. ]] > > -- > Tony Arcieri
Received on Wednesday, 16 September 2015 19:36:53 UTC