On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote: > On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> 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? > > >
Hi Ryan Sure, this could work for browsers validation, but our concern is about Web Certificates for Spanish Public administration. Spanish Public Administration is AC Camerfirma main customer. Additionally, Roots should be accepted by public administration validation services. So, if we provide a new root 2018, first of all, we should pass a new eIDAS conformity assessment for the new roots and then send it to administration validation services to be accepted by each particular public service. We have been working for month to be our root 2016 recognized by Spanish public services. We hope this could be improved in a future but nowadays is so complicated. We have been waiting for Mozilla 2016 root inclusion for many years, and we have to going back to the starting point ? Root 2016 are not having problems, we have issue only a few SSL certificates. It has nothing to do with StartCom, Have technical controls to avoid related problems found with RA validation and other, have no CPS problems.... I don't know how creating a new root 2018 can improve our trust for the community, in contrast, it will produce an economic damage and time consuming tasks for Camerfirma. Regards Ramiro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
