<div dir="ltr"><a href="http://bugzil.la/394919">http://bugzil.la/394919</a> describes the behaviour of NSS (both legacy and libpkix) with respect to nameConstraints.<div><br></div><div>In all cases, the Subject name MUST be compliance with the NC.PermittedSubTrees.directoryName if present.</div>
<div>IF no SAN is present (meaning the CN will be treated as a host name, as described in RFC 6125), then the CN MUST ALSO be compliant with the NC.PermittedSubTrees.dnsNames.</div><div><br></div><div>This is not required by RFC 5280.</div>
<div><br></div><div>I'm not sure I understand your question re: IDN comparisons. The dnsNames subtree is an IA5String, so it must be punycoded (per 7.2 of 5280).</div><div><br></div><div>NSS expects the hostname-to-be-validated as ASCII (eg: Punycoded) and performs an ASCII-code-point equivalence test when comparing the CN to the hostname. As such, if the CN contains a non-punycoded name, no subjectAltName is present (eg: in violation of the BRs), but the dNSNames contains a punycoded subtree, then the certificate will be rejected (non-ASCII equivalence). eg: It does not punycode the CN before comparison.</div>
<div><br></div><div>CryptoAPI is different, in that before performing hostname equivalence checks as part of the SSL policy, the common name will be punycoded/normalized. ISTR this goes as far back as roughly the IE 3.0/5.0 implementation of CAPI (it's been a long while since I've tested this aspect).</div>
<div><br></div><div>It can be argued that such policies are particular aspects of SSL hostname validation, and thus more reflected in RFC 6125 than RFC 5280. OpenSSL's lack of an RFC 2818/6125 hostname validation routine (which has caused an unending set of bugs in language bindings) can similarly be blamed for why such certificates are accepted.</div>
<div><br></div><div>The only use of heuristics that I'm aware of are with respect to whether the CN looks like an IP address.</div><div>- OS X (which doesn't do NCs...) uses a heuristic to see if the CN parses as an IPv4 address when matching host address (does not support IPv6...).</div>
<div>- CryptoAPI does no such parsing, IIRC, and thus I believe does not constrain the CN to permittedSubTrees.iPAddress</div><div>- NSS always treats the CN as a dNSName, and thus does not check that whether permittedSubtrees.iPAddress overlaps. I've filed <a href="http://bugzil.la/895063">http://bugzil.la/895063</a> for this.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 17, 2013 at 10:52 AM, Erwann Abalea <span dir="ltr"><<a href="mailto:erwann.abalea@keynectis.com" target="_blank">erwann.abalea@keynectis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Bonjour,<br>
<br>
Reading the X.509 standard (8.4.2.2 and Annex G):<br>
<ul>
<li>SSL1.cer is invalid because it has a SAN/dnsName containing
"<a href="http://anything.example.com" target="_blank">anything.example.com</a>" and its issuer CA has a NameConstraints
only allows dnsNames ending in "<a href="http://onlythis.com" target="_blank">onlythis.com</a>"; could you
produce certificates with matching names
("<a href="http://google.com" target="_blank">google.com</a>"/"<a href="http://onlythis.com" target="_blank">onlythis.com</a>")?<br>
</li>
<li>SSL2.cer is invalid for the same reason.</li>
<li>SSL3.cer is valid ("C=US, ST=MA, L=Boston, O=Example LLC,
O=Google, CN=*.<a href="http://google.com" target="_blank">google.com</a>" is a subordinate of "C=US, ST=MA,
L=Boston, O=Example LLC", which is the only permitted
directoryName form, and the EE cert doesn't contain a SAN
extension).</li>
</ul>
I tried to find equivalent tests in PKITS, with no luck (the
closer I get is with a NC permitting a DN and an rfc822Name, and
the EE has its email in the SAN, not in the subject).<br>
<br>
<br>
Testing with real browsers gives:<br>
<ul>
<li>FF22.0, SSL1.cer, SSL2.cer, SSL3.cer: NOK<br>
L'autorité de certification pour ce certificat n'est pas
autorisé à délivrer un certificat avec ce nom.<br>
(Code d'erreur : sec_error_cert_not_in_name_space)</li>
<li>IE8/XPSP3, SSL1.cer, SSL2.cer, SSL3.cer: NOK<br>
Le certificat de sécurité présenté par ce site Web a été émis
pour une autre adresse de site Web.</li>
<li>I guess that Chrome and Safari will produce the same result
on that platform.<br>
</li>
<li>Opera12.15/XPSP3, SSL1.cer, SSL2.cer: NOK<br>
Connexion sécurisée: erreur fatale (47)<br>
</li>
<li>Opera12.15/XPSP3, SSL3.cer: OK (owner is shown as
"*.<a href="http://google.com" target="_blank">google.com</a>, Example LLC, Google")</li>
<li>OpenSSL-based clients, SSL1.cer, SSL2.cer: NOK<br>
Verify return code: 47 (permitted subtree violation)</li>
<li>OpenSSL-based clients, SSL3.cer: OK</li>
</ul>
<br>
It seems FF and CAPI (XPSP3) consider that the CN is to be
validated as a dnsName and not part of the directoryName (whence,
it's validated against NC.PermittedSubTrees.dnsName instead of
NC.PermittedSubTrees.directoryName). This behaviour isn't
mentioned in RFC5280 either, but it's logical (legacy use of email
addresses in the subjectName is also mentioned in RFC5280, and the
same kind of treatment regarding NC extension is proposed).
However, I don't know if that behaviour is the result of
heuristics (does the CN look like a FQDN?), and how all this will
work with internationalized domain names. There's room for
failures.<br>
<br>
Opera uses OpenSSL, clearly, and they both follow X.509 to the
letter.<br>
<br>
I don't have anything more recent than XPSP3 as a VM, sorry.<br>
<br>
<pre cols="72">--
Erwann ABALEA
</pre>
Le 17/07/2013 17:09, Ben Lightowler a écrit :<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">Hi Erwann,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Steve asked me to put together some example
certificates based on your concerns surrounding Name
Constraints please find a zip attached with a Root and Issuing
CA, as well as three SSL certificate created to your
specifications in the examples you gave earlier.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hope this helps,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="line-height:115%"><b><span style="color:#1f497d">Ben
Lightowler<u></u><u></u></span></b></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:10.0pt;line-height:115%;color:#1f497d">Sales
Engineer</span><b><span style="color:#1f497d"><u></u><u></u></span></b></p>
<p class="MsoNormal" style="line-height:115%"><b><span style="font-size:4.0pt;line-height:115%;color:#1f497d"><u></u> <u></u></span></b></p>
<p class="MsoNormal" style="line-height:115%"><b><span style="color:#1f497d">GlobalSign<u></u><u></u></span></b></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:10.0pt;line-height:115%;color:#1f497d">+44
(0) 1622 766766 <u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:10.0pt;line-height:115%;color:#1f497d"><a href="http://www.globalsign.co.uk/" target="_blank"><span style="color:blue">www.globalsign.co.uk</span></a> | <a href="http://www.globalsign.eu/" target="_blank"><span style="color:blue">www.globalsign.eu</span></a> <u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:4.0pt;line-height:115%;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal" style="line-height:115%"><span style="color:#1f497d"><img alt="Description: Description: secured-by-globalsign.gif" border="0" height="63" width="171"></span><span style="font-size:4.0pt;line-height:115%;color:#7f7f7f"><u></u><u></u></span></p>
<p class="MsoNormal" style="line-height:115%"><b><span style="font-size:4.0pt;line-height:115%;color:#404040"><u></u> <u></u></span></b></p>
<p class="MsoNormal" style="line-height:115%"><span style="font-size:7.5pt;line-height:115%;color:#1f497d">Springfield
House, Sandling Road, Maidstone, Kent, ME14 2LP, UK. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:7.5pt;color:#1f497d">Tel:
+44 1622 766766 Fax: +44 1622 662255<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><img alt="Description: Description: oneclick-2" border="0" height="75" width="450"></span><span><u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div>