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<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. De: Burton <j...@0.me.uk> Enviado el: martes, 15 de diciembre de 2020 19:39 Para: Ramiro Muñoz <rami...@camerfirma.com> CC: r...@sleevi.com; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Ben Wilson <bwil...@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-security-policy@lists.mozilla.org<mailto:dev-security-policy@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 <r...@sleevi.com<mailto:r...@sleevi.com>> Enviado el: lunes, 14 de diciembre de 2020 22:41 Para: Ramiro Muñoz <rami...@camerfirma.com<mailto:rami...@camerfirma.com>> CC: r...@sleevi.com<mailto:r...@sleevi.com>; Ben Wilson <bwil...@mozilla.com<mailto:bwil...@mozilla.com>>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@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 dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
