[cabfpub] Technically Constrained SubCAs

[Dimitris Zacharopoulos]

On 11/5/2016 4:30 μμ, Rob Stradling wrote:
>>
>> So, let's assume that there is an Intermediate CA with EKU
>> id=kp-serverAuth + NameConstraints extension (all non-critical), and an
>> Intermediate CA with no EKU but with NameConstraints extension. Is there
>> a difference regarding the technical constraints? Browsers and
>> implementations that follow RFC5280 will treat them both exactly the
>> same way.
>
> Unfortunately, the "Browsers and implementations that follow RFC5280" 
> don't have 100% market share, hence why the BRs permit non-critical 
> Name Constraints.
>
> Also, most browsers don't "follow RFC5280" when it comes to processing 
> a CA certificate that contains the EKU extension!
>
>> Implementations that completely ignore the Name Constraints
>> extension will also treat them exactly the same way.
>
> 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. 

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.

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 _include_ an EKU that _does not_ 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.


Best regards,

Dimitris.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160512/0f5c7b0d/attachment-0003.html>