Re: [precis] [Fwd: [pkix] IDNA2008 and PKIX certificates]
John C Klensin <john-ietf@jck.com> Wed, 23 November 2016 15:52 UTC
Return-Path: <john-ietf@jck.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 6C1DC129A05 for <precis@ietfa.amsl.com>; Wed, 23 Nov 2016 07:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 iMhsvrtStdlr for <precis@ietfa.amsl.com>; Wed, 23 Nov 2016 07:52:45 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4E7129E3E for <precis@ietf.org>; Wed, 23 Nov 2016 07:52:05 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1c9Zq6-000MSu-Sb; Wed, 23 Nov 2016 10:52:02 -0500
Date: Wed, 23 Nov 2016 10:51:57 -0500
From: John C Klensin <john-ietf@jck.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Message-ID: <F04F5141033B22C123F856F5@JcK-HP8200>
In-Reply-To: <1479914378.2765.2.camel@redhat.com>
References: <1479808931.31825.10.camel@redhat.com> <1479914378.2765.2.camel@redhat.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/Ag58aXtTQxu88n3YKP8yluxPbXY>
Cc: 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: Wed, 23 Nov 2016 15:52:46 -0000
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. Free advice: (1) Assume there will be no mapping. Use only labels consisting of "final" codepoints, i.e., in IDNA2008 terminology. the decoded form of each label in a domain name must be either an LDH-label or a U-label (2) Use domain names that are valid under both IDNA2003 and IDNA2008. That, unfortunately, limits you to Unicode 3.2 because IDNA2003 does not allow later versions to be used to create labels to be stored in the DNS. If you follow both rules in your choice of domains, you should be safe and behavior should be predictable unless you use a string that IDNA2008 considers a valid U-label but that contains characters that IDNA2003 and/or UTR46 map to different characters. If you need to violate either rule, or use one of the three characters referred to in the previous sentence, expect confusion and possible bad results. If what you intend to put in the certificates are non-ASCII email addresses rather than just domain names, things are even more complicated and confusing. Best to take that up in LAMPS as well. If you want someone to complain to about this situation, I'm sure someone on this list can point you to appropriate parties. :-( Good luck. john --On Wednesday, November 23, 2016 16:19 +0100 Nikos Mavrogiannopoulos <nmav@redhat.com> wrote: > Hi, > I sent the attached message originally in pkix list. It seems > that PKIX (X.509) certificates are currently stuck with > IDNA2003, making the HTTPS situation quite confusing, since > most browsers and registrars use IDNA2008 for DNS. Is there > any suggestion on how this situation can be addressed? > > regards, > Nikos
- [precis] [Fwd: [pkix] IDNA2008 and PKIX certifica… Nikos Mavrogiannopoulos
- Re: [precis] [Fwd: [pkix] IDNA2008 and PKIX certi… Alexey Melnikov
- Re: [precis] [Fwd: [pkix] IDNA2008 and PKIX certi… John C Klensin
- Re: [precis] [Fwd: [pkix] IDNA2008 and PKIX certi… =JeffH
- Re: [precis] [Fwd: [pkix] IDNA2008 and PKIX certi… Nikos Mavrogiannopoulos