Summary of Camerfirma's Compliance Issues

1509 views
Skip to first unread message

Ben Wilson

unread,
Dec 3, 2020, 1:01:55 PM12/3/20
to mozilla-dev-security-policy
All,

We have prepared an issues list as a summary of Camerfirma's compliance
issues over the past several years. The purpose of the list is to collect
and document all issues and responses in one place so that an overall
picture can be seen by the community. The document is on the Mozilla wiki:
https://wiki.mozilla.org/CA:Camerfirma_Issues.
<https://wiki.mozilla.org/CA:Camerfirma_Issues>

I will now forward the link above to Camerfirma to provide them with a
proper opportunity to respond to the issues raised and to ask that they
respond directly in m.d.s.p. with any comments, corrections, inputs, or
updates that they may have.

If anyone in this group believes they have an issue appropriate to add to
the list, please send an email to certif...@mozilla.org.

Sincerely yours,
Ben Wilson
Mozilla Root Program

Ryan Sleevi

unread,
Dec 10, 2020, 3:44:12 PM12/10/20
to Ben Wilson, mozilla-dev-security-policy
Hi Ben,

This is clearly a portrait of a CA that, like those that came before
[1][2][3][4], paint a pattern of a CA that consistently and regularly fails
to meet program requirements, in a way that clearly demonstrates these are
systemic and architectural issues.

As with Symantec, we see a systematic failure to appropriately supervise
RAs and Sub-CAs.
As with Procert, we see systemic technical failures continuing to occur. We
also see problematic practices here of revocations happening without a
systemic examination about why, which leads them to overlook incident
reports.
As with Visa, we see significant issues with their audits that are
fundamentally irreconcilable. As called out in [5] (Issue JJ), short of
distrusting their certificates, there isn't a path forward here.

I'm concerned that there's been no response from Camerfirma, even
acknowledging this publicly, as is the norm. I wanted to give a week, even
to allow for a simple acknowledgement, since Mozilla Policy requires that
CAs MUST follow and be aware of discussions here, above and beyond your
direct communication with them pointing this out.

Given that there haven't been corrections proposed yet, is it appropriate
to begin discussing what next steps should be to protect users?

[1] https://wiki.mozilla.org/CA:PROCERT_Issues
[2] https://wiki.mozilla.org/CA:Visa_Issues
[3] https://wiki.mozilla.org/CA:Symantec_Issues
[4] https://wiki.mozilla.org/CA:WoSign_Issues
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1583470#c3
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Ramiro Muñoz

unread,
Dec 10, 2020, 6:35:03 PM12/10/20
to ry...@sleevi.com, Ben Wilson, mozilla-dev-security-policy
Hi Ryan

Camerfirma is working writing a complete answer to Ben comunicación. Ben has been informed from the first day. Hope we can send it in the next days.

Regards
Ramiro



Obtener Outlook para Android<https://aka.ms/ghei36>

________________________________
De: dev-security-policy <dev-security-...@lists.mozilla.org> en nombre de Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org>
Enviado: jueves, 10 de diciembre de 2020 21:44
Para: Ben Wilson
Cc: mozilla-dev-security-policy
Asunto: Re: Summary of Camerfirma's Compliance Issues

Ramiro Muñoz

unread,
Dec 13, 2020, 1:02:28 PM12/13/20
to ry...@sleevi.com, Ben Wilson, mozilla-dev-security-policy
Hi Ben, Ryan and All.

Sorry for the delay in answering this communication in this channel. Even though we have been in contact with Ben from the very moment we were notified, a prompt answer to the community is convenient as Ryan said.

Camerfirma is working to deliver a detailed report to transmit our improvements in these years. Obviously, we were not succeeded to do it in the different bugs we have reported so far. We plan to send it to mdsp next Tuesday.

We have fixed most of the issues reported as we will try to explain, but we are aware that other persist despite the remediation measures adopted.

Summarizing:

. We have increased the PKI team to managing the bugs and administrative task to avoid delays in notifications, responses and CCADB management. We honestly think that we have made significant improvements in this area. Nevertheless, we plan to increase the resources this year to be more active in the community and understand deeply the BR and Mozilla requirement that have been root cause of some bugs.

. We have developed automations in the certificate issuing process, pre-issuing, and post-issuing. We plan to keep on doing this, like integrate ACME or develop a suspicions activity detection in our platform like certificate revocations with a short period of live time.

