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. > > 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-security-policy@lists.mozilla.org > <mailto:dev-security-policy@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > <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
