[spec] Certificate trust

Solene Rapenne solene at perso.pw
Sun Feb 28 19:32:53 GMT 2021

On Sun, 28 Feb 2021 20:27:26 +0100
Côme Chilliet <come at chilliet.eu>:

> Hello,
> I have been using lagrange for a few months to browse Gemini, and I realize that I’m already making a habit of ignoring certificate mismatch warnings, and blindly trusting any certificate that shows.
> The certificate trust is one of the weak point of the current specification I think, and it would need to be clarified.
> Firstly, there is the idea of TOFU, but it does not say on which part of the certificate the TOFU works (some people consider it’s the whole certificate, some only the fingerprint), and it does not say how much the certificate needs to be valid (I’ve seen on the ML some people considering that a wrong domain in a certificate and a past expiration date should be ignored by clients). Reading the specification it appears that it recommends using fingerprint and to consider past expiration date invalid.
> Secondly, there is the good old CA system, nowadays mostly using letsencrypt. It seems badly supported in most clients which still use TOFU in this case and will complain at each renewal.
> A third possibility I think would be to use DANE and base validation on the DNS system, but I’ve not seen anyone advocating this, is there anything wrong with that idea?
> I’m failing to see how TOFU can provide any security, especially if there is no way to announce a renewal by sending both new and old cert or something, there is a MITM possibility at each renewal. The only TOFU example I’ve seen cited is openssh, which seems offtopic because you usually do not ssh into random machine on the internet by following links like you do with Gemini.
> Côme


I suggested something on IRC a while ago, I'm not sure this would
be a good idea but I'll share it here.

Instead of TOFU, 2 mecanisms could be used:

1) Check chain of trust of the certificate, with let's encrypt and
other provider (they are not alone anymore) it's easy to get a valid

2) If 1 is invalid, let's (introduce something new here) check if
DNS doesn't have a TXT field with the certificate fingerprint and
see if it matches the current one, accept if OK

3) if 2 found a TXT that doesn't match, tell the user, if it matches,
accepts, if no TXT, TOFU?

The fingerprint published in DNS is already done for SSH fingerprint
using a SSHFP field. This allows to have a third party check. I
agree it's not absolutely perfect but, it gives the opportunity for
an extra check.

This wouldn't have any backward incompatibilities because it's up
to the client to implement it, if a person hosting a gemini server
doesn't want to host it, just do TOFU as usual.

More information about the Gemini mailing list