. We are rethinking the SubCA policy since some of the problems come from there. Camerfirma has increase the control imposing our 3 external SubCA to use the camerfirma central lint control in the pre-isuance process. However, next year we plan to convert external SubCA to Wite label CA, that's means to run them inside Camerfirma infrastructure. Regarding RA we already closed all the external RA for SSL certificates keeping only one inside our company group.

. We are working with our customers to face a certificate substitution process honouring the timeline requested by the Mozilla policy and the BR. We also work with the camerfirma internal high management to assume that some damage could be produced to our customers services because an unilateral revocation by the CA. This is the most difficult issue to manage and the only way to resolve it is avoiding mistakes. We think that the community should rethink the misissued revocation timeline requirement, at least to increase the number of user cases.

Finally, emphasize that in anyway Camerfirma try or have consciously mislead the community and our aim is to act transparently in order to be a valuable member of this community.

KR
Ramiro

-----Mensaje original-----
De: dev-security-policy <dev-security-...@lists.mozilla.org> En nombre de Ryan Sleevi via dev-security-policy
Enviado el: jueves, 10 de diciembre de 2020 21:44
Para: Ben Wilson <bwi...@mozilla.com>
CC: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>

Ryan Sleevi

unread,
Dec 14, 2020, 4:41:20 PM12/14/20
to Ramiro Muñoz, ry...@sleevi.com, Ben Wilson, mozilla-dev-security-policy
Thanks Ramiro for the update.

I do want to make sure we're on the same page. Responding point-by-point to
the issues would probably be the least productive path forward. If there
are specific disagreements with the facts as presented, which were taken
from the Bugzilla reports, it would be good to highlight that. However, I
believe the intent is that the Bugzilla report is the source of truth, so
if there are details that were *not* on the incident reports, I would say
that's more concerning than it is reassuring.

I'm a bit concerned to see your latest reply still highlight the "increased
the PKI team", since that's been a sort of repeated refrain (e.g. Issue T,
Issue BB, Issue PP). I don't disagree that it's important to ensure that
there are adequate resources devoted to compliance _and_ development, but I
think it's also important to make sure that the solution is not to throw
more people at the problem.

While the integrity of the CA is perhaps not as obviously cut and dry, as
was the case with WoSign/StartCom, I do believe it's reasonable to ask
whether or not the CA has the skills, expertise, and understanding of the
systemic issues to effectively manage things going forward, especially when
we have seen the regular repetition of issues. This suggests more systemic
fixes are needed, but also suggests that there are more systemic flaws in
how things are operated, designed, and administered that do call into
question the trustworthiness of the current infrastructure.

If Camerfirma were approaching with a new CA/new certificate hierarchy, it
would be reasonable to ask why, given all of these incidents, Camerfirma
should be included, since it puts a lot of risk onto the community.
Regaining trust and reputation, once lost, is incredibly difficult, and
requires going above and beyond. I hope that, in your formal response, you
provide a holistic picture of how Camerfirma has changed its operations,
implementation, infrastructure, management process, policies, and quite
frankly, the use cases/subscribers that it targets with these certificates,
so that the community can make an informed decision about risk.

Similarly, in thinking about what this would be for a "new" PKI, and how
difficult it would be, given the current evidence, to see that as good for
users, it's also worth asking what should happen with the current PKI.
Should we continue to assume that the implementation of the EV guidelines
is correct, even though we have ample evidence of basic RFC 5280 and BR
violations? Should we consider sunsetting (e.g. with a notBefore
restriction) trust? Would it be reasonable to remove trust altogether?

