On Sat, May 23, 2020 at 09:57:14PM -0400, Sean Conner wrote: > > Or is it because the user will permanently lose access to their > > account if they ever lose that key? > > Of if they get logged out and forget the password? That can happen now, > so I don't think it's of much concern. Apologies for the double-reply; another thought occurred to me. Suppose that TLS just expects a parseable cert from the client, and the server application is only interested in the key type and fingerprint. Maybe expiry is not a significant concern? (After all, we don't normally expire passwords on the web.) A client could implement this using random keys and a permanent keystore if it wanted. It could simply regenerate its own certificate based on the same key when it wants to. That sidesteps the validity problem. Alternatively, a client could use a key derivation function based on a combination of a user-selected (hopefully high quality) password and the domain of the server. You would then be able to reestablish your identity at any time knowing just the password. If the key derivation method was enshrined as a best practice, you could then take your passwords with you when you try out different clients that implemented it. This would free applications from the main burden of my original proposal, which is having to add some sort of login/response system on top of the certificate. That is admittedly a hassle. I forgot to mention, thank you for the history of how the current certificate handling came to be! Very interesting. Cheers, Tom
---
Previous in thread (4 of 25): 🗣️ Thomas Karpiniec (tkarpiniec (a) icloud.com)
Next in thread (6 of 25): 🗣️ Katarina Eriksson (gmym (a) coopdot.com)