Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

Summary of audit statements that are due:

 Forwarded Message 
Subject: Summary of February 2018 Audit Reminder Emails
Date: Tue, 20 Feb 2018 20:00:05 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   ISRG Root X1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2193=pdf
Audit Statement Date: 2017-02-07
BR Audit: https://cert.webtrust.org/SealFile?seal=2194=pdf
BR Audit Statement Date: 2017-02-07
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Staat der Nederlanden EV Root CA
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden Root CA - G2
Standard Audit: https://cert.webtrust.org/SealFile?seal=2204=pdf
Audit Statement Date: 2017-03-03
BR Audit: https://cert.webtrust.org/SealFile?seal=2204=pdf
BR Audit Statement Date: 2017-03-03
EV Audit: https://cert.webtrust.org/SealFile?seal=2204=pdf
EV Audit Statement Date: 2017-03-03
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA_8.02.2017.pdf

Audit Statement Date: 2017-02-08
BR Audit: 
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA_8.02.2017.pdf

BR Audit Statement Date: 2017-02-08
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Symantec Class 1 Public Primary Certification Authority - G4**
   Symantec Class 2 Public Primary Certification Authority - G4**
   Symantec Class 2 Public Primary Certification Authority - G6**
   VeriSign Class 1 Public Primary Certification Authority - G3**
   VeriSign Class 2 Public Primary Certification Authority - G3**
   VeriSign Class 3 Public Primary Certification Authority - G3**
   VeriSign Class 3 Public Primary Certification Authority - G4**
   VeriSign Class 3 Public Primary Certification Authority - G5**
   VeriSign Universal Root Certification Authority**
   Symantec Class 1 Public Primary Certification Authority - G6**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.symantec.com/content/en/us/about/media/repository/18_Symantec_STN_WTCA_period_end_11-30-2016.pdf

Audit Statement Date: 2017-02-28
BR Audit:
BR Audit Statement Date:
BR Audit: 
https://www.symantec.com/content/en/us/about/media/repository/21_Symantec_STN_WTBR_period_end_11-30-2016.pdf

BR Audit Statement Date: 2017-02-28
EV Audit:
EV Audit Statement Date:
EV Audit: 
https://www.symantec.com/content/en/us/about/media/repository/24_Symantec_STN_WTEV_period_end_11-30-2016.pdf

EV Audit Statement Date: 2017-02-28
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Hongkong Post Root CA 1
Standard Audit: https://cert.webtrust.org/SealFile?seal=2208=pdf
Audit Statement Date: 2017-02-28
BR Audit: 
http://www.hongkongpost.gov.hk/product/cps/ecert/img/HKPCA_WebTrust_BR_2016-17.pdf

BR Audit Statement Date: 2017-02-28
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Class 2 Primary CA
Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236

Audit Statement Date: 2017-01-14
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
BR Audit Statement Date: 2017-01-14
EV Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236
EV Audit Statement Date: 2017-01-14
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=2197=pdf
Audit Statement Date: 2017-02-16
BR Audit: https://cert.webtrust.org/SealFile?seal=2195=pdf
BR Audit Statement Date: 2017-02-16
EV Audit: https://cert.webtrust.org/SealFile?seal=2196=pdf
EV Audit Statement Date: 2017-02-16
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Trustis Limited - Trustis FPS Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399

Audit Statement Date: 2017-03-01
BR Audit: https://bug1360184.bmoattachments.org/attachment.cgi?id=8862399
BR Audit Statement Date: 2017-03-01
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8828490
Audit Statement Date: 2016-12-31
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf

BR Audit Statement Date: 2016-12-31
CA Comments: null



___
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

[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: Firefox security too strict (HSTS?)?

[beboyabella.kallfly--- via dev-security-policy]

its been a whole day to search for a resolution. some of them i research in 
google entails with servers and stand alon computers.

and i found a solution for this issue and its works like a charm.
Solution No.2 and 3 from this website 
https://www.errorsolutions.tech/error/firefox-error-code-sec_error_unknown_issuer/

Before doing a complex troubleshooting i perform the basic first like clear 
cache, clean boot, and deleting some of my addons and i Run an malwarebytes and 
i found threats on my computer so once i remove it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

Based on this discussion, Mozilla is denying the ComSign Global Root CA
inclusion request.  I'd like to thank everyone for your constructive input
into the discussion, and I'd like to thank ComSign for their patience and
work to address issues as they have been discovered.

ComSign may submit a newly generated root and key-pair for inclusion, and
this submission can be made using the existing bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=675060)

For now, I am moving this request to an on-hold status. Mozilla will
require updated documentation, and that documentation will need to be
verified. This request will effectively need to go through the entire
process again, but may do so more quickly if ComSign's new submission
addresses all the issues that have already been identified.

- Wayne

On Mon, Feb 19, 2018 at 4:09 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear Wayne,
> What is the decision on our matter?
> Can we start the new Root process (new Certificate with new KeyPair and
> the new CA software) and proceed the inclusion from this point later?
> Our next steps will be to create all the above and disclose all the needed
> audits as required by Mozilla and the BR.
>
> Looking forward to your reply.
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy