> On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy
> <firstname.lastname@example.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.
>> 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.
> 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.
In this case, the NFC and NFKC representations are the same:
irb(main):001:0> require 'simpleidn'
irb(main):002:0> a = "xn--109-3veba6djs1bfxlfmx6c9g"
irb(main):003:0> u = SimpleIDN.to_unicode(a)
irb(main):004:0> u.unicode_normalize(:nfc) == a
irb(main):005:0> u.unicode_normalize(:nfc) == u.unicode_normalize(:nfkc)
irb(main):006:0> n = SimpleIDN.to_ascii(u.unicode_normalize(:nfc))
irb(main):007:0> n == a
dev-security-policy mailing list