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

Wei Chuang <weihaw@google.com> Tue, 28 February 2017 11:11 UTC

Return-Path: <weihaw@google.com>
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 31DF4129516 for <ietf@ietfa.amsl.com>; Tue, 28 Feb 2017 03:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 FD1U-DoToyYW for <ietf@ietfa.amsl.com>; Tue, 28 Feb 2017 03:11:50 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7321D12950F for <ietf@ietf.org>; Tue, 28 Feb 2017 03:11:50 -0800 (PST)
Received: by mail-oi0-x231.google.com with SMTP id m124so4140508oig.1 for <ietf@ietf.org>; Tue, 28 Feb 2017 03:11:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=fMSnVllrwhdu4InDGENV7I9/UZSQ8A47sDQaZAERclo=; b=u3jU2J1ex6PrS2tsXIokcNaFbYxb8eJ9shH9kgO76hGaaI5RbS5Cj70CrOXyvLvETQ mtNO52g6hKno9/g0ewQ6ky8DjAl+uvzxn5OnUBuNuRuqWJcekQpP+0MCiviI84dcgHY4 5Bf57Lzu2sbdfVlsazBZn6RDHriQdBQm+ZS7smOry3whIIzbDJf3MLjs47R08/bkOZv9 dP0cMJWdO+WFy+gAF3EFariD/VMmRcFvJbdKGWrQL4GbYLTX4WjEFi5oJhmjbheZ01I/ bpzSq3X64E6Uzq2xXVKMU4vRDGgfmDx+9NaWFwu4pld6xy5SeyXSlhSOW3jf3IcMiRr+ 4YXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=fMSnVllrwhdu4InDGENV7I9/UZSQ8A47sDQaZAERclo=; b=F2s/YIhGyrwzLeZCwMcX7dXKVsyt0ntaz9RhbSwGlJJYqFOTqHb3g6MP1wbW31edJp +usQCRhhna2OCOt408YQcobHyf1KVwNx7DkLHEePq6LsPR8uuGYDilwX+O1vNVwk1Bjn rSeOJOV8Tkg2g44tjl3HW+KfWpmK9uwXeE5+BUxdivpSiHQCn5jpeRDe9SwmYy/HRujm FBr0O2vfo3mGww8OXFej5+Qv91MFAAyVdOq386xrO8YM9zUwP4Qmo6oUOSYnfBOSVwQK CjkUrlyTvMBgut5gyRxRYQ/dTabGwaVHSzSENl/xvH9yv9qp58nOECpQ85PYL8mfsGsc zSqw==
X-Gm-Message-State: AMke39ndytTz67n5RPAboZWegWRLL2Mp0hMFiG69T7JHeDGZIyRpX+Qcm5UDrchBi/SNdp6908Npq+IimNkk1k7r
X-Received: by 10.202.108.212 with SMTP id h203mr887658oic.129.1488280309068; Tue, 28 Feb 2017 03:11:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.3.108 with HTTP; Tue, 28 Feb 2017 03:11:47 -0800 (PST)
In-Reply-To: <D237E866-CEC3-4A3C-9D5E-0D1B48F1799B@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>
From: Wei Chuang <weihaw@google.com>
Date: Tue, 28 Feb 2017 03:11:47 -0800
Message-ID: <CAAFsWK2h1phbNhwxx+q5X_PPKe7OrFBC1ScmP91Z=PLxqwEk-Q@mail.gmail.com>
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>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1142ef382a8644054995436a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_6NO1-4KJVIKsfetcuUJ5Dc92qg>
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: Tue, 28 Feb 2017 11:11:53 -0000

On Thu, Feb 16, 2017 at 10:26 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

>
> > On Feb 16, 2017, at 10:30 AM, Wei Chuang <weihaw@google.com> wrote:
> >
> >> How about if a CA with only rfc822Name constraints can't issue certs
> >> with SmtpUTF8Names at all, and of course vice versa.  If you want both
> >> kinds of names, the CA has to constrain both.
> >
> > I had asked a few folks at Google for an opinion about the name
> constraints.
> > Let me post Ryan Sleevi's (CC'ed) opinion:
> >
> > https://mailarchive.ietf.org/arch/msg/ietf/ngUOjvCHubjcyiG4uZ0w16-5-fg
> > [the above] basically says option 3 [the acceptable approach of the 3],
> > but unfortunately suffers from 'legacy' - namely, you cannot assume that
> > all rfc822Name clients will be updated to support SmtpUtf8Name, and short
> > of marking it critical (which would mean its undeployable), you can't
> > assume that an SmtpUtf8Name nameConstraint will constrain an rfc822Name.
>
> 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.
>
> --
>         Viktor.
>

Hi Viktor and everyone else on the thread,

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.

thanks,
-Wei