[cabfpub] Name Constraints, Auditing and EKU
erwann.abalea at keynectis.com
Mon Apr 22 07:08:48 MST 2013
Le 22/04/2013 12:12, Rob Stradling a écrit :
> On 27/03/13 13:49, Steve Roylance wrote:
>> I'm looking for a couple of volunteers to whip this into shape. Any takers?
> Hi Steve. As requested, here are some comments on your proposal...
> 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".
> 13. Appendix B(2)G:
> "** Extended Key Usage within Subordinate CAs is an exception to
> RFC 5280 that MAY be used to further protect relying parties until
> the Name Constraints extension is supported by Application
> Software Suppliers whose software is used by a substantial portion
> of Relying Parties worldwide."
> I agree that we should note that this is "an exception to RFC 5280".
> However, I don't think Mozilla have any plans to stop requiring EKU once
> Name Constraints are supported more widely, since EKU and Name
> Constraints achieve different things.
More information about the Public