implementing client certificate support

[solderpunk]

On Tue, Jun 09, 2020 at 12:01:28AM -0400, Michael Lazar wrote:
 
> Any complexity that we can remove from the spec surrounding client certificates
> is a strong positive. I'm in favor of deprecating the 61 and 21 status codes.

I was thinking of dropping 21 and "softening" 61 to mean something like
"you need a certificate to access this resource, and the server is
signalling that it's okay to use something temporary/disposable" - i.e.
to make it clear this is not an Astrobotany-style application where
losing your key/cert pair means forever losing access to your account.
Clients can handle this however they want - some clients will implement
good support for transient certs which never hit the disk, and will brag
about that, and users who really care will use them.

In general, I was thinking of just having a bunch of 6x codes which all
mean "you need a cert to get in here" but with different hints as to
what is expected - something you can generate yourself on the spot and
dispose of when you like, something you can generate yourself on the spot
and should take care to keep hold of (astrobotany style), or something
pre-approved by the admin (which might mean a CSR process, or just a
fingerprint whitelisting).  No prescribed behaviour for any of them,
clients can give users as many or as few options for dealing with them as
the authors see fit, but at least this way they can convey enough
information to the user for them to make an informed choice.

> Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED"
> while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED".

I expect Sean to object to this...
 
> 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

This is true.  I may amend the spec the explicitly call them an advanced
and optional feature.  People should not feel ashamed of writing a
client that just opts out of the whole thing.  To some extent the
existence of good clients which do this will act as a defence against
people putting stuff behind certificates without very good reason.

> It sticks out when compared to the rest of the spec, which mostly borrows from
> tried-and-true patterns already seen in gopher/WWW.

I like to think of at least the pre-approved cert workflow as
tried-and-true from ssh.

Cheers,
Solderpunk