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 
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.

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       
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.

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 
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.

Ryan argument number 4: “This is an issue of judgement here, about whether or 
not the degree of truth to these statements adequately reflects the very risk 
that continued trust in Camerfirma poses. The sheer volume of bugs do help 
paint a trendline, which is what Camerfirma is arguing here, but just there's a 
big difference between y = x + x, y = x * x, and y = x ^ x, there's a big 
difference in the nature of the incidents, the quality of response, and the 
(lack of) a meaningful rate of improvement that don't really inspire 

Camerfirma does not agree that the trend and nature of the bugs were different, 
nor that our bugs are multiplying or enhancing rather than adding up. We have 
always been open and transparent, but we shall try to be even more so.

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. 

In Camerfirma’s case, a certificate with a wrong character in the Organization 
name, or a problem with an audit date has been issued, but never was a serious 
impact produced that put the community at risk. We do not mean to ignore these 
incidents but, simply to take into consideration the real impact/danger they’ve 
produced on the community. As stated before, in the WoSign or Diginotar cases, 
we have had misissued certificates capable of replacing the identity of public 
website with serious and potentially devastating impacts, which by no means 
could compare with Camerfirma case.
Accepting any phrase such as “ the risk in removing trust is exceedingly low” 
without true statistical analysis could become a precedent towards the 
elimination of more CAs in the ecosystem even when striving to uphold the best 
business practices.

Ryan argument number 6. “I would be curious if folks believe there is evidence 
that is being overlooked from the Wiki, or believe that there is a different 
perspective that can be reached from that data, and if they'd like to show how 
and why they reached that conclusion. I have shared my perspective, but value 
learning more if others do see things differently.”

Camerfirma appeals to the community to fairly evaluate the number and the 
nature of incidents reported as well as the improvements made by Camerfirma to 
maintain the trust in our certificates. In addition to the above mentioned 
actions already completed, Camerfirma presents a series of 10 measures -already 
mentioned in our previous communications- that will further reinforce 
transparency and quality in the life cycle management processes of 
certificates, while maintaining strict compliance with BR and Mozilla policies. 
We highlight in brackets the dates already planned for putting them into 

1.      Control of outlier activity patterns (March 2021).
2.      Replace information not expressly validated in the certificate 
attributes with standardized values to avoid human errors. (March 2021)
3.      Use of (from January 2021)
4.      Specific enhancements to the Business Category and StateofProvinceName 
fields that assist the RA requester and operator. (January 2021)
5.      Audit of the totality (100%) of the certificates issued during 
January-february 2021.
6.      Dedication of exclusive resources for the issuance of SSL certificates 
for compliance activities. (March 2021)
7.      Proactive activities in the CA/B forum WG. (February 2021)
8.      Exclusive dedication of developers on the improvement of automatic 
controls in the process of managing the life cycle of SSL certificates. 
Implementation of ACME for automatic certificate replacement (June 2021).
9.      Limit the number of DNS names that can appear in a certificate to make 
the substitution easier (planned for March 2021 for Camerfirma infrastructure 
and to be designed for the Intermediate CAs).
10.     Insource the management of all the operational activities of the 
intermediate CAs (June 2021).

These controls will reinforce transparency in the life cycle management 
processes of the certificates issued, while maintaining strict compliance with 
BR and Mozilla policies.
We hope to have addressed in depth the doubts that Ryan stated in his latest 
contribution, and are available to further clarification in case anyone would 
like to comment.

dev-security-policy mailing list

Reply via email to