Hi Aaron, Thanks for raising this. Regarding the callout on P-labels in the bug:
> By these definitions, the label xn--2ug is a valid P-Label, as it begins > with the prefix “xn--”, and the remainder of the label is valid output from > the Punycode algorithm with input U+200E. Note that this definition directly > references the Punycode spec (RFC 3492) rather than referencing the > higher-level IDNA spec (RFC 3490) that we examined above, and that the > Punycode algorithm itself does not forbid any particular code points from > being encoded. The reference to RFC 3492 (the Punycode RFC) is by design, as normatively referencing RFC 3490 would constrain the set of domain labels to only those allowed by IDNA 2003. Every standard or variant of IDNA uses the Punycode algorithm as defined in RFC 3492 underneath for encoding/decoding, so this provides flexibility. This flexibility is needed because domain registrars have not universally settled on IDNA 2008 (there’s a lot of domains out there with emoji, which are generally disallowed by IDNA 2008), and user agents generally do not follow the IDNA standards. For example, depending on which source you trust, Chrome still might not support non-transitional UTS-46 processing [1][2], which deviates from the behavior in Firefox and Safari and is not compatible with IDNA 2008. This deviation in behavior across user agents means that U-labels (i.e., domain labels consisting of non-ASCII/LDH characters) might yield different LDH label (i.e., on the wire) representations. To account for this, I created the P-label term in Ballot SC-48 [3] to allow flexibility in the LDH label representation and make it explicit that the BRs are deviating from the RFC 5280 profile (which mandates IDNA 2003) in this regard. While this may appear to be overly permissive, it is important to remember that the BR profile requires that the subject CN be represented in its LDH-label form and must not use U-labels (SAN dNSNames already implicitly require LDH label representation due to the constraints on character repertoire imposed by the ASN.1 IA5String type). LDH label representations are always unambiguous in terms of the DNS protocol, so there is no possibility of confusion or spoofing. Thus, this requirement for using LDH labels throughout the profile provides a clean separation of concerns: the CA need not be concerned about the vagaries of user agent behavior (which can change with no notice or change to a standard) and is instead exclusively concerned with the validation and processing of domain names as represented by LDH labels. The guardrails established by the P-label definition provide assurance that XN labels will, at the very least, contain valid Punycode. The rendering of that Punycode domain label in Unicode (or not) is exclusively a user agent concern. With all that in mind, I agree with your team’s conclusion that the issuance of the certificate is not a violation. Thanks, Corey [1] https://chromium.googlesource.com/chromium/src/+/main/docs/idn.md [2] https://chromestatus.com/feature/5105856067141632 [3] https://cabforum.org/2021/07/22/ballot-sc048v2-domain-name-and-ip-address-encoding/ From: 'Aaron Gable' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> Sent: Wednesday, May 14, 2025 5:26 PM To: dev-secur...@mozilla.org <dev-security-policy@mozilla.org> Subject: New Bugzilla Report regarding issuance for Internationalized Domain Names Hello WebPKI community and root programs, Let's Encrypt has filed a new Bugzilla ticket in the format of a Preliminary Incident Report: https://bugzilla.mozilla.org/show_bug.cgi?id=1966515 We believe that the behavior described in that ticket is not a violation of the Baseline Requirements or any specific Root Program Requirements. However, we wanted to share our research with you to begin a discussion on whether other members of the community share our reasoning and conclusions. Thank you, Aaron Gable on behalf of Let's Encrypt -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> " group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org <mailto:dev-security-policy+unsubscr...@mozilla.org> . To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErco1mAcqMkae9xyG35oAEVxfz7gepbH%3D91u5%2BxfP99H8Q%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErco1mAcqMkae9xyG35oAEVxfz7gepbH%3D91u5%2BxfP99H8Q%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DS0PR14MB621667C04DD1863ED4D04A099290A%40DS0PR14MB6216.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
