Here is proposed language to include at the top of MRSP section 5.3.1: 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 * CRLs. See https://github.com/BenWilson-Mozilla/pkipolicy/commit/0c215bb32e9ab556808cc4fb704eb633c3cb4581 I'm open to suggestions. For example, should the above language be placed at the bottom of Section 5.1.3 instead? (I already tried placing the language after every relevant case in section 5.1.3, but that was unnecessarily repetitive.) Thanks, Ben On Thu, Feb 17, 2022 at 11:09 AM Ben Wilson <[email protected]> wrote: > Everyone, > > Here is what I'd like to propose: > > Effective July 1, 2022, S/MIME certificates cannot be signed using SHA1 > (Apple’s deadline is April 1, 2022). > > Effective July 1, 2023, all certificates (including OCSP responders), > CRLs (including ARLs), and OCSP responses cannot be signed using SHA1. > > Thoughts? > > Ben > > > > On Wed, Feb 16, 2022 at 6:25 AM Pekka Lahtiharju < > [email protected]> wrote: > >> 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/CA%2B1gtaaHU8dj%2BNMLDkJZg4OdQcuy_E5uHOJhH6p80%2BGvRrFaiw%40mail.gmail.com.
