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 

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 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 

“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.



> 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

Reply via email to