RE: POLL: Nonce-specific error code for OCSP

["Michael Myers" <mmyers@xxxxxxxxx>]

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Denis Pinkas
> Sent: Thursday, October 16, 2003 12:34 AM
> To: Michael Myers
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
>
> Mike,
>
> > All,
>
> > I recently received permission from the chairs to
> poll the WG
> > against the following question.
>
> > Should we standardize an OCSP *V1* error code that enables a
> > responder to indicate its inability to respond to nonced
> > requests?
>
> > Please respond with either YES or NO.
>
> I would suggest to you provide a resumé of the
> advantages of this new error
> code (and disadvantages if not supported), so that
> people do not have to
> look back at that long thread on that topic to make
> up their opinion.
>
> Denis
>
> > Mike



A reasonable request.

In summary, we need to standardize the treatment of nonces when
nonces aren't supported.  RFC2560 is regrettably silent on the
point.  The need to do so is particularly acute in the context
of heterogeneous populations of clients and servers (i.e. not
operating under a single administrative authority).  Some may be
set up to use or support nonces and some may not.  The question
is of course moot for requests that don't contain nonces.

The issue is further complicated by the use of pre-produced
responses to achieve scalability through caching (i.e.
non-signing) servers.  A relay back to a master signing server
could work, but that doesn't seem to be a popular option.  So
that leaves us with two server-side options.  Either: 1) send
back a non-nonced response anyway with technical extensions; or
2) send back an error code.

Variations on option 1 have been discussed, with the likelihood
that an extended response syntax or equivalent technical
mechanisms will force a v2 and all that entails with regard to
IETF process.

Yet we also need to do something sooner about v1.  In this case,
an existing error could be designated or we could define a new
one that servers can send back in the event they don't support
nonces.  Absent a designated error code, it is predictable that
ad-hoc selections will be made to to address the issue with a
consequent reduction in Internet-wide OCSP interoperability and
security.

This poll is focussed on the narrower v1 issue ONLY. Should we
or should we not standardize a v1 error code? If this poll is
inconclusive, then I suppose we'll get into the heart of the
matter, which is whether it is acceptable in v1 to disregard a
client's nonce.  But let's leave those discussions to another
thread and first get a vote tally.

Mike