[cabfpub] Technically Constrained SubCAs
rob.stradling at comodo.com
Thu May 12 02:14:31 MST 2016
On 12/05/16 09:28, Dimitris Zacharopoulos wrote:
>>> Let's look at an actual example:
>>> 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.
> 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
Example: The Flame malware relied on an intermediate cert that had been
granted the Code Signing EKU unnecessarily.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public