[cabfpub] Technically Constrained SubCAs

Rob Stradling rob.stradling at comodo.com
Wed May 11 12:45:31 UTC 2016

On 11/05/16 06:36, Dimitris Zacharopoulos wrote:
> Hello everyone,
> The BRs in section 7.1.5 state:
> " For a Subordinate CA Certificate to be considered Technically
> Constrained, the certificate MUST include an Extended Key Usage (EKU)
> extension specifying all extended key usages that the Subordinate CA
> Certificate is authorized to issue certificates for. The
> anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension".
> And then, it goes on about describing the Name Constraints extension
> when the id-kp-serverAuth EKU is used.
> It is clear that if an Intermediate CA Certificate has an EKU, limiting
> the scope to "id-kp-emailProtection", it is technically constrained as
> far as the SSL certificates are concerned and there is no need for an
> additional Name Constraints extension.
> The same applies for an Intermediate CA Certificate that either:
>   * includes the "id-kp-serverAuth" EKU
>   * includes the "anyExtendedKeyUsage"
>   * does not include an EKU
> AND includes the nameConstraints extension with constraints on dNSName,
> iPAddress and DirectoryName. My point is that, if an Intermediate CA
> includes the nameConstraints extension with these constraints, the EKU
> requirement should not be a mandatory requirement. Is there any other
> reason why the EKU is currently a MUST requirement for SSL certificates?

The BRs permit the Name Constraints extension to be non-critical.

There may be platforms that process a non-critical EKU extension but 
completely ignore a non-critical Name Constraints extension.

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

More information about the Public mailing list