[mortehu]

Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication, and a very small number of websites supported it. After Chrome became popular, those sites were forced to switch to a different form of second factor authentication, and it's fallen almost completely out of use.

Part of the reason was that the user interfaces for installing certificates were terrible, and websites needed to have guides on how to use it in each browser.

[bo1024]

Thanks. I’m still not clear what the authentication method is, but I don't see why we can’t have a one click browser button “give this site my public key” and another “authenticate to this site with my private key”.

[chipsa]

Who gives you the private key? Is it generated on the device? How do you move the keys to your different devices? I can end up working at any of 20 computers on a given day, not counting my personal devices.

[bo1024]

Not sure what the best solution is, but some thoughts. First, you definitely want a different keypair per device.

One approach is to just supplement passwords. You could use a password (2FA, etc) to log in, then the site gives you the option of adding that device's public key and from then on you can log in on that device automatically. The site would maintain a list of public keys associated with your account, just like github does for repositories.

Of course, if you don't trust those 20 work computers, you wouldn't want it set up so that anyone using them can log in to all your accounts. One thing the browser could do is password-protect your private key, so you have to enter the master password when you start the browser, and as long as you remember to exit out of the browser, the next person to use it won't be able to use your logins.

[Avamander]

> Before Chrome, all popular web browsers had a user interface for installing client side HTTPS certificates for user authentication

Chrome has an interface for it.

[mortehu]

Last I checked it could only install from the filesystem, and not directly generate a key and install a certificate through the web. Do you have an example site where this works with Chrome?

[jessaustin]

Has the goalpost been moved? Upthread you compared Chrome to "all popular web browsers [which] had a user interface for installing client side HTTPS certificates for user authentication". I just opened up Firefox, and found a very similar menu to Chrome's: the only option was to "import" a cert from the filesystem. I agree that we should expect more from our tools, but has any popular browser ever allowed the user to generate a new cert? If one were to do so, how would the generated cert be connected to PKI -- who would sign the cert and how would they do that?

[mortehu]

Yes, browsers other than Chrome can generate keys, submit the public key to a site you're logged into and install the certificate you get in response (usually after a second factor verification). I am not aware of any site that still does this, so I can't show it to you. Skandiabanken in Norway used to do it before Chrome.

You won't be able to see this in Firefox in any way other than visiting such a site.

[jessaustin]

Now I'm curious. This seems like a procedure that would need to be precisely defined. Is there a standard protocol for this? Does it have an RFC or similar I could read? If nothing else, it would be nice to have a short bumper-sticker "Chrome destroyed protocol X!" complaint.

[mortehu]

I did some digging, and I believe this was implemented with the <keygen> element and the generateCRMFRequest and importUserCertificate JavaScript functions.

https://bugzilla.mozilla.org/show_bug.cgi?id=1088063

[Avamander]

You can also use external enclaves/smart cards for key storage.

The specific feature you're now describing doesn't really exist in any browser, mostly because it kinda negates why people'd use PKI for.