Re: [TLS] Justification

["Brian Smith" <[e-mail]>]

Adam Langley wrote:
> On Wed, May 12, 2010 at 11:47 AM, Brian Smith <[e-mail]> wrote:
> I don't think that a caching mechanism based on hashing the OCSP responses is
> going to be optimal for this. A different caching mechanism that allows the
> client to ask specifically for only *newer* (not just *different*) OCSP responses
> would be much better.
> 
> The specific case that I'm worried about is a client connecting to a
> server for which the previously cached OCSP responses have expired.
> 
> As an example, consider a server which returns two certificates: 806
> and 807 bytes long. The OCSP responses for these certs are 1085 bytes
> long. So the total return is 3783 bytes, not including the overhead of
> the ServerHello etc. This is very close to the three packet limit.

Yes, I understand. But, just because the server has a different OCSP response, doesn't mean that it's OCSP response is better than the cached one. For example, two responses could have different producedAt times but the same thisUpdate/nextUpdate times. Or, even thisUpdate might be slightly newer, but not enough to make it worthwhile to download it. AFAICT, optimally the client would ask for an OCSP response with thisUpdate >= X, where X is some time significantly later than its cached OCSP response's thisUpdate but before its cached OCSP's responses nextUpdate.

At any rate, I think it would be better to discuss the optimal way of caching OCSP responses first, independent of syntax. Then it would be clear whether this syntax or another one would be best.

Regards,
Brian