💾 Archived View for rawtext.club › ~sloum › geminilist › 001005.gmi captured on 2020-11-07 at 01:55:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Thomas Karpiniec tkarpiniec at icloud.com
Sun May 24 00:04:29 BST 2020
- - - - - - - - - - - - - - - - - - -
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 thespec! I particularly like the insistence "Transient certificates MUSTNOT be generated automatically". I wasn't here for the earlierdiscussion but I assume this is to fend off servers making sessionspurely 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 wouldbe nice to use something smaller than UUID if possible just to keepcert 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 peoplemight be tempted to use) - and it slightly increases the complexity ofintegration between the TLS library and the client/server code.
When a server wants the client to use a non-disposable certificatethere is an ambiguity. Is it just because they want the user topreserve their authentication for more than 24 hours for convenience?Or is it because the user will permanently lose access to theiraccount if they ever lose that key?
Much like a bitcoin wallet, the latter is technically a very tidy andsecure solution but it absolutely sets up users to fail. People whoare auto-generating this authentication in regular clients will losetheir keys and be sad about it. By comparison, those who are settingup whitelisted keys out-of-band are likely more savvy and know whatthey're getting into.
With this in mind, my current opinion is that there should be no wayfor a server to request a non-disposable certificate. Whereauthentication is required, it should be done in-band via a passwordor username/password 10 responses as you noted, which is thenassociated on the server with the transient certificate. It thenbecomes the responsibility of clients to ask the user "how long do youwant to stay authenticated to this website?" If it times out, they cansimply repeat their authentication.
One argument against is that it encourages clients to choose very laxdeletion policies to reduce friction. This may not be as big a concernas it is on the web, since users will presumably only have a sessionwith a small fraction of the gemini sites they visit, so they are notpicking up transient tracking sessions willy nilly that need to beflushed out.
One final thought: do we need a way to encourage clients to havemultiple certificates for the same server, depending on path? If Iauthenticate to a CGI application on a multi-user server I don'tnecessarily want my identity to be followed by everybody else'sapplications on that server.
Cheers,
Tom