Sam Hartman wrote: > Martin Rex wrote: >> Oh, here is a message from the Security AD back then (Sam >> Hartman), commenting on requirements for rfc2560bis (the I-D >> under last call right now!): >> >> 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. True. It was the Security co-AD Russ Housley who indicated _early_ during the discussion of that draft (2.5 years after it had been adopted as a WG item) that he considered some of the suggested abuses of existing error codes "unacceptable": http://www.ietf.org/mail-archive/web/pkix/current/msg03570.html So far, I haven't found any arguments that could reasonably invalidate Russ' initial assessment on the "unacceptable" the error code abuse, i.e. any kind of transparent trade-off and the facts it could be based on. Looking as Russ' comment again, I check the documents again on the exact behaviour required from an rfc5019 server when receiving an OCSP request with a requestList. Myself, I'm surprised and confused by the answer: the rfc5019 server is prohibited from returning an error! rfc2560 neither provides and option nor an error code to refuse a response based on the presence of multiple entries in request list. The limit of a single entry in the requestList ist *CLEARLY* limited to clients conforming to the rfc5019 profile, it is neither limited to the requests sent to rfc5019 servers, nor does it apply to rfc5019 servers themselves -> "this profile ensures interoperability with a fully conformant OCSP 2560 client": http://tools.ietf.org/html/rfc5019#page-4 End of Section 1: In the case where out-of-band mechanisms may not be available, this profile ensures that interoperability will still occur between a fully conformant OCSP 2560 client and a responder that is operating in a mode as described in this specification. 2.1.1. OCSPRequest Structure OCSPRequests conformant to this profile MUST include only one Request in the OCSPRequest.RequestList structure. Other than what I had assumed from Russ' message about unacceptable error code abuse, rfc5019 does not define what kind or error code to (ab)use if a request contains more than one entry in requestList, and contains this explicit guidance: http://tools.ietf.org/html/rfc5019#section-2.2.1 2.2.1. OCSPResponse Structure In the case where a responder does not have the ability to respond to an OCSP request containing a option not supported by the server, it SHOULD return the most complete response it can. For example, in the case where a responder only supports pre-produced responses and does not have the ability to respond to an OCSP request containing a nonce, it SHOULD return a response that does not include a nonce. But when there are multiple entries received in a requestList from a "fully conformant OCSP 2560 client", to which rfc5019 allegedly ensures interoperability, then the option to return "unauthorized" to indicate inability to obtain authoritative information, and results in self-contraditory design. I strongly believe this stuff needs some housekeeping applied. The currently proposed minimal change of the description for the "unauthorized" error code in rfc2560bis is only going to make the mess worse, this is neither a solution, nor an improvement to anything. -Martin