[Top] [All Lists]

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

2016-03-15 20:35:29


From: pkix [mailto:pkix-bounces(_at_)ietf(_dot_)org] On Behalf Of Wei Chuang
Sent: Tuesday, March 15, 2016 3:30 PM
To: John R Levine <johnl(_at_)taugh(_dot_)com>
Cc: PKIX <pkix(_at_)ietf(_dot_)org>; ietf-smtp <ietf-smtp(_at_)ietf(_dot_)org>
Subject: Re: [pkix] [ietf-smtp] why you shouldn't even try to canonicalize 
local parts




On Thu, Mar 10, 2016 at 2:01 PM, John R Levine <johnl(_at_)taugh(_dot_)com 
<mailto:johnl(_at_)taugh(_dot_)com> > 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.


Sorry about belaboring a point.  Popping out a level, what defines an identity? 
even when we send mail to someone?  Is it a mailbox or rather an authenticated 
user?  Most users probably would say they mean for their mail to reach a 
person, and that the recipient would care about the person who sent it.  How it 
gets there is almost invisible to them.  This probably pedantic to many reading 
this, but doesn't RFC7542 specify a notion of a Network Access Identity which 
has a notion of canonicalization for email addresses?  Granted this is at the 
edge/client but the point is that is separate from the authentication etc (AAA) 
service that consumes the canonical NAI.  The analogy I'm try to draw is that 
the signature verifier at the recipient MUA is an external entity to the SMTP, 
and is trying to do a similar canonicalization for the purposes authentication.


DO NOT be misled by the fact that an email address and an NAI have the same 
overall structure.  They are not the same thing and they do not match each 
other except for on a local specific basis.   An NAI is expected to be 
normalized as far to the edge of a AAA system as is possible.  This generally 
means that the owner of the NAI (in terms of a person) is the one responsible 
for doing the normalization.   This allows for the internals of the system to 
do simple binary comparisons and ignore all of the issues involved.  It is 
never expected that a third party would create an NAI without lots of knowledge 
and input it into the system.  This is the same as I type my email address 
correctly into my MUI.  It says nothing about you being able to type my email 
address correctly into your MUI.







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.



ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>