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

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

Reply via email to