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

Wei Chuang <> Thu, 09 February 2017 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7053129C2E for <>; Thu, 9 Feb 2017 09:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qi5IkQ7BVwoc for <>; Thu, 9 Feb 2017 09:34:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2624E129C28 for <>; Thu, 9 Feb 2017 09:34:30 -0800 (PST)
Received: by with SMTP id 65so8557676otq.2 for <>; Thu, 09 Feb 2017 09:34:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=NTXhVMBAFbzRJN1BKF1/mcovsvT/xVInwWrir1jyikI=; b=OubRiY7dPT6IiaC/c5QUwTLPdF7sM+YTGuj+FsYrvCnpq0/Q0yg9gFoY1GcaozZU+w Kys8WxDttXM4dAFsC+uT+aWt1Tz+aFxa6/jwGxIJaYHCPGGP4KxgD5rij74UoDgvqEl+ DSMzbvRaAE81O3uy96i8VZZIyqTBRRv0h+LyfmzR2HY4uLOqTkNqRYvU+yfeqD1l7Fi5 w7rhXBTnNLeBbfEiAykqdCYsOV+TI0yKYh2QyKYeYcyv5iiT3rK5imFk48bw8Vx6e8Y0 LqAt/CyGiPM4Px1rNlTdUusF7k5wyVSvX9CKHp1k3rxIeDkSaXkCTJPJQ7XoFnNyzovX 4Dwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=NTXhVMBAFbzRJN1BKF1/mcovsvT/xVInwWrir1jyikI=; b=fWxzHUENaV7jkwjjv4SOXrDRErAdcqyJibHZVxHXwMNDU2737xagIOVgOMm6zeJphF OaoC5AX542srAWZAvIJvN1kjQglPTG7tNg6Y2OcMYGzR3KDaye7z6zvyoJFO6o9b0U0D 1RtZBxJ9cy5EQ9HES4nORq57sXyyTDwiTrrymdyS4HJYLmHVGsnopBx1NTLkjO0eujGq ybL3kd+Dzf965xXh8lQAwYLIdz39Krn5MF+CUhp9AMcMumDIZvaMLr9kwakw1xwCUuqi eizqweVW6M2sSUtr/8wff1FP6D9khdtJ4jddARewnIY5lVjRcDSZccwH6di3d7LAwCka YHYQ==
X-Gm-Message-State: AMke39ljVDizJMz2aLNoV9aRC05y2RzP+UBexWSi/A8OlXb0VqvoE/ruVd/hogaSBeiKZUs4kAB/DyBS2bI+oehY
X-Received: by with SMTP id 43mr2112744otn.143.1486661669174; Thu, 09 Feb 2017 09:34:29 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Feb 2017 09:34:27 -0800 (PST)
In-Reply-To: <>
References: <> <D45CE6A5317D4B373CD90742@PSB> <> <> <> <> <> <> <> <> <>
From: Wei Chuang <>
Date: Thu, 09 Feb 2017 09:34:27 -0800
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
To: "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="94eb2c09b6c4b57fd705481c647b"
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 17:34:33 -0000

On Wed, Feb 8, 2017 at 7:19 AM, Viktor Dukhovni <>

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

You are stretching the language used above.  They are "applied separately".

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.  An alternate design of SmtpUtf8Name would
have to check constraints for rfc822Name and legacy email address in
Distinguished Names in addition to SmtpUtf8Name and vice versa for those
forms.  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.  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.

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

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.  Similarly SmptUtf8Name.  An issuer with both
SmtpUtf8Name and rfc822Name in its path can issue both subjectAltName name
form email addresses.