[cabfpub] Name Constraints, Auditing and EKU
ryan.hurst at globalsign.com
Tue Apr 23 13:50:42 MST 2013
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
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.
> 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