9

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);
Jared
  • 3,651
  • 11
  • 39
  • 64
Cratylus
  • 52,998
  • 69
  • 209
  • 339

1 Answers1

3

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.

Thomas Pornin
  • 72,986
  • 14
  • 147
  • 189
  • @Thomas:The RFC explicitely specifies in (2) that it should be the certificate of the CA that ISSUED the certificate in question.The TA though, we use in the validation path, may NOT be the same CA, e.g. if a subordinate CA issued the certificate in question.So for example if certificate A signed by SubCA1, is under revocation check, if the response of the OCSP responder is NOT signed by SubCA1, but it is signed by the TA (which is in the validation path) should the response be rejected or not?The RFC seems to imply to be rejected.But isn't the TA the root of all trust?? – Cratylus May 05 '11 at 17:11
  • What RFC 2560 says is: if CA 'C' issues a certificate 'E', then an OCSP response talking about the status of E should be either directly signed by C (with the same key), or by a responder who has a certificate R issued by C (signed with the same key than the one used to sign E). Whether C is a trust anchor or an intermediate CA is irrelevant here. Any implementation _may_ decide to accept other setups as part of a "local configuration", but it can "legally" reject them as well. – Thomas Pornin May 05 '11 at 17:17
  • @Thomas:So if the local configuration is missing, and the response for certificate 'E' is not signed by 'C' but the TA of the validation path (signer of 'C'), it should be rejected, or is it implementation dependent? – Cratylus May 05 '11 at 17:28
  • An implementation is _entitled_ to reject the response. An implementation is _allowed_ to accept it nonetheless, but if it does so, then its behavior is what the RFC calls a "local configuration". The whole concept of "local configuration" is a RFC-compatible way of saying that implementations are allowed to do whatever they want. – Thomas Pornin May 05 '11 at 17:33
  • @Thomas:I see.This makes sense.What you are describing is the "outside view" of the behavior.In general when using an existing OCSP client implementation (I am using java's pkix apis) I assume the libraries would reject the certificate signed by the TA, if a specific local configuration is not provided.Is this the behavior I should expect?Because I am seeing some inconsistencies on this, between provider implementations and I am not sure on what should I expect to see as a result. – Cratylus May 05 '11 at 17:46
  • There are many different implementation behaviors which have been deployed, so you can expect to see many weird things in the wild. As an OCSP producer, the safe way is to assume that the other implementations do not have a "local configuration". As an OCSP consumer, you can omit any "local configuration" and still claim RFC 2560 full compliance. – Thomas Pornin May 05 '11 at 17:57
  • @Thomas:Thank you very much for helping me understand this.My main concern is what to expect from an existing implementation of an OCSP consumer (in my case Java's PKIX apis) in case I do NOT provide any local configuration.They could either reject the response if signed by the TA or accept it.Do you by any chance have worked with java on this?The documentation is way too vague on this.For me it matters since I want to know the precise behavior so that my enduser "understands" how to deploy it's environment – Cratylus May 05 '11 at 18:06
  • At my work, I use our own OCSP consumer (and I write the code which decides what to do, precisely). For Java's behavior, I suggest that you try (and, when you know, that you add the information as an edit to your question). – Thomas Pornin May 05 '11 at 18:41