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

From: John C Klensin <[email-masked]>
Date: Sun, 22 Jan 2017 14:46:46 -0500

--On Monday, January 16, 2017 2:45 PM -0800 The IESG
<[email-masked]> wrote:

> The IESG has received a request from the Limited Additional
> Mechanisms for PKIX and SMIME WG (lamps) to consider the
> following document: - 'Internationalized Email Addresses in
> X.509 certificates'   <draft-ietf-lamps-eai-addresses-05.txt>
> as Proposed Standard
>...

Hi.

This note is the result of a quick review for email, SMTPUTF8
and general I18n issues only.   I have some questions about
general comprehensibility but, in part because I have not
carefully followed the work that this extends, I'll leave those
questions to others and the RFC Editor.  Most of what follows is
nit-picking, but significant parts of it may affect the
comprehensibility of the document and hence the ability of
implementers, working it good faith, to conform and create
interoperable implementations. 

(1) The term "EAI" was the hastily-chosen short name/
abbreviation for a WG.  It is not the name of a protocol,
system, technique, etc.  The relevant standards-track RFCs are
very clear that, if a reference is made to the relevant SMTP
extension and associated protocols, the term should be
"SMTPUTF8".  "Internationalized Email Addresses" in the title is
ok, but there should be no IANA registry, subregistry, or module
that uses the "EAI" terminology.

