Hi Ben, Ryan and All. Sorry for the delay in answering this communication in this channel. Even though we have been in contact with Ben from the very moment we were notified, a prompt answer to the community is convenient as Ryan said.
Camerfirma is working to deliver a detailed report to transmit our improvements in these years. Obviously, we were not succeeded to do it in the different bugs we have reported so far. We plan to send it to mdsp next Tuesday. We have fixed most of the issues reported as we will try to explain, but we are aware that other persist despite the remediation measures adopted. Summarizing: . We have increased the PKI team to managing the bugs and administrative task to avoid delays in notifications, responses and CCADB management. We honestly think that we have made significant improvements in this area. Nevertheless, we plan to increase the resources this year to be more active in the community and understand deeply the BR and Mozilla requirement that have been root cause of some bugs. . We have developed automations in the certificate issuing process, pre-issuing, and post-issuing. We plan to keep on doing this, like integrate ACME or develop a suspicions activity detection in our platform like certificate revocations with a short period of live time. . 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. Regarding RA we already closed all the external RA for SSL certificates keeping only one inside our company group. . We are working with our customers to face a certificate substitution process honouring the timeline requested by the Mozilla policy and the BR. We also work with the camerfirma internal high management to assume that some damage could be produced to our customers services because an unilateral revocation by the CA. This is the most difficult issue to manage and the only way to resolve it is avoiding mistakes. We think that the community should rethink the misissued revocation timeline requirement, at least to increase the number of user cases. Finally, emphasize that in anyway Camerfirma try or have consciously mislead the community and our aim is to act transparently in order to be a valuable member of this community. KR Ramiro -----Mensaje original----- De: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> En nombre de Ryan Sleevi via dev-security-policy Enviado el: jueves, 10 de diciembre de 2020 21:44 Para: Ben Wilson <bwil...@mozilla.com> CC: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Asunto: Re: Summary of Camerfirma's Compliance Issues Hi Ben, This is clearly a portrait of a CA that, like those that came before [1][2][3][4], paint a pattern of a CA that consistently and regularly fails to meet program requirements, in a way that clearly demonstrates these are systemic and architectural issues. As with Symantec, we see a systematic failure to appropriately supervise RAs and Sub-CAs. As with Procert, we see systemic technical failures continuing to occur. We also see problematic practices here of revocations happening without a systemic examination about why, which leads them to overlook incident reports. As with Visa, we see significant issues with their audits that are fundamentally irreconcilable. As called out in [5] (Issue JJ), short of distrusting their certificates, there isn't a path forward here. I'm concerned that there's been no response from Camerfirma, even acknowledging this publicly, as is the norm. I wanted to give a week, even to allow for a simple acknowledgement, since Mozilla Policy requires that CAs MUST follow and be aware of discussions here, above and beyond your direct communication with them pointing this out. Given that there haven't been corrections proposed yet, is it appropriate to begin discussing what next steps should be to protect users? [1] https://wiki.mozilla.org/CA:PROCERT_Issues [2] https://wiki.mozilla.org/CA:Visa_Issues [3] https://wiki.mozilla.org/CA:Symantec_Issues [4] https://wiki.mozilla.org/CA:WoSign_Issues [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1583470#c3 On Thu, Dec 3, 2020 at 1:01 PM Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > We have prepared an issues list as a summary of Camerfirma's > compliance issues over the past several years. The purpose of the list > is to collect and document all issues and responses in one place so > that an overall picture can be seen by the community. The document is on the > Mozilla wiki: > https://wiki.mozilla.org/CA:Camerfirma_Issues. > <https://wiki.mozilla.org/CA:Camerfirma_Issues> > > I will now forward the link above to Camerfirma to provide them with a > proper opportunity to respond to the issues raised and to ask that > they respond directly in m.d.s.p. with any comments, corrections, > inputs, or updates that they may have. > > If anyone in this group believes they have an issue appropriate to add > to the list, please send an email to certifica...@mozilla.org. > > Sincerely yours, > Ben Wilson > Mozilla Root Program > _______________________________________________ > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
