Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt

Russ Housley <housley@vigilsec.com> Thu, 19 January 2017 15:21 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0975129487 for <spasm@ietfa.amsl.com>; Thu, 19 Jan 2017 07:21:21 -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] 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 w9BiNZyGhRit for <spasm@ietfa.amsl.com>; Thu, 19 Jan 2017 07:21:20 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC117129463 for <spasm@ietf.org>; Thu, 19 Jan 2017 07:21:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AC5C230043B for <spasm@ietf.org>; Thu, 19 Jan 2017 10:11:04 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9sXaOzcn4OWz for <spasm@ietf.org>; Thu, 19 Jan 2017 10:11:03 -0500 (EST)
Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 99A6B300209; Thu, 19 Jan 2017 10:11:01 -0500 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <1544074.0Z1XjAZpMm@blitz-lx>
Date: Thu, 19 Jan 2017 10:21:14 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <46661456-29AE-4792-84B9-0A6C59767CB1@vigilsec.com>
References: <1544074.0Z1XjAZpMm@blitz-lx>
To: Tim Ruehsen <tim.ruehsen@gmx.de>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/qNESyqGWsOj5lGGevwa1r3uh-9o>
Cc: spasm@ietf.org, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Subject: Re: [Spasm] New Internet-Draft: draft-housley-rfc5280-i18n-update-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 15:21:22 -0000

On Jan 19, 2017, at 4:22 AM, Tim Ruehsen <tim.ruehsen@gmx.de> wrote:

> Hi,
> 
> as an implementer of IDN aware client software I am seeking for clarification.
> 
> Punycode conversion of an IDN always comes with preprocessing steps. These 
> steps influence the resulting punycode in a way that a reverse procedure 
> (punycode decoding) doesn't result in the original IDN.
> That leads to incompatibilities between IDNA2003 and IDNA2008, addressed by 
> Unicode technical report #46 (TR46)[1]. This technical report defines two 
> preprocessing procedures, namely 'transitional' and 'non-transitional'.
> 
> Currently the open source client software (e.g. curl, wget) goes in the 
> direction of using TR46's 'non-transitional', which is very close to IDNA2008 
> + a few flaws fixed.
> 
> Maybe you could address this also in your draft, to clarify implementation 
> work.
> 
> Just a (often cited) example from the german locale:
> 
> IDNA2003 translates 'faß.de' to 'fass.de'. That is not revertable by the means 
> of IDNA2003. That means using IDN2003 to compare a certificates validity would 
> match 'faß.de' and 'fass.de', both have different owners... no chance to do it 
> right.
> 
> IDNA2008 fixes this and translates 'faß.de' to 'xn--fa-hia.de', but doesn't 
> address other peculiarities.
> 
> 
> Having the above in mind, I would appreciate it if you clearly say:
> 
> 1. IDNs used in certs have to be punycode-encoded using TR46 non-transitional 
> processing (that is where we all want be to some time in the future).

As you say, that would be equivalent to telling people to use IDNA2008 plus some stuff not agreed by the IETF consensus process.  Since this document will be an IETF consensus document (once approved), I think it better to stick to IDNA2088.

> 2. for comparison, two IDNs have to be converted by TR46 non-transitional 
> processing (into punycode) and those resulting strings will be compared byte-
> by-byte.

Given the above, it should say:

   if it is an A-label, convert A through Z to lower case.
   if it is an U-label, convert it to an A-label.
   compare octet by octet.

Russ