On Tue, 26 Jan 2021 at 06:21, Ben Wilson via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > > - Do the proposed actions in the Remediation Plan address the underlying > issues?
One of the underlying issues is that Camerfirma has multiple SubCAs with each their own control over ICA keys, CPS, certificate profiles, conformance and validation. As the proposed plan doesn't seem to remove all of those (reasons mentioned in the other thread), I do not think this Remediation Plan addresses that part of the concern. > - If Camerfirma fully executes on this plan, will that be sufficient to > regain trust so that they can remain a CA in Mozilla's root store? I find it difficult to trust in a CA that supplies other companies with unconstrained ICAs. One CA can have a few classes of problems, but now we have one CA which has their own classes of problems, plus the problems of their SubCAs. As we've seen before, and probably will continue to see in the future; unconstrained SubCAs that are not direct part of a root program are an antipattern for public trust. It can provide a false impression of "the CA didn't make the mistake, the SubCA did", whereas the mistakes of the SubCA _are_ the mistakes of the CA due to the delegation of trust by the CA to the SubCA; any mistakes made by that SubCA (trust-wise) are the mistakes of the CA as long as the SubCA is valid. I have not seen much improvement in communication, self-reporting and problem resolving of problems with regards to Camerfirma's SubCAs, nor have I seen substantial improvements in Camerfirmas' stance regarding their SubCAs. If this was only about the CA activities of Camerfirma (excluding the SubCAs), the improvements would scrape the bottom, but the existence of externally managed SubCAs more than triple the risks involved. > - Do you have additional recommendations for steps that you think > Camerfirma should take? - Stop using the current roots / request removal of current roots / revoke all external SubCAs. - Start a new root of trust (the current roots are 'poisoned' due to the delegated OCSP responder issue and missing key destruction audits of some of said OCSP responder keys). - Operate all of the CA infrastructure of this new root of trust without delegating any of keys, management, validation, and operations to SubCAs. - Ensure that you comply to the BR and relevant root store policies and that you can respond to problems promptly. - Then, and only then, request inclusion of the new root(s) into the relevant root stores. Regards, Matthias van de Meent _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
