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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 08 March 2017 16:22 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D21126DFB; Wed, 8 Mar 2017 08:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K7OAnCzeD2o; Wed, 8 Mar 2017 08:22:29 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59911293FB; Wed, 8 Mar 2017 08:22:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 359FEBE74; Wed, 8 Mar 2017 16:22:27 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7VJ91IF2gm0; Wed, 8 Mar 2017 16:22:26 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80A11BE5C; Wed, 8 Mar 2017 16:22:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488990146; bh=lY6U4W5VBenuNRZ4o8uth1UN4sqP7TcC5DK94bv2Vbo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Jhx9pK7lqgDgPkkiVbIStuwtRRFnndGn8Xjui467XoiO48ItlD7LZOFPfXg4vMgJ3 wQVixcWIc5qY3pHTXfFIwePDzwCZSq33B35YgtKVisXLQEE8gusnvIJ0YAxNgPXIaP zUY7V1PkJ7WWRNdTcEIEAy1T4oQyngNinxsbvE88=
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 <ietf@ietf.org>
References: <alpine.OSX.2.20.1702111606270.2386@ary.qy> <CAAFsWK0KoeeHeKxay=j=NR8AqbzaHXtjNoQNQqRHwUNT3-Pe_Q@mail.gmail.com> <D237E866-CEC3-4A3C-9D5E-0D1B48F1799B@dukhovni.org> <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie>
Date: Wed, 08 Mar 2017 16:22:25 +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: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="quAp4X6UJvPOAv7q2DWUgEAos2xxHDs4F"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/G-UGc8g7U__5sYvLxHVWlz9n5z8>
Cc: "spasm@ietf.org" <spasm@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 16:22:31 -0000

Hiya,

So I don't think we've yet resolved the issues raised
with this. And since the March 16th telechat will be my
last one I figure that the best thing to do is to ask
that this go back to the working group for resolution.

Once that's sorted out, then the WG can kick it over
to their new AD. Note that this need not add any major
delay - it'd be entirely possible to have it back on a
telechat agenda shortly after IETF98, all going well.

If nobody yells, I'll do that tomorrow.

If someone does yell, please do that now and accompany
your yell with the OLD/NEW changes that you claim resolve
the issues raised. (To be honest though, I think this
would benefit from more WG discussion so I'll not be so
easy to convince if someone does yell thusly;-)

Cheers,
S.

On 23/02/17 20:16, Stephen Farrell wrote:
> 
> Folks,
> 
> 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
> enough.
> 
> 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.
> 
> Cheers,
> S.
> 
> 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:-)
> 
> 
>