[cabfpub] Ballot 118 - SHA1 Sunset

Tue Oct 28 18:29:41 UTC 2014

On Tue, Oct 28, 2014 at 10:49 AM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

>  To follow up on Rick’s question – I am getting increasingly confused by
> the responses on this string, so I will just ask my questions outright
> (possibly “already answered”, but please humor me).  My concern is more
> with signatures on CRLs and OCSP responses in 2016, not 2017.
>
>
>
> 1.  Will CRLs with a  SHA-1 signature be rejected or receive a negative
> browser UI in Chrome in *2016*?  (Same question for Firefox and
> Microsoft.)
>

The date for disabling SHA-1 signatures, as discussed, is 1 January 2017.

The previously reply already identified the relevance (or lack) of CRLs.

>
>
> 2. Will OCSP responses with a  SHA-1 signature be rejected or receive a
> negative browser UI in Chrome in *2016*?  (Same question for Firefox and
> Microsoft.)
>

Likewise, the date for disabling SHA-1 signatures is 1 January 2017.

To answer your question regarding UIs: Unlike the 1 January 2016 date that
CAs need to stop issuing certificates - which immediately affects site
operators today and affects their planning for certificate reissuance -
site operators have zero control over SHA-1, and so there is no value to
UI, as site operators can not do anything to change the CA's infrastructure.

So no, no UI. Then again, neither method is used, which should also have
signaled the expectations.

>
>
> As Rick noted, CRLSets and OneCRL will likely be checking CRLs in 2016, so
> it will be useful to know if SHA-1 signatures will be a problem then.  As
> far as I know, they may also be doing some OCSP checking in 2016, so same
> question.
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Rick Andrews
> *Sent:* Tuesday, October 28, 2014 10:37 AM
> *To:* Ryan Sleevi
> *Cc:* CABFPub
>
> *Subject:* Re: [cabfpub] Ballot 118 - SHA1 Sunset
>
>
>
> Ryan,
>
>
>
> Firefox and Chromium do not check CRLs, but Google parses some CRLs to
> build its CRLSets, and Mozilla plans to do something similar with OneCRL.
> So both companies rely on CRLs, and it would be helpful to know that
> switching the CRL for a SHA-1 root from SHA-1 to SHA-2 will not cause any
> problems.
>
>
>
> Many CAs are already signing CRLs and OCSP responses with SHA-2, so that’s
> not what I’m concerned about. I’m just concerned about the special case of
> SHA-1 roots. Currently, I bet all CAs are signing CRLs and OCSP responses
> for certs issued by those roots with SHA-1, and at some point we need to
> switch to using SHA-2. We may not want to do that too early, because that
> will negatively affect clients that don’t support SHA-2. And we’d like to
> be sure that there’s no assumptions built in to any relying party software
> that a SHA-1 CA will always sign a CRL and OCSP response with SHA-1.
>
>
>
> Mozilla’s blog is helpful, but it says nothing about CRL use (for OneCRL)
> or OCSP responses.
>
>
>
> -Rick
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Tuesday, October 28, 2014 9:49 AM
> *To:* Rick Andrews
> *Cc:* 陳立群; 王文正; CABFPub; Geoff Keating
> *Subject:* RE: [cabfpub] Ballot 118 - SHA1 Sunset
>
>
>
>
> On Oct 28, 2014 9:38 AM, "Rick Andrews" <Rick_Andrews at symantec.com> wrote:
> >
> > 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?
> >
>
> As discussed previously, Mozilla has published
> https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
> .
>
> As was discussed previously for how the NSS development team has handled
> this - from MD5 to 1024-bit - this will affect all signed data blobs. That
> is, when the NSS team disabled MD5, and this was uplifted into Mozilla
> Firefox, all MD5 signed blobs were rejected. This is the normal and
> configured expression for how NSS disables algorithms.
>
> While I can't speak authoritatively for Apple, when Apple disabled MD5
> (first on iOS, then on OS X), the exact same behavior described for
> Chromium, Microsoft, and Firefox was adopted. That is, all signed data
> blobs containing MD5 - whether certificate, CRL, S/MIME, etc - were
> rejected as weak signatures.
>
> >
> >
> > 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.
> >
>
> Firefox does not check CRLs.
> Chromium does not check CRLs.
> You have a statement from Tom that Microsoft does not plan to check CRLs.
>
> So really, this is just a question for Apple then, right? I can say
> categorically that their code accepts SHA-2 CRLs, but I suspect you'll want
> confirmation from Apple directly.
>
> >
> >
> > -Rick
> >
> >
> >
> > 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>
> 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]
> 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]
> 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]
> 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
> >
> >
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141028/334bf75a/attachment-0003.html>