Sam Hartman wrote:
Martin Rex <mrex(_at_)sap(_dot_)com> writes:
Martin> http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
To be clear, I didn't comment on which error codes were overloaded to do
what. My point was simply that there needs to be a minimal set of
client behavior that is guaranteed to work (if permitted by responder
policy) with any responder. That's the level of interoperability we
generally require from our specs.
It sounds like Martin would like to be able to distinguish three client
behaviors:
1) Use less of the spec and send me a simpler request
2) I can't help you with this particular request
3) Please go away and never come back
That's a fine desire. In my opinion, it's also fine for us to decide
for interoperability, simplicity or other reasons that we're combining
all that into one error and clients don't get to make this distinction.
When the rfc2560 semantics of "unauthorized(6)" and the rfc5019 semantics
of "unauthorized(6)" are merged into one, then this error code ought
to be renamed to "whatever(6)", because it will be impossible for a
client to know what a server really meant! Whether an OCSP responder
is rfc2560 compliant or whether it adheres to rfc5019 subset can neither
be determined from the id-ad-ocsp AIA information of an X.509v3 certificate
nor from an OCSPResponse that conveys a responseStatus (6).
Why don't we add sensible, well-defined OCSPResponseStatus error code
now during rfc2560bis, and see how and when we can make appropriate
use of those in clients.
-Martin