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 client 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 more than the current solution now that I look at it. - Michael
---
Previous in thread (3 of 6): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (5 of 6): 🗣️ solderpunk (solderpunk (a) SDF.ORG)