[cabfpub] Technically Constrained SubCAs

Dimitris Zacharopoulos jimmy at it.auth.gr
Thu May 12 02:35:43 MST 2016


On 12/5/2016 12:14 μμ, Rob Stradling wrote:
>> 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

I agree that it is a good thing to further limit Intermediate CAs. This
could change the requirement to have a serverAuth EKU for Intermediate
CAs capable of issuing SSL certificates, from a "MUST" to a "SHOULD". As
long as the nameConstraints extension is properly set with
dnsName+iPAddress, the attack vector for SSL certificates remains the
same whether the Intermediate includes the EKU with serverAuth or not.


Dimitris.



More information about the Public mailing list