On 11/08/2017 00:00, Jonathan Rudenberg wrote:

On Aug 10, 2017, at 17:31, 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.
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
irb(main):001:0> require 'simpleidn'
=> true
irb(main):002:0> a = "xn--109-3veba6djs1bfxlfmx6c9g"
=> "xn--109-3veba6djs1bfxlfmx6c9g"
irb(main):003:0> u = SimpleIDN.to_unicode(a)
=> "؈؜ب1؈ؘؑ؞؈ءؒؔ0؛9ؘؚ؜"
irb(main):004:0> u.unicode_normalize(:nfc) == a
=> false
irb(main):005:0> u.unicode_normalize(:nfc) == u.unicode_normalize(:nfkc)
=> true
irb(main):006:0> n = SimpleIDN.to_ascii(u.unicode_normalize(:nfc))
=> "xn--109-3veba6djs0bgykfmx6c9g"
irb(main):007:0> n == a
=> false

Ah, I missed that this was about one of many extra SANs in the
certificate, not the main name, as this was not previously reported and
I don't have the tools handy to easily go through all those SANs myself.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list

Reply via email to