Re: [Spasm] 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> Thu, 09 March 2017 03:19 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E77129717; Wed, 8 Mar 2017 19:19:24 -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 HbCfQ_P6vvTc; Wed, 8 Mar 2017 19:19:23 -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 DC96F1296FD; Wed, 8 Mar 2017 19:19:22 -0800 (PST)
Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (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 8C5F97A32D8; Thu, 9 Mar 2017 03:19:21 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAAFsWK3yJ9r+6abTXZQsNsey+VcRpdtVv=Hku_54_LZ9y1T2xQ@mail.gmail.com>
Date: Wed, 08 Mar 2017 22:19:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8A5967B-9C19-4167-8A20-B82DFD46A924@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> <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <CAAFsWK2RMGp0jqesx3cTbN=S7p0WuhH+0AbeJuuiZPF6WCbQOQ@mail.gmail.com> <BCEFAA3C-B711-4269-81C8-4DA0E1AA7AD0@dukhovni.org> <CAAFsWK3yJ9r+6abTXZQsNsey+VcRpdtVv=Hku_54_LZ9y1T2xQ@mail.gmail.com>
To: "spasm@ietf.org" <spasm@ietf.org>, IETF general list <ietf@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/3veIc2WhrXtcspHI3KkPnrZR6MY>
Subject: Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "spasm@ietf.org" <spasm@ietf.org>, IETF general list <ietf@ietf.org>
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Mar 2017 03:19:25 -0000
> On Mar 8, 2017, at 8:17 PM, Wei Chuang <weihaw@google.com> wrote: > > Okay. I think the direction then is to have SmtpUTF8Name respect rfc822Name name constraints and vice versa. Well, no, the simplest proposal on the table is for SmtpUTF8Name to be *prohibited* when rfc822Name constraints are present and SmtpUTF8Name constraints are not. When both present, they can operate independently. The verifier logic is then: 1. If neither rfc822Name constraints nor SmtpUTF8Name constraints are present in any CA certificate in the chain, any mixture of rfc822Name and SmtpUTF8Name SAN elements is valid. 2. If some certificate in the chain contains *only* rfc822Name constraints, then these apply to rfc822Name SAN elements, but all SmtpUTF8Names are prohibited. 3. When both types of constraints are present in all CA certificates that have either type, then constraints for each SAN type are exclusively based on just the corresponding constraint type. 4. If some certificate in the chain contains only SmtpUTF8Name constraints then those are unavoidably at risk of bypass via rfc822Name SAN elements when processed by legacy verifiers. Therefore, this should be avoided, and the CA needs to publish rfc822Name constraints that prevent bypass. Such constraints *need not* be equivalent (not always possible) to the desired SmtpUTF8Name constraints. Rather, it suffices to not permit rfc822Name elements that would be prohibited if they were simply cut/pasted (with no A-label to U-label conversions) as SmtpUTF8Name elements. It is not necessary for these to permit everything that SmtpUTF8Name permits. Thus for example, if SmtpUtf8Name only permits addresses in the non NR-LDH domain "духовный.org" (or a specific set of addresses in such a domain), then the corresponding rfc822Name constraint could just permit "." (or the reserved "invalid" TLD if that's preferable) which is not a usable email domain. This ensures that only the permitted SmtpUTF8Name SANs are used and no rfc822Name SANs are used. If, instead the Smtp8Name constraints are excluded non-ASCII address forms, then since these have no literal rfc822Name equivalents, the rfc822Name constraints can be omitted with the same effect. Only when the intention is to permit NR-LDH domains with either ASCII or UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and SmtpUTF8Name constraints need to be fully equivalent. This is of course trivial to do. Just cut/paste the same string into both types of constraint. -- Viktor.
- [Spasm] Last Call: <draft-ietf-lamps-eai-addresse… The IESG
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… John C Klensin
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Alexey Melnikov
- [Spasm] draft-ietf-lamps-eai-addresses-05, JCK Co… Russ Housley
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Patrik Fältström
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… John C Klensin
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Patrik Fältström
- Re: [Spasm] draft-ietf-lamps-eai-addresses-05, JC… Wei Chuang
- [Spasm] Fwd: Last Call: <draft-ietf-lamps-eai-add… Wei Chuang
- [Spasm] Fwd: Last Call: <draft-ietf-lamps-eai-add… Wei Chuang
- [Spasm] Fwd: Last Call: <draft-ietf-lamps-eai-add… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Stephen Farrell
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Jim Schaad
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… John C Klensin
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Stephen Farrell
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Russ Housley
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Russ Housley
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Stephen Farrell
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Viktor Dukhovni
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang