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

Wei Chuang <> Thu, 16 February 2017 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FE0A12964B for <>; Thu, 16 Feb 2017 07:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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] 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 VhdfqHNevRQR for <>; Thu, 16 Feb 2017 07:30:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 432C412943F for <>; Thu, 16 Feb 2017 07:30:34 -0800 (PST)
Received: by with SMTP id 45so13190707otd.2 for <>; Thu, 16 Feb 2017 07:30:34 -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 :cc; bh=HzmpDguhp33xdLCQo3q5M5BEW7gTVPB5oH05fj5eiaw=; b=tu5j2eCrLra8ZhHF9OPGpZiN/8VdbZZex0nr1r1BTH10zScGz2UENhk95FsODaIb9q IFWY2C5bIE6eOwmVLq4s37fwFJvl5qeAxDFViuB4BkFWwZXv2ipVf0EPJm45z8depXQH FAGFRDLXIe3PkCUbRhCIp1tZTQw/9/hAA10ANU+HMFT/V28iv95TNhTOezoHtmp/Bsx+ b1Q8YqO87EMoL1rFRaLqu2ckpNJKw4SrE+AIyA+Oa5Lx8EvYTpJXFVNeUN0tO7BcYmJS g9nvco4shMRmOek/4TtT8go8KJ0YE324ImEAwk4ndjmarRJEAfAyYYZDA1menOH02kOw pULg==
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:cc; bh=HzmpDguhp33xdLCQo3q5M5BEW7gTVPB5oH05fj5eiaw=; b=mX/oVZxMgr2Wuukc0Wav2DHISGFi8KRr+eURjN83v/HOt7Qj8anOQYLFDPnYhsX/Ow 45nmYoVPNtEvhkxoQ7EAkYbMio9WcvDsBfDOFQPw4p2pEloYKnH+djkcN3oxKVb5GpyN jGifeWIl2ERhi/SotesVcoqJxGUtbU1oeUt1ZdXj7qtz3P6OMy71DMJLZ4p5QojtYmXP ayYyqoP8ntX2RwOYpegWyPFkt1usDtLObiCF+KGt0kQRFpPx1P1qOnV7FoccafD+Hpjy ET0NRZ4WKNtJTogKotPOT4zoaqnrWJopyPvrLDgsq3M4mu4d445ThVnru8roptgCwxq4 5nNw==
X-Gm-Message-State: AMke39kvjykOiw/31drdlzVLPIuJKVgdSyrcicG/D7TNYRKCTdPqY6Rv+2X+TJBd47ut+LHTZ0TC3BwTVBUOLsh+
X-Received: by with SMTP id x47mr1312567otx.233.1487259033448; Thu, 16 Feb 2017 07:30:33 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Feb 2017 07:30:32 -0800 (PST)
In-Reply-To: <alpine.OSX.2.20.1702111606270.2386@ary.qy>
References: <alpine.OSX.2.20.1702111606270.2386@ary.qy>
From: Wei Chuang <>
Date: Thu, 16 Feb 2017 07:30:32 -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: "John R. Levine" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a113d13bc66c4240548a77ad5"
Archived-At: <>
Cc: IETF general list <>, Ryan Sleevi <>
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, 16 Feb 2017 15:30:36 -0000

On Sat, Feb 11, 2017 at 1:06 PM, John R. Levine <> wrote:

> Once again, a CA with *ONLY* rfc822Name constraints should not be
>> able to able issue EE certificates with SmtpUtf8Name altNames that
>> conflict with its rfc822Name constraints.
> How about if a CA with only rfc822Name constraints can't issue certs
> with SmtpUTF8Names at all, and of course vice versa.  If you want both
> kinds of names, the CA has to constrain both.
> R's,
> John
I had asked a few folks at Google for an opinion about the name
constraints.  Let me post Ryan Sleevi's (CC'ed) opinion: [the
above] basically says option 3 [the acceptable approach of the 3], but
unfortunately suffers from 'legacy' - namely, you cannot assume that all
rfc822Name clients will be updated to support SmtpUtf8Name, and short of
marking it critical (which would mean its undeployable), you can't assume
that an SmtpUtf8Name nameConstraint will constrain an rfc822Name.


There are a few approaches you could try:
- "Monkey Patch" RFC5280, 6.1.4 (g) (1) and (2) [and 6.1.2 (b) and (c)]
such that an rfc822Name present in the permittedSubtrees/excludedSubtrees
(or initial-permitted-subtrees / initial-excluded-subtrees, for 6.1.2) but
an Smtp8Utf8Name is not, or if an Smtp8UtfName is present but an rfc822Name
is not, then set permitted to the empty set for that name type / set
excluded to the wildcard set. However, https://tools.ietf.
org/html/draft-ietf-lamps-eai-addresses-06#section-6 leaves me completely
confused as to whether you support the empty set / wildcard set
- Require post-processing validation, namely
  - For each certificate in the validated certificate chain, clients that
recognize SmtpUtf8Name MUST NOT accept any certificate which contains an
nameConstraint that asserts a constraint for an rfc822Name in either the
permittedSubtrees or excludedSubtrees if it does not also assert a
nameConstraint for an SmtpUtf8Name in the same section. Similarly, clients
that recognize SmtpUtf8Name MUST NOT accept any certificate which contains
a nameConstraint for an SmtpUtf8Name ... if it does not also assert a
nameConstraint for an rfc822Name in the same section.


We can update the draft to include the validation steps to preclude the
unexpected legacy path.