On Tue, Mar 5, 2019 at 12:11 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Objections to DarkMatter on the sole basis of the actions of a sibling > business with common owners is dangerous turf to get into, if we care about > historic precedent. Not only for corporate MITM but for straight-up > malware as well. Until quite recently the operation presently called > Sectigo was called Comodo and for a not brief period was owned by Francisco > Partners, an organization which also owns/owned the NSO Group. > Additionally, and before Symantec would ultimately be untrusted for > entirely unrelated reasons, Symantec owned BlueCoat. > > This means there are two recent precedents for which this category of > issues has not resulted in delegation of trust and one proposal that the > same category of behaviors should. I am not suggesting that a position > against DarkMatter on this basis is an indicator of xenophobia or bias > against a particular national affiliation, but I do wonder how one would > defend against such an accusation. > I believe you may have misunderstood the details of these incidents and their relationship to what's currently under discussion. In the Sectigo + NSO Group, these were entities that shared common investment ownership, but otherwise operated as distinct business entities. In the Symantec + BlueCoat, these were integrated organizations - and the concern was raised about ensuring that the entity BlueCoat did not have access to the key material operated by the Symantec entity. In this case, the Symantec entity asserted that the keys, operations, and audits were under its scope - BlueCoat was prevented from having access or control. [1] Both of those cases acknowledged a potential of conflicting interests, and worked to distinguish how those conflicting interests would not conflict with the community needs or goals. By comparison, the discussion around DarkMatter has been more similar to the discussion of Symantec rather than Sectigo, except DarkMatter has issued carefully worded statements that may, to some, appear to be denials, while to others, suggest rather large interpretative loopholes. This, combined with the interpretative issues that have been shown throughout the inclusion process - for which the serial numbers are merely the most recent incident, but by no means the first, raises concerns that there may be interpretative differences in the nature of the statements provided or the proposed guarantees. This seems like a reasonable basis of concern. Recall when TrustWave provided a similar creative interpretation regarding a MITM certificate it issued for purposes of "local" traffic inspection [2][3], attempting to claim it was not a BR violation. Or recall that Symantec made similar claims that the 30,000+ certificates that it could not demonstrate adhered to the BRs were somehow, nevertheless, not "misissued" [4] - as if the point of concern was the semantic statement of misissuance, rather than the systemic failure of the controls and the resulting lack of assurance. In this regard, there is at least precedent that such interpretative differences do not bode well. Going back to past policy discussions provided [5], there seemed clear consensus that there are business operations that are fundamentally incompatible with being a trusted CA, without ascribing value judgements to those operations or practices. The question is not one of bias or xenophobia against a particular country or national affiliation - it's whether or not the interests and operations of the business are incompatible with a trusted CA. To date, we have reports of certain business activities that are unquestionably incompatible with being a trusted CA - and the only question is whether or not there is accuracy in those reports of activities. We have a carefully worded statement that can both indicate those activities happen (under a different semantic interpretation - such as we saw with "misissuance" by Symantec or "Enterprise management" by Trustwave or "entropy" by DarkMatter) or could be seen as denials. The process to date is indeed to evaluate whether or not there is a conflict of interest that would disqualify an entity from being a CA, and there's ample past precedent about that being a relevant factor for discussion. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/akOzSAMLf_k/Y1D4-RXoAwAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/ehwhvERfjLk/XyHxrYkxdnsJ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=724929 [4] https://community.digicert.com/en/blogs.entry.html/2017/03/24/symantec-backs-its-ca.html [5] https://groups.google.com/d/msg/mozilla.dev.security.policy/PFDMOUL_Xkc/HviuS-rx_gcJ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