(2) The base document [RFC5280] is referenced as depending on
RFC 5322 addresses.  822-addresses (used in message headers,
etc.) are not the same as 821-addresses (used in the SMTP
envelope).  One can make a case for either, but neither is a
proper subset of the other.  This is important in this context
because the document then talks about extending 5280 to
accommodate RFC 6531-style addresses.  Those are envelope-style
addresses, not message header-style ones.  I think the protocol
specifics may be ok due to the language in the third (" This
document further refines..." and subsequent paragraphs in
Section 3, but the explanation could easily be a source of
confusion and may need some clarification.

Note that, as proposals are kicked around that move information
from the mailbox name to the descriptive phrase (which does not
exist in envelope names) during mailing list expansion or some
models of post-delivery SMTPUTF8 "downgrading", any confusion
about this issue may become important (again, the I-D explicitly
prohibits the phrase, but only after talking a lot about
822-style addresses).

(3) A MUST NOT requirement on the use of A-labels has often
been problematic because, as far as a protocol that does not
support IDNA is concerned, they are ordinary labels conforming
to the "preferred syntax" of RFC 1034/1035 (commonly known as
"LDH syntax").  As important, it is easily possible to construct
strings that look (lexically) like A-labels but are actually not
A-labels.   If the desire is to prevent the use of anything but
normal (i.e., not IDNA) LDH labels and U-labels, the restriction
that is probably needed is either "no label starting in 'xn--'"
or "no label starting in two letters followed by two
hyphen-minus characters".  Requiring NR-LDH restrictions
probably solves the problem (although I'm not sure what "solely
ASCII character labels" means -- see (2) above) but requires
much more specific knowledge of the IDNA2008 protocol set
(particularly RFC 5890 in this case) than I predict readers of
this document will have.  See RFC 5890 and 5894 for more
discussion on this issue and other recent correspondence about
confusing and contradictory usage of "IDN" and "IDNA" and the
associated risks for additional details and risk descriptions.

(4) The second paragraph of Section 4 appears to me to be
correct.  However, for reasons related to those discussed above,
these are not strictly "conversion" because the operations may
fail (and will fail if the U-labels or A-labels are not strictly
valid).  It would probably be useful to be explicit that one of
the effects of this definition is to absolutely prohibit domains
that do not conform to IDNA2008 from appearing in certificates
(IMO, that is A Good Thing).

(5) It may be worth being explicit that there is no
normalization or case-folding permitted with the local-part.
The current text does say that but it may not be obvious to
someone not thoroughly familiar with other specs.

(6) I assume the RFC Editor would catch this, but the name of
the CCS that is historically most often used for/on the Internet
is "ASCII" not "ascii" or some other variation.  "US-ASCII" is
common to but, since there isn't any non-US-ASCII", a little
redundant unless reference is being made to the relevant media
type rather than the CCS.  The I-D appears to use "ASCII" and
"ascii" inconsistently.

(7) In part because of the normalization issue mentioned briefly
above, the Security Considerations section should probably
mention not only "visually similar characters" but "visually
identical strings".  Note that, at least modulo the
non-decomposing character issue, RFC 5890 does not have that
problem because IDNA requires that all input strings be
NFC-conforming.

(8) Perhaps no one cares, but the notation used in Appendix B
for  "\u8001\[email-masked]" does not appear to be referenced
or described anywhere in the document, nor is it consistent with
the recommendations of RFC 5137.

best,
   john

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jan 2017 13:40:41 +0000

Hi John,

Thank you for your thorough review! My comments/answers below:

> that uses the "EAI" terminology.
Sounds fair, this should be fixed.
> confusion and may need some clarification.
Very good point. Would just changing the first sentence in 
"Introduction" to reference RFC 5321 address this concern?
> associated risks for additional details and risk descriptions.
I think this needs to be discussed a bit more in the LAMPS WG, but you 
have a good point here.
> (IMO, that is A Good Thing).
Yes, I agree this should be said explicitly.
> someone not thoroughly familiar with other specs.
Do you have a suggestion where this should be clarified?
> type rather than the CCS.  The I-D appears to use "ASCII" and
Ok. We should fix.
> problem because IDNA requires that all input strings be
Right.
> the recommendations of RFC 5137.
Yes, we should either specify the notation or use RFC 5137.

Best Regards,
Alexey

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 23 Jan 2017 22:50:14 +0100

> Thank you for your thorough review! My comments/answers below:

I have a few comments as well. Basically I agree with what John writes, but let me add some additional spice.

>> hyphen-minus characters".
>>
>> Requiring NR-LDH restrictions
> I think this needs to be discussed a bit more in the LAMPS WG, but you have a good point here.

I would extend to 'starting in "XX--" where X can be any ascii character" because who knows whether we need a completely different prefix one day.

Or you should explicitly note that ascii-only mailboxes do imply the litteral value and those strings MUST NOT be interpreted as A-Labels.

> Do you have a suggestion where this should be clarified?

What about here in section 4 (which I presume is referenced implicitly, or similar places where it is noted some transformation is done (between A-Labels and U-Labels):

OLD:

In setup for SmtpUtf8Mailbox, the email address local-part MUST be converted to UTF-8 if it is not already.

NEW:

In setup for SmtpUtf8Mailbox, the email address local-part MUST be converted to UTF-8 if it is not already. The local-part MUST NOT be transformed in any way, for example by doing case folding or normalization of any kind.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jan 2017 18:10:28 -0500

--On Monday, January 23, 2017 22:50 +0100 Patrik Fältström
<[email-masked]> wrote:

>...
> OLD:
> 
> In setup for SmtpUtf8Mailbox, the email address local-part
> MUST be converted to UTF-8 if it is not already.
> 
> NEW:
> 
> In setup for SmtpUtf8Mailbox, the email address local-part
> MUST be converted to UTF-8 if it is not already. The
> local-part MUST NOT be transformed in any way, for example by
> doing case folding or normalization of any kind.

That reinvents the same apparent contradiction I was concerned
about.  RFC 6530 and 6531 require (there is a MUST) in Section
1.1 of 6531 and maybe elsewhere) that all relevant strings,
including Mailboxes, be in UTF-8 (noting that an all-ASCII
string with ASCII encoded in the usual octet form with a leading
zero bit followed by (seven-bit) ASCII is a string encoded in
UTF-8.     So there is no such thing as a SMTPUTF8-valid
local-part that is not in UTF-8 and no conversion can possibly
be needed.   If it is needed, then this I-D is allowing
local-part strings that do not conform to 6530/6531 (or 5321 for
that matter).  If that were the intent, a _lot_ more discussion
is needed, if only because I believe there are CCSs floating
around that do not have obvious and unique transformations to
Unicode (which would be a necessary step to get them to [Unicode
in] UTF-8).

Then you say "MUST NOT be transformed in any way", which is
correct, but "conversion to UTF-8", required by the previous
sentence, is "transformed in [some] way".

One way out of this would be to say 

NEW2:

	In setup for SmtpUtf8Mailbox, the email address
	local-part MUST conform to the requirements of RFC 6530
	and 6531, including already being a string in UTF-8
	form.  In particular, the local-part MUST NOT be
	transformed in any way, such as by doing case folding or
	normalization of any kind.

That accomplishes two things:

(i) It avoids the apparent contradiction.

(ii) It puts the responsibility for the restriction on the
SMTPUTF8 specs and makes it clear that this I-D is just carrying
those restrictions over.  IMO, the less this spec appears to be
imposing its own restrictions, the better off we will all be.
That is especially important if there is even the vaguest of
chances that we might eventually decide that unnormalized
strings, or strings with no restrictions on the code points
(other than those ASCII-repertoire characters prohibited by RFC
5321), are a terrible idea and either deprecate or recommend
against their use.    If this part of this document is strictly
dependent on 6531 and its successors, we avoid the need to
untangle it to reflect that change and the risk of having it be
contradictory to the mail spec.

best,
    john

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 24 Jan 2017 00:16:40 +0100

On 24 Jan 2017, at 0:10, John C Klensin wrote:

> --On Monday, January 23, 2017 22:50 +0100 Patrik Fältström <[email-masked]> wrote:
>
>> ...
>> OLD:
>>
> That reinvents the same apparent contradiction I was concerned about.  RFC 6530 and 6531 require (there is a MUST) in Section 1.1 of 6531 and maybe elsewhere) that all relevant strings,
> string with ASCII encoded in the usual octet form with a leading zero bit followed by (seven-bit) ASCII is a string encoded in UTF-8.     So there is no such thing as a SMTPUTF8-valid
> local-part that is not in UTF-8 and no conversion can possibly be needed.   If it is needed, then this I-D is allowing
> local-part strings that do not conform to 6530/6531 (or 5321 for that matter).  If that were the intent, a _lot_ more discussion is needed, if only because I believe there are CCSs floating around that do not have obvious and unique transformations to Unicode (which would be a necessary step to get them to [Unicode in] UTF-8).
>
> correct, but "conversion to UTF-8", required by the previous sentence, is "transformed in [some] way".
>

True, thanks.

   paf

> SMTPUTF8 specs and makes it clear that this I-D is just carrying those restrictions over.  IMO, the less this spec appears to be imposing its own restrictions, the better off we will all be.
> That is especially important if there is even the vaguest of chances that we might eventually decide that unnormalized
> (other than those ASCII-repertoire characters prohibited by RFC 5321), are a terrible idea and either deprecate or recommend against their use.    If this part of this document is strictly dependent on 6531 and its successors, we avoid the need to
> untangle it to reflect that change and the risk of having it be contradictory to the mail spec.
>
> best,
>     john

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2017 02:01:38 -0000

>completely different prefix one day.

I hope you mean X can be any ascii letter or digit.  After all, Ctrl/C is an ASCII character.

>Or you should explicitly note that ascii-only mailboxes do imply the literal value and those strings MUST NOT
>be interpreted as A-Labels.

Urrgh.  As far as I know, this is an entirely valid ASCII address:

  [email-masked]

That domain name happens to be the A-label for exámple.com but so what?

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jan 2017 21:43:04 -0500

--On Tuesday, January 24, 2017 02:01 +0000 John Levine
<[email-masked]> wrote:

>> I would extend to 'starting in "XX--" where X can be any
>> ascii character" because who knows whether we need a
>> completely different prefix one day.
> 

Let me made the suggestion differently.   The restriction is in
2.3.1 of RFC 5890.  This document should either incorporate that
restriction by reference and say as little as possible itself or
be sure that whatever it does say is _exactly_ consistent with
the definition there.   In doing that, note that Figure 1 is a
little bit confusing about R-LDH because there is no box for, or
formal name assigned to, non-XN R-LDH labels.

That said, if X and Y are letters or digits, "XY--" is
prohibited because it is an R-LDH label that is not an A-label.
If X and/or Y are something else (an ASCII graphic that is
neither a letter nor a digits, or  even some C0 control) then
whether it is prohibited because the third and fourth characters
are hyphens or prohibited because the characters are not letters
or digits is of the most pedantic interest only because it is
prohibited nonetheless.  It is actually important to not get
wrapped around that axle because "----foo" is prohibited too and
that string consists entirely of so-called LDH characters.

>> Or you should explicitly note that ascii-only mailboxes do
>> imply the literal value and those strings MUST NOT be
>> interpreted as A-Labels.
> 
> That domain name happens to be the A-label for ex᭰le.com but
> so what?

Have you read the spec, or are you just responding to my notes
and/or Patrik's?    The LAMPS WG apparently decided that it
wanted to insist on U-labels when IDN labels were concerned and
that doing so would make comparison rules easier.  I wasn't part
of their discussions, but believe the issue was that they
concluded that certificates should contain one form or the
other, but not both (or either on a per-cert basis), and then
selected the U-label form.  Doing that avoids their having to
decide whether [email-masked] and fred@ex᭰le.com were
equal and, I assume, a whole set of even more complex issues
about hashes and signatures over certificates.

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.

What started the discussion about how to state the prohibition
on A-labels is that, unless there is a good reason not to, one
needs a rule that does not allow what RFC 5890 calls "Fake
A-labels" to be treated as valid strings even while valid
A-labels are not.  The stronger restriction, i.e., "nothing with
'--' in the third or fourth positions", is actually somewhat
easier to state and far easier to implement in practice than
splitting hairs.  Again, unless someone can think of a good
reason to allow a Fake A-label in a cert while valid A-labels
are not allowed.

best,
   john

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 24 Jan 2017 05:54:25 +0100

> I hope you mean X can be any ascii letter or digit.  After all, Ctrl/C is an ASCII character.

Yes, of course.

> That domain name happens to be the A-label for exámple.com but so what?

Sure, but my point was that this spec must make up its mind here. Should labels be allowed which being with XX-- be allowed or not, and if they are (instead of just ignored) should they be interpreted as their literal values or as A-Labels?

What I see is that one do *NOT* want to allow labels starting with XX-- (as one must use U-Lables) but I see between the lines that the reasoning behind that is that there might be some backward compatibility to cases where already deployed labels exists in the wild that start with XX--.

This should be spelled out explicitly in the draft so that people really understand what the thinking in, and not hidden in some (for non-english speaking people) complicated english.

   paf

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Jan 2017 05:42:12 +0000

On Mon, Jan 23, 2017 at 09:43:04PM -0500, John C Klensin wrote:

> The LAMPS WG apparently decided that it

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.

This does mean one one will not be able to obtain a useful certificate
for addresses like [email-masked], 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:

    * [email-masked]
    * [email-masked]

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 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.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Jan 2017 01:05:14 -0500

--On Tuesday, January 24, 2017 05:42 +0000 Viktor Dukhovni
<[email-masked]> 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

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 [email-masked],
> 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.
> 
> 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.

---

From: "John R Levine" <[email-masked]>
Date: 24 Jan 2017 11:40:04 -0500

> and/or Patrik's?

I reread the spec, which was a good idea.  It says the domain names can 
contain U-labels and NR-LDH ASCII labels, which seems correct.  That 
forbids both A-labels and dodgy stuff that looks like A-labels but isn't.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Jan 2017 12:25:02 -0500

--On Tuesday, January 24, 2017 11:40 -0500 John R Levine
<[email-masked]> wrote:

> I reread the spec, which was a good idea.  It says the domain
> names can contain U-labels and NR-LDH ASCII labels, which
> seems correct.  That forbids both A-labels and dodgy stuff
> that looks like A-labels but isn't.

Thanks.  That is consistent with my impression.   My concern is
that the language and terminology won't make it clear about what
is being specified unless someone is _really_ familiar with IDNA
and the "EAI" specs.   It meshes with Patrik's concern that the
wording of the spec won't be clear to someone who is not _very_
good with English.

My impression is that there is little problem with the intended
underlying spec, but the document text needs some tuning.

     john

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2017 19:31:09 -0000

>underlying spec, but the document text needs some tuning.

Agreed.  The subsequent section on comparing names would likely
benefit from clearer instructions, e.g.

a) if the domain contains A-labels, turn them into U-labels
b) if the domain still contains R-LDH labels, stop, not a valid name.
c) if the domain contains NR-LDH labels, make them all the same case
d) do a straight byte comparison of the addresses

R's,
John