Encryption and Signing

When reading about Gemini for the first time (not very long ago) I immediately got the feeling that privacy was very important. That was one of the big selling points compared to Gopher. Then there was the philosophy of TOFU (trust on first use) vs third party verification (via CA). Now, trust is an issue way more difficult than privacy, so let's dive into that.

When I visit a capsule, to be honest, I'm not really that concerned about any of that. Gemini is a friendly neighborhood where you can park your bike unlocked. Illegal content have not yet found its way here and the merchants and money changers have not yet infested the temple. There is nothing sensitive to protect, really. Nothing to even be ashamed of, even.

But still, even in these circumstances I find trust to be important. And with trust I mean the possibility to verify that the content I'm consuming really comes from the sender in the address bar. TLS supports both encrypting and signing, so we're definitely covered here, right? First, it depends on whether or not we can trust the signer. If we use a CA that ensures ownership of the domain, like Let's Encrypt, then we at least know that there was no man in the middle. But that is not very interesting for tilde servers with loads of users on the same domain, and admins that practically have access to modifying any users data. There we have another trust problem. Would TOFU solve that? Not the way TLS is working with Gemini currently. To solve that the author would need to sign all content locally before sending it up and then serve the signed material untouched. Now this would mean that the signing would take place on the application layer rather than the transport layer.

This is where I kind of start to like this train of thought. If we let go of the encryption requirement and focus on the signing, we could easily move the signing up a few steps in the network stack, simplifying the server and client implementation. It could all be clear text, with optional PGP (or other) signing around the content. A trivial client would just strip out the header and footer while a full blown one would verify the signature and act on the result. The public keys could be handled by a CA or a web of trust or even a TOFU solution, maybe the public key would be expected at /public.key or similar.

I'm not suggesting any changes here, this is just a thought experiment. Or maybe I should start my own protocol. Heavier than Spartan, lighter than Gemini.