Client certificate musings

[solderpunk]

On Sun, May 24, 2020 at 11:22:48PM +0100, Martin Keegan wrote:
> On Sat, 23 May 2020, solderpunk wrote:
 
> 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

This is exactly the intended workflow, and is now supported somewhat
smoothly in AV-98.  Here is an example session.  For the sake of making
it clear what is happening, I have `set debug true` but deleted most of
the debugging output, leaving only what is necessarily to make it clear
what is happening here:

AV-98> go gemini://gemini.conman.org/conman-labs-private/
[DEBUG] Response header: 62 Authorized Certicate Required.
The site gemini.conman.org is requesting a client certificate.
This will allow the site to recognise you across requests.
What do you want to do?
1. Give up.
2. Generate new certificate and retry the request.
3. Load previously generated certificate from file.
4. Load certificate from file and retry the request.
> 2
What do you want to name this new certificate?
Answering `mycert` will create `~/.av98/certs/mycert.crt` and
`~/.av98/certs/mycert.key`
conman
Generating a RSA private key
..............+++++
.........................................+++++
writing new private key to '/home/solderpunk/.av98/client_certs/conman.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:Let me in!
Email Address []:.
[DEBUG] Sending gemini://gemini.conman.org/conman-labs-private/<CRLF>
[DEBUG] Response header: 63 Certificate Not Accepted.
The server did not accept your certificate.
You may need to e.g. coordinate with the admin to get your certificate
fingerprint whitelisted.
What do you want to do?
1. Give up.
2. Generate new certificate and retry the request.
3. Load previously generated certificate from file.
4. Load certificate from file and retry the request.
> 1

> 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.

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.

> 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
prove to anybody who trusts party B that party B verified they are
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?

Cheers,
Solderpunk