RE: DISCUSS: MUST reject in OCSPv1

["Liaquat Khan" <liaquat.khan@xxxxxxxxxxxx>]

It's interesting what you say about "one-size-fits-all".  My view is you
have to look at things from the RPs point of view, i.e. as a relying
party, I only care what's best for me.  Therefore either nonces are
important to me or they are not (I don't particularly care whether OCSP
responder's support them or not).  

Therefore from a RP perspective a single security policy is probably
want you do want.  Also from a security perspective, you don't want to
make special cases unless you think that communication between that
particular server is secure against such threats and hence the
protection is not required.  

I think it is sufficient to make OCSP clients configurable on whether to
include a nonce or not (since the protocol already identifies it as an
optional item) and then leave it up the local administrator to define
what suits them according to their local security policy.  I should add
though that if you include a nonce in the request you MUST reject a
response if it doesn't include a nonce (or a correct one).  

Regards,
LK


-----Original Message-----
From: David Engberg [mailto:dave@xxxxxxxxxxxxxx] 
Sent: 05 December 2003 12:15
To: liaquat.khan@xxxxxxxxxxxx
Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; ietf-pkix@xxxxxxx
Subject: Re: DISCUSS: MUST reject in OCSPv1


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.
>
>  
>