On Fri, Apr 22, 2016 at 1:27 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Regarding the suitability of embedding email addresses in certificates,
would it be fair to say that domains willing to live with permanent
email
identities and narrowly defined delivery patterns could have a
standardized
means of describing equivalent email addresses?
Hard to say. The PKIX crowd put in case folded addreses without, as
far as I know, asking anyone in the SMTP community whether that's a
good idea. While nobody thinks it's likely that Fred@example,
FRED@example, and fred@example would correspond to different people,
once you get past case folding you quickly run out of popular
techniques, and even case folding is hard in EAI since the folding
rules are specific to each language.
It's hard to say because the entire idea of defining a general
"canonicalization" operation for email address as a solution for various
problems is, as I have previously pointed out, nonsensical.
There are problems, such as the address equivalence tests mailing list
managers
are obliged to perform, where a single canonicalization operation is both
necessary and sufficient. And there are problems, such as looking up
the certificate/private key to use for an address, where anything based on
canicalization will at best be a partial solution only applicable to
administrative domains that meet some very specific criteria, and a better
solution won't use canonicalization at all.
More generally, this entire discussion has taken on the characteristics of
an
antipattern we see regularly in customer support: The customer has a
problem, settles on a particular solution and then asks us how to
implement it.
Sounds fine, right? Except the solution they've settled on is either
unworkable, impractical, unimplementable, fails to solve the problem, or
some combination of the four.
And then we invariably spend a bunch of time wandering around before we're
able to back things up to the actual problem. Which at least we might have
a chance of solving.
And it's the same here. Painful though it may be, it's becoming
increasingly
clear that we need to back up to the original set of problems that started
this discussion.
I originally thought that backing up to the problem of how to determine
various
properties of an address was sufficient. But although I believe all of the
motivating problems here do reduce to property lookup, I now see that we're
going to have to go back further than that.
Perhaps a way of thinking about this is whether identity equivalence rules
of a domain can specified and then communicated to a third party so that
the third party can make its own judgement about identity of the purported
sender of some email. At a high level can a specification be made assuming
that the domain makes it suitable to do so?
Another approach might be to rework how to interpret the sender with signed
messages so that its possible to skip the RFC5280 address validation at the
receiving MUA. In this process, the MUA would ignore the RFC822
FROM/SENDER header, and take the sender from the certificate SAN rfc822
email address. (Only one address would be allowed in the SAN in this
approach) The email UI would display the certificate email address as the
FROM address and replies would go there. This is a bit more of a change
though I would think.
-Wei
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp