[cabfpub] Ballot 118 - SHA1 Sunset

Rick Andrews Rick_Andrews at symantec.com
Tue Oct 28 16:38:45 UTC 2014

There’s more to discuss here. First of all, I don’t think we’ve heard from *all* browser vendors. Clearly, what Ryan said below applies to Chrome (and I presume Opera, since they share the common Chromium open source base) and IE. I don’t recall hearing from Gerv during the F2F, so I’d appreciate a positive confirmation about Firefox. And we’ve not yet heard from Apple. Geoff Keating, can you please confirm that Safari will accept SHA-2 signed CRLs from SHA-1 roots after January 1, 2017?

Second: speaking only for Symantec (although I suspect other CAs will agree) I don’t want to make the change from SHA-1 CRLs to SHA-2 CRLs at midnight December 31, 2016. We’d like to make the change sooner, perhaps early December 2016 when we have a full staff in the office. I would like positive confirmation from all browser vendors that the latest version of their browser will not *reject* a SHA-2 CRL from a SHA-1 CA before January 1, 2017. Thanks in advance.


From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Friday, October 24, 2014 4:57 PM
To: Rick Andrews
Cc: 王文正; 陳立群; CABFPub
Subject: Re: [cabfpub] Ballot 118 - SHA1 Sunset

Browser vendors have repeatedly responded to this - during the discussion of the ballot and during F2F.

To answer the specific question, "Will SHA-1 signed CRLs be accepted after January 1, 2017", the answer from multiple vendors has been:

On January 1, 2017, SHA-1-based signatures will no longer be accepted. The use of SHA-1 for non-signature purposes (e.g. the ReponderID construct, key hash, or cert ID) will remain accepted.

This should make it clear and unambiguous that CRLs and OCSP responses that are still signed with SHA-1 on or after January 1, 2017, will no longer validate. As such, a CA who continues to do so is effectively doing the same thing as providing an invalid CRL or OCSP response - and clients will not be able to use this for revocation information.

Focusing on things like "Will it show a warning" is counter-productive, because the answer has been consistently that "The signatures will not be accepted". If the signature is not accepted, the data cannot be used, ergo the CA will be unable to revoke certificates, the same as if they served an invalid CRL.

On Fri, Oct 24, 2014 at 4:41 PM, Rick Andrews <Rick_Andrews at symantec.com<mailto:Rick_Andrews at symantec.com>> wrote:
Wen-Cheng, I agree that we should clarify this for the BRs.

Browser vendors, please respond.


From: 王文正 [mailto:wcwang at cht.com.tw<mailto:wcwang at cht.com.tw>]
Sent: Thursday, October 23, 2014 8:52 PM
To: Rick Andrews; 陳立群; 'CABFPub'
Subject: RE: [cabfpub] Ballot 118 - SHA1 Sunset


Besides from the purpose of building CRLSets and OneCR, I think that since the current BR mandates Root CAs to issue CRL, it is necessary to clarify the SHA-1 validity period for signing CRL in section 9.4.2, otherwise we leave ambiguity in the BR.

(Please refer to Appendix B of the BR, for the cRLDistributionPoints extension field of the Subordinate CA Certificate, it says “This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA’s CRL service.” That implies that Root CAs MUST issue CRL.)

As for revocation checking mechanisms adopted by browsers, modern browsers indeed will check OCSP first. However, if the OCSP check failed after several retries, our observation (from our CA’s http access log) is that some browsers will do CRL fetching as a fallback.

Wen-Cheng Wang

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Friday, October 24, 2014 2:42 AM
To: 陳立群; 'CABFPub'
Subject: Re: [cabfpub] Ballot 118 - SHA1 Sunset


I don’t know the answer, but most (maybe all?) modern browsers don’t check CRLs today. However, I would re-state your question as “For the purpose of building CRLSets and OneCRL, will Google and Mozilla require CRLs to be signed with SHA-2 after 2017, or will they still accept CRLs signed with SHA-1?” Ryan Sleevi and Gerv Markham would have to answer this.

At the face-to-face meeting in Beijing, a similar question was discussed about OCSP. Here are notes from the minutes of the meeting:

“Bruce asked if those SHA-1 roots can still sign OCSP responses and CRLs with SHA-1? Microsoft doesn't use CRLs anymore, but Tom said that SHA-1 roots would have to switch to signing OCSP Responses with SHA-2. When that happens, though, the OCSP responses won't be usable by clients who don't support SHA-2. That could cause problems in 2017.”

(Note that the discussion was about OCSP, not CRLs)


From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of ???
Sent: Thursday, October 23, 2014 4:00 AM
To: 'CABFPub'
Subject: Re: [cabfpub] Ballot 118 - SHA1 Sunset

            We wonder if  a SHA-1 Root CA  sign SHA-1 CRL (or we have to say it is Certification Authority Revocation List, CARL) after Jan.,1,2017, will there be any warning message from application software?

Sincerely Yours,

                                                                   Li-Chun CHEN



Government Network Service Dept.

Data Communication Business Group

Chunghwa Telecom Co. Ltd.

realsky at cht.com.tw<mailto:realsky at cht.com.tw>


From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, October 03, 2014 4:56 AM
Subject: [cabfpub] Ballot 118 - SHA1 Sunset

Ballot 118 - SHA1 Sunset
Kelvin Yiu of Microsoft made the following motion, and Kirk Hall from Trend Micro and Ryan Sleevi from Google have endorsed it.
Reason for Ballot
Over the last year or two, several application software providers have announced deprecation of the SHA-1 algorithm in their software.
-- Motion Begins --
A. In the Baseline Requirements, insert the following new section 9.4.2:
9.4.2 SHA-1 Validity Period
Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017. This Section 9.4.2 does not apply to Root CA or CA cross certificates. CAs MAY continue to use their existing SHA-1 Root Certificates. SHA-2 Subscriber certificates SHOULD NOT chain up to a SHA-1 Subordinate CA Certificate.
Effective 16 January 2015, CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017 because Application Software Providers are in the process of deprecating and/or removing the SHA-1 algorithm from their software, and they have communicated that CAs and Subscribers using such certificates do so at their own risk.
B. In Appendix A of the Baseline Requirements - Cryptographic Algorithm and Key Requirements (Normative), add this note under Table 2, Subordinate CA certificates:
* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 9.4.2.
And amend this note at the end of each of the 3 tables.
* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 9.4.2 until SHA-256 is supported widely by browsers used by a substantial portion of relying-parties worldwide.
-- Motion Ends --
The review period for this ballot shall commence at 2200 UTC on Thursday, 2 October 2014, and will close at 2200 UTC on Thursday, 9 October 2014. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Thursday, 16 October 2014. Votes must be cast by posting an on-list reply to this thread. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members– at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining.

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141028/0c3615b6/attachment-0003.html>

More information about the Public mailing list