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

Re: OCSP response pre-production (was RE: POLL: Use of nonces in OCSP)




Alex,


I support the idea, ... with some changes.

Hi Russ,

Agreed, however we do not have control of all OCSP clients.  In the case
where a responder is using pre-produced responses and can't respond to a
request with a nonce, the responder can do one of two things:

1) Send the pre-produced response without the nonce
2) return a malformedReqest OCSPResponseStatus

I feel that the first choice is better as it gives clients a chance to
accept the response, even though it does not contain a nonce.

For clients that require a nonce not matter what the outcome of both optoins
is the same...i.e. the response is rejected.

If a nonce is present in the request then the server SHALL send back a response with the same nonce, if it is not using cached pre-produced responses.


If the server is using cached pre-produced responses, then he MAY send back a response with or without a nonce. In such a case, the client SHOULD check the freshness of the response using the producedAt field from ResponseData which is only possible if the client has a local trusted clock.

New text proposal:

    "Upon receipt of a request containing a nonce,
     a responder SHALL include the value of such nonce
     in the production of the associated response,
     if it is not using cached pre-produced responses.
     If the responder is using cached pre-produced responses,
     then it MAY send back a response with or without a nonce."

     "Clients that elect to include a request nonce
     MAY reject responses that fail to include
     the client's nonce from the associated request.
     Alternatively they MAY ignore the nonce field and accept
     the response, if they have a local trusted clock and are
     satisfied with the time difference between their local
     trusted clock and the producedAt field from ResponseData".

Denis

Alex





-----Original Message-----
From: Russ Housley [mailto:housley@xxxxxxxxxxxx]
Sent: Friday, September 26, 2003 9:31 AM
To: Deacon, Alex
Cc: ietf-pkix@xxxxxxx
Subject: RE: POLL: Use of nonces in OCSP


Alex:


To support such an environment, the client should not include a nonce in the request. Do you have control over the clients? If so, then the change will not cause you a problem.

Russ

At 05:12 PM 9/25/2003 -0700, Deacon, Alex wrote:



Hi Mike,

Although this new text would not break the existing VeriSign

OCSP code base,


it will break the (soon to be deployed) next generation of our OCSP
services. These services are designed to serve PKI's with a

high volume of


RP's (such as TLS server and code signing CA's) and rely on response
pre-production, distribution and caching through out the network.

In such a deployment it is not possible for a responder to

include a nonce


in the response.

Regards,
Alex





-----Original Message-----
From: Michael Myers [mailto:mmyers@xxxxxxxxx]
Sent: Wednesday, September 24, 2003 7:38 AM
To: ietf-pkix@xxxxxxx
Cc: Stephen Kent; Ambarish Malpani
Subject: POLL: Use of nonces in OCSP



All,

Recent list traffic indicates there might be some confusion out
there regarding the use of nonces in OCSP.  This is
understandable since RFC 2560 is regrettably silent on the
point.  It seems that most folks correctly inferred our original
intent but absent normative language there's a possibility that
some may not.

After some discussion with the Chairs and the AD, we will take
action to clarify our original intent in one fashion or another
but first need to poll IMPLEMENTORS to determine how many, if
any, implementations of OCSP would break as a consequence of the
following normative language:

   "Clients that elect to include a request nonce
    SHALL reject responses that fail to include
    the client's nonce from the associated request."

   "Correspondingly, upon receipt of a request
    containing a nonce, a responder SHALL include
    the value of such nonce in the production of
    the associated response."

IMPLEMENTORS ONLY, please, and just yes/no or equivalent.

Mike