On Fri, Mar 23, 2018 at 1:12 PM ramirommunoz--- via dev-security-policy < [email protected]> wrote:
> 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 < > > [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? > > > > > > > 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. And cross-signing covers this. > > 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. This is not correct. Cross-signing the 2018 Root with the 2016 root allows all services that support your 2016 root to continue to work without disruption. From the point of view of clients, you’ve just added another intermediate certificate. > 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. Yes, but the cross-signing of the 2018 root with the 2016 root will ensure all the work you have done for 2016 is applied. > > 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. > I’m afraid this statement is not correct, and it’s based on an unfortunate understanding about what is being proposed - and how PKI works. None of what you’ve described is required by what I have proposed here. > Regards > Ramiro > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
