Re: Root Store Policy 2.6

[Wayne Thayer via dev-security-policy]

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=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

[Wayne Thayer via dev-security-policy]

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=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

[Wayne Thayer via dev-security-policy]

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=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

[Wayne Thayer via dev-security-policy]

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

[Wayne Thayer via dev-security-policy]

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
>>> 

Re: Root Store Policy 2.6

[Ryan Sleevi via dev-security-policy]

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 

Re: Root Store Policy 2.6

[Wayne Thayer via dev-security-policy]

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 

RE: Root Store Policy 2.6

[Stephen Davidson via dev-security-policy]

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)

 


 

Re: Root Store Policy 2.6

[Ryan Sleevi via dev-security-policy]

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, 

Root Store Policy 2.6

[Wayne Thayer via dev-security-policy]

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.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy