In Item 8 of the April 2021 CA Survey, we asked CAs about the challenges, strategies, and information gaps involved with removing old root CA certificates from the root store.
Below is a summary of the suggestions we received.
Pre-2006/pre-2012 roots should not be automatically considered non-compliant with the Baseline Requirements. Instead, Mozilla should remove roots that cannot provide an unbroken sequence of period-of-time audits. Alternatively, Mozilla should focus on industry timeframes (e.g. NIST) for the removal of 2048-bit RSA roots.
Mozilla should provide data on how many clients and third parties are still using older roots that might be seriously impacted by their removal from NSS.
Mozilla should balance the risks it intends to address by removing the roots with the disruptions it will cause.
Mozilla should publish its timelines for root removals, including root submission, review, inclusion, and deprecation of the older roots.
Mozilla needs to coordinate the effort with other root programs (e.g. Microsoft, Apple and Google) and should streamline the process to ensure sufficient ubiquity of new roots.
An older root CA should only be distrusted 15 months after the new root CA is included in all of Mozilla, Microsoft, Apple and Google.
The inclusion process is too long, and this effort will clog inclusion requests. Mozilla and the other root stores need an abbreviated process for this effort.
Cross-certification adds another certificate to the chain, which is sometimes difficult for customers to configure, and S/MIME clients do not process cross certificates very well.
Mozilla should distinguish between root CAs supporting serverAuth certificates vs. S/MIME certificates, and Mozilla should keep the email trust bit and remove the websites trust bit to help bridge the transition.
important aspects of root inclusion and requirements applicable to roots to help facilitate the removal and inclusion process; and
good and bad practices from past experience and mistakes to help CAs avoid future non-compliance and delays.
In Item 8 of the April 2021 CA Survey, we asked CAs about the challenges, strategies, and information gaps involved with removing old root CA certificates from the root store.
Below is a summary of the suggestions we received.
Pre-2006/pre-2012 roots should not be automatically considered non-compliant with the Baseline Requirements. Instead, Mozilla should remove roots that cannot provide an unbroken sequence of period-of-time audits. Alternatively, Mozilla should focus on industry timeframes (e.g. NIST) for the removal of 2048-bit RSA roots.
Mozilla should provide data on how many clients and third parties are still using older roots that might be seriously impacted by their removal from NSS.
Mozilla should balance the risks it intends to address by removing the roots with the disruptions it will cause.
Mozilla should publish its timelines for root removals, including root submission, review, inclusion, and deprecation of the older roots.
Mozilla needs to coordinate the effort with other root programs (e.g. Microsoft, Apple and Google) and should streamline the process to ensure sufficient ubiquity of new roots.
An older root CA should only be distrusted 15 months after the new root CA is included in all of Mozilla, Microsoft, Apple and Google.
The inclusion process is too long, and this effort will clog inclusion requests. Mozilla and the other root stores need an abbreviated process for this effort.
Cross-certification adds another certificate to the chain, which is sometimes difficult for customers to configure, and S/MIME clients do not process cross certificates very well.
Mozilla should distinguish between root CAs supporting serverAuth certificates vs. S/MIME certificates, and Mozilla should keep the email trust bit and remove the websites trust bit to help bridge the transition.
- Mozilla should publish guidance, in coordination with other root stores, consisting of:
important aspects of root inclusion and requirements applicable to roots to help facilitate the removal and inclusion process; and
good and bad practices from past experience and mistakes to help CAs avoid future non-compliance and delays.
Cross-certification adds another certificate to the chain, which is sometimes difficult for customers to configure, and S/MIME clients do not process cross certificates very well.
Mozilla should distinguish between root CAs supporting serverAuth certificates vs. S/MIME certificates, and Mozilla should keep the email trust bit and remove the websites trust bit to help bridge the transition.
These are somewhat reasonable, although the statement about S/MIME clients is one that demands evidence, and is a little suspect based on the major implementations I've examined in the past. Supported with concrete data, it might be reasonable to treat a TLS transition independent of an S/MIME transition.
On 14/5/2021 2:58 π.μ., Ryan Sleevi wrote:
Cross-certification adds another certificate to the chain, which is sometimes difficult for customers to configure, and S/MIME clients do not process cross certificates very well.
Mozilla should distinguish between root CAs supporting serverAuth certificates vs. S/MIME certificates, and Mozilla should keep the email trust bit and remove the websites trust bit to help bridge the transition.
These are somewhat reasonable, although the statement about S/MIME clients is one that demands evidence, and is a little suspect based on the major implementations I've examined in the past. Supported with concrete data, it might be reasonable to treat a TLS transition independent of an S/MIME transition.
We were able to reproduce and confirm past findings on this issue regarding the S/MIME agents not using cross-certificates in the chain.
Our tests were performed using Thunderbird as sending agent and TB/Outlook as receiving agents.
Sending agent trusted old and new Root and included the cross-certificate in local certificate store.
The signed email contained only the Intermediate Certificate that chains to the new Root. There was no way to "dictate" TB to include the cross-certificate in the signature.
The receiving agents trusted only the old Root.
The receiving agents did not attempt to follow the AIA CAIssuers URI in order to get the cross-certificate, therefore the path validation failed and the signature was marked invalid.
Dimitris.
--
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/b8891dcf-b042-4514-2324-61d0cc101c13%40it.auth.gr.
On Mon, Aug 9, 2021 at 1:25 PM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote:
On 14/5/2021 2:58 π.μ., Ryan Sleevi wrote:
Cross-certification adds another certificate to the chain, which is sometimes difficult for customers to configure, and S/MIME clients do not process cross certificates very well.
Mozilla should distinguish between root CAs supporting serverAuth certificates vs. S/MIME certificates, and Mozilla should keep the email trust bit and remove the websites trust bit to help bridge the transition.
These are somewhat reasonable, although the statement about S/MIME clients is one that demands evidence, and is a little suspect based on the major implementations I've examined in the past. Supported with concrete data, it might be reasonable to treat a TLS transition independent of an S/MIME transition.
We were able to reproduce and confirm past findings on this issue regarding the S/MIME agents not using cross-certificates in the chain.
Our tests were performed using Thunderbird as sending agent and TB/Outlook as receiving agents.
Sending agent trusted old and new Root and included the cross-certificate in local certificate store.
The signed email contained only the Intermediate Certificate that chains to the new Root. There was no way to "dictate" TB to include the cross-certificate in the signature.
The receiving agents trusted only the old Root.
The receiving agents did not attempt to follow the AIA CAIssuers URI in order to get the cross-certificate, therefore the path validation failed and the signature was marked invalid.
Thanks. This, at least, is a little more concrete as to what you meant by "do not process well" - it seems what you were actually testing here is whether or not AIA fetching occurs, correct?
It's certainly not unexpected that Thunderbird does not do AIA chasing, especially since Firefox does not. At a minimum, the Thunderbird behaviour will be affected by what path builder it's using (which depends on which NSS version as well as the build flags for your distribution - e.g. if it's Mozilla-provided Thunderbird vs a distro-provided version), but even there, I suspect Thunderbird-proper hasn't wired up AIA. It should, however, properly handle the scenario where sender sends both, as well as paths that chain to "new certified by old".
It's unclear, however, from your description on your test methodology for the certificate chain. It sounds like you did "(new leaf) <- (new intermediate)" as the actual message contents, but it's unclear if you constructed a chain "(new leaf) <- (new intermediate) <- (new root) <- (old root)" or a chain of "(new leaf) <- (new intermediate) <- (new root), (new leaf) <- (old intermediate) <- (old root)", the latter of which is expected to be problematic.
The test here is:- Sending agent sends certificate bundle that contains their cert, intermediate, and new-signed-by-old
--
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/CAErg%3DHHpnzu2OWdPZ_9535Z0tiztgXMnn3%2BBqVKQA4fr%3DxqNng%40mail.gmail.com.
Hi RyanYou seem to only focus on how the recipient email application will validate a certificate chain it receives. Do you disagree that it is important how the sending email application chooses what chain it will put in the message?