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 have
access to a half-decent TLS library, does this flow make sense for self-signed
- 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 more
than the current solution now that I look at it.
More information about the Gemini