💾 Archived View for rawtext.club › ~sloum › geminilist › 000529.gmi captured on 2020-11-07 at 01:33:32. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Client certificates

solderpunk solderpunk at SDF.ORG

Tue Apr 21 08:51:50 BST 2020

- - - - - - - - - - - - - - - - - - - ```

On Mon, Apr 20, 2020 at 06:02:32PM -0400, Michael Lazar wrote: 
> - The client requests "gemini://astrobotany.mozz.us/" and receives a
>   "62 AUTHORISED CERTIFICATE REQUIRED" response.
> - The client generates a self-signed certificate and makes a second request to
>   the same endpoint. This certificate generation could be done through the
>   gemini client software itself, or the user could provide their own cert.
> - The server accepts the self-signed client certificate and saves a hashed
>   fingerprint of the peer cert. This fingerprint is now associated with that
>   user and represents a unique UUID that nobody else can spoof.
> - We kick the can down the road concerning the user needing to update or
>   re-associate their client certificate. We hope that they set an expiration
>   date far enough in the future for this to never matter.

Yes, this is more or less precisely as I imagined it working!

With "nice" clients, the user basically gets a prompt like "Would youlike to create a persistent identity for this service? Y/N", and if Y,the client itself generates and saves a self-signed certificate to usewithout the user having to drop to the commandline and use opensslcommands.  The cert is associated with a particular domain and, if theclient is set up to do so, can be used automatically for all requeststo that domain.  This gives a pretty fluid user experience: the userdoesn't need to understand anything technical about TLS at all.  Theyjust get a transparently working account which is basically bound tothe device/client they used at sign up (advanced users of course canexport/import cert-key pairs to multiple devices).  No passwords toforget, or to be brute-forced.  Even a full compromise of the server'sdatabase does not allow account hijacking, even with all the rainbowtables and time in the world, because the private key never leaves theclient.  Of course, good backups of the cert-key pairs becomesessential to avoid getting locked out of things after a diskfailure...

You raise good points about cert expiry.  Let's think about that.

Cheers,Solderpunk