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

"Patrik Fältström " <> Mon, 23 January 2017 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 976F31298C5; Mon, 23 Jan 2017 13:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ORyWhC9Go3Yg; Mon, 23 Jan 2017 13:50:17 -0800 (PST)
Received: from ( [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A1AF1298C3; Mon, 23 Jan 2017 13:50:17 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 07A6420599; Mon, 23 Jan 2017 22:50:13 +0100 (CET)
From: Patrik Fältström <>
To: Alexey Melnikov <>
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Date: Mon, 23 Jan 2017 22:50:14 +0100
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_61FB970E-5EAF-4189-9CA5-B0175CDCDC81_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (2.0BETAr6072)
Archived-At: <>
Cc:,,, John C Klensin <>,
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 21:50:19 -0000

On 23 Jan 2017, at 14:40, Alexey Melnikov wrote:

> Thank you for your thorough review! My comments/answers below:

I have a few comments as well. Basically I agree with what John writes, but let me add some additional spice.

>> (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.

I would extend to 'starting in "XX--" where X can be any ascii character" because who knows whether we need a completely different prefix one day.

Or you should explicitly note that ascii-only mailboxes do imply the litteral value and those strings MUST NOT be interpreted as A-Labels.

>> (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?

What about here in section 4 (which I presume is referenced implicitly, or similar places where it is noted some transformation is done (between A-Labels and U-Labels):


In setup for SmtpUtf8Mailbox, the email address local-part MUST be converted to UTF-8 if it is not already.


In setup for SmtpUtf8Mailbox, the email address local-part MUST be converted to UTF-8 if it is not already. The local-part MUST NOT be transformed in any way, for example by doing case folding or normalization of any kind.