RE: DISCUSS: MUST reject in OCSPv1

["Ambarish Malpani" <ambarish@xxxxxxxxxxx>]

I agree completely with Liaquat.

Ambarish

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Liaquat Khan
> Sent: Friday, December 05, 2003 4:43 AM
> To: 'David Engberg'
> Cc: 'Ryan M. Hurst'; 'Florian Oelmaier'; ietf-pkix@xxxxxxx
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
> 
> 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.
> >
> >  
> >
> 
> 
> 
>