💾 Archived View for rawtext.club › ~sloum › geminilist › 001092.gmi captured on 2020-09-24 at 02:07:35. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Martin Keegan martin at no.ucant.org
Wed May 27 19:37:02 BST 2020
- - - - - - - - - - - - - - - - - - -
On Wed, 27 May 2020, solderpunk wrote:
must present its cert; to present the cert, the client must be asked to do
so by the server; but the server doesn't know it should ask for the
certificate before the client has said which resource it wants to access.
Hmm. Either you are mistaken, or you're correct but all the servers
I've tested this against thus far (admittedly not many!) request a
client cert unconditionally and don't complain when one is not provided.
If you're right, I guess we need to spec this behaviour as required.
Thanks for taking the time to spell this out. I was largely mistaken, as far as I can tell from my own attempts to add client certs to my server implementation. I think what's going on is that since I last seriously looked into this circa 2001, client UIs now behave better when servers request a client cert without making it mandatory.
Anyway, I think the ergonomics and patterns around how certificate signing
requests get moved around are going to be a bigger problem.
I have to admit that I don't see a lot of point in using CSRs in this
context. The whole point of a signed certificate is so that party A can
Well, they are a potential implementation of the step you referred to as"You may need to e.g. coordinate with the admin to get your certificate"
In my proposed pattern, the server trusts any cert which has been signed by some CA run by the server operator. The coordination with the admin to get such a cert is done via normal CSRs.
I'd recommend having a look at how Scuttlebutt does its analogous step: "invite codes". See, e..g.,
https://github.com/ssbc/ssb-server/wiki/pub-servershttps://ssbc.github.io/scuttlebutt-protocol-guide/ (invite codes section)https://handbook.scuttlebutt.nz/guides/pubs/create-an-invite
... which suggests that a layer on top of CSRs may also be useful. Anyway, best way to find out is to try it.
really party A. The certificate is for the benefit of third parties.
If you are running a Gemini server and you want to use client certificates to
restrict access to certain people, there is no third party in the
picture. So why not just remember the fingerprint of certificates you've
verified as belong to people you want to grant access to? That way nobody
has to send you a CSR and you don't have to send back a signed certificate.
In a two-party scenario all that just seems like pointless busy work to
me. Am I missing something?
Well, in the two party scenario, sending a CSR and sending a fingerprint seem to be pretty similar: the user's software submits the mystic runes to openssl and the result is pasted to the other party. In the CSR route, however, you do indeed need to save the other party's response (the cert).
I would say that the CSR mechanism goes with the grain of how SSL is conventionally used, and thus is likely to have better existinglibrary/docs support.
My server sets $REMOTE_USER to the client cert's "Common Name" field, which is probably not what other people are doing, but which I think is more in the spirit of Gemini. If I get time I'll write up what the current practices of the other server software are.
Mk
-- Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/