💾 Archived View for bbs.geminispace.org › u › jeang3nie › 1682 captured on 2024-05-10 at 13:53:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
Re: "Verification of Sender Certificate"
Yes, the call back to the sender's server is what I was referring to before. The meta portion of the status is supposed to be the hash of the client certificate for the receiver, so it's easy to check the client certificate that is presented when getting an incoming message.
If this is the first time seeing that certificate, the server sends a blank message to that mailbox, and this gets the fingerprint in the return code. If something goes wrong in that transaction, like the mailbox doesn't exist, then the original incoming message is rejected. If the transaction succeeds but the hash does not match, then the identity is being spoofed.
2023-06-08 · 11 months ago
🦀 jeang3nie · 2023-06-08 at 13:36:
There is a potential flaw in this scheme for getting the user's hash, and since I don't want to type it all back in again I'll direct you to this other conversation where I elaborate on it a bit.
— bbs.geminispace.org/s/discuss/1679
🧩 ERnsTL [OP] · 2023-06-08 at 16:53:
Thanks @jeang3nie for your clarifications and that there still is work to be done on cert verification (empty message loop etc.)
Verification of Sender Certificate — Greetings, maybe I oversaw this in the spec, but if a client connects with a TOFU / self-signed certificate for chuck@norris.com is there any verification done to ensure that the client is not spoofing the sender address? I could think of something like a back-connection to a kind of "misfin MX" record (well SRV record would be perfect for that) and checking if the presented client certificate is signed by the norris.com server certificate.