[Top] [All Lists]

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

2016-03-22 09:22:52
On Tue, Mar 22, 2016 at 5:41 AM, Miller, Timothy J. 

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.

It's more practical to treat the key as the relevant identity, since only
the key holder can read the email irrespective of email address.  This is
already implicit in most S/MIME aware MUAs--to decrypt, many MUAs simply of
look for RecipientInfo's SKID in the user's private key store.  The
RecipientInfo's issuerAndSerialNumer identifier are irrelevant.  IOW, if
your key store allows it, you can delete the cert and retain the private
key and decrypt S/MIME encrypted mail.  Or you can load your private key
into *someone else's MUA* and read mail addressed to that key (it's
convoluted to test this with, say, Outlook, but it can be done).

This is on purpose, BTW, because there are plenty of relevant use cases
where this is the only solution.  Expired certs, mailbox renaming, domain
renaming (think mergers), & etc. would all interfere with accessing old
encrypted mail if the cert had to be examined on decryption.

Keys matter.  Everything else is (potentially) transient, especially the
association of key to mailbox.

-- T

Thanks for the detailed explanation.  From this perspective a reasonable
refinement of RFC5751 would be to drop the verification of the FROM or
SENDER address?  Messages would still be signed by a CA issued
cert/private-key.  To make workable for people, the cert still ought to
specify either an email address, name or some other human comprehensible
identity (e.g. photo?) so that the recipient knows the cert belongs to the
sender.  The refinement would also need to address the issue of protecting
the integrity of the headers which the current comparison sort of does.

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