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.
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.
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.
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
confidence”.
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
production.
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 https://misissued.com (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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
