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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp