💾 Archived View for bbs.geminispace.org › u › alexlehm › 1678 captured on 2023-07-22 at 18:02:20. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "Verification of Sender Certificate"
actually the spec says you can it any way you like, it may do a callback to the sending server to get the cert and verify that it is the same, not sure if that is practical
2023-06-08 · 6 weeks ago
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.
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
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.