Re: DISCUSS: MUST reject in OCSPv1

[David Engberg <dave@xxxxxxxxxxxxxx>]

I agree that this is not a current problem that many people are seeing, 
because current OCSP use is primarily limited to small "internal" 
deployments where a one-size-fits-all security policy isn't an issue. 
If I'm only ever hitting one OCSP responder, a "require nonces from all 
servers" policy may be fine.

On the other hand, when people start using OCSP for real-world 
interoperability, the nonce-related options in all existing clients will 
likely be too limited.  For example, if ACME Amalgamated installs CAPI 
clients for its internal PKI users that are configured to "require 
nonces from every server," this client will immediately act up when apps 
try to verify SSL certs from Verisign if Verisign were to deploy a 
cache-based infrastructure.

Without a spec refinement to handle the broader interopability case, 
most people will probably just turn off nonce support across the board 
rather than trying to reconcile their internal PKI with external ones 
that they interoperate with.  Since I think nonces are actually negative 
for security on balance, I'm fine with this result, but I don't think 
this is the desired goal of everyone involved.


Liaquat Khan wrote:

> The situation "we would like to have nonces in OCSP requests as default,
> but if the server legitimately doesn't support nonces we are happy to
> forgo nonces or we will generate a fresh request without a nonce" is not
> that common in my opinion.  If such a case does exist, local policy will
> probably be also happy to choose to not include a nonce in the OCSP
> request message in the first place.
>
>