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