Re: OCSP response pre-production

[Jean-Marc Desperrier <jmdesp@xxxxxxx>]

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.