[cabfpub] Allowing SHA-1 OCSP and CRL signatures past 2016

[Bruce Morton]

Can we ensure that the ballot covers both:

-        Signing OCSP certificates with a SHA-1 hash after 31 December 2016

-        Signing OCSP responses with a SHA-1 hash after 31 December 2016

Thanks, Bruce.

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Wayne Thayer via Public
Sent: Friday, October 21, 2016 7:51 PM
To: CABFPub <public at cabforum.org>
Subject: [cabfpub] Allowing SHA-1 OCSP and CRL signatures past 2016

One of the concerns raised about SHA-1 deprecation at the recent Face-to-face meeting was signing OCSP responses for SHA-1 subscriber and intermediate certs that remain unexpired after Jan 1, 2017. CAs need to continue to provide OCSP responses and CRLs for these certs, and would ideally continue to sign those with SHA-1 in order to allow clients (not necessarily browsers) that do not support SHA-2 to properly validate the certificates until they expire.

I don't believe the BRs forbid CRLs signed with SHA-1, but section 7.1.3 does forbid CAs to issue new SHA-1 OCSP Signing certificates after Jan 1, 2017:

CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017

I believe the reason for this prohibition is that OCSP responses become an attack vector under the following conditions, as described in the Mozilla dev-security-policy thread from March titled "OCSP Responders Are An Attack Vector For SHA-1 Collisions":

1.      The responder supports nonces or otherwise echoes back information submitted in the request (serial number is the example given in the Mozilla thread)

2.      The OCSP responder certificate is not constrained with an EKU (this does not prevent forged OCSP responses but does prevent the use of a forged certificate for TLS)

I don't believe that there are any policies limiting the lifetime of an OCSP responder certificate, so CAs could issue a "last" delegated OCSP responder certificate before Jan 1 with a lifetime that exceeds the validity of their longest lived SHA-1 subscriber certificate. I believe a better approach would be to require that these certificates be constrained to OCSP signing and allowed to be issued after 2016. This is already part of the Microsoft policy:

4(A).17 - A CA must either technically constrain an OCSP responder such that the only EKU allowed is OCSP Signing or it must not use SHA-1 to sign OCSP responses.

Are there objections to modifying section 7.1.3 to align with Microsoft's policy?

Thanks,

Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161027/446d5565/attachment-0003.html>