For example, Camerfirma currently has four roots ([1], [2], [3], [4]). [1]
appears to have issued less than 3,500 still valid certificates, [2] / [3]
are only trusted for e-mail, and [4] seems to be a super-CA of sorts (with
sub-CAs operated by Intesa Sanpaolo, Infocert, Multicert, and Govern
d'Andorra). For the sub-CAs that aren't constrained/revoked, it seems
Intesa Sanpaolo has only issued ~2200 certificates, Infocert ~650, and
Multicert ~3000.

Is that accurate? I totally could have made a mistake here, since this was
just manually inspecting every sub-CA from Camerfirma and I totally could
have clicked wrong, but that suggests that there is... very little
practical risk here to removal, compared to the rather significant risk of
having a CA that has established a pattern of compliance and supervision
issues.

[1] https://crt.sh/?caid=869
[2] https://crt.sh/?caid=140
[3] https://crt.sh/?caid=8453
[4] https://crt.sh/?caid=1114

Ramiro Muñoz

unread,
Dec 15, 2020, 1:13:18 PM12/15/20
to ry...@sleevi.com, Ben Wilson, mozilla-dev-security-policy
Hi Ryan

Thanks. We will take into account your observations.
As I said we planed to send the formal answer today but the team has asked me for more time in order to give a more accurate answer. We plan to postpone to this Friday.

KR
Ramiro


De: Ryan Sleevi <ry...@sleevi.com>
Enviado el: lunes, 14 de diciembre de 2020 22:41
Para: Ramiro Muñoz <ram...@camerfirma.com>
CC: ry...@sleevi.com; Ben Wilson <bwi...@mozilla.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Asunto: Re: Summary of Camerfirma's Compliance Issues

Burton

unread,
Dec 15, 2020, 1:39:38 PM12/15/20
to Ramiro Muñoz, ry...@sleevi.com, mozilla-dev-security-policy, Ben Wilson
It doesn't look great to the community when a CA that is under
investigation for serious compliance issues asks for more time to provide
detailed answers.

Also you said 'accurate answers' ? Were the answers you were going to post
today inaccurate in some way?

Burton

Ramiro Muñoz

unread,
Dec 15, 2020, 2:03:05 PM12/15/20
to Burton, ry...@sleevi.com, mozilla-dev-security-policy, Ben Wilson
I really sorry for the Delay Burton.

Obviously we do not intend to send inaccurate answers. Maybe I was not using the right wording may be I should use “precise” instead ? sorry for my English language limitation. Your complain about my email prove that some misunderstanding problem could have happen also in our bugs reports. We want to be sure that the answers are fully understand to give to the community the complete information to evaluate them. As you can imagine in the situation we are, it’s critical for us. That’s the reason.

Thanks
Ramiro


De: Burton <j...@0.me.uk>
Enviado el: martes, 15 de diciembre de 2020 19:39
Para: Ramiro Muñoz <ram...@camerfirma.com>
CC: ry...@sleevi.com; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>; Ben Wilson <bwi...@mozilla.com>
Asunto: Re: Summary of Camerfirma's Compliance Issues

It doesn't look great to the community when a CA that is under investigation for serious compliance issues asks for more time to provide detailed answers.

Also you said 'accurate answers' ? Were the answers you were going to post today inaccurate in some way?

Burton

On Tue, Dec 15, 2020 at 6:13 PM Ramiro Muñoz via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
Hi Ryan

Thanks. We will take into account your observations.
As I said we planed to send the formal answer today but the team has asked me for more time in order to give a more accurate answer. We plan to postpone to this Friday.

KR
Ramiro


De: Ryan Sleevi <ry...@sleevi.com<mailto:ry...@sleevi.com>>
Enviado el: lunes, 14 de diciembre de 2020 22:41
Para: Ramiro Muñoz <ram...@camerfirma.com<mailto:ram...@camerfirma.com>>
CC: ry...@sleevi.com<mailto:ry...@sleevi.com>; Ben Wilson <bwi...@mozilla.com<mailto:bwi...@mozilla.com>>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>>
Asunto: Re: Summary of Camerfirma's Compliance Issues

Thanks Ramiro for the update.

I do want to make sure we're on the same page. Responding point-by-point to the issues would probably be the least productive path forward. If there are specific disagreements with the facts as presented, which were taken from the Bugzilla reports, it would be good to highlight that. However, I believe the intent is that the Bugzilla report is the source of truth, so if there are details that were *not* on the incident reports, I would say that's more concerning than it is reassuring.

I'm a bit concerned to see your latest reply still highlight the "increased the PKI team", since that's been a sort of repeated refrain (e.g. Issue T, Issue BB, Issue PP). I don't disagree that it's important to ensure that there are adequate resources devoted to compliance _and_ development, but I think it's also important to make sure that the solution is not to throw more people at the problem.

While the integrity of the CA is perhaps not as obviously cut and dry, as was the case with WoSign/StartCom, I do believe it's reasonable to ask whether or not the CA has the skills, expertise, and understanding of the systemic issues to effectively manage things going forward, especially when we have seen the regular repetition of issues. This suggests more systemic fixes are needed, but also suggests that there are more systemic flaws in how things are operated, designed, and administered that do call into question the trustworthiness of the current infrastructure.

If Camerfirma were approaching with a new CA/new certificate hierarchy, it would be reasonable to ask why, given all of these incidents, Camerfirma should be included, since it puts a lot of risk onto the community. Regaining trust and reputation, once lost, is incredibly difficult, and requires going above and beyond. I hope that, in your formal response, you provide a holistic picture of how Camerfirma has changed its operations, implementation, infrastructure, management process, policies, and quite frankly, the use cases/subscribers that it targets with these certificates, so that the community can make an informed decision about risk.

Similarly, in thinking about what this would be for a "new" PKI, and how difficult it would be, given the current evidence, to see that as good for users, it's also worth asking what should happen with the current PKI. Should we continue to assume that the implementation of the EV guidelines is correct, even though we have ample evidence of basic RFC 5280 and BR violations? Should we consider sunsetting (e.g. with a notBefore restriction) trust? Would it be reasonable to remove trust altogether?

For example, Camerfirma currently has four roots ([1], [2], [3], [4]). [1] appears to have issued less than 3,500 still valid certificates, [2] / [3] are only trusted for e-mail, and [4] seems to be a super-CA of sorts (with sub-CAs operated by Intesa Sanpaolo, Infocert, Multicert, and Govern d'Andorra). For the sub-CAs that aren't constrained/revoked, it seems Intesa Sanpaolo has only issued ~2200 certificates, Infocert ~650, and Multicert ~3000.

Is that accurate? I totally could have made a mistake here, since this was just manually inspecting every sub-CA from Camerfirma and I totally could have clicked wrong, but that suggests that there is... very little practical risk here to removal, compared to the rather significant risk of having a CA that has established a pattern of compliance and supervision issues.

[1] https://crt.sh/?caid=869
[2] https://crt.sh/?caid=140
[3] https://crt.sh/?caid=8453
[4] https://crt.sh/?caid=1114
_______________________________________________
dev-security-policy mailing list

Ramiro Muñoz

unread,
Dec 19, 2020, 3:03:35 AM12/19/20
to mozilla-dev-s...@lists.mozilla.org
Hi Ben, Ryan, Burton and all:

Camerfirma will present its claims based on a description of the problems found by associating the references to the specific bugs.
After making a complete analysis of the bugs as presented by Ben, always considering that bugs are the main source of truth, we see that the explanations offered by Camerfirma could generally be better developed. We hope to make up for these deficiencies with this report.
We have included a list of issues that we consider to be fully addressed in the Appendix I: State of the fixed issues.

We will classify the issues in different categories:
• SUBCA SUPERVISION
• REVOCATION DELAYS
• TECHNICAL ISSUES AND AUTOMATISMS
1.- SUBCA SUPERVISION

MULTICERT, INFOCERT, INTESA SANPAOLO.
Issue H: Non-compliant OCSP Responders by Third-Party Subordinates (Dec. 2017)
Issue R: Failure to disclose unconstrained sub-CA (DigitalSign) (2018)
Issue T: Failure to disclose unconstrained sub-CA (MULTICERT) (2018 - 2020)
Issue X: MULTICERT Misissuance (2018 - 2019)
Issue Z: Intesa Sanpaolo Misissuance (2017 - 2020)
Issue BB: Failure to revoke underscores (2019)
Issue DD: Infocert Misissuance (2017 - 2020)
Issue PP: Failure to disclose unconstrained Sub-CA (Government of Andorra) (2013 - 2019)
Issue RR: Failure to disclose unconstrained Sub-CA (Intesa Sanpaolo and Infocert) (2018 - 2020)
Issue TT: Certificate with Incorrect OrganizationName (Nov. 2020)

In addition to the following requirement stated in the Mozilla policy and just in place
• Requirement of pointing in time audit (PIT) and report (at the beginning of each new CA)
• Requirement of the annual audits and report (from the creation of each Intermediate CA)
We are currently carrying out additional controls on the activities of the organizations that manage intermediate CAs with different implementation time frames:
• Adoption of a centralised LINTS (the same one used by Camerfirma) by all intermediate CAs before issuing certificates. (March 2019 Multicert and April 2019 Infocert e Intesa SanPaolo)
• Contractual reinforcement of Camerfirma's rights with regards to the activities carried out by Intermediate CAs and their obligation to a periodic communication. (October 2019).
• Contractual rights and tools for Camerfirma to insource, when deemed appropriate, intermediate CAs operational activities in order to be able to apply all needed (and already implemented for Camerfirma CAs) controls and to force certificate revocation in a timely manner.
Planned changes:
• Stop the issuance of certificates. (January 2021)
• Implementation of Intermediate CA PIT. (January 2021)
• Audit by Camerfirma of 100% of the active certificates issued (Task carry out during January 2021)
• Change in the audit process. We are currently requesting the audit report to be issued by a recognised auditor. The new process will require the audit to be carried out by an auditor selected by Camerfirma. (All new audits from January 2021)
• Technical environment set-up and procedural definition to be able to insource the management of operational activities of intermediate CAs by the first half of 2021
3.-REVOCATION DELAYS

Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017)
Issue J: Invalid DNS names within certificates (August 2017)
Issue L: Invalid subjectAlternativeName within certificates (July 2017)
Issue N: Improper issuance and failure to revoke intranet certificates (2015 - 2017)
Issue X: MULTICERT Misissuance (2018 - 2019)
Issue Z: Intesa Sanpaolo Misissuance (2017 - 2020)
Issue BB: Failure to revoke underscores (2019)
Issue PP: Failure to disclose unconstrained Sub-CA (Government of Andorra) (2013 - 2019)
Issue DD: Infocert Misissuance (2017 - 2020)
Issue LL: Invalid authorityKeyIdentifier (2003 - 2020)
Issue NN: Incorrect OCSP Delegated Responder Certificate (2013 - 2020)
We face the problem when the customers ask more time to complete certificates substitution in their own applications.
Controls already in place:
• All our External Intermediate CAs and clients have accepted new general terms and condition allowing Camerfirma to revoke all the problematic certificates without their permission if necessary (October 2019). There are not so many problems in reissuing some hundreds of certificates in a couple of days, the problem is awaiting critical customers activities (for example Intesa Sanpaolo one of the largest banks in Europe) before being able to revoke the misissued certificates.
• We have developed and started using a massive revocation and substitution tool to be more effective in that process. (June 2020).

After implementing all those measures, we have noticed that they were not enough to comply with the required deadlines, and we are planning to incorporate the following additional measures:

• Implement ACME to control the revocations and substitution automatically (planned for June 2021 for Camerfirma infrastructure and to be designed for the Intermediate CAs)
• 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)
• Have the contractual right and the operational procedures in place to insource the management of all the operational activities of the intermediate CAs (June 2021)

