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
"xn--109-3veba6djs1bfxlfmx6c9g.xn--f1awi.xn--p1ai" from
"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:


However the string when normalized to NFC is:


If you look carefully, you will see two different pairs of codepoints
that are swapped in the normalized string.

dev-security-policy mailing list

Reply via email to