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

View Raw

More Information

⬅️ Previous capture (2020-09-24)

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

<-- back to the mailing list

Client certificates

Michael Lazar lazar.michael22 at gmail.com

Mon Apr 20 23:02:32 BST 2020

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

On Mon, Apr 20, 2020 at 2:20 PM solderpunk <solderpunk at sdf.org> wrote:
> While we're talking details on client certificates - I never envisaged
> client certificates being signed by the server they're destined for.
> This does no harm, but it also does no good, either, if the server signs
> them without any kind of validation process. In general I don't see a
> need for it and it just adds a lot of friction to the "signup process".
> But, I'm aware that lots of TLS libraries are very inflexible when it
> comes to certificate validation, and accepting self-signed client
> certificates may not be possible - I wouldn't be surprised if this was
> the cause for astrobotany, since Python's standard library is precisely
>one of these inflexible ones...

To be honest, I never even considered doing it that way. Assuming I haveaccess to a half-decent TLS library, does this flow make sense for self-signedclient certificates?

- 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.

Are there any flaws that I'm not seeing here? I actually like this a lot morethan the current solution now that I look at it.

- Michael