Wayne, Thank you for your detailed review of the CP/CPS.
In attempt to discuss continued trust, I have attempted to summarize the patterns and issues of note, along with the timeline from reporting to remediation. It is my goal that this will allow the public to make an objective assessment of the risks introduced by Camerfirma, as well as the responsiveness towards remediation. While the ecosystem continues to improve both its understanding of the requirements and expectations, we must nevertheless consider the full picture. Issue 1: Invalid dNSNames/CNs ( https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) 2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p 2017-08-13 - Jonathan Rudenberg contacts the CA 2017-08-16 - Kathleen Wilson opens a Bugzilla incident 2017-08-17 - Camerfirma Responds 2017-09 - Scheduled remediation 2017-12 - First attempted remediation 2018-02-14 - Actual remediation, as per https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33 Issue 2: Unrevoked Internal Servernames ( https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 ) 2016-10-01 - Deadline for revoking internal server name certificates 2017-08-24 - Camerfirma shares list of misissued certificates affected by Issue 1, along with their response 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify and revoke internal server name certificates - https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp 2017-11-28 - Gerv Markham highlights that Camerfirma has still not responded to outstanding questions - https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21 2017-12-21 - Camerfirma responds to the substance of the questions Issue 3 - Improperly Configured OCSP - https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP configurations at https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by Camerfirma 2017-12-22 - Camerfirma confirms the issue is resolved. It took one of their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to implement these changes. Camerfirma did not self-report this non-compliance, despite acknowledging it on 12-12. 2018-01-03 - Camerfirma completes a minimal incident report with all required information. Issue 4 - Improper CAA checking ( https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 ) 2017-09-08 - Baseline Requirements require checking CAA 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by Camerfirma 2017-11-29 - Camerfirma confirms misissuance, believing it was valid because they found "and for which CAA was checked" to be confusing and indicating that CAA checking was optional. 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs Issue 5 - Duplicate dNSNames and invalid localityName/stateOrProvinceName ( https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 ) 2017-04-17 - Issue reported 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue is apparently a Camerfirma issue, and with improper logging as well as certificate configuration. 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller Note: No response was provided by Camerfirma in this incident report. Issue 6 - Out of date CP/CPSes 2016-06 - Last published version of the CPS at http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf 2018-05 - Next proposed update of the CPS, as stated elsewhere on this thread I'm not sure whether to track issues with the new hierarchy, so I will simply note the following: 2017-08-23 - Last issued certificate with invalid dNSName ( https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01 ) 2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's requirements that "CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString, with two exceptions" ( https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 ) Notable is that Camerfirma includes the organizationIdentifier, OID 2.5.4.97, in their certificates. This is documented in the CPS [5] from the original message, within Section 3.1.1, with the validation process described in 3.1.8.1. However, the CP/CPS lacks details as to the construction and validation - it appears to be a construction of "VAT" [member state] "-" [VAT number] In this, we see a pattern of issues, with a strong reliance on trusting RAs (which included entities such as StartCom, known to not be validating correctly) and, when failure detected, on technical controls. We see a pattern of delayed remediation, misunderstanding of expectations in the face of misissuance, and misunderstandings of the requirements themselves. If there is any one remark that perfectly captures this, it would be found in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 , provided on 2017-12-21 (i.e. after many of these issues) "AC Camerfirma is a small CA that uses an in-house developed CA software and is supported by our RA trusted operators and the continuous training they receive. AC Camerfirma has been working with this technology and staff for 17 years without problems and we have dedicated a big effort improving it along those years. Due to the number of TLS certificates issued on previous years, this working method was appropriate and suitable for us. The increase of certificates issued, increasing technical requirements and the analysis of these reported problems have helped us to realize the need to extend the technical controls in the CA application to cover all possible and new requirements and introduce a new person in charge of coordinating these implementations." I think it's problematic to suggest "without problems", and concerning that it required a "big effort" to improving. It equally remains problematic/concerning that the in-house CA software has continued to show issues. Camerfirma states that it believes those issues remediated, in part, by extending technical controls. Yet many of these failures also highlight problems in the design of the system (and its reliance on RAs) and the staff tasked with understanding and implementing compliance. In the midst of all of this overhaul at Camerfirma, the 2016 root was created. The existing roots still show problems (such as their CP/CPS issues), and it seems energy has been focused on the new root, despite it operating for a considerable time on the legacy infrastructure and subject to issues as recently as 3 months ago. If, despite the evidence, we are to believe that Camerfirma has remediated the technical issues (via the technical controls deployed in February 2018) and has remediated the policy issues (via the onboarding of new staff tasked with ensuring compliance in December 2017), then it seems minimally appropriate to suggest that a new, Camerfirma 2018 root be created and established. Camerfirma's 2016 root can be used to cross-certify this, thus supporting those users on Microsoft platforms for which 2016 is trusted, while providing greater assurance that the issuance and trust is appropriate. Such an inclusion should not occur until a key generation ceremony report, a point in time audit, and a period of time audit report have been provided for the new 2018 root, which would mean would not be reconsidered for at least 3 months, at a minimum. This would also ensure that Camerfirma has completed its remediation steps for its existing set of hierarchy, such as updating the CP/CPS, demonstrating that the new controls and personnel are equipped to maintain a globally trusted CA. Further, given Camerfirma's statements that their investment in compliance is with regards to the 2016 root, and the issue the prior roots have had (both from policy compliance and issuance), it seems that we should also begin discussing at what point trust in those legacy roots should be removed, up to and including disallowing new certificates from it if existing certificates are to remain trusted, as new issuance will be on/from the 2018 root (through the 2016 path, for Windows users) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