Only In some specific cases where a fast revocation could caused much more damages (to the impacted client) than benefits (to the entire community) in those cases we asked the community for some extra time.

4.-TECHNICAL ISSUES AND AUTOMATISMS

Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017)
Issue H: Non-compliant OCSP Responders by Third-Party Subordinates (Dec. 2017)
Issue J: Invalid DNS names within certificates (August 2017)
Issue L: Invalid subjectAlternativeName within certificates (July 2017)
Issue P: Invalid characters within the OU field (2018)
Issue X: MULTICERT Misissuance (2018 - 2019)
Issue Z: Intesa Sanpaolo Misissuance (2017 - 2020)
Issue BB: Failure to revoke underscores (2019)
Issue DD: Infocert Misissuance (2017 - 2020)
Issue NN: Incorrect OCSP Delegated Responder Certificate (2013 - 2020)
Issue LL: Invalid authorityKeyIdentifier (2003 - 2020)
Issue UU: Certificate for unregistered domain (Oct. 2020)

Regarding the automations, these are currently implemented:
• Control of the DNS and Email domain (August 2020)
• CT Control (April 2017)
• Control cablint, x509lint and zlint (pre-issuance - post-issuance) (January 2019)
• Syntax control of the domain (August 2020)
• Control of black and white lists of domains (August 2020)
• Automatic verification of CAA (June 2020)
• Additional automatic control to verify the correction of AKI extension before certificate issuance (April 2020)

