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

Alexey Melnikov <> Mon, 23 January 2017 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22AE11295F8; Mon, 23 Jan 2017 05:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.2
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6RBxy4uZDbVD; Mon, 23 Jan 2017 05:40:44 -0800 (PST)
Received: from ( []) by (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;; s=june2016;; 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 [] ( []) by (submission channel) via TCP with ESMTPSA id <>; 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 <>,
References: <> <>
From: Alexey Melnikov <>
Message-ID: <>
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: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
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: 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
> <> 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.
> (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.
Yes, we should either specify the notation or use RFC 5137.

Best Regards,