> I would note that we could also combine these responses.  For example, we
> might require that CAs retire SHA-1 for OCSP with a long-ish horizon, but
> require them to use constrained OCSP certs basically ASAP.
> Of course, if we could just turn off SHA-1 for OCSP, that would be
> fantastic.  Do any CAs on the list know of blockers on making this switch
> basically now?  E.g., are there client stacks that support SHA-2 for
> verification, but not for OCSP?  (Firefox is obviously fine for both.)
> --Richard

I know of one blocker: Microsoft. Their TechNet article at aka.ms/sha1 says 
that CAs are allowed to use SHA-1 and SHA-2 for OCSP signing certs and OCSP 
responses, to allow continued support for XP SP1 and 2, and Server 2003. Using 
SHA-2 only for OCSP signing certs and OCSP responses will break those platforms.

The TechNet article is about Authenticode code signing and timestamping, but I 
think most CAs use the same roots (but different intermediates) to issue TLS 
and Code Signing certs. The current discussion in the CABF public list about 
what's in scope and what's not in scope is relevant here. If the BRs are scoped 
to include everything signed under certain roots, that may pull in code signing 
certs, timestamping certs, and CRLs and OCSP responses for code signing certs.
dev-security-policy mailing list

Reply via email to