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

Stephen Farrell <> Thu, 23 February 2017 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0259129A9E; Thu, 23 Feb 2017 12:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4368ryaAmxra; Thu, 23 Feb 2017 12:16:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCAF7129A8B; Thu, 23 Feb 2017 12:16:44 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61A19BE3E; Thu, 23 Feb 2017 20:16:42 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tnglWHDyLc9J; Thu, 23 Feb 2017 20:16:41 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id B3157BE38; Thu, 23 Feb 2017 20:16:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1487881001; bh=AjFh+hwxoaGT4Bg9EGW7Oh33/RsFfxfBSchIucXBhRw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YTm9gZZQH12Nack20ayVV3WpLbzMx3y017ljvkHbxSlH+xks1sU43iztItMbpS+GU 1PjvVIUQraJBnmJpslzQpf61HJBlKZSHp7ErrsSn7ZniALRcUgG4hQ/oOyHdL92d4Y YvcxRjTfV44NCNuBirr+vpA/QD4JnVj/woFIKbgM=
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
To: IETF general list <>
References: <alpine.OSX.2.20.1702111606270.2386@ary.qy> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 23 Feb 2017 20:16:40 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="2R6chPAJhdmCeBoGv7Vpuq8RIa5KjpgOq"
Archived-At: <>
Cc: "" <>
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: Thu, 23 Feb 2017 20:16:47 -0000


I've just reviewed the IETF LC for this draft. Thanks all for
the comments and discussion which I think have thrown up some
real issues.

As of now, it is not clear to me that we have finished the
work with this one, at least the issues to do with name
constraints seem to me to call for some more WG consideration.

I think Russ (as lamps WG chair) has a similar opinion
that we're not done yet.

That said, I had put this on the March 16th IESG telechat
for consideration. If we do manage to reach a clear enough
consensus on a published revision to the draft in say the
next week then that schedule should still be fine. So I'd
encourage the authors and others who've commented to try
again and see if, in that timeframe, we can get to where
we're happy that the issues raised have been handled well

But, if it looks (as it does to me today) as if this'll take
a bit longer to figure out, then I figure the right thing to
do will be to let the lamps WG figure out how to proceed.
(And that'll mean that my successor as the responsible AD
for the lamps WG will handle further actions with the doc.)

Bottom line: if this isn't settled in the next week or so,
I'll take it off the March 16th IESG telechat and let the WG
continue the discussion.


PS: To add to the name constraints discussion, I did wonder
if anyone really wants to use those. So for example, if we
defined the new name form so that certificate chains with
any name constraints at all and one of those names anywhere
are always treated as invalid, then would that cause any
real breakage? (It certainly would cause theoretical breakage,
but if that's all then I'd be ok with that:-)