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