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> Wed, 08 February 2017 15:19 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 54A0F129B83 for <ietf@ietfa.amsl.com>; Wed, 8 Feb 2017 07:19:47 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 HGHMyyr_ih4d for <ietf@ietfa.amsl.com>; Wed, 8 Feb 2017 07:19:45 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983D012997E for <ietf@ietf.org>; Wed, 8 Feb 2017 07:19:45 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 71291284E4C; Wed, 8 Feb 2017 15:19:43 +0000 (UTC)
Date: Wed, 08 Feb 2017 15:19:43 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <20170208151943.GQ28349@mournblade.imrryr.org>
References: <20170201210155.GI28349@mournblade.imrryr.org> <D45CE6A5317D4B373CD90742@PSB> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAAFsWK3xY35+yD5drtmUJUNMaAA8pRUwM3h22rvm+k7g5W8uKg@mail.gmail.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6HkSQALQp8crn_EMZcqX3l5-mwk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: 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: Wed, 08 Feb 2017 15:19:47 -0000
On Wed, Feb 08, 2017 at 06:46:41AM -0800, Wei Chuang wrote: > > This draft breaks the existing name constraint restrictions, because > > the same CA can now issue EE certificates with SmtpUtf8 addresses > > outside the permitted rfc822Name tree. Possibly including all-ASCII > > addresses that just happen to be found in an SmtpUtf8 subjectAltName. > > > > The problem is that the namespaces of the existing "rfc822Name" > > constraints and the new "SmtpUtf8Name" constraints substantially > > overlap leading to unexpected behaviour. > > I wouldn't say unexpected. It may well be expected as a consequence of decisions in the draft, but it is objectively unwanted new behaviour for a name constrained CA, to suddenly be able to issue certificates for previously excluded addresses. Software that allows such violations of previously enforced constraints would IMHO be CVE-worthy. > 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. > It is followed by examples illustrating the behavior of > the overlap case. The reason for separating the rfc822Name and > SmtpUtf8Name constraints was to minimize the domain A-label to U-label > conversions (and vice versa) (which I believe you're asking for too). This is not a valid reason to violate the meaning of existing name constraints. It is not even clear why any conversions would be required. All that one needs to do is satisfy rfc822Name constraints when no SmtpUtf8Name constraints are present in the same certificate. When the domain is a non-ASCII domain, no permitted tree or excluded sub-tree matches without conversion. Thus the address is acceptable only if the rfc822Name constraints contain only excluded sub-trees. The only corner case is when an all-ASCII address (both localpart and domainpart) for some reason appears in SmtpUtf8Name. Such names could match a full address in rfc822Name constraints (not just a domainpart sub-tree). This is why it is important to be clear about whether all-ASCII names are valid in that context. > The assumption being made in the draft is that a SmtpUtf8Name > aware issuer will also be aware of the name constraints on that type. 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. > > I therefore propose that: > > > > When validating an EE certificate that contains SmtpUtf8Name > > subjectAltName values, all such subjectAltName values must > > match any rfc822Name name constraints in each issuer certificate > > that does not also include SmtpUtf8Name constraints. > > As mentioned the draft is trying to avoid this comparison. This comparison MUST happen to avoid evasion of name constraints. I see no need for "conversions" to implement these comparisons. An issuer with only rfc822Name constraints present should only be able to issue email altNames with ASCII domains that satisfy the rfc822Name constraints. > > In > > particular, an issuer CA with only rfc822Name permitted subtrees > > cannot issue EE certificates with SmtpUtf8Name altNames bearing > > (non-ASCII) UTF-8 domains. > > This could be added. This needs to be added, and also language about how to match SmtpUtf8Name elements against rfc822Name constraints in the case that the domainpart is all-ASCII. > > I don't recall seeing language in the draft that expains whether > > addresses that are valid rfc822Name values can be instead presented > > in the certificate as SmtpUtf8Name values, or whether any SmtpUtf8Name > > value MUST contain either a non-ASCII localpart or a valid non-ASCII > > UTF-8 domain. > > This is mentioned in section 7 and says: "This document RECOMMENDS using > SmtpUtf8Name when local-part contains non-ASCII characters, and otherwise > rfc822Name." This effectively makes all-ASCII names valid in SmtpUtf8Name, which increases scope for implementation errors. I would prefer that the draft prohibit use of SmtpUtf8Name when rfc822Name is an option. -- 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