💾 Archived View for rawtext.club › ~sloum › geminilist › 001035.gmi captured on 2020-09-24 at 02:09:57. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Martin Keegan martin at no.ucant.org
Sun May 24 23:22:48 BST 2020
- - - - - - - - - - - - - - - - - - -
On Sat, 23 May 2020, solderpunk wrote:
I first learned about client certificates in the murky, distant past
when the "semantic web" was a hot topic, in the context of the
decentralised "Friend Of a Friend" social network idea. You can read
about FOAF+SSL at https://www.w3.org/wiki/Foaf+ssl.
Though very skeptical about SSL itself, I have always had a soft spot for SSL client certificates. I first came across them at Zeus (we made an HTTP webserver that behaved rather differently from Apache; in particular, CGI was implemented via a SCGI-like mechanism. I loved CGI - in the 1990s I would check in at http://hoohoo.uiuc.ncsa.edu/CGI/ just to see if they'd updated the spec): not only did some of our customers use client certs, but we used them for authenticating email: if your cert had been signed by our CA and not revoked, the IMAP/SMTP magically worked for you, otherwise no.
I've tried writing a Gemini server (now looking pretty tidy: https://github.com/mk270/blizanci/blob/master/apps/blizanci/src/blizanci_gemini.erl ) but I reckon SSL client certs are going to be what stops me using Erlang and forces me over to Rust with the cool crowd. The use case I care about is your first one:
I want to make a set of documents available to clients who can present a certificate signed by a particular CA (e.g., one I control).
I appreciate that under the current dispensation, the distribution of certificates or certificate-signing-requests is out-of-band, but in my use case, it's not clear to me how I'd go about implementing this. I'dhave thought something like:
C: connect to S, without presenting a client cert and request /path/fileS: 62 you need to present an authorised client cert; closes connection
C: reconnect to S, presenting appropriate client cert, request /path/fileS: 20 text/gemini [data follows]; closes connection
However, it's my possibly mistaken understanding that an SSL client will not present a cert to the server unless the server sends the CertificateRequest message first. Since the server doesn't know whether the client is going to ask for a restricted resource, it won't request a client cert. This seems to lead to a chicken-and-egg problem: to get access to the resource, the client 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.
This only arises where there is a combination of restricted and unrestricted resources in the URL namespace on a server on a particular port. In the case where *all* the resources on the server are restricted, the server could unconditionally request a cert from each client that connects, and then allow or deny access to the resources on a per-URL, per-cert basis. What seems to be impossible is having a landing page, say, gemini://gemini.podunk.edu/ which has a link to gemini://gemini.podunk.edu/restricted on its main landing page.
Maybe this is fine, or maybe I misunderstand how SSL works (I know things changed a little on the certificate request front in TLS1.3).
Anyway, I think the ergonomics and patterns around how certificate signing requests get moved around are going to be a bigger problem.
Keep up the good work!
Mk
-- Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/