💾 Archived View for rawtext.club › ~sloum › geminilist › 001450.gmi captured on 2020-09-24 at 01:52:35. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Tue Jun 9 19:39:23 BST 2020
- - - - - - - - - - - - - - - - - - -
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 issignalling that it's okay to use something temporary/disposable" - i.e.to make it clear this is not an Astrobotany-style application wherelosing your key/cert pair means forever losing access to your account.Clients can handle this however they want - some clients will implementgood support for transient certs which never hit the disk, and will bragabout that, and users who really care will use them.
In general, I was thinking of just having a bunch of 6x codes which allmean "you need a cert to get in here" but with different hints as towhat is expected - something you can generate yourself on the spot anddispose of when you like, something you can generate yourself on the spotand should take care to keep hold of (astrobotany style), or somethingpre-approved by the admin (which might mean a CSR process, or just afingerprint whitelisting). No prescribed behaviour for any of them,clients can give users as many or as few options for dealing with them asthe authors see fit, but at least this way they can convey enoughinformation 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 advancedand optional feature. People should not feel ashamed of writing aclient that just opts out of the whole thing. To some extent theexistence of good clients which do this will act as a defence againstpeople 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 astried-and-true from ssh.
Cheers,Solderpunk