💾 Archived View for rawtext.club › ~sloum › geminilist › 005904.gmi captured on 2024-02-05 at 11:05:46. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Drew DeVault sir at cmpwn.com
Thu Mar 4 16:43:49 GMT 2021
- - - - - - - - - - - - - - - - - - -
Note: I'm not subscribed to this list, please use "reply-all" to makesure I get Cc'd on your reply.
Hello! I have recently announced some upcoming changes to my Geminisoftware 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 thechanges:
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 certificatesshould let their current certificates expire and then automaticallyissue a long-lived certificate to replace it when the time comes, ratherthan switching immediately and causing your clients to flag your cert asuntrusted.
To re-state one of my previous recommendations, which I still figure isa good idea: server software should handle certificate maintenance forthe user. Making the sysadmin generate certificates is cumbersome anderror prone, and because Gemini encourages TOFU and self-signedcertificates, we can remove that burden from server operators entirelyby generating certificates on-demand for the hosts we intend to service.
Aside: it might be a good idea to have a non-authoratitive TLSbest-practices document on gemini.circumlunar.space somewhere. I'd behappy to draft up such a document if this is desirable.