[cabfpub] Name Constraints, Auditing and EKU

[Erwann Abalea]

Le 22/04/2013 12:12, Rob Stradling a écrit :
> On 27/03/13 13:49, Steve Roylance wrote:
> <snip>
>> 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.