[cabfpub] Technically Constrained SubCAs

[Rob Stradling]

On 12/05/16 09:28, Dimitris Zacharopoulos wrote:
<snip>
>>> 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?
>>>
>> This intermediate CA is technically constrained for SSL certificates,
>> not code Signing. Section 7.1.5 tries to technically constrain
>> intermediate CAs in issuing SSL certificates.
<snip>
> A correction to my previous e-mail. This particular intermediate CA you
> used as an example SHOULD NOT be considered technically constrained per
> my interpretation because it lacks the iPAddress scope in the Permitted
> Subtree of the Name Constraints extension. However, this intermediate
> https://crt.sh/?id=13371081, should be considered technically
> constrained for SSL certificates, even if it lacks the EKU extension.

The current requirement (to include the EKU extension in "technically 
constrained" intermediates) means that CAs must explicitly list "all 
extended key usages that the Subordinate CA Certificate is authorized to 
issue certificates for" (section 7.1.5).

That's a good thing!  We should encourage CAs to constrain their 
intermediate certs as much as possible, because doing so can help to 
thwart attacks.

Example: The Flame malware relied on an intermediate cert that had been 
granted the Code Signing EKU unnecessarily.
https://en.wikipedia.org/wiki/Flame_(malware)#Operation

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