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
