💾 Archived View for gemi.dev › gemini-mailing-list › 000453.gmi captured on 2024-06-16 at 13:18:33. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
I've been reading about Gemini and part of me likes the decision to abandon certificate authorities in favor of TOFU, but I have a question about how this works. The Gemini specification says: > If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA. Doesn't this mean that the replacement certificate must be deployed at
On Mon Nov 9, 2020 at 7:06 AM EST, Ryan Westlund wrote: > I've been reading about Gemini and part of me likes the decision to > abandon certificate authorities in favor of TOFU, but I have a > question about how this works. The Gemini specification says: > > > If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA. > > Doesn't this mean that the replacement certificate must be deployed at > *exactly* the right time to avoid errors? If you deploy it even a day > ahead of time, users will see errors? And users will see errors if you > are late to replace it? Yes, it does. Some servers automatically generate certificates to avoid this issue, ensuring that an expired certificate is never used.
---
Previous Thread: Statement of intent regarding TLS server name identification (SNI)
Next Thread: Serious writing (in the Latin script) needs italics