[cabfpub] Technically Constrained SubCAs

[Rob Stradling]

On 12/05/16 05:38, Dimitris Zacharopoulos wrote:
> 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.

Let's look at an actual example:
https://crt.sh/?id=12967730

Was it your intent for this CA to be capable of issuing 
id-kp-codeSigning end-entity certificates that Windows would trust?

Assuming it wasn't your intent...
What constraint prevents this CA from issuing id-kp-codeSigning 
end-entity certificates that Windows would trust?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online