Subject: Explanation of the OCSP sign request

From: Robert Hernady <[email-masked]>
Date: Tue, 21 Feb 2012 13:51:16 +0000

Hi,

I'm looking for the better understanding for the RFC 2560  Online Certificate Status Protocol - OCSP.

The section 4.1 defines the ASN.1 structure for the OCSP request. Follows the shortened structure.

OCSPRequest
   TBSRequest
   OPTIONAL Signature,

where the signature is marked as OPTIONAL. That one leads to the conclusion that signing of the OCSP request is not required and the implementer of the OCSP client MAY digitally sign that request.

But the section 2.3  Exception Cases defines error types and one of them is "-sigRequired"

   The response "sigRequired" is returned in cases where the server
   requires the client sign the request in order to construct a
   response.

Does it mean that in that case the signature of the request becomes mandatory? Does it mean that OCSP clients that have not implemented OCSP request signing after are breaking this RFC?

Thanks in advance

Robert Hernady

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Feb 2012 20:55:40 +0100 (MET)

Robert Hernady wrote:
> 
> I'm looking for the better understanding for the
> RFC 2560  Online Certificate Status Protocol - OCSP.
> 
> where the signature is marked as OPTIONAL. That one leads to the
> conclusion that signing of the OCSP request is not required and
> the implementer of the OCSP client MAY digitally sign that request.
> 
> Does it mean that in that case the signature of the request becomes
> mandatory? Does it mean that OCSP clients that have not implemented
> OCSP request signing after are breaking this RFC?

OCSP servers that are requiring an OCSP request to be signed are not
"breaking" the protocol, but preclude interoperability with the vast
majority of potential peers, by using a standardized protocol option
to implement a very restrictive policy in whose OCSP requests they answer.

Whether such a policy is configured for an OCSP responder is a
deployment decision of the consumer of the technology.

Breaking interop is the logical result when requiring the use of
optional protocol features, so it has to be assumed the operator
of an OCSP responder that requires signatures on OCSP request explicitly
desires the non-interoperability outcome.  I don't see a standardized
indication of acceptable certification_authorities for the signature
on the OCSP request to accompany the "sigRequired" OCSPResponseStatus,
so this policy can be expected to work only for extremely small groups
of RPs, matching the following preconditions:

    - all RPs in the PKI have implemented the optional protocol feature
      "signed OCSP requests"
    - all RPs in the PKI have out-of-band knowledge of certificate issuers
      acceptable to that OCSP responder for signing OCSP requests.
    - all RPs in the PKI have signing PKI credentials issued by one of
      those certificate issuers acceptable to the OCSP responder.

-Martin