Client certificates

[solderpunk]

On Mon, Apr 20, 2020 at 04:02:00PM +0300, Ciprian Dorin Craciun wrote:
 
> On Mon, Apr 20, 2020 at 12:23 AM Julien Blanchard <julien at typed-hole.org> wrote:
> > When trying to implement client certificate support in my client I
> > wondered whether or not we would want to be able to use different
> > certificates for different gemini places?
> 
> I would definitively want to have different "personas" for different
> sites.  In fact even for the same site I would like to have different
> ones, for example:  one for administrative purposes, and one for
> normal (but authenticated) access.

Yes, absolutely the idea is that different certificates would be used to
identify the client to different servers.  A universal client
certificate would allow server admins to compare logs and track users.

Possibly this question was provoked by the way the (wonderful!)
astrobotany app advices people to use client certs with AV-98, where you
provide a cert path when starting AV-98 and it's used for everything.  I
should clarify that this way of handling client certs was added to AV-98
as a kind of quick-and-dirty way to get the astrobotany app usable.
It's not supposed to be the standard way of using client certificates.

> > I figured why not so started I my implementation by searching for a
> > certificate that matches the host domain name like
> > astrobotany.mozz.us.key and astrobotany.mozz.us.crt.
> > Does it make sense? Where should one put its certificates if such a
> > place exists in a filesystem?

Transient certificates are explicitly bound to a domain in the spec.
Nothing is said about non-transient certificates, but I guess it makes
sense that they would work similarly.  The META part of response headers
with status 6x have no explicit semantics yet - it's possible we could
implement a syntax for binding certificates to subdomains?  Or even
paths?

I should remind myself how this works for cookies...
 
> Automatically choosing a client certificate and presenting it to the
> server, I believe is a bad idea from a privacy perspective.  I would
> implement something like this:  when connecting to a domain for which
> one could use a client certificate, ask the user the first time if he
> wants to:
> * always use the same certificate for that particular domain;
> * wants to use a particular certificate (assuming there are multiple),
> but prefers to confirm it for each new "tab" (or browsing context);
> (i.e. sort of "last-used" but "confirm";)
> * never use any certificate;

Bugging the user about certs upon each connection to a new domain would
be a pretty unpleasant user experience!  I would expect clients not to
use client certificates by default and not to ask the user about client
certificates until receieving a response with a status of 60, 61 or 62.

When a user opts to generate a new non-transient certificate to send to
a site, I guess it would be handy if the client offered a "Remember me"
option, such that the same certificate would then automatically be used
for all connections to that domain (which would involve saving the key
and certificate to disk, presumably in some client-specific location).
This way one could automatically and invisibly log in to places like
astrobotany on each visit.  One of course could reverse this decision at
any time.

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...

Cheers,
Solderpunk