Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
John C Klensin <klensin@jck.com> Sun, 22 January 2017 19:47 UTC
Return-Path: <klensin@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF781298A8; Sun, 22 Jan 2017 11:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtfyPMTYN00k; Sun, 22 Jan 2017 11:47:00 -0800 (PST)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CDC1298AF; Sun, 22 Jan 2017 11:46:54 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <klensin@jck.com>) id 1cVO6F-0005RJ-KV; Sun, 22 Jan 2017 14:46:51 -0500
Date: Sun, 22 Jan 2017 14:46:46 -0500
From: John C Klensin <klensin@jck.com>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <E61E7383DDD7A81671C398EC@JcK-HP5.jck.com>
In-Reply-To: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com>
References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/EshdU-le0c9B7gYS8d0X228bhPM>
Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Jan 2017 19:47:02 -0000
--On Monday, January 16, 2017 2:45 PM -0800 The IESG <iesg-secretary@ietf.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@example.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
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Alexey Melnikov
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Diversity, writing systems, identifiers, and prot… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R. Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Stephen Farrell
- RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Jim Schaad
- RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Stephen Farrell
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… tom p.
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang