RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Jim Schaad <ietf@augustcellars.com> Thu, 23 February 2017 21:46 UTC
Return-Path: <ietf@augustcellars.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 404E412940A; Thu, 23 Feb 2017 13:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 7LV7Za_VGJTP; Thu, 23 Feb 2017 13:46:17 -0800 (PST)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172B4129997; Thu, 23 Feb 2017 13:46:16 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1487886372; h=from:subject:to:date:message-id; bh=u7Vz5MbN7nAQN6W9gBIiMddB31v9jF7HvbVUsqBS3Qs=; b=WhyWd+EU83geu92MZaKj7LK6q9XxdwqkeW7Eb33PFsKTmYSgVKnsq6e7EzRTdiZ5lEhu9SxPwmM v4haIVQpapKhLfRI791bMHRkgE9lavOWo51GBqVfE88T4onvEQX9GcywVYLeUHpEeU1P5rzkIJm0G lpFbdCzkoJHL7y+WnhHdGGjHTuigLPLIfI8ZBunQgI2u7hgrsgNNkB8en7VrQNTCAH16rJQtVC3+L 86KWamYJb/0I1EF8LCStym0wqCDQNNpHkTIm6PKuTNty2SV7kQEPiOVNPK3xBNKgr+NKGUClB8enL GRrxFERlpCaSfNGIsreEZMfojTJwxyZF5chQ==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 13:46:11 -0800
Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 13:43:36 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'John C Klensin' <klensin@jck.com>, ietf@ietf.org
References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <E61E7383DDD7A81671C398EC@JcK-HP5.jck.com>
In-Reply-To: <E61E7383DDD7A81671C398EC@JcK-HP5.jck.com>
Subject: RE: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Date: Thu, 23 Feb 2017 13:44:53 -0800
Message-ID: <009201d28e1e$13337c30$399a7490$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLDY2fkRCgzG0ihtoVsZdX9vIbgygGIv4dMn4kvBMA=
X-Originating-IP: [173.8.216.38]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nLrKf301V6lVgTCLHIuftCRkSeQ>
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: Thu, 23 Feb 2017 21:46:19 -0000
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@ietf.org] On Behalf Of John C Klensin > Sent: Sunday, January 22, 2017 11:47 AM > To: ietf@ietf.org > Cc: spasm@ietf.org; lamps-chairs@ietf.org; draft-ietf-lamps-eai- > addresses@ietf.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@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 > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm
- 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… 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… 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… 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