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

Jim Schaad <> Thu, 23 February 2017 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 404E412940A; Thu, 23 Feb 2017 13:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7LV7Za_VGJTP; Thu, 23 Feb 2017 13:46:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (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;; 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 ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 13:46:11 -0800
Received: from hebrews ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 13:43:36 -0800
From: Jim Schaad <>
To: 'John C Klensin' <>,
References: <> <>
In-Reply-To: <>
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$>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLDY2fkRCgzG0ihtoVsZdX9vIbgygGIv4dMn4kvBMA=
X-Originating-IP: []
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 21:46:19 -0000


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.


> -----Original Message-----
> From: Spasm [] On Behalf Of John C Klensin
> Sent: Sunday, January 22, 2017 11:47 AM
> To:
> Cc:;; draft-ietf-lamps-eai-
> 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-
>> 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
> the work that this extends, I'll leave those questions to others and the
> Editor.  Most of what follows is nit-picking, but significant parts of it
> 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
> 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
> 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
> be ok due to the language in the third (" This document further
> and subsequent paragraphs in Section 3, but the explanation could easily
> 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
> 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"
> RFC 1034/1035 (commonly known as "LDH syntax").  As important, it is
> possible to construct strings that look (lexically) like A-labels but are
> 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
> above) but requires much more specific knowledge of the IDNA2008 protocol
> set (particularly RFC 5890 in this case) than I predict readers of this
> will have.  See RFC 5890 and 5894 for more discussion on this issue and
> 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
> "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
> 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
> historically most often used for/on the Internet is "ASCII" not "ascii" or
> other variation.  "US-ASCII" is common to but, since there isn't any
> 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
> inconsistently.
> (7) In part because of the normalization issue mentioned briefly above,
> Security Considerations section should probably mention not only "visually
> similar characters" but "visually identical strings".  Note that, at least
> 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\" 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