[cabfpub] Technically Constrained SubCAs

[Dimitris Zacharopoulos]

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. Implementations that completely ignore the Name Constraints
extension will also treat them exactly the same way. 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 :)

Best regards,
Dimitris.