implementing client certificate support

[mbays at sdf.org]

* Sunday, 2020-06-07 at 20:37 +0000 - solderpunk <solderpunk at SDF.ORG>:

>On Sun, Jun 07, 2020 at 08:54:39PM +0200, mbays at sdf.org wrote:
>
>> ### Using identities
>> * An identity can be set to be used on a given server at and below a given
>> URI path. So you can have one identity in use for
>> gemini://foo.bar/~quux/..., and another for gemini://foo.bar/~xuuq/...
>
>How does a certificate come to be restricted to a given URL path and 
>subpaths?

If an identity starts being used as the result of a 6* response to 
a request, then the identity is subsequently used for all requests to 
that path and anything below. Same if the "identify" command is used on 
an URI.

This doesn't work entirely smoothly with astrobotony -- you might start 
using our certificate at gemini://astrobotany.mozz.us/plant/, so it then 
also takes effect for gemini://astrobotany.mozz.us/plant/water and so 
on, but if you try e.g. gemini://astrobotany.mozz.us/settings you have 
to select the identity again. You can manually "identify 
gemini://astrobotany.mozz.us", but that isn't so smooth. Probably marks 
should optionally have an identity associated -- that would help quite 
a bit, but needs some forethought from the user.

If this method of restricting an identity to subpaths of the path it's 
first requested at became normal, maybe servers would tend to arrange 
everything which requires a certificate below a single "gate" root.

>I have been thinking that perhaps the <META> line for status coedes 6x 
>could be used for the server to specify precisely this information.

That could work.

Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200608/a05b2f1c/attachment-0001.sig>