RE: OCSP response pre-production

["Florian Oelmaier" <oelmaier@xxxxxxxxxxx>]

I think a client should definitely and in every case reject a response
with a mismatching nonce. This is covered in RfC2560 in its current
form: mismatching nonce => reject.

So allow me to rephrase again based on your proposal:

A) always includes a nonce into his request;
B) checks the nonce in the response:

     - if it matches with the nonce from the request, then accept
       the response (pending other checks),

     - if it does not match with the nonce from the request, then
       reject the response

     - if nonce is not present, then are a local trusted time 
       available and a policy for cache responses both available ?
 
          - if both a local trusted time is available and there exists
            a policy for cache responses, then compare the time
            difference between that local trusted clock and the
            producedAt field from ResponseData. If that time difference
            is below the limit stated by that policy, then accept the
            response (pending other checks).

          - if not, then reject the response.


[Additionally we add some checks: 

i) if nextUpdate is present and is lower than the current date from our
trusted clock before sending the request, we detected a clock problem in
our "trusted" clocks.

ii) if thisUpdate is too old for our limit stated in the policy we
reject the answer, too.

iii) additionally some sanity checks: thisUpdate<=producedAt<=nextUpdate

I have to double check, but I think thats all we do.]