New controls:
• Control of suspicious activity patterns. (March 2021)
• Remove fields as OU in the profile and avoiding other manual filling fields not validated in the certificate content. We have an exception for Spanish Public Administration Requirements where the field OU is mandatory for Spanish CAs (discussion https://github.com/cabforum/servercert/pull/225 ) (from January 2021).

Besides, in order to be as transparent as possible, each time we discover a new certificate misissued, we will review our internal procedure to make sure that those situations will always be promptly disclosed in https://misissued.com (for all new certificates detected from now on).
Other controls for the incorporation of correct information in the fields that automatic controls cannot detect, for example:

- Issue HH: EV Certificates with wrong businessCategory (2018 - 2019)
BUG 1600114 Information that shall be included in the BusinessCategory field of the EV certificates. If some EV certificates were issued with wrong values (there are four values that can be used)
- Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017)
BUG 1667430 Interpretation of what values can place in the stateOrProvinceName field
Audit process is the most effective answers to solve such residual problems. We will audit 100% of the certificates issued to detect wrong values in all the certificate’s fields (100% of certificates issued till January 2021).
Additionally, we must consider the importance of dedicated resources, because it has been an important aspect that has influenced past registered issues.
We think that thanks to the increased team, as described before, we have achieved a better issue and compliance management. For the future, our objective is to have a more proactive attitude to avoid incidents instead of a reactive action to quickly fix them.
Adding more employees, by itself, cannot be considered a solution. But the origin of some of the issues is a poor follow-up. This is the case with bugs, audits, activities of Intermediate CAs or matters concerning the community. Therefore, we believe that a proper sizing of the team can be considered an important structural change. Right sizing the department will improve operational and administrative management processes. Coupled with the automation of the processes to minimize manual operations, this will give us the quality we aim for.

