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