💾 Archived View for rawtext.club › ~sloum › geminilist › 000527.gmi captured on 2020-09-24 at 02:30:32. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
<-- back to the mailing list
Client certificates

solderpunk solderpunk at SDF.ORG
Mon Apr 20 19:19:56 BST 2020
- - - - - - - - - - - - - - - - - - - ```

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 toidentify the client to different servers.  A universal clientcertificate 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 youprovide a cert path when starting AV-98 and it's used for everything.  Ishould clarify that this way of handling client certs was added to AV-98as 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 makessense that they would work similarly.  The META part of response headerswith status 6x have no explicit semantics yet - it's possible we couldimplement a syntax for binding certificates to subdomains?  Or evenpaths?

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 wouldbe a pretty unpleasant user experience!  I would expect clients not touse client certificates by default and not to ask the user about clientcertificates 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 toa site, I guess it would be handy if the client offered a "Remember me"option, such that the same certificate would then automatically be usedfor all connections to that domain (which would involve saving the keyand certificate to disk, presumably in some client-specific location).This way one could automatically and invisibly log in to places likeastrobotany on each visit.  One of course could reverse this decision atany time.

While we're talking details on client certificates - I never envisagedclient certificates being signed by the server they're destined for.This does no harm, but it also does no good, either, if the server signsthem without any kind of validation process.  In general I don't see aneed 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 itcomes to certificate validation, and accepting self-signed clientcertificates may not be possible - I wouldn't be surprised if this wasthe cause for astrobotany, since Python's standard library is preciselyone of these inflexible ones...

Cheers,Solderpunk