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