1311824 - WoSign: Action Items

Status: RESOLVED INCOMPLETE

(CA Program :: CA Certificate Root Program, task)

Description

[Kathleen Wilson]

As per Bug #1309707, new certificates issued after October 21, 2016 that chain up to certificates with the following Subject Distinguished Names will no longer be trusted in Mozilla products, beginning with Firefox 51.

1) CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN 
2) CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN 
3) CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN 
4) CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN 

WoSign may apply for inclusion of new (replacement) root certificates[1] following Mozilla's normal root inclusion/change process[2] (minus waiting in the queue for the discussion), after they have completed all of the following action items, and no earlier than June 1, 2017. 

1. Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla's CA Certificate Policy and the CA/Browser Forum's Baseline Requirements.

2. Implement the changes, and update their CP/CPS to fully document their improved processes. The CP/CPS must explicitly state that it is prohibited to backdate the notBefore of certificates by more than one day.

3. Provide a public-facing attestation from a Licensed WebTrust Practitioner acceptable to Mozilla[3] that the changes have been made. This audit may be part of an annual WebTrust CA audit.

4. Provide auditor[3] attestation that a full performance audit has been performed confirming compliance with the CA/Browser Forum's Baseline Requirements. This audit may be part of an annual WebTrust BR audit. 

5. Provide auditor[3] attestation that a full security audit of the CA’s issuing infrastructure has been successfully completed.

6. 100% embedded CT for all issued certificates, with embedded SCTs from at least one Google and one non-Google log. The CA should not fulfill the non-Google log requirement by using logs that they run themselves. For as long as they do so, they will need to demonstrate ongoing evidence of efforts to get other logs to take their volume, and why those efforts have not been successful.

Notes:
[1] The new (replacement) root certificates may be cross-signed by the Affected Roots listed above. However, the Affected Roots may *not* be cross-signed by the new (replacement) root certificates, because that would bring the concerns about the Affected Roots into the scope of the new roots. Due to the way we are implementing the distrust, the new root certificates must have a Subject Distinguished Name that does not overlap with the Subject Distinguished Names listed above.
[2] Mozilla's root inclusion/change process includes checking that certificates in the CA hierarchy comply with the CA/Browser Forum's Baseline Requirements.
[3] The auditor must be an external company, and approved by Mozilla.

Comment 1

[Arkadiusz Ławniczak]

Based on the information from our E&Y External Auditors and from
the WebTrust team that WoSign CA Limited has lost its WebTrust seal which has been applied to its roots: Certification Authority of WoSign CA 沃通根证书, CA WoSign ECC Root and Certification Authority of WoSign G2.

Certum revoked subordinate CAs issued to Certification Authority of WoSign G2. The revoked CAs are posted to our public CRL at http://crl.certum.pl/ca.crl
The CRL contains two entries for this event.

These revocations have been marked at Mozilla Salesforce.

Comment 2

[Arkadiusz Ławniczak]

Could you please update https://wiki.mozilla.org/CA:WoSign_Issues#Cross_Signing?

Comment 3

[Gervase Markham [:gerv]]

The requirements in comment 0 have been communicated to WoSign, and so this bug is currently not actionable. If and when WoSign reapply for inclusion, we can make sure they have met all these conditions.

Gerv

Comment 4

[Richard Wang]

Attachment: WoSign system code security audit report summary 20170627.pdf

WoSign New system and new infrastructure have passed the Cure 53 security audit, Cure53 is the Mozilla approved security auditor. The full version report including all finding details have sent to Mozilla Gerv and Kathleen. This attached file is the summary report for public, thanks.

Comment 5

[Richard Wang]

and the full version report have sent to Google Ryan Sleevi, Microsoft CA program team, Apple CA program team.

Comment 6

[Wayne Thayer]

Richard - Has action item #1 been completed?

"Provide a list of changes that the CA plans to implement to ensure that there are no future violations of Mozilla's CA Certificate Policy and the CA/Browser Forum's Baseline Requirements"

I feel that this list would help to inform the discussion happening on the mailing list.

Wayne

Comment 7

[Richard Wang]

Thanks, Wayne.

According to the issues list: https://wiki.mozilla.org/CA:WoSign_Issues, we classify the issues into two cases:
CASE 1: System bug issues, here is the list of changes:
(1)We discarded the old system, developing new code BUY/CMS system, not modified from the old system. For CA system, we used EJBCA open source edition with our own developed CA proxy, CT proxy and Validation system.
(2)The new system integrated the CABFlint, X509lint and Zlint for all pre-issued SSL certificate to make sure every pre-issued certificate complies with the Standard (Mozilla policy and CAB Forum BR etc.).   
(3)The new system deployed in new infrastructure (servers and network) that hosted in Qihoo 360’s secure infrastructure.
(4)We submitted the new system (BUY/CMS, CA proxy, CT proxy, Validation System and OCSP system) and new system source code to Cure 53 for security test that Cure 53 had the full system administration access to all servers for full test. And the new system passed Cure 53 test, all found bugs are fixed and verified.
(5)We will do the system security test again once we have finished the Step 1-4 using the new system.

