On Fri, Feb 16, 2018 at 3:41 PM, Wayne Thayer via dev-security-policy < [email protected]> wrote:
> I have begun work on version 2.6 of the Root Store Policy by drafting some > changes that are [I hope] uncontroversial. The diff can be viewed at > https://github.com/mozilla/pkipolicy/compare/2.6 > > > The changes I have already drafted are: > - Require disclosure of email validation practices in CPS (Issue #114) > - Require audit statements to be provided by the auditor in English (Issue > #106) > - Clarify ‘technically constrained’ language and update compliance date to > match what has been communicated (Issue #111 and #91) > - Update root inclusion criteria (Issue #118 and #104) > - Add compliance date (Issue #117) > - Minor bug fixes > > I will appreciate any feedback you have on these changes. > > I have also selected a set of proposed updates that I would like to discuss > and fix in this version of the policy. The issues I selected are tagged > with “2.6” on GitHub: https://github.com/mozilla/pkipolicy/issues > > If there are additional issues that I have not tagged but that you feel are > important to address in this version of the policy, please speak up. > > As has been done in the past, I plan to post individual issues for > discussion in small batches over the coming weeks. > Hi Wayne, One point of possible clarification that should be undertaken is with respect to https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#8-ca-operational-changes While this section is worded around CA's certificates, it would appear that some CAs have interpreted this to mean "root CAs", rather than "Any certificates operated by the CA" An example of this would potentially appear to be QuoVadis. QuoVadis created several sub-CAs, under their control and audit regime. They then sold/transferred these to an entity closely linked with the United Arab Emirates, and known to be closely related to the intelligence services [1], and reportedly under investigation by the FBI. [2] This information comes by way of DarkMatter, as part of their request to join the CA/Browser Forum [3], and as far as I can tell, has not been discussed publicly here. DarkMatter reported to the Forum that "DM also operates 3 other Issuing CAs - one for EV, one for OV, and one for Client certificates. These 3 ICAs were issued under QuoVadis Roots and subsequently migrated to the DM infrastructure (as witnessed by our WT auditors) once our WebTrust Audits were successfully obtained. These 3 Issuing CAs have live end entity certificates being trusted within the browsers." This statement was made by Scott Rea, the Senior Vice President of Trust Services at DarkMatter. DarkMatter disclosed that these ICAs were previously under QuoVadis's audit, [4], a period of time audit, and are now nominally in scope for DarkMatter's audit, [5], or at least, we can expect to see in the next update. DarkMatter's CP/CPS [6] notes that some certificates are under the QuoVadis CA3 - but it is ambiguous as to what policies are in place for those, given that they state "additional" policies, whether it's additive or separate. In any event, it would appear that the aforementioned EV and OV sub-CAs are likely [7] and [8]. At present, these disclosures are still representing as being under the QuoVadis audit in CCADB. It may be that QuoVadis intends to ensure their next audit covers the facility, state, and procedures at both QuoVadis' location and DarkMatter's location. It may alternatively be that the expectation is that, within a year of QuoVadis' audit, that DarkMatter is expected to provide the audit. What is unclear, however, is whether any such disclosure was made to Mozilla regarding the change in Legal Ownership, Operational Personnel, or Secure Location. Given the requirement that there MUST be a public discussion for new organizations being introduced, it's unclear if QuoVadis failed to ensure this. This may be nothing - it may be that Scott Rea misrepresented DarkMatter's controls and access to these ICAs. That, however, seems unlikely, given their attempt to join the CA/Browser Forum on the basis of operating these ICAs. Given the set of problems that Section 8 is intended to address, it does not seem to be a valid interpretation to suggest that the CA's certificates "only" include its Roots. If such an interpretation were to be applied, it would permit a scenario in which Root transfers require transparency and public review, but the Root CA can simply cut a new intermediate and sell to the highest bidder, 'effectively' transferring the trust that was imparted on the Root. Further, such a scheme would also circumvent Section 5.3.2 of Mozilla's Root Policy, as issuing a new intermediate to a new organization would require public disclosure within a week, while cutting a new intermediate, keeping it in scope of the 'parent's' audit for one report, and then transferring it the day after the end of the reporting period, would allow for that transfer to go undisclosed for as much as 15 months (given the 90 days until reports are produced). Thus, there seems to be several issues worth resolving here: 1) Clarifying the policy regarding Section 8 to ensure that CAs have no leg to stand on regarding the 'obvious' reading, which is that it includes any certificates within the CA's hierarchy that are themselves CA certificates (those capable of causing issuance) 2) Clarifying the matter with respect to QuoVadis, as to whether a policy violation has occurred if QuoVadis has indeed transferred the operational control of a CA in its control, particularly with respect to Section 8.3 3) Clarifying the matter with respect to DarkMatter, as to whether they are operating a CA trusted by Mozilla products and whether that trust is warranted, given the risks to Mozilla users 4) Clarifying whether, given the requirements in Section 8, and given the issues discussed in the context of Mozilla Policy 2.5 regarding CAs under sanction, whether it makes sense to unify Section 8 with restrictions on/controls over the issuance of sub-CA certificates, to ensure that every organization that possesses a certificate capable of causing issuance of new certificates has undergone the necessary disclosure and review, particularly if they are a new organization that does not operate CA certificates trusted by Mozilla. I suspect Item 4 will present some challenges, but unless and until that gap is addressed, we will be in an asymmetric situation, such that public CAs are reviewed and carefully evaluated, but they may quickly squander that trust through the issuance of sub-CAs to organizations whose audits, CP/CPSes, or practices are deficient. Remediating such issuance post-facto presents significant challenges, up to and including distrusting the Issuing CA, and ensuring the public review and discussion prior to such issuance - much as we saw with the StartCom cross-signing - can help prevent significant risks. [1] https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/ [2] http://foreignpolicy.com/2017/12/21/deep-pockets-deep-cover-the-uae-is-paying-ex-cia-officers-to-build-a-spy-empire-in-the-gulf/ [3] https://cabforum.org/pipermail/public/2018-February/013008.html [4] https://cert.webtrust.org/ViewSeal?id=2223 [5] https://cert.webtrust.org/ViewSeal?id=2340 [6] https://ca.darkmatter.ae/CPS/index.html [7] https://crt.sh/?id=125032795 [8] https://crt.sh/?id=23432430 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
