Certificates with improperly normalized IDNs

RFC 5280 section 7.2 and the associated IDNA RFC requires that =
Internationalized Domain Names are normalized before encoding to =
punycode.

Let=E2=80=99s 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=3D187634027&opt=3Dcablint
https://crt.sh/?id=3D187628042&opt=3Dcablint
https://crt.sh/?id=3D173493962&opt=3Dcablint

It=E2=80=99s 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

0
Jonathan
8/10/2017 8:22:46 PM
mozilla.dev.security.policy 1213 articles. 1 followers. Post Follow

6 Replies
51 Views

Similar Articles

[PageSpeed] 12

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

Or broken down into DNS labels:

ICANN tld:

xn--p1ai

Second level domains, registrar is currently RUCENTER-RF

xn--b1addckdrqixje4a
xn--f1awi

Third level domains, subscriber responsibility:

xn--80aqafgnbi
xn-----blcihca2aqinbjzlgp0hrd8c


Enjoy

Jakob
-- 
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
0
Jakob
8/10/2017 9:31:35 PM
> On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy =
<dev-security-policy@lists.mozilla.org> wrote:
>=20
> 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=E2=80=99s 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=3D187634027&opt=3Dcablint
>> https://crt.sh/?id=3D187628042&opt=3Dcablint
>> https://crt.sh/?id=3D173493962&opt=3Dcablint
>> It=E2=80=99s 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
>=20
> 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" .
>=20
> 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.
>=20
> 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).
>=20
> 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'
=3D> true
irb(main):002:0> a =3D "xn--109-3veba6djs1bfxlfmx6c9g"
=3D> "xn--109-3veba6djs1bfxlfmx6c9g"
irb(main):003:0> u =3D SimpleIDN.to_unicode(a)
=3D> "=D8=88=D8=9C=D8=A81=D8=88=D8=98=D8=91=D8=9E=D8=88=D8=A1=D8=92=D8=940=
=D8=9B9=D8=98=D8=9A=D8=9C"
irb(main):004:0> u.unicode_normalize(:nfc) =3D=3D a
=3D> false
irb(main):005:0> u.unicode_normalize(:nfc) =3D=3D =
u.unicode_normalize(:nfkc)
=3D> true
irb(main):006:0> n =3D SimpleIDN.to_ascii(u.unicode_normalize(:nfc))
=3D> "xn--109-3veba6djs0bgykfmx6c9g"
irb(main):007:0> n =3D=3D a
=3D> false=
0
Jonathan
8/10/2017 10:00:40 PM
On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> 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.
>

No. It doesn't. That's been addressed several times in the CA/Browser Forum
with other forms of 'invalid' (non-preferred name syntax) domain names,
such as those with underscores.

It's not permitted under RFC 5280, thus, CAs are responsible. Full stop.


> 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.
>

No, it's a newer RFC not referenced in RFC 5280, so it's not permitted
under the current BRs.

There's no retroactive immunity.
0
Ryan
8/10/2017 10:14:54 PM
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 punycod=
e.
>>
>> Let=E2=80=99s 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=3D187634027&opt=3Dcablint
>> https://crt.sh/?id=3D187628042&opt=3Dcablint
>> https://crt.sh/?id=3D173493962&opt=3Dcablint
>>
>> It=E2=80=99s 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 sh=
ould
>> 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 fro=
m
> 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=3D187634027&opt=3Dcablint
"xn--109-3veba6djs1bfxlfmx6c9g.xn--f1awi.xn--p1ai" from
https://crt.sh/?id=3D187628042&opt=3Dcablint
"xn--109-3veba6djs1bfxlfmx6c9g.xn--f1awi.xn--p1ai" from
https://crt.sh/?id=3D173493962&opt=3Dcablint (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\u=
0030\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\u=
0030\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
0
Peter
8/10/2017 11:59:08 PM
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.
>>> 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.
> 
> 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.


Enjoy

Jakob
-- 
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
0
Jakob
8/11/2017 2:47:33 AM
On 11/08/2017 00:14, Ryan Sleevi wrote:
> On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>>
>> 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.
>>
> 
> No. It doesn't. That's been addressed several times in the CA/Browser Forum
> with other forms of 'invalid' (non-preferred name syntax) domain names,
> such as those with underscores.
> > It's not permitted under RFC 5280, thus, CAs are responsible. Full stop.
> 

As an aside (not applicable to this case), it is worth noting that some
newer RFCs explicitly require DNS names with underscores, though
currently only for things that won't to go in a certificate dnsName SAN
extension.

> 
>> 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.
>>
> 
> No, it's a newer RFC not referenced in RFC 5280, so it's not permitted
> under the current BRs.
> 
> There's no retroactive immunity.
> 

As you could see, in the snipped part of my posting, I was checking the
wrong name from the certificate and concluding that it was apparently
valid under RFC349x, which Jonathan wrote was the one referenced by the
BRs.  Therefore I mistook the report for complaining that the encoding
was not valid under RFC5890, which is not referenced by the BRs.

In a later post, Jonathan explained that the problematic name was a
different one which I did not look at.



Enjoy

Jakob
-- 
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
0
Jakob
8/11/2017 2:58:09 AM
Reply: