Re: why you shouldn't even try to canonicalize local parts
Wei Chuang <[email protected]> Tue, 15 Mar 2016 15:36:57 -0700
| Newsgroups | gmane.ietf.smtp,gmane.ietf.smime |
|---|---|
| Message-ID | <CAAFsWK0e_YXVG9EoZzFJtNfmqwaP7xFrwriqEQw=4WqKNBRA-A@mail.gmail.com> |
[-PKIX, +SMIME] On Thu, Mar 10, 2016 at 2:01 PM, John R Levine <[email protected]> wrote: > Its certainly true that the issuer of a cert using such a regex represented >> name matters greatly now. (I wondered about the same issue in another >> thread) A third party CA is going to have a much harder time >> understanding >> the local practices, and that represents a spoofing risk, though I suspect >> it might be possible to communicate local practices to prevent that. A >> workable scenario is that the certificate issuer is the email domain owner >> who understands intimately the email local practices. >> > > This is almost certainly a blind alley, and it'd help to back up and think > about what problem you're trying to solve. > > It seems to me that even though the same S/MIME certificate is used for > signing and encryption, the two applications are quite different. > > For signing, a random recipient having verified that the signature matches > the message body wants to check that an address in the certificate matches > the sender's address, typically the one on the From: line. In my > experience, even those of us with a zillion inbound addresses don't use all > that many addresses for outbound mail, so it's practical to enumerate them > all in certificates. Or if a sender does want to make an address on the > fly for which it does not yet have a certificate, if the CA is the sender's > domain owner, it should be straightforward invent to ask the CA at that > time for a certificate that matches the the address, and the CA can use > whatever local rules it wants to decide whether the desired address is one > that belongs to the requester and provide one or not. This is extra work, > but in the context of mail submission, it's not an unreasonable amount of > extra work. Another idea in the opposite direction: A local-part fix up might be to use RFC7508 encrypted headers to repair the FROM and SENDER email addresses to their canonical form. -Wei > > For encryption of inbound mail, it doesn't matter what address is in the > certificate; if the recipient can decode the message it's the right one, > otherwise it's not. So the sender can ask the domain's key oracle for a > certficate for the address, the key oracle applies local rules and provides > a certificate that might have the exact requested address, or might have > another address that goes to the same recipient. > > I'd think that something along these lines would not be particularly hard > to implement, and would require semantic changes neither to PKIX nor to > SMTP. > > R's, > John > _______________________________________________ ietf-smtp mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-smtp