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? On Tue, Jan 25, 2022 at 10:29 PM Ben Wilson <[email protected]> wrote: > My previous email asked, "Can the future use of SHA1 signing be eliminated > from the MRSP altogether, and if so, on what timeframes?" > > Rather than attempt to determine SHA1 deprecation timeframes here, I am > going to create a CA Communication and Survey. The survey will go out to > all CAs in the Mozilla program, and it will ask the relevant questions that > will help us determine appropriate sunset dates for SHA1. > > Thanks, > > Ben > > On Fri, Jan 21, 2022 at 12:54 PM Ben Wilson <[email protected]> wrote: > >> All, >> >> This email launches a new discussion related to sunsetting the future use >> of SHA1 in the Mozilla Root Store Policy (MRSP) >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>. >> >> >> It is related to GitHub Issue #178 >> <https://github.com/mozilla/pkipolicy/issues/178> (as well as Issue #201 >> <https://github.com/mozilla/pkipolicy/issues/201>). >> >> SHA1 is still allowed to be used in signing SMIME certificates, Authority >> Revocation Lists (ARLs), and CRLs, and OCSP responses (but see CABF Ballot >> >> <https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003090.html> >> >> SC53: Sunset for SHA-1 OCSP Signing >> <https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003090.html> >> ). >> Can the future use of SHA1 signing be eliminated from the MRSP >> altogether, and if so, on what timeframes? >> >> Currently, SHA1 is mentioned in the MRSP as follows: >> ----------- >> *Section 5.1.1 RSA* >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#511-rsa> >> >> 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. >> >> Section 5.1.3 SHA-1 >> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#513-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: >> >> 1. >> >> The end-entity certificate: >> - is not within the scope of the Baseline Requirements; >> - contains an EKU extension which does not contain either of the >> id-kp-serverAuth or anyExtendedKeyUsage key purposes; >> - has at least 64 bits of entropy from a CSPRNG in the serial >> number. >> 2. >> >> The issuing certificate: >> - contains an EKU extension which does not contain either of the >> id-kp-serverAuth or anyExtendedKeyUsage key purposes; >> - has a pathlen:0 constraint. >> >> 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: >> >> - a new key (of the same size); >> - a new serial number (of the same length); >> - the addition of an EKU and/or a pathlen constraint to meet the >> requirements outlined above. >> >> 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 " > [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%2B1gtaa9f1Oi6bNSkHfu4Cnd%3DgNUnbF_6DuKgYGULSOWb3myog%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaa9f1Oi6bNSkHfu4Cnd%3DgNUnbF_6DuKgYGULSOWb3myog%40mail.gmail.com?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/CAErg%3DHEixp9qPGPEO3_LGSDDgi83G-5948b%3DeOfPPFP5i0dvZg%40mail.gmail.com.
