Closed Bug 1128392 Opened 5 years ago Closed 2 years ago

Add GDCA Root Certificate

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: capoc, Assigned: kwilson)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.34, FF 58, EV enabled in FF 60)

Attachments

(50 files, 3 obsolete files)

39.00 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
140.16 KB, application/pdf
Details
CP
713.04 KB, application/pdf
Details
558.15 KB, application/pdf
Details
86.08 KB, application/pdf
Details
145.25 KB, application/pdf
Details
60.57 KB, application/pdf
Details
761.03 KB, application/pdf
Details
638.38 KB, application/pdf
Details
278.14 KB, application/pdf
Details
277.75 KB, application/pdf
Details
264.68 KB, application/pdf
Details
1.39 KB, application/x-x509-ca-cert
Details
3.87 MB, application/pdf
Details
4.01 MB, application/pdf
Details
3.84 MB, application/pdf
Details
153.48 KB, application/pdf
Details
692.86 KB, application/pdf
Details
747.55 KB, application/pdf
Details
546.23 KB, application/pdf
Details
624.80 KB, application/pdf
Details
875.70 KB, application/pdf
Details
970.54 KB, application/pdf
Details
586.28 KB, application/pdf
Details
696.37 KB, application/pdf
Details
2.10 MB, application/pdf
Details
2.31 MB, application/pdf
Details
1.44 MB, application/pdf
Details
1.81 MB, application/pdf
Details
1.09 MB, application/pdf
Details
813.00 KB, application/msword
Details
2.18 MB, application/pdf
Details
1.43 MB, application/pdf
Details
1.50 MB, application/pdf
Details
1.90 MB, application/pdf
Details
314.02 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
880.36 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
880.36 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
2.36 MB, application/pdf
Details
2.13 MB, application/pdf
Details
1.84 MB, application/pdf
Details
1.45 MB, application/pdf
Details
2.15 MB, application/pdf
Details
2.50 MB, application/pdf
Details
1.56 MB, application/pdf
Details
1.95 MB, application/pdf
Details
1.32 MB, application/pdf
Details
1.28 MB, application/pdf
Details
1.52 MB, application/pdf
Details
1.24 MB, application/pdf
Details
Attached file CA Information.docx
User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)

Steps to reproduce:

Access the test websites, which possess SSL certificates issued by GDCA’s Root Certificate, using HTTPS protocol in Mozilla Firefox browser.


Actual results:

The Mozilla Firefox browser shows a warning message that root certificates are not trusted.


Expected results:

If GDCA is a Trusted Root Certificate Authority in Mozilla Firefox browser, this will benefit all Mozilla users in China and worldwide.
Accepting this bug, so I can begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
The attached document shows the information that has been verified, and where further information or clarification is needed. Please review the entire document for accuracy, and update this bug to provide corrections and the requested information.
Whiteboard: EV - Information Incomplete
Attached file CP
Add CP file.
Attached file CPS (obsolete) —
Add CPS file.
Attached file EV CP
Add EV CP file.
Attached file EV CPS (obsolete) —
Add EV CPS file.
We upload the answer for 1128392-CAInformation and CP/CPS in English. Please review.
Still needed:

1) Resolve https://certificate.revocationcheck.com/ errors
https://certificate.revocationcheck.com/ev-ssl-test-1.95105813.cn

2) Need URLs to the WebTrust CA, BR, and EV audit statements.

3) Need the CP and/or CPS to document which procedures that may be taken to verify that the certificate subscriber owns/controls the domain name to be included in the SSL certificate.
See item #3 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
and
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
1) Resolve https://certificate.revocationcheck.com/ errors
https://certificate.revocationcheck.com/ev-ssl-test-1.95105813.cn

We have resolved.

2) Need URLs to the WebTrust CA, BR, and EV audit statements.

See the update.

3) Need the CP and/or CPS to document which procedures that may be taken to verify that the certificate subscriber owns/controls the domain name to be included in the SSL certificate.
See item #3 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
and
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

