On Mon, Jun 8, 2020 at 1:25 PM solderpunk <solderpunk at sdf.org> wrote: > > On Sun, Jun 07, 2020 at 10:00:02PM -0400, Michael Lazar wrote: > > > There are several other advantages to having a well designed path > > hierarchy. It's something that I often don't spend enough time > > thinking about up front and then I regret not doing it right later. > > This seems wise to me. It's already pretty clear that associating > client certificates with domains, as currently specced (for transient > certs, at least) and as implemented in AV-98, is not the best idea. It > will inevitably cause confusion/frustration/difficulty in environments > where multiple users share a domain (like pubnixes). Associating them > with paths seems the obvious solution. > > As the current leading implementer of client cert consumning apps, I'm > curious how you feel about the idea of using the <META> for 6x statuses > to convey an intended "path scope" for certs? > > Cheers, > Solderpunk I think hijacking the <META> is unnecessary for my application. I can accomplish the same thing by sending a "30 TEMPORARY REDIRECT" to all unauthenticated requests, and then hitting them with a 61 after they have been redirected to the path scope. I concede that this wouldn't be *exactly* the same because the client won't end up at the page that they originally requested. But it's workable enough for me. And I like having the meta available for human readable error messages. 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. Drop "64 FUTURE CERTIFICATE REJECTED" and "65 EXPIRED CERTIFICATE REJECTED" while you're at it, they can be subsumed by "63 CERTIFICATE NOT ACCEPTED". Heck, drop client certificates from the gemini specification all together. 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 2. There's not much interest in actually using them I get the vision behind the transient client sessions and fingerprinting stuff, and it really is a nice idea. But it's also very prescriptive and unproven. It sticks out when compared to the rest of the spec, which mostly borrows from tried-and-true patterns already seen in gopher/WWW. Best, Michael
---
Previous in thread (5 of 17): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (7 of 17): 🗣️ Sean Conner (sean (a) conman.org)