Re: OCSP response pre-production

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Florian,

> > [Florian]

> > > Client Type I) Given you have a client with the following behaviour:
> > > A) always includes a nonce into his request
> > > B) accepts responses without nonce

> > If a client Type I "accepts responses without nonce" (i.e. "B 
> > condition")then a nonce generated by the server is ignored by 
>>the client and thus does not help, and "do NOT allow
>>Client Type I operate securely".

> Why should the client *ignore* the nonce? The client will check the
> nonce when it is included in the response while simultaneous accepting
> responses without nonce. Although I have not tested it, I dont think any
> client out there that accepts nonce-less responses to his nonce-requests
> IGNORES the nonce. After all a mismatching nonce definitely indicates a
> replay attack while a response without nonce just indicates no
> protection against replay attacks.

No, this is not as simple. What you say is true, if only real-time responses 
are being used. Since we also want to allow for cached-responses, the story 
is a litte more complicated.

> This way the responder can decide wether to protect the client against
> replay attacks (through server-generated nonces).

> So allow me to define the behaviour of "Client Type I" more clearly:
> A) always includes a nonce into his request
> B) checks if the nonces match if the response included a nonce
> C) accepts responses without nonce

Not exactly. Proposed rephrasing for a "Client Type I":

 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 or if it
        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.

Denis