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

Wei Chuang <> Wed, 08 February 2017 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDA92129B92 for <>; Wed, 8 Feb 2017 06:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 FYrxwiSf3XAK for <>; Wed, 8 Feb 2017 06:46:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABCD7129B8F for <>; Wed, 8 Feb 2017 06:46:43 -0800 (PST)
Received: by with SMTP id j15so83035188oih.2 for <>; Wed, 08 Feb 2017 06:46:43 -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=tAv4ysi+cxmfQCeEnE/2Ua8kk103fJl3rfonVU6toFk=; b=aUhRpELTjZY23zzXRV5zKpxwaAQhoFtFlYrJ/rWOUivtiJzPUF2vUqG0CChMdYmDJ4 kzPq3xUw9pWxu7BI0AvdWY1diAQVvDharAA187mLln19wBfySZxeMTpNHWwgiYt86kxv rhtmz5jnIipIJiPxLgkvbmxvdinrxiWLtbbCg59qsL8aDw8Ut4eMydtbus5VenOz9hZe 0Fhk+wYw0hTm5JKiGlOJK9tWaa7r8uOf6eTFqf6EiKaCJo36Hlm8vi5eWl13FBnlQsLK oqkt/sB5RE/Ko83hBfCxjxKX2bYkqS42Ehm0zT/7FM3kRDtLu6tJJ3lbNsb1bu/wMsUs UqNQ==
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=tAv4ysi+cxmfQCeEnE/2Ua8kk103fJl3rfonVU6toFk=; b=ELreQhXm8DqqdsI8Ph5n/W2vJTbMHntKKy476AMEg5ySahpR+9gZ+jBJjnV696lcoq YDaPFBE1mdizJgnMuFvbGeQ4RQSErQo0LypSoEQxvtB08bZX+vphhQFGBFWpbQzh6B5w gmgPTYBab4ns8mxUetORygH6xDSXa0MedFHe9dCClLM76lCHjdEVwub5aWJGrK7oXL4G qGdKqTouaPgJgyQkBye4YiMfac4OIWm5HJR7FgJttvSL/2f3ylWEuew76AGzh2tlblsZ UwjTEyl3aS/InOsloFTOlE98U2gLYnbsdHDNTu8qFmvuOmoVCx7Gr5oeSUI3IeMKMdT6 Yelw==
X-Gm-Message-State: AMke39noS/PHswmpTKe5718O8BMDeIviDtz/RRh6eyEjqiU8icaKmSq4ZQvG7LYrvmidzTlI3NVeK8fwfdSDTX+O
X-Received: by with SMTP id a68mr10207432oic.106.1486565202665; Wed, 08 Feb 2017 06:46:42 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 8 Feb 2017 06:46:41 -0800 (PST)
In-Reply-To: <>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan> <> <D45CE6A5317D4B373CD90742@PSB> <> <> <> <> <> <> <>
From: Wei Chuang <>
Date: Wed, 08 Feb 2017 06:46:41 -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="001a1140b784db93c4054805ee6d"
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: Wed, 08 Feb 2017 14:46:46 -0000

On Tue, Feb 7, 2017 at 9:13 PM, Viktor Dukhovni <>

> 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:
>              rfc822Name:
> with "" 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 "".
> 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.  The draft says the rfc822Name and SmtpUtf8Name
name constraints are applied separately, and don't affect other results
(see section 6).  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).

The assumption being made in the draft is that a SmtpUtf8Name aware issuer
will also be aware of the name constraints on that type.

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

As mentioned the draft is trying to avoid this comparison.

>     In
>     particular, an issuer CA with only rfc822Name permitted subtrees
>     cannot issue EE certificates with SmtpUtf8Name altNames bearing
>     (non-ASCII) UTF-8 domains.

This could be added.

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

This is mentioned in section 7 and says: "This document RECOMMENDS using
SmtpUtf8Name when local-part contains non-ASCII characters, and otherwise

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