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

John C Klensin <> Tue, 24 January 2017 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DFD612955D for <>; Mon, 23 Jan 2017 18:43:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zeTjPGCq7bq0 for <>; Mon, 23 Jan 2017 18:43:13 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87FFC129555 for <>; Mon, 23 Jan 2017 18:43:13 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1cVr4h-000Cwi-D2; Mon, 23 Jan 2017 21:43:11 -0500
Date: Mon, 23 Jan 2017 21:43:04 -0500
From: John C Klensin <>
To: John Levine <>,
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <2A6C1E77A2FDB3E4147305EA@PSB>
In-Reply-To: <20170124020138.65213.qmail@ary.lan>
References: <20170124020138.65213.qmail@ary.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 24 Jan 2017 02:43:15 -0000

--On Tuesday, January 24, 2017 02:01 +0000 John Levine
<> wrote:

> In article <>
> you write:
>>> 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.
> I hope you mean X can be any ascii letter or digit.  After
> all, Ctrl/C is an ASCII character.

Let me made the suggestion differently.   The restriction is in
2.3.1 of RFC 5890.  This document should either incorporate that
restriction by reference and say as little as possible itself or
be sure that whatever it does say is _exactly_ consistent with
the definition there.   In doing that, note that Figure 1 is a
little bit confusing about R-LDH because there is no box for, or
formal name assigned to, non-XN R-LDH labels.

That said, if X and Y are letters or digits, "XY--" is
prohibited because it is an R-LDH label that is not an A-label.
If X and/or Y are something else (an ASCII graphic that is
neither a letter nor a digits, or  even some C0 control) then
whether it is prohibited because the third and fourth characters
are hyphens or prohibited because the characters are not letters
or digits is of the most pedantic interest only because it is
prohibited nonetheless.  It is actually important to not get
wrapped around that axle because "----foo" is prohibited too and
that string consists entirely of so-called LDH characters.

>> Or you should explicitly note that ascii-only mailboxes do
>> imply the literal value and those strings MUST NOT be
>> interpreted as A-Labels.
> Urrgh.  As far as I know, this is an entirely valid ASCII
> address:
> That domain name happens to be the A-label for ex᭰ but
> so what?

Have you read the spec, or are you just responding to my notes
and/or Patrik's?    The LAMPS WG apparently decided that it
wanted to insist on U-labels when IDN labels were concerned and
that doing so would make comparison rules easier.  I wasn't part
of their discussions, but believe the issue was that they
concluded that certificates should contain one form or the
other, but not both (or either on a per-cert basis), and then
selected the U-label form.  Doing that avoids their having to
decide whether and fred@ex᭰ were
equal and, I assume, a whole set of even more complex issues
about hashes and signatures over certificates.

I can argue for the choice of A-labels rather than U-labels (or
vice versa), but the choice is a matter of taste and I'm happy
to accept the WG's analysis and decision.

What started the discussion about how to state the prohibition
on A-labels is that, unless there is a good reason not to, one
needs a rule that does not allow what RFC 5890 calls "Fake
A-labels" to be treated as valid strings even while valid
A-labels are not.  The stronger restriction, i.e., "nothing with
'--' in the third or fourth positions", is actually somewhat
easier to state and far easier to implement in practice than
splitting hairs.  Again, unless someone can think of a good
reason to allow a Fake A-label in a cert while valid A-labels
are not allowed.