Policy 2.8: MRSP Issue #232: Add policy about old root certificates

[Ben Wilson]

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 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

[Doug Beattie]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
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.

[Ryan Sleevi]

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.

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.

[Ben Wilson]

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.