Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

[Wei Chuang <[e-mail]>]

On Fri, Feb 3, 2017 at 11:51 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > On Feb 3, 2017, at 2:38 PM, Wei Chuang <[e-mail]> wrote:
> >
> > Can you clarify what this means for addresses such as:
> >
> >         U: ietf-dane@духовный.org
> >
> > Not recommended but supported by SmtpUtf8Name.
> >
> >
> >         A: [e-mail]
> >
> > Use rfc822Name.  This is recommended.
>
> So, to be clear, for the same domain, some addresses will be
> represented as rfc822Name SAN elements (with the domain in
> A-label form), and other addresses (those with non-ASCII
> localparts) will be represented as SmtpUtf8Name SAN elements
> (with the domain in U-label form).
>

Yes that right.


>
> A verifier checking for an address with a non-ASCII localpart
> will compare against SmtpUtf8Name elements with U-label domain
> encodings, while a verifier checking for an address with an all
> ASCII localpart will check against rfc822Name elements using an
> A-label domain encoding (of the same domain).
>
> Is that right?  Thus the verifier would sometimes need to convert
> from U-labels to A-labels (when the localpart is all ASCII), and

at other times from A-labels to U-labels (when the localpart is not
> all ASCII)...
>

Yes that right.

Now that said what we've done is an extension of current practice keeping
them in place.  Conversions have been what's being done with rfc822Name
comparison for awhile, and that hasn't been changed by this document.  What
we've done is taken a new unhandled circumstance (UTF8 local part) and
specified its behavior.  With the SmtpUtf8Form we kept its scope and form
limited to reduce implementation overhead and limit the likelihood of
bugs.  As noted before we got advice to minimize conversions so we opted
for consistency and for the form where we think email will move towards.
In time those conversions will becomes fewer and fewer.  Yes the verifier
has to do conversions but that's already been practice now for many years
now.

If we focused solely on eliminating conversion as the objective, yes, we
could have done things differently but that would been disruptive to
existing practices.  The approach in the draft is incremental over those
practices since there's a large amount of deployed software.

While the draft does not preclude different email "personae" in a PKIX
certificate, I don't think this would be a good to specify in this draft.
I can see confusion between whether those "personae" represents a single
single person or multiple persons and that should be thought through in its
own draft.

-Wei