RE: OCSP response pre-production

["Ambarish Malpani" <ambarish@xxxxxxxxxxx>]

I agree.

A

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Jean-Marc Desperrier
> Sent: Thursday, October 02, 2003 2:19 AM
> To: ietf-pkix@xxxxxxx
> Subject: Re: OCSP response pre-production
> 
> 
> 
> David Engberg wrote:
> > I would prefer a signalling mechanism that does not require two 
> > round-trip communications to establish nonce support, 
> 
> May I say we should *NOT* aim to fullfill this ?
> 
> If we don't, everything is easy.
> 
> Clients that requires freshest response send a nonce, and get back an 
> error if it's not possible to give freshest response.
> Client that don't require it, send no nonce.
> 
> Client that would like it, but don't require it, make a round trip, and 
> cache the fact the server can't supply freshest response, so they do the 
> round trip only once.
> 
> My opinion is :
> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. Even if it's the case, there won't be so many different OCSP 
> responders, and it won't take long to discover they don't provide fresh 
> answers.
> 
> - The global security brought by trying to get a fresh response, but 
> being ready to accept a non-fresh one, can hardly be said to be any 
> different from directly accepting a non-fresh one. If the system was 
> audited, I'm doubtful auditors would think it brings any real difference.
> 
> So I don't see a reason to go such lengths to support this.
>