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> Tue, 14 March 2017 14:49 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 6B1E212709A for <spasm@ietfa.amsl.com>; Tue, 14 Mar 2017 07:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01] 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 BGlOXl4-C6Qa for <spasm@ietfa.amsl.com>; Tue, 14 Mar 2017 07:49:03 -0700 (PDT)
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 7F8BD12025F for <spasm@ietf.org>; Tue, 14 Mar 2017 07:49:03 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 334E57A3309; Tue, 14 Mar 2017 14:49:02 +0000 (UTC)
Date: Tue, 14 Mar 2017 14:49:02 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: SPASM <spasm@ietf.org>
Message-ID: <20170314144901.GK4095@mournblade.imrryr.org>
References: <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> <B8A5967B-9C19-4167-8A20-B82DFD46A924@dukhovni.org> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> <CAAFsWK1Q=d-9E++J0Z7UyEn3mshKkbYZ9yuGX974XvU8rO0VQw@mail.gmail.com> <CAAFsWK3n=dpix1dF6_tm+ZBSqkC=+DW301HaLSg__p-0Tt0rxg@mail.gmail.com> <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/AZdq0IZtGkRtK1y6hBUlBRzHIMQ>
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
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: Tue, 14 Mar 2017 14:49:05 -0000
On Mon, Mar 13, 2017 at 10:44:32AM -0400, Russ Housley wrote: > > On Mar 12, 2017, at 5:40 PM, Wei Chuang <weihaw@google.com> wrote: > > > > The latest draft 08 is up: > > > > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 > > > > The diff is: > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt > > > > This draft attempts to capture Viktor's name constraint verifier logic, > > and illustrate the examples in the diagrams. > > These changes were made in response to an IETF Last Call comment. Please > review them. The vast bulk of the changes are in Section 6. Please speak > promptly if you think this is the word technical solution. I think that while the new section 6 is technically on track, that it still needs a bit more effort to improve clarity. The design would be more clear if the rationale were stated clearly and concisely up-front. Therefore, after the second paragraph, I would like to see something along the lines of (please improve as needed): Some legacy actors (either CAs or relying parties) support only rfc822Name SANs and rfc822Name constraints. While limits on the new SmtpUTF8Name SANs will be expressed via new SmtpUTF8Name constraints defined in this document, these will not be generated or understood by the above legacy actors. When a legacy CA has only rfc822Name constraints, with the intent of limiting the scope of email addresses allowed in end-entity certificates it can issue, there would be a potential constraint bypass risk, if as a result all SmtpUTF8Name SANs were allowed to be used for lack of corresponding constraints. When a non-legacy CA has only SMTPUTF8Name constraints, with the intent of limiting the scope of allowed addresses to particular UTF8 forms, there is again a risk of bypass when a legacy relying party remains unaware of this intent. To avoid the above constraint bypass issues, we obligate SmtpUTF8Name-aware relying parties to disallow SmtpUTF8Name SANS in end-entity certificates whose chain includes (presumed) legacy CAs that have only rfc822Name constraints. Similarly, we obligate SmtpUTF8-aware CAs issuing constrained CA certificates, to also include sufficient rfc822Name constraints so that the set of email addresses acceptable in end-entity certificates is not unintentionally larger for legacy SmtpUTF8-unaware relying parties. I also think that the text below points 1--4 could be more clear. Instead of a single explosion of text that tries to explain all the diagrams, it is perhaps better to interleave the diagrams with corresponding explanatory text. Also there could be a better explanation of how to craft rfc822Name constraints to avoid constraint bypass against legacy relying parties. That is, the paragraph: If the issuer wishes to represent the name constraint asymmetrically, with either rfc822Name or SmtpUTF8Name to respectively represent some A-label or U-label in the domain or host, the alternate name constraint form must still be present. If nothing needs be represented by the alternate form, then empty name constraint can described by the "invalid" TLD that helps initialize the name constraint path validation set. Or alternatively it may be omitted if some other name constraint pair, provides a name constraint of that form. In particular this initialization may be needed when SmtpUTF8Name is used to represent an email address name constraint with an UTF-8 local-part and rfc822Name cannot represent such a email address constraint. may be too concise. With luck the suggested rationale additions may help readers figure out an appropriate strategy that meets the same goals, but this text could probably be improved. -- 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