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, 8 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.