💾 Archived View for bbs.geminispace.org › s › misfin › 20736 captured on 2024-12-17 at 15:14:26. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Prompted by @skyjake 's questions, I wanted to talk about the misfin server-client distinction and how verification is currently implemented in cipres' server and my server software.
A misfin server receives gemmails and will prepend the sender and timestamp to that gemmail. A server also manages the storage for mailboxes, and has a certificate authority that signs mailbox certificates for a multiuser system. While most implementations will store the private keys for all user registrations on the server, it is possible that a server will instead accept CSRs (Certificate Signing Requests) so that users can register certificates without the server seeing or storing the private key. In this setup, servers would not be able to send mails on behalf of the mailbox holder. However, this might not make any sense if the server could just change the certificate of a mailbox anytime it wants to replace the old cert and key.
Misfin clients would handle just the sending of gemmails. Rather than sending a mail to one's own misfin server to then be transferred from that server to the recipient server (like a transient mode), the user just sends directly to the recipient server from their own device. I think it is useful to have misfin clients separate from servers so that users can send mails on their own computer without having to connect to their own server. It also simplifies the misfin protocol itself.
Some servers, like mine, will implement a mailinglist feature that will automatically forward gemmails. For consistency, I think it is better to view the mailinglist feature as a misfin server that is *acting as a misfin client* for this specific purpose. Servers that implement this will have to store the private key of the mailinglist mailbox on the server for this reason. Servers will also do this for verification, and for the purposes of verification, servers end up acting like misfin clients.
So, I have a mailbox at auragem.letz.dev which is signed by the auragem server, but my private key is only stored on my own computer. I can send a mail directly to satch.xyz from my computer, and it never touches my auragem server. Satch's server receives the gemmail and looks at the sender, using the client certificate. If the client certificate is unknown, it constructs the client cert's address, clseibold@auragem.letz.dev, and sends a blank gemmail to clseibold@auragem.letz.dev using the satch.xyz's admin/CA certificate, and the AuraGem server will respond with a success status code and the fingerprint of my mailbox's certificate. This lets satch.xyz's server compare the returned fingerprint to the fingerprint of the client certificate. Satch's server will then respond to my client on my own computer with a success and a fingerprint of mail@satch.xyz, which my misfin client application can then store in its TOFU store.
In this example, servers act like clients for verification, and clients can also send verification messages to verify both the existence of mailboxes and their cert fingerprint. The method a server uses to verify the fingerprint of an address is the same method that a client can use to verify the existance of a mailbox.
As a sidenote: you should be able to check if a client is a misfin server itself by comparing the IP address to the IP address the domain name in the certificate resolves to. This could be useful if you want to restrict the forwarding of mails to just servers (for the purposes of federated mailinglists, newsletters, or other things). However, if we have a distinction between client and server software, then users would not necessarily be forwarding mail from their server, but from their own devices.
Oct 12 · 2 months ago