It looks like VeriSign has hit on the same solution to the personal PKI problem that I have in the callsign registry and for the same reason: To get around the problem that a certificate for [email protected] doesn't work to authenticate Alice unless she is the holder of example.com.
Building out the registry co-extensive with the PKI removes the need to validate the certificate requests for holdership of the domain because this is established by definition. It also looks like they have hit the inevitable constraints from trying to engage with the legacy SMTP installed base to make it do something different. And I can't see that problem as having a good solution. SPF was not designed to support the case where [email protected] was in a different domain of control to [email protected]. The .name use case is not going to have nearly enough of a user base to cause deployment of a proposed change to SPF to solve the problem. The only approach I can see working is for .name to provide the inbound and outbound mail services. Which given how SMTP works for inbound they must surely do anyway. On Tue, May 31, 2022 at 11:14 PM Douglas Foster < [email protected]> wrote: > David's goal for the name registration is different from what Verisign > intended. Here is what I have inferred: > > Verisign wants to sell personal identity PKI certificates to the masses, > for use with S/MIMIE. A personal PKI certificate requires a subject name > and an owner email address. "first.last.name" becomes the subject name, > and "[email protected]" becomes the email certificate. This is a much > better solution than requiring the consumer to get a different PKI > certificate every time that they change hosting services. It also gives > Verisign a name space under their own control, so that the certificate's > legitimacy is easier to protect. > > S/MIME signatures do not have to match the From address or Mail From > address of the email message that contains, they just have to be > recognizable and trusted by the person receiving the message. This allows > the "first.last.name" certificate to be used inside a message from " > [email protected]" > > So the [email protected] email address is just part of the control system > for the PKI certificate, and is not intended for general use. As John > observed, there is no way to provide outbound authentication for these > addresses, because authentication is based on domain name (and changing > that would take 100 years to deploy.) [email protected] and > [email protected] are likely to be using different message sending > systems. So any SPF or DKIM mechanism used to authenticate Mary's mail > could be used as a weapon to attack Joseph's mail. Since the addresses > cannot be authenticated, they should not be used for outbound mail. A > recipient who understands this situation would be wise to block any > incoming messages coming from the .name TLD. > > Doug Foster > > > On Tue, May 31, 2022 at 3:51 PM David Bustos <[email protected]> wrote: > >> On Tue, May 31, 2022, at 1:33 PM, John R Levine wrote: >> > On Tue, 31 May 2022, David Bustos wrote: >> >>> Forwarding is pretty broken these days. Even if you had perfect SPF, >> a lot of your incoming >> >>> mail would fail DMARC because a lot of DMARC policies depend on SPF >> and SPF can't deal with forwarded mail. >> >> >> >> I'm talking about outgoing mail, not incoming mail. >> > >> > Are you talking about mail you send, or mail sent to your bustos.name >> > address that's forwarded to a mailbox somewhere else? >> >> Mail that I send to other people, with [email protected] as the from >> address. Yahoo and Gmail sometimes direct it to spam. I presume it is >> because bustos.name doesn't have an SPF record. >> >> >>> I'm not surprised. The registry contract with ICANN forbids it. >> >> >> >> Is the contract available for me to read? >> > >> > It's the standard registry contract on the ICANN web site. >> >> Does the contract forbid publication of MX records? Verisign does that. >> >> >> This special case was committed to by TLD regulators back in 2002 and >> it is a problem for everyone with a third level .name domain. That's >> probably not many people, but the current situation is inconsistent so I am >> trying to figure out if any increases in consistency are possible. >> >> >> >> Yes, if no changes are possible then I may need to abandon >> [email protected] . >> > >> > Looks that way. >> >> Is your position that Verisign should publish SPF records for the .name >> domains? >> >> >> David >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
