[cabfpub] Technically Constrained SubCAs

[Rob Stradling]

On 11/05/16 14:05, Dimitris Zacharopoulos wrote:
> On 11/5/2016 3:45 μμ, Rob Stradling wrote:
>> 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.
>>
>
> So, let's assume that there is an Intermediate CA with EKU
> id=kp-serverAuth + NameConstraints extension (all non-critical), and an
> Intermediate CA with no EKU but with NameConstraints extension. Is there
> a difference regarding the technical constraints? Browsers and
> implementations that follow RFC5280 will treat them both exactly the
> same way.

Unfortunately, the "Browsers and implementations that follow RFC5280" 
don't have 100% market share, hence why the BRs permit non-critical Name 
Constraints.

Also, most browsers don't "follow RFC5280" when it comes to processing a 
CA certificate that contains the EKU extension!

> Implementations that completely ignore the Name Constraints
> extension will also treat them exactly the same way.

That's not true.  Implementations that process Name Constraints will 
reject cert chains that don't fit within those constraints, whereas 
implementations that ignore Name Constraints won't do that.

> The CA/B Forum
> refers only to SSL certificates and intermediate CAs that are capable to
> issue SSL certificates.
>
> IMHO, even if there is an Intermediate CA with EKU=id-kp-emailProtection
> + nameConstraints for dNSName and iPAddress, it is technically
> constrained in regards to SSL certificates which is what the CA/B Forum
> worries about :)

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