Planned Changes:
• The exclusive dedication of the quality area in Camerfirma to the management of SSL certificates reinforced with a new recruitment to check 100% SSL certificates issued. (January 2021)
• Increase resources exclusively dedicated during the next year to the creation and maintenance of automatisms in the process of generating SSL certificates. January (2021)

Appendix I: State of the issues

Closed and remediated issues:
- Issue B: Delegation of validation to StartCom following Mozilla's distrust of StartCom (March 2017)
- Issue F: Ignoring CAA based on another CA's Certificate Transparency disclosure (Nov. 2017)
- Issue P: Invalid characters within the OU field (2018).
- Issue V: Audit Qualifications (2017 - 2018).
- Issue H: Non-compliant OCSP Responders by Third-Party Subordinates (Dec. 2017).
- Issue LL: Invalid authorityKeyIdentifier (2003 - 2020).

Closed but not considered remediated issues:
- Issue JJ: Unresolvable Gap in Audits (Camerfirma) (2018 - 2019).
- Issue FF: Intentional unrevocation of externally-operated sub-CA (2019).
Regards
Ramiro.






Ramiro Muñoz

unread,
Dec 20, 2020, 12:54:38 PM12/20/20
to Ben Wilson, ry...@sleevi.com, mozilla-dev-security-policy, Burton
Besides, in order to be as transparent as possible, each time we discover a new certificate misissued, we will review our internal procedure to make sure that those situations will always be promptly disclosed in https://misissued.com<https://misissued.com/> (for all new certificates detected from now on).
Other controls for the incorporation of correct information in the fields that automatic controls cannot detect, for example:


* Issue HH: EV Certificates with wrong businessCategory (2018 - 2019)

BUG 1600114 Information that shall be included in the BusinessCategory field of the EV certificates. If some EV certificates were issued with wrong values (there are four values that can be used)

* Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017)

BUG 1667430 Interpretation of what values can place in the stateOrProvinceName field
Audit process is the most effective answers to solve such residual problems. We will audit 100% of the certificates issued to detect wrong values in all the certificate’s fields (100% of certificates issued till January 2021).
Additionally, we must consider the importance of dedicated resources, because it has been an important aspect that has influenced past registered issues.
We think that thanks to the increased team, as described before, we have achieved a better issue and compliance management. For the future, our objective is to have a more proactive attitude to avoid incidents instead of a reactive action to quickly fix them.
Adding more employees, by itself, cannot be considered a solution. But the origin of some of the issues is a poor follow-up. This is the case with bugs, audits, activities of Intermediate CAs or matters concerning the community. Therefore, we believe that a proper sizing of the team can be considered an important structural change. Right sizing the department will improve operational and administrative management processes. Coupled with the automation of the processes to minimize manual operations, this will give us the quality we aim for.

Planned Changes:

• The exclusive dedication of the quality area in Camerfirma to the management of SSL certificates reinforced with a new recruitment to check 100% SSL certificates issued. (January 2021)

• Increase resources exclusively dedicated during the next year to the creation and maintenance of automatisms in the process of generating SSL certificates. January (2021)


