Ben, Here are my thoughts:
- First off, we have given Camerfirma the benefit of the doubt for too long and Mozilla can't continue to trust Camerfirma while they remediate these problems. With all the documented issues and Camerfirma's response, that would represent an unacceptable ongoing risk to Mozilla's users. Distrust is the first step. - While most documented incidents are related to TLS certificates, I see nothing to indicate that Camerfirma manages S/MIME any better. It's more likely that we simply don't know about many of the email certificate issues due to the lack of CT enforcement. Mozilla should act to protect Thunderbird users as well. - Given the number of issues that have been documented with Camerfirma's delegated SubCAs, any remediation plan that has them keeping control of CA certificates is a non-starter for me. Having said that, I don't think Mozilla should forbid future delegated SubCAs, but rather require Camerfirma to gain approval for each one (as is currently required by section 8.1 of the Mozilla Root Store Policy). - Camerfirma's current certificate hierarchies are quite outdated and represent a significant risk independent of their operator. They must be replaced as part of any remediation plan. - To regain trust, Camerfirma will need to take adequate time to complete the remediations they have outlined and present evidence of the improvements from their auditor as part of a new root inclusion request. Thanks, Wayne On Tue, Jan 26, 2021 at 4:01 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > So far there have been several good comments. Please keep them coming. > > I want to take this opportunity just to clarify a few of things. > > First, it has been Mozilla's long-standing position that, "We believe that > the best approach to safeguarding secure browsing is to work with CAs as > partners, to foster open and frank communication, and to be diligent in > looking for ways to keep our users safe." So, expect that we will take a > well-thought and deliberate approach to this issue with Camerfirma. > > Second, many of the compliance issues have dealt with requirements > applicable to server certificates, yet only two roots of the four trusted > by Mozilla have the websites bit enabled. > > Chambers of Commerce Root – 2008 (Email and Websites) > > 063E4AFAC491DFD332F3089B8542E94617D893D7FE944E10A7937EE29D9693C0 > > Global Chambersign Root – 2008 (Email and Websites) > > 136335439334A7698016A0D324DE72284E079D7B5220BB8FBD747816EEBEBACA > > Chambers of Commerce Root (Email only) > > 0C258A12A5674AEF25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3 > > Global Chambersign Root (Email only) > > EF3CB417FC8EBF6F97876C9E4ECE39DE1EA5FE649141D1028B7D11C0B2298CED > So there is another issue that needs to be considered, if distrust is > chosen, whether to remove just the websites trust bit or to take action > against all 4 roots, and if so, on what basis? > > (Also, note that Camerfirma has two other roots that are not included in > the Mozilla trust store. They are the CHAMBERS OF COMMERCE ROOT – 2016 and > the GLOBAL CHAMBERSIGN ROOT - 2016.) > > Thanks, > > Ben > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
