This prompted me to dig up more information of this old issue. Here is the 
issue in our tracker:

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.

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 

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.

On Friday, October 4, 2019 at 8:38:41 PM UTC+2, Jeremy Rowley wrote:
> (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 <> On 
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Friday, October 4, 2019 12:35 PM
> To: Tomas Gustavsson <>; 
> 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 <> On 
> Behalf Of Tomas Gustavsson via dev-security-policy
> Sent: Friday, October 4, 2019 1:45 AM
> To:
> 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:
> > 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 ( 
> > ) and 
> > crypto agility discussions ( 
> > ), 
> > 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 -
> > - 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. 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 
> > 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.
> _______________________________________________
> dev-security-policy mailing list
> _______________________________________________
> dev-security-policy mailing list

dev-security-policy mailing list

Reply via email to