Appendix I: State of the issues

Closed and remediated issues:

* Issue B: Delegation of validation to StartCom following Mozilla's distrust of StartCom (March 2017)
* Issue F: Ignoring CAA based on another CA's Certificate Transparency disclosure (Nov. 2017)
* Issue P: Invalid characters within the OU field (2018).
* Issue V: Audit Qualifications (2017 - 2018).
* Issue H: Non-compliant OCSP Responders by Third-Party Subordinates (Dec. 2017).
* Issue LL: Invalid authorityKeyIdentifier (2003 - 2020).
Closed but not considered remediated issues:

* Issue JJ: Unresolvable Gap in Audits (Camerfirma) (2018 - 2019).
* Issue FF: Intentional unrevocation of externally-operated sub-CA (2019).
Regards
Ramiro.

Wayne Thayer

unread,
Dec 22, 2020, 6:01:23 PM12/22/20
to Ramiro Muñoz, mozilla-dev-security-policy
On Sat, Dec 19, 2020 at 1:03 AM Ramiro Muñoz via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Ben, Ryan, Burton and all:
>
> Camerfirma will present its claims based on a description of the problems
> found by associating the references to the specific bugs.
> After making a complete analysis of the bugs as presented by Ben, always
> considering that bugs are the main source of truth, we see that the
> explanations offered by Camerfirma could generally be better developed. We
> hope to make up for these deficiencies with this report.
>
>
It's worth pointing out that in April 2018, the Camerfirma '2016 roots'
inclusion request [1] was denied [2] after a host of issues were
documented. At that time it was made clear that ongoing trust in the older
roots was in jeopardy [3]. While some progress was made, the number,
severity, and duration of new and ongoing bugs since then remains quite
high. In this context, I don't find these new disclosures and commitments
from Camerfirma to form a convincing case for their trustworthiness.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=986854
[2]
https://groups.google.com/g/mozilla.dev.security.policy/c/skev4gp_bY4/m/snIuP2JLAgAJ
[3]
https://groups.google.com/g/mozilla.dev.security.policy/c/skev4gp_bY4/m/ZbqPhO5FBQAJ

Ramiro Muñoz

unread,
Dec 28, 2020, 6:36:00 AM12/28/20
to mozilla-dev-s...@lists.mozilla.org
Hi Wayne

I understand your concern but, Camerfirma has indeed achieved huge improvements in terms of Mozilla’s policy compliance during recent years. Camerfirma nowadays has a much more mature management system. It’s true, some bugs have occurred but, looking at the bugs dashboard, our situation cannot be considered very different from other CAs. We firmly believe that the improvements already implemented together with the proposed measures will strengthen the governance of our SSL certificate activities in a very impactful and lasting way. In that regard, it’s important to highlight that we have the full support of our top management - both at the company level as well as at InfoCert Group level - in making everything will be required in order to come out successfully from this unpleasant situation.

Ryan Sleevi

unread,
Dec 29, 2020, 7:02:22 PM12/29/20
to Ramiro Muñoz, mozilla-dev-security-policy
On Mon, Dec 28, 2020 at 6:35 AM Ramiro Muñoz via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> El miércoles, 23 de diciembre de 2020 a las 0:01:23 UTC+1, Wayne Thayer
> escribió:
> Hi Wayne
>
> I understand your concern but, Camerfirma has indeed achieved huge
> improvements in terms of Mozilla’s policy compliance during recent years.
> Camerfirma nowadays has a much more mature management system. It’s true,
> some bugs have occurred but, looking at the bugs dashboard, our situation
> cannot be considered very different from other CAs.


So there's three specific claims here, as to why serious consideration of
distrust isn't warranted:

1. Camerfirma has made huge improvements
2. Camerfirma nowadays has a much more mature management system.
3. Camerfirma is not very different from other CAs.

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.
Similarly, to point out at how laughably bad the old system was does show
that there is a degree of truth in 2. 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.

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

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've shared my perspective, but value
learning more if others do see things differently.

Ramiro Muñoz

unread,
Jan 5, 2021, 9:01:22 AM (11 days ago) Jan 5
to mozilla-dev-s...@lists.mozilla.org
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.

Ryan Sleevi

unread,
Jan 5, 2021, 10:45:11 AM (11 days ago) Jan 5
to Ramiro Muñoz, mozilla-dev-security-policy
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
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.
>
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.

