|
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:
- 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.
- 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.
- 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
|