I think that, if the responder is capable of understanding another hash (e.g. SHA-256), and has support for that built into its backend database, returning the CertID with those supported hashes is fine and good. IMO, there should be no prohibition on supporting alternative hash algorithms.
But it stands to reason that the number of potential hash algorithms will generally be greater than the ability of OCSP responders to support them (especially in the case of CAs pregenerating responses); so the more general question seems to be “what is the optimal way to signal that the OCSP responder does not understand, or does not have a valid confirmation for, a given CertID.hashAlgorithm?” Returning a response with an alternative CertID.hashAlgorithm (e.g. SHA-1) feels wrong; in order to validate the response, the client would have to recalculate the request using the “well known" hash algorithm - in which case, why didn’t it just send that query to the responder in the first place? RFC 6960, Section 4.4.7.2.2 states "the responder SHOULD still use the client request data during the selection of the pre-generated response to be returned” - which would indicate that selection of an alternative CertID (even if semantically identical to the request) is viewed poorly. “unauthorized” seems a valid view - it’s essentially saying “I don’t understand this Issuer specification”. Whether because of an unsupported hash algorithm, or a (name-hash, key-hash) value which does not map to a known issuer, it doesn’t really matter. From my personal view, “malformedRequest” is also an acceptable return value - the text in RFC6960 gives the explanatory text “Illegal Confirmation Request” - which doesn’t in itself mean that the client sent a syntactically invalid OCSP request - merely that the parameters specified in that request cannot generate a successful answer from the OCSP responder. So, from the original list of observed behaviours, 1, 4 and 5 seem OK by me. Regards, Neil > On 19 Sep 2019, at 16:23, Curt Spann via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > I am looking at this from an interoperability perspective and not security. > If a client is requesting a SHA256 hash for the issuerNameHash and > issuerKeyHash I don’t think the OCSP responder should be prohibited from > returning a response containing issuerNameHash and issuerKeyHash using > SHA256. I like the idea of agility for algorithms and it appears the RFCs > supports this by having a CertID.hashAlgorithm field. > > - Curt > >> On Sep 19, 2019, at 4:24 AM, Rob Stradling via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
