On Fri, Feb 3, 2017 at 11:51 AM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
> On Feb 3, 2017, at 2:38 PM, Wei Chuang <weihaw@xxxxxxxxxx> wrote:
>
> Can you clarify what this means for addresses such as:
>
> U: ietf-dane@духовный.org
>
> Not recommended but supported by SmtpUtf8Name.
>
>
> A: ietf-dane@xxxxxxxxxxxxxxxxxxxx
>
> 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
<<attachment: smime.p7s>>