On Tue, Apr 11, 2017 at 6:49 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I have attempted to integrate the information provided by Symantec into: > https://wiki.mozilla.org/CA:Symantec_Issues > and started to draw some conclusions where that is warranted. > > There are of course still open questions from myself, Ryan and others, > and so the truth relating to some incidents is not yet clear. > Can you clarify what issues you believe this to be related? Many of my questions related to Symantec's approach to handling incidents, which were unaddressed or meaningfully deficient in ways that undermines trust substantially, but were limited related to the material facts. The only point where I believe Symantec disagreed with the summary was Issue W, but it does not appear Symantec was bothered to support that claim with objective data, rather than with statements. That is, that Symantec disagrees is useful to know, but if Symantec has failed to provide any evidence with that disagreement, I do not believe it should block reaching a conclusion. Given that Symantec has a routine habit of exceeding any reasonable deadline for response, at what point do you believe it is appropriate for the Mozilla Root Store to begin discussing what steps can or should be taken with respect to the documented and supported incidents, which Symantec has not provided counter-factual data? Does the Mozilla Root Program seek to consider the intent of the CA that violated the Baseline Requirements repeatedly for a span of several years? If so, does it have a process at which point it will stop considering feedback, versus allowing a CA to indefinitely delay meaningful action to protect users? It's unclear from your remark "Started to draw some conclusions where that is warranted" what you see as the process and next steps. Perhaps you could clarify what you imagine happening next, and on what timeline, to provide clarity both to Symantec and the general population here. I must admit, I'm quite confused as to where things stand, given that many items have conclusions to them. With respect to the conclusion to Issue T "Symantec's reaction to the discovery of these problems was unarguably swift and comprehensive.", I would disagree with this. Symantec's response was not swift, relative to other CAs that have been informed of issues. It was not comprehensive - Symantec failed to identify the issues until question, and still maintains, in the latest response, that there is a conclusion unsupported by the evidence they have shared with the community. Their timeline for responsiveness was not swift - we're still discussing this specific issue, and it was first reported on Issue T. I would be happy to find evidence of issues from other CAs that demonstrate a more thorough response or a more timely response. With respect to the conclusion to Issue T, "Their case is that WebTrust audit monitoring should have been sufficient," it's unclear if you are agreeing with that conclusion or simply stating Symantec claims. With respect to the conclusion to Issue V, "to specifically address the GeoRoot audit status and remediation plan" - this was not reflected within https://www.symantec.com/content/en/us/about/media/repository/23_Symantec_GeoTrust_WTBR_period_end_11-30-2016.pdf , the relevant audit for the roots, ending on 2016-11-30. Do you believe this should play in with any determination about the reliability of KPMG audits (to discover this) and/or to Symantec (to disclose this to their auditors)? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
