--On Monday, January 16, 2017 2:45 PM -0800 The IESG
<iesg-secretary@xxxxxxxx> 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@xxxxxxxxxxx" does not appear to be referenced
or described anywhere in the document, nor is it consistent with
the recommendations of RFC 5137.
best,
john