Subject: Re: [smime] [ietf-smtp] why you shouldn't even try to canonicalize local parts

From: Wei Chuang <[email-masked]>
Date: Tue, 15 Mar 2016 15:36:57 -0700

[-PKIX, +SMIME]

On Thu, Mar 10, 2016 at 2:01 PM, John R Levine <[email-masked]> 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
>

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2016 19:28:11 -0400

> FROM and SENDER email addresses to their canonical form.

If you mean the canonicalization rules in section 4.3, they're borrowed 
from DKIM and only change white space.  It also references RFC 5750 which 
says that

       Receiving agents MUST check that the address in the
    From or Sender header of a mail message matches an Internet mail
    address, if present, in the signer's certificate, if mail addresses
    are present in the certificate.

but it doesn't say what "matches" means.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Wed, 16 Mar 2016 07:45:34 -0700

On Tue, Mar 15, 2016 at 4:28 PM, John R Levine <[email-masked]> wrote:

> from DKIM and only change white space.

Actually I meant using the encrypt and decrypt functionality of RFC7508
4.6.1 and 4.6.2 to replace the FROM and SENDER headers contents which are
used for transport with the presented values to be verified and presented
to the recipient.  In those sections, the two headers when present are
treated as status modified and replaced with new values.

It also references RFC 5750 which says that
> but it doesn't say what "matches" means.

It probably would be risky for the validator which often is remote from to
the sender's domain and unfamiliar with their SMTP processing policies to
fix anything up (excepting IDNA) during comparison without some sort of
instruction from the sender.

-Wei

> R's,
> John
>
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>