implementing client certificate support

[solderpunk]

On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote:
 
> For what it's worth, I have been thinking about reorganizing the URL
> structure for astrobotany so that all of the authenticated endpoints
> live behind a single path. I am also planning on adding more
> unauthenticated content to the server, so I want to establish a
> clear separation between the sections that require a client certificate
> and the sections that do not.
> 
> - gemini://astrobotany.mozz.us/
> - gemini://astrobotany.mozz.us/about
> - gemini://astrobotany.mozz.us/app (requires client certificate)
> - gemini://astrobotany.mozz.us/app/plant
> - gemini://astrobotany.mozz.us/app/directory
> - ...
> 
> There are several other advantages to having a well designed path
> hierarchy. It's something that I often don't spend enough time
> thinking about up front and then I regret not doing it right later.

This seems wise to me.  It's already pretty clear that associating
client certificates with domains, as currently specced (for transient
certs, at least) and as implemented in AV-98, is not the best idea.  It
will inevitably cause confusion/frustration/difficulty in environments
where multiple users share a domain (like pubnixes).  Associating them
with paths seems the obvious solution.

As the current leading implementer of client cert consumning apps, I'm
curious how you feel about the idea of using the <META> for 6x statuses
to convey an intended "path scope" for certs?

Cheers,
Solderpunk