Dear Peter,  Thanks for your comments! We think that there are some good 
suggestions for our work. We’ll take notes and do better in our future work.   

We have discussed these questions with our auditor. Here are our reply to your 
comments:   

Opportunties for Improvement: 
- The basic WebTrust Report and assertion do not specify location(s) where 
services are provided.  Other reports do indicate the services are provided 
in/from China. 
Reply: It’s not a mandatory requirement but a good suggestion, we’ve told our 
auditor and they would use the new report template published by WebTrust/PKI 
Task Force in next year's audit which will specify the location.   

- The opinions do not specify the list of Certification Authorities in scope 
Reply: Our company has changed the name from “GUANG DONG CERTIFICATE AUTHORITY 
CO.,LTD.” to “Global Digital Cybersecurity Authority Co., Ltd.” in this year. 
We do not have any external sub-CAs, so it’s no need to list the CAs in scope.
https://www.gdca.com.cn/about_gdca/CTrends/new/Notification-of-Company-Name-Change/
 
https://www.gdca.com.cn/about_gdca/CTrends/new/-00119/  
  

- The reports and asssertions do not specify the versions of the CP and CPS 
Reply: It’s not a mandatory requirement but a good suggestion, we’ve told our 
auditor and they would use the new report template published by WebTrust/PKI 
Task Force in next year's audit which will specify the version of the CP and 
CPS.   

- The management assertion appendixes mix keys and certificates.  The 
certificate is not the interesting part; the CA Distinguished Name (DN), type 
(Root or not), Key, and Key ID are the interesting parts. 
Reply: It’s a good suggestion. We may consider to specify them in our future 
assertion.   

 - The BR report repeats a bullet under "Maintained effective controls to 
provide reasonable assurance that:" 
Reply: We’ve confirmed with the auditor and it’s just a clerical error in 
auditor’s report.   

Bad: 
- The basic WebTrust for CA Report does not cover controls that provide 
assurance that subordinate CA certificate requests are accurate, authenticated, 
and approved (the management assertion does, so this indicates the auditor 
might have found issues with the controls) 
Reply: We've communicated with our auditor, they said that in the period of 
time report, we did not generate any subordinate certificates, which means that 
no subordinate certificate request happened during the audit period. So that 
the subordinate certificate request did not be mentioned in the audit report.   

 - The basic WebTrust for CA Management assertion does not include Subordinate 
CA [cross-]certification in the list of CA services. 
Reply: We do not have any external sub-CAs, so it’s no need to include the 
cross-certs in the list.   

 - The basic WebTrust for CA Management assertion does not include "Subordinate 
CA Certificate Lifecycle Management Controls" in the list of portions of 
criteria used 
Reply: We do not have any external sub-CAs, so it’s not applicable.   

- After the reporting period ended, GDCA issued at least two new subordinate CA 
certificates from the R5 root.  These use the organization name of "Global 
Digital Cybersecurity Authority Co., Ltd." and have keys and key IDs that are 
identical to those found in CA certificates for GUANG DONG CERTIFICATE 
AUTHORITY CO.,LTD.  This is problematic as re-use of key IDs with different 
issuer names causes problems on some platforms.  Additionally the separate DN 
means it is out of scope for the submitted report.  Combined with the lack of 
audited controls around subordinate CA management, CAs outside of the scope of 
the report may be a significant concern. 
Reply: Our company has changed the name from “GUANG DONG CERTIFICATE AUTHORITY 
CO.,LTD.” to “Global Digital Cybersecurity Authority Co., Ltd.” in this year, 
which was after the period in time audit. We have informed the Mozilla of the 
name change in advance. We also announced the name change to the public in our 
official website. 

- The Baseline + Network Security Requirements report and management assertion 
only covers two of the CAs. However the cross-certs issued by the root to the 
subordinate CAs do not include EKU constraints, so the subordinate CAs are 
capable of issuing server authentication ("SSL") certificates.  The assertion 
and report should include all CAs that are capable of issuing ser 
authentication certificates. 
Reply: We do not have any external sub-CAs.   

- The Baseline report does not provide an option that GDCA "maintained 
effective controls to provide reasonable assurance that it meets the Network 
and Certificate System Security Requirements as set forth by the CA/Browser 
Forum" 
Reply: The Baseline report issued by our auditor follows the “Webtrust 
Principles and Criteria for Certification Authorities – SSL Baseline with 
Network Security - Version 2.0” which is based on “Baseline Requirements for 
the Issuance and Management of Publicly – Trusted Certificates - Version 1.1.6” 
and “Network and Certificate Systems Security Requirement - Version 
1.0”.(Please refer to http://www.webtrust.org/homepage-documents/item79806.pdf) 
So the SSL report has covered the assurance of the Network and Certificate 
System Security Requirement. We’ve also communicated with the auditor and 
confirmed that their audit work include the Network and Certificate System 
Security Requirement.   

- The Extended Validation report and management assertion attempts to merge the 
Extended Validation SSL and Extended Validation Code Signing criteria. These 
should be distinct reports.  As writtten, the report fails to adequately cover 
the EVCS critera. 
Reply: It’s not a mandatory requirement before the publish of new report 
template. We’ve communicated with auditor and confirmed they have covered the 
audit work for EV SSL and EVCS in the audit process, and they would separate 
the EV SSL and EV Code Signing in their future report.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to