On certificates and validation

[Drew DeVault]

On Wed Nov 25, 2020 at 7:58 AM EST, Björn Wärmedal wrote:
> I'm building a lib to simplify gemini client development in python,
> and my current headache is certification handling. There's a few
> things that come to mind, some more philosophical than technical in
> nature.
>
> * Should I support verification of CA-issued certificates, or
> self-signed only? Doing both at the same time leads to a "try this, if
> fail then try this" sort of situation which isn't very pretty. How
> common are CA-issued certificates in geminispace, and should they be
> handled differently than TOFU?

I strongly recommend not checking for CA-signed certificates, and only
supporting TOFU.

> * How does one even validate a self-signed cert? If ew0k.example.com
> serves a certificate with the Common Name "ew0k's Awesome Site" and no
> Subject Alternative Names, is that less valid than one that includes
> the hostname? Or the IP? Does expiration time matter at all for a
> self-signed cert?

Yes, test the common name and/or alternative names, and the expiration
time.

> * When a browser has accepted one cert for example.com but is
> presented another on the next visit, it shows a warning to the user
> who will then decide whether to accept the new cert. What information
> allows a user to make an informed decision in this case? Does it
> matter that the last cert would still be valid for another 3 years? Or
> 2 months?

The SHA-256 of the certificate is helpful in this, because they use it
to verify the certificate's authenticity out of band (e.g. email the
operator, call a friend on a different ISP, etc).

You may find this article I wrote on TOFU helpful:

gemini://drewdevault.com/2020/09/21/Gemini-TOFU.gmi