Telia is not anymore using SHA-1 for signing CRL, OCSP or certificates within scope of publicly trusted certificates.
perjantai 11. helmikuuta 2022 klo 22.02.22 UTC+2 Dustin Hollenback kirjoitti: > Microsoft is not using SHA-1 for signing of CRLs or end entity > certificates. However, we are currently using SHA-1 to sign some OCSP > responses and will stop using it by 2022-06-01. > > On Friday, January 21, 2022 at 11:54:49 AM UTC-8 [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/fa01725e-9bfe-4bbb-8488-2fc765b52fd4n%40mozilla.org.
