Hi Ryan Thanks. We will take into account your observations. As I said we planed to send the formal answer today but the team has asked me for more time in order to give a more accurate answer. We plan to postpone to this Friday.
KR Ramiro De: Ryan Sleevi <r...@sleevi.com> Enviado el: lunes, 14 de diciembre de 2020 22:41 Para: Ramiro Muñoz <rami...@camerfirma.com> CC: r...@sleevi.com; Ben Wilson <bwil...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Asunto: Re: Summary of Camerfirma's Compliance Issues Thanks Ramiro for the update. I do want to make sure we're on the same page. Responding point-by-point to the issues would probably be the least productive path forward. If there are specific disagreements with the facts as presented, which were taken from the Bugzilla reports, it would be good to highlight that. However, I believe the intent is that the Bugzilla report is the source of truth, so if there are details that were *not* on the incident reports, I would say that's more concerning than it is reassuring. I'm a bit concerned to see your latest reply still highlight the "increased the PKI team", since that's been a sort of repeated refrain (e.g. Issue T, Issue BB, Issue PP). I don't disagree that it's important to ensure that there are adequate resources devoted to compliance _and_ development, but I think it's also important to make sure that the solution is not to throw more people at the problem. While the integrity of the CA is perhaps not as obviously cut and dry, as was the case with WoSign/StartCom, I do believe it's reasonable to ask whether or not the CA has the skills, expertise, and understanding of the systemic issues to effectively manage things going forward, especially when we have seen the regular repetition of issues. This suggests more systemic fixes are needed, but also suggests that there are more systemic flaws in how things are operated, designed, and administered that do call into question the trustworthiness of the current infrastructure. If Camerfirma were approaching with a new CA/new certificate hierarchy, it would be reasonable to ask why, given all of these incidents, Camerfirma should be included, since it puts a lot of risk onto the community. Regaining trust and reputation, once lost, is incredibly difficult, and requires going above and beyond. I hope that, in your formal response, you provide a holistic picture of how Camerfirma has changed its operations, implementation, infrastructure, management process, policies, and quite frankly, the use cases/subscribers that it targets with these certificates, so that the community can make an informed decision about risk. Similarly, in thinking about what this would be for a "new" PKI, and how difficult it would be, given the current evidence, to see that as good for users, it's also worth asking what should happen with the current PKI. Should we continue to assume that the implementation of the EV guidelines is correct, even though we have ample evidence of basic RFC 5280 and BR violations? Should we consider sunsetting (e.g. with a notBefore restriction) trust? Would it be reasonable to remove trust altogether? For example, Camerfirma currently has four roots ([1], [2], [3], [4]). [1] appears to have issued less than 3,500 still valid certificates, [2] / [3] are only trusted for e-mail, and [4] seems to be a super-CA of sorts (with sub-CAs operated by Intesa Sanpaolo, Infocert, Multicert, and Govern d'Andorra). For the sub-CAs that aren't constrained/revoked, it seems Intesa Sanpaolo has only issued ~2200 certificates, Infocert ~650, and Multicert ~3000. Is that accurate? I totally could have made a mistake here, since this was just manually inspecting every sub-CA from Camerfirma and I totally could have clicked wrong, but that suggests that there is... very little practical risk here to removal, compared to the rather significant risk of having a CA that has established a pattern of compliance and supervision issues. [1] https://crt.sh/?caid=869 [2] https://crt.sh/?caid=140 [3] https://crt.sh/?caid=8453 [4] https://crt.sh/?caid=1114 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
