On Thu, Feb 28, 2019 at 7:31 PM Matthew Hardeman <[email protected]> wrote:
> Regarding program policy as it now stands, it is not unreasonable to > arrive at a position that the root program would be better positioned to > supervise and sanction DarkMatter as a member Root CA than as a trusted > SubCA. For starters, as a practical matter, membership in the root program > does not offer DarkMatter a privilege or capability that they do not > already have today. (Save for, presumably, a license fee payable or > already paid to QuoVadis/Digicert.) By requiring directly interfacing with > Mozilla on any and all disputes or issues, root program membership would > mean Mozilla gets to make final decisions such as revocation of trust > directly against the CA and can further issue a bulletin putting all other > CA program members on note that DarkMatter (if untrusted) is not, under any > circumstances, to be issued a SubCA chaining to a trusted root. The > obvious recent precedent in that matter is StartCom/StartSSL/WoSign. > That is certainly one way to approach it. As I tried to call out with the related sub-CA issue, the mere existence of third-party Sub-CAs does fundamentally introduce a risk to any root program and its ability to oversee its policies. For example, Microsoft requires contractual negotiations with Root CAs, but sub-CAs provide a loophole to that. Mozilla goes through detailed CP/CPS reviews, but sub-CAs bypass that. In theory, the issuing CA accepts the risks and liability, but in practice, we see it creates considerable difficulty for root programs. While we know that no CA is too big to fail, we also know that if a widely-used CA encounters issues - perhaps improper delegation to a sub-CA or RA - the costs and consequences are borne by the ecosystem. The approach you highlight is one approach that can be taken - which is to move to a system where all organizations are root CAs, and no third-party organizations may exist beneath a hierarchy, as the logical conclusion. I tried to balance the status quo with a bit more oversight with my proposal regarding introducing new organizations - which tries to balance the policy oversight with the cost that it'd incur. > On the topic of beneficial ownership I am less enthusiastic for several > reasons: > > 1. It should not matter who holds the equity and board level control if > the trust is vested in the executive team and the executive team held > accountable by the program. At that level, the CA just becomes an > investment property of the beneficial owners and the executive and > (hopefully) the ownership are aware that their membership in the root CA > program is a sensitive and fragile asset subject to easy total loss of > value should (increasingly easily detectible) malfeasance occur. I submit > that this may be imperfect, but I believe it's far more achievable than > meaningful understanding and monitoring of beneficial ownership. > > 2. Actually getting a full understanding of the down-to-the-person level > of the beneficial ownership is complex and in some cases might range from > infeasible to impossible. It's possible for even the senior management to > have less than full transparency to this. > > 3. Even if you can achieve a correct and full understanding of beneficial > ownership, it is inherently a point-in-time data set. There are ways to > transfer off the equity and/or control that may happen in multiple steps or > increments so as to avoid triggering change-of-control reporting, etc. > There are attorneys and accountants who specialize in this stuff and plenty > of legal jurisdictions that actively facilitate. > I think you've got some very legitimate concerns here. However, I think it's overlooking how closely this relates to policy. If we believe that the organization - its reputation, its incentives, its related efforts - matters, then I don't think we can overlook the need to understand the structure that governs the organization. While it's true that it's a point-in-time assessment, we've already seen how Section 8 of the Mozilla Policy attempts to address such matters. This isn't unprecedented, either - ICANN's Registrar Accreditation Agreements [1] or PCI's QSA Agreement - provide some models for this. The demonstrable example of StartCom/WoSign (and their related interests with Qihoo 360) seems relevant, in which both organizational incentives and the officers themselves were reason for sanction and concern. I don't share your skepticism regarding the change of control overhead - again, Section 8 demonstrates a way to tackle this already, through continuous disclosure. While I don't suggest this is perfect, the important element here is to improve transparency. While it's likely true that it can be gamed, by being transparent (e.g. disclosure by CAs), this facilitates investigation into misleading claims, as well as relationships that may be relevant to trust decisions. To this specific matter, consider this "hypothetical": If DarkMatter is denied, whether through Root or as a Sub-CA, there is nothing to prevent them from going and, say, acquiring the business interests of a smaller CA. While Section 8 provides a number of clauses regarding the disclosure, this could be done through an arms-length intermediate organization. If they did not immediately change the CP/CPS, this may not be obvious through Section 8.1's requirements for disclosures, and given the discussion we've seen both in the application and subsequent discussion about serial numbers, we may see some interpretative differences as to whether subsequent changes to the CP/CPS represent a material change in the CA's operations regarding Section 8. However, we may not even see changes in the CP/CPS; after all, we may see principles directly authorize improper behaviour, as we saw with WoSign/StartCom, and this may not be reflected in the audits themselves - as we saw, with WoSign/StartCom. So to the extent we think that the operating organization is relevant to a trust decision, it seems we need more transparency here in order to make informed decisions. Alternatively, if the view is that the organization itself is not relevant - only the CP/CPS and audits are - then I agree that this information may be seen as useless, because it shouldn't factor in to the decision making. I don't believe we can argue both though - that the organization is relevant for a trust decision, but the organizational structure isn't. I'm not trying to suggest that DarkMatter is or is not untoward. I am, however, trying to highlight that if the decision is to not trust, because of the concerns that have been shared on this thread and because of the organizational affiliation, then there are gaps, both in how ownership is disclosed and how sub-CAs are issued, that can allow this decision to be bypassed, and, as highlighted earlier, we've already seen some of that play out in the past. Even if the decision is ultimately to trust, it may be worthwhile to close these gaps, so that future policies have flexibility. In my previous message, I highlighted some of the early materials [3][4] that have been influential in the design of the current audit and accreditation schemes. For PKIs in general, the fundamental assumption is that relationships between two PKIs (e.g. the "Mozilla Root Store PKI" and the "DarkMatter CA") rests heavily on assumptions of contractual relationships with strong due-dilligence. The audit schemes are merely complementary to those business relationships, and the value of an audit is only recognized when you know who you're dealing with. That's why I think there is inescapable relevance to the organization and organizational structure in making and maintaining trust decisions, regardless of how that plays out regarding DarkMatter, and as a result, much like we require the disclosure of audits and PKI hierarchies, we should similarly require disclosure of organizational and decision making hierarchy. [1] https://www.icann.org/en/system/files/files/approved-with-specs-27jun13-en.pdf p64-66 [2] https://www.pcisecuritystandards.org/documents/QSA_Qualification_Requirements_v3_0.pdf Appendix A [3] https://www.americanbar.org/content/dam/aba/events/science_technology/2013/pki_guidelines.pdf [4] http://www.oasis-pki.org/resources/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
