💾 Archived View for rawtext.club › ~sloum › geminilist › 001012.gmi captured on 2020-09-24 at 02:10:53. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Thomas Karpiniec tkarpiniec at icloud.com
Sun May 24 05:06:54 BST 2020
- - - - - - - - - - - - - - - - - - -
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, andthe server application is only interested in the key type andfingerprint. Maybe expiry is not a significant concern? (After all, wedon't normally expire passwords on the web.)
A client could implement this using random keys and a permanentkeystore if it wanted. It could simply regenerate its own certificatebased on the same key when it wants to. That sidesteps the validityproblem.
Alternatively, a client could use a key derivation function based on acombination of a user-selected (hopefully high quality) password andthe domain of the server. You would then be able to reestablish youridentity at any time knowing just the password. If the key derivationmethod was enshrined as a best practice, you could then take yourpasswords with you when you try out different clients that implementedit.
This would free applications from the main burden of my originalproposal, which is having to add some sort of login/response system ontop of the certificate. That is admittedly a hassle.
I forgot to mention, thank you for the history of how the currentcertificate handling came to be! Very interesting.
Cheers,
Tom