javasecuritycryptographypkiocsp

Should I accept an OCSP responder certificate signed by the trust anchor?

Could someone please help me on the following?
RFC2560 defines when an OCSP responder certificate (sigining the response) could be accepted: 

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

My question is:
If the certificate of the OCSP responder is signed by the Trust Anchor of the validation path, is it also considered accepted?
I have the impression that it should be, but this is not stated explicitely above from RFC and could not found an explicit reference on this.

From my reading of the RFC though is that even if it is signed by the TA, it is still is not valid for OCSP response.
Any help is appreciated
Note: I am working in java on this, in case it matters

UPDATE:
In section 2.2 of the RFC:

All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CA

Point 2 seems ambiguous to me.
It could mean:
a) Any PK trusted, so Trust Anchor is acceptable
or
b) Have the meaning of point (1) in the first quotation, which means preconfigure a certificate (any) to trust as being the OCSP responder's as for example is done in java here: 

   Security.setProperty("ocsp.responderCertSubjectName",ocspCert.getSubjectDN().getName));
   List<X509Certificate> list = new ArrayList<X509Certificate>();
   list.add(ocspCert);
   CollectionCertStoreParameters p = new CollectionCertStoreParameters(list);  
   CertStore store = CertStore.getInstance("Collection", p);
   PKIXParameters params = new PKIXParameters(Collections.singleton(anchor));
   params.addCertStore(store);
Solution

  • In RFC 2560, these mean:

    1. Matches a local configuration of OCSP signing authority for the
certificate in question; or

    → You can do what you want as long as you are consistently aware of what you are doing. This is the "catch-all" clause which means that you will most likely conform to RFC 2560 whatever you do. But if you are the producer of OCSP responses, you will want to avoid using that license-to-be-standard because you would prefer users of your responses to accept them even if they do not have the same "local configuration" than you.

    2. Is the certificate of the CA that issued the certificate in
question; or

    → The tricky point is that the Trust Anchor is a CA. It is not formally represented by a certificate (although in many systems trust anchors are encoded as self-signed certificates); but it issues certificates and, as such, is a certification authority. You are in this case if the OCSP response was signed with the the TA key.

    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
extension and is issued by the CA that issued the certificate in
question."

    → Similarly to above, an OCSP responder signing an answer for certificate X, where X appears to have been issued by the TA, may use a responder certificate R which has also been issued by the same TA -- by this, I mean that both X and R have been issued by the certification authority whose name and key you use as Trust Anchor.

    These three cases describe the verification steps which should be performed by whoever receives an OCSP response, and wishes to use it as part of a certificate path validation. Section 2.2 of the RFC is about the duties of the OCSP responder:

    All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a specially
   marked certificate issued directly by the CA, indicating that the responder
   may issue OCSP responses for that CA

    These three cases matches those for the receiver, which we detailed above, in the "2, 1, 3" order. There again, the "CA who issued the certificate" can be the entity whose name and public key will be used as trust anchor by the receiver.