Ryan, On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi <r...@sleevi.com> wrote:
> > Hi Wayne, > > One point of possible clarification that should be undertaken is with > respect to https://github.com/mozilla/pkipolicy/blob/master/rootstor > e/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" > > My interpretation is that this section applies to certificates directly included in the Mozilla root store - i.e. root CAs. > 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's root inclusion request hasn't yet reached the public discussion phase: https://bugzilla.mozilla.org/show_bug.cgi?id=1427262 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. > > In terms of policy, is the issue here that subordinate CAs - either newly issued by or newly transferred to an "existing" CA organization (i.e. one that had a current audit prior to generating or receiving the new sub CA) - only show up on the CA organization's next regular audit? That is issue #32 (https://github.com/mozilla/pkipolicy/issues/32), one that I had not proposed tackling in version 2.6 of the policy. > 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 > Can you provide a reference for that last sentence as it relates to audited and disclosed subordinate CAs? , it's unclear if QuoVadis failed to ensure this. > > Per Stephen's response, it appears that they did. 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. > Except that in this scenario responsibility remains with the Root CA. In a root transfer, responsibility is reassigned. 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). > > I'm not following. Section 5.3.2 states that "The CA with a certificate included in Mozilla’s root program MUST disclose this information within a week of certificate creation, and before any such subordinate CA is allowed to issue certificates." If your root is in the Mozilla program, you have to disclose all the subordinates that chain to it. 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) > Since we have different interpretations, I agree that it needs to be clarified. 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 > Section 8.3 specifically refers to the "root certificate's private key", so I'm not convinced that any clarification is needed here. 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 > I see this as a separate topic, and one that will be covered during the public discussion period for DarkMatter's inclusion request. If you want to discuss this now, let's fork to a new thread. 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. > > This is the core issue, and I agree that it's an important one to address. I will plan to add it to the list for version 2.6 of the policy. 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. > > Agreed. Thanks for raising this topic. [1] https://theintercept.com/2016/10/24/darkmatter-united-ar > ab-emirates-spies-for-hire/ > [2] http://foreignpolicy.com/2017/12/21/deep-pockets-deep-co > ver-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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
