3 ms·

> HTML <keygen> tag has been around since Netscape Navigator 3, and still nobody uses it? StartSSL uses it for personal (email) certificates. I've tried using

> HTML <keygen> tag has been around since Netscape Navigator 3, and still nobody uses it? StartSSL uses it for personal (email) certificates. I've tried using it in a toy VPN project but dropped the idea mostly because I was unable to easily explain how to use those certificates afterwards (i.e. export them out of the browser's keystore, import them to smartphone and use with VPN without horrendous tens-of-steps tutorials that'd bore anyone to death). The issue is, almost nobody uses client X.509 certificates, so <keygen> is obviously unused, too. The core issue is, browser (and other software) vendors never gave a thought on improving horrendous UIs for certificate use and management. It's still hidden after 4-7 clicks away under some obscure names, and then it exposes almost raw X.509 data which asserts those casual users who found their way through the settings are scared away. I mean, something in this direction is a must: https://www.dropbox.com/s/xxfzf9ed4wfytkj/tls_auth_ui.png https://www.dropbox.com/s/xxfzf9ed4wfytkj/tls_auth_ui.png

peterwwillis 13y ago
It seems like the browser vendors (Netscape) never intended for there to be a UI for a good reason. It's intended to be used to (basically) transparently install and use a client cert. Each device can get its own key pair/client cert, and no UI is necessary to manage them.
- drdaeman 13y ago
  > no UI is necessary to manage them Not that simple, unfortunately. Even with per-device certificates (which is, I believe, the proper way - have a "master" one signed by remote party then sign your own per-device certs with those), users will still have to: 1. Chose the certificate they want to present to a server. Current UIs are plain terrible and scare every non-techie user (and techies who don't know about X.50x) away. This is absolutely a must, unless Netscape intended for certificate auth to be completely transparent to end user (which is bad, because many of us have multiple identities). 2. See and be notified in advance of certificate expiration times. I have multiple overlapping for half an year StartSSL client auth certificates just because I may forget about the expiration (and miss the notification email). This is not absolutely necessary, but quite important feature if we'd suddenly start to take client certificates seriously. 3. Interoperate with system-wide keystore (if there's any) for the cases certificates're going to be used outside of the browser (say, for VPN or Email S/MIME). This is not an absolute requirement, but very useful feature to have. I understand that when Netscape Navigator was young there probably wasn't system-wide keystores, though. 4. Securely backup the certificates if they're meant to me used as a master ones, not per-device.

peterwwillis 13y ago

It seems like the browser vendors (Netscape) never intended for there to be a UI for a good reason. It's intended to be used to (basically) transparently install and use a client cert. Each device can get its own key pair/client cert, and no UI is necessary to manage them.

drdaeman 13y ago
> no UI is necessary to manage them Not that simple, unfortunately. Even with per-device certificates (which is, I believe, the proper way - have a "master" one signed by remote party then sign your own per-device certs with those), users will still have to: 1. Chose the certificate they want to present to a server. Current UIs are plain terrible and scare every non-techie user (and techies who don't know about X.50x) away. This is absolutely a must, unless Netscape intended for certificate auth to be completely transparent to end user (which is bad, because many of us have multiple identities). 2. See and be notified in advance of certificate expiration times. I have multiple overlapping for half an year StartSSL client auth certificates just because I may forget about the expiration (and miss the notification email). This is not absolutely necessary, but quite important feature if we'd suddenly start to take client certificates seriously. 3. Interoperate with system-wide keystore (if there's any) for the cases certificates're going to be used outside of the browser (say, for VPN or Email S/MIME). This is not an absolute requirement, but very useful feature to have. I understand that when Netscape Navigator was young there probably wasn't system-wide keystores, though. 4. Securely backup the certificates if they're meant to me used as a master ones, not per-device.