> 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: >
> - 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.
You have one or more CAs that have a non-zero path constraint. Therefore they
are able to issue certificates to subordinate CAs, whether operated by your
organization or externally operated. As such, it is important that the CA have
controls around issuing CA certificates and that the auditor has reasonable
assurance the controls function as designed.
Reply: We’ve communicated with our auditor and knew that they always performed
design effectiveness audit to all of our controls, include controls around
issuing CA certificates. As there is no subordinate certificate request
happened during the audit period, it was not mentioned in the audit report.
It’s a good suggestion, they would specify the controls around issuing CA
certificates in the future report no matter if it happens.
> - 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.
I understand it was a name change. However you issued new CA certificates with
the new name which means you do issue CA certificates from time to time.
Reply: The issuing of new CA certificates was after the period of audit report.
We’ve informed Mozilla of the situation that we’ve issued new CA certificates
which only changed the DN because of our company’s name change to facilitate
our customers' use. During the issuing process, we also consulted our auditor
about the format of new CA certificates. Also, if we don't change the DN of
certificates, it will be difficult for browser users to confirm the identity of
us when they visit the website whose certificate was signed by us because the
CA name in certificate is “Guangdong certificate…” while our actual name is
“Global Digital…”. It may cause unnecessary puzzle to browser users.
> - 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 server authentication certificates.
> Reply: We do not have any external sub-CAs.
The question is not whether you have external sub-CAs, but whether all the CAs
that are subordinate to your root have controls around issuance of server
authentication certificates.
Reply: Our CA system has realized the control that only appointed CA
certificates can issue SSL certificates. We’ve communicated with our auditor
and confirmed that the control effectiveness has been covered in their audit
work. So only CA certificates mentioned in the management assertion can issuing
SSL certificates.
> - 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.
I'm glad that the auditor has confirmed to you they did include the Network
Security criteria. However without it being included in their report, it is
not possible for a third party to have assurance they did.
Reply: The audit criteria “Webtrust Principles and Criteria for Certification
Authorities – SSL Baseline with Network Security - Version 2.0” has included
the “Network and Certificate Systems Security Requirement” which is clearly
listed in the criteria. So the baseline report has covered the audit to
“Network and Certificate Systems Security Requirement” and the third party can
easily found and confirm it.
> - 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.
The EVCS audit does not build on the SSL BR audit, so it is important that the
report calls out that the CA maintained effective controls to provide
reasonable assurance that: requests for EV CS Signing Authority and EV CS
Timestamp Authority certificates are properly authenticated; and certificates
issued to EV CS Signing Authorities and EV CS Timestamp Authorities are not
valid for a period longer than specified by the CA/Browser Forum. The report
here does not call out that the auditor confirmed there are controls to ensure
these are true. However, Mozilla no longer grants code signing trust to CAs, so
this is outside of the scope of this inclusion request.
Reply: understood. We’ve communicated with our auditor and confirmed that 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
