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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 23 Nov 2016 16:19:38 +0100

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

Subject: [pkix] IDNA2008 and PKIX certificates
From: Nikos Mavrogiannopoulos <[email-masked]>
To: [email-masked]
Date: Tue, 22 Nov 2016 11:02:11 +0100
List-Id: PKIX Working Group <pkix.ietf.org>

Hi,
 RFC5280 and its update (6818), reference IDNA2003 (rfc3490) for
storing internationalized DNS names. However, IDNA2003 is already
obsolete standard (it seems it was already deprecated when RFC6818 was
published [0]) and in practice phased out. What is the current best
practice on internationalized names with certificates?

Is it transparently switch to IDNA2008 (rfc5890), and let software
figure out the reverse mappings to utf8 somehow?

Or is it store UTF-8 dns names on the certificate, and let the software
comparing DNS names do any mapping it deems necessary prior to
comparison?

regards,
Nikos

[0]. https://www.ietf.org/mail-archive/web/pkix/current/msg28386.html

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Nov 2016 15:29:00 +0000

Hi Nikos,

You might want to email the LAMPS WG ([email-masked]) asking about this.

> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Nov 2016 10:51:57 -0500

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 <[email-masked]> 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