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> Thu, 09 February 2017 17:57 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 39ED5129C2E for <ietf@ietfa.amsl.com>; Thu, 9 Feb 2017 09:57:40 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 f6WaaqxefkwK for <ietf@ietfa.amsl.com>; Thu, 9 Feb 2017 09:57:38 -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 B827012943B for <ietf@ietf.org>; Thu, 9 Feb 2017 09:57:38 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2180F284E4C; Thu, 9 Feb 2017 17:57:38 +0000 (UTC)
Date: Thu, 9 Feb 2017 17:57:38 +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: <20170209175737.GV28349@mournblade.imrryr.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAFsWK20Sf51W+cRUBET8-U5XXO+Z1ixOt3dgu70ad99FPsrWg@mail.gmail.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/yc-648WjF629sazn2RyCfBbPgaA>
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: Thu, 09 Feb 2017 17:57:40 -0000

[ 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".org".

-- 
	Viktor.