On Tue, Jan 5, 2021 at 9:01 AM Ramiro Muñoz via dev-security-policy <
> 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
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
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. 
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.
> 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.
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
> 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.