OCSP responder support for SHA256 issuer identifier info

[Curt Spann]

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]

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 [1]) 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 [2]) for all unexpired
leaf certificates.


[1] https://cabforum.org/pipermail/public/2013-November/002453.html

[2] https://tools.ietf.org/html/rfc6960#section-4.4.7.2.2

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

[Curt Spann]

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-secur...@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.
>
> SHA-1 is the defacto requirement for CertID.hashAlgorithm, and I would
> (still [1]) 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 [2]) for all unexpired
> leaf certificates.
>
>

> [1] https://cabforum.org/pipermail/public/2013-November/002453.html <https://cabforum.org/pipermail/public/2013-November/002453.html>
>
> [2] https://tools.ietf.org/html/rfc6960#section-4.4.7.2.2 <https://tools.ietf.org/html/rfc6960#section-4.4.7.2.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
> dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy <https://lists.mozilla.org/listinfo/dev-security-policy>

[Neil Dunbar]

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

[Ryan Sleevi]

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.

[Tomas Gustavsson]

I was pointed to this interesting discussion. We were forced to support requests with SHA256 in CertID back in 2014. Not for any relevant security reasons, just because some stubborn auditors saw a red flag on the mentioning of SHA-1.

We've implemented it by having both hashes in the lookup table where we check for issuer when a response comes in.

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect that any client if checking CertID in the response would expect it to match what they send.

I'm suspicious of adding two SingleResponse in the response, one for each CertID.
- Clients are used to one response, they may fail verification if the first one doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not seem agile.
- It increases the size of responses, we've been told before about the desire to keep responses as small as possible (typically to fit in a single etehrnet frame)

Regards,
Tomas

[Jeremy Rowley]

The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC 6960. The requirements do not specific which RFC to follow when processing requests, but I think you can imply that either one is required, right?

Section 2.1.1. specifies that:
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values. Anyone implementing the BRs would expect SHA1 for both fields. Where does the requirement to support SHA256 come in? As Ryan mentioned, there was some discussion, but it seems like there was nothing settled. I'd support a ballot clarifying the profile, but I don't understand the value of requiring both SHA1 and SHA2 signatures for OCSP. Doesn't it just make OCSP more cumbersome?

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Tomas Gustavsson via dev-security-policy
Sent: Friday, October 4, 2019 1:45 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: OCSP responder support for SHA256 issuer identifier info

I was pointed to this interesting discussion. We were forced to support requests with SHA256 in CertID back in 2014. Not for any relevant security reasons, just because some stubborn auditors saw a red flag on the mentioning of SHA-1.

We've implemented it by having both hashes in the lookup table where we check for issuer when a response comes in.

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect that any client if checking CertID in the response would expect it to match what they send.

I'm suspicious of adding two SingleResponse in the response, one for each CertID.
- Clients are used to one response, they may fail verification if the first one doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not seem agile.
- It increases the size of responses, we've been told before about the desire to keep responses as small as possible (typically to fit in a single etehrnet frame)

Regards,
Tomas

On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote:

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-security-policy

[Jeremy Rowley]

(And, for the record, none of that legacy infrastructure that would Ryan mentions taking years to update exists anymore. Yay for shutting down legacy systems!)

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Friday, October 4, 2019 12:35 PM
To: Tomas Gustavsson <tomass...@gmail.com>; mozilla-dev-s...@lists.mozilla.org
Subject: RE: OCSP responder support for SHA256 issuer identifier info

The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC 6960. The requirements do not specific which RFC to follow when processing requests, but I think you can imply that either one is required, right?

Section 2.1.1. specifies that:
Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values. Anyone implementing the BRs would expect SHA1 for both fields. Where does the requirement to support SHA256 come in? As Ryan mentioned, there was some discussion, but it seems like there was nothing settled. I'd support a ballot clarifying the profile, but I don't understand the value of requiring both SHA1 and SHA2 signatures for OCSP. Doesn't it just make OCSP more cumbersome?

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Tomas Gustavsson via dev-security-policy
Sent: Friday, October 4, 2019 1:45 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: OCSP responder support for SHA256 issuer identifier info

I was pointed to this interesting discussion. We were forced to support requests with SHA256 in CertID back in 2014. Not for any relevant security reasons, just because some stubborn auditors saw a red flag on the mentioning of SHA-1.

We've implemented it by having both hashes in the lookup table where we check for issuer when a response comes in.

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect that any client if checking CertID in the response would expect it to match what they send.

I'm suspicious of adding two SingleResponse in the response, one for each CertID.
- Clients are used to one response, they may fail verification if the first one doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not seem agile.
- It increases the size of responses, we've been told before about the desire to keep responses as small as possible (typically to fit in a single etehrnet frame)

Regards,
Tomas

On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote:

[Tomas Gustavsson]

This prompted me to dig up more information of this old issue. Here is the issue in our tracker:
https://jira.primekey.se/browse/ECA-3149

Looking back in my records it's not only a local jurisdiction auditor that enforced SHA-256. We also received several request from Web PKI CAs to implement SHA256 support in CertID. Some sparked by the mozilla issue to accept SHA256 based CertID in responses.
https://bugzilla.mozilla.org/show_bug.cgi?id=663315

There was a discussion on the RFC compliance back then, noting the differences between RFC6960 and 5019. RFC5019 is from 2007 though, and we are no strangers here to extending old RFCs. I think it is a valid, deliberate, violation of RFC5019 to support new algorithms.

It is a fact that when supplying to many different jurisdictions, private PKIs as well as Web PKI. SHA-256 must be supported.
The current approach has worked flawless since 2014, and I think it's a reasonable approach. I agree with Curt that #1 is correct in a generic perspective, but #4 is also valid and compliant with RFC509 2.2.3. Even #5 as well.

Standardizing clients on SHA-1 is fine, as RFC5019 says. Servers should be allowed to support SHA-256 (or other algorithms) to not complicate configuration and infrastructure even further.