RE: DISCUSS: MUST reject in OCSPv1

["Ryan M. Hurst" <rmh@xxxxxxxxxxxxxxxxxxxxx>]

Comments in-line

-----Original Message-----
From: Michael Myers [mailto:mmyers@xxxxxxxxx] 
Sent: Friday, December 05, 2003 12:52 PM
To: Ryan M. Hurst; David Engberg
Cc: liaquat.khan@xxxxxxxxxxxx; 'Florian Oelmaier'; ietf-pkix@xxxxxxx
Subject: RE: DISCUSS: MUST reject in OCSPv1

> From: Ryan M. Hurst
> Sent: Friday, December 05, 2003 12:25 PM
>
> [rmh] But what prevents the nonce unsupported
>       response from being replayed?



While a caveated response can be replayed, it bears with it
unambiguous signed proof that the client's request for
anti-replay would not have been successful in the first place.

[rmh] Once again why does this matter, isn't that what you get by
getting the nonceless response back?

This is substantially different from replay of a nonceless
response captured from a server able and willing to support
nonces, but also able and willing to support non-nonced requests
(hence the capture and replay).
[rmh] But an attacker could just replay a response without this value,
how can this be relied upon?

In the former case, the replay protection is not there to begin
with and the server/service is being forthright about that.  Any
lawyer will tell you, full disclosure is good thing, especially
in the case when one has no contracted relationship with a
relying party.
[rmh] But if no client decision is being made off of this data, why
include it? Why break existing implementations?

In the latter case, anti-replay *is* available but the client is
being blocked from it by an attacker.  This is not so good.

Mike