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

Viktor Dukhovni <> Fri, 03 February 2017 16:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86697129691 for <>; Fri, 3 Feb 2017 08:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XkAPdlFDI-nK for <>; Fri, 3 Feb 2017 08:49:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C22C129669 for <>; Fri, 3 Feb 2017 08:49:31 -0800 (PST)
Received: from [IPv6:2604:2000:1382:81a2:a15d:7573:e5c2:bb3f] (unknown [IPv6:2604:2000:1382:81a2:a15d:7573:e5c2:bb3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 556BB284E4B for <>; Fri, 3 Feb 2017 16:49:29 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
From: Viktor Dukhovni <>
In-Reply-To: <D45CE6A5317D4B373CD90742@PSB>
Date: Fri, 03 Feb 2017 11:49:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan> <> <D45CE6A5317D4B373CD90742@PSB>
To: IETF general list <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: IETF general list <>
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Feb 2017 16:49:32 -0000

> On Feb 3, 2017, at 11:07 AM, John C Klensin <> wrote:
> As to "put all the alternate forms in the cert", we've been
> there too and it hasn't ended happily.

I must say that I am quite sympathetic to many of the points
you raise.  As is often the case in discussions of the finer
points of an issue, we're not as far apart as it may seem.
That said, I do want to comment on the objection to having
to deal with "all the alternative forms".

My suggestion is not to publish a combinatorial explosion.
Rather, my suggestion is to publish precisely the verbatim
forms that users will emit as their purported email addresses
in message origin headers.  If they use an address form that
is not published in the certificate (without any coversions)
then the certificate will not match the purported author.

Thus I would expect that for a user with an all-ASCII localpart
name, there might in be a need to use one of two addresses.
For me that might be (neither address is currently provisioned):


I might then use the former in email with peers whose systems
support "EAI" and the latter with peers whose systems do not.
Had I, hypotheticall, registered a related domain under a
Cyrillic TLD, I would still use one of two address forms


and these (or whatever the user actually needs to be known
as) would be the only ones in the certificate.  This is not
very different from a certificate with two addresses in
domains that are simply distinct, rather than just being
variant encodings of the same thing:

Such a certificate (like many a PGP public key) carries
multiple personae.  Putting multiple extant address forms
in a certificate can free the verifier from performing any
encoding conversions.  Perhaps that's worthwhile.

A certificate that lists multiple address forms, whether
semantically distinct, or just variant encodings, may be
more likely to work with verifiers that predate the
specification and do no conversions.  Forbidding variant
forms can close off interoperability options.