When a root or intermediate certificate's RSA key is used to produce a signature, only the following algorithms may be used, and with the following encoding requirements:
RSASSA-PKCS1-v1_5 with SHA-1.
The encoded AlgorithmIdentifier MUST match the following hex-encoded bytes:
300d06092a864886f70d0101050500
.
See section 5.1.3 for further restrictions on the use of SHA-1.
CAs MAY sign SHA-1 hashes over end-entity certificates which chain up to roots in Mozilla's program only if all the following are true:
The end-entity certificate:
The issuing certificate:
Point 2 does not apply if the certificate is an OCSP signing certificate manually issued directly from a root.
CAs MAY sign SHA-1 hashes over intermediate certificates which chain up to roots in Mozilla's program only if the certificate to be signed is a duplicate of an existing SHA-1 intermediate certificate with the only changes being all of:
CAs MAY sign SHA-1 hashes over OCSP responses only if the signing certificate contains an EKU extension which contains only the id-kp-ocspSigning EKU.
CAs MAY sign SHA-1 hashes over CRLs for roots and intermediates only if they have issued SHA-1 certificates.
CAs MUST NOT sign SHA-1 hashes over other data, including CT pre-certificates.
-----------
I am thinking that we could amend MSRP sections 5.1.1 and 5.1.3 to have sunset dates and to also say something to the effect that:
"CAs MUST NOT sign SHA-1 hashes over any data."
Thoughts?
Thanks,
Ben
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa9f1Oi6bNSkHfu4Cnd%3DgNUnbF_6DuKgYGULSOWb3myog%40mail.gmail.com.
It’s not clear: what situations make it appropriate for a CA communication, versus discussion here?
Given Mozilla requires CA program participants monitor this list, and given the discussion gives a chance to gather feedback directly, it’s not entirely clear the benefit? Do we expect that some CAs are out of compliance with that part of the program?
If CAs don’t respond, but are otherwise aware, isn’t it reasonable to conclude “Yes” and “immediately”? Isn’t that part of the point of the policy in the first place - for CAs to engage when questions are raised, while also being able to be aware of discussions relevant to there operations, whether it be new policies, incidents, or other matters of interest?
See responses inline below.On Tue, Jan 25, 2022 at 11:12 PM Ryan Sleevi <ry...@sleevi.com> 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.
Dear All,
DESC is already using sha256 for signing CRLs, OCSP responses, and EE Certificates.
Kind Regards,
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
||||||||||||||||||||||
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)
Sep 30 04:20:49 2023 GMT
(*2) #8.d of April 2021 CA Communication
Thank you for your consideration.
Best regards,
Hisashi Kamo
From: 'Bruce Morton' via dev-secur...@mozilla.org [mailto:dev-secur...@mozilla.org]
Sent: Friday, February 4, 2022 6:13 AM
To: dev-secur...@mozilla.org
Cc: mo.masar...@gmail.com <mo.masar...@gmail.com>; bwi...@mozilla.com <bwi...@mozilla.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
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.
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dev-security-po...@mozilla.org.
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.
DigiCert supports banning SHA1 across the board. We are no longer supporting SHA1 signatures for services related to certs trusted by Mozilla.
Jeremy
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabsr__yskc6K8%2BDc%3DOQGYp5C-mQBanqeBm67-R3qOQi_w%40mail.gmail.com.
Disig currently uses SHA-256 signing exclusively, so there is no problem with sunset of SHA-1.
Regards
Peter
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabsr__yskc6K8%2BDc%3DOQGYp5C-mQBanqeBm67-R3qOQi_w%40mail.gmail.com.
Hi Ben,
GlobalSign supports banning SHA-1 across the board. We no longer supporting SHA-1 signatures for services related to certs trusted by Mozilla except for the "GlobalSign Root CA" CRL and we plan to change that over prior to September.
We use SHA-1 for other purposes such as accepting SHA-1 hashes in CSRs, for the issuerKeyHash and issuerNameHash in OCSP requests, and in computing and validating subjectkeyidentifer and issuerkeyidentifier values.
Doug
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Ben Wilson
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabsr__yskc6K8%2BDc%3DOQGYp5C-mQBanqeBm67-R3qOQi_w%40mail.gmail.com.
Hi,
Izenpe doesn’t perform any SHA-1 signatures. As other mentioned, we also accept SHA-1 for CSRs and OCSP/TSA requests, but that’s all. The proposed change wouldn’t have any impact on us.
Regards,
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabsr__yskc6K8%2BDc%3DOQGYp5C-mQBanqeBm67-R3qOQi_w%40mail.gmail.com.
Actalis uses SHA-256 all over the place,
therefore sunsetting of SHA-1 is okay with us.
Regards
Adriano
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZ69aUkmG9m978YTjeiDsRtznTmL0-%2B_6eP%2BfmiDgpSGQ%40mail.gmail.com.
Hi
Buypass does only use SHA256 when signing certificates, CRLs and OCSP responses and we are supportive of sunsetting SHA-1.
Regards
Mads
--
Effective July 1, 2022, CAs SHALL NOT sign SHA-1 hashes over end-entity certificates with an EKU extension containing the id-kp-emailProtection key purpose. |
Effective July 1, 2023, CAs SHALL NOT sign SHA-1 hashes over: |
* certificates with an EKU extension containing the id-kp-ocspSigning key purpose; |
* intermediate certificates that chain up to roots in Mozilla's program; |
* OCSP responses; or |
Hi Ben and dev-security-policy group,
Consorci AOC supports banning SHA-1 across the board.
We no longer support SHA-1 signatures for services related to CAs trusted by Mozilla, in our situation OCSP and CRL, and we have met the deadline to change in February 2022.
We use SHA-1 for other purposes such as accepting SHA-1 hashes in CSRs, for the issuerKeyHash and issuerNameHash in OCSP requests, and in computing and validating subjectkeyidentifer and issuerkeyidentifier values.
Thank you,
_ |
|
|
|
|
--