[cabfpub] Technically Constrained SubCAs
rob.stradling at comodo.com
Wed May 11 05:45:31 MST 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.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public