--On Tuesday, January 24, 2017 05:42 +0000 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
...
I can argue for the choice of A-labels rather than U-labels
(or vice versa), but the choice is a matter of taste and I'm
happy to accept the WG's analysis and decision.
I also agree that having a single normal form in the
certificate has some merit. I must say that the choice of
U-label as that form is somewhat unexpected given the use of
an A-label normal form with DNS subjectAltNames. Consistency
might have been preferable, though of course the local part
offers no similar representation, and so perhaps the
compelling argument in favour of U-labels is using a
consistent encoding for both parts.
Personal opinion: if one gives priority to consistency with DNS
subjectAltNames, then it would be best to go with A-labels. If
one gives priority to consistency with SMTPUTF8 addresses,
especially those containing local-parts with characters in them
that lie outside the ASCII repertoire, then one goes with
U-labels. If the principal desire is to be consistent with
SMTPUTF8 recommendations, then one goes with U-labels too
because those specs are fairly clear about not involving email
users with A-labels if it can be avoided.
As I said, I can argue it either way, but am happy to defer to
the WG on this (especially since I strongly suspect they got it
right).
This does mean one one will not be able to obtain a useful
certificate for addresses like user(_at_)xn--b1adqpd3ao5c(_dot_)org,
which is what Apple's Mail.app (even in the latest MacOS
Sierra) emits when I configure a sender address in the unicode
form of that domain. My MTA delivers both the U-label and
A-label forms to the same mailbox, but my other (not Mutt) MUA
only sends A-labels.
Which leads me to the observation that verification software
will already have the message "From:" (or other purported)
signer address in hand, which it will be comparing with the
associated certificate. So it seems far more natural to use
*that* address *verbatim* as the reference identifier to seek
in the certificate.
One might then obtain a certificates with two email
subjectAltNames:
* user(_at_)xn--b1adqpd3ao5c(_dot_)org
* user@духовный.org
which will work regardless of which form is seen in the message
headers, and would not require any conversions by the verifier.
In other words, check the certificate for whichever address
form appears in the message headers. If that's how the
sending system knows the author, then perhaps it ought to be
good enough in the certificate too!
This is a more interesting argument. On the other hand, if that
application is ever going to fully support and conform to
SMTPUTF8, including local parts that are not entirely in ASCII
and non-ASCII header field contents, they are going to need to
get over the A-label preference/requirement. What you describe
is a plain, ordinary, traditional, use of IDNA by an application
that doesn't understand it, not some type of partial SMTPUTF8
implementation. I hope the WG has thought about the two cert
option, or will soon, but, if two certificates (potentially
issued to different parties unless the CAs are really careful)
for what the email system considers the same address poses an
attack risk, perhaps "no certs for domains containing any IDN
labels" until the relevant mail systems are upgraded" might be a
reasonable decision.
As Patrik commented about another aspect of the issue, the
document really needs to be very clear about these decisions
and, ideally, the rationale for them when they might seem
questionable... and needs to do it in really clear English.
john
This would dramatically simply the implementation, the
application provides the X.509 library with the verbatim
author address and this either matches or does not match the
certificate without any conversions.