Re: Summary of Camerfirma's Compliance Issues
On Friday, January 22, 2021 at 10:01:22 AM UTC-8, Ramiro Muñoz wrote: > El miércoles, 20 de enero de 2021 a las 5:04:27 UTC+1, Matt Palmer escribió: > > On Tue, Jan 19, 2021 at 07:28:17AM -0800, Ramiro Muñoz via > > dev-security-policy wrote: > > > Camerfirma is not the member with the highest number of > > > incidents nor the member with the most severe ones. > > No, but Camerfirma's got a pretty shocking history of poor incident > > response, over an extended period, with no substantive evidence of > > improvement. *That* makes me not want to trust Camerfirma, because I have > > no confidence that problems are being handled in a manner befitting a > > globally-trusted CA. Further, Camerfirma's continued insistence that "it's > > all better now", in the face of all the contrary evidence, does not inspire > > confidence that there will be future improvement. > > > > - Matt > Hi Matt. > > As we recognized previously, we have room for improvement. As we remain open > to suggestions, we are still working a lot on incident response, action > details and language skills. Why exactly should Mozilla trust your record of failure to improve on these after the first, second, third, fourth, fifth, sixth, seventh, eighth, etc. time? Far from getting better Camerfirma continues to have issues with implementing obvious steps to manage risks in the issuance process. It is not the job of members of this forum to tell CAs how to shape up, it's the job of CAs to not misissue certificates. It's actually more important than issuing certificates. Why should I believe that Camerfirma can do the job? We're on to double Latin letters for a CA that has a very small issuance volume over very few years. About once every 1.5 months on average Camerfirma has a deficiency. It's a shocking error rate, made even more shocking by the failure to learn lessons and its worsening over time. Many of the issues stem from a reliance on manual processing and inability or unwillingness to automate routine validity checks, even after the folly of this approach has been made clear. Another class of issues involve failure to properly manage delegation of authority, be it trusting WoSign, uncontrolled CAs not disclosed, etc. A third overarching theme is continued denial and making of excuses. This is not the right attitude a publicly trusted CA should have. Every one of these incidents was an unacceptable violation of trust, that by the terms of inclusion needed to be reported with a detailed answer as to actions taken in response. You've consistently failed to articulate in these incidents a root cause analysis, what steps will be taken to prevent a recurrence, and failed to learn from the failures of other CAs or even your own issues. In several cases commitments Camerfirma made to the community were not followed through on: see issue LL, where commitments from issues J and Z were seemingly undone, and the supposed remediation was incomplete. After issue R, issues T, PP, and RR should have been impossible. It is not your English that is lacking but your candor and sense of duty to the responsibilities with which you have been entrusted. I do not understand how any statements on your part can restore confidence given this record. I do not understand how Mozilla can trust any remediation plan Camerfirma articulates when the past response to incidents has been lackluster, incomplete, and, incredibly, continued to get worse. The proposed remediation actions strike me as woefully insufficient and should have been taken as part of any incident response already. I see no remedy but distrust. Sincerely, Watson Ladd > > Ramiro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla's Response to Camerfirma's Compliance Issues
On Monday, January 25, 2021 at 9:21:53 PM UTC-8, Ben Wilson wrote: > Dear All, > > We appreciate your comments and participation in the discussion about the > Summary of Camerfirma's Compliance Issues, > https://wiki.mozilla.org/CA:Camerfirma_Issues. > > Mozilla has not yet made a decision about Camerfirma's continuation in our > root store. We intend to continue with our public discussion process to > determine whether Camerfirma's root certificates can remain included in > Mozilla's root store, and what actions they need to take. > > Camerfirma has responded to the list of issues by providing a Remediation > Plan, > https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing, > > with a commitment to align Camerfirma to the highest level of standards of > the Mozilla community. > > They asked if there are parts of the Remediation Plan that need > clarification and for suggestions to improve the Remediation Plan. > > We will appreciate your constructive feedback on it. > > - Do the proposed actions in the Remediation Plan address the underlying > issues? In my opinion they do not. Camerfirma has demonstrated that they do not know what good management is, yet they ask us to trust in their ability to evaluate their sub CAs. Camerfirma has a history of not following through on their commitments, with multiple incidents with similar root causes despite committed to addressing the root causes. Camerfirma seems to depend on human evaluation in the issuance process to an alarming extent. I think it's worth revising the BRs to require extensive process automation. > > - 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 don't think this plan goes beyond what a reasonable person would have done in response to the incidents. It's too little, too late. The repetition of already existing commitments is alarming. Either they reneged then, or they are lying now. > > - Do you have additional recommendations for steps that you think > Camerfirma should take? Camerfirma should at minimum insource all subCA operations. Camerfirma should automate all BR requirements and steps in the issuance process that is humanly possible to automate, and ensure that all manual actions are reviewed independently before and after being acted upon. Camerfirma should also replace its current legal counsel with a competent one, and ask them to review all existing subscriber agreements and other contracts and the BRs and Mozilla root program requirements and determine if any conflicts exist, and if so remedy them. If conflicts are unresolveable Camerfirma should be distrusted. Camerfirma should halt all issuance until the plan is implemented. Given the extent of the possible SubCA problems all issuance from the old roots should sunset or be limited to explicitly disclosed intermediate certificates, no new ones created. Then new roots should be created and a de novo application for inclusion created. I'm not sure even this would assauge my worries. Ultimately the trust one can place in individuals is dependent upon their character, and Camerfirma has a history of being dilatory and lackadaisical with critically important issues, and I'm not sure what can change that kind of organizational rot. Sincerely, Watson Ladd > > Thanks, > > Ben ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Summary of Camerfirma's Compliance Issues
On Sunday, January 24, 2021 at 11:58:29 AM UTC-8, Ramiro Muñoz 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. The remediation plan seems to raise, not eliminate issues: - Action point 1 raises the possibility that anomalous actions are possible. Why aren't the issuance processes automated and logged already? - Action point 2 will not work. Humans are bad at monitoring for rare conditions. Some of the issues were not misspellings or confusion over the name of a company, but syntactic defects that machines could detect. It should at minimum be paired with automated validation. - Action point 5 should already be achieved as a result of commitments made in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 - Action point 9 should be trivial. But it isn't. Why not? Beyond that all of these are actions that should have been undertaken in remediation of the past issues when they happened. I see very little that would remediate the risks of missussance, such as e.g exiting the sub-CA business, and migrating to a proven CA infrastructure rather than the homegrown one that seems to give operators plenty of scope to make mistakes. There's no issuance freeze to permit these necessary controls to be in place before resuming. Sincerely, Watson Ladd > > Thanks for your contribution. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report
On Monday, February 15, 2021 at 3:07:12 PM UTC-8, Jeff Ward wrote: > On Monday, February 15, 2021 at 4:11:15 PM UTC-6, Ryan Sleevi wrote: > > Apologies for belaboring the point, but I think we might be talking past > > eachother. > > > > You originally stated “The only place I am aware that lists the audit > > partner in a comparable world is the signing audit partner on public > > company audits in the US, which is available on the SEC website.” I gave > > two separate examples of such, and you responded to one (FPKI) by saying > > the report was not public (even when it is made available publicly), and > > the other I didn’t see a response to. > > > > This might feel like nit-picking, but I think this is a rather serious > > point to work through, because I don’t think you’re fully communicating > > what you judge to be a “comparable world”, as it appears you are dismissing > > these examples. > > > > I can think of several possible dimensions you might be thinking are > > relevant, but rather than assume, I’m hoping you can expand with a few > > simple questions. Some admittedly seem basic, but I don’t want to take > > anything for granted here. > > > > 1) Are you/the WTTF familiar with these audit schemes? > > > > 2) Are you aware of schemes that require disclosing the relevant skills and > > experience of the audit team to the client? (E.g. as done by BSI C5 audits > > under ISAE 3000) > > > > 3) Are you aware of such reports naming multiple parties for the use of the > > report (e.g. as done by FPKI audits) > > > > 4) Are you aware of schemes in which a supplier requires a vendor to be > > audited, and ensures that the customer of supplier are able to access such > > audits as part of their reliance upon supplier? (Note, this doesn’t have to > > be limited to ISMS systems) > > > > I’m trying to understand what, given the prevalence of these practices, > > makes these instances *not* a comparable world, since it seems that helps > > move closer to solutions. > Ryan, I hope you are not suggesting I am dodging you points. That would be > absurd. Let me use different words as comparable world seems to be tripping > you up. You are not providing a general/public distribution example to make > your point so it is baseless. You are using a restricted opinion from EY and > neither Ryan Sleevi nor Google are listed as the two intended users. The > closest I have seen to support your desire to name individual auditors is in > public company audit reports, which are housed on the SEC website. To be > clear, of your two examples, one is an opinion, which is restricted, and the > other represents the guidelines. Perhaps you have seen a public/general > distribution report from your second opinion as I do not see it in this > thread. I am aware, as mentioned previously, of the Federal PKI program > desiring to know more about team members, but that is not listed in a > non-restricted report, in a public/general distribution format. I can click on the URL and read it. This seems to be the very definition of public, even if the audit report says it is not for reliance upon by the general public. I fully appreciate that this may be a technicality in the world of auditing, but it is very confusing to those of us who are less familiar. > Jeff ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
