💾 Archived View for rawtext.club › ~sloum › geminilist › 005952.gmi captured on 2023-11-14 at 09:43:52. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Fri Mar 5 12:13:47 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Thu, 04 Mar 2021 11:43:49 -0500"Drew DeVault" <sir at cmpwn.com> wrote:
- Use long-lived certificates with the expiration set to the far future
That makes perfect sense for TOFU. If for whatever reason you need torenew a certificate (e.g. to use stronger encryption) you can just swapit out. The clients will (hopefully) learn of the change and can choosewhether to trust the new certificate.
- Client software should disregard notBefore/notAfter dates, and the
common name as well. Requiring strong algorithms and other technical
constraints is fine.
What is the motivation for ignoring CN?
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.
Without a chain of trust, and ignoring notBefore/notAfter, there's nopoint in waiting.
The client (according to the procedure you describe in your article)will find the old cert in known_hosts in step 2., see that the servedcertificate differs and consider the new certificate UNTRUSTED. That istrue regardless of whether you immediately replace the certificate orwait until the old one has expired, unless the client *doen't* ignorenotBefore/notAfter and uses those dates to vacuum known_hosts to removeexpired certificates automatically (which is impossible given the storeformat you currently recommend).
The procedure you describe does not provide for any other way to rollout new certificates than for the new one to be UNTRUSTED, nor do Ithink clients are able to provide this in general outside the use ofcertificate authorities or validity date based vacuuming of known_hosts.
That's really how it has to be for TOFU: whenever a new certificate isused, a new trust has to be established. *Any* certificate thatyou haven't used is untrusted.
IMO, UNKNOWN is really the same thing as UNTRUSTED. There is noUNKNOWN state; either I've asserted my trust in the certificate or Ihaven't. UNKNOWN and UNTRUSTED are just different cases of untrustedcertificates, with latter giving you an additional piece ofinformation: that you have already trusted a different certificate forthe given host. I think it's better for clients if they are treated assuch.
In my client, the user gets a choice whenever they encounter a newcertificate. If the trust store happens to contain a differentcertificate for the host, that information will be displayed to theuser as well, so that they can use it as a basis for the decisionwhether to trust the new certificate. Manually editing known_hosts isjust that, "with extra steps".
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.
Agreed.
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.
Agreed. I think your article is a good starting point, but consider mycriticism above.
-- Philip-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 488 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210305/17dbaf8c/attachment.sig>