On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy
<dev-security-policy@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
> 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?


Matthias van de Meent
dev-security-policy mailing list

Reply via email to