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

"John Levine" <> Fri, 03 February 2017 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1C0F129693 for <>; Fri, 3 Feb 2017 09:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NrmV7sZLmeDr for <>; Fri, 3 Feb 2017 09:21:10 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E119D129683 for <>; Fri, 3 Feb 2017 09:21:09 -0800 (PST)
Received: (qmail 3605 invoked from network); 3 Feb 2017 17:21:09 -0000
Received: from unknown ( by with QMQP; 3 Feb 2017 17:21:09 -0000
Date: Fri, 03 Feb 2017 17:20:47 -0000
Message-ID: <20170203172047.13653.qmail@ary.lan>
From: John Levine <>
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
In-Reply-To: <D45CE6A5317D4B373CD90742@PSB>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
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: Fri, 03 Feb 2017 17:21:21 -0000

In article <D45CE6A5317D4B373CD90742@PSB> you write:
>Victor, Wei Chuang, and IESG,
>The more this discussion goes on, the more I become convinced
>that this document should make an explicit reference to the IDNA
>2008 and SMTPUTF8 documents, say that strings in certificates
>MUST conform to whatever is allowed there and then, other than
>making a statement about preference for U-labels over A-labels
>(or vice versa), say as little as possible. ...

I'd like to endorse John's point -- if these things look like e-mail
addresses, they should *be* e-mail addresses, with the same rules.
Particularly in a security context, we're not doing people any favors
by allowing strings that look almost like addresses but aren't, or
alternate forms where users have to decide whether they're equivalent.

If people want to do experiments with other kinds of names, that
is fine, but they don't go into a standards track document.  If
they turn out to be useful, we can add them to the spec later.