[cabfpub] Name Constraints, Auditing and EKU

[Rob Stradling]

On 22/04/13 15:08, Erwann Abalea wrote:
<snip>
>> 12. Appendix B(2)G:
>>        "id-kp-OCSPSigning MUST be present"
>>
>> Disagree.  The OCSP Signing trust purpose is not supposed to be passed
>> down from the Root, and AFAIK there is no way to prevent a Subordinate
>> CA from issuing delegated OCSP Signing Certificates!  (If you have
>> evidence to the contrary, please say).
>
> I think the requirement is really a "id-kp-OCSPSigning MUST NOT be present".
> If CA A issues a certificate to CA B with id-kp-OCSPSigning in the EKU,
> then CA B has now a valid OCSP responder for certificates issued by CA
> A; which is certainly NOT something wanted by CA A.

+1

> There are limits to using an extension for something it wasn't designed
> for... I'm not a fan of "EKU constraints".

I agree that it would be preferable for the PKIX specs to match the 
reality, but unfortunately that isn't the case here.

Mozilla could've achieved the same "technically constrained" goal by 
requiring the use of the Netscape Certificate Type extension instead of 
Extended Key Usage, but they chose EKU because "EKU constraints" are 
already supported more widely.  Yes, it's arguably a violation of 
RFC5280, but the momentum behind "EKU constraints" is already too great 
for that to make any difference IMHO.

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