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

Wei Chuang <> Mon, 06 February 2017 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66B1F1295A4 for <>; Mon, 6 Feb 2017 10:03:32 -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 ZKsZ--fBTa3f for <>; Mon, 6 Feb 2017 10:03:30 -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 438F31295A5 for <>; Mon, 6 Feb 2017 10:03:30 -0800 (PST)
Received: by with SMTP id 65so67926297otq.2 for <>; Mon, 06 Feb 2017 10:03: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=X6wcIvyIOkGdtFHFd5zrdOQRhMgwyNLy2jgJ1A8beRo=; b=dRONQlOgFo7DqmeaRPaxlF62+WgjT15oqmnKKA9hp6XnJa1VJ9sflc9nXz4Q5TcTXj +mxdqG5eDRNqcxaDEUlq6hFgf5oFIrLpZB82JOT5CDVwrdFZy/4bX549whnfLdkWRnng xbxSETTBAk9he7Q0JNb5VUSlvfulnam+bbhnnEQ7QWlcQnfyl1CJlQ/oHNwFZXJo1eSy xj1VqJ8z1qmUid29es5Et+GMBjxWeLQBYWmg17d9U5zVy2L57EhosbQf0aKTlE1DFCoq kYJlAuumoFMZGkS1THq3cUBfE6jm5i5vPfEMe5p7pY+u+wRVpJoILcVL97SIH/t0Sm2T QrHA==
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=X6wcIvyIOkGdtFHFd5zrdOQRhMgwyNLy2jgJ1A8beRo=; b=cw7h5W2jZpUWAbqHduiuIh6VQ92zncRS1u+UAQeYOVVFqV9HGOsptyRT4257z6nrYi UvhSpE/Vn3EuN1Yv0Z6qeegGIcVJA1kWYI7cJ6w6u3tzpk3A86sqvsRJ4qvUtRZb5lby tfjtrDsIIxNppcp/piItcvp1u+TN9ZnmbLtotlLqdzP/uxswjxBwRzWXXRTg2GAvPos6 NRADS8VibEW3UH9V7dddRh4BlnSqmFAB6uBqo5hyqwsNFMKAooXilKEjR7KxOX8junvk Vf0+ovafJAulAtRVFjZDVqNE4+pzoD3zZNGDHr/u8kfKws1lC2Hk99uR350HlJ8z0DDK cpcA==
X-Gm-Message-State: AMke39kTKC/aXPgt8s7esD3z2hnFyYm0bhMFRlgreTADa22de2V5EMtJebWCJEx19s3Hf1ZStdfBpl6BUOwS1uLV
X-Received: by with SMTP id o22mr6355052otb.33.1486404208947; Mon, 06 Feb 2017 10:03:28 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Feb 2017 10:03:27 -0800 (PST)
In-Reply-To: <>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan> <> <D45CE6A5317D4B373CD90742@PSB> <> <> <> <>
From: Wei Chuang <>
Date: Mon, 06 Feb 2017 10:03: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: IETF general list <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a1141d730e47c1b0547e07239"
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: Mon, 06 Feb 2017 18:03:32 -0000

On Fri, Feb 3, 2017 at 11:51 AM, Viktor Dukhovni <>

> > On Feb 3, 2017, at 2:38 PM, Wei Chuang <> wrote:
> >
> > Can you clarify what this means for addresses such as:
> >
> >         U: ietf-dane@духовный.org
> >
> > Not recommended but supported by SmtpUtf8Name.
> >
> >
> >         A:
> >
> > Use rfc822Name.  This is recommended.
> So, to be clear, for the same domain, some addresses will be
> represented as rfc822Name SAN elements (with the domain in
> A-label form), and other addresses (those with non-ASCII
> localparts) will be represented as SmtpUtf8Name SAN elements
> (with the domain in U-label form).

Yes that right.

> A verifier checking for an address with a non-ASCII localpart
> will compare against SmtpUtf8Name elements with U-label domain
> encodings, while a verifier checking for an address with an all
> ASCII localpart will check against rfc822Name elements using an
> A-label domain encoding (of the same domain).
> Is that right?  Thus the verifier would sometimes need to convert
> from U-labels to A-labels (when the localpart is all ASCII), and

at other times from A-labels to U-labels (when the localpart is not
> all ASCII)...

Yes that right.

Now that said what we've done is an extension of current practice keeping
them in place.  Conversions have been what's being done with rfc822Name
comparison for awhile, and that hasn't been changed by this document.  What
we've done is taken a new unhandled circumstance (UTF8 local part) and
specified its behavior.  With the SmtpUtf8Form we kept its scope and form
limited to reduce implementation overhead and limit the likelihood of
bugs.  As noted before we got advice to minimize conversions so we opted
for consistency and for the form where we think email will move towards.
In time those conversions will becomes fewer and fewer.  Yes the verifier
has to do conversions but that's already been practice now for many years

If we focused solely on eliminating conversion as the objective, yes, we
could have done things differently but that would been disruptive to
existing practices.  The approach in the draft is incremental over those
practices since there's a large amount of deployed software.

While the draft does not preclude different email "personae" in a PKIX
certificate, I don't think this would be a good to specify in this draft.
I can see confusion between whether those "personae" represents a single
single person or multiple persons and that should be thought through in its
own draft.