💾 Archived View for rawtext.club › ~sloum › geminilist › 001463.gmi captured on 2020-11-07 at 02:14:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Peter Vernigorov pitr.vern at gmail.com
Tue Jun 9 21:23:55 BST 2020
- - - - - - - - - - - - - - - - - - -
My two cents: I don’t understand why server gets to decide if user’scertificate is transient or not. I as a user should make that decision. Ifthey want to lose access to their Astro plant, that’s their decision. In myopinion there should just be one 6X status code, to request that userretries with a certificate. If user didn’t use one, meta field shouldexplain why it is needed. If user used one - meta should explain why it wasdeclined (expiry, invalid, etc)
Using this logic, I would say status code 21 is similarly unnecessary. Usershould be able to decide if they want to stop using client certificate.AV-98 for instance allows user to do that (so does my iOS client). It seemsto me that status 21 tries to implement a logout functionality from theweb, where users have a jarfull of cookies and might not be able to deletethe right one. In Gemini on the other hand, it can be a simple toggleswitch.
On Tue, Jun 9, 2020 at 20:39 solderpunk <solderpunk at sdf.org> wrote:
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
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200609/6c95230c/attachment-0001.htm>