💾 Archived View for rawtext.club › ~sloum › geminilist › 001442.gmi captured on 2020-11-07 at 02:13:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Tue Jun 9 08:42:32 BST 2020
- - - - - - - - - - - - - - - - - - -
On Tue, Jun 09, 2020 at 12:40:07AM -0400, Sean Conner wrote:
It was thus said that the Great Michael Lazar once stated:
Heck, drop client certificates from the gemini specification all together.
Judging by the lack of client support so far, it's becoming clear that either:
1. They're a pain to implement compared to the rest of the specification
2. There's not much interest in actually using them
I personally would like to keep them, if only to protect sections of a
Gemini site from general consumption. The "transient client certificate"
idea is certainly problematic and I wouldn't mind if that concept went away
though.
I think it's probably a little too early in the game to interpet thelack of client support as a lack of interest in using them. Many peoplemight be holding off on implementing them in the expectation that thespec will change/simplify - which it surely will: I'm pretty much soldon deprecating the transient client certificate status codes. There'salso an obvious chicken-and-egg problem here, where client authors haveno incentive to add support until servers require it to accesscompelling content.
I too would like to keep *some* client cert support, though. I reallylike the idea of being able to self-host little productivity apps formyself which I can simply and reliably secure in an ssh-like fashion(add my self-signed cert fingerprint to the equivalent of anauthorized_keys file). And, yes, okay, that doesn't strictly require 6xstatus codes, the server could just immeditely cut the connection if itdidn't get a cert it liked. But it would be nice to be able togracefully use those apps from within an everyday client.
Mk's concern that "it'd be good not to hardwire SSL too strongly intoGemini, in case the tooling around an alternative improves sufficientlyin the future and we'd like to swap" is a valid one, though, and one Ihave (very occasionally) worried about. If nothing else this is a goodargument to keep our use of client certificates simple and perhaps notto make use in apps of anything beyond the cert fingerprint (i.e. don'trely heavily on the notion of Distinguished Names for Subject andIssuer)...
Cheers,Solderpunk