<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/5/2016 4:30 μμ, Rob Stradling
wrote:<br>
</div>
<blockquote
cite="mid:7634d4cf-ff9b-0dc6-ed49-8db17a4f1878@comodo.com"
type="cite">
<blockquote type="cite" style="color: #000000;"><br>
So, let's assume that there is an Intermediate CA with EKU
<br>
id=kp-serverAuth + NameConstraints extension (all non-critical),
and an
<br>
Intermediate CA with no EKU but with NameConstraints extension.
Is there
<br>
a difference regarding the technical constraints? Browsers and
<br>
implementations that follow RFC5280 will treat them both exactly
the
<br>
same way.
<br>
</blockquote>
<br>
Unfortunately, the "Browsers and implementations that follow
RFC5280" don't have 100% market share, hence why the BRs permit
non-critical Name Constraints.
<br>
<br>
Also, most browsers don't "follow RFC5280" when it comes to
processing a CA certificate that contains the EKU extension!
<br>
<br>
<blockquote type="cite" style="color: #000000;">Implementations
that completely ignore the Name Constraints
<br>
extension will also treat them exactly the same way.
<br>
</blockquote>
<br>
That's not true. Implementations that process Name Constraints
will reject cert chains that don't fit within those constraints,
whereas implementations that ignore Name Constraints won't do
that.
</blockquote>
<p>Perhaps I did not describe it clearly enough. Implementations
that do not handle name constraints, will treat a subCA with or
without the "kp-server-auth" EKU, in exactly the same way and
probably allow the verification of the SSL certificate. This is
not what we discuss here though. If an implementation ignores the
nameConstraints, there is nothing the CA/B Forum or the BRs can do
about it.</p>
<p>I believe the nameConstraints extension alone, with the three
limits described in 7.1.5 of the BRs is sufficient for an
intermediate CA to be considered "technically constrained" for SSL
certificates. An exception to this rule would be to <u>include</u>
an EKU that <u>does not</u> contain "kp-server-auth" or "anyEKU".
In the latter case, you don't need a nameConstraints extension for
dNSName, iPAddress and DirectoryName because the EKU is the
blocking factor.</p>
<p><br>
</p>
<p>Best regards,</p>
<p>Dimitris.<br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>