Thanks for raising this!
There some some slight past discussion in the CA/B Forum on this -
- as well
as a little during the SHA-1 deprecation discussions (
crypto agility discussions (
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 -
- 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. 22.214.171.124 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 126.96.36.199
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
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.