Updated recommendations regarding TOFU & TLS

[Drew DeVault]

Note: I'm not subscribed to this list, please use "reply-all" to make
sure I get Cc'd on your reply.

Hello! I have recently announced some upcoming changes to my Gemini
software implementations with respect to TLS and TOFU:

https://lists.sr.ht/~sircmpwn/gmni-discuss/%3CC9OP7IK9T9EP.15EOEOOS7QSB9%40taiga%3E

I've also updated my older TOFU recommendations article to reflect the
changes:

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

In short, after listening to some feedback from the community on TOFU,
I'd like to make the following updated suggestions:

- Use long-lived certificates with the expiration set to the far future
- Client software should disregard notBefore/notAfter dates, and the
  common name as well. Requiring strong algorithms and other technical
  constraints is fine.

Any server software which wants to migrate to long-lived certificates
should let their current certificates expire and then automatically
issue a long-lived certificate to replace it when the time comes, rather
than switching immediately and causing your clients to flag your cert as
untrusted.

To re-state one of my previous recommendations, which I still figure is
a good idea: server software should handle certificate maintenance for
the user. Making the sysadmin generate certificates is cumbersome and
error prone, and because Gemini encourages TOFU and self-signed
certificates, we can remove that burden from server operators entirely
by generating certificates on-demand for the hosts we intend to service.

Aside: it might be a good idea to have a non-authoratitive TLS
best-practices document on gemini.circumlunar.space somewhere. I'd be
happy to draft up such a document if this is desirable.