Sam Hartman wrote: > Martin Rex <mrex@xxxxxxx> 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