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 structure. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
