On Thu, Aug 10, 2017 at 2:31 PM, Jakob Bohm via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On 10/08/2017 22:22, Jonathan Rudenberg 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. >> >> https://crt.sh/?id=187634027&opt=cablint >> https://crt.sh/?id=187628042&opt=cablint >> https://crt.sh/?id=173493962&opt=cablint >> >> 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. >> >> Jonathan >> > > All 3 dnsName values exist in the DNS and point to the same server (IP > address). Whois says that the two second level names are both registered > to OOO "JilfondService" . > > This raises the question if CAs should be responsible for misissued > domain names, or if they should be allowed to issue certificates to > actually existing DNS names. > > I don't know if the bad punycode encodings are in the 2nd level names (a > registrar/registry responsibility, both were from 2012 or before) or in > the 3rd level names (locally created at an unknown date). > > An online utility based on the older RFC349x round trips all of these. > So if the issue is only compatibility with a newer RFC not referenced from > the current BRs, these would probably be OK under the current BRs and > certLint needs to accept them. > > Note: The DNS names are: > > xn--80aqafgnbi.xn--b1addckdrqixje4a.xn--p1ai > xn--80aqafgnbi.xn--f1awi.xn--p1ai > xn-----blcihca2aqinbjzlgp0hrd8c.xn--f1awi.xn--p1ai
These are not the names causing issues. "xn--109-3veba6djs1bfxlfmx6c9g.xn--b1addckdrqixje4a.xn--p1ai" from https://crt.sh/?id=187634027&opt=cablint "xn--109-3veba6djs1bfxlfmx6c9g.xn--f1awi.xn--p1ai" from https://crt.sh/?id=187628042&opt=cablint "xn--109-3veba6djs1bfxlfmx6c9g.xn--f1awi.xn--p1ai" from https://crt.sh/?id=173493962&opt=cablint (same name as the prior cert) It is the xn--109-3veba6djs1bfxlfmx6c9g label that is incorrect in all three. In all three the bad label is not in the registered domain or any public suffix. Directly decoded, this string is: "\u0608\u061c\u0628\u0031\u0608\u0611\u0618\u061e\u0608\u0621\u0612\u0614\u0030\u061b\u0039\u061a\u0618\u061c" However the string when normalized to NFC is: "\u0608\u061c\u0628\u0031\u0608\u0618\u0611\u061e\u0608\u0621\u0612\u0614\u0030\u061b\u0039\u0618\u061a\u061c" If you look carefully, you will see two different pairs of codepoints that are swapped in the normalized string. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
