I was pointed to this interesting discussion. We were forced to support requests with SHA256 in CertID back in 2014. Not for any relevant security reasons, just because some stubborn auditors saw a red flag on the mentioning of SHA-1.
We've implemented it by having both hashes in the lookup table where we check for issuer when a response comes in. What to have in the response was an interesting topic. In the response we use the same certID that the client sent. I would expect that any client if checking CertID in the response would expect it to match what they send. I'm suspicious of adding two SingleResponse in the response, one for each CertID. - Clients are used to one response, they may fail verification if the first one doesn't have the same CertID - When auditors that requiring SHA3, shall we add three? That approach does not seem agile. - It increases the size of responses, we've been told before about the desire to keep responses as small as possible (typically to fit in a single etehrnet frame) Regards, Tomas On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote: > Thanks for raising this! > > There some some slight past discussion in the CA/B Forum on this - > https://cabforum.org/pipermail/public/2013-November/002440.html - as well > as a little during the SHA-1 deprecation discussions ( > https://cabforum.org/pipermail/public/2016-November/008979.html ) and > crypto agility discussions ( > https://cabforum.org/pipermail/public/2014-September/003921.html ), but > none really nailed it down to the level you have. > > Broadly, it suggests the need for a much tighter profile of OCSP, either > within policies or the BRs. Two years ago, I started work on such a thing - > https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large CA > suggested it would take them years to even implement that, and it wouldn't > have covered this! > > I can't see #3 being valid, but I can see and understand good arguments for > #1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960. > > The question about whether #2 is valid is about whether or not a client > should be expected to be able to match the CertID in the > OCSPRequest.requestList to the CertID in the > OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that the > response MUST include a SingleResponse for each certificate in the request, > but may include additional, and so a client encountering a SHA-1 computed > CertID in response to a SHA-256 CertID would have to recompute all the > CertIDs to see if it matched. On the other hand, RFC 5019 2.2.1 states that > "In the case where a responder does not have the ability to respond to an > OCSP response containing an option not supported by the server, it SHOULD > return the most complete response it can." > > A different question would be whether said responder, in response to a > SHA-1 request, can and/or should provide a response with both a SHA-1 > computed CertID AND a SHA-256 computed CertID. This would improve the > pre-generation performance that Rob was concerned about, and allow both > SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse. > > However, one concern with the pre-generation approach is that 4.2.2.3 > requires that the response MUST include a SingleResponse for each > certificate in the request. RFC 5019 2.1.1 limits clients using that > profile to only include one Request in the OCSPRequest.RequestList (via a > MUST). So should responders be permitted to reject requests that include > multiple? Or should they be required to do online signing? Similar to > extensions. > > This suggests we should actually nail down and define what we expect, > perhaps as a clear processing algorithm for how a Responder must respond to > various requests. I suspect that "What we want" is a profile of RFC 5019 > that nails down the SHOULD / SHOULD NOT and MAY / MAY NOT behaviours from > 5019, as relevant to the Web PKI, and describe a processing algorithm that > can be used to both assess compliance and test implementation. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
