On Tue, Jan 5, 2021 at 9:01 AM Ramiro Muñoz via dev-security-policy <
dev-security-policy@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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to