Ramiro Muñoz

unread,
Jan 9, 2021, 1:44:20 PM (7 days ago) Jan 9
to mozilla-dev-s...@lists.mozilla.org
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,

Ryan Sleevi

unread,
Jan 10, 2021, 11:27:01 AM (6 days ago) Jan 10
to Ramiro Muñoz, mozilla-dev-s...@lists.mozilla.org
> 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.


I am concerned about the attempts to so significantly dismiss the concerns
as merely subjective.

I’m saddened that Camerfirma does not recognize the seriousness of these
issues, despite this thread, as evidenced by this latest response.
Camerfirma continues to suggest “risk” as if this is some absolute that
should the the guiding pole.

The analogy, in the hopes that it helps Camerfirma understand, is a bit
like saying to a bank “I know we borrowed $100, and defaulted on that loan
and never paid it back, but we were a small CA, we’ve grown, and now we
would like to borrow $1 million. We cannot demonstrate our financials, nor
can we offer collateral, but we believe we are low risk, because it was
only $100”.

More concretely, Camerfirma is viewing this through the lens of what did go
wrong, and continuing to be blind to how that signals, from a risk
perspective, of what can go wrong. They are asking to be judged based on
the direct harm to users by their (many, more than any CA I can think of)
failures, while similarly asking the community to disregard the
significance of that pattern of failures, and what it says about the
overall operations of the CA.

In short, Camerfirma is asking to be trusted implicitly and explicitly for
the future, and asking that their $100 default not hold back their $1m
loan. In banking, as in trust, this is simply unreasonable.

Some have suggested that “trust” is the ability to use pst actions to
predict future outcomes. If you say you do X, and as long as I’ve known
you, you’ve done X, then when I say I “trust” you to do X, it’s an
indicator I believe your future actions will be consistent with those past
actions.

Camerfirma has, undisputed, shown a multi-year pattern that continues,
which demonstrates both a failure to correctly implement requirements, but
also a failure to reasonably and appropriately respond to and prevent
future incidents. The incident responses, which Camerfirma would like to
assert are signs of maturity, instead show a CA that has continued to
operate below the baseline expectations for years.

Camerfirma would like the community to believe that they now meet the bare
minimum, as if that alone should be considered, and all of these past
actions disregarded because of this.

Yet the risk is real: that Camerfirma has not met the bare minimum at
present, and that Camerfirma is not prepared to continue to meet that
minimum as the requirements are improved over time. We have exhaustive
evidence of this being the case in the past, and the only assurances we
have that things are different now is Camerfirma’s management believing
that, this time, they have finally got it right. However, the responses on
even the most recent incidents continue to show that Camerfirma is
continuing to pursue the same strategy for remediation it has for years: a
strategy that has demonstrably failed to keep up with industry
requirements, and failed to address the systemic issues.

These are objective statements, demonstrated by the evidence presented, but
Camerfirma would like to present them as subjective, because they take
consideration of the full picture, and not merely the rosy, but misleading,
image that Camerfirma would like to present.

That these are persistent, sustained issues, without systemic change, is
something demonstrably worse than DigiNotar. Further, when considering the
capability for harm, and the sustained pattern of failure, it would be
foolish to somehow dismiss the risk, pretending as if Chekhov’s gun of
failure is not destined to go off in the next act.

At the core, Camerfirma is treating this as if any response from the
community should be directly proportional to the *individual* failures, as
many as they are, and is asking the community to ignore both the systemic
patterns and what it says about the future. This is abundantly clear when
they speak of risk: they apparently are unable to comprehend or acknowledge
what the patterns predict, and the risk of that, and thus ask such patterns
be disregarded entirely as somehow, incorrectly, being too subjective.

If these failures were to be plotted on a time series, there is no question
that the slope of this graph is worrying, and the number of incidents - and
the type and pattern of incidents - is worrying. Camerfirma would ask we
ignore all such statistics and data, under the assertion that the slope of
sheer number of incidents is trending downward. Yet to do so would be to
disregard the data we have, and disregard the trendlines that show the type
of incidents have not meaningfully changed, that even with a downward trend
it is unacceptably above the baseline and will be for some time, and would
like us to forget everything we know because, Finally, Once and For All,
they’ve hired enough people to do the job that they’ve been required to do
from the beginning.
Reply all
Reply to author
Forward
0 new messages