RE: DISCUSS: MUST reject in OCSPv1

["Michael Myers" <mmyers@xxxxxxxxx>]

The fact still remains that Section 4.4.1 of RFC 2560 opens with
the sentence "The nonce cryptographically binds a request and a
response to prevent replay attacks."  The original intent of
this assertion is self-evident: nonces are to be incorporated by
servers.

Yet it is a fair observation that the relationship between
cached responses and nonced requests is underspecified,
particularly in the case of Internet-facing services receiving
requests from a heterogeneous population of clients over which
such services have no administrative control.

I chose nonceUnsupported as a candidate means of developing a
compromise solution to this issue based in part on prior list
dialog, including that below:

> From: David Engberg
> Sent: Thursday, October 02, 2003 12:23 PM
> Subject: Re: OCSP response pre-production
>
> If adding a new top-level error code is possible
> in v1, and adding a new response extension to
> indicate nonceUnsupported (or similar solution)
> is only possible in v2, then this may be the
> best course of action.

I saw how it was possible by cycling v1 at Proposed to get this
solution into v1 in a way that satisified all perspectives,
including that of the opening sentence, and yet not break the
installed base.  The core notion was that of a "caveated
response".  Looking back, had we addressed this issue during the
I-D phase of OCSP, I suspect we would have come up with
something very similar.

It enables secure on-the-fly client configuration on a
per-server basis while also providing as much OCSP value add as
possible.  Upon receipt of a caveated response, a clever client
could record this fact and not bother sending nonces to that
server again.

As proposed on this thread,
http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
we have six who agree to this path forward and two who disagree.
Perhaps a poll is in order to get conclusive on it.

Yes, sending back a plain nonceless response to a nonced request
is not conformant to this proposal.  But neither is it
conformant in spirit to the above 4.4.1 sentence.  My
expectation is that, no matter what we do here, this will
continue anyway as a de-facto market standard practice until
such time as the market dictates otherwise. e.g. somebody gets
burned.  In which case the official IETF standard will have the
solution in place.  By not taking this action, someone could
otherwise point back to the RFC and claim it is the RFC's fault
for being underspecified in this area.  Which is where we got
started over two months ago.

Mike