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