On Wed, 9 Mar 2016 21:40:32 +0100
Jakob Bohm <jb-mozi...@wisemo.com> wrote:

> 1. Use a non-CA OCSP certificate if the relevant clients are known to
>    support this aspect of the OCSP protocol (I don't know if any OCSP
>    clients, historic or otherwise, lack this ability).

Using a dedicated OCSP responder certificate is a common practice (518
of the responders I probed use one; only 52 do not), and was part of
the original RFC, so hopefully support for this is widespread among
OCSP clients.

> Such an OCSP certificate needs to be issued using the historic (and obsolete!)
> algorithms that were used for the certificates the OCSP is
> responding about, even though this technically violates fanatical
> readings of modern algorithm bans.

The BRs explicitly permit signing OCSP responder certificates with SHA-1
until January 1, 2017, so bringing a new SHA-1 OCSP responder certificate
online before then would not violate any reading of the BRs.

> 2. Find a way to add OCSP responder chosen random data in each OCSP
>    response.  And preferably lots of bits, e.g. 256 or more bits with
>    current technology.  This does not preclude the use of precomputed
>    pre-signed responses for each known single certificate query, as
>    the random value only needs to change when the rest of the response
>    changes, so a pre-computed response would contain a pre-computed
>    random value.

Pre-signed responses do not need any random data since they don't contain
any attacker-controlled input.

Just using pre-signed responses (equivalently, preventing any attacker
control over the response) is a much simpler fix than trying to stuff
entropy into the OCSP response.  Are there clients that will choke if
they receive a response without the expected nonce?

dev-security-policy mailing list

Reply via email to