Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Russ Housley <housley@vigilsec.com> Thu, 09 February 2017 21:33 UTC
Return-Path: <housley@vigilsec.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 141D7129C8B for <ietf@ietfa.amsl.com>; Thu, 9 Feb 2017 13:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] 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 wcJE_s2IMWWB for <ietf@ietfa.amsl.com>; Thu, 9 Feb 2017 13:33:46 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2771295BB for <ietf@ietf.org>; Thu, 9 Feb 2017 13:33:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7FC6B30041D for <ietf@ietf.org>; Thu, 9 Feb 2017 16:33:45 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YUl6ejQLbVUj for <ietf@ietf.org>; Thu, 9 Feb 2017 16:33:44 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A9D530024F for <ietf@ietf.org>; Thu, 9 Feb 2017 16:33:43 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20170209175737.GV28349@mournblade.imrryr.org>
Date: Thu, 09 Feb 2017 16:33:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <EB04BFE1-6A74-4697-9D4F-67A356B107DE@vigilsec.com>
References: <CAAFsWK1kQUUZrq9Cs47+jYbEJXW+hQN8gzKb+2qjXYdfYhRFzw@mail.gmail.com> <E56ED618-6670-437D-87A9-BD59FC10DBC1@dukhovni.org> <CAAFsWK2QjdkovXTgJR-6Hpj=u=MD5Mjk0srYVpoqNnK_d7_Y9Q@mail.gmail.com> <78EFB6CA-BB21-4B6F-964C-9A0BBAA68023@dukhovni.org> <CAAFsWK0p5Zjj73Av3Z=TpjRmpJwFekfj9N+4zdcE_fFDcw65dA@mail.gmail.com> <20170206182023.GN28349@mournblade.imrryr.org> <20170208051311.GP28349@mournblade.imrryr.org> <CAAFsWK3xY35+yD5drtmUJUNMaAA8pRUwM3h22rvm+k7g5W8uKg@mail.gmail.com> <20170208151943.GQ28349@mournblade.imrryr.org> <CAAFsWK20Sf51W+cRUBET8-U5XXO+Z1ixOt3dgu70ad99FPsrWg@mail.gmail.com> <20170209175737.GV28349@mournblade.imrryr.org>
To: IETF <ietf@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lkJw0J0SRUKI4YeScccxcAF_rPw>
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: Thu, 09 Feb 2017 21:33:48 -0000
Viktor: RFC 5280 says: A name constraint for Internet mail addresses MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@example.com" indicates the root mailbox on the host "example.com". To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the domain "example.com", but not Internet mail addresses on the host "example.com”. I think you are talking about constraints on addresses at a particular host and constraints on mailboxes in a domain, but not constraints on a particular mailbox. Please correct me is I got that wrong. I think you are suggesting that any A-label in the rfc822Name be converted to a U-label, and the result is used to constrain the SmtpUtf8Name. If people like your suggestion, then a constraint for a particular mailbox will still require a SmtpUtf8Name, so I think the mechanism described in the draft is needed. It would just be used in combination with the above. Russ On Feb 9, 2017, at 12:57 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote: > [ Sorry about the duplicate post, Somehow the original body got > "Content-Disposition: attachment", reposting as "inline". ] > > On Thu, Feb 09, 2017 at 09:34:27AM -0800, Wei Chuang wrote: > >>>> The draft says the rfc822Name and SmtpUtf8Name >>>> name constraints are applied separately, and don't affect other results >>>> (see section 6). >>> >>> Yes, that's what I'm objecting to. This is a design error in the >>> draft. The namespaces are *not* separate, and orthogonal constraints >>> are not desirable. >> >> You are stretching the language used above. They are "applied separately". > > Separate application is not sufficient when the issuer's certificate > contains only rfc822Name constraints. > >> I think we're open to changing how name constraints are applied. But its >> worth spelling out the design concern clearly before going down that path. >> The concern is that as we add a new representation for international email >> address that we are seeing that combinatorial increase in comparisons >> needed for name constraints. > > My proposal creates no combinatorial increase of any kind. When > the issuer CA has *only* rfc822Name constraints, any SmtpUtf8Name > subjectAltNames in the certificate, instead of getting a free ride, > would have to satisfy the rfc822Name constraints. Each rfc822Name > constraint becomes (under the identity function) a valid SmtpUtf8 > constraint. > >> This design chooses to simplify that by keeping rfc822Name name >> constraint behavior and separately defining a new SmtpUtf8Name name >> constraint behavior that works only on SmtpUtf8Name names. > > Yes, buts this evades rfc822Name constraints created SmtpUtf8-agnostic > parent issuers. The namespaces are not disjoint. > >> That simplifies >> the work of the path verifier and eliminates potential domain (A/U label) >> conversions between the alternate forms. Work is now shifted to the issuer >> which must explicitly define SmtpUtf8Name name constraint. > > The simplest thing for the verifier is to do no checks at all. > Presumably we make things as simple as possible, but no simpler. > The security requirements should be to correctly process existing > name constraints. And I don't believe that *any* conversions are > required to do this. > > Specifically, rfc822Name constraints that include a non-empty list > of permitted subtrees, in the absence of explicit SmtpUtf8Name > constraints would imply that the CA cannot issue *any* email altnames > for a non-ASCII domain. If the domain is all-ASCII, no conversions > are required. If the rfc822Name constraints have only excluded > subtrees, then no non-ASCII domain is excluded. > >>> The issuer may be SmtpUtf8 aware, but the parent CA that sets the >>> issuer's constraints (possibly some time ago in the past) may not. >>> The issuer should not be able to evade name constraints. >> >> Assuming we keep the current name constraint design, we can add a >> requirement that name constraints on email addresses has to be consistently >> applied on the certificate issuance path. In other words, an issuer with >> only rfc822Name name constraints in its path can only issue rfc822Name >> subAltName email addresses. > > No that's too limiting. If the issuer is permitted to issue altnames > for "example.org", it should be able to issue "виктор@example.org". > > -- > Viktor. >
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Alexey Melnikov
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Patrik Fältström
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Diversity, writing systems, identifiers, and prot… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John C Klensin
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… John R. Levine
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… 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: Last Call: <draft-ietf-lamps-eai-addresses-05… Wei Chuang
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Russ Housley
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… Viktor Dukhovni
- Re: Last Call: <draft-ietf-lamps-eai-addresses-05… 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… tom p.
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang
- Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addr… Wei Chuang