On Tue, 26 Jan 2021 at 16:28, Ramiro Muñoz via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > > El lunes, 25 de enero de 2021 a las 13:31:18 UTC+1, Matthias van de Meent > escribió: > > On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy > > <dev-secur...@lists.mozilla.org> wrote: > > > > > > Thanks everyone for your valuable contribution to the discussion. We’ve > > > prepared a throughful Remediation Plan that addresses all areas of > > > improvement emerged both in this public discussion as well as direct > > > contacts with some of the members > > > https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing. > > > The plan is very ambitious but, we’ve our BoD commitment to align > > > Camerfirma to the highest level of standards of the Mozzilla community. > > > Please feel free send us any request for clarification or any suggestion > > > to improve the attached document. > > In one of your previous replies on this thread you stated the following: > > > > > . We are rethinking the SubCA policy since some of the problems come from > > > there. Camerfirma has increase the control imposing our 3 external SubCA > > > to use the camerfirma central lint control in the pre-isuance process. > > > However, next year we plan to convert external SubCA to Wite label CA, > > > that's means to run them inside Camerfirma infrastructure. > > > > But in this document it looks like this decision has been reverted: > > > > > a. Action Point 10. > > > Insource the management of all the operational activities of the > > > intermediate CAs (June > > 2021). > > > How: > > > - Obligation of the SubCA to use the application of controls defined by > > > Camerfirma (obligation to send us evidence that they have implemented > > > them). > > > - SubCA obligation to submit to audits set by Camerfirma and with an > > > auditor selected by Camerfirma. > > > - Insource management of all the operational activities of the > > > intermediate CAs in a discretionary manner. > > > > > > Resources: Internal resources (Legal). > > > > Specifically, the need for SubCAs to submit to audits implies that > > this SubCA (company) is still in control of the ICA's signing. > > Additionally, the lack of operational resources required for this > > change further reinforces this implication. > > > > As we've seen a lot of problems also stemming from the implementation > > of external SubCAs, this seems like a serious deterioration in > > trustability, as that requires Mozilla to trust Camerfirma to hold the > > SubCA to the requirements of the relevant root stores, while it has > > repeatedly shown not to do that. > > > > Could you explain why you decided to revert that decision? > > > > Regards, > > > > Matthias van de Meent > > Dear Matthias; > > We’ve had the chance to discuss the topic with some of our subCAs and arrived > to the proposed solution. > What we’re proposing is not an immediate insourcing of all SubCAs operational > activities but, a right to do so if and when we deem it necessary. > This means the following: > > 1. SubCAs will be obliged to implement the application controls defined > by Camerfirma > 2. SubCAs will be obliged to submit to audits set by Camerfirma and with > an auditor selected by Camerfirma > 3. SubCAs will accept contractually that Camerfirma can at any time > decide to gain full control of their operational activities > > In such a way we’ll be able, at any timer, to insource the management of > operational activities of our ‘problematic’ intermediate CA. > While virtuous intermediate CA will be allowed to retain the control of their > operational activities as long as they remain virtuous.
Could you share what your definition of 'virtuous' means? This, too, is critical in determining if the trust in your actions (including your actions to keep trusting these SubCAs with key, operational and managemental control of parts of your CA infrastructure) is misplaced or not. And since your SubCAs have a less than virtuous track record, this wording seems out-of-place. > In addition, In our remediation plan we are going to incorporate additional > resources and controls that will allow us to carry out this monitoring with > all guarantees. > However, we are open to discuss further tuning of our remediation plan to > gain the community confident and assure the security and compliance with the > BRs and Mozilla's policies. > _______________________________________________ > 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
