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> Tue, 24 January 2017 05:42 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 E8F1412956A for <ietf@ietfa.amsl.com>; Mon, 23 Jan 2017 21:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 PTV2JwEvlZ2g for <ietf@ietfa.amsl.com>; Mon, 23 Jan 2017 21:42:14 -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 219E5126CD8 for <ietf@ietf.org>; Mon, 23 Jan 2017 21:42:13 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DC460284B0C; Tue, 24 Jan 2017 05:42:12 +0000 (UTC)
Date: Tue, 24 Jan 2017 05:42:12 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <20170124054212.GF860@mournblade.imrryr.org>
References: <20170124020138.65213.qmail@ary.lan> <2A6C1E77A2FDB3E4147305EA@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2A6C1E77A2FDB3E4147305EA@PSB>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/d_6QR2jIZSNg_YdcXJlTWW6QWuE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: 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: Tue, 24 Jan 2017 05:42:16 -0000

On Mon, Jan 23, 2017 at 09:43:04PM -0500, John C Klensin wrote:

> The LAMPS WG apparently decided that it
> wanted to insist on U-labels when IDN labels were concerned and
> that doing so would make comparison rules easier.  I wasn't part
> of their discussions, but believe the issue was that they
> concluded that certificates should contain one form or the
> other, but not both (or either on a per-cert basis), and then
> selected the U-label form.  Doing that avoids their having to
> decide whether fred@xn--exmple-qta.com and fred@ex᭰le.com were
> equal and, I assume, a whole set of even more complex issues
> about hashes and signatures over certificates.
> 
> I can argue for the choice of A-labels rather than U-labels (or
> vice versa), but the choice is a matter of taste and I'm happy
> to accept the WG's analysis and decision.

I also agree that having a single normal form in the certificate
has some merit.  I must say that the choice of U-label as that form
is somewhat unexpected given the use of an A-label normal form with
DNS subjectAltNames.  Consistency might have been preferable, though
of course the local part offers no similar representation, and so
perhaps the compelling argument in favour of U-labels is using a
consistent encoding for both parts.

This does mean one one will not be able to obtain a useful certificate
for addresses like user@xn--b1adqpd3ao5c.org, which is what Apple's
Mail.app (even in the latest MacOS Sierra) emits when I configure
a sender address in the unicode form of that domain.  My MTA delivers
both the U-label and A-label forms to the same mailbox, but my other
(not Mutt) MUA only sends A-labels.

Which leads me to the observation that verification software will
already have the message "From:" (or other purported) signer address
in hand, which it will be comparing with the associated certificate.
So it seems far more natural to use *that* address *verbatim* as
the reference identifier to seek in the certificate.

One might then obtain a certificates with two email subjectAltNames:

    * user@xn--b1adqpd3ao5c.org
    * user@духовный.org

which will work regardless of which form is seen in the message
headers, and would not require any conversions by the verifier.

In other words, check the certificate for whichever address form
appears in the message headers.  If that's how the sending system
knows the author, then perhaps it ought to be good enough in the
certificate too!

This would dramatically simply the implementation, the application
provides the X.509 library with the verbatim author address and
this either matches or does not match the certificate without any
conversions.

-- 
	Viktor.