ietf
[Top] [All Lists]

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

2017-02-23 15:46:36
John,

I have used and have seen used the term of US-ASCII to refer to 7-bit ASCII
as opposed to the full 8-bit ASCII.  I think that this generally makes sense
and therefore am unsure that the term should be removed.

Jim


-----Original Message-----
From: Spasm [mailto:spasm-bounces(_at_)ietf(_dot_)org] On Behalf Of John C 
Klensin
Sent: Sunday, January 22, 2017 11:47 AM
To: ietf(_at_)ietf(_dot_)org
Cc: spasm(_at_)ietf(_dot_)org; lamps-chairs(_at_)ietf(_dot_)org; 
draft-ietf-lamps-eai-
addresses(_at_)ietf(_dot_)org
Subject: Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt>
(Internationalized Email Addresses in X.509 certificates) to Proposed
Standard



--On Monday, January 16, 2017 2:45 PM -0800 The IESG <iesg-
secretary(_at_)ietf(_dot_)org> 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\u5E2B(_at_)example(_dot_)com" does not appear to be referenced or
described anywhere in the document, nor is it consistent with the
recommendations of RFC 5137.

best,
   john



_______________________________________________
Spasm mailing list
Spasm(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/spasm

<Prev in Thread] Current Thread [Next in Thread>