On Thu, Aug 10, 2017 at 1:22 PM, Jonathan Rudenberg via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > RFC 5280 section 7.2 and the associated IDNA RFC requires that > Internationalized Domain Names are normalized before encoding to punycode. > > Let’s Encrypt appears to have issued at least three certificates that have at > least one dnsName without the proper Unicode normalization applied. > > It’s also worth noting that RFC 3491 (referenced by RFC 5280 via RFC 3490) > requires normalization form KC, but RFC 5891 which replaces RFC 3491 requires > normalization form C. I believe that the BRs and/or RFC 5280 should be > updated to reference RFC 5890 and by extension RFC 5891 instead.
I did some reading on Unicode normalization today, and it strongly appears that any string that has been normalized to normalization form KC is by definition also in normalization form C. Normalization is idempotent, so doing toNFKC(toNKFC()) will result in the same string as just doing toNFKC() and toNFC(toNFC()) is the same as toNFC(). Additionally toNFKC is the same as toNFC(toK()). This means that checking that a string matches the result of toNFC(string) is a valid check regardless of whether using the 349* or 589* RFCs. It does mean that Certlint will not catch strings that are in NFC but not in NFKC. Thanks, Peter P.S. I've yet to find a registered domain name not in NFC, and that includes checking every name in the the zone files for all ICANN gTLDs and a few ccTLDs _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
