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

Kirk Hall Kirk.Hall at entrustdatacard.com
Wed Oct 26 00:26:42 UTC 2016

Wayne -  I agree with you we that need to move forward now.

Previously we had discussed not putting forward any ballots that amend the current BRs or EVGL until we complete the readoption Ballot 180, which should be occur by January 7.  But as you point out, this change is very time sensitive and can't wait that long.

I think we can treat this as a Maintenance Guideline to Sec. 7.1.3 of the BRs because we need to complete the adoption process by December 31.  I see no risks of infringing IP in the change you propose, but in any case we can run it through the normal 30 day Review Period for Maintenance Guidelines and complete voting before December 31.

(My present recommendation is that all other pending ballots for Maintenance Guidelines be discussed and drafted, but that we delay the start of the 30 day Review Period for those ballots until January 7 and then have multiple Review Periods for those ballots running simultaneously.)

We can discuss on our Thursday call, but does anyone have an objection to this plan at this time?

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

Having received no objections to this proposed change, I'd like to move forward with a ballot. This change is time sensitive due to the current 1 January 2017 deadline. Can this be balloted prior to passage of ballot 180, which is expected on Jan 7?



From: Wayne Thayer
Sent: Friday, October 21, 2016 4:51 PM
To: CABFPub <public at cabforum.org<mailto:public at cabforum.org>>
Subject: 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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161026/9a12fba7/attachment-0003.html>

More information about the Public mailing list