My two cents: I don?t understand why server gets to decide if user?s certificate is transient or not. I as a user should make that decision. If they want to lose access to their Astro plant, that?s their decision. In my opinion there should just be one 6X status code, to request that user retries with a certificate. If user didn?t use one, meta field should explain why it is needed. If user used one - meta should explain why it was declined (expiry, invalid, etc) Using this logic, I would say status code 21 is similarly unnecessary. User should 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 seems to me that status 21 tries to implement a logout functionality from the web, where users have a jarfull of cookies and might not be able to delete the right one. In Gemini on the other hand, it can be a simple toggle switch. 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/6c95 230c/attachment-0001.htm>
---
Previous in thread (9 of 17): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (11 of 17): 🗣️ solderpunk (solderpunk (a) SDF.ORG)