SwissSign is currently using SHA1 on our CRLs. We are currently looking into the necessary changes to remove SHA1 signing. If the sunset date is anytime in 2023 we do not see any time issues.
Mike [email protected] schrieb am Freitag, 4. Februar 2022 um 18:50:38 UTC+1: > 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/cd07d26a-84f7-46d1-9300-8f6a5787f1c1n%40mozilla.org.
