Subject: Error Codes in OCSPv1

From: "Andrew Sciberras" <[email-masked]>
Date: Mon, 10 Dec 2001 09:48:30 +1100

G'day,

I'm not sure if this has been discussed before, so please excuse me if it
has.

Of the OCSPResponseStatus codes defined in RFC2560 I am unsure what should
be used if the following errors occur:
  a.. The OCSP Server receives a signed request that it cannot verify due to
lack of information. In the case where the OCSP Server requires all requests
to be signed, I would imagine that the sigRequired or unauthorized errors
messages could be used as the ResponseStatus. However, neither of these
responses provide the Client with any sort of indication as to what the
problem is.

  b.. In Section 4.1.1, it is stated that the issuerNameHash (and
issuerKeyHash) are hashed with an algorithm identified in hashAlgorithm.
Section 4.3 then states that an OCSP Server SHALL support SHA1. From what I
can tell, it would be reasonable for Clients to use any hashing algorithm
they like. If the Server received a request that used a hash algorithm that
it didn't support, what should be returned? All I can really think of is
successful ResponseStatus and an unknown CertStatus. However, I feel that a
successful ResponseStatus should not be used if the OCSP Server cannot fully
understand/decode/process the request which it is given.

  c.. Unsupported Request Version. If the version number is unsupported is
it appropriate to return the malformedRequest status?
Each of the scenarios described above could fit into some of the preexisting
status codes, however in each case the Client would have created a request
that is correct, but received a reply which indicates otherwise. Perhaps
another error response needs to be included that lets the OCSP Client know
that they have not done anything wrong, but should try another OCSP Server,
since the one they are currently using cannot handle the request
appropriately.

Any feedback on this would be appreciated..

Andrew Sciberras
Software Engineer
Adacel Technologies Ltd