Root Store Policy 2.6

[Wayne Thayer]

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

[Ryan Sleevi]

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, would allow for that transfer to go undisclosed for as much as 15
months (given the 90 days until reports are produced).

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

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.

[1]
https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/
[2]
http://foreignpolicy.com/2017/12/21/deep-pockets-deep-cover-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

[Stephen Davidson]

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: ge...@mozilla.com; Kathleen Wilson <kwi...@mozilla.com>
Cc: Barry Kilborn <B.Ki...@quovadisglobal.com>; Tony Nagel <T.N...@quovadisglobal.com>
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 Assurance CA


Serial

‎19 ff 34 56 9d 36 6b a1 f6 6e 8d 95 32 ee 05 d0 55 b9 dd 1d

‎62 7a 61 b1 0e 7f 5f 27 be 3b eb 5e 94 cf 7f f4 48 de e1 c5

‎14 ed 7e 90 75 b6 ae 86 8e 1a 3b 02 4f 8a 94 af c8 f5 db ba


Valid to

Saturday, ‎April ‎19, ‎2025 3:38:50 PM

‎Saturday, ‎April ‎19, ‎2025 3:27:31 PM

‎Saturday, ‎April ‎19, ‎2025 3:20:31 PM


Issuer

QuoVadis Root CA 3 G3

QuoVadis Root CA 2 G3

QuoVadis Root CA 2 G3


Sha1 thumb

‎‎9f eb 09 1e 05 3d 1c 45 3c 78 9e 8e 9c 44 6d 31 cb 17 7e d9

‎3a d0 10 24 7a 8f 1e 99 1f 8d de 5d 47 98 9c b5 20 2e 56 14

‎d3 fd 32 5d 0f 22 59 f6 93 dd 78 94 30 e3 a9 43 0b b5 9b 98


Sha256 thumb

D8 88 8F 4A 84 F7 4C 97 4D FF B5 73 A1 BF 5B BB AC D1 71 3B 90 50 96 F8 EB 01 50 62 BF 39 6C 4D

A2 5A 19 54 68 19 D0 48 00 0E F9 C6 57 7C 4B CD 8D 21 55 B1 E4 34 6A 45 99 D6 C8 B7 97 99 D4 A1

3A E6 99 D9 4E 8F EB DA CB 86 D4 F9 0D 40 90 33 33 47 8E 65 E0 65 5C 43 24 51 19 7E 33 FA 07 F2



-----Original Message-----
From: Gervase Markham [mailto:ge...@mozilla.org]
Sent: Thursday, November 2, 2017 7:12 AM
To: Stephen Davidson <S.Dav...@quovadisglobal.com>; Kathleen Wilson <kwi...@mozilla.com>
Cc: Barry Kilborn <B.Ki...@quovadisglobal.com>; Tony Nagel <T.N...@quovadisglobal.com>
Subject: Re: Moving (root signed) issuing CAs



Hi Stephen,



On 26/10/17 15:36, Stephen Davidson wrote:

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



Mozilla has concerns about this plan. The name of DarkMatter has been associated with some fairly shady behaviour related to online surveillance and the government of the UAE. With QuoVadis doing parallel validation of domain names for certs they issue, this was not necessarily a concern. But giving them independent issuance capability would be, as there would be no external controls. (QV would of course still be held responsible for any misissuance by DarkMatter, as they would still be a sub-CA of QuoVadis.)



While there are to some degree ecosystem mitigations against misbehaviour such as CT, Firefox does not currently require CT either by policy or code. And when one has control of a country's infra, surgical attacks on individuals are much more possible and much harder to detect.



I note in this connection that Mozilla is pondering, but has not yet implemented, a requirement that unconstrained cross-signs be disclosed in advance for discussion, specifically relating to the trustworthiness or otherwise of the organization to whom certificate issuance authority is being delegated. If we were to have such a requirement, this would fall under it.



I'm sure the issues relating to DarkMatter are not entirely unknown to you. Do you have comments or thoughts on the situation?



Gerv



-----Original Message-----
From: Stephen Davidson
Sent: Friday, November 3, 2017 4:42 AM
To: Gervase Markham <ge...@mozilla.org>; Kathleen Wilson <kwi...@mozilla.com>
Cc: Barry Kilborn <B.Ki...@quovadisglobal.com>; Tony Nagel <T.N...@quovadisglobal.com>
Subject: RE: Moving (root signed) issuing CAs



Hello Gerv:



Thank you for the feedback and clarity regarding Mozilla’s concerns.



We have worked extensively with DarkMatter as well as KPMG (their auditors) and EY (our auditors) to ensure that the appropriate requirements for root signing set by browsers are adhered to, including the BR and WebTrust.



In light of your concerns, we have contractually agreed that every SSL/TLS certificate issued from those DarkMatter trusted CAs will be automatically logged in CT (pre-cert using the native CA functionality). QuoVadis has the rights and duties to audit the DM environment regularly including CA logs (which are tamperproof/digitally signed). In addition to the duties laid out in the BR and Mozilla requirements, with DarkMatter we will implement a mechanism to reconcile weekly that all issued SSL/TLS certs have in fact been CT logged.



I hope this satisfies some of your concerns, and look forward to hearing from you.



Regards, Stephen





-----Original Message-----
From: Gervase Markham [mailto:ge...@mozilla.org]
Sent: Friday, November 3, 2017 6:31 AM
To: Stephen Davidson <S.Dav...@quovadisglobal.com>; Kathleen Wilson <kwi...@mozilla.com>
Cc: Barry Kilborn <B.Ki...@quovadisglobal.com>; Tony Nagel <T.N...@quovadisglobal.com>
Subject: Re: Moving (root signed) issuing CAs



Hi Stephen,



On 03/11/17 07:42, Stephen Davidson wrote:

> In light of your concerns, we have contractually agreed that every

> SSL/TLS certificate issued from those DarkMatter trusted CAs will be

> automatically logged in CT (pre-cert using the native CA

> functionality). QuoVadis has the rights and duties to audit the DM

> environment regularly including CA logs (which are

> tamperproof/digitally signed). In addition to the duties laid out in

> the BR and Mozilla requirements, with DarkMatter we will implement a

> mechanism to reconcile weekly that all issued SSL/TLS certs have in

> fact been CT logged.



That sounds positive. Although while you will have a view on all the certificates they issue, presumably the logs do not necessarily record the details of the domain validation done? (Some manual domain validation methods are inherently unloggable in that secure sense

anyway.) So if you see a cert for somesite.ae, will you be able to validate whether the owner of somesite.ae is the holder of the private key?



As it happens, perhaps not by coincidence, I got an email from Scott Rea this week announcing his intention to apply for full root inclusion for a hierarchy managed by DarkMatter. So it seems like there will soon be an opportunity for us to discuss DarkMatter in the community even under the existing rules.



Gerv

[Wayne Thayer]

Ryan,

On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi <ry...@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

[Ryan Sleevi]

On Tue, Feb 20, 2018 at 6:19 PM, Wayne Thayer <wth...@mozilla.com> wrote:

> Ryan,
>
> On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi <ry...@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.

[Wayne Thayer]

I've added the issue of subordinate CA transfers to the list for policy
version 2.6: https://github.com/mozilla/pkipolicy/issues/122

[Wayne Thayer]

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

[Wayne Thayer]

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

[Wayne Thayer]

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 <wth...@mozilla.com> 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 Thayer]

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