Hi Ryan Many thanks for your report. I will try to answer to your concerns about our root inclusión.
> 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 > All previous bugs as you said are closed successfully. > > 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. > We were not aware that an answer from us was needed. The incident report provided by StartCom was coordinated with us. > > 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 > We already have a new CPS version, next week we will publish it, and a new version when it was RFC 3647 compliant. > > 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 > ) > there is an open bug https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 where previous bug are treated. > > 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] > website certificates profile is defined in ETSI EN 319 412-4. This standard refers ETSI EN 319 412-1 where this OID is defined. VAT is as defined in CPS section 3.1.8.2.3 > > 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) > We rely on our RA network and we train them and audit them for assure a correct validation. As a result of https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 technical controls were deployed to avoid misissuance, misunderstandings and reduce this dependency on trusting RAs. > > "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. > When we said “without problems” means that our practices and tools (PKI platform included) has passed many audit successfully. Sure, we have to improve (this very process, and every control, audits, certifications helps us to improve it). Just to let the community know, this is the list of AC Camerfirma SA last audit process: ETSI 319 401 Audited by TÜV-IT (2017-2019) https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf ETSI 319 401 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf ETSI 319 411-1 Audited by TÜV-IT (2017-2019) https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf ETSI 319 411-1 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf ETSI 319 411-2 Audited by TÜV-IT (2017-2019) https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf ETSI 319 411-2 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf ETSI 319 421 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf WEBTRUST FOR CA Audited by AUREN (2017) https://cert.webtrust.org/SealFile?seal=2283&file=pdf WEBTRUST BR Audited by AUREN (2017-2018) https://cert.webtrust.org/SealFile?seal=2284&file=pdf WEBTRUST EV Audited by AUREN (2017-2018) https://cert.webtrust.org/SealFile?seal=2285&file=pdf ISO 27001 Audited by AENOR (2016-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_27001_AENOR.pdf ISO 20000 Audited by AENOR (2016-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_20000_AENOR.pdf. In spite of the issues arisen, hope that at least this could count on our favor when a decision about our root inclusion were taken. > 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) Creating a new root 2018 is unfeasible for us for the following reasons: •Root 2016 is already audited and incorporated into the European TSL based on the favorable evaluation of our national supervisor body for both the issuance of S/MIME, WEB and TSU certificates. •Root is already recognized by other comunities such as Microsoft and Adobe. •Root 2016 is already accredited in the Spanish public administration & Public Services. •And above all, because the problems found so far have not incorporated a significant risk to the user community and they have been solved by incorporating technical controls and specific resources that currently allow us to commit with the ecosystem requirements. Best Regards Ramiro _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
