Hi Josh, Given that these were all caught by cablint, has Let's Encrypt considered integrating it into your issuance pipeline, or automatically monitoring crt.sh (which runs cablint) for these issues so they don't need to be caught manually by researchers?
Alex On Thu, Aug 10, 2017 at 11:00 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > At 11:30am PST on August 10, 2017, Let’s Encrypt was made aware of a > compliance issue regarding unicode normalization of domain names. During > the same day we were made aware of the issue, all unexpired non-compliant > certificates were found and revoked, a fix was applied to our CA systems, > and we communicated with our community. We consider the matter to be fully > resolved at this point, please let us know if we missed anything. > > We were notified by a community member that Let's Encrypt had issued a > number of certificates containing punycode domain names which had not > undergone compliant unicode normalization. We confirmed that this was the > case and began investigating our code and the relevant RFCs. > > We noticed that the code we added to check the validity of punycode > encodings in CSRs when we implemented support for IDNs didn't enforce any > form of Unicode Normalization. We started developing a fix. After seeking > outside insight into the issue and reading the relevant reference documents > we came to the conclusion that Normalization Form KC was required. The BRs > reference RFC 5280, which in turn references the encoding specified in RFC > 3490 for IDNs, which requires Normalization Form KC. We finished our fix > and deployed it to our CA at 5:20PM PST. > > While developing the fix we searched our issuance databases for all > unexpired certificates containing punycode DNS names and checked them for > non-NFKC compliant names. We found 16, which are listed below. We revoked > these certificates and notified the subscribers who requested them. > > I would like to thank the community members that discovered this issue, as > well as the Let's Encrypt team that worked hard to resolve it quickly. > > -- > Josh Aas > Executive Director > Internet Security Research Group > Let's Encrypt: A Free, Automated, and Open CA > > Serial numbers of affected and revoked certificates: > > 03d03877cbcec666b81340ed6a39c47556d1 > 03758d04a7816ba893847658e636a58e1f71 > 03ef82538ca2e54e97ae2b180ecb32f8cee4 > 044568f36455d8847713adb24c69e60bf123 > 033e73ebfd2f270bc6109925f1ed40edca8b > 038295d240613cdb9367506c0d3cf8002401 > 03556fbc38b13ea3a9b7f4dd59dacc350293 > 030cfe12721e17ca02c095b4a0c5e60ca8da > 03ca6617e634f2f5ad9224ca32ca4c835909 > 03bd090cfe0fbd07b4fc60df07bbc5770b35 > 0314017b4eab87bb0f211e9e2bb329ca4297 > 03f48a8c02c473ce971236b6407ad7d00d89 > 03bfa7b8f318a30a88894523ebd2717ea9b4 > 032d7c46b0a815faa41a1876fed4d66a9993 > 039f94badc798eea44f8c81ceb0515024871 > 038f81a32455e41b702ffb1732186be3a007 > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
