On Mon, Sep 19, 2016 at 1:56 AM,  <wangsn1...@gmail.com> wrote:
> 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.

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

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

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

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

Thanks,
Peter
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to