[Servercert-wg] IDNA2003 vs IDNA2008 usage

[Corey Bonnell]

Hi Martijn,

The same Punycode algorithm as defined in RFC 3492 is used by IDNA2003, 2008, and more to convey Unicode code points in domain labels in a way that conforms to the LDH syntax. The BRs currently require that any labels that are prefixed with “xn—” contain valid Punycode-encoded values (the defined term “P-label” was created to denote this type of label). Given that IDNA2008 “A-labels” which may contain code points that are not allowed in IDNA2003 (or other deviations from IDNA2003) are valid Punycode, such values are allowed by the BRs as valid P-labels.

 

This flexibility in allowing differing IDNA standards in domain labels was an explicit design decision of SC48v2, as there was much variation between browsers and domain registries in terms of conformance to the various IDNA standards.

 

Thanks,

Corey

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Martijn Katerbarg via Servercert-wg
Sent: Tuesday, March 19, 2024 5:12 AM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [Servercert-wg] IDNA2003 vs IDNA2008 usage

 

All,

 

We’ve recently become aware that some CAs have issued certificates containing punycode encoded domain labels compatible with IDNA2008, that are not compatible with IDNA2003.

 

Our own interpretation is that IDNA2008 is currently not permitted. While the LDH, Non-Reserved LDH and XN label definitions reference RFC 5890, they only quote a very specific part of it. Meanwhile the P-Label definition directly references RFC3492 for encoding. Likewise RFC5280 which the BRs require adherence to, both reference IDNA2003 (RFC3490). (Side-note, I believe RFC9549 aims to rectify the issue with RFC5280)

 

As a note, ballot SC48v2 updated the language to the current definition.

 

I’m looking for the opinions of this group as to their interpretations, as well as opinions if we indeed want to allow IDNA2008 and make this clear within the language.

 

Regards,

 

Martijn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240319/4923d754/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5231 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240319/4923d754/attachment-0001.p7s>