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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 28 February 2017 16:30 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 E73C2129621 for <ietf@ietfa.amsl.com>; Tue, 28 Feb 2017 08:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 LHsy1U6lNlXO for <ietf@ietfa.amsl.com>; Tue, 28 Feb 2017 08:30:39 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64C0129628 for <ietf@ietf.org>; Tue, 28 Feb 2017 08:30:38 -0800 (PST)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 236217A330A for <ietf@ietf.org>; Tue, 28 Feb 2017 16:30:38 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
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 <ietf-dane@dukhovni.org>
In-Reply-To: <CAAFsWK2h1phbNhwxx+q5X_PPKe7OrFBC1ScmP91Z=PLxqwEk-Q@mail.gmail.com>
Date: Tue, 28 Feb 2017 11:30:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <437CDE7D-0261-474A-B752-6A5403C34B23@dukhovni.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> <CAAFsWK2h1phbNhwxx+q5X_PPKe7OrFBC1ScmP91Z=PLxqwEk-Q@mail.gmail.com>
To: IETF general list <ietf@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ky0K2re5Be5v-jvCJzv0mjgjIk4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: IETF general list <ietf@ietf.org>
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: Tue, 28 Feb 2017 16:30:41 -0000

> On Feb 28, 2017, at 6:11 AM, Wei Chuang <weihaw@google.com> wrote:
> 
>> Given that rfc822Name is a well-known legacy element, while SmtpUtf8Name
>> is a novel element, the prescription can be asymmetric.  Specifically,
>> all that's really needed (in the simpler model proposed by John) is
>> to disallow SmtpUtf8Name altnames when (only) rfc822Name constraints
>> are present.
>> 
>> The converse is not required, a parent CA that is SmtpUtf8Name aware
>> and wants to issue a child CA with SmtpUtf8Name constraints can and
>> should also include appropriate rfc822Name constraints that ensure
>> that the desired SmtpUtf8Name constraints are not bypassed via
>> unauthorized rfc822Name altnames.
>> 
>> The rfc822Name constraints can either permit only equivalent domain
>> names (LDH or A-label forms), or, if no rfc822Name can be compatible
>> with the SmtpUtf8Name constraints, permit only something like
>> "nouser@nodomain.invalid"alid", thereby excluding all valid rfc822 addresses.
> 
> Apologies about being pedantic.  If we specify the CA name constraints as you describe above with the asymmetric requirements on SmtpUtf8Name, are you okay with the draft's position on keeping separate name constraint processing for rfc822Name and SmtpUtf8Name types?  In other words the above is proposed to be the resolution for the issue raised in your email Feb 11th, second email, para 1-3 i.e. preventing evasion of name constraints.  

Works for me.

-- 
	Viktor.