The certificate name form specification seems very straightforward to me. The
hard part is the text that says how to compare the internationalized email
address in the certificate to the one in the email message.
Russ
On Mar 9, 2016, at 5:25 PM, Wei Chuang wrote:
John C. and John R.:
Let me bring up a variation of email address naming that's much more limited
in scope.
Do you see any problems to introducing a new PKIX email address type to
support Unicode in email local part for Email-Address-Internationalization?
This would be an alternative or refined interpretation of rfc822Name in
subject-alternative-name and issuer-alternative-name PKIX extension. As
RFC6532 allows this, but RFC5280 hasn't been updated to support this.
-Wei
On Wed, Mar 9, 2016 at 2:15 PM, Wei Chuang <weihaw(_at_)google(_dot_)com>
wrote:
On W ed, Mar 9, 2016 at 1:20 PM, John C Klensin
<john-ietf(_at_)jck(_dot_)com> wrote:
--On Wednesday, March 09, 2016 21:46 +0100 John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:
...
As I said a few messages ago, it is not an accident or a
mistake that there is no canonical form for e-mail addresses.
We understand why some people wish it were otherwise, but the
number of ways that MTAs map e-mail addresses is only slightly
less than the number of MTAs, and the mappings are constantly
changing.
The alternative is that for each mapping i.e. email address variant
the sender will need a different set of signing keys and certificates,
which they will have to distribute. Because these email addresss local
variations
have become so ingrained, adopting PKIX for email address authentication
becomes
burdensome to point of killing off its feasibility. To quote pull a quote
from that
earlier message, I too worry that "perfect may be the enemy of the good"
here.
And, while smaller than the number of mappings and MTAs, there
are a very large number of specialized formats used for special
purposes like extended tracking or managing of delivery and
non-delivery notifications. Having a canonical form that can be
trusted requires understanding all of those cases, some
deliberately undocumented, and then guessing correctly (every
time) about what one is seeing.
It may be possible to figure out a way to use an SMTP server
or maybe a web server connected to an SMTP server as an
oracle, to ask do these two addresses deliver to the same
place or to ask for a key or a certificate for an address, but
even that is iffy.
Or not, depending on _exactly_ how the operation and selection
function are applied. But the point is the only that server can
definitively answer "do these deliver to the same place" and, as
pointed out for one case below, even that information may not
mean as much as people believe.
We can't even say what it means for two addresses to be "the
same". For example, on my MTA there about a thousand live
addresses that deliver to the same inbox where your message
was delivered, but that doesn't mean I want all of them to
have the same PGP or S/MIME keys.
Nor does it mean that, by the time whatever you are using as an
MUA or local mail routing rules (SIEVE or otherwise) that it
will end up in the same place ("inbox", "folder", etc.) on your
desktop.
In case it isn't clear, John Levine and I are in agreement about
this and I'm writing only to emphasize his message and that his
position is not unique to him. The problem is really hard,
changing every mail MTA and MUA in the word to match someone's
idea of a desired canonical isn't feasible and probably would
not be desirable even if it were, etc., etc.
Wouldn't the problem size be smaller, and limited to those that want to
validate
the identity of the sender and/or to do a key lookup? At some future point,
using PKIX asserted identities for sender and recipients for mail delivery
seems like
a good idea.
-Wei
best,
john
_______________________________________________
pkix mailing list
pkix(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp