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. 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 <dev-security-policy-boun...@lists.mozilla.org> On > Behalf Of Jeremy Rowley via dev-security-policy > Sent: Friday, October 4, 2019 12:35 PM > To: Tomas Gustavsson <tomasshred...@gmail.com>; > mozilla-dev-security-pol...@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-policy-boun...@lists.mozilla.org> On > Behalf Of Tomas Gustavsson via dev-security-policy > Sent: Friday, October 4, 2019 1:45 AM > To: mozilla-dev-security-pol...@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: > > 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. > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
