[cabfpub] Ballot 118 - SHA1 Sunset

Ryan Sleevi sleevi at google.com
Fri Oct 24 16:57:03 MST 2014


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>
wrote:

> Wen-Cheng, I agree that we should clarify this for the BRs.
>
>
>
> Browser vendors, please respond.
>
>
>
> -Rick
>
>
>
> *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
>
>
>
> Rick,
>
>
>
> 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
> <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
>
>
>
> Li-Chun,
>
>
>
> 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)
>
>
>
> -Rick
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org
> <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
>
>                                                                    Engineer
>
> CISSP, CISA, CISM, PMP,
>
> Government Network Service Dept.
>
> Data Communication Business Group
>
> Chunghwa Telecom Co. Ltd.
>
> realsky at cht.com.tw
>
> +886-2-2344-4820#4025
>
>
>
>
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org
> <public-bounces at cabforum.org>] *On Behalf Of *Ben Wilson
> *Sent:* Friday, October 03, 2014 4:56 AM
> *To:* CABFPub
> *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
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141024/6838c968/attachment-0001.html 


More information about the Public mailing list