Hi! On Sat, May 23, 2020 at 02:56:38PM +0000, solderpunk wrote: > Gemini specs a lot of use for client certificates - partially because > they're a nice tool for the job, partially because the design goal of > maximising power-to-weight ratio means once you accept the weight of > using TLS you'd better implement everything you can using TLS rather > than adding yet another pile of concepts. This was the thing that stood out most on my first read-through of the spec! I particularly like the insistence "Transient certificates MUST NOT be generated automatically". I wasn't here for the earlier discussion but I assume this is to fend off servers making sessions purely for tracking purposes by default. > Right now, AV-98 fills the "Subject" of transient certs with > random unique values from Python's `uuid` module, because I seemed > to encounter errors sending totally empty certificates to > conman.org. I've seen similar problems before with custom usage of X.509. It would be nice to use something smaller than UUID if possible just to keep cert size down - provided there is library support as you noted. > There is a third scenario, which the spec does not explicitly discuss at > all, but which is actually the most widely used scenario in Geminispace > so far, which is the main reason that I want to kick off a discussion > about this and change the spec if required. It's the idea of persistent > identity (basically, a "user account") at a server which is not under > the client's control. > ... > We could change 62 to specify that the META should be a plain-language > message to users, which could disambiguate the scenario. Something > else to consider here is that astrobotany uses the Common Name part of > the certificate for the username. I like this idea a lot, but > different applications may want different or additional user > information, and using META to convey this information could work well. I'm not a big fan of using certificate fields for anything meaningful - it's a side channel (surrounded by lots of other fields that people might be tempted to use) - and it slightly increases the complexity of integration between the TLS library and the client/server code. When a server wants the client to use a non-disposable certificate there is an ambiguity. Is it just because they want the user to preserve their authentication for more than 24 hours for convenience? Or is it because the user will permanently lose access to their account if they ever lose that key? Much like a bitcoin wallet, the latter is technically a very tidy and secure solution but it absolutely sets up users to fail. People who are auto-generating this authentication in regular clients will lose their keys and be sad about it. By comparison, those who are setting up whitelisted keys out-of-band are likely more savvy and know what they're getting into. With this in mind, my current opinion is that there should be no way for a server to request a non-disposable certificate. Where authentication is required, it should be done in-band via a password or username/password 10 responses as you noted, which is then associated on the server with the transient certificate. It then becomes the responsibility of clients to ask the user "how long do you want to stay authenticated to this website?" If it times out, they can simply repeat their authentication. One argument against is that it encourages clients to choose very lax deletion policies to reduce friction. This may not be as big a concern as it is on the web, since users will presumably only have a session with a small fraction of the gemini sites they visit, so they are not picking up transient tracking sessions willy nilly that need to be flushed out. One final thought: do we need a way to encourage clients to have multiple certificates for the same server, depending on path? If I authenticate to a CGI application on a multi-user server I don't necessarily want my identity to be followed by everybody else's applications on that server. Cheers, Tom
---
Previous in thread (1 of 25): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (3 of 25): 🗣️ Sean Conner (sean (a) conman.org)