Client certificate musings

[Martin Keegan]

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'd
have thought something like:

C: connect to S, without presenting a client cert and request /path/file
S: 62 you need to present an authorised client cert; closes connection

C: reconnect to S, presenting appropriate client cert, request /path/file
S: 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/