-Original Message-
> From: dev-security-policy 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
>
&
12:35 PM
To: Tomas Gustavsson ;
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
, 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
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
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
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.
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'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
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
9 matches
Mail list logo
