All, Do we know of any CA claiming a need to sign with SHA1 past September 2023?
Also, two other concepts that I don't believe have been fully expressed yet are: 1 - Mozilla curates the trust store for TLS server authentication and for SMIME and not for other uses - see https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/, and 2 - while switching from SHA1 to SHA2 might be costly and time-consuming for some CAs, isn't it something that they need to do sooner rather than later? Thanks, Ben On Fri, Feb 4, 2022 at 3:57 AM 加毛 寿 <[email protected]> wrote: > Ben-san, > > > > Regarding Policy 2.8: MRSP Issue #178: Sunset SHA1, we agree with the > response with a view to improving the reliability of network security. > > > > On the other hand, the CRL signed with SHA-1 of a Root CA Certificate > (Security Communication Root CA1) (* 1) is used for the verification of the > already issued client-auth certificate, and suppose if we try replace the > verification logic to SHA-2, the serious impact on the PKI of client-auth > may be expected, which makes difficulty doing it. For that reason, we are > planning to use the SHA-1 CRL until September 2023, which is the expiration > date of Security Communication Root CA1. Therefore, in order to comply > sunset of the SHA-1 CRL before that date, we believe that it is necessary > to erase the security bit of server-auth and revoke the Cross root > certificate. > > We are currently working on the timeline planning for these procedures. We > also understand that this validation path is used by the feature phones > (old cell phones) with a hard-coded trust store. (As reported in # 8.d of > April 2021 CA Communication (* 2), NTT DoCoMo, a Japanese mobile phone top > carrier, plans to continue providing services to those feature phones until > March 2026). We suppose that users who still use these feature phones > include a significant proportion of elderly people, and that they will pay > greater switching costs than ordinary consumers would do. In such a > situation, we also had received requests from some stakeholders to let them > have a certain period of informing time before revoking the Cross-Root > Certificate, so that we are trying to decide timeline bit more carefully > compare to other cases. > > > > (*1) SHA1 Root CA Certificate (Security Communication RootCA1) > > https://crt.sh/?id=144 > > Sep 30 04:20:49 2023 GMT > > > > (*2) #8.d of April 2021 CA Communication > > > https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00156,Q00151,Q00158 > > > > Thank you for your consideration. > > > > Best regards, > > Hisashi Kamo > > > > > > *From:* 'Bruce Morton' via [email protected] [mailto: > [email protected]] > *Sent:* Friday, February 4, 2022 6:13 AM > *To:* [email protected] > *Cc:* [email protected] <[email protected]>; > [email protected] <[email protected]>; [email protected] < > [email protected]> > *Subject:* Re: Policy 2.8: MRSP Issue #178: Sunset SHA1 > > > > Entrust has already sunset SHA-1 for S/MIME certificates. Entrust will > respond to ballot SC53 and will stop using SHA-1 with OCSP responses and > will push this requirement to CRLs as well. We have also reached out to our > subordinate CAs to advise of the pending change and confirm their current > SHA-1 status. > > On Thursday, February 3, 2022 at 11:28:33 AM UTC-5 [email protected] > wrote: > > Hello, > > This is Cybertrust Japan. One of our root CAs uses SHA-1 for CRL signing. > But we would like to sunset the use of SHA1. In fact, our plan is to > retire this SHA-1 Root of SecureSign Root11 and replace it with its > successors. So we are preparing root inclusion requests. > > > Best, > Mo > > 2022年2月3日木曜日 2:35:58 UTC+9 [email protected]: > > For the sake of completeness: Let's Encrypt / ISRG does not sign SHA-1 > hashes for any purpose, and would be amenable to any sunset date. > > > > We do accept signatures over SHA-1 hashes of CSRs provided by subscribers, > and of course accept SHA-1 hashes for the issuerKeyHash and issuerNameHash > in OCSP requests, but those are not relevant to this proposal. > > > > Aaron > > On Tuesday, February 1, 2022 at 7:59:37 PM UTC-8 [email protected] wrote: > > I have emailed CAs in the Mozilla program asking them to respond here. > > > > On Wed, Jan 26, 2022 at 12:41 PM Ryan Sleevi <[email protected]> wrote: > > > > > > On Wed, Jan 26, 2022 at 2:00 PM Ben Wilson <[email protected]> wrote: > > See responses inline below. > > > > On Tue, Jan 25, 2022 at 11:12 PM Ryan Sleevi <[email protected]> wrote: > > It’s not clear: what situations make it appropriate for a CA > communication, versus discussion here? > > > > Yes. It is preferable that discussion take place here. However, a survey > would still be public, as they have been in the past, and the CCADB would > collect all of the responses in a table format. > > > > Oh, for sure :) I just know that the surveys have historically had delays > or had confusion by CAs in interpreting questions, and the survey approach > somewhat predates the m.d.s.p. participation requirement. I totally realize > that it has benefits for bringing direct awareness, but I raise it to try > and understand if the expectation is to always have the two parallel paths > for soliciting feedback, or if it might just be sufficient to email blast > CAs to say "Hey, here's the discussion, to send feedback, please > participate here". That, I think, might achieve the goal of highlighting > the importance, while still centralizing some of the conversation :) Just a > thought > > > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b75895bc-37e7-4962-afdb-8841dd8b39c2n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b75895bc-37e7-4962-afdb-8841dd8b39c2n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYbMus_j5%2BrYhYXskoi821oK73OQ18o8g8A6GPBS6Z_0Q%40mail.gmail.com.
