Re: Root Store Policy 2.6
Version 2.6 of the policy has been reviewed and (with some minor changes to section 7.3) approved by Mozilla's Legal department. I've set the effective date to July 1, 2018 and requested publication of the new version. Meanwhile, it can be found here: https://github.com/mozilla/pkipolicy/blob/2.6/rootstore/policy.md I'll be working on a CA Communication and blog post to ensure that everyone is aware of these changes. Many thanks to everyone who contributed to this update. - Wayne On Fri, May 18, 2018 at 6:54 PM Wayne Thayer wrote: > I have incorporated the final changes from our policy discussions, as well > as some corrections and clarifications that Kathleen and I found during our > review, into the latest draft of the policy: > https://github.com/mozilla/pkipolicy/compare/master...2.6 I would > encourage everyone to review the changes and respond with any comments. > > On Fri, May 11, 2018 at 11:11 AM Wayne Thayer wrote: > >> We're concluding discussions on all of the issues identified for version >> 2.6 of the policy [1]. >> >> You can find a complete set of changes here: >> https://github.com/mozilla/pkipolicy/compare/master...2.6 >> >> Two of the changes [2][3] require CAs to update their CP/CPS. For many >> CAs the current practice is to wait for the next required annual review >> (usually coinciding with their audit) to make CP/CPS changes. Do we want to >> allow that practice to continue, or set a date by which we expect CP/CPSs >> to reflect the new requirements? This was previously discussed [4], with >> the outcome being that we would make these decisions on a case-by-case >> basis. >> >> > > Since there were no comments on the question above, we'll continue with > the status-quo: there will be no defined enforcement date for the CP/CPS > changes required by the 2.6 version of our policy. CAs are expected to > update their CP/CPSs within a reasonable period of time of the 2.6 > effective date. I expect the 2.6 effective date to be sometime in June. > > > >> - Wayne >> >> [1] >> https://github.com/mozilla/pkipolicy/issues?utf8=%E2%9C%93&q=label%3A2.6+ >> [2] >> https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8 >> [3] >> https://github.com/mozilla/pkipolicy/commit/42ebde18794bc1690885bfdd4e3fb12e7c2c832b >> [4] >> https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/TT2u4wfoBQAJ >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Root Store Policy 2.6
I have incorporated the final changes from our policy discussions, as well as some corrections and clarifications that Kathleen and I found during our review, into the latest draft of the policy: https://github.com/mozilla/pkipolicy/compare/master...2.6 I would encourage everyone to review the changes and respond with any comments. On Fri, May 11, 2018 at 11:11 AM Wayne Thayer wrote: > We're concluding discussions on all of the issues identified for version > 2.6 of the policy [1]. > > You can find a complete set of changes here: > https://github.com/mozilla/pkipolicy/compare/master...2.6 > > Two of the changes [2][3] require CAs to update their CP/CPS. For many CAs > the current practice is to wait for the next required annual review > (usually coinciding with their audit) to make CP/CPS changes. Do we want to > allow that practice to continue, or set a date by which we expect CP/CPSs > to reflect the new requirements? This was previously discussed [4], with > the outcome being that we would make these decisions on a case-by-case > basis. > > > Since there were no comments on the question above, we'll continue with the status-quo: there will be no defined enforcement date for the CP/CPS changes required by the 2.6 version of our policy. CAs are expected to update their CP/CPSs within a reasonable period of time of the 2.6 effective date. I expect the 2.6 effective date to be sometime in June. > > - Wayne > > [1] > https://github.com/mozilla/pkipolicy/issues?utf8=%E2%9C%93&q=label%3A2.6+ > [2] > https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8 > [3] > https://github.com/mozilla/pkipolicy/commit/42ebde18794bc1690885bfdd4e3fb12e7c2c832b > [4] > https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/TT2u4wfoBQAJ > > On Mon, Mar 19, 2018 at 10:15 PM Wayne Thayer wrote: > >> There are 17 proposed changes in total for version 2.6 of the policy, and >> I'm about to kick off discussions on the first batch. I expect some of >> these to be straightforward while others will hopefully generate good >> dialogues. As always, everyone's constructive input is appreciated. >> >> Thanks, >> >> Wayne >> >> On Wed, Feb 21, 2018 at 9:14 AM, Wayne Thayer >> wrote: >> >>> I've added the issue of subordinate CA transfers to the list for policy >>> version 2.6: https://github.com/mozilla/pkipolicy/issues/122 >>> >>> >> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Root Store Policy 2.6
We're concluding discussions on all of the issues identified for version 2.6 of the policy [1]. You can find a complete set of changes here: https://github.com/mozilla/pkipolicy/compare/master...2.6 Two of the changes [2][3] require CAs to update their CP/CPS. For many CAs the current practice is to wait for the next required annual review (usually coinciding with their audit) to make CP/CPS changes. Do we want to allow that practice to continue, or set a date by which we expect CP/CPSs to reflect the new requirements? This was previously discussed [4], with the outcome being that we would make these decisions on a case-by-case basis. - Wayne [1] https://github.com/mozilla/pkipolicy/issues?utf8=%E2%9C%93&q=label%3A2.6+ [2] https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8 [3] https://github.com/mozilla/pkipolicy/commit/42ebde18794bc1690885bfdd4e3fb12e7c2c832b [4] https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/TT2u4wfoBQAJ On Mon, Mar 19, 2018 at 10:15 PM Wayne Thayer wrote: > There are 17 proposed changes in total for version 2.6 of the policy, and > I'm about to kick off discussions on the first batch. I expect some of > these to be straightforward while others will hopefully generate good > dialogues. As always, everyone's constructive input is appreciated. > > Thanks, > > Wayne > > On Wed, Feb 21, 2018 at 9:14 AM, Wayne Thayer wrote: > >> I've added the issue of subordinate CA transfers to the list for policy >> version 2.6: https://github.com/mozilla/pkipolicy/issues/122 >> >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Root Store Policy 2.6
There are 17 proposed changes in total for version 2.6 of the policy, and I'm about to kick off discussions on the first batch. I expect some of these to be straightforward while others will hopefully generate good dialogues. As always, everyone's constructive input is appreciated. Thanks, Wayne On Wed, Feb 21, 2018 at 9:14 AM, Wayne Thayer wrote: > I've added the issue of subordinate CA transfers to the list for policy > version 2.6: https://github.com/mozilla/pkipolicy/issues/122 > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Root Store Policy 2.6
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 wrote: > > > On Tue, Feb 20, 2018 at 6:19 PM, Wayne Thayer wrote: > >> Ryan, >> >> On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi 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, Operationa
Re: Root Store Policy 2.6
On Tue, Feb 20, 2018 at 6:19 PM, Wayne Thayer wrote: > Ryan, > > On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi 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
Re: Root Store Policy 2.6
Ryan, On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi 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 "Th
RE: Root Store Policy 2.6
Hello: I am following up regarding Ryan's comments relating to the DarkMatter external CAs signed by QuoVadis. In short: * QuoVadis has been transparent with Mozilla regarding these CAs throughout their existence, with the latest discussion occurring in the autumn of 2017 (see below). * The DarkMatter CAs have continuous WebTrust audit coverage, while initially under our managed operation and subsequently on a standalone basis. * The DarkMatter CAs are logging all new trusted SSL in CT. Regards, Stephen -Original Message- From: Stephen Davidson Sent: Thursday, October 26, 2017 11:37 AM To: g...@mozilla.com; Kathleen Wilson Cc: Barry Kilborn ; Tony Nagel Subject: Moving (root signed) issuing CAs Hello: I am writing to provide information on a long-planned project with a QuoVadis client, taking into mind the requirements of Section 8.3 of the Mozilla Root Store Policy. QuoVadis has worked with DarkMatter for a number of years to build and operate a number of CAs – some of which were root signed by QuoVadis roots and hosted by QuoVadis in our PKI trustcentre. Those trusted CAs shown below. DarkMatter has been in control of those CAs, although QuoVadis has conducted its own vetting of SSL domains and organisations in parallel. The CAs have been included in QuoVadis’ own WebTrust. The plan has always been to eventually relocate those CAs to the UAE, and DarkMatter has built a team and prepared facilities. You probably know their team leader, Scott Rea, from the CABF and elsewhere in the PKI world. We believe that Dark Matter are now prepared to transition to being a “publicly audited and disclosed” external CA. We have taken great care to adhere to the Mozilla policies in planning this transition. Following the transition, DarkMatter will take control of validation. To summarise: * EY formally audited phase 1 of the migration and produced a formal audit report. Phase 1 was just a transfer of some key material (that will be used in Phase 2). The CAs continued to operate in QV Bermuda. DarkMatter CAs were included in the 2016 QuoVadis WebTrust. They will be also named in the 2017 QuoVadis WebTrust * DarkMatter have successfully completed a PITA WebTrust (that includes the location where the ICAs will be migrated to). * Phase 2 of the migration is due to happen soon. This will be formally audited by KPMG (both in Bermuda, CH and UAE) and a report will be produced. We will have our auditors EY on hand too. * DarkMatter are finalizing their initial period of time WebTrust reports. Note that these ones won’t mention the CAs to be migrated since the initial period ends before the migration will take place. Going forward, KPMG will conduct – continuous coverage – WebTrust for CAs, WebTrust for BR, and WebTrust for EV audits of the DarkMatter CAs. QuoVadis will continue ongoing monitoring and internal audits of their issuance, per requirements. We expect the move to occur in the first week of November. We have not been aware of discussion regarding a move such as this involved a trusted issuing CA. We are requesting information on the degree of disclosure you would like regarding this move. Best regards, Stephen Background on the CA Certs In April 2016 we had the first DarkMatter ceremony. These had .ae constraints in them. (They didn’t count as fully technically constrained though). EY audited fully. These CA were on the QuoVadis WebTrust 2016 report. Original Certs CN DarkMatter Assured CA DarkMatter Secure CA DarkMatter High Assurance CA Serial 05 a6 22 7d 59 9c 95 fe b5 5a 33 3a 9b 6b 54 13 45 12 db 63 62 3f 50 d8 3a 11 19 2f 11 16 cc 4b 12 78 5e 12 b0 39 6b 24 62 06 5c 48 9e a2 37 c7 c4 0b b7 a3 38 9b 1d 0e b9 b9 a3 58 Valid from Friday, April 29, 2016 7:53:00 PM Friday, April 29, 2016 7:45:18 PM Friday, April 29, 2016 7:38:11 PM Valid to Monday, April 29, 2024 7:53:00 PM Monday, April 29, 2024 7:45:18 PM Monday, April 29, 2024 7:38:11 PM Issuer QuoVadis Root CA 3 G3 QuoVadis Root CA 2 G3 QuoVadis Root CA 2 G3 Sha1 thumb 6b 6f a6 5b 1b dc 2a 0f 3a 7e 66 b5 90 f9 32 97 b8 eb 56 b9 6a 2c 69 17 67 c2 f1 99 9b 8c 02 0c ba b4 47 56 a9 9a 0c 41 88 35 43 7d 38 7b bb 1b 58 ff 5a 0f f8 d0 03 d8 fe 04 ae d4 Sha256 thumb 60 F0 66 DC 78 A4 E2 E9 29 A1 C8 ED 10 2E DB 70 7D F0 31 81 F8 2F DF 50 D5 3A 52 DA C3 55 C6 5B A0 19 81 1E 43 69 CA 4C 62 AA A8 0A 15 49 61 3E 60 F6 C5 CE D3 83 AF 9D 79 DF 8F 8F 19 3F 1D FE E0 A6 70 F4 F1 05 7E 91 79 E9 DB 45 E3 33 CE 37 E3 EE 31 C3 49 9F 1C 58 4A 58 7B D9 A5 F5 36 40 Renewed Certs In April 2017 we renewed these CAs to remove the .ae constraints. These CAs will be in the QuoVadis WebTrust 2017 report (as well as the 2016 CAs) CN DarkMatter Assured CA DarkMatter Secure CA DarkMatter High Ass
Re: Root Store Policy 2.6
On Fri, Feb 16, 2018 at 3:41 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> 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,