On Wed, Mar 9, 2016 at 12:40 PM, 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).  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.
> 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.

The OCSP spec has tons of places where extensions are supported.  For
example nonces are not part of the core message but are a type of
extension.  If OCSP clients properly ignore unknown extensions then
random data could be included in a newly defined extension.
Additionally the response is technically a sequence of
SingleResponses.  RFC 6960 says:

"The response SHOULD NOT include any additional
   SingleResponse elements, but, for example, OCSP responders that
   pre-generate status responses might include additional SingleResponse
   elements if necessary to improve response pre-generation performance
   or cache efficiency (according to [RFC5019], Section 2.2.1)."

This suggests another solution would be add a random SingleResponse as
the first responses member.  SingleResponse has plenty of room for
random bytes while still ending up with a syntactically valid
dev-security-policy mailing list

Reply via email to