[cabfpub] Name Constraints, Auditing and EKU
rob.stradling at comodo.com
Mon Apr 22 12:37:30 MST 2013
On 22/04/13 15:08, Erwann Abalea wrote:
>> 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.
> 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.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public