[cabfpub] Ballot 118 - SHA1 Sunset

Ryan Sleevi sleevi at google.com
Tue Oct 28 09:48:34 MST 2014


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141028/8c93b14e/attachment-0001.html 


More information about the Public mailing list