On Mon, Feb 13, 2017 at 4:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Hi Steve, > > On 12/02/17 15:27, Steve Medin wrote: > > A response is now available in Bugzilla 1334377 and directly at: > > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 > > Thank you for this timely response. Mozilla continues to expect answers > to all reasonable and polite questions posed in our forum, and is happy > that Symantec is taking this approach. Indeed Steve, thank you for your continued attention as we try to gain the information and understanding necessary to determine how best to protect users from misissued certificates. I note that Symantec's answer to question 1 in [1] reiterates that, in Symantec's view, the set of misissuance previously was solely related to a specific internal tool, and as such, the remediation steps Symantec engaged in focused on the process and controls related to that tool. I highlight this because it seems difficult to understand the distinction between the previous event and this current event, and understanding that distinction seems relevant to understanding whether the steps Symantec took previously were reasonable and complete to address this set of issues and the community trust, as well as understanding the steps Symantec is proposing or has taken in response to this current set of issues. In the previous misissuance event, my understanding is that Symantec asserts that the whole totality of the misissuance was related to a single, specific tool. Symantec's initial response [2] was to assert that the issue was limited to rogue actions of a few individuals contrary to Symantec's policies and procedures. The proposed remediation of this was a termination of relationship with those specific individuals. However, it was pointed out by browsers based on a simple cursory examination that such a statement was not consistent with the data - that the full set of issues were not identified by Symantec in their initial investigation, and only upon prompting by Browsers with a specific deadline did Symantec later recognize the scope of the issues. In recognizing the scope, it was clear that the issues did not simply relate to the use of a particular tool, but also to the practices of employees with respect to asserting that things were correct when they were not. A specific example is that the role of Validation Specialist - which is tasked with independently reviewing the certificate request for non-compliance - was designed in such a way that it could be bypassed or overridden without following the appropriate policies. These were actions independent of any particular tooling. These issues were then amplified by the fact that Symantec was failing to ensure that its policies and practices adhered to the appropriate version of the Baseline Requirements, and that employees and staff were trained on the appropriateness of ensuring the appropriate policies were followed, regardless of the tools being employed. In response to this issue, Symantec took a series of corrective steps, such as: - A comprehensive review of its Policies and Practices to ensure compliance with the Baseline Requirements, as requested in [3] (and available at [4]) - The establishment of a centralized Compliance team to ensure compliance across Symantec branded-CAs - Internal training, which on the basis of [1] appears to have been limited to a specific tool, rather than to the overall auditable criteria or policies In the current misissuance, my understanding is that Symantec asserts that the totality of the misissuance was related to RAs. Symantec's initial response to the set of questions posed by Google [5] indicated that " At this time we do not have evidence that warrants suspension of privileges granted to any other RA besides CrossCert" in the same message that provided the CP/CPS for other RAs besides CrossCert, and itself a follow-up to Symantec's initial response to the Mozilla community, [6], which acknowledged for the potential of audit issues in the statement "We are reviewing E&Y’s audit work, including E&Y’s detailed approach to ascertaining how CrossCert met the required control objectives.". This appears to be similar to the previous event, in that the proposed remediation was first a termination of relationship with specific individuals. However, in Symantec's most recently reply, [1], it seems that again, on the basis of browser questions from a simple cursory examination that such a statement was not consistent with the data - that is, that the full set of issues were not identified by Symantec in their initial investigation, and only upon prompting by Browsers with a specific deadline did Symantec later recognize the scope of the issues. In recognizing the scope, it was clear that the issues did not simply relate to the use of a particular RA or auditor, but also to the practices of RAs with respect to asserting things were correct when they were not. It appears that, similar to the Testing Tool's failure to ensure that certificates were adhering to the fulsome standards of authentication, Symantec's newly established compliance team was failing to perform even a cursory review of the CP, CPS, and audit statements presented - despite Symantec having found it necessary in that introspective process themselves in response to [3], as noted above. Symantec's also stated that, in response to the past misissuance, it deployed a compliance assessment tool, which functionally serves a role similar to a Validation Specialist. However, such compliance assessment was designed in a way that it could be bypassed or overridden without following appropriate policies. Further, as acknowledged in [1], even when Symantec noted that at least one of their RAs had identified specific deficiencies in practice and issuance, Symantec determined it was not appropriate to notify Root Stores or Mozilla of a "problem report". In response to the issues identified in Question 8 of [1], Symantec noted that one of their RAs was deficient in response to its "policies and business practices change in regards to verification procedures for issuing certificates", and allowed 90 days for the RA to remediate this. However, it does not appear Symantec took any corrective action for the period under audit - a year long period - to review any issued certificates during the period of deficiency. I highlight this because Mozilla's Policy [7], Item 5, requires such notification to certifica...@mozilla.org, but Symantec acknowledges in Question 9 of [1] that it failed to do so. Symantec's proposed remediation for these issues appears to be limited to: - Suspend the use of RAs for independent validation of domain control and organizational information With this background in mind, and the comparisons highlighted, I do hope Symantec can consider the following questions: 1) Given that the Baseline Requirements require that Symantec accept full liability and responsibility for all actions by Delegated Third Parties, can Symantec please provide what were the specific steps and process Symantec's Compliance Team took in reviewing Registration Authorities prior to the detection of this misissuance? Specific example questions include: a) Did Symantec's compliance team independently assess the WebTrust licensing status of each received audit? b) Did Symantec's compliance team review the CP and/or CPS of each Delegated Third Party to independently assert compliance with the STN CP/CPS? 2) Given that Symantec has noted that RAs bore the capability to override the results of the compliance tool, can Symantec please provide details about every certificate Symantec has issued which has had the compliance check overridden? 3) Symantec noted in [5] that "Each certificate request is screened for BR compliance failure. Failures are flagged, preventing RA issuance until the flag is cleared." Can Symantec please confirm that "RA issuance" refers to the act of Symantec signing a TBSCertificate and producing a signed certificate, as opposed to any other interpretation, such as Symantec signed the certificate, but did not provide it to the RA until the flag was cleared? 4) Was the problematic audit, highlighted in Questions 10 and 11 of [1], CertSuperior's first audit as a Symantec RA? Stated differently, did Symantec engage in any business relationship with CertSuperior prior to the production of [8]? 5) Symantec's initial response to Mozilla, in [6], indicated that Symantec will be conducting "a review of our delegated RA controls and why we did not detect this problematic behavior before it was reported to us". What is the timeline for when this review will be completed and published? 6) Please provide the specific dates that Symantec engaged in a Delegated Third Party relationship with each of the RAs, so that the community can independently evaluate the 'scope of the issues' with respect to what certificates may be affected by the issues Symantec has disclosed. 7) Are there any elements in the above comparison between the past and present misissuance that Symantec believes are factually incorrect or unsubstantiated that Symantec would like to address or correct? More broadly, a set of questions exist for the community to be considering in evaluating Symantec's present and past responses, such as: - Whether the community believes Symantec adhered to the appropriate duty of care to review the CP, CPS, and audit reports produced for RAs, given Symantec's own experiences through participation in the Mozilla Community reviewing CP, CPSes, and audit reports of Symantec and other CA participants, the Mozilla policies related to disclosure of sub-CA's CP, CPS, and audit reports, and through Symantec's participation in the CA/Browser Forum, in which audit and audit issues has been a long-standing topic of discussion. - Whether the community believes Symantec's compliance team, which failed to detect these issues that were prominent and easily discovered, has demonstrated itself as an appropriate compensating control for either the past or present issues - Whether the community believes Symantec's statements regarding the scope of the issues - and the continued expansion of that scope - fully represent and contain the set of misissued certificates and the set of compliance issues - Whether the choice of Symantec to discontinue the use of RAs represents a sufficient mitigation for the past, existing and issued certificates - Whether the choice of Symantec to discontinue the use of RAs represents a sufficient and suitable mitigation for the possibility of future compliance issues that may be discovered or arise - What steps Symantec should take to reassure the Mozilla community of its ability to abide by the letter and the spirit of the Mozilla CA Certificate Policy if continuing to participate in the Mozilla CA Certificate program - What steps Mozilla should take regarding Symantec to reassure the Mozilla community of the appropriateness of continued trust in Symantec issued certificates, given the past and present issues [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487 [2] http://archive.is/Ro70U [3] https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html [4] https://www.symantec.com/page.jsp?id=test-certs-update# [5] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 [6] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 [7] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#inclusion [8] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831930 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
