Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling

[Jean-Marc Desperrier <[e-mail]>]

Sean Leonard wrote:
> 2.(a) Your suggestion says that "servers" must include this extension in
> requests. How does the OCSP responder verify that the requester is a
> "server"? It cannot. So, if the CA is concerned about the staleness
> problem, why not just update OCSP information for all OCSP requests on a
> shorter interval?

The operational cost of the short interval is higher.

So with that extension the server is saying : I'm highly sensitive *and* 
I'll optimize your network load, therefore trying to optimize your costs 
by giving me a long lived response is not the optimal strategy. Please 
give me a truer response of when you'll really be able to have fresher info.

What you write in details later is true, this is just an optimization, 
different strategy could be used to not need it, and it will work only 
if the client checks this extension.

One thing I can confirm is that, as often the next CRL is generated 
earlier that the next update in the CRL, I've seen one actual CA case 
where the policy is such that getting the latest CRL *could* get you a 
fresher info than getting an OCSP token.
So this is a specific case where the CA could make sure the staple OCSP 
request always hits the very latest CRL, whereas there's an interval 
where standard OCSP request are not yet updated to it, and using a still 
trustworthy (earlier than next update) CRL but not actually the very 
latest produced CRL.

So the question is just, is this sufficiently useful to deserve being 
added to the standard ?

Just one more thing, I'm thinking now that one strategy for the server 
can be to guarantee a 20 ms response delay on standard requests, but 
have a 1 or 2 seconds delay for a staple ready answer. It's then up to 
the client to decide if he wants slow but best, or fast but maybe less 
fresh.