RE: OCSP response pre-production

["Michael Myers" <mmyers@xxxxxxxxx>]

Dave,

I used the pop-up as an example.  It could very well be a
one-time configuration issue.   Or, as Jean-Marc Desperrier
suggested, all this hoo-hah could be a moot point when reduced
to practice.  In any case, specific software design features are
out of scope.

As you point out, caching servers today send back a non-nonced
response to a nonced request because 2560 is regrettably silent
on the point. 10 of 12 implementors seem to have understood the
principles of nonce use anyhow.  If that isn't rough consensus
and running code, I don't know what is.  Despite that, if this
WG, its chairs and our AD wish to condone the practice of
ignoring a nonce, I'd be happy to abide by that decision.

Mike



> -----Original Message-----
> From: David Engberg [mailto:dave@xxxxxxxxxxxxxx]
> Sent: Thursday, October 02, 2003 9:41 AM
> To: Michael Myers
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: OCSP response pre-production
>
>
>
> If the only change is an error code in the unsigned
> portion of the
> protocol, there is no way for a client to
> automatically tell that the
> responder is intentionally configured to never send nonces.
>
> This prevents a client from choosing this
> automatically-enforced
> security policy:
>
>    Require nonce from servers that support nonces.
>    Accept responses without nonces from trusted
> responders that
>       securely indicate they won't ever provide a nonce.
>
> Like you said, a solution based only around an
> unsigned error code would
> require explicit user acceptance for each responder,
> while the most
> users don't have the faintest idea what nonces (or
> OCSP for that matter)
> are.  The pop-up example you listed may as well be in
> Latin for the
> majority of users.
>
> If nothing changes in the spec, caching-only servers
> will continue to
> send back a response without a nonce.  They won't
> send back any error
> because this is not an error under the current RFC.
>
>
> Michael Myers wrote:
> >
> >
> > If we don't define a nonce-specific error, it's
> predictable that
> > client developers will choose one of the existing 5 unsigned
> > error values in order to pop up a dialog that says,
> essentially,
> > "You used a nonce and received an error.  If you want to try
> > again not using nonces, click here."
> >
> > It doesn't matter much which error; any one will do
> in order to
> > discover if nonce use is the problem.  In fact if nothing
> > changed I'm wondering what the server side *would*
> send back?
> > I've recently seen suggestions on this list for
> > malFormedRequest, internalError and unauthorized.
> >
> > Not defining a nonce-specific error value escapes nothing.
> > Clients can today enable relying parties to achieve their
> > intended goals via error-triggered nonce capability
> discovery.
> >
> > Mike
> >
> >
> >
>
>