See the update.
(In reply to capoc from comment #9)
> Created attachment 8664080 [details]
> Update of 1128392-CAInformation_GDCA.pdf
> 
> 1) Resolve https://certificate.revocationcheck.com/ errors
> https://certificate.revocationcheck.com/ev-ssl-test-1.95105813.cn
> 
> We have resolved.

Verified.

> 
> 2) Need URLs to the WebTrust CA, BR, and EV audit statements.
> 
> See the update.

I assume you are referring to the attachment in Comment #7...

For the audits it says: "2015/SH-124/CCYI/TWB Report of Independent Accountant on Assessment of the Assertion by the management of Guang Dong Certificate Authority Co., Ltd. (“GDCA”) for WebTrust Audit"

What does that mean?

Please provide the direct URL to the audit statements. 


> 
> 3) Need the CP and/or CPS to document which procedures that may be taken to
> verify that the certificate subscriber owns/controls the domain name to be
> included in the SSL certificate.
> See item #3 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices
> and
> https://wiki.mozilla.org/CA:
> Recommended_Practices#Verifying_Domain_Name_Ownership
> 
> See the update.

The attachment to Comment #7 says: CP Section 3.2.2, 3.2.3, 3.2.5. CPS Section 3.2.2, 3.2.3, 3.2.4, 3.2.7.

CP section 3.2.2 - Authentication of Organization Identity says: 
"GDCA must verify the permission of certificate request when domain name, device name or email address is used as subject content in certificate. For example, the organization should submit ownership documents of domain name or written ownership commitment of applicant, etc.
If necessary, GDCA can also verify the applicants’ identities using the information obtained from the third-party. If GDCA can’t get all the required information from a third-party, it may delegate a third-party to conduct an investigation or require certificate applicants to provide additional information and evidence material."

But that does not say which steps are taken to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate.

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
"The CA's public documentation needs to provide sufficient information describing the steps taken by the CA to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. For instance, if a challenge-response type of procedure is used, then there needs to be a brief description of the process. If public resources are used, then there should be a description of which public resources are used, what data is retrieved from public resources, and how that data is used to verify that the certificate subscriber owns/controls the domain name. ..."
Maybe the attachment you see is the old one. And the latest reply is "Update of 1128392-CAInformation_GDCA.pdf ". 

2) Need URLs to the WebTrust CA, BR, and EV audit statements.
a)Standard Audit
https://cert.webtrust.org/SealFile?seal=1859&file=pdf
b) BR Audit
https://cert.webtrust.org/SealFile?seal=1862&file=pdf
c) EV Audit
https://cert.webtrust.org/SealFile?seal=1861&file=pdf

3) Need the CP and/or CPS to document which procedures that may be taken to verify that the certificate subscriber owns/controls the domain name to be included in the SSL certificate.

see CPS Section 3.2.5.
(In reply to capoc from comment #11)
> 3) Need the CP and/or CPS to document which procedures that may be taken to
> verify that the certificate subscriber owns/controls the domain name to be
> included in the SSL certificate.
> 
> see CPS Section 3.2.5.


https://bug1128392.bmoattachments.org/attachment.cgi?id=8650347 -- English translation of CPS
"3.2.5. Domain Recognition and Identification
If the certificate name is a domain name (or IP address), except for reviewing submitted written 16
materials, GDCA should review identification documents of this domain name (or IP address) provided by applicant or query corresponding RA of domain name (RA of IP) or third-party. GDCA also need to take other review measures to confirm the ownership of the domain name (or IP address). Applicant can’t refuse to the request for providing appropriate assistance."

This is insufficient to meet Mozilla's requirements.

Please refer to
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
and
https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
Attached file CPS.pdf
update 3.2.5.
Attachment #8650347 - Attachment is obsolete: true
Attached file EV CPS.pdf
update 3.2.5.
Attachment #8650349 - Attachment is obsolete: true
(In reply to Kathleen Wilson from comment #12)
> (In reply to capoc from comment #11)
> 3) Need the CP and/or CPS to document
> which procedures that may be taken to
> verify that the certificate
> subscriber owns/controls the domain name to be
> included in the SSL
> certificate.
> 
> see CPS Section 3.2.5.

> https://bug1128392.bmoattachments.org/attachment.cgi?id=8650347 -- English
> translation of CPS
"3.2.5. Domain Recognition and Identification
If the
> certificate name is a domain name (or IP address), except for reviewing
> submitted written 16
materials, GDCA should review identification documents
> of this domain name (or IP address) provided by applicant or query
> corresponding RA of domain name (RA of IP) or third-party. GDCA also need to
> take other review measures to confirm the ownership of the domain name (or
> IP address). Applicant can’t refuse to the request for providing appropriate
> assistance."

This is insufficient to meet Mozilla's requirements.

Please
> refer to
> https://wiki.mozilla.org/CA:
> Recommended_Practices#Verifying_Domain_Name_Ownership
and
> https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs

We have updated Section 3.2.5 of "CPS.pdf" and "EV CPS.pdf". 
The SSL Verification Procedures and EV SSL Verification Procedures are:
1. GDCA should confirm that the domain's owner is certificate applicant based on the information queried from corresponding domain registrant or authoritative third-party database and provided by applicant.
2. GDCA should confirm that the significant information (such as document information of applicant) in application materials are consistent with the reply of domain's owner by sending email or making phone call based on the contact information (such as email, registrar, administrator's email published at this domain's website, etc.)queried from corresponding domain registrant or authoritative third-party database.
Attached file 1128392-CAInformation-Complete.pdf (obsolete) —
This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

In the meantime, please make sure that the changes that you made to the English version of the CPS and EV CPS also get made to the Chinese versions of those documents.

Note: Mozilla is no longer enabling the Code Signing trust bit for root certs, because the Code Signing trust bit will be removed in the next version of our policy.
Reference: https://wiki.mozilla.org/CA:CertificatePolicyV2.3
Summary: Add GDCA Root Certificates → Add GDCA Root Certificate
Whiteboard: EV - Information Incomplete → EV -Ready for Public Discussion
We recently added two additional tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

No errors returned for Test 1.

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
~~
Using certificate chain from 'https://ev-ssl-test-1.95105813.cn/'

Using certificate from local file 'GDCA_TrustAUTH_R5_ROOT.cert'

    /C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE5\xB9\xBF\xE5\xB7\x9E\xE5\xB8\x82/1.3.6.1.4.1.311.60.2.1.3=CN/1.3.6.1.4.1.311.60.2.1.2=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/1.3.6.1.4.1.311.60.2.1.1=\xE4\xBD\x9B\xE5\xB1\xB1\xE5\xB8\x82/serialNumber=74709895-8/businessCategory=private/O=\xE5\xB9\xBF\xE4\xB8\x9C\xE6\x95\xB0\xE5\xAD\x97\xE8\xAF\x81\xE4\xB9\xA6\xE8\xAE\xA4\xE8\xAF\x81\xE4\xB8\xAD\xE5\xBF\x83\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/OU=\xE7\xA0\x94\xE5\x8F\x91\xE9\x83\xA8/CN=mall.gdca.com.cn
        Error
            1.3.6.1.4.1.311.60.2.1.3 must be PrintableString
        Notice
            businessCategory could be encoded as PrintableString
            CN could be encoded as PrintableString
~~

Please add a comment in this bug when the error has been resolved.
(In reply to Kathleen Wilson from comment #18)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/
We have updated the certificate, please try again.
(In reply to Kathleen Wilson from comment #19)
> (In reply to Kathleen Wilson from comment #18)
> Test 2) Browse to
> http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to
> https://cert-checker.allizom.org/
(In reply to capoc from comment #20)
> We have updated the certificate, please try again.

I confirm that https://cert-checker.allizom.org/ is no longer listing errors for this root and test website.
EV Audit Report for 2016. The root certificate doesn't been reissued.
SSL Audit Report for 2016.
WebTrust Audit Report for 2016.
Will these audit statements also be posted on the webtrust.org website?
If yes, please update this bug with the URLs when they are available.

My notes say that the document repository and the intermediate certs are here:
http://www.gdca.com.cn/TrustAUTH/
But now that returns an error.
What is the new URL?
I just reviewed the new audit statements, and none of them state which root and intermediate certificates were actually audited. Please ask your auditors to update these statements to indicate this information.
(In reply to Kathleen Wilson from comment #26)
> Will these audit statements also be posted on the webtrust.org website?
If
> yes, please update this bug with the URLs when they are available.

My notes
> say that the document repository and the intermediate certs are here:
> http://www.gdca.com.cn/TrustAUTH/
But now that returns an error.
What is the
> new URL?

audit statements are as follows:
webtrust ca:https://cert.webtrust.org/ViewSeal?id=2024
webtrust br:https://cert.webtrust.org/ViewSeal?id=2025
webtrust ev:https://cert.webtrust.org/ViewSeal?id=2026


new URL:
https://www.gdca.com.cn/customer_service/knowledge_universe/ca_cq/
(In reply to Kathleen Wilson from comment #27)
> I just reviewed the new audit statements, and none of them state which root
> and intermediate certificates were actually audited. Please ask your
> auditors to update these statements to indicate this information.

Please refer to the new version of our audit report, which
includes the audited roots.  This is the version we sent to WebTrust for
register and seal.
Attachment #8698666 - Attachment is obsolete: true
I am now opening the public discussion period for this request from Guangdong Certificate Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Guang Dong Certificate Authority (GDCA) root inclusion request".

Please actively review, respond, and contribute to the discussion.

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV -Ready for Public Discussion → EV -In Public Discussion
Attached file CP_V1.4.pdf
Attached file CPS_V4.3.pdf
Attached file EV CP_V1.2.pdf
Attached file EV CPS_V1.3.pdf
Attached file CP_20161028.pdf
Attached file CPS_20161028.pdf
Attached file EV CP_20161028.pdf
Attached file EV CPS_20161028.pdf
Per discussion (https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/aOa8Y4ocCgAJ) the explanation for the problems with the previous translations of the CP/CPS documents has been accepted as reasonable. Therefore, the discussion will continue after the CA provides updated versions of the translations of the CP/CPS documents.
Attached file GDCA-CP-V1.5.pdf
Attached file GDCA-CPS-V4.4.pdf
Attached file GDCA-EVCP-V1.3.pdf
Attached file GDCA-EVCPS-V1.4.pdf
Flags: needinfo?(patrickt)
Flags: needinfo?(patrickt)
Whiteboard: EV -In Public Discussion → [ca-discussion] -- EV
The discussion of this request is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/kB2JrygK7Vk/b_22zTwIBAAJ

The status of the discussion is that I am waiting for a member of the community to do a thorough review of the udpated CP/CPS documents.
https://wiki.mozilla.org/CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

The problem is that the people who have been doing these reviews are too busy right now to do them. We are looking into ways to solve this problem.

In the meantime, I think we would be able to move forward with this request if a representative of the CA does the following:

Attach a document to this bug showing the results of a careful comparison of the current version of the CA/Browser Forum's Baseline Requirements with the CA's CP/CPS. Then update the discussion to provide a link to that document.
Current version of the BRs: 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
For section 3.2.2.4 (Domain validation), use:
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

That comparison is basically what the member of the community would do in regards to the thorough review of the CP/CPS. Therefore, if the CA provides the evaluation, it will make the job much easier for a member of the community to confirm their findings.

Best Regards,
We uploaded a comparison document regarding the compliance of GDCA’s CP and CPS with the BRs, is it necessary to post this link to the Google discussion board?
Whiteboard: [ca-discussion] -- EV → [ca-in-discussion] -- EV
(In reply to capoc from comment #49)
> Created attachment 8851230 [details]
> Analysis on the Compliance of GDCA’s CP and CPS with the Baseline
> Requirements - 25 March 2017 .pdf
> 
> We uploaded a comparison document regarding the compliance of GDCA’s CP and
> CPS with the BRs, is it necessary to post this link to the Google discussion
> board?

This is great! Thanks for reviewing the BRs and providing your self-assessment.

Throughout the document you mention updates to your next version. When do you plan to do that?

I will also post about this in the discussion.
Whiteboard: [ca-in-discussion] -- EV → [ca-in-discussion] -- EV -- BR Self Assessment Completed
Flags: needinfo?(patrickt)
Flags: needinfo?(patrickt)
(In reply to Kathleen Wilson from comment #50)
> (In reply to capoc from comment #49)
> > Created attachment 8851230 [details]
> > Analysis on the Compliance of GDCA’s CP and CPS with the Baseline
> > Requirements - 25 March 2017 .pdf
> > 
> > We uploaded a comparison document regarding the compliance of GDCA’s CP and
> > CPS with the BRs, is it necessary to post this link to the Google discussion
> > board?
> 
> This is great! Thanks for reviewing the BRs and providing your
> self-assessment.
> 
> Throughout the document you mention updates to your next version. When do
> you plan to do that?
> 
> I will also post about this in the discussion.

We plan to publish the next version of our CP/CPS on around 20 April 2017.
I have been trying to confirm that Wang Shengnan is an authorized representative of GDCA and should have the requested CA Community license. GDCA is included already by Microsoft, so can have a CA Community license, even though not yet included by Mozilla. 

But all email I send to anyone at @gdca.com.cn is failing with:

Remote-MTA: dns; mail.gdca.com.cn. (119.145.171.202, the server for the domain gdca.com.cn.)
Diagnostic-Code: smtp; 454 4.7.0 TLS not available due to local problem
Last-Attempt-Date: Sun, 02 Apr 2017 00:01:13 -0700 (PDT)

Remote-MTA: dns; mail.gdca.com.cn. (119.145.171.202, the server for the domain gdca.com.cn.)
Diagnostic-Code: smtp; 454 4.7.0 TLS not available due to local problem
Last-Attempt-Date: Sat, 01 Apr 2017 15:50:09 -0700 (PDT)
(In reply to Kathleen Wilson from comment #53)
> I have been trying to confirm that Wang Shengnan is an authorized
> representative of GDCA and should have the requested CA Community license.
> GDCA is included already by Microsoft, so can have a CA Community license,
> even though not yet included by Mozilla. 
> 
> But all email I send to anyone at @gdca.com.cn is failing with:
> 
> Remote-MTA: dns; mail.gdca.com.cn. (119.145.171.202, the server for the
> domain gdca.com.cn.)
> Diagnostic-Code: smtp; 454 4.7.0 TLS not available due to local problem
> Last-Attempt-Date: Sun, 02 Apr 2017 00:01:13 -0700 (PDT)
> 
> Remote-MTA: dns; mail.gdca.com.cn. (119.145.171.202, the server for the
> domain gdca.com.cn.)
> Diagnostic-Code: smtp; 454 4.7.0 TLS not available due to local problem
> Last-Attempt-Date: Sat, 01 Apr 2017 15:50:09 -0700 (PDT)

We have fixed the e-mail problem, please send again to: capoc@gdca.com.cn, and please cc to: wangsn1206@gmail.com.

Thanks.
> We plan to publish the next version of our CP/CPS on around 20 April 2017.(In reply to capoc from comment #51)
Has this been posted yet? If so will you please attach or share URL?
Attached file CP_V1.6
Attached file CPS_V4.5.pdf
Attached file EV CP_V1.4.pdf
Attached file EV CPS_V1.5.pdf
We have just published the updated CP/CPS documents, this version has been revised according to the latest Baseline Requirements and has been reviewed internally, meanwhile, the points our “Analysis on the Compliance of GDCA’s CP and CPS with the Baseline Requirements (published on March 25, 2017)” promised to disclose have been included in this version, and we will update the compliance analysis document as soon as possible.
(In reply to capoc from comment #60)
> We have just published the updated CP/CPS documents, this version has been
> revised according to the latest Baseline Requirements and has been reviewed
> internally, meanwhile, the points our “Analysis on the Compliance of GDCA’s
> CP and CPS with the Baseline Requirements (published on March 25, 2017)”
> promised to disclose have been included in this version, and we will update
> the compliance analysis document as soon as possible.


When you "update the compliance analysis document as soon as possible" I ask that you please use the attached "Analysis on the Compliance of GDCA’s CP and CPS with the Baseline Requirements - 20 April 2017.docx" (attachment 8860075 [details]) as your starting point. This will save time as no further action is needed for "Compliant" sections. Thank you.
Please check our second BR self-assessment against our updated CP/CPS (CP V1.6, CPS V4.5, EV CP V1.4, and EV CPS V1.5).You can find the document at the following address of the BUG:https://bugzilla.mozilla.org/attachment.cgi?id=8860627

Thanks.
Product: mozilla.org → NSS
Aaron, please review the updated BR Self Assessment.
Assignee: kwilson → awu
Greetings, I have reviewed your second BR self-assessment (https://bugzilla.mozilla.org/attachment.cgi?id=8860627) against your updated CP/CPS (CP V1.6, CPS V4.5, EV CP V1.4, and EV CPS V1.5) and provided comments and/or recommendations in the public discussion (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/kB2JrygK7Vk)
Attached file GDCA CP V1.7.pdf
Attached file GDCA CPS V4.6.pdf
Attached file GDCA EV CP V1.5.pdf
Attached file GDCA EV CPS V1.6.pdf
Hi.

Thanks for update your CP/CPS as following:
CP V1.7: https://bug1128392.bmoattachments.org/attachment.cgi?id=8871236 
CPS V4.6: https://bug1128392.bmoattachments.org/attachment.cgi?id=8871237 
EV CP V1.5: https://bug1128392.bmoattachments.org/attachment.cgi?id=8871238 
EV CPS V1.6: https://bug1128392.bmoattachments.org/attachment.cgi?id=8871240 

We are reviewing your 2nd BR Self Assessment and the CP/CPS above now, will get back to you soon. Please stay tuned, thanks!

Regards,
Aaron
We are verifying the BR Self Assessment you provided, there are two things still need your input/update

1. Since your root requests Website trust bit, please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired

2. I found the effective date of your current audit statement is during the period from 1st March 2015 through 29th February 2016. Could you please update your audit statement accordingly?

Thanks,
Aaron
Attached file WebTrust CA-2017.pdf
Attached file WebTrust BR-2017.pdf
Hi Aaron,
 
Thanks for your reply.
 
1.Regarding the three URLs to the test websites (valid: https://SSLTEST-1.95105813.cn, revoked: https://SSLTEST-2.95105813.cn, and expired: https://SSLTEST-3.95105813.cn), Kathleen indicated that the three test websites are those items that can be verified directly and thus do not need to be in the CP/CPS. Please check our discussion with Kathleen: 
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Y-PxWRCIcck/fVvDeYXrAAAJ
 
2.Our audit reports had been updated in CCADB, and hereby we upload these reports to the bug for your reference:
WebTrust CA: https://bug1128392.bmoattachments.org/attachment.cgi?id=8879424
WebTrust BR: https://bug1128392.bmoattachments.org/attachment.cgi?id=8879425
WebTrust EV SSL: https://bug1128392.bmoattachments.org/attachment.cgi?id=8879426
WebTrust EV CS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8879428
 
Please also check our WebTrust seals at: 
WebTrust CA: https://cert.webtrust.org/ViewSeal?id=2231
WebTrust BR: https://cert.webtrust.org/ViewSeal?id=2232
WebTrust EV SSL: https://cert.webtrust.org/ViewSeal?id=2233
WebTrust EV CS: https://cert.webtrust.org/ViewSeal?id=2234
 
Many Thanks.
Regards
Wang Shengnan
Hi Aaron, any update on this? Tnank you.
This request has been evaluated as per Mozilla’s Root Store Policy at

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

CA Owner: Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA))
Geographic Focus: China
Primary Market / Customer Base:
a) Business corporations registered in mainland China
b) Government agencies of China
c) Individuals or mainland China citizens
d) Servers of business corporations which have been registered in mainland China
e) Software developers
Impact to Mozilla Users: GDCA is one of the biggest Certification Authorities in China. GDCA is a national recognized CA and operates under China’s Electronic Signature Law. More than 80% of our certificate users are organization or company entity, which has a large demand for SSL certificates.
	 
Subject: CN=GDCA TrustAUTH R5 ROOT, OU=null, O=GUANG DONG CERTIFICATE AUTHORITY CO.,LTD., C=CN
Trust Bits: Websites
EV Policy OID: 1.2.156.112559.1.1.6.1

Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8748933
https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der

Certificate Summary: This root has internally-operated subordinate CAs.
Note: Company name changing to 'Global Digital Cybersecurity Authority.Corp.

Documents are provided in Chinese and English:

https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA1.7GDCA-CP-V1.7/
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA-EV1.5GDCA-EV-CP-V1.5/
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCAV4.6GDCA-CPS-V4.6/
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA-EV1.6GDCA-EV-CPS-V1.6/

BR Self Assessment: https://bugzilla.mozilla.org/attachment.cgi?id=8860627

Certificate Revocation
CRL URL(s): 
http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R5_ROOT.crl
http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_SSL_CA.crl
http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_Extended_Validation_SSL_CA.crl
http://www.gdca.com.cn/crl/GDCA_TrustAUTH_R4_Generic_CA.crl
OCSP URL(s): 
http://www.gdca.com.cn/TrustAUTH/ocsp

GDCA appears to meet the minimum requirements for subscriber verification, as follows:

* SSL Verification Procedures: CP section 3.2.7 says: 
“GDCA may use one of the following ways for the validation of domain names:
1. Obtain the e-mail address or phone number of the domain name owner listed by the domain name registrar or other authoritative third party  database, and check the key information (e.g. documentation information or domain name details etc.) with the owner by emails or phone calls to confirm its ownership of the domain name. This way of validation conformsto section 3.2.2.4.3 and section 3.2.2.4.4 of the Baseline Requirements v1.4.1.
2. Verify according tothe domain authorization documents provided by the domain name registrar. This way of validation conforms to section 3.2.2.4.5 of the Baseline Requirements v1.4.1.
3. By making a change to the agreed-upon information found on an online Web page identified by a uniform resource identifier containing the FQDN, to confirm the applicant’s practical control over the FQDN. This way of validation conforms to section 3.2.2.4.6 of the Baseline Requirements v1.4.1.

* EV SSL Verification Procedures: EV CPS Section 3.2.2.2

* Email Verification Procedures: Not requesting Email trust bit.

* Code Signing Subscriber Verification Procedure: Mozilla is no longer enabling the Code Signing trust bit for root certs.

CA Hierarchy: CP and EV CP section 1.1.4
This root has the following internally-operated subCAs:
- GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs)
- GDCA TrustAUTH R4 Generic CA (issues 2048-bit individual certs)
- GDCA TrustAUTH R4 CodeSigning CA (issues 2048-bit CodeSigning certs)
- GDCA TrustAUTH R4 Extended Validation SSL CA (issues 2048-bit EV SSL certs)
- GDCA TrustAUTH R4 Extended Validation Code Signing CA (issues 2048-bit EV CodeSigning certs)
Externally Operated SubCAs: None. None planned
Cross Signing: None. None planned.

Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP, according to the WebTrust criteria.
Standard Audit: https://cert.webtrust.org/SealFile?seal=2231&file=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=2232&file=pdf
EV Audit: https://cert.webtrust.org/SealFile?seal=2233&file=pdf

Based on this assessment, I intend to approve this request to include the GDCA TrustAUTH R5 ROOT certificate, turn on the Websites trust bit, and enabled EV treatment.
Whiteboard: [ca-in-discussion] -- EV -- BR Self Assessment Completed → [ca-pending-approval] -- EV
As per the summary in Comment #84, and on behalf of Mozilla I approve this request from Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA)) to include the following root certificate:

** 'GDCA TrustAUTH R5 ROOT' (Websites), enable EV

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: [ca-pending-approval] -- EV → [ca-approved] - Pending NSS and PSM Changes
Depends on: 1385063
Depends on: 1385065
I have filed bug #1385063 against NSS and bug #1385065 against PSM for the actual changes.
Whiteboard: [ca-approved] - Pending NSS and PSM Changes → [ca-approved] - In NSS 3.34, FF 58, pending PSM Changes for EV
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Assignee: awu → kwilson
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - In NSS 3.34, FF 58, pending PSM Changes for EV → [ca-approved] - In NSS 3.34, FF 58, EV enabled in FF 60
You need to log in before you can comment on or make changes to this bug.