I've added the issue of subordinate CA transfers to the list for policy version 2.6: https://github.com/mozilla/pkipolicy/issues/122
On Tue, Feb 20, 2018 at 4:50 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > 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
