Re: [precis] [Fwd: [pkix] IDNA2008 and PKIX certificates]

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 06 December 2016 10:10 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5443A129F4C; Tue, 6 Dec 2016 02:10:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.818
X-Spam-Level:
X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 4nzXVbXsCY0y; Tue, 6 Dec 2016 02:10:05 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB110129F27; Tue, 6 Dec 2016 02:10:05 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 524738124B; Tue, 6 Dec 2016 10:00:55 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.253]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB6A0qUU011917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Dec 2016 05:00:54 -0500
Message-ID: <1481018451.3063.12.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: John C Klensin <john-ietf@jck.com>
Date: Tue, 06 Dec 2016 11:00:51 +0100
In-Reply-To: <F04F5141033B22C123F856F5@JcK-HP8200>
References: <1479808931.31825.10.camel@redhat.com> <1479914378.2765.2.camel@redhat.com> <F04F5141033B22C123F856F5@JcK-HP8200>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 06 Dec 2016 10:00:55 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/DyPMn4zuTmUyH2ph3FYsSuKfZFo>
Cc: spasm@ietf.org, precis@ietf.org
Subject: Re: [precis] [Fwd: [pkix] IDNA2008 and PKIX certificates]
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Dec 2016 10:10:07 -0000

On Wed, 2016-11-23 at 10:51 -0500, John C Klensin wrote:
> Nikos,
> 
> Follow Alexey's advice about where to take this -- LAMPS should
> have constructive suggestions.  However, the evidence I've seen
> suggests that, while most registrars use IDNA2008 as you note,
> many or most browsers are still using IDNA2003 or some hybrid
> involving IDNA2003, UTR46, and, sometimes, unofficial (and
> inconsistent) versions of Stringprep modified to reflect some or
> all Unicode versions since 3.2.
> 
> That makes many situations, not just HTTPS, quite confusing.

Thank you for the suggestions and the comments John and Alexey. I
return on that. I've sent an email to the LAMPS list with no reply. I
find that understandable since few of the PKIX people actually
understand what is going on with IDNA, labels, and unicode. On that
field, we simply need a standard to follow and the current IDNA2003 vs
IDNA2008 situation doesn't help. 

More precisely what is needed is a standard to reference to map UTF-8
hostnames to ACE and vice-versa. I am not sure whether reverse function
required by PKIX (we need to display to the user the actual string),
exists. According to some discussion in libidn2 list, there is no RFC
describing it [0]. Has this changed since then?

About transitioning, my impression is that for PKIX, a transition
method would most likely make things worse rather than provide an
actual fix (IDNA2008 is already deployed in DNS registrars, and PKIX is
currently mandating an obsolete standard).

What is required at the PKIX, is an update of section 7.2 of RFC5280:
https://tools.ietf.org/html/rfc5280#section-7.2

Could someone from the precis list with better understanding of the
IDNA specifics help with updating that section? I could help drafting
it, if required.

regards,
Nikos

[0]. https://lists.gnu.org/archive/html/help-libidn/2013-06/msg00001.html