Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Alexey Melnikov <alexey.melnikov@isode.com> Mon, 23 January 2017 13:40 UTC
Return-Path: <alexey.melnikov@isode.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 22AE11295F8; Mon, 23 Jan 2017 05:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.2
X-Spam-Level:
X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 6RBxy4uZDbVD; Mon, 23 Jan 2017 05:40:44 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 92FED12950B; Mon, 23 Jan 2017 05:40:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1485178843; d=isode.com; s=june2016; i=@isode.com; bh=wiN/LnCNB8JDAgu70rqf8Wfk0OOQhOueVsneqSMMLAE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OMGlSoDTARi4d2My9wsgHPfXXn8/XEUwJLXMXiidi0iJ6Gacmzx7a65rclql9mVyxjrGQK M1rDA3IgMBlnL2q/cLl6N5PMXl9LCMB4aTQrTZIlaEHjyAuOG10yCDZVFXTtezErO8xnxT 8QwUADHUnHXE0R+cnZruUGVwHhDKz2k=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <WIYH2gAY1405@statler.isode.com>; Mon, 23 Jan 2017 13:40:43 +0000
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
To: John C Klensin <klensin@jck.com>, ietf@ietf.org
References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <E61E7383DDD7A81671C398EC@JcK-HP5.jck.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com>
Date: Mon, 23 Jan 2017 13:40:41 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
In-Reply-To: <E61E7383DDD7A81671C398EC@JcK-HP5.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8eVRK74mFCFzxldL-TkW5FS7uJY>
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: Mon, 23 Jan 2017 13:40:46 -0000
Hi John, Thank you for your thorough review! My comments/answers below: On 22/01/2017 19:46, John C Klensin wrote: > --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. Sounds fair, this should be fixed. > (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. Very good point. Would just changing the first sentence in "Introduction" to reference RFC 5321 address this concern? > 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. I think this needs to be discussed a bit more in the LAMPS WG, but you have a good point here. > (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). Yes, I agree this should be said explicitly. > (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. Do you have a suggestion where this should be clarified? > (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. Ok. We should fix. > (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. Right. > (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. Yes, we should either specify the notation or use RFC 5137. Best Regards, Alexey
- 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