On 2025-10-19 10:39, Alessandro Vesely via mailop wrote:
While you can self-sign a certificate saying that your name is "example.com", most CAs at least verify that the domain name is actually controlled by the requestor.
How about adding the fingerprint of the certificate to DNS, or even better publish the public key in some well-known URL on the server pointed by DNS? just sayin'
I (sender) want to choose who my ID provider is. I do not want to leave that choice to a third-party CA; or to an olygopoly/restricted club of CAs. There is a use-case for government-run CA; there is a use-case for commercial CA; there is a use-case for grassroot/volunteer/self-run CA; there is a use-case for self-signed certificates too; and they are different from the use-case for a non-signed message (which is a use-case too). We shall not sacrifice flexibility, nor the possibility of selective anonymity, but it has to be a distinct, legitimate use-case.
The CA/Browser Forum has established policies on how to perform such verification. As a result, a certificate recognized by your system, in addition to securing the key exchange, also guarantees the domain name. This is not such an uncertain value.
I (recipient) want to choose choose if, why, when, how to accept a certificate. While in many cases the default CAs recognized by my system are fine, there are use-cases when I want to be much more restrictive; and there are use cases when I want to be less restrictive.
Use-cases are message by message. It is not enough to do client verification, although it is helpful to sanction/blanket-block a client who does not police properly its users. It is not enough to do domain verification, because a domain/subdomain can be shared by many users, and again, blanket-block a TLD, a domain, or a subdomain is the ultimate punishment if said TLD/domain/subdomain does not govern its users. It is not enough to do user verification: for example, I may want to receive an electronic ticket and an e-bill from an airline, but not annoying feedback requests. All of these use-cases results in an arms' race and more systemic damage than benefit. It is the hard way or the smart way: I can use a computationally expensive AI agent to delete annoying "legitimate" surveys, offers, reminders, calendar entries AND risk false positives; or I can put out, in machine-readable format, what identified purposes I accept emails for and the sender can respect my expressed wishes, or face a blanket-block. The wishes are user-by-user, so a well-known/per-user URL would be required for the expression of said policy; and an automated feedback-loop would be required to give sender-SMTP information necessary to police its users.
At the most restrictive, I (recipient) would publish that I only accept email encrypted with my public key at the well-known/user/public_key URL and signed with the sender's private key corresponding to its public key at its domain's well-known/user/public_key URL. The signature shall indicate, in machine-readable format, the user-declared nature of the message; and my user should have a one-click possibility to inform the sender's SMTP server that the message received does not conform to the declared nature of the message. SMTP-service provider can police their senders as they see fit based on the signal. reputation loop complete.
Yuv Ontario-licensed lawyer _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
