💾 Archived View for rawtext.club › ~sloum › geminilist › 006471.gmi captured on 2023-11-14 at 09:20:37. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
nervuri nervuri at disroot.org
Thu Apr 29 14:50:21 BST 2021
- - - - - - - - - - - - - - - - - - -
On Wed, 2021-04-28, Anna “CyberTailor” wrote:
It'd be better an opt-in feature (like HSTS Preload for the web)
because otherwise capsules, whose owners didn't know about the list,
may just break.
This would only happen on certificate change, in the same way it wouldif you had previously visited the capsule: your client would warn youthat it received a different cert. The chances of that are happeningcan be reduced by not bundling short-lived certificates.I see the certificate's expiry date as a kind of opt-in: if a certexpires in 100 years, we can assume it's ok to bundle with clients.It's up to each client developer where to draw the line. I guess itwould depend on release frequency.
Ideally, clients could include the option to refresh the trust storefrom a chosen source (thereby providing a way to do out-of-bandverification). This option could be shown to the user on every certmismatch warning. The lag between certificate change and trust storegeneration is an issue here, but it's better than not having the optionat all. We could eliminate the lag by using a Convergence-like approach(which I'm working on, but that's a different discussion).
https://en.wikipedia.org/wiki/Convergence_(SSL)