From nobody Mon Dec  5 21:01:09 2016
Return-Path: <Jeff.Hodges@kingsmountain.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 D6F341296B9 for <precis@ietfa.amsl.com>; Mon,  5 Dec 2016 21:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 rexs7nUF1TTa for <precis@ietfa.amsl.com>; Mon,  5 Dec 2016 21:01:06 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 173921296B6 for <precis@ietf.org>; Mon,  5 Dec 2016 21:01:06 -0800 (PST)
Received: (qmail 15580 invoked by uid 0); 6 Dec 2016 05:01:04 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 6 Dec 2016 05:01:04 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with  id GV0y1u00j2UhLwi01V118E; Mon, 05 Dec 2016 22:01:02 -0700
X-Authority-Analysis: v=2.1 cv=YNIMl32x c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=n5n_aSjo0skA:10 a=9NGZVl_YAAAA:8 a=te1EGT4yAAAA:8 a=S89q9SsuAAAA:8 a=ekYV4lpRAAAA:8 a=K4pVMRo4wAk5KEeOt94A:9 a=QEXdDO2ut3YA:10 a=g0XXRn4i-fsA:10 a=BPxUC_qpliQA:10 a=D7JCScNmnv7i29dlldji:22 a=RRElR4r2U1jGY2dU47NL:22 a=V0Y8OygpzzIQqifL1C4u:22 a=mrCxpU6zTNQDHnudu_9Q:22
Received: from c-73-202-80-238.hsd1.ca.comcast.net ([73.202.80.238]:52860 helo=[192.168.11.53]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1cE7sC-0004d8-0v; Mon, 05 Dec 2016 22:01:00 -0700
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
From: =JeffH <Jeff.Hodges@KingsMountain.com>
Message-ID: <0c4cf44d-29b2-31c9-1c43-372fe6147ef1@KingsMountain.com>
Date: Mon, 5 Dec 2016 21:00:59 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box514.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - KingsMountain.com
X-BWhitelist: no
X-Source-IP: 73.202.80.238
X-Exim-ID: 1cE7sC-0004d8-0v
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: c-73-202-80-238.hsd1.ca.comcast.net ([192.168.11.53]) [73.202.80.238]:52860
X-Source-Auth: jeff.hodges+kingsmountain.com
X-Email-Count: 2
X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/BXfYXEbfSi9KZVNRiedx8H0fQgk>
Cc: IETF PRECIS WG <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 05:01:08 -0000

On Wed, 23 Nov 2016 10:51:57 -0500  John C Klensin <john-ietf at
jck.com> wrote:
 >
 > ... the evidence I've seen suggests that ... 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.

Yes, AFAIK. The WHATWG URL [sic] spec (which obsoletes RFCs 3986 & 3987 
as far as (most?) web browser developers are concerned [0]) references 
(indirectly) only IDNA2003.

It does this by normatively referencing these algorithms in UNICODE TR46 
-- see:
   <http://www.unicode.org/reports/tr46/#ToASCII> and
   <http://www.unicode.org/reports/tr46/#ToUnicode>

Also, back when I was researching IDNA (for what became RFC6125 and 
RFC6797), I exchanged notes with a developer at Opera. This was Fall 
2011 and they were working on Opera 12. He indicated it implemented 
IDNA2008 + RFC5895 "but with a few differences" (though, I do not know 
what the current Opera browser implements IDNA).


 > That makes many situations, not just HTTPS, quite confusing.

Indeed. See also:

   wrt IDNA2003->IDNA2008 transitionn (was: IDN processing-related,
   security considerations for draft-ietf-websec-strict-transport-sec)
   <http://www.alvestrand.no/pipermail/idna-update/2011-October/007170.html>

HTH,

=JeffH

[0] https://url.spec.whatwg.org/#goals



From nobody Tue Dec  6 02:10:08 2016
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