> I would say the periodic-request aspect of it is pretty trivial; you add a
> timer to the event loop that expires in some configurable amount of time,
> e.g. a bit before the last OCSP response expires, and you cache the result
> until it expires or a more recent result overwrites it. Given that the
> overhead of making a single OCSP request for the cert inside HAProxy is very
> low, you can easily do this every few minutes with no perceivable overhead.
> Obviously some logic re: failing requests and retrying has to be implemented,
> which amounts to nothing more than a formulation for how much time to wait
> until retrying again.

I confirm that this part it clearly nothing.

> The user should also be able to configure whether to
> deliver an expired OCSP response or none at all in the case that an upstream
> OCSP response cannot be received by the time the currently cached response
> expires.

That's one of the points of attention, I agree.

> A single timer and single cache slot are used for each certificate chain. The
> timer is reset with a new value when:
> - a request fails; in this case we need
>   to use our retry/backoff algorithm to decide how long to wait before
>   retrying;
> - a request succeeds; in this case we need to use our expires algorithm,
>   which can be parameterized over the expiration time of the OCSP response, to
>   decide how long to wait before trying to get a fresh response.

Hmmm OK it's per certificate... Obviously in fact. So that probably means
some funny mechanisms to connect to various places depending on the cert
chain (eg: for those connecting via proxies, etc...).

> One thing to keep in mind is that OCSP stapling in many libraries has (or
> had, at one point) buggy or nonexistent support for OCSP payloads containing
> multiple certificates,

That's a very useful and interesting piece of information.

> and a bit of research should be done prior to
> implementation to discover the current state of the world in this regard.

I agree!

> I believe the official word at one point was that OCSP stapling of chains
> should be accomplished by including the entire chain in the OCSP request,
> delivering that compound OCSP response via the TLS Certificate Status Request
> extension.

And do you know how large this could be for average web sites ? Maybe
there is a cross-over point where doing so has a more negative impact
than letting the client check by itself ?

Thanks for your comments and suggestions!
Willy


Reply via email to