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 -- Tony Arcieri
Received on Wednesday, 16 September 2015 19:13:29 UTC