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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: On Wed, Jan 26, 2022 at 2:00 PM Ben Wilson <[email protected]<mailto:[email protected]>> wrote: See responses inline below. On Tue, Jan 25, 2022 at 11:12 PM Ryan Sleevi <[email protected]<mailto:[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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[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/0bdca4214f974f91b93d27b8af02ee93%40secom.co.jp.
