I'm not aware of any requirement that demands that OCSP responders support SHA-256 for CertID.hashAlgorithm or of any requirement that forbids this. Therefore, I think 1, 2 and 4 are all acceptable responses to an OCSP request whose CertID.hashAlgorithm is SHA-256.
SHA-1 is the defacto requirement for CertID.hashAlgorithm, and I would (still ) prefer to see SHA-1 required and all other hash algorithms forbidden. Supporting stronger hash algorithms for CertID.hashAlgorithm would not lead to any security gain, but it would inflict pain on those CAs that need to regularly pregenerate OCSP responses (see ) for all unexpired leaf certificates.  https://cabforum.org/pipermail/public/2013-November/002453.html  https://tools.ietf.org/html/rfc6960#section-184.108.40.206.2 On 19/09/2019 01:09, Curt Spann via dev-security-policy wrote: > In the WebPKI ecosystem I have seen a wide range of OCSP responses for OCSP > requests using SHA256 for the issuerNameHash and issuerKeyHash. I have > observed the following types of OCSP responses: > 1. “good” response with issuerNameHash and issuerKeyHash using SHA256 > 2. “good” response with issuerNameHash and issuerKeyHash using SHA1 > 3. “unknown” response containing the correct SHA256 issuerNameHash and > issuerKeyHash but signed with an incorrect OCSP signing cert (chains to > different authority) > 4. “unauthorized” response > 5. “malformedrequest” response > > I would like to have a discussion with the community about what is thought to > be the correct response. Of the various responses I have observed I think the > correct response is number 1. I would also like to know if others have seen > other variants of OCSP responses for request using SHA256 for the > issuerNameHash and issuerKeyHash. > > Supporting info > RFC 6960: https://tools.ietf.org/html/rfc6960 > - 4.1.1. ASN.1 Specification of the OCSP Request > RFC 2560: https://tools.ietf.org/html/rfc2560 > - 4.1.1 Request Syntax > > - Curt -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy