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

["Miller, Timothy J." <[e-mail]>]

Clients concerned with OCSP response freshness can always insist on nonces, and fall back on CRLs if the OCSP service won't support them.

-- Tim


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Jean-Marc Desperrier
>Sent: Friday, March 26, 2010 4:40 AM
>To: [e-mail]; [e-mail]
>Cc: [e-mail]
>Subject: Re: [pkix] Possible revocation delay issue with TLS stapling
>
>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.
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix