Re: OCSP response pre-production

[David Engberg <dave@xxxxxxxxxxxxxx>]

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