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 05:13 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 582A212996D for <ietf@ietfa.amsl.com>; Tue, 7 Feb 2017 21:13:14 -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 YDzz3zMjbTqH for <ietf@ietfa.amsl.com>; Tue, 7 Feb 2017 21:13:12 -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 AD4F5129969 for <ietf@ietf.org>; Tue, 7 Feb 2017 21:13:12 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C4D03284E4C; Wed, 8 Feb 2017 05:13:11 +0000 (UTC)
Date: Wed, 08 Feb 2017 05:13:11 +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: <20170208051311.GP28349@mournblade.imrryr.org>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170206182023.GN28349@mournblade.imrryr.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/5FRh3awGQpKP_3PO75ymapvqhxQ>
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 05:13:14 -0000
On Mon, Feb 06, 2017 at 06:20:23PM +0000, Viktor Dukhovni wrote: > Understood. As I mentioned, I think that avoiding all conversions, > and checking for whatever verbatim address is found in message > headers is less likely to lead to problems at the cost of some more > names in the certificate (all the names that the author uses in > practice, no combinatorial explosion). > > We'll see how this plays out in practice. It will take some time, > as adoption of SMTPUTF8 is still quite low. There's already a complication, in a pull request for OpenSSL, Dmitry Belyavsky proposes an implementation of SmtpUtf8 in OpenSSL. In this proposed implementation OpenSSL acquires a new dependency on libicu (a widely used IDNA conversion library). Such a new dependency is a significant barrier to adoption of the pull request. [ Donning OpenSSL team-menber hat ] I am asking the author to remove that dependency, leaving construction of the normal form of the reference identifier to the application rather than the X.509 stack. If he is unsuccessful, and there is a fundamental requirement for X.509 certificate validation code to become IDNA aware, that'd be a major barrier to widespread support for this specification. Review of the pull-request brings us to another (perhaps the main) issue. The security considerations section of the draft fails to note a significant name-constraint issue. Suppose an existing CA is constrained to email addresses in a particular DNS subtree: CA Cert Name Constraint Extension Permitted rfc822Name: example.com rfc822Name: .example.com with "example.com" an ordinary LDH domain. Prior to the proposed specification, this precludes, e.g., issuance of valid EE certificates with rfc822 email addresses with a domain part of "example.net". 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 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. In particular, an issuer CA with only rfc822Name permitted subtrees cannot issue EE certificates with SmtpUtf8Name altNames bearing (non-ASCII) UTF-8 domains. 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. It should also be possible to evaluate name constraints and match an EE certificate against an email address reference identifier without imposing a dependency on libraries that convert domain names between A-label and U-label forms. -- 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