[cabfpub] Name Constraints, Auditing and EKU

[Ryan Hurst]

I am just catching up on my CAB Forum mail, I see this conversation
regarding the OCSP signing EKU and it seems there may be a miss
understanding.

There are four trust models for OCSP:
1. CA Signed; the same key/certificate that signed the certificate was used
to sign the OCSP status.
2. CA delegated; the same key/certificate that signed the certificate was
used to sign a certificate that contains the OCSP Signing EKU that was used
to sign a OCSP response.
3. VA Signed; the relying party has been configured out of band to trust
this specific key/certificate to sign OCSP responses for a given set
(usually all) of certificates.
4. VA delegated; the relying party has been configured out of band to trust
a specific key/certificate to sign OCSP responses for a given set of
certificates, that entity has signed a certificate/key that contains the
OCSP Signing EKU.

It is only possible to trust do 1 & 2 automatically in that they are in
essence leverage the policy expressed in the certificate and not out of band
configuration. In other words even if clients support 2 & 3 (which most
don't in my testing) the only thing the browsers do is #1 and #2.

Additionally notice the logic is gated by the signing key; even in CA
delegated the delegated responder can not sign for any other CA in the
hierarchy -- only those within its scope.

I am confident Windows behaves this way, I am also confident what was once
the ValiCert  (now Axway) client behaved this way.

As such I don't see a need to exclude name constrained CAs from using OCSP.

Ryan


-----Original Message-----
> 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.