[cabfpub] Ballot 118 - SHA1 Sunset
Rick_Andrews at symantec.com
Fri Oct 24 16:41:26 MST 2014
Wen-Cheng, I agree that we should clarify this for the BRs.
Browser vendors, please respond.
From: ÍõÎÄÕý [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.
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
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?
CISSP, CISA, CISM, PMP,
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¨C at least nine members must participate in the ballot, either by voting in favor, voting against, or abstaining.
±¾ÐÅ¼þ¿ÉÄÜ°üº¬ÖÐÈAëÐÅ¹É·ÝÓÐÏÞ¹«Ë¾CÃÜÙYÓ,·ÇÖ¸¶¨Ö®ÊÕ¼þÕß,ÕÎðÉL¼¯¡¢ÌÀí»òÀûÓÃ±¾ÐÅ¼þÈÈÝ,KÕäN§´ËÐÅ¼þ. ÈçéÖ¸¶¨ÊÕ¼þÕß,ª´_±£×oà]¼þÖÐ±¾¹«Ë¾Ö® IICÃÜ¼°ÈËÙYÁÏ,²»µÃÈÎÒâ÷Ñ»ò½ÒÂ¶,Kª×ÔÐÐ´_ÕJ±¾à]¼þÖ®¸½nÅc³¬ßB½YÖ®°²È«ÐÔ,ÒÔ¹²Í¬ÉÆ±MÙYÓ°²È«ÅcÙY±£×oØÈÎ.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public