Hi Buypass does only use SHA256 when signing certificates, CRLs and OCSP responses and we are supportive of sunsetting SHA-1.
Regards Mads From: [email protected] <[email protected]> On Behalf Of Ben Wilson Sent: fredag 21. januar 2022 20:55 To: [email protected] <[email protected]> Subject: Policy 2.8: MRSP Issue #178: Sunset SHA1 All, This email launches a new discussion related to sunsetting the future use of SHA1 in the Mozilla Root Store Policy (MRSP)<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BSNUt8H7WxEMMJiP93iyXIOGTHDuWbHXcwowcfZNexo%3D&reserved=0>. It is related to GitHub Issue #178<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F178&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KageYkikethliY5C%2FR3TVw6OSO4nL9TC5mLzk5mXDWc%3D&reserved=0> (as well as Issue #201<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F201&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TxcjyzQDa1pzo%2BvNC%2BlA4g7CpvayzRm1V9B3djTQc%2Bg%3D&reserved=0>). 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://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2022-January%2F003090.html&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WElZREtBY9VopbyuGGud36nPQrYtjRddUwnlSpQ%2Fp2Y%3D&reserved=0> SC53: Sunset for SHA-1 OCSP Signing<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2022-January%2F003090.html&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WElZREtBY9VopbyuGGud36nPQrYtjRddUwnlSpQ%2Fp2Y%3D&reserved=0>). 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://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F%23511-rsa&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pQDhc6CbjtyUwzDQ14ntHvCSbM91x9wcpZYVVNaXYdA%3D&reserved=0> 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://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mozilla.org%2Fen-US%2Fabout%2Fgovernance%2Fpolicies%2Fsecurity-group%2Fcerts%2Fpolicy%2F%23513-sha-1&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2xf%2F3zoEb73lNmqqT82aSh%2FrxewBoM7n2v0O9m7aGx8%3D&reserved=0> 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. 1. 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]<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/CA%2B1gtaZ69aUkmG9m978YTjeiDsRtznTmL0-%2B_6eP%2BfmiDgpSGQ%40mail.gmail.com<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCA%252B1gtaZ69aUkmG9m978YTjeiDsRtznTmL0-%252B_6eP%252BfmiDgpSGQ%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Cmads.henriksveen%40buypass.no%7C7e3ed45f472943ddc56808d9dd17e246%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637783916924535875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5%2Fve2JANCCj1TkcHsEl%2Fhthaxc0px4QI%2FWJNRO0c7lM%3D&reserved=0>. -- 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/SVAP279MB01263D8247C89A1FFD2D1261E7309%40SVAP279MB0126.NORP279.PROD.OUTLOOK.COM.
