IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 03 February 2017 19:51 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6841297F7 for <ietf@ietfa.amsl.com>; Fri, 3 Feb 2017 11:51:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7PBBwFFILNz for <ietf@ietfa.amsl.com>; Fri, 3 Feb 2017 11:51:26 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E98012951E for <ietf@ietf.org>; Fri, 3 Feb 2017 11:51:26 -0800 (PST)
Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 95403284E4B for <ietf@ietf.org>; Fri, 3 Feb 2017 19:51:25 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAAFsWK2QjdkovXTgJR-6Hpj=u=MD5Mjk0srYVpoqNnK_d7_Y9Q@mail.gmail.com>
Date: Fri, 03 Feb 2017 14:51:24 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <78EFB6CA-BB21-4B6F-964C-9A0BBAA68023@dukhovni.org>
References: <B9F32633ED13374379C6E0D1@PSB> <20170124193109.68919.qmail@ary.lan> <20170201210155.GI28349@mournblade.imrryr.org> <D45CE6A5317D4B373CD90742@PSB> <CAAFsWK1kQUUZrq9Cs47+jYbEJXW+hQN8gzKb+2qjXYdfYhRFzw@mail.gmail.com> <E56ED618-6670-437D-87A9-BD59FC10DBC1@dukhovni.org> <CAAFsWK2QjdkovXTgJR-6Hpj=u=MD5Mjk0srYVpoqNnK_d7_Y9Q@mail.gmail.com>
To: IETF general list <ietf@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mMPN3mmD-qYA2tcidsVv6mDzQ2Y>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: IETF general list <ietf@ietf.org>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 19:51:28 -0000

> On Feb 3, 2017, at 2:38 PM, Wei Chuang <weihaw@google.com> wrote:
> 
> Can you clarify what this means for addresses such as:
> 
>         U: ietf-dane@духовный.org
> 
> Not recommended but supported by SmtpUtf8Name.
>  
> 
>         A: ietf-dane@xn--b1adqpd3ao5c.org
> 
> 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).

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

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email