implementing client certificate support

[solderpunk]

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 the
lack of client support as a lack of interest in using them.  Many people
might be holding off on implementing them in the expectation that the
spec will change/simplify - which it surely will:  I'm pretty much sold
on deprecating the transient client certificate status codes.  There's
also an obvious chicken-and-egg problem here, where client authors have
no incentive to add support until servers require it to access
compelling content.

I too would like to keep *some* client cert support, though.  I really
like the idea of being able to self-host little productivity apps for
myself which I can simply and reliably secure in an ssh-like fashion
(add my self-signed cert fingerprint to the equivalent of an
authorized_keys file).  And, yes, okay, that doesn't strictly require 6x
status codes, the server could just immeditely cut the connection if it
didn't get a cert it liked.  But it would be nice to be able to
gracefully use those apps from within an everyday client.

Mk's concern that "it'd be good not to hardwire SSL too strongly into
Gemini, in case the tooling around an alternative improves sufficiently
in the future and we'd like to swap" is a valid one, though, and one I
have (very occasionally) worried about.  If nothing else this is a good
argument to keep our use of client certificates simple and perhaps not
to make use in apps of anything beyond the cert fingerprint (i.e. don't
rely heavily on the notion of Distinguished Names for Subject and
Issuer)...

Cheers,
Solderpunk