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

From: The IESG <[email-masked]>
Date: Mon, 16 Jan 2017 14:45:31 -0800

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2017-01-30. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines a new name form for inclusion in the otherName
   field of an X.509 Subject Alternative Name and Issuer Alternate Name
   extension that allows a certificate subject to be associated with an
   Internationalized Email Address.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ballot/

No IPR declarations have been submitted directly on this I-D.

RFC5912 is already noted as an acceptable downref.

---

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: Russ Housley <[email-masked]>
Date: Mon, 23 Jan 2017 08:56:58 -0500

Alexey said:

> I think this needs to be discussed a bit more in the LAMPS WG, but you have a good point here.

What is the best way to resolve this comment in the document?

Russ

---

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 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: Wei Chuang <[email-masked]>
Date: Tue, 24 Jan 2017 15:17:04 -0800

The last-call thread seems to be coming to a resolution on a suggested path
forward with comment 3).  If we could wait for a day or so, I think the
feedback there will be clear.

Apologies for not bringing in feedback sooner, but all the important points
were already covered by folks in that thread.

-Wei

On Mon, Jan 23, 2017 at 5:56 AM, Russ Housley <[email-masked]> wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>