2

There are 6 requirements mentioned in RFC 2560 for an OCSP response to consider as a valid OCSP response:

  1. The certificate identified in a received response corresponds to that which was identified in the corresponding request;
  2. The signature on the response is valid;
  3. The identity of the signer matches the intended recipient of the request.
  4. The signer is currently authorized to sign the response.
  5. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent.
  6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) is greater than the current time.

The ambiguation in these requirements is that:

  1. Why we need to check number 3? Is it possible that I send an OCSP request to Comodo CA, and then I receive a response from Iden Trust CA for example?! I mean, isn't it enough to check if the response is signed by one of the trusted CAs in my computers?
  2. Why we need to check number 4? Is there any case which in that case a CA's OSCP responder become unauthorized after a while? If so, why? (I mean which cases)?
Ebrahim Ghasemi
  • 264
  • 2
  • 10

1 Answers1

4

The OCSP response does not necessarily have to be signed by the same entity which signed the original certificate, as this responsibility can be delegated explicitly.

This is discussed in section 4.2.2.2 of RFC 2560:

4.2.2.2 Authorized Responders

The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST either sign the OCSP responses itself or it MUST explicitly designate this authority to another entity. OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that issued the certificate in question.

Systems or applications that rely on OCSP responses MUST be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. They MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:

  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.

In regard to this part of your question:

I mean, isn't it enough to check if the response is signed by one of the trusted CAs in my computers?

It is critical that this is not the case, otherwise any compromised CA could falsify an OCSP response for any certificate, rather than just certificates issued by it (or delegated to it). This is not limited to public CAs; imagine the case where a company's internal CA (e.g. for use with their intranet) is compromised and used to falsify OCSP responses when users visit external websites, thus bypassing HPKP and other stapling.

Subsection 4.2.2.2.1 explains check 4; the OCSP responder must also be checked for revocation to avoid a revoked CA being able to falsify OCSP responses.

Polynomial
  • 132,208
  • 43
  • 298
  • 379