💾 Archived View for rawtext.club › ~sloum › geminilist › 004809.gmi captured on 2023-11-14 at 10:31:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Petite Abeille petite.abeille at gmail.com
Mon Jan 11 20:10:45 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Jan 11, 2021, at 20:47, easrng <easrng at gmail.com> wrote:
I'm not writing a client right now, but if I was, I think I would
handle certs a few different ways. First, if it was tunneled over a
protocol that is already encrypted (ex. Tor), I'd accept any
certificate, because TLS would be redundant, even though the spec
requires it.
Good point. I actually do that over wireguard -using old school ident at time- LAN type ala tailscale †. No point for TLS in such setup.
It was suggested to move TLS outside of the core protocol (i.e. gemini+plain), and precisely define TLS as a Gemini "profile", i.e. gemini+tls.
No traction :P
If the certificate was valid and trusted by the CAs
installed, I would also accept it, even if that means overwriting an
earlier TOFU entry. Otherwise, I would handle them like SSH handles
keys, by asking the user on the first connection if the certificate is
trusted. Hopefully blockchain-based naming systems will make cert
validation easy some day, as you could just check if the cert matches
the signature in the blockchain of the person who owns the domain.
This is all sounds rather reasonable.
The part I don't really like personally is the mixed metaphor of ( TOFU + X.509 ) = ‽
℀ ±𝟤¢
† https://tailscale.com/blog/remembering-the-lan/