Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

 








[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]