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

John C Klensin <> Wed, 08 February 2017 10:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E99EE129590 for <>; Wed, 8 Feb 2017 02:18:30 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id COF705rf4TZf for <>; Wed, 8 Feb 2017 02:18:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1C40128E18 for <>; Wed, 8 Feb 2017 02:18:29 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1cbPKW-000PEv-Rh for; Wed, 08 Feb 2017 05:18:28 -0500
Date: Wed, 08 Feb 2017 05:18:22 -0500
From: John C Klensin <>
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <291B1050C3EE53B9DB4D8BF4@PSB>
In-Reply-To: <>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan> <> <D45CE6A5317D4B373CD90742@PSB> <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Wed, 08 Feb 2017 10:18:31 -0000

--On Wednesday, February 8, 2017 05:13 +0000 Viktor Dukhovni
<> wrote:

> I am asking the author to remove that dependency, leaving
> construction of the normal form of the reference identifier to
> the application rather than the X.509 stack.  If he is
> unsuccessful, and there is a fundamental requirement for X.509
> certificate validation code to become IDNA aware, that'd be a
> major barrier to widespread support for this specification.

As you and others have pointed out, SMTPUTF8 is deploying rather
slowly.   That should not be a surprise to anyone who
participated in the WG discussions and understands the issues --
there are a complex sequencing and support tradeoffs involved
although with a number of problems some would describe as
involving "chicken and egg" relationships and others would claim
would benefit from a flag day.

So, as I understand it, you want to shift the issues to the
application in order to get more rapid deployment.  I prefer to
keep the decisions, including a single canonical form, bound to
the X.509 certificate because I think, especially given the
security implications of either false positives or false
negatives, that getting implementations right (and consistent)
is more important than getting quick deployment.   A preference
for "right" over "quick" is particularly important where IDNs
are concerned given the number of inconsistent implementations
of things claiming to be IDNA in the wild.