El martes, 5 de enero de 2021 a las 16:45:11 UTC+1, Ryan Sleevi escribió: > On Tue, Jan 5, 2021 at 9:01 AM Ramiro Muñoz via dev-security-policy < > dev-secur...@lists.mozilla.org> wrote: > > > In response to Ryan’s latest post, we want to provide the community with > > Camerfirma’s due responses and we hope this clears up any doubts that might > > have arisen. > > > > Ryan argument number 1: “These statements are ones that are sort of "true > > by degree". That is, if I was to dispute 1, Camerfirma would/could > > rightfully point out that they were *much* worse before, and so yes, it's > > true that they've improved.” > > 1. Camerfirma has made huge improvements. > > > > Camerfirma has improved its operations to avoid errors. We have procedures > > in place to incentivate improvement in every level in our operations. We > > shall continue to work in this way in the future. > > We have worked to automate internal processes, also improving the > > management and level of attention on each incident. We have involved more > > experts in the process. Our goal has always been to meet the highest > > demands, including monitoring of CA activities that Mozilla has been > > implementing over the past years. > > In addition, Camerfirma publishes SSL certificates in the CT, EV since > > (May 2016) and OV since (April 2017) ( even if it was mandatory only from > > April 30, 2018). We have always been in favour of increasing transparency > > and providing useful information to the community. > > We have implemented several improvements during 2019 and 2020 (as we have > > already mentioned in previous reports): > > > > • Decreased response time and increased attention to incidents. As a > > result, we have eliminated communications failures and we have avoided > > response delays (2020). > > • Use of a centralized lint. Our three unconstrained subCA > > (Multicert, Infocert and Intesa Sao Paolo) with codification errors in > > issued certificates were added to our centralized lint. The first one since > > March 2019 and the other two since April 2019. > > • Contractual cover of unilateral revocations with the subCAs has > > been clarified and streamlined. (October 2019). > > • Mass revocation processes have been implemented (June 2020). > > • Verification of CAA has been revised and reinforced with automatic > > procedures (June 2020). > > • Control zlint has been implemented, both at pre-issuance and > > post-issuance (January 2019). > > • Syntax control of the domain (August 2020) > > • Additional automatic control to verify the correctness of AKI > > extension before certificate issuance has been implemented (April 2020). > > > > In addition, Camerfirma periodically evaluates the efficacy of these > > measures and every other improvement implemented. > > > I understand why Camerfirma feels it important to exhaustively list these > things, but I think the Wiki page, and its details, provides a much more > honest look at these. The adoption of Certificate Transparency before it > was mandatory, for example, does not highlight Camerfirma's leadership in > the area: it reveals how many issues Camerfirma's own management was > letting through its quality control processes, even though tools readily > existed to prevent this. The centralized lints for sub-CAs, for example, > were not imposed proactively to prevent incidents, but reactively in > response to a failure to supervise sub-CAs. Each of these improvements you > list, while there are some improvements, have been reactive in nature, > after Camerfirma has been shown to repeatedly fail to meet the basic > expectations of CAs, fail to detect this, and have the community highlight > it. > > Perhaps no greater example of this can be found than "Syntax control of the > domain", implemented in August 2020, despite issues having been raised in > 2017 highlighting the importance of this requirement. [1] > > What Camerfirma has done here has list the controls they've implemented in > response to their specific incidents, which, while important, overlooks > that many of these were basic expectations that would have prevented > incidents. This is akin to a student asking for full credit for a paper > they turned in a semester late, on the principle that they at least turned > it in, even after their (failing) grade had already been received. > > [1] > https://groups.google.com/g/mozilla.dev.security.policy/c/D0poUHqiYMw/m/Pf5p0kB7CAAJ > > > > > > > Ryan argument number 2: “Similarly, to point out at how laughably bad the > > old system was does show that there is a degree of truth in 2” > > 2. Camerfirma nowadays has a much more mature management system. > > > > Subjective opinions aside, the community bug reports from the last 4 years > > show the improvement and efficacy of controls in Camerfirma's systems and > > procedures: > > > > CAMERFIRMA InfoCert MULTICERT > > DIGITALSIGN CGCOM TOTAL > > BUGS 2020 1 3 2 > > 0 1 7 > > BUGS 2019 5 1 1 > > 0 0 7 > > BUGS 2018 4 1 2 > > 1 0 8 > > BUGS 2017 5 1 0 > > 0 0 6 > > TOTAL 15 6 5 > > 1 1 28 > > > > Regarding the nature of the errors, the bug associated with Camerfirma’ s > > systems in the last year (2020) was: > > • #1623384 AKI issue encountered due to the incomplete templates in > > the certificate model. The modification of the profile correction procedure > > and establishment of an additional automatic control to verify the AKI > > before the issue of certificates was implemented in a timely manner. > > > > If we consider also bugs concerning the external SubCAs, the total number > > of bugs registered in 2020 is in line with the previous years. In order to > > extend to subCAs the same rate of improvement registered by Camerfirma > > we’ve proposed to obtain the contractual right and the operational > > procedures in place to insource the management of all the operational > > activities of subCAs. > > > Alternatively, this highlights that, throughout the years, Camerfirma has > failed to appropriately supervise sub-CAs. > > > > > > Ryan argument number 3: “…and, as I laid out in my own post, Camerfirma > > *is* not very different from other CAs - CAs that have been distrusted, for > > not very different reasons than Camerfirma. I'm sure Camerfirma meant to > > mean "not much different than other *currently trusted* CAs", but that's > > equally a degree of truth - many individual incidents affected other CAs, > > even though the sheer volume *and nature* of Camerfirma bugs is troubling. > > 3. Camerfirma is not very different from other (trusted) CAs. > > > > Obviously, when we state that the reported errors do not differ from other > > CAs, we mean that we see in those trusted CAs a situation similar to the > > one we have stated. Stating otherwise is a strawman fallacy. > > In no way Camerfirma could be compared with more critical cases such as > > WoSign or Diginotar, as it might be implied in Ryan messages. These > > messages risk to give a misleading view to the entire community. The WoSign > > ot Diginotar incidents had direct effects on the security of the system > > with the possibility of issuing fraudolent certificates with devastating > > consequences. Those sort of incidents cannot – and shall not - be related > > at all with Camerfirma’s situation. > > It is obvious that some unfair comments give an extremely negative image > > of our company, implying lack of collaboration or willful deception to > > community requests that do not represent the real situation. > > > Absolutely, Camerfirma is, subjectively, as bad or worse than WoSign and > DigiNotar right here. Camerfirma's focus on "Well, nothing _really_ bad > happened here" underscores exactly the risk of continued trust in > Camerfirma. What we have here is an undeniable pattern of issues, from a > failure to understand requirements, a failure to supervise subordinates, > and a failure to implement appropriate controls. At the core, all of these > issues similar to those faced by WoSign and DigiNotar. DigiNotar's biggest > mistake was not getting compromised, for example, but the failure to report > that compromise in a timely fashion that could have allowed immediate > action to take place. From Camerfirma's incidents, we see that same hubris > and misunderstanding of what it means to be a trusted CA. We see a failure > to timely detect and report issues, from both Camerfirma and its > subordinates, and a failure to appropriately design systems robust to > ensure prompt action can be taken. Indeed, Camerfirma's argument here is > that, despite repeated incidents year over year, they're "finally" in a > place to now observe the Baseline Requirements as they existed in 2015. > This is not something we should praise Camerfirma for. > > Ryan argument number 5: “…similarly, the risk in removing trust is > > exceedingly low, which helps show the "risk to current users" (from > > trusting) versus the "risk of breaking things" (by distrusting) is not a > > major consideration.” > > > > We do not understand the risk assessment carried out here; it seems to be > > based on the aphorism "not too big to fall" which is not a fair or > > realistic parameter in terms of the possibility of evaluating incidents > > according to the number of certificates issued by a CA. Stating that the > > number of certificates issued would be a parameter when deciding if a CA > > should be distrusted, could lead to favouring monopolistic business > > practices. > > > > Risk is a probabilistic parameter to be used with the impacts produced. > The risk Mozilla, and any other root program, must contend with, is the > risk to their users. Camerfirma's practices reveal poor management, poor > incident response, poor understanding of expectations, and poor awareness > of industry trends and practices, all of which are required. The risk > Camerfirma highlights is the risk to their business, which is unsurprising, > but that risk is clearly outweighed by the risk to the community of users. > In this set, all users must be considered, as every single user is affected > by the failure of Camerfirma. This is not about "too big to fail", of which > there is demonstrably no such thing, but about understanding the > compatability risk to the users who rely on Camerfirma certificates > regularly, who would be affected by a removal of trust, compared to the > risk to all the users who do not rely on such certificates, but would and > are affected by Camerfirma's failures. > > That Camerfirma does not understand or express appreciation for this risk > is, to the extent, of great cause for concern.
Dear Ryan, We are looking at the same data but we’re reading two completely different stories. We are reading a story of a small CA that had its own graduation journey, struggled but eventually managed to emerge stronger from such journey. You are reading a story of deceitful and unreliable CA that represents the worst danger to the entire community (your even wrote: “Camerfirma is as bad or worse than WoSign and DigiNotar”!), even if you yourself recognised that was your subjective opinion on the matter. It is a huge distance in interpreting the same data and this subjectiveness do not guarantee a fair governance of our community. Finally We are not saying we have not had issues during the time we have been operational. It may be more conducive for future discussions to not overlook the fact that any risk analysis involves not only risk identification but also the identification of the qualitative and quantitative impact of the risk event. All the best, _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
