On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy < [email protected]> wrote:
> 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. The path I provided ensures every one of those things continues to work. Can you please elaborate more as to why it is unfeasible? > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
