On Tue, Feb 20, 2018 at 6:19 PM, Wayne Thayer <wtha...@mozilla.com> wrote:
> 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. > Interesting. This definitely means we have a gap in disclosure requirements, in which there exists a set of trust paths where there's no public awareness. > > >> 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 > The public discussion refers to the Section 8 process, which was meant to mitigate situations in which CAs transferred their trust. Transferring root certificates and intermediates is no different - it's still conferring trust to an organization unknown to Mozilla. Intermediate cross-signing at least has a disclosure within a week, which allows for some public awareness and review (and indeed, tooling has been built around it). > > 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. > No, this is different, but related. In the case of Issue #32, it means that the certificate itself won't necessary be listed in the scope of the Operating Organization's audit, even though they're operating to the audited CP/CPS. This is the general problem that audits only look retrospectively, and thus can't speak to future events. This goes a step further, which is that there will be no (public) disclosure of the transfer of control until 15 months after the transfer was executed, at least based on a reading that says Section 8 only applies to roots. This seems to go against the intent of both Section 8 and Section 5.3.2 - which tried to get timely disclosure of those events. > > >> 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? > Section 8.1 paragraph 3, combined with Section 5.3 para 1. > 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. > Here, the initial ICA is created under Organization Foo. Organization Foo discloses this (modulo issue #32). Let's further assume that they operate this ICA for at least one year, thus including it in the scope of their audit. Let's say their audit ends December 31, 2017. On January 1, 2018, they transfer this ICA to another Organization Bar. On March 31, 2018, Organization Foo obtains their audit for the period Jan 1, 2017 to Dec 31, 2017, and enter, within CCADB, that the ICA was under Organization Foo's audit, as part of disclosing an unbroken sequence of audits. Despite the fact that control of the key has been transferred to Organization Bar, the public is not made aware of this transfer until March 31, 2019 - as Organization Bar is now responsible for the period Jan 1, 2018 - Dec 31, 2018. This differs from the creation of a cross-signed intermediate. If Organization Foo signs for Organization Bar's keys directly on Jan 1, 2018, then that disclosure (and the audit) must be made within a week (per 5.3.2). If Organization Foo sells their root key to Organization Bar, it sounds like there's uniform agreement that Section 8 unquestionably applies, which means that until that transfer happens, Organization Bar undergoes public review/approval. Yet this creates a case in which trust is conferred, without triggering any disclosure. Given the motivation regarding Section 5.3.2 and Section 8 were motivated by specific incidents, amply discussed (namely, StartCom's both sale and cross-signature), it seems odd to suggest that Section 8 only applies to roots themselves, because of this loophole it would thus create. > > 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. > This seems troubling / should be fixed for 2.6, precisely because it creates the gap where transfer of ICAs doesn't undergo any of the rigor, but still possesses all of the risk. One would think the same policy applies - both to the roots and to any intermediates - precisely to ensure the appropriate mitigation. > > 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. > Agreed, I think it's worth discussing, especially given the concerns Gerv shared previously prior to this. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