CASE 2: Management issues, here is the list of changes:
(1)We set up a department: Risk Control & Compliance Department (RCC), which have 5 persons, the manager is from the bank IT risk control department, he leads team for the risk control management and internal audit. Two English major employees, they are responsible to translate all WebTrust documents and all CAB Forum documents into Chinese to let all employees learn the Standard more clearly. And one is responsible for checking CAB Forum mailing list to produce a weekly brief in Chinese for CAB Forum activity to all department managers, one is responsible for checking Mozilla D.S.P. mailing list to produce a weekly brief in Chinese. And they produce summary report if some CA has accident report to let us learn how to prevent from the same mistakes and how to respond to the Community. Another two employees are security test, one from PKI/CA RD team, one is from Buy/CMS RD team, they are responsible for the system test and security test to two RD team developed system. 
(2)RCC Department setup many internal management regulations, it is the internal auditor to check and verify every CA operation is complaint with the Standard.
(3)We have full employees meeting to summary what’s wrong in the daily operation and what we need to improve. Every employee including Richard Wang has learnt a deep lesson from the Sanction, we know the importance of comply with the Standard.  
(4)We stopped updating the old roots CPS and prepared a new CPS that complies with all Standards for new planned coming roots. The new CPS will explicitly state that it is prohibited to backdate the notBefore of certificates by more than one day, and this will be guaranteed by the new system control and the daily checking by the RCC department.
(5)The RCC Department are responsible for the CPS updates according to the Mozilla Root Store Policy and the CA/Browser Forum’s Baseline Requirements, and check every CA operation comply with CPS, this department has super right to supervise all CA operation that nobody including Richard Wang can have a finger in the pie to violate the Standard.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1311824, we will do the following work:
(1)Appoint a WebTrust audit qualified auditor to the PITRA audit, this auditor must be approved by Mozilla;
(2)The PITRA audit will audit the new system, New CPS and new management;
(3)After finishing the PITRA audit, we will send the PITRA audit report to Mozilla and other browsers;
(4)Do the system security test again, and send the security audit report to Mozilla and other browsers;
(5)Confirm with Mozilla if we can generate the new roots and start to use the new system with the new roots;
(6)After getting the approval, we start to use the new roots to issue certificate, and submit the new roots for inclusion;
(7)Start to do the full WebTrust audit within the 90 days after the new roots start date, the WebTrust audit report must be disqualified, must be a clear report. And submit the WebTrust audit report to the new roots inclusion application Bugzilla.

Comment 8

[Gervase Markham [:gerv]]

(In reply to Richard Wang from comment #7)
> (4)We submitted the new system (BUY/CMS, CA proxy, CT proxy, Validation
> System and OCSP system) and new system source code to Cure 53 for security
> test that Cure 53 had the full system administration access to all servers
> for full test. And the new system passed Cure 53 test, all found bugs are
> fixed and verified.

Is there any connection or relationship at all between this system, and the system that Cure53 audited for StartCom? Or are they different codebases?

Gerv

Comment 9

[Wayne Thayer]

(In reply to Gervase Markham [:gerv] from comment #8)
> (In reply to Richard Wang from comment #7)
> Is there any connection or relationship at all between this system, and the
> system that Cure53 audited for StartCom? Or are they different codebases?

Also, were any of the people, leadership, or processes used to develop the new Wotrus system that Cure53 audited the same as those used to develop the Startcom system that Cure53 audited?

Wayne

Comment 10

[Richard Wang]

(In reply to Richard Wang from comment #8)
Two different system with difference codebase, we develop it by our team. They develop it by 360 team. You can confirm this difference from Cure 53 that viewed two code.
thanks.
Richard

Comment 11

[Richard Wang]

(In reply to Richard Wang from comment #9)
No, we are completely separated, two different team and leadership, a completely new system we developed, most RD engineers worked in WoTrus for more than 5 years that know PKI/CA and CA business very well. But the two system both use EJBCA to issue certificate.
Thanks.

Richard

Comment 12

[Gervase Markham [:gerv]]

(In reply to Richard Wang from comment #11)
> (In reply to Richard Wang from comment #9)
> No, we are completely separated, two different team and leadership, a
> completely new system we developed, most RD engineers worked in WoTrus for
> more than 5 years that know PKI/CA and CA business very well. But the two
> system both use EJBCA to issue certificate.

Cure53 confirm that, as far as they can see, the two systems are different.

Gerv