Those are good points. I was using the algorithms as surrogates when trying to explain where I saw differences in the kinds of roots that might be treated differently. I'll put lesser weight on that factor in my spreadsheet, and more weight on other factors, and see how that might change things.
On Thu, Feb 3, 2022, 12:41 PM Ryan Sleevi <[email protected]> wrote: > I agree with Doug. The signature algorithm seems irrelevant. > > Shouldn’t the priority for removal be: > * Certificates created before the BRs > * Certificates created after the BRs, but without a root key generation > report > * Certificates without an unbroken series of audits from the moment of > creation > * Certificates with audits that have findings/qualifications > * Certificates that have had incidents within their CA hierarchy > * Certificates more than five years old, on the basis that as the > understanding of the BRs has improved by auditors over time, past incidents > that would be detected today and result in findings/qualifications would > not have been detected then > > Focusing on the key size is useful, but seems to only mitigate a very > narrow attack (key factorization), when we know from the ecosystem that > substantial risk is in the management and day to day operation. > > On Thu, Feb 3, 2022 at 2:32 PM 'Doug Beattie' via > [email protected] <[email protected]> wrote: > >> Hi Ben, >> >> >> >> I’m not against removing old roots from the trust store, but is using the >> hash algorithm on the root the right criteria? I was under the impression >> that the root programs really embedded the public key and that the >> signature on the root was “irrelevant” from a security perspective once it >> was imbedded. >> >> >> >> Doug >> >> >> >> *From:* [email protected] <[email protected]> >> *On Behalf Of *Ben Wilson >> *Sent:* Thursday, February 3, 2022 2:01 PM >> *To:* [email protected] <[email protected]> >> *Subject:* Policy 2.8: MRSP Issue #232: Add policy about old root >> certificates >> >> >> >> All, >> >> >> >> Originally, I scoped version 2.8 of the Mozilla Root Store Policy (MRSP) >> to include criteria and timeframes for when certain old root CA >> certificates would be removed from the trust store (prior to their expiry >> date). >> >> >> >> In Github, I am taking off the "2.8" Label from Issue #232 >> <https://github.com/mozilla/pkipolicy/issues/232> and will not include >> it in version 2.8 of the MRSP, but I will be continuing my analyses of >> older roots and the appropriate time by which each should be removed. >> >> >> >> The approach might be to remove the website trust bit for the following >> types of roots in the following order: >> >> - 2048-bit RSA signed using SHA1 (approx. 2025) >> - 2048-bit RSA signed using SHA256 (approx. 2027) >> - 4096-bit RSA signed using SHA1 (approx. 2029) >> - EC 256r1 signed using SHA256 (approx. 2029) >> >> There are a number of factors that I am looking at, like CABF >> requirements in existence when the root was created, whether the root is >> older than 18-20 years, etc. >> >> >> >> I would suggest that we might take action on other roots (e.g. RSA 4096 >> with SHA256 and EC 384r1 with SHA384) in the early 2030s, but that will >> depend on the evolution of computing power and the development of systems >> that support stronger, quantum-resistent crypto. >> >> >> >> 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%2B1gtabt4tSD%3DyUgruO-dNbR%3DAjZzxkxDLostvG-xFKht5dYKg%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabt4tSD%3DyUgruO-dNbR%3DAjZzxkxDLostvG-xFKht5dYKg%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/PUZPR03MB6129CCE0FC5122A48B7A5D30F0289%40PUZPR03MB6129.apcprd03.prod.outlook.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/PUZPR03MB6129CCE0FC5122A48B7A5D30F0289%40PUZPR03MB6129.apcprd03.prod.outlook.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/CA%2B1gtaYWfQ7cPp1KN9ibn2afWPVshsdq3Kx0MG1f0FpAYqOXgQ%40mail.gmail.com.
