3 ms·
Each person should pay for a client SSL certificate that they use to authenticate themselves on the web.
by x5n1 11y ago
Each person should pay for a client SSL certificate that they use to authenticate themselves on the web.
- deleted 11y ago[deleted]
- drdaeman 11y agoI would've loved if I could just use a self-generated certificate to authenticate. Especially if they'd be on HSM like YubiKey/NitroKey. Heck, there's even <keygen> element in HTML5, so this could've been quite user-friendly hassle-free. I could consider paying someone to assert my identity, or get some assertions for free, or whatever - the possibilities could be limitless. However, there are few issues with this. 1. We're currently stuck with X.509 and those don't allow subkeys or multiple signatures. 2. Then, the problem is that, AFAIK, there's no way to tell in that we accept just anything in TLS. I think there were a lot of discussions about allowing spontaneous authentication (changing state machine to allow TLS client to send certificate without CertificateRequest) or adding hacks like DN=WebID, but none is here. My memory's blurry in this regard - I've read about this about an year or two ago, sorry. But I'm certain there were some issues here. 3. Then, the problem is, browser UI and UX for managing certificates are terrible. There weren't any changes in this area for decades, and everything about those is deep hidden. Then, there are no subkeys and no cross-browser sync or key escrow mechanisms (opt-in, absolutely), so it's very unlikely to be useable by average person. And so on. So, format is not ready, protocol is not ready and browsers are not ready. Thus, sad but no, it's not going to work.
- deleted 11y ago[deleted]