(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
