Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

Russ Housley <> Thu, 09 February 2017 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 141D7129C8B for <>; Thu, 9 Feb 2017 13:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wcJE_s2IMWWB for <>; Thu, 9 Feb 2017 13:33:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D2771295BB for <>; Thu, 9 Feb 2017 13:33:46 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FC6B30041D for <>; Thu, 9 Feb 2017 16:33:45 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id YUl6ejQLbVUj for <>; Thu, 9 Feb 2017 16:33:44 -0500 (EST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 0A9D530024F for <>; 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 <>
In-Reply-To: <>
Date: Thu, 09 Feb 2017 16:33:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: IETF <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Feb 2017 21:33:48 -0000


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,
   "" indicates the root mailbox on the host
   "".  To indicate all Internet mail addresses on a
   particular host, the constraint is specified as the host name.  For
   example, the constraint "" is satisfied by any mail
   address at the host "".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, "" indicates all the Internet mail
   addresses in the domain "", but not Internet mail
   addresses on the host "”.

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.


On Feb 9, 2017, at 12:57 PM, Viktor Dukhovni <> 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 "", it should be able to issue "виктор".
> -- 
> 	Viktor.