Let's Encrypt: Issuance for Invalid Internationalized Domain Name
The bug concerns a certificate issued by Let’s Encrypt that contains a SAN DNS name `xn--2ug.walesbonner.net`, where the first label `xn--2ug` is the Punycode encoding of Unicode code point U+200E (LEFT-TO-RIGHT MARK). The reporter argues that, while U+200E is prohibited/disallowed by RFC 5280/Nameprep (and is listed as prohibited in the referenced RFC 3454 section), the certificate is still compliant with the Baseline Requirements due to the BR exception allowing P-Labels in SANs. A Mozilla representative and the Chrome Root Program both stated that the certificate is technically compliant with the Baseline Requirements and TLS/Root Program policy, and supported closing the bug as INVALID. The Mozilla representative also stated Mozilla has concerns about including Unicode code points disallowed by IDNA 2003 and IDNA 2008 because it could undermine user safety and trust, and recommended clarifying rules in the CA/Browser Forum. The reporter stated that two root programs concurred with closing as INVALID and that Let’s Encrypt would participate in future public discussion about whether DNS names in publicly-trusted certificates should be required to adhere to IDNA 2003 and/or IDNA 2008. The bug was ultimately marked RESOLVED with resolution INVALID.
- Let’s Encrypt issued a certificate containing a SAN DNS name with a P-Label encoding U+200E (LEFT-TO-RIGHT MARK).
- A preliminary report bug was filed to discuss whether the issuance violates Mozilla or Baseline Requirements.
- The Chrome Root Program supported closing the bug as INVALID.
- Mozilla provided an analysis and recommended clarifying CA/Browser Forum rules while supporting INVALID closure.
- Let’s Encrypt requested closure as INVALID and stated it would not provide further updates.
- A final call for comments was issued before the bug would be closed as INVALID.
- Internet Security Research Group — Filed a preliminary report describing the certificate SAN `xn--2ug.walesbonner.net` (U+200E) and asked whether it violates Mozilla/Baseline Requirements, requesting INVALID if root programs agree.
- Community commenter — Commented that although the Punycode strings are syntactically valid, the corresponding Unicode representations may be disallowed by IDNA and questioned whether such domains are valid/resolvable.
- HARICA — Asked whether the BR exception for P-Labels is justified by support for newer Unicode/IDNA standards.
- Internet Security Research Group — Responded that the cited BR note is non-normative motivation and argued the CA should not determine which Unicode characters are renderable by user agents.
- Google representative — Stated that, based on SC-048 and the in-force BRs and discussions, they support closing as INVALID and found no violations of TLS BRs or the Chrome Root Program Policy.
- Mozilla representative — Provided Mozilla’s analysis: technically compliant so INVALID, but expressed concerns about disallowed Unicode code points and urged CA/Browser Forum clarification to protect against spoofing/misuse.
- Internet Security Research Group — Noted two root programs concurred with INVALID closure, provided a closure summary, and asked to close as INVALID.
- Snj representative — Asked whether an interim approach of voluntarily enforcing specific NAMEPREP tables (subset) would be appropriate.
- Internet Security Research Group — Responded that such tables are not a clean subset and argued a CA should not refuse issuance for domains a browser can load/render; reiterated preference to discuss on mailing lists and asked to close as INVALID.
- CCADB representative — Issued a final call for comments/questions before the bug would be closed as INVALID.