💾 Archived View for rawtext.club › ~sloum › geminilist › 001015.gmi captured on 2020-10-31 at 01:59:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sun May 24 15:27:26 BST 2020
- - - - - - - - - - - - - - - - - - -
On Sun, May 24, 2020 at 09:04:29AM +1000, Thomas Karpiniec wrote:
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, transient sessions generated automatically and invisibly to theuser are not really any better than cookies. Of course, even though thtspec forbids is, there is a risk that clients start actually doing that.The fact that generating a certificate takes a small but noticableamount of time means this would not make for a good user experience,which I hope is incentive against it.
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.
The cert size concern is a good one (the lack of connection reuse inGemini means that TLS overhead is more of an issue than it otherwisewould be. This is one nice thing about self-signed certs, they willtypically be shorter as they won't have a long chain of intermediatesigning certs). I think Sean's solution of having the spec require asingle fixed nonce value is a good one. Having every cert identicalwith regard to subject/issuer prevents linking certs together just aswell as having every one be unique.
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.
I guess I am seduced to some extent by the ideas in FOAF+SSL. If thecert can refer to some other resource (a FOAF profile in that case, butwe wouldn't need to follow that) and that resource contains the certfingerprint to validate the connection, then client certificates can -if and only if the user wants them to! - be vehicles for richidentities under full user control.
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?
The former, i.e. the idea is that, unlike a transient certificate (whichhas the semantics of "I don't really care who you are and am not at allinterested in recognising you again next week, I just need to tietogether a handful of separate requests *right now*" - although thatidea can be destroyed if that handful of separate requests involves theclient providing a username and password), a non-disposable certificateis supposed to be a persistent identity - what people think of as a"user account" on the web.
In the simplest possible implementation of this, the server just usesthe cert hash as user ID and then, yes, we're in high-risk territorywhere if the user doesn't backup their keys and certs then a hard drivefailure or theft of a laptop or similar scenarios result in lock out.It doesn't *need* to work that way, though. An application which usersauthenticate to this way could give users the option to associate anemail address which could be used for the equivalent of "passwordrecovery" - email the user a URL with a random unique token in it andtell them the first new certificate which visits that URL sometime inthe next one hour will become linked to their account.
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.
Hmm, interesting. I'll ponder this, thanks for your thoughts. My firstreaction is that that I'm reluctant to remove a dedicated mechanism forcreating something which is unavoidably and non-negotiably very shortlived. Maybe you didn't mean for that to happen, though?
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.
Ah! I absolutely positively meant to bring this up in my original postto this thread. This is a very valid point. Right now, the spec (andmy proof-of-concept implementations in AV-98) associates client certswith a domain. The presence of many multi-user servers in Geminispace(and for what it's worth, I like those, a lot, assuming the usersconstitute a community in some sense beyond sharing a server) means thisis not necessarily going to work well. We could use the <META> contentof status codes which request a cert to specify a path or range of pathsfor which the cert should be used.
I'm, unsurprisingly, extremely out of touch with modern web development:are cookies still strictly tied to domains or have they evolved somekind of path-specificity?
Cheers,Solderpunk