Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Kathleen Wilson via dev-security-policy]

Thanks to all of you who reviewed and commented on 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. 

I believe that all of the concerns that were raised in this discussion have 
been properly addressed, and I will state my intent to approve this request in 
the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1128392

I am now closing this discussion. Any further follow-up should be added 
directly to the bug.

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Kathleen Wilson via dev-security-policy]

The updated documents are also posted on the CA's website:
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/

Current audit statements are here:
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

Unless anyone raises further questions or concerns, I plan to close this 
discussion and recommend approval of this request to include "GDCA TrustAUTH R5 
ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment.

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

Hi All, 

We have just updated and published our CP/CPS, and the latest versions are 
available at:
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 wish these documents will be fully discussed and commented.
Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年5月17日星期三 UTC+8下午5:18:59，Rob Stradling写道：
> On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote:
> > 在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道：
> >> On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
> >> 
>  * CPS Appendix1: Certificate information of the publicly trusted CAs: 
>  Most
>  of the listed CAs can't be found in crt.sh - it would be great to get 
>  them
>  CT logged.
> 
> >>> Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation 
> >>> cannot be done for the other two ROOTs as we have not yet applied for the 
> >>> inclusion of these two.
> >>
> >> Hi.
> >>
> >> Would you like me to add your other two roots to the list of roots that
> >> are accepted by the Comodo Dodo log?
> >>
> >> If so, please either submit a pull request on GitHub (see
> >> https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two
> >> root certs.
> >>
> >> The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh.
> > 
> > Hi Rob,
> > 
> > Thanks for your kind assistance, we have e-mailed our roots to you for this 
> > purpose.
> 
> Our Dodo log now accepts the "GDCA TrustAUTH E5 ROOT" and "数安时代 R5 根 CA" 
> root certificates, and I've submitted both of them to Dodo.  You can see 
> them here:
> 
> https://crt.sh/?id=139646527
> https://crt.sh/?id=139646529
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

Thanks Rob.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Rob Stradling via dev-security-policy]

On 12/05/17 06:51, wangsn1206--- via dev-security-policy wrote:

在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道：

On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:


* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh - it would be great to get them
CT logged.


Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be 
done for the other two ROOTs as we have not yet applied for the inclusion of 
these two.


Hi.

Would you like me to add your other two roots to the list of roots that
are accepted by the Comodo Dodo log?

If so, please either submit a pull request on GitHub (see
https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two
root certs.

The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh.


Hi Rob,

Thanks for your kind assistance, we have e-mailed our roots to you for this 
purpose.


Our Dodo log now accepts the "GDCA TrustAUTH E5 ROOT" and "数安时代 R5 根 CA" 
root certificates, and I've submitted both of them to Dodo.  You can see 
them here:


https://crt.sh/?id=139646527
https://crt.sh/?id=139646529

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年5月16日星期二 UTC+8上午5:19:14，Patrick Tronnier写道：
> 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 the 
> following comments and/or recommendations.
> 
> 
> 1. BR Section 3.2.2.5 Authentication for an IP: Per your comments please make 
> sure your CPS states “GDCA does not issue EV certificate for an IP address.”
> 
> 2. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
> length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
> section 3.2.11 of your CPS.   
> 
> 3. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
> length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
> section 3.2.7 of your EV CPS.   
> 
> 4. BR Section 3.2.3 Authentication of Individual Identity: I do not see in 
> the CPS/CP where the differences in authentication of individuals is backed 
> up by the appropriate technical constraining of the type of certificate 
> issued. 
>4.1.   Your comments for Type I and Type II Individual Certificates 
> state they “are only for ordinary signing certificates, not for SSL 
> certificates and code signing certificates” but I can’t find in the CPS where 
> this is substantiated. I recommend clearly documenting in the CPS how each 
> type of certificate is technically constrained (i.e. Key Usage, Enhanced Key 
> Usage, etc.) and in CPS section 1.3.7.1 removing the words “but not limited 
> to”. 
>4.2.   For Type III certificates change the word “can” to “must”. 
> (i.e. This must be validated by ID card, officer card or other valid document 
> issued by government agency.”
> 
> 5. BR Section 3.2.5 Validation of Authority: Per your comments please make 
> sure this is clearly defined in the next version of your CPS.
> 
> 6. BR Section 3.2.6 Criteria for Interoperation or Certification. Per your 
> comments please make sure the next version of your CPS states you do not 
> issue any cross certificates. 
> 
> 7. BR Section 4.2.1 Performing Identification and Authentication Functions. 
> Per your comments please make sure the next version of your CPS states you do 
> not rely on data older than 27 months (or 39 months or 825 days per BRs).
> 
> 8. BR Section 4.2.2 Approval or Rejection of Certificate Applications: Per 
> your comments please make sure the next version of your CPS states GDCA does 
> not issue certificates containing a new gTLD under consideration by ICANN.
> 
> 9. BR Section 4.3.1 CA Actions during Certificate Issuance: Per your comments 
> please make sure the next version of your CPS states “Certificate issuance by 
> the Root CA SHALL require an individual authorized by the CA (i.e. the CA 
> system operator, system officer, or PKI administrator) to deliberately issue 
> a direct command in order for the Root CA to perform a certificate signing 
> operation.”
> 
> 10. BR Section 4.5.1 Subscriber private key and certificate usage: Per your 
> comments please make sure the next version of your CPS details the use of SSL 
> certificates per #4 (Use of Certificate) as described in BR Section 9.6.3. 
> Subscriber Representations and Warranties.
> 
> 11. BR Section 4.9.13 Circumstances for Suspension: Per your comments please 
> make sure the next version of your CPS states certificate suspension is not 
> allowed.
> 
> 12. BR Section 4.10.1 Operational Characteristics: Per your comments please 
> make sure the next version of your CPS states “Revocation entries on a CRL or 
> OCSP Response will not be removed until after the Expiry Date of the revoked 
> Certificate”.
> 
> 13. BR Section 4.10.2 Service Availability: Per your comments please make 
> sure the next version of your CPS states “the service response time shall be 
> less than 10 seconds”.
> 
> 14. Based on your self assessment comments in BR sections 1 – 4, I submit it 
> would be useful for you to revisit your assessment of BR sections 5 
> (MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS) through section 9 (OTHER 
> BUSINESS AND LEGAL MATTERS) and update your BR Assessment.

Hi Patrick, 

Thanks for the comments and recommendations, which will be duly considered as 
necessary in the next version of our CP/CPS to be published on around May 25, 
2017.
Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Patrick Tronnier via dev-security-policy]

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 the 
following comments and/or recommendations.


1. BR Section 3.2.2.5 Authentication for an IP: Per your comments please make 
sure your CPS states “GDCA does not issue EV certificate for an IP address.”

2. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
section 3.2.11 of your CPS.   

3. BR Section 3.2.2.7 Data Source Accuracy: I recommend adding the specific 
length of time data is relied upon (i.e. 39 months or 825 days per BRs) to 
section 3.2.7 of your EV CPS.   

4. BR Section 3.2.3 Authentication of Individual Identity: I do not see in the 
CPS/CP where the differences in authentication of individuals is backed up by 
the appropriate technical constraining of the type of certificate issued. 
   4.1. Your comments for Type I and Type II Individual Certificates state they 
“are only for ordinary signing certificates, not for SSL certificates and code 
signing certificates” but I can’t find in the CPS where this is substantiated. 
I recommend clearly documenting in the CPS how each type of certificate is 
technically constrained (i.e. Key Usage, Enhanced Key Usage, etc.) and in CPS 
section 1.3.7.1 removing the words “but not limited to”. 
   4.2. For Type III certificates change the word “can” to “must”. (i.e. This 
must be validated by ID card, officer card or other valid document issued by 
government agency.”

5. BR Section 3.2.5 Validation of Authority: Per your comments please make sure 
this is clearly defined in the next version of your CPS.

6. BR Section 3.2.6 Criteria for Interoperation or Certification. Per your 
comments please make sure the next version of your CPS states you do not issue 
any cross certificates. 

7. BR Section 4.2.1 Performing Identification and Authentication Functions. Per 
your comments please make sure the next version of your CPS states you do not 
rely on data older than 27 months (or 39 months or 825 days per BRs).

8. BR Section 4.2.2 Approval or Rejection of Certificate Applications: Per your 
comments please make sure the next version of your CPS states GDCA does not 
issue certificates containing a new gTLD under consideration by ICANN.

9. BR Section 4.3.1 CA Actions during Certificate Issuance: Per your comments 
please make sure the next version of your CPS states “Certificate issuance by 
the Root CA SHALL require an individual authorized by the CA (i.e. the CA 
system operator, system officer, or PKI administrator) to deliberately issue a 
direct command in order for the Root CA to perform a certificate signing 
operation.”

10. BR Section 4.5.1 Subscriber private key and certificate usage: Per your 
comments please make sure the next version of your CPS details the use of SSL 
certificates per #4 (Use of Certificate) as described in BR Section 9.6.3. 
Subscriber Representations and Warranties.

11. BR Section 4.9.13 Circumstances for Suspension: Per your comments please 
make sure the next version of your CPS states certificate suspension is not 
allowed.

12. BR Section 4.10.1 Operational Characteristics: Per your comments please 
make sure the next version of your CPS states “Revocation entries on a CRL or 
OCSP Response will not be removed until after the Expiry Date of the revoked 
Certificate”.

13. BR Section 4.10.2 Service Availability: Per your comments please make sure 
the next version of your CPS states “the service response time shall be less 
than 10 seconds”.

14. Based on your self assessment comments in BR sections 1 – 4, I submit it 
would be useful for you to revisit your assessment of BR sections 5 
(MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS) through section 9 (OTHER 
BUSINESS AND LEGAL MATTERS) and update your BR Assessment.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年5月11日星期四 UTC+8下午5:58:00，Rob Stradling写道：
> On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
> 
> >> * CPS Appendix1: Certificate information of the publicly trusted CAs: Most
> >> of the listed CAs can't be found in crt.sh - it would be great to get them
> >> CT logged.
> >>
> > Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot 
> > be done for the other two ROOTs as we have not yet applied for the 
> > inclusion of these two.
> 
> Hi.
> 
> Would you like me to add your other two roots to the list of roots that 
> are accepted by the Comodo Dodo log?
> 
> If so, please either submit a pull request on GitHub (see 
> https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two 
> root certs.
> 
> The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh.
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

Hi Rob,

Thanks for your kind assistance, we have e-mailed our roots to you for this 
purpose.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Rob Stradling via dev-security-policy]

On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:


* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh - it would be great to get them
CT logged.


Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be 
done for the other two ROOTs as we have not yet applied for the inclusion of 
these two.


Hi.

Would you like me to add your other two roots to the list of roots that 
are accepted by the Comodo Dodo log?


If so, please either submit a pull request on GitHub (see 
https://github.com/Comodo-CA/CTLogs-AcceptedRoots) or send me the two 
root certs.


The Comodo Dodo log isn't trusted by Chrome, but it is monitored by crt.sh.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

Hi Andrew,

Thanks for the comments. Please check our following responses. 

> * Please don't protect your PDFs for printing
>
We have removed the restrictions on the printing of the PDF documents and 
re-uploaded them to the BUG, these documents are available at:

https://bug1128392.bmoattachments.org/attachment.cgi?id=888
https://bug1128392.bmoattachments.org/attachment.cgi?id=889
https://bug1128392.bmoattachments.org/attachment.cgi?id=8866670
https://bug1128392.bmoattachments.org/attachment.cgi?id=8866671
 
> * https://SSLTEST-2.95105813.cn - which I believe should be revoked, has
> also expired.  The revoked test cert should be otherwise valid and not
> expired.
> 
We have replaced the certificate. Please check.

> * While there is mention of how CAA records are dealt with in section
> 4.2.4, it doesn't seem to specify what value is expected to be present in
> the record for the check to pass.
> 
GDCA will not issue corresponding certificates if the "issue", 
"issuewild"property tags do not contain“gdca.com.cn”. In case the property tag 
“iodef” is present in the CAA records, GDCA will determine whether or not to 
issue certificates after communicating with the applicant. 

> * 3.2.7. 域名的确认和鉴别 Domain name recognition and identification - This section
> references BR version v1.4.1. Version 1.4.4 is current and has changes in
> the section numbers referred to here.  (Also see versions under IPR review
> on the CAB Forum website)
> 
As required by Mozilla, CPS V4.5 uses methods documented in section 3.2.2.4 of 
version 1.4.1 of the CA/Browser Forum's Baseline Requirements (BRs)for domain 
validation. We will checkBR v1.4.3 and later versions and update this section 
as necessary. 

> * 7.1 Certificate profile: There is no mention of how the serial number is
> generated. The BRs specify "Effective September 30, 2016, CAs SHALL
> generate non‐sequential Certificate serial numbers greater than zero (0)
> containing at least 64 bits of output from a CSPRNG."
> 
In our next version, we will disclose: “Certificate serial number--Within the 
domain of each Issuing CA, GDCA includes a unique non-sequential Certificate 
serial number greater than zerocontaining at least 64 bits of output from a 
CSPRNG.”

> * CP 7.1.3 says "The cryptographic algorithm identifiers of certificates
> issued by GDCA include sha1RSA, sha256RSA and sha256ECDSA".  SHA1
> signatures must not be used in any part of the publically trusted hierarchy.
> 
Certificates of GDCA's publically trusted CAs do not use sha1RSA signing 
algorithm. We will definitely disclose in the next version.

> * CP 7.1.5 on "Name Constraints" looks like it's referring to 3.1.2 "Need
> for names to be meaningful".  This section is meant to refer to RFC 5280
> section 4.2.1.10 name constraints.
> 
The content of section 7.1.5 of CP/CPS will be moved to section 3.1.2 in the 
next version of CP/CPS. And GDCA has no stipulation on Name Constraints. 

> * CPS Appendix1: Certificate information of the publicly trusted CAs: Most
> of the listed CAs can't be found in crt.sh - it would be great to get them
> CT logged.
> 
Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation cannot be 
done for the other two ROOTs as we have not yet applied for the inclusion of 
these two. 

> * Only GDCA TrustAUTH R5 ROOT (SHA-1 Fingerprint
> 0F:36:38:5B:81:1A:25:C3:9B:31:4E:83:CA:E9:34:66:70:CC:74:B4) seems to have
> been disclosed in Mozilla's CCADB.
> 
We have uploaded all the intermediate certificates of the GDCA TrustAUTH R5 
ROOT in the CCADB. According to the CCADB rules, CAs can only upload 
intermediate certificates, and only Root Store Members can upload root 
certificates, therefore, GDCA has not uploaded the 数安时代R5根CA and the GDCA 
TrustAUTH E5 ROOTand their respective intermediate certificates. 

For your information, we expect to publish the next version of our CP/CPS on 
around May 25, 2017, with the latest comments and BR v1.4.4 taken into 
consideration. 

And as always, we welcome all comments and suggestions. 

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年4月20日星期四 UTC+8下午11:31:14，Patrick Tronnier写道：
> On Thursday, April 20, 2017 at 9:30:31 AM UTC-4, wangs...@gmail.com wrote:
> > 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. Please find the new 
> > version at:
> > CP V1.6: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860016
> > CPS V4.5: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860018
> > EV CP V1.4: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860019
> > EV CPS V1.5: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860020
> > 
> > We wish these documents will be fully discussed by the public, so that 
> > Mozilla can make decision on this root inclusion application.
> > All comments and suggestions are welcomed. Thanks.
> 
> I updated your bug with a review of your initial BR-self-assessment using the 
> previously posted CPS's. The review is attachment 
> https://bugzilla.mozilla.org/attachment.cgi?id=8860075. 
> 
> Would you please complete a second BR-self-assessment against the just posted 
> CPS's and CP's and use my attachment as your starting point? Thank you.

Hi Patrick,

Thanks for the comments.

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

We welcome all comments and suggestions. 
Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Patrick Tronnier via dev-security-policy]

On Thursday, April 20, 2017 at 9:30:31 AM UTC-4, wangs...@gmail.com wrote:
> 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. Please find the new 
> version at:
> CP V1.6: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860016
> CPS V4.5: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860018
> EV CP V1.4: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860019
> EV CPS V1.5: https://bug1128392.bmoattachments.org/attachment.cgi?id=8860020
> 
> We wish these documents will be fully discussed by the public, so that 
> Mozilla can make decision on this root inclusion application.
> All comments and suggestions are welcomed. Thanks.

I updated your bug with a review of your initial BR-self-assessment using the 
previously posted CPS's. The review is attachment 
https://bugzilla.mozilla.org/attachment.cgi?id=8860075. 

Would you please complete a second BR-self-assessment against the just posted 
CPS's and CP's and use my attachment as your starting point? Thank you.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年3月30日星期四 UTC+8下午10:34:00，Patrick Tronnier写道：
> On Sunday, March 26, 2017 at 11:48:43 PM UTC-4, wangs...@gmail.com wrote:
> > We compiled an analysis document on our CP/CPS’s Compliance with the BRs 
> > for everyone to review and comment. You can find the document at the 
> > following address of the 
> > BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8851230
> >  
> > Your suggestions will be much appreciated.
> 
> As part of the suggestion process it would be useful to expand on the tables 
> you listed in section 2 "Compliance Analysis". Would you be able to attach an 
> editable MS Word version?

We uploaded an editable version of the comparison document in MS Word format 
for the convenience of review and comments. You can find the document at the 
following address of the 
BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8853351
The contents of the Word document are the same with that of the PDF document, 
except for the correction of a mistake in the Table of Contents part of the PDF 
document. All suggestions and comments are welcomed. Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

在 2017年3月30日星期四 UTC+8下午10:34:00，Patrick Tronnier写道：
> On Sunday, March 26, 2017 at 11:48:43 PM UTC-4, wangs...@gmail.com wrote:
> > We compiled an analysis document on our CP/CPS’s Compliance with the BRs 
> > for everyone to review and comment. You can find the document at the 
> > following address of the 
> > BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8851230
> >  
> > Your suggestions will be much appreciated.
> 
> As part of the suggestion process it would be useful to expand on the tables 
> you listed in section 2 "Compliance Analysis". Would you be able to attach an 
> editable MS Word version?

We uploaded an editable version of the comparison document in MS Word format 
for the convenience of review and comments. You can find the document at the 
following address of the 
BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8853351
The contents of the Word document are the same with that of the PDF document, 
except for the correction of a mistake in the Table of Contents part of the PDF 
document. All suggestions and comments are welcomed. Thanks. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Patrick Tronnier via dev-security-policy]

On Sunday, March 26, 2017 at 11:48:43 PM UTC-4, wangs...@gmail.com wrote:
> We compiled an analysis document on our CP/CPS’s Compliance with the BRs for 
> everyone to review and comment. You can find the document at the following 
> address of the 
> BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8851230
>  
> Your suggestions will be much appreciated.

As part of the suggestion process it would be useful to expand on the tables 
you listed in section 2 "Compliance Analysis". Would you be able to attach an 
editable MS Word version?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Kathleen Wilson via dev-security-policy]

All,

This request is to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on 
the Websites trust bit, and enabled EV treatment.

In order to help get this discussion moving again, I asked GDCA to provide a 
side-by-side comparison of the latest version of the BRs with their CP/CPS 
documents.

They provided this BR-self-assessment here:
https://bugzilla.mozilla.org/attachment.cgi?id=8851230

The documents that were evaluated in this self-assessment are available on the 
CA's website. 

All of these documents contain both the original text in Chinese, and the 
translation into English.

Document Repository: 
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/

GDCA CP v1.5:
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA1.5GDCA-CP-V1.5/

GDCA CPS v4.4:
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA4.4GDCA-CPS-V4.4/

GDCA EV CP v1.3:
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA-EV1.3GDCA-EV-CP-V1.3/

GDCA EV CPS v1.4:
https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/CPCPS-GDCA-EV1.4GDCA-EV-CPS-V1.4/

I will greatly appreciate it if you all would take another look at this CA's 
request, review their self-assessment, and respond in this discussion to let me 
know if you believe that this CA has addressed all of your questions or 
concerns. 

Also, I would like to make this BR-self-assessment a standard part of Mozilla's 
root inclusion/change process. I will draft what that will look like, and start 
a separate discussion about it. 

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206--- via dev-security-policy]

We compiled an analysis document on our CP/CPS’s Compliance with the BRs for 
everyone to review and comment. You can find the document at the following 
address of the 
BUG:https://bug1128392.bmoattachments.org/attachment.cgi?id=8851230
 
Your suggestions will be much appreciated.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

The answer is yes. That’s why we need to apply for root inclusion. We also 
upload the latest version of CP/CPS here for your convenience. 
1. GDCA CP Ver 1.5 
https://bug1128392.bmoattachments.org/attachment.cgi?id=8813656
2. GDCA CPS Ver 4.4 
https://bug1128392.bmoattachments.org/attachment.cgi?id=8813658 
3. GDCA EV CP Ver 1.3 
https://bug1128392.bmoattachments.org/attachment.cgi?id=8813659
4. GDCA EV CPS Ver 1.4 
https://bug1128392.bmoattachments.org/attachment.cgi?id=8813660
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Gervase Markham]

On 22/11/16 15:47, wangsn1...@gmail.com wrote:
> into effect on Dec 1st, 2016. Here are the names of the files and
> their URL: 1. GDCA CP Ver 1.5 
> https://www.gdca.com.cn/export/sites/default/customer_service/.content/attachments/1.GDCA-CP-V1.5.pdf

A bilingual edition seems like an excellent idea :-)

I would note that the site from which you are serving these documents
uses a security certificate which is not currently trusted by Firefox.
Is that because it uses the new root you are applying to include?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

Thanks for all suggestions upon our CP/CPS and base on the development of our 
business, we have revised and prepared a bilingual edition of CP/CPS, which 
have been submitted to our auditor to check the consistency of major contents 
between Chinese version and English version, and officially published after 
internal review and approval in accordance with control regulations disclosed 
in CP. We did the translation work to the best of our knowledge. However, there 
may still be some improper translation because of time limit. Please kindly 
point out if there is any error, propose any question or offer suggestions for 
us to make further improvements in the next revision. We will devote our best 
effort to do it better!
The following files have been published in the official website of GDCA and 
will come into effect on Dec 1st, 2016. Here are the names of the files and 
their URL: 
1. GDCA CP Ver 1.5
https://www.gdca.com.cn/export/sites/default/customer_service/.content/attachments/1.GDCA-CP-V1.5.pdf
2. GDCA CPS Ver 4.4
https://www.gdca.com.cn/export/sites/default/customer_service/.content/attachments/1.GDCA-CPS-V4.4.pdf
3. GDCA EV CP Ver 1.3
https://www.gdca.com.cn/export/sites/default/customer_service/.content/attachments/1.GDCA-EVCP-V1.3.pdf
4. GDCA EV CPS Ver 1.4
https://www.gdca.com.cn/export/sites/default/customer_service/.content/attachments/1.GDCA-EVCPS-V1.4.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Gervase Markham]

On 18/11/16 11:38, wangsn1...@gmail.com wrote:
> GDCA takes security and governance seriously and we have a strict
> control for Chinese version CP/CPS, all the contents are disclosed.
> And The Chinese versions for CPS 4.1, 4.2, 4.3 are published on the
> official website, so we cannot cover-up anything. There are three
> reasons for the confusion in the English versions: 


Thank you for this information. I accept these explanations. Once the
fully-translated documents are available, I think the inclusion request
should continue.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年11月17日星期四 UTC+8下午7:20:05，Gervase Markham写道：
> Hi Kathleen,
> 
> On 15/11/16 00:51, Kathleen Wilson wrote:
> > There were some recommendations to deny this request due to the
> > versioning problems between the English documents and the original
> > documents.
> > 
> > Do you all still feel that is the proper answer to this root
> > inclusion request?
> 
> As I understand it, what happened was as follows:
> 
> * As part of their application, GDCA provided both Chinese and English
> versions of their CP/CPS, posted to m.d.s.policy on 3rd August:
> 
> Chinese CP: http://www.gdca.com.cn/cp/cp
> Chinese CPS: http://www.gdca.com.cn/cps/cps
> English CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> English CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> 
> (I don't immediately have URLs for their EV CP and CPS in Chinese or
> English from the original submission.)
> 
> * On 26th September, it was pointed out by Andrew Whalley that the
> English versions had lower version numbers than the Chinese versions
> (CP: 1.2 vs. 1.4; CPS: 4.1 vs 4.3)
> 
> * On 27th September, one day later, GDCA provided new English versions
> with the same version numbers as the Chinese versions:
> 
> CP V1.4: https://bugzilla.mozilla.org/attachment.cgi?id=8795090
> CPS V4.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795091
> EV CP V1.2: https://bugzilla.mozilla.org/attachment.cgi?id=8795093
> EV CPS V1.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795094
> 
> * It was pointed out by more than one person that there were significant
> content differences between the English and Chinese versions which were
> both labelled with the same version number
> 
> * GDCA said this was due to a "poor CP/CPS English translation" and on
> 28th October, provided new English versions (again) with the same
> version numbers
> 
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805545
> EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> EV CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805547
> 
> What Mozilla has to decide is whether this was incompetence or malice.
> Were GDCA trying to hide something? If so, their inclusion must be in
> doubt. If they were not trying to hide something and just need a lesson
> in version control, that is not necessarily something which
> disqualifies, although it does give one concern.
> 
> Looking at the CPS (using pdf2txt and diff), the differences between the
> originally-submitted v4.1 and the first 4.3 are very minor. One
> intermediate certificate changes name throughout, as does the name of
> GDCA. Three certs in an appendix are replaced with others. Other than
> that, the only changes are these:
> 
> https://gist.github.com/gerv/fc311785c49c7fdfdfba78d6d5ad4aa9
> 
> This seems like an odd change, removing specificity about how domain
> validation is done. This change was _added_ to the Chinese version of
> 3.2.5 between 4.1 and 4.2, and moved to section 3.2.7 in version 4.3. So
> how does going from 4.1 to 4.3 in the English version lead to it being
> removed?

On 2015.8.20, we uploaded the English Version 4.1 to bugzilla for the first 
time, and section 3.2.5 was translated from the Chinese version CPS 4.1. 
On 2015.10.22, Kathleen pointed out that section 3.2.5 " Domain name 
recognition and identification" could not meet the requirements of Mozilla. 
Therefore, on 2015.11.17, we submitted a new English Version 4.1 with modified 
section 3.2.5. 
However, due to the negligence of our employee, the submitted English Version 
4.3 on 2016.9.26 was revised based on the English version 4.1 of 2015.8.20. 
In the submitted English Version 4.3 on 2016.10.28, this mistake was found and 
solved.
For the question that "the Chinese version of 3.2.5 between 4.1 and 4.2 moved 
to section 3.2.7 in version 4.3", this is because we added section 3.2.5 " 
Authentication of SSL Server Identity" and section 3.2.6 " Authentication of 
CodeSigning Identity". Accordingly, the former 3.2.5 changes into 3.2.7.

> 
> The differences between the first 4.3 and the second one are much more
> extensive.
> 
> So I'd say the questions for GDCA are these:
> 
> * When you were asked to produce a version of your CPS matching Chinese
> version 4.3, within a day you came up with:
> https://bugzilla.mozilla.org/attachment.cgi?id=8795091
> That clearly doesn't match Chinese version 4.3, and yet it has "version
> 4.3" written in it. And the effective date marked within it is one month
> _earlier_ than the effective date of the Chinese 4.3. How did this
> happen? How did such a document come to exist with such a version number
> and date attached, when it is so massively different from the real 4.3,
> and so similar to the previous 4.1?
> 
> * You say you only translated the relevant bits rather than all of it,
> which is why there is a discrepancy, but the diff between 4.1 and the
> first version of 4.3 reveals no additions, 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Jakob Bohm]

On 17/11/2016 12:19, Gervase Markham wrote:

Hi Kathleen,

On 15/11/16 00:51, Kathleen Wilson wrote:

There were some recommendations to deny this request due to the
versioning problems between the English documents and the original
documents.

Do you all still feel that is the proper answer to this root
inclusion request?


As I understand it, what happened was as follows:

* As part of their application, GDCA provided both Chinese and English
versions of their CP/CPS, posted to m.d.s.policy on 3rd August:

Chinese CP: http://www.gdca.com.cn/cp/cp
Chinese CPS: http://www.gdca.com.cn/cps/cps
English CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
English CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749

(I don't immediately have URLs for their EV CP and CPS in Chinese or
English from the original submission.)

* On 26th September, it was pointed out by Andrew Whalley that the
English versions had lower version numbers than the Chinese versions
(CP: 1.2 vs. 1.4; CPS: 4.1 vs 4.3)

* On 27th September, one day later, GDCA provided new English versions
with the same version numbers as the Chinese versions:

CP V1.4: https://bugzilla.mozilla.org/attachment.cgi?id=8795090
CPS V4.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795091
EV CP V1.2: https://bugzilla.mozilla.org/attachment.cgi?id=8795093
EV CPS V1.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795094

* It was pointed out by more than one person that there were significant
content differences between the English and Chinese versions which were
both labelled with the same version number

* GDCA said this was due to a "poor CP/CPS English translation" and on
28th October, provided new English versions (again) with the same
version numbers

CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805545
EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
EV CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805547

What Mozilla has to decide is whether this was incompetence or malice.
Were GDCA trying to hide something? If so, their inclusion must be in
doubt. If they were not trying to hide something and just need a lesson
in version control, that is not necessarily something which
disqualifies, although it does give one concern.



I believe their overall excuses can be rephrased as:

1. The previous Mozilla policy guidance only requiring a partial
  translation.  Mozilla has since fixed that, though I can't find
  the posting that mentioned that document fix.

2. Sloppy translation work, including sloppyness when trying to quickly
  update the 4.1 translation to match the 4.3 Chinese documents.

3. At the time, the English translations were not version controlled,
  only the Chinese versions.  They have promised to change this for the
  next version, where they will even request an outside audit of the
  translation.

4. That consistent pair of a new CP/CPS in Chinese and English has not
  been posted yet, indicating that Mozilla will just have to put the
  inclusion request on hold until then.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年11月16日星期三 UTC+8下午3:59:12，wangs...@gmail.com写道：
> 在 2016年11月16日星期三 UTC+8上午1:11:05，Han Yuwei写道：
> > 在 2016年11月15日星期二 UTC+8下午7:03:07，wangs...@gmail.com写道：
> > > 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> > > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com 
> > > > wrote:
> > > > > We have uploaded the lastest translantion of CP/CPS.
> > > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > > > > EV CPS: 
> > > > > https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > > > > 
> > > > > Because of our English level, there maybe some mistakes. If you have 
> > > > > any questions, please contact us.
> > > > 
> > > > 
> > > > Thanks to all of you who have reviewed and commented on this request 
> > > > from Guangdong Certificate Authority (GDCA) is to include the "GDCA 
> > > > TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> > > > enabled EV treatment. 
> > > > 
> > > > There were some recommendations to deny this request due to the 
> > > > versioning problems between the English documents and the original 
> > > > documents. 
> > > > 
> > > > Do you all still feel that is the proper answer to this root inclusion 
> > > > request?
> > > > 
> > > > Or should we proceed with reviewing these new English translations of 
> > > > the documents, and make our decision based on the new versions?
> > > > 
> > > > Thanks,
> > > > Kathleen
> > > 
> > > Because we misunderstand that we only need to provide the related 
> > > chapters of CP/CPS in English, and non-related sections are not required. 
> > > We are terribly sorry that we misinterpreted your requirement and upload 
> > > an inconsistent CP/CPS in English. Someone inferred that we don’t utilize 
> > > a version control for CP/CPS. In fact, we do have a strict control for 
> > > master version CP/CPS (see section 1.5 in CP/CPS).
> > > We understand that it is our responsibility to provide accurate English 
> > > versions and ensure consistency and synchronicity between Chinese and 
> > > English versions. Hence, we have decided to strictly implement version 
> > > controlling of English version CP/CPS according to section 1.5 in CP/CPS. 
> > > The auditor is reviewing our complete CP/CPS in English and the new 
> > > version will be published as soon as possible.
> > > We will keep open mind to process any further issues.
> > 
> > Ok, this is what I want to see. Maybe next time you could be more specific 
> > about the problems and not just like "translation problem". If you can't 
> > describe your opinion exactly in English you can use Chinese and let others 
> > translate. But it's best for you to hire a professional translator.
> > Since CPS is very critical, I hope you understand what I said before. I 
> > don't want another Wosign incident happen again.
> 
> Thanks for proposing many good questions, which push us to utilize version 
> controls for English CP/CPS. We are looking forward to your further comments 
> and suggestions. 
> We plan to attend the CA/B Forum meetings in February next year, If it is 
> lucky to meet you there, we are looking forward to have your consultation and 
> suggestions.

So are you going to conduct a complete investgation about this? I am still 
waiting for it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Gervase Markham]

Hi Kathleen,

On 15/11/16 00:51, Kathleen Wilson wrote:
> There were some recommendations to deny this request due to the
> versioning problems between the English documents and the original
> documents.
> 
> Do you all still feel that is the proper answer to this root
> inclusion request?

As I understand it, what happened was as follows:

* As part of their application, GDCA provided both Chinese and English
versions of their CP/CPS, posted to m.d.s.policy on 3rd August:

Chinese CP: http://www.gdca.com.cn/cp/cp
Chinese CPS: http://www.gdca.com.cn/cps/cps
English CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
English CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749

(I don't immediately have URLs for their EV CP and CPS in Chinese or
English from the original submission.)

* On 26th September, it was pointed out by Andrew Whalley that the
English versions had lower version numbers than the Chinese versions
(CP: 1.2 vs. 1.4; CPS: 4.1 vs 4.3)

* On 27th September, one day later, GDCA provided new English versions
with the same version numbers as the Chinese versions:

CP V1.4: https://bugzilla.mozilla.org/attachment.cgi?id=8795090
CPS V4.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795091
EV CP V1.2: https://bugzilla.mozilla.org/attachment.cgi?id=8795093
EV CPS V1.3: https://bugzilla.mozilla.org/attachment.cgi?id=8795094

* It was pointed out by more than one person that there were significant
content differences between the English and Chinese versions which were
both labelled with the same version number

* GDCA said this was due to a "poor CP/CPS English translation" and on
28th October, provided new English versions (again) with the same
version numbers

CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805545
EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
EV CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8805547

What Mozilla has to decide is whether this was incompetence or malice.
Were GDCA trying to hide something? If so, their inclusion must be in
doubt. If they were not trying to hide something and just need a lesson
in version control, that is not necessarily something which
disqualifies, although it does give one concern.

Looking at the CPS (using pdf2txt and diff), the differences between the
originally-submitted v4.1 and the first 4.3 are very minor. One
intermediate certificate changes name throughout, as does the name of
GDCA. Three certs in an appendix are replaced with others. Other than
that, the only changes are these:

https://gist.github.com/gerv/fc311785c49c7fdfdfba78d6d5ad4aa9

This seems like an odd change, removing specificity about how domain
validation is done. This change was _added_ to the Chinese version of
3.2.5 between 4.1 and 4.2, and moved to section 3.2.7 in version 4.3. So
how does going from 4.1 to 4.3 in the English version lead to it being
removed?

The differences between the first 4.3 and the second one are much more
extensive.

So I'd say the questions for GDCA are these:

* When you were asked to produce a version of your CPS matching Chinese
version 4.3, within a day you came up with:
https://bugzilla.mozilla.org/attachment.cgi?id=8795091
That clearly doesn't match Chinese version 4.3, and yet it has "version
4.3" written in it. And the effective date marked within it is one month
_earlier_ than the effective date of the Chinese 4.3. How did this
happen? How did such a document come to exist with such a version number
and date attached, when it is so massively different from the real 4.3,
and so similar to the previous 4.1?

* You say you only translated the relevant bits rather than all of it,
which is why there is a discrepancy, but the diff between 4.1 and the
first version of 4.3 reveals no additions, only one deletion. How does
that fit?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年11月16日星期三 UTC+8上午1:11:05，Han Yuwei写道：
> 在 2016年11月15日星期二 UTC+8下午7:03:07，wangs...@gmail.com写道：
> > 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> > > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:
> > > > We have uploaded the lastest translantion of CP/CPS.
> > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > > > 
> > > > Because of our English level, there maybe some mistakes. If you have 
> > > > any questions, please contact us.
> > > 
> > > 
> > > Thanks to all of you who have reviewed and commented on this request from 
> > > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH 
> > > R5 ROOT" certificate, turn on the Websites trust bit, and enabled EV 
> > > treatment. 
> > > 
> > > There were some recommendations to deny this request due to the 
> > > versioning problems between the English documents and the original 
> > > documents. 
> > > 
> > > Do you all still feel that is the proper answer to this root inclusion 
> > > request?
> > > 
> > > Or should we proceed with reviewing these new English translations of the 
> > > documents, and make our decision based on the new versions?
> > > 
> > > Thanks,
> > > Kathleen
> > 
> > Because we misunderstand that we only need to provide the related chapters 
> > of CP/CPS in English, and non-related sections are not required. We are 
> > terribly sorry that we misinterpreted your requirement and upload an 
> > inconsistent CP/CPS in English. Someone inferred that we don’t utilize a 
> > version control for CP/CPS. In fact, we do have a strict control for master 
> > version CP/CPS (see section 1.5 in CP/CPS).
> > We understand that it is our responsibility to provide accurate English 
> > versions and ensure consistency and synchronicity between Chinese and 
> > English versions. Hence, we have decided to strictly implement version 
> > controlling of English version CP/CPS according to section 1.5 in CP/CPS. 
> > The auditor is reviewing our complete CP/CPS in English and the new version 
> > will be published as soon as possible.
> > We will keep open mind to process any further issues.
> 
> Ok, this is what I want to see. Maybe next time you could be more specific 
> about the problems and not just like "translation problem". If you can't 
> describe your opinion exactly in English you can use Chinese and let others 
> translate. But it's best for you to hire a professional translator.
> Since CPS is very critical, I hope you understand what I said before. I don't 
> want another Wosign incident happen again.

Thanks for proposing many good questions, which push us to utilize version 
controls for English CP/CPS. We are looking forward to your further comments 
and suggestions. 
We plan to attend the CA/B Forum meetings in February next year, If it is lucky 
to meet you there, we are looking forward to have your consultation and 
suggestions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年11月16日星期三 UTC+8上午6:35:22，Kathleen Wilson写道：
> On Tuesday, November 15, 2016 at 10:41:28 AM UTC-8, Peter Bowen wrote:
> > I think Mozilla needs to update its guidance to CAs.  The information
> > checklist directions
> > (https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices)
> > says "If the CP/CPS documents are not in English, then the portions of
> > those documents pertaining to verification of the certificate
> > subscriber must be translated into English."
> 
> Done...
> https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
> now says: "If the CP/CPS documents are not in English, then the CP/CPS 
> documents that are relevant to the root inclusion request must be translated 
> into English."
> 
> Also updated
> https://wiki.mozilla.org/CA:Recommended_Practices#Publicly_Available_CP_and_CPS
> to add the second sentence to the 3rd bullet point:
> "The CP/CPS should be available in an English version. The non-English 
> version may be authoritative (as that's the working language of the CA) but 
> the CA is responsible for ensuring that the translation is not materially 
> different from the authoritative version of the document."
> 
> Note that this is also on our list of things to add directly to the policy:
> https://github.com/mozilla/pkipolicy/issues/6
> 
> 
> > 
> > This makes me think that the expectation is not that the full doc is
> > in English and that a one-time translation is acceptable.
> > 
> > I don't think we should hold it against GDCA that Mozilla's
> > requirements have apparently changed.
> 
> Fair enough.
> 
> Before asking folks to review the documents again...
> 
> Would a representative of GDCA please confirm that the following translations 
> are correct to the best of their knowledge? 
> Please also confirm that these documents match the corresponding version of 
> the document in Chinese (no material differences).
> 
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> 
> 
> Thanks,
> Kathleen

Now we have a good understanding of the latest policy of Mozilla. We have sent 
a complete CP/CPS in English to our auditor. They will review the documents to 
ensure it is consistent with the Chinese version and meets the latest 
requirements. The CP/CPS in English will be revised and approved in light of 
Section 1.5 in CP/CPS after receiving feedback from the auditor, and will be 
published in our website before November 22nd 23:59 (Beijing time). We hope 
everyone can have a discussion based on the newly published versions.
Thanks to all for your understanding and suggestions to GDCA. We will keep an 
open mind to process any further issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Kathleen Wilson]

On Tuesday, November 15, 2016 at 10:41:28 AM UTC-8, Peter Bowen wrote:
> I think Mozilla needs to update its guidance to CAs.  The information
> checklist directions
> (https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices)
> says "If the CP/CPS documents are not in English, then the portions of
> those documents pertaining to verification of the certificate
> subscriber must be translated into English."

Done...
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
now says: "If the CP/CPS documents are not in English, then the CP/CPS 
documents that are relevant to the root inclusion request must be translated 
into English."

Also updated
https://wiki.mozilla.org/CA:Recommended_Practices#Publicly_Available_CP_and_CPS
to add the second sentence to the 3rd bullet point:
"The CP/CPS should be available in an English version. The non-English version 
may be authoritative (as that's the working language of the CA) but the CA is 
responsible for ensuring that the translation is not materially different from 
the authoritative version of the document."

Note that this is also on our list of things to add directly to the policy:
https://github.com/mozilla/pkipolicy/issues/6


> 
> This makes me think that the expectation is not that the full doc is
> in English and that a one-time translation is acceptable.
> 
> I don't think we should hold it against GDCA that Mozilla's
> requirements have apparently changed.

Fair enough.

Before asking folks to review the documents again...

Would a representative of GDCA please confirm that the following translations 
are correct to the best of their knowledge? 
Please also confirm that these documents match the corresponding version of the 
document in Chinese (no material differences).

CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547


Thanks,
Kathleen




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Peter Bowen]

On Tue, Nov 15, 2016 at 3:02 AM,   wrote:
>
> Because we misunderstand that we only need to provide the related chapters of 
> CP/CPS in English, and non-related sections are not required. We are terribly 
> sorry that we misinterpreted your requirement and upload an inconsistent 
> CP/CPS in English. Someone inferred that we don’t utilize a version control 
> for CP/CPS. In fact, we do have a strict control for master version CP/CPS 
> (see section 1.5 in CP/CPS).
> We understand that it is our responsibility to provide accurate English 
> versions and ensure consistency and synchronicity between Chinese and English 
> versions. Hence, we have decided to strictly implement version controlling of 
> English version CP/CPS according to section 1.5 in CP/CPS. The auditor is 
> reviewing our complete CP/CPS in English and the new version will be 
> published as soon as possible.
> We will keep open mind to process any further issues.

I think Mozilla needs to update its guidance to CAs.  The information
checklist directions
(https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices)
says "If the CP/CPS documents are not in English, then the portions of
those documents pertaining to verification of the certificate
subscriber must be translated into English."

This makes me think that the expectation is not that the full doc is
in English and that a one-time translation is acceptable.

I don't think we should hold it against GDCA that Mozilla's
requirements have apparently changed.

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Kevin]

On Tuesday, November 15, 2016 at 6:03:07 AM UTC-5, wangs...@gmail.com wrote:
> 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:
> > > We have uploaded the lastest translantion of CP/CPS.
> > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > > 
> > > Because of our English level, there maybe some mistakes. If you have any 
> > > questions, please contact us.
> > 
> > 
> > Thanks to all of you who have reviewed and commented on this request from 
> > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 
> > ROOT" certificate, turn on the Websites trust bit, and enabled EV 
> > treatment. 
> > 
> > There were some recommendations to deny this request due to the versioning 
> > problems between the English documents and the original documents. 
> > 
> > Do you all still feel that is the proper answer to this root inclusion 
> > request?
> > 
> > Or should we proceed with reviewing these new English translations of the 
> > documents, and make our decision based on the new versions?
> > 
> > Thanks,
> > Kathleen
> 
> Because we misunderstand that we only need to provide the related chapters of 
> CP/CPS in English, and non-related sections are not required. We are terribly 
> sorry that we misinterpreted your requirement and upload an inconsistent 
> CP/CPS in English. Someone inferred that we don’t utilize a version control 
> for CP/CPS. In fact, we do have a strict control for master version CP/CPS 
> (see section 1.5 in CP/CPS).
> We understand that it is our responsibility to provide accurate English 
> versions and ensure consistency and synchronicity between Chinese and English 
> versions. Hence, we have decided to strictly implement version controlling of 
> English version CP/CPS according to section 1.5 in CP/CPS. The auditor is 
> reviewing our complete CP/CPS in English and the new version will be 
> published as soon as possible.
> We will keep open mind to process any further issues.

Read through this discussion thread, here is my take on this. GDCA has taken 
action to address the discrepancies between English and Chinese CP/CPS and put 
in place stricter version control. So we should look at the updated version, if 
that's deemed good I don't see other reason to reject.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Jakob Bohm]

On 15/11/2016 18:10, Han Yuwei wrote:

在 2016年11月15日星期二 UTC+8下午7:03:07，wangs...@gmail.com写道：

在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：

On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:

We have uploaded the lastest translantion of CP/CPS.
CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547

Because of our English level, there maybe some mistakes. If you have any 
questions, please contact us.



Thanks to all of you who have reviewed and commented on this request from Guangdong 
Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 ROOT" 
certificate, turn on the Websites trust bit, and enabled EV treatment.

There were some recommendations to deny this request due to the versioning 
problems between the English documents and the original documents.

Do you all still feel that is the proper answer to this root inclusion request?

Or should we proceed with reviewing these new English translations of the 
documents, and make our decision based on the new versions?

Thanks,
Kathleen


Because we misunderstand that we only need to provide the related chapters of 
CP/CPS in English, and non-related sections are not required. We are terribly 
sorry that we misinterpreted your requirement and upload an inconsistent CP/CPS 
in English. Someone inferred that we don’t utilize a version control for 
CP/CPS. In fact, we do have a strict control for master version CP/CPS (see 
section 1.5 in CP/CPS).
We understand that it is our responsibility to provide accurate English 
versions and ensure consistency and synchronicity between Chinese and English 
versions. Hence, we have decided to strictly implement version controlling of 
English version CP/CPS according to section 1.5 in CP/CPS. The auditor is 
reviewing our complete CP/CPS in English and the new version will be published 
as soon as possible.
We will keep open mind to process any further issues.


Ok, this is what I want to see. Maybe next time you could be more specific about the 
problems and not just like "translation problem". If you can't describe your 
opinion exactly in English you can use Chinese and let others translate. But it's best 
for you to hire a professional translator.
Since CPS is very critical, I hope you understand what I said before. I don't 
want another Wosign incident happen again.



Note that he said most of these things already in his post dated Thu,
27 Oct 2016 03:21:53 -0700 (PDT)

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年11月15日星期二 UTC+8下午7:03:07，wangs...@gmail.com写道：
> 在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> > On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:
> > > We have uploaded the lastest translantion of CP/CPS.
> > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > > 
> > > Because of our English level, there maybe some mistakes. If you have any 
> > > questions, please contact us.
> > 
> > 
> > Thanks to all of you who have reviewed and commented on this request from 
> > Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 
> > ROOT" certificate, turn on the Websites trust bit, and enabled EV 
> > treatment. 
> > 
> > There were some recommendations to deny this request due to the versioning 
> > problems between the English documents and the original documents. 
> > 
> > Do you all still feel that is the proper answer to this root inclusion 
> > request?
> > 
> > Or should we proceed with reviewing these new English translations of the 
> > documents, and make our decision based on the new versions?
> > 
> > Thanks,
> > Kathleen
> 
> Because we misunderstand that we only need to provide the related chapters of 
> CP/CPS in English, and non-related sections are not required. We are terribly 
> sorry that we misinterpreted your requirement and upload an inconsistent 
> CP/CPS in English. Someone inferred that we don’t utilize a version control 
> for CP/CPS. In fact, we do have a strict control for master version CP/CPS 
> (see section 1.5 in CP/CPS).
> We understand that it is our responsibility to provide accurate English 
> versions and ensure consistency and synchronicity between Chinese and English 
> versions. Hence, we have decided to strictly implement version controlling of 
> English version CP/CPS according to section 1.5 in CP/CPS. The auditor is 
> reviewing our complete CP/CPS in English and the new version will be 
> published as soon as possible.
> We will keep open mind to process any further issues.

Ok, this is what I want to see. Maybe next time you could be more specific 
about the problems and not just like "translation problem". If you can't 
describe your opinion exactly in English you can use Chinese and let others 
translate. But it's best for you to hire a professional translator.
Since CPS is very critical, I hope you understand what I said before. I don't 
want another Wosign incident happen again.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[谭晓生]

Agree with Gerv & Tony,
More patience should be given if they want to improve.

And I don’t think “I posted on the solidot (Chinese Slashdot) about this. The 
majority comments want the application rejected. “is enough to be the reason to 
reject the request.
For many Chinese companies, they do need to learn how to work with global 
community, they might even have language issues to use English as the working 
language, for Guang Dong CA case, I can see they are willing to work with the 
community and we should encourage them to do more.

Thanks，
Xiaosheng Tan



在 2016/11/15 下午9:08，“dev-security-policy 代表 
Tony” 写入:

在 2016年11月15日星期二 UTC+8下午5:53:19，Gervase Markham写道：
> On 15/11/16 08:39, Percy wrote:
> > I posted on the solidot (Chinese Slashdot) about this. The majority
> > comments want the application rejected.
> > 
https://translate.google.com/translate?hl=en=zh-CN=en=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368
> 
> That fact, by itself, is not useful information. It would help if you
> were to summarise why people feel the application should be rejected,
> and how those reasons map to Mozilla's policy requirements.
> 
> Gerv

Agreed with Gerv, the reasons for rejection/improvements should be listed 
very clearly in this case, considering the positive actions taken by CA as it 
will publish the full new version of CP/CPS in English and implement version 
control on EN CP/CPS.  

It's common that Chinese company only maintains one master file policy 
which is in Chinese based on experience.  But if they can do one version 
control on EN policies, even from now on, it should be deemed as a good 
improvement.  

Also,  guidance for coaching the CA to enhance the internal controls for 
the future is needed.  More patience shall be given.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Tony]

在 2016年11月15日星期二 UTC+8下午5:53:19，Gervase Markham写道：
> On 15/11/16 08:39, Percy wrote:
> > I posted on the solidot (Chinese Slashdot) about this. The majority
> > comments want the application rejected.
> > https://translate.google.com/translate?hl=en=zh-CN=en=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368
> 
> That fact, by itself, is not useful information. It would help if you
> were to summarise why people feel the application should be rejected,
> and how those reasons map to Mozilla's policy requirements.
> 
> Gerv

Agreed with Gerv, the reasons for rejection/improvements should be listed very 
clearly in this case, considering the positive actions taken by CA as it will 
publish the full new version of CP/CPS in English and implement version control 
on EN CP/CPS.  

It's common that Chinese company only maintains one master file policy which is 
in Chinese based on experience.  But if they can do one version control on EN 
policies, even from now on, it should be deemed as a good improvement.  

Also,  guidance for coaching the CA to enhance the internal controls for the 
future is needed.  More patience shall be given.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Percy]

On Wednesday, August 3, 2016 at 2:45:23 PM UTC-7, Kathleen Wilson wrote:
> This request from Guangdong Certificate Authority (GDCA) is to include the 
> "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> enabled EV treatment.
> 
> GDCA is a nationally recognized CA that operates under China’s Electronic 
> Signature Law. GDCA’s customers are business corporations registered in 
> mainland China, government agencies of China, individuals or mainland China 
> citizens, servers of business corporations which have been registered in 
> mainland China, and software developers.
> 
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> 
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
> 
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> 
> Noteworthy points:
> 
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> 
> * The primary documents are provided in Chinese.
> 
> CA Document Repository: 
> https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/
> http://www.gdca.com.cn/cp/cp
> http://www.gdca.com.cn/cps/cps
> http://www.gdca.com.cn/cp/ev-cp
> http://www.gdca.com.cn/cps/ev-cps
> 
> Translations into English:
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> 
> * CA Hierarchy: This root certificate has internally-operated subordinate CAs
> - 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)
> 
> * This request is to turn on the Websites trust bit.
> 
> CPS section 3.2.5: For domain verification, GDCA needs to check the written 
> materials which can be used to prove the ownership of corresponding domain 
> provided by applicant. Meanwhile, GDCA should ensure the ownership of domain 
> from corresponding registrant or other authoritative third-party databases. 
> During the verification, GDCA needs to perform the following procedures:
> 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.
> If necessary, GDCA also need to take other review measures to confirm the 
> ownership of the domain name. Applicant can't refuse to the request for 
> providing appropriate assistance.
> 
> 
> * EV Policy OID: 1.2.156.112559.1.1.6.1
> 
> * Test Website: https://ev-ssl-test-1.95105813.cn/
> 
> * CRL URLs:
> 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
> 
> * OCSP URL:
> http://www.gdca.com.cn/TrustAUTH/ocsp
> 
> * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP 
> according to the WebTrust criteria.
> WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf
> 
> * Potentially Problematic Practices: None Noted
> (http://wiki.mozilla.org/CA:Problematic_Practices)
> 
> This begins the discussion of the request from Guangdong Certificate 
> Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on 
> the Websites trust bit, and enabled EV treatment. At the conclusion of this 
> discussion I will provide a summary of issues noted and action items. If 
> there are outstanding issues, then an additional discussion may be needed as 
> follow-up. If there are no outstanding issues, then I will recommend approval 
> of this request in the bug.
> 
> Kathleen

I posted on the solidot (Chinese Slashdot) about this. The majority comments 
want the application rejected.  
https://translate.google.com/translate?hl=en=zh-CN=en=http%3A%2F%2Fwww.solidot.org%2Fstory%3Fsid%3D50368
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年11月15日星期二 UTC+8上午8:51:25，Kathleen Wilson写道：
> On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:
> > We have uploaded the lastest translantion of CP/CPS.
> > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> > EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> > EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> > 
> > Because of our English level, there maybe some mistakes. If you have any 
> > questions, please contact us.
> 
> 
> Thanks to all of you who have reviewed and commented on this request from 
> Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 
> ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. 
> 
> There were some recommendations to deny this request due to the versioning 
> problems between the English documents and the original documents. 
> 
> Do you all still feel that is the proper answer to this root inclusion 
> request?
> 
> Or should we proceed with reviewing these new English translations of the 
> documents, and make our decision based on the new versions?
> 
> Thanks,
> Kathleen

If GDCA insists on translation problem, I can't trust it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Kathleen Wilson]

On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote:
> We have uploaded the lastest translantion of CP/CPS.
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
> CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
> EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> 
> Because of our English level, there maybe some mistakes. If you have any 
> questions, please contact us.


Thanks to all of you who have reviewed and commented on this request from 
Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 
ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. 

There were some recommendations to deny this request due to the versioning 
problems between the English documents and the original documents. 

Do you all still feel that is the proper answer to this root inclusion request?

Or should we proceed with reviewing these new English translations of the 
documents, and make our decision based on the new versions?

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Peter Bowen]

On Sun, Oct 30, 2016 at 11:34 PM,   wrote:
> wangs...@gmail.com於 2016年10月31日星期一 UTC+8下午2時22分05秒寫道：
>> 在 2016年10月28日星期五 UTC+8上午8:19:43，Percy写道：
>> > "When facing any requirements of laws and regulations or any demands for 
>> > undergoing legal
>> > process of court and other agencies, GDCA must provide confidential 
>> > information in this CP"
>> >
>> > Can GDCA specify what other agencies are included? In China, many requests 
>> > are relayed simply through a phone call without any paper trail or IM and 
>> > the service providers must meet the demand very quickly. Are such informal 
>> > procedures honored by GDCA?
>>
>> Agencies include: public security organization, procuratorate, court.
>> The agency is required to meet the following conditions:
>> 1. provide paper official letters
>> 2. submit application to GDCA on site
>> 3. site applicants must be law enforcement officers
>
> I figured out that you are selling certificates on Taobao.com instead of 
> handling application on your own website, does it matches your CP and CPS and 
> if it conflicts with Mozilla's policy?

There is nothing in Mozilla's policy that forbids CAs using resellers
and/or selling via 3rd party sites.  Many, if not most, CAs in the
Mozilla program have reseller programs.

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年10月30日星期日 UTC+8下午9:13:32，Gervase Markham写道：
> On 29/10/16 22:23, Han Yuwei wrote:
> > Is SM2 acceptable in publicy-trusted CAs? I don't think so.
> 
> No; the BRs list the permitted algorithms, and SM2 is not one of them.
> 
> > Maybe Gerv could explain more about this. And I am wondering what can
> > CA do if government requirement conflicts with Mozilla's policy?
> 
> It may well be a government requirement that Chinese CAs be able to
> issue SM2 certificates. However, no-one has yet demonstrated that it's a
> requirement that they do so from specific roots (i.e. the ones trusted
> by the major root stores).
> 
> Gerv
We know that SM2 is not a permitted algorithm in BRs list. And we only apply 
for GDCA TrustAUTH R5 ROOT to be included this time.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年10月28日星期五 UTC+8上午8:19:43，Percy写道：
> "When facing any requirements of laws and regulations or any demands for 
> undergoing legal
> process of court and other agencies, GDCA must provide confidential 
> information in this CP"
> 
> Can GDCA specify what other agencies are included? In China, many requests 
> are relayed simply through a phone call without any paper trail or IM and the 
> service providers must meet the demand very quickly. Are such informal 
> procedures honored by GDCA?

Agencies include: public security organization, procuratorate, court.
The agency is required to meet the following conditions:
1. provide paper official letters 
2. submit application to GDCA on site
3. site applicants must be law enforcement officers
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Gervase Markham]

On 29/10/16 22:23, Han Yuwei wrote:
> Is SM2 acceptable in publicy-trusted CAs? I don't think so.

No; the BRs list the permitted algorithms, and SM2 is not one of them.

> Maybe Gerv could explain more about this. And I am wondering what can
> CA do if government requirement conflicts with Mozilla's policy?

It may well be a government requirement that Chinese CAs be able to
issue SM2 certificates. However, no-one has yet demonstrated that it's a
requirement that they do so from specific roots (i.e. the ones trusted
by the major root stores).

Gerv



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月30日星期日 UTC+8上午5:30:23，Peter Bowen写道：
> > On Oct 29, 2016, at 2:23 PM, Han Yuwei  wrote:
> > 
> > 在 2016年10月28日星期五 UTC+8下午9:23:01，wangs...@gmail.com写道：
> >> We are not intended to cover-up anything since we had disclosed every 
> >> change to the Chinese version CP/CPS at once after the auditor reviewed.
> >> The “ROOTCA(SM2)” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 
> >> ROOT Certificate” CA in $1.1.3 of CPS ver4.1. The “Guangdong Certificate 
> >> Authority(SM2) ” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 CA 
> >> Certificate” CA in $1.1.3 of CPS ver4.1. We change these names in diagram 
> >> in this revision in order to show the actual CN of these certificates. 
> >> Furthermore, we only issue SM2 subscriber certificates from the subCA of 
> >> “ROOTCA(SM2)” CA.
> > 
> > Is SM2 acceptable in publicy-trusted CAs? I don't think so.
> > 
> > Maybe Gerv could explain more about this. And I am wondering what can CA do 
> > if government requirement conflicts with Mozilla's policy?
> 
> It is acceptable to have a single CPS that covers CAs that are included the 
> Mozilla list of trust anchors and CAs that are not trusted by Mozilla.  The 
> CPS should make clear which portions apply to which CA when there are 
> portions that do not apply to all CAs.
> 
> In this case, I would expect that the ROOTCA(SM2) CA is not proposed for 
> inclusion in Mozilla.  As long as the CPS does not allow issuance of SM2 
> signed certificates or certificates with SM2 subject public keys from the CAs 
> proposed for inclusion in Mozilla, I do not seen an issue.
> 
> Thanks,
> Peter

I don't see anything about this in Chinese CPS or Bugzilla. Could someone point 
out or GDCA explain about this?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月28日星期五 UTC+8上午6:43:30，Han Yuwei写道：
> 在 2016年10月27日星期四 UTC+8下午6:22:03，wangs...@gmail.com写道：
> > 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > > I think these are both good points and my recommendation is that Mozilla 
> > > deny GDCA's request for inclusion.
> > > 
> > > 
> > > We should not have to explain something as basic as document versioning 
> > > and version control. If GDCA can not demonstrate sufficient controls over 
> > > their documentation, there is no reason for the Internet community to 
> > > place confidence in any of the other versioning systems that are needed 
> > > to operate a CA.
> > > 
> > > 
> > > Question: Are auditors expected to review translations of CP or CPS docs 
> > > and verify consistency between them?
> > > 
> > >   
> > >
> > > 
> > >   
> > >   
> > >
> > >   
> > >   
> > >               
> > >   
> > > From: Jakob Bohm
> > > Sent: Saturday, October 22, 2016 9:07 AM
> > > To: mozilla-dev-s...@lists.mozilla.org
> > > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion 
> > > request
> > > 
> > > 
> > > On 21/10/2016 10:38, Han Yuwei wrote:
> > > >
> > > > I think this is a major mistake and a investgation should be conducted 
> > > > for CPS is a critical document about CA. This is not just a translation 
> > > > problem but a version control problem. Sometimes it can be lying.
> > > >
> > > 
> > > Let me try to be more specific:
> > > 
> > > When publishing a document called CPS version 4.3 the document with
> > > that number must have the same contents in all languages that have a
> > > document with that name and version number.
> > > 
> > > When making any change, even just correcting a mistyped URL, the
> > > document becomes a new document version which should have a new and
> > > larger number than the number of the document before the change.
> > > Thus when a published document refers to a broken URL on your own
> > > server, it is often cheaper to repair the server than to publish a new
> > > document version.  Some of the oldest CAs have been proudly
> > > publishing their various important files at multiple URLs corresponding
> > > to whatever was mentioned in old CP and CPS documents etc., only
> > > shutting down those URLs years after the corresponding CA roots were
> > > shut down.
> > > 
> > > There can also be a "draft" document which has no number and which
> > > contains the changes that will go into the next numbered edition.  Such
> > > a "draft" would have no official significance, as it has not been
> > > officially "published".  For a well-planned change, the final "draft"
> > > would be translated and checked into the relevant languages (e.g.
> > > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > > Special Administrative Regions old writing system, English), before
> > > simultaneously publishing the matching documents with the same number
> > > on the same day.
> > > 
> > > There are infinitely many version numbers in the universe to choose
> > > from.  There are also computer programs that can generate new version
> > > numbers every time a draft is changed, but computers cannot decide when
> > > a version is good enough in all languages to make an official
> > > publication, and the computer generated version numbers are often
> > > impractical for publication because they count all the small steps that
> > > were not published.
> > > 
> > > 
> > > Enjoy
> > > 
> > > Jakob
> > > -- 
> > > Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> > > Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> > > This public discussion message is non-binding and may contain errors.
&

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Peter Bowen]

> On Oct 29, 2016, at 2:23 PM, Han Yuwei  wrote:
> 
> 在 2016年10月28日星期五 UTC+8下午9:23:01，wangs...@gmail.com写道：
>> We are not intended to cover-up anything since we had disclosed every change 
>> to the Chinese version CP/CPS at once after the auditor reviewed.
>> The “ROOTCA(SM2)” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 ROOT 
>> Certificate” CA in $1.1.3 of CPS ver4.1. The “Guangdong Certificate 
>> Authority(SM2) ” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 CA 
>> Certificate” CA in $1.1.3 of CPS ver4.1. We change these names in diagram in 
>> this revision in order to show the actual CN of these certificates. 
>> Furthermore, we only issue SM2 subscriber certificates from the subCA of 
>> “ROOTCA(SM2)” CA.
> 
> Is SM2 acceptable in publicy-trusted CAs? I don't think so.
> 
> Maybe Gerv could explain more about this. And I am wondering what can CA do 
> if government requirement conflicts with Mozilla's policy?

It is acceptable to have a single CPS that covers CAs that are included the 
Mozilla list of trust anchors and CAs that are not trusted by Mozilla.  The CPS 
should make clear which portions apply to which CA when there are portions that 
do not apply to all CAs.

In this case, I would expect that the ROOTCA(SM2) CA is not proposed for 
inclusion in Mozilla.  As long as the CPS does not allow issuance of SM2 signed 
certificates or certificates with SM2 subject public keys from the CAs proposed 
for inclusion in Mozilla, I do not seen an issue.

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月28日星期五 UTC+8下午9:23:01，wangs...@gmail.com写道：
> We are not intended to cover-up anything since we had disclosed every change 
> to the Chinese version CP/CPS at once after the auditor reviewed.
> The “ROOTCA(SM2)” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 ROOT 
> Certificate” CA in $1.1.3 of CPS ver4.1. The “Guangdong Certificate 
> Authority(SM2) ” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 CA 
> Certificate” CA in $1.1.3 of CPS ver4.1. We change these names in diagram in 
> this revision in order to show the actual CN of these certificates. 
> Furthermore, we only issue SM2 subscriber certificates from the subCA of 
> “ROOTCA(SM2)” CA.

Is SM2 acceptable in publicy-trusted CAs? I don't think so.

Maybe Gerv could explain more about this. And I am wondering what can CA do if 
government requirement conflicts with Mozilla's policy?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Gervase Markham]

On 27/10/16 23:43, Han Yuwei wrote:
> Since Mozilla's working language is English (Not sure about this),

That is true.

> it's your responsibility to provide an accurate translation of CPS.

That is also true. However, we don't require that the English version be
the master copy.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

We have uploaded the lastest translantion of CP/CPS.
CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543
CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545
EV CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547

Because of our English level, there maybe some mistakes. If you have any 
questions, please contact us.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

We are not intended to cover-up anything since we had disclosed every change to 
the Chinese version CP/CPS at once after the auditor reviewed.
The “ROOTCA(SM2)” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 ROOT 
Certificate” CA in $1.1.3 of CPS ver4.1. The “Guangdong Certificate 
Authority(SM2) ” CA in $1.1.3 of CPS ver4.3 is equivalent to the “SM2 CA 
Certificate” CA in $1.1.3 of CPS ver4.1. We change these names in diagram in 
this revision in order to show the actual CN of these certificates. 
Furthermore, we only issue SM2 subscriber certificates from the subCA of 
“ROOTCA(SM2)” CA.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Percy]

"When facing any requirements of laws and regulations or any demands for 
undergoing legal
process of court and other agencies, GDCA must provide confidential information 
in this CP"

Can GDCA specify what other agencies are included? In China, many requests are 
relayed simply through a phone call without any paper trail or IM and the 
service providers must meet the demand very quickly. Are such informal 
procedures honored by GDCA?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月27日星期四 UTC+8下午6:22:03，wangs...@gmail.com写道：
> 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > I think these are both good points and my recommendation is that Mozilla 
> > deny GDCA's request for inclusion.
> > 
> > 
> > We should not have to explain something as basic as document versioning and 
> > version control. If GDCA can not demonstrate sufficient controls over their 
> > documentation, there is no reason for the Internet community to place 
> > confidence in any of the other versioning systems that are needed to 
> > operate a CA.
> > 
> > 
> > Question: Are auditors expected to review translations of CP or CPS docs 
> > and verify consistency between them?
> > 
> > 
> >  
> > 
> > 
> > 
> >
> > 
> > 
> >       
> >   
> > From: Jakob Bohm
> > Sent: Saturday, October 22, 2016 9:07 AM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request
> > 
> > 
> > On 21/10/2016 10:38, Han Yuwei wrote:
> > >
> > > I think this is a major mistake and a investgation should be conducted 
> > > for CPS is a critical document about CA. This is not just a translation 
> > > problem but a version control problem. Sometimes it can be lying.
> > >
> > 
> > Let me try to be more specific:
> > 
> > When publishing a document called CPS version 4.3 the document with
> > that number must have the same contents in all languages that have a
> > document with that name and version number.
> > 
> > When making any change, even just correcting a mistyped URL, the
> > document becomes a new document version which should have a new and
> > larger number than the number of the document before the change.
> > Thus when a published document refers to a broken URL on your own
> > server, it is often cheaper to repair the server than to publish a new
> > document version.  Some of the oldest CAs have been proudly
> > publishing their various important files at multiple URLs corresponding
> > to whatever was mentioned in old CP and CPS documents etc., only
> > shutting down those URLs years after the corresponding CA roots were
> > shut down.
> > 
> > There can also be a "draft" document which has no number and which
> > contains the changes that will go into the next numbered edition.  Such
> > a "draft" would have no official significance, as it has not been
> > officially "published".  For a well-planned change, the final "draft"
> > would be translated and checked into the relevant languages (e.g.
> > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > Special Administrative Regions old writing system, English), before
> > simultaneously publishing the matching documents with the same number
> > on the same day.
> > 
> > There are infinitely many version numbers in the universe to choose
> > from.  There are also computer programs that can generate new version
> > numbers every time a draft is changed, but computers cannot decide when
> > a version is good enough in all languages to make an official
> > publication, and the computer generated version numbers are often
> > impractical for publication because they count all the small steps that
> > were not published.
> > 
> > 
> > Enjoy
> > 
> > Jakob
> > -- 
> > Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> > Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> > This public discussion message is non-binding and may contain errors.
> > WiseMo - Remote Service Management for PCs, Phones and Embedded
> > ___
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> 
> We’d like to explain a few points.
> 
> 1. We have already implemented version control on Chinese version CP/CPS, the 
> revision and release of CP/CPS are reviewed and approve

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月28日星期五 UTC+8上午2:12:32，Percy写道：
> On Thursday, October 27, 2016 at 3:22:03 AM UTC-7, wangs...@gmail.com wrote:
> > 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > > I think these are both good points and my recommendation is that Mozilla 
> > > deny GDCA's request for inclusion.
> > > 
> > > 
> > > We should not have to explain something as basic as document versioning 
> > > and version control. If GDCA can not demonstrate sufficient controls over 
> > > their documentation, there is no reason for the Internet community to 
> > > place confidence in any of the other versioning systems that are needed 
> > > to operate a CA.
> > > 
> > > 
> > > Question: Are auditors expected to review translations of CP or CPS docs 
> > > and verify consistency between them?
> > > 
> > >   
> > >
> > > 
> > >   
> > >   
> > >
> > >   
> > >   
> > >               
> > >   
> > > From: Jakob Bohm
> > > Sent: Saturday, October 22, 2016 9:07 AM
> > > To: mozilla-dev-s...@lists.mozilla.org
> > > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion 
> > > request
> > > 
> > > 
> > > On 21/10/2016 10:38, Han Yuwei wrote:
> > > >
> > > > I think this is a major mistake and a investgation should be conducted 
> > > > for CPS is a critical document about CA. This is not just a translation 
> > > > problem but a version control problem. Sometimes it can be lying.
> > > >
> > > 
> > > Let me try to be more specific:
> > > 
> > > When publishing a document called CPS version 4.3 the document with
> > > that number must have the same contents in all languages that have a
> > > document with that name and version number.
> > > 
> > > When making any change, even just correcting a mistyped URL, the
> > > document becomes a new document version which should have a new and
> > > larger number than the number of the document before the change.
> > > Thus when a published document refers to a broken URL on your own
> > > server, it is often cheaper to repair the server than to publish a new
> > > document version.  Some of the oldest CAs have been proudly
> > > publishing their various important files at multiple URLs corresponding
> > > to whatever was mentioned in old CP and CPS documents etc., only
> > > shutting down those URLs years after the corresponding CA roots were
> > > shut down.
> > > 
> > > There can also be a "draft" document which has no number and which
> > > contains the changes that will go into the next numbered edition.  Such
> > > a "draft" would have no official significance, as it has not been
> > > officially "published".  For a well-planned change, the final "draft"
> > > would be translated and checked into the relevant languages (e.g.
> > > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > > Special Administrative Regions old writing system, English), before
> > > simultaneously publishing the matching documents with the same number
> > > on the same day.
> > > 
> > > There are infinitely many version numbers in the universe to choose
> > > from.  There are also computer programs that can generate new version
> > > numbers every time a draft is changed, but computers cannot decide when
> > > a version is good enough in all languages to make an official
> > > publication, and the computer generated version numbers are often
> > > impractical for publication because they count all the small steps that
> > > were not published.
> > > 
> > > 
> > > Enjoy
> > > 
> > > Jakob
> > > -- 
> > > Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> > > Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> > > This public discussion message is non-binding a

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Percy]

On Thursday, October 27, 2016 at 3:22:03 AM UTC-7, wangs...@gmail.com wrote:
> 在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> > I think these are both good points and my recommendation is that Mozilla 
> > deny GDCA's request for inclusion.
> > 
> > 
> > We should not have to explain something as basic as document versioning and 
> > version control. If GDCA can not demonstrate sufficient controls over their 
> > documentation, there is no reason for the Internet community to place 
> > confidence in any of the other versioning systems that are needed to 
> > operate a CA.
> > 
> > 
> > Question: Are auditors expected to review translations of CP or CPS docs 
> > and verify consistency between them?
> > 
> > 
> >  
> > 
> > 
> > 
> >
> > 
> > 
> >       
> >   
> > From: Jakob Bohm
> > Sent: Saturday, October 22, 2016 9:07 AM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request
> > 
> > 
> > On 21/10/2016 10:38, Han Yuwei wrote:
> > >
> > > I think this is a major mistake and a investgation should be conducted 
> > > for CPS is a critical document about CA. This is not just a translation 
> > > problem but a version control problem. Sometimes it can be lying.
> > >
> > 
> > Let me try to be more specific:
> > 
> > When publishing a document called CPS version 4.3 the document with
> > that number must have the same contents in all languages that have a
> > document with that name and version number.
> > 
> > When making any change, even just correcting a mistyped URL, the
> > document becomes a new document version which should have a new and
> > larger number than the number of the document before the change.
> > Thus when a published document refers to a broken URL on your own
> > server, it is often cheaper to repair the server than to publish a new
> > document version.  Some of the oldest CAs have been proudly
> > publishing their various important files at multiple URLs corresponding
> > to whatever was mentioned in old CP and CPS documents etc., only
> > shutting down those URLs years after the corresponding CA roots were
> > shut down.
> > 
> > There can also be a "draft" document which has no number and which
> > contains the changes that will go into the next numbered edition.  Such
> > a "draft" would have no official significance, as it has not been
> > officially "published".  For a well-planned change, the final "draft"
> > would be translated and checked into the relevant languages (e.g.
> > Chinese with mainland writing system, Chinese with Hong Kong and Macao
> > Special Administrative Regions old writing system, English), before
> > simultaneously publishing the matching documents with the same number
> > on the same day.
> > 
> > There are infinitely many version numbers in the universe to choose
> > from.  There are also computer programs that can generate new version
> > numbers every time a draft is changed, but computers cannot decide when
> > a version is good enough in all languages to make an official
> > publication, and the computer generated version numbers are often
> > impractical for publication because they count all the small steps that
> > were not published.
> > 
> > 
> > Enjoy
> > 
> > Jakob
> > -- 
> > Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> > Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> > This public discussion message is non-binding and may contain errors.
> > WiseMo - Remote Service Management for PCs, Phones and Embedded
> > ___
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> 
> We’d like to explain a few points.
> 
> 1. We have already implemented version control on Chinese version CP/CPS, the 
> revision and release of CP/CPS

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年10月27日星期四 UTC+8上午8:09:06，Peter Kurrasch写道：
> I think these are both good points and my recommendation is that Mozilla deny 
> GDCA's request for inclusion.
> 
> 
> We should not have to explain something as basic as document versioning and 
> version control. If GDCA can not demonstrate sufficient controls over their 
> documentation, there is no reason for the Internet community to place 
> confidence in any of the other versioning systems that are needed to operate 
> a CA.
> 
> 
> Question: Are auditors expected to review translations of CP or CPS docs and 
> verify consistency between them?
> 
>   
>
> 
>   
>   
>
>   
>   
>   
>   
> From: Jakob Bohm
> Sent: Saturday, October 22, 2016 9:07 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Guang Dong Certificate Authority (GDCA) root inclusion request
> 
> 
> On 21/10/2016 10:38, Han Yuwei wrote:
> >
> > I think this is a major mistake and a investgation should be conducted for 
> > CPS is a critical document about CA. This is not just a translation problem 
> > but a version control problem. Sometimes it can be lying.
> >
> 
> Let me try to be more specific:
> 
> When publishing a document called CPS version 4.3 the document with
> that number must have the same contents in all languages that have a
> document with that name and version number.
> 
> When making any change, even just correcting a mistyped URL, the
> document becomes a new document version which should have a new and
> larger number than the number of the document before the change.
> Thus when a published document refers to a broken URL on your own
> server, it is often cheaper to repair the server than to publish a new
> document version.  Some of the oldest CAs have been proudly
> publishing their various important files at multiple URLs corresponding
> to whatever was mentioned in old CP and CPS documents etc., only
> shutting down those URLs years after the corresponding CA roots were
> shut down.
> 
> There can also be a "draft" document which has no number and which
> contains the changes that will go into the next numbered edition.  Such
> a "draft" would have no official significance, as it has not been
> officially "published".  For a well-planned change, the final "draft"
> would be translated and checked into the relevant languages (e.g.
> Chinese with mainland writing system, Chinese with Hong Kong and Macao
> Special Administrative Regions old writing system, English), before
> simultaneously publishing the matching documents with the same number
> on the same day.
> 
> There are infinitely many version numbers in the universe to choose
> from.  There are also computer programs that can generate new version
> numbers every time a draft is changed, but computers cannot decide when
> a version is good enough in all languages to make an official
> publication, and the computer generated version numbers are often
> impractical for publication because they count all the small steps that
> were not published.
> 
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

We’d like to explain a few points.

1. We have already implemented version control on Chinese version CP/CPS, the 
revision and release of CP/CPS are reviewed and approved by the security policy 
committee (see section 1.5 in CP/CPS). The Chinese version CP/CPS is also 
reviewed by our auditor.

2. The Chinese version CP/CPS is the formal documents we published in our 
Website. In the initial phase of "Bug 1128392", we have summited the Chinese 
version CP/CPS to Mozilla, and Mozilla release a basic review list in file 
"1128392-CAInformation.pdf" which contains instructions for us to summit some 
chapters of the CP/CPS in English version. We are n

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Peter Kurrasch]

  I think these are both good points and my recommendation is that Mozilla deny GDCA's request for inclusion.We should not have to explain something as basic as document versioning and version control. If GDCA can not demonstrate sufficient controls over their documentation, there is no reason for the Internet community to place confidence in any of the other versioning systems that are needed to operate a CA.Question: Are auditors expected to review translations of CP or CPS docs and verify consistency between them?From: Jakob BohmSent: Saturday, October 22, 2016 9:07 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Guang Dong Certificate Authority (GDCA) root inclusion requestOn 21/10/2016 10:38, Han Yuwei wrote:>> I think this is a major mistake and a investgation should be conducted for CPS is a critical document about CA. This is not just a translation problem but a version control problem. Sometimes it can be lying.>Let me try to be more specific:When publishing a document called CPS version 4.3 the document withthat number must have the same contents in all languages that have adocument with that name and version number.When making any change, even just correcting a mistyped URL, thedocument becomes a new document version which should have a new andlarger number than the number of the document before the change.Thus when a published document refers to a broken URL on your ownserver, it is often cheaper to repair the server than to publish a newdocument version.  Some of the oldest CAs have been proudlypublishing their various important files at multiple URLs correspondingto whatever was mentioned in old CP and CPS documents etc., onlyshutting down those URLs years after the corresponding CA roots wereshut down.There can also be a "draft" document which has no number and whichcontains the changes that will go into the next numbered edition.  Sucha "draft" would have no official significance, as it has not beenofficially "published".  For a well-planned change, the final "draft"would be translated and checked into the relevant languages (e.g.Chinese with mainland writing system, Chinese with Hong Kong and MacaoSpecial Administrative Regions old writing system, English), beforesimultaneously publishing the matching documents with the same numberon the same day.There are infinitely many version numbers in the universe to choosefrom.  There are also computer programs that can generate new versionnumbers every time a draft is changed, but computers cannot decide whena version is good enough in all languages to make an officialpublication, and the computer generated version numbers are oftenimpractical for publication because they count all the small steps thatwere not published.EnjoyJakob-- Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.comTransformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10This public discussion message is non-binding and may contain errors.WiseMo - Remote Service Management for PCs, Phones and Embedded___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

We have already implemented version control on Chinese version CP/CPS, which 
include version number (e.g. V4.3) and effective date (e.g. 2016-08-01). The 
revision and release of CP/CPS are reviewed and approved by the security policy 
committee  (see section 1.5 in CP/CPS).

Meanwhile, we are a Chinese company and all of our customers are domestic. We 
only released the Chinese version of the CP/CPS, the English CP/CPS is only the 
translation version for reference. 

It’s our negligence that we did a poor CP/CPS English translation for the 
latest version (CN version V4.3). After discussion and your suggestion, we will 
make sure that the same version of CP/CPS will be consistent in all languages 
in the future.

We've reconfirmed that the English version of CP/CPS uploaded by us in 
2016-09-27 cannot be consistent with the latest Chinese version. We’ll upload 
the latest English version CP/CPS to you in this week. 

Sorry for the inconvenience.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Jakob Bohm]

On 21/10/2016 10:38, Han Yuwei wrote:


I think this is a major mistake and a investgation should be conducted for CPS 
is a critical document about CA. This is not just a translation problem but a 
version control problem. Sometimes it can be lying.



Let me try to be more specific:

When publishing a document called CPS version 4.3 the document with
that number must have the same contents in all languages that have a
document with that name and version number.

When making any change, even just correcting a mistyped URL, the
document becomes a new document version which should have a new and
larger number than the number of the document before the change.
Thus when a published document refers to a broken URL on your own
server, it is often cheaper to repair the server than to publish a new
document version.  Some of the oldest CAs have been proudly
publishing their various important files at multiple URLs corresponding
to whatever was mentioned in old CP and CPS documents etc., only
shutting down those URLs years after the corresponding CA roots were
shut down.

There can also be a "draft" document which has no number and which
contains the changes that will go into the next numbered edition.  Such
a "draft" would have no official significance, as it has not been
officially "published".  For a well-planned change, the final "draft"
would be translated and checked into the relevant languages (e.g.
Chinese with mainland writing system, Chinese with Hong Kong and Macao
Special Administrative Regions old writing system, English), before
simultaneously publishing the matching documents with the same number
on the same day.

There are infinitely many version numbers in the universe to choose
from.  There are also computer programs that can generate new version
numbers every time a draft is changed, but computers cannot decide when
a version is good enough in all languages to make an official
publication, and the computer generated version numbers are often
impractical for publication because they count all the small steps that
were not published.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月21日星期五 UTC+8下午12:15:07，wangs...@gmail.com写道：
> 在 2016年10月21日星期五 UTC+8上午12:15:00，Han Yuwei写道：
> > 在 2016年10月20日星期四 UTC+8上午5:27:42，Andrew R. Whalley写道：
> > > Hello,
> > > 
> > > Thank you for the links.  I note, however, that there's at least one
> > > difference between the native language version and the English 
> > > translation:
> > > 
> > > http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
> > > CAA.
> > > https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 
> > > 4.3
> > > in English has no such section.
> > > 
> > > The fact there's a discrepancy is rather worrying.  Could you please check
> > > and let me know if there are any other substantive differences between the
> > > Chinese and English versions?
> > > 
> > > Cheers,
> > > 
> > > Andrew
> > > 
> > > On Mon, Sep 26, 2016 at 7:17 PM,  wrote:
> > > 
> > > > 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > > > > Hello,
> > > > >
> > > > > I have completed a read through of the English translations of the CP
> > > > > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if 
> > > > > there
> > > > > were any more recent translations?  It looks like the local language
> > > > > versions are 1.4 and 4.3 respectively.
> > > > >
> > > > > Many thanks,
> > > > >
> > > > > Andrew
> > > > >
> > > > > On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson 
> > > > wrote:
> > > > >
> > > > > > This request from Guangdong Certificate Authority (GDCA) is to 
> > > > > > include
> > > > the
> > > > > > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust 
> > > > > > bit,
> > > > and
> > > > > > enabled EV treatment.
> > > > > >
> > > > > > GDCA is a nationally recognized CA that operates under China’s
> > > > Electronic
> > > > > > Signature Law. GDCA’s customers are business corporations 
> > > > > > registered in
> > > > > > mainland China, government agencies of China, individuals or 
> > > > > > mainland
> > > > China
> > > > > > citizens, servers of business corporations which have been 
> > > > > > registered
> > > > in
> > > > > > mainland China, and software developers.
> > > > > >
> > > > > > The request is documented in the following bug:
> > > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > > > > >
> > > > > > And in the pending certificates list:
> > > > > > https://wiki.mozilla.org/CA:PendingCAs
> > > > > >
> > > > > > Summary of Information Gathered and Verified:
> > > > > > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > > > > >
> > > > > > Noteworthy points:
> > > > > >
> > > > > > * Root Certificate Download URL:
> > > > > > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > > > > > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > > > > >
> > > > > > * The primary documents are provided in Chinese.
> > > > > >
> > > > > > CA Document Repository: https://www.gdca.com.cn/
> > > > > > customer_service/knowledge_universe/cp_cps/
> > > > > > http://www.gdca.com.cn/cp/cp
> > > > > > http://www.gdca.com.cn/cps/cps
> > > > > > http://www.gdca.com.cn/cp/ev-cp
> > > > > > http://www.gdca.com.cn/cps/ev-cps
> > > > > >
> > > > > > Translations into English:
> > > > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > > > > > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > > > > >
> > > > > > * CA Hierarchy: This root certificate has internally-operated
> > > > subordinate
> > > > > > CAs
> > > > > > - 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)
> > > > > >
> > > > > > * This request is to turn on the Websites trust bit.
> > > > > >
> > > > > > CPS section 3.2.5: For domain verification, GDCA needs to check the
> > > > > > written materials which can be used to prove the ownership of
> > > > corresponding
> > > > > > domain provided by applicant. Meanwhile, GDCA should ensure the
> > > > ownership
> > > > > > of domain from corresponding registrant or other authoritative
> > > > third-party
> > > > > > databases. During the verification, GDCA needs to perform the 
> > > > > > following
> > > > > > procedures:
> > > > > > 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 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年10月21日星期五 UTC+8上午12:15:00，Han Yuwei写道：
> 在 2016年10月20日星期四 UTC+8上午5:27:42，Andrew R. Whalley写道：
> > Hello,
> > 
> > Thank you for the links.  I note, however, that there's at least one
> > difference between the native language version and the English translation:
> > 
> > http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
> > CAA.
> > https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 4.3
> > in English has no such section.
> > 
> > The fact there's a discrepancy is rather worrying.  Could you please check
> > and let me know if there are any other substantive differences between the
> > Chinese and English versions?
> > 
> > Cheers,
> > 
> > Andrew
> > 
> > On Mon, Sep 26, 2016 at 7:17 PM,  wrote:
> > 
> > > 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > > > Hello,
> > > >
> > > > I have completed a read through of the English translations of the CP
> > > > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if 
> > > > there
> > > > were any more recent translations?  It looks like the local language
> > > > versions are 1.4 and 4.3 respectively.
> > > >
> > > > Many thanks,
> > > >
> > > > Andrew
> > > >
> > > > On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson 
> > > wrote:
> > > >
> > > > > This request from Guangdong Certificate Authority (GDCA) is to include
> > > the
> > > > > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit,
> > > and
> > > > > enabled EV treatment.
> > > > >
> > > > > GDCA is a nationally recognized CA that operates under China’s
> > > Electronic
> > > > > Signature Law. GDCA’s customers are business corporations registered 
> > > > > in
> > > > > mainland China, government agencies of China, individuals or mainland
> > > China
> > > > > citizens, servers of business corporations which have been registered
> > > in
> > > > > mainland China, and software developers.
> > > > >
> > > > > The request is documented in the following bug:
> > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > > > >
> > > > > And in the pending certificates list:
> > > > > https://wiki.mozilla.org/CA:PendingCAs
> > > > >
> > > > > Summary of Information Gathered and Verified:
> > > > > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > > > >
> > > > > Noteworthy points:
> > > > >
> > > > > * Root Certificate Download URL:
> > > > > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > > > > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > > > >
> > > > > * The primary documents are provided in Chinese.
> > > > >
> > > > > CA Document Repository: https://www.gdca.com.cn/
> > > > > customer_service/knowledge_universe/cp_cps/
> > > > > http://www.gdca.com.cn/cp/cp
> > > > > http://www.gdca.com.cn/cps/cps
> > > > > http://www.gdca.com.cn/cp/ev-cp
> > > > > http://www.gdca.com.cn/cps/ev-cps
> > > > >
> > > > > Translations into English:
> > > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > > > > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > > > >
> > > > > * CA Hierarchy: This root certificate has internally-operated
> > > subordinate
> > > > > CAs
> > > > > - 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)
> > > > >
> > > > > * This request is to turn on the Websites trust bit.
> > > > >
> > > > > CPS section 3.2.5: For domain verification, GDCA needs to check the
> > > > > written materials which can be used to prove the ownership of
> > > corresponding
> > > > > domain provided by applicant. Meanwhile, GDCA should ensure the
> > > ownership
> > > > > of domain from corresponding registrant or other authoritative
> > > third-party
> > > > > databases. During the verification, GDCA needs to perform the 
> > > > > following
> > > > > procedures:
> > > > > 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.
> > > > > If necessary, GDCA also need to take 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年10月21日星期五 UTC+8上午10:52:42，Percy写道：
> Thanks for bringing the discrepancy into our attention. 
> Even the cover page of the English and Chinese version of CPS are dated 
> differently.
> 
> English
> Global Digital Cybersecurity Authority
> CO., LTD.
> Certification Practice Statement (CPS) Version: V4.3
> Effective Date: July 1, 2016
> 
> Chinese  
> 数安时代科技股份有限公司
> 电子认证业务规则
> 版本:V4.3 
> 生效日期:2016 年 8 月 1 日 (Effective date: August 1st, 2016)
> 
> 
> In 1.1.3 3) the Chinese version shows ROOTCA(SM2) - Guangdong Certificate 
> Authority(SM2) while the English version shows ROOTCA(SM2) - SM2 CA 
> Certificate. 
> 
> I saw 4) included in the English version about 1.1.3 5) 数安时代 R5 根 CA and 6) 
> GDCA TrustAUTH E5 ROOT 
> are completely missing in the English version. 
> 
> I translated the 6) section below.
> 
> GDCA TrustAUTH E5 ROOT uses ECC, with the root key length 384-bit . It has 7 
> sub-CA. 1)GDCA TrustAUTH E4 EV SSL CA with key length 256-bit and it signs 
> 256-bit EV SSL servers. 2)GDCA TrustAUTH E4 OV SSL CA and it signs 256-bit OV 
> SSL certs for servers. (3)GDCA TrustAUTH E4 IV SSL CA，256-bit key and signs 
> 256-bit IV SSL certs for servers; (4)GDCA TrustAUTH E4 DV SSL CA，256-bit key 
> and signs 256-bit DV SSL certs for servers; (5)GDCA TrustAUTH E4 CodeSigning 
> CA 256-bit key，and signs 256-bit code certs;(6)GDCA TrustAUTH E4 Generic CA, 
> 256-bit，signed 256-bit certs for organizations  and individuals ;(7)GDCA 
> TrustAUTH E4 Primer CA， 256-bit，and signs 256-bit personal certs.
> 
> GDCA TrustAUTH E5 ROOT will expire on 2040 Dec  31st. 
> GDCA TrustAUTH E4 EV SSL CA will expire on  2030 Dec 31st. From 2027 Jan,1st 
> ，no new certs will be signed with it.
> …( More expiration date stuff)
> 
> GDCA TrustAUTH R5 ROOT 、数安时代 R5 根 CA 证书、GDCA 
> TrustAUTH E5 ROOT’s intermediate certs: GDCA conforms to the latest version 
> of CA/Browser Forum Baseline Requirements for the Issuance and Management of 
> Publicly Trusted SSL Digital Certificates published at www.cabforum.org. In 
> the event that a discrepancy arises between interpretations of this document 
> and Baseline Requirement, the Baseline Requirement shall govern. 
> 
> This is as far as I read. There are probably many more inconsistencies as 
> Yuwei pointed out. 
> I suggest Mozilla ask a staff who know Chinese to fully translate the Chinese 
> CPS yourself and compare with the provided English CPS
Hi Andrew,Yuwei and Percy:
Thank you for your reviews of our CP and CPS. 
The effective date of Chinese version was August 1 while the English 
version was July 1. We are now translating a new English version which match 
the Chinese version. We will upload a new English version next week when the 
translation is all complete.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Percy]

Thanks for bringing the discrepancy into our attention. 
Even the cover page of the English and Chinese version of CPS are dated 
differently.

English
Global Digital Cybersecurity Authority
CO., LTD.
Certification Practice Statement (CPS) Version: V4.3
Effective Date: July 1, 2016

Chinese  
数安时代科技股份有限公司
电子认证业务规则
版本:V4.3 
生效日期:2016 年 8 月 1 日 (Effective date: August 1st, 2016)


In 1.1.3 3) the Chinese version shows ROOTCA(SM2) - Guangdong Certificate 
Authority(SM2) while the English version shows ROOTCA(SM2) - SM2 CA 
Certificate. 

I saw 4) included in the English version about 1.1.3 5) 数安时代 R5 根 CA and 6) 
GDCA TrustAUTH E5 ROOT 
are completely missing in the English version. 

I translated the 6) section below.

GDCA TrustAUTH E5 ROOT uses ECC, with the root key length 384-bit . It has 7 
sub-CA. 1)GDCA TrustAUTH E4 EV SSL CA with key length 256-bit and it signs 
256-bit EV SSL servers. 2)GDCA TrustAUTH E4 OV SSL CA and it signs 256-bit OV 
SSL certs for servers. (3)GDCA TrustAUTH E4 IV SSL CA，256-bit key and signs 
256-bit IV SSL certs for servers; (4)GDCA TrustAUTH E4 DV SSL CA，256-bit key 
and signs 256-bit DV SSL certs for servers; (5)GDCA TrustAUTH E4 CodeSigning CA 
256-bit key，and signs 256-bit code certs;(6)GDCA TrustAUTH E4 Generic CA, 
256-bit，signed 256-bit certs for organizations  and individuals ;(7)GDCA 
TrustAUTH E4 Primer CA， 256-bit，and signs 256-bit personal certs.

GDCA TrustAUTH E5 ROOT will expire on 2040 Dec  31st. 
GDCA TrustAUTH E4 EV SSL CA will expire on  2030 Dec 31st. From 2027 Jan,1st 
，no new certs will be signed with it.
…( More expiration date stuff)

GDCA TrustAUTH R5 ROOT 、数安时代 R5 根 CA 证书、GDCA 
TrustAUTH E5 ROOT’s intermediate certs: GDCA conforms to the latest version of 
CA/Browser Forum Baseline Requirements for the Issuance and Management of 
Publicly Trusted SSL Digital Certificates published at www.cabforum.org. In the 
event that a discrepancy arises between interpretations of this document and 
Baseline Requirement, the Baseline Requirement shall govern. 

This is as far as I read. There are probably many more inconsistencies as Yuwei 
pointed out. 
I suggest Mozilla ask a staff who know Chinese to fully translate the Chinese 
CPS yourself and compare with the provided English CPS




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Han Yuwei]

在 2016年10月20日星期四 UTC+8上午5:27:42，Andrew R. Whalley写道：
> Hello,
> 
> Thank you for the links.  I note, however, that there's at least one
> difference between the native language version and the English translation:
> 
> http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
> CAA.
> https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 4.3
> in English has no such section.
> 
> The fact there's a discrepancy is rather worrying.  Could you please check
> and let me know if there are any other substantive differences between the
> Chinese and English versions?
> 
> Cheers,
> 
> Andrew
> 
> On Mon, Sep 26, 2016 at 7:17 PM,  wrote:
> 
> > 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > > Hello,
> > >
> > > I have completed a read through of the English translations of the CP
> > > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if there
> > > were any more recent translations?  It looks like the local language
> > > versions are 1.4 and 4.3 respectively.
> > >
> > > Many thanks,
> > >
> > > Andrew
> > >
> > > On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson 
> > wrote:
> > >
> > > > This request from Guangdong Certificate Authority (GDCA) is to include
> > the
> > > > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit,
> > and
> > > > enabled EV treatment.
> > > >
> > > > GDCA is a nationally recognized CA that operates under China’s
> > Electronic
> > > > Signature Law. GDCA’s customers are business corporations registered in
> > > > mainland China, government agencies of China, individuals or mainland
> > China
> > > > citizens, servers of business corporations which have been registered
> > in
> > > > mainland China, and software developers.
> > > >
> > > > The request is documented in the following bug:
> > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > > >
> > > > And in the pending certificates list:
> > > > https://wiki.mozilla.org/CA:PendingCAs
> > > >
> > > > Summary of Information Gathered and Verified:
> > > > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > > >
> > > > Noteworthy points:
> > > >
> > > > * Root Certificate Download URL:
> > > > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > > > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > > >
> > > > * The primary documents are provided in Chinese.
> > > >
> > > > CA Document Repository: https://www.gdca.com.cn/
> > > > customer_service/knowledge_universe/cp_cps/
> > > > http://www.gdca.com.cn/cp/cp
> > > > http://www.gdca.com.cn/cps/cps
> > > > http://www.gdca.com.cn/cp/ev-cp
> > > > http://www.gdca.com.cn/cps/ev-cps
> > > >
> > > > Translations into English:
> > > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > > > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > > >
> > > > * CA Hierarchy: This root certificate has internally-operated
> > subordinate
> > > > CAs
> > > > - 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)
> > > >
> > > > * This request is to turn on the Websites trust bit.
> > > >
> > > > CPS section 3.2.5: For domain verification, GDCA needs to check the
> > > > written materials which can be used to prove the ownership of
> > corresponding
> > > > domain provided by applicant. Meanwhile, GDCA should ensure the
> > ownership
> > > > of domain from corresponding registrant or other authoritative
> > third-party
> > > > databases. During the verification, GDCA needs to perform the following
> > > > procedures:
> > > > 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.
> > > > If necessary, GDCA also need to take other review measures to confirm
> > the
> > > > ownership of the domain name. Applicant can't refuse to the request for
> > > > providing appropriate assistance.
> > > >
> > > >
> > > > * EV Policy OID: 1.2.156.112559.1.1.6.1
> > > >
> > > > * Test Website: https://ev-ssl-test-1.95105813.cn/
> > > >
> > > > * CRL URLs:

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Andrew R. Whalley]

Hello,

Thank you for the links.  I note, however, that there's at least one
difference between the native language version and the English translation:

http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
CAA.
https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 4.3
in English has no such section.

The fact there's a discrepancy is rather worrying.  Could you please check
and let me know if there are any other substantive differences between the
Chinese and English versions?

Cheers,

Andrew

On Mon, Sep 26, 2016 at 7:17 PM,  wrote:

> 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > Hello,
> >
> > I have completed a read through of the English translations of the CP
> > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if there
> > were any more recent translations?  It looks like the local language
> > versions are 1.4 and 4.3 respectively.
> >
> > Many thanks,
> >
> > Andrew
> >
> > On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson 
> wrote:
> >
> > > This request from Guangdong Certificate Authority (GDCA) is to include
> the
> > > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit,
> and
> > > enabled EV treatment.
> > >
> > > GDCA is a nationally recognized CA that operates under China’s
> Electronic
> > > Signature Law. GDCA’s customers are business corporations registered in
> > > mainland China, government agencies of China, individuals or mainland
> China
> > > citizens, servers of business corporations which have been registered
> in
> > > mainland China, and software developers.
> > >
> > > The request is documented in the following bug:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > >
> > > And in the pending certificates list:
> > > https://wiki.mozilla.org/CA:PendingCAs
> > >
> > > Summary of Information Gathered and Verified:
> > > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > >
> > > Noteworthy points:
> > >
> > > * Root Certificate Download URL:
> > > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > >
> > > * The primary documents are provided in Chinese.
> > >
> > > CA Document Repository: https://www.gdca.com.cn/
> > > customer_service/knowledge_universe/cp_cps/
> > > http://www.gdca.com.cn/cp/cp
> > > http://www.gdca.com.cn/cps/cps
> > > http://www.gdca.com.cn/cp/ev-cp
> > > http://www.gdca.com.cn/cps/ev-cps
> > >
> > > Translations into English:
> > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > >
> > > * CA Hierarchy: This root certificate has internally-operated
> subordinate
> > > CAs
> > > - 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)
> > >
> > > * This request is to turn on the Websites trust bit.
> > >
> > > CPS section 3.2.5: For domain verification, GDCA needs to check the
> > > written materials which can be used to prove the ownership of
> corresponding
> > > domain provided by applicant. Meanwhile, GDCA should ensure the
> ownership
> > > of domain from corresponding registrant or other authoritative
> third-party
> > > databases. During the verification, GDCA needs to perform the following
> > > procedures:
> > > 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.
> > > If necessary, GDCA also need to take other review measures to confirm
> the
> > > ownership of the domain name. Applicant can't refuse to the request for
> > > providing appropriate assistance.
> > >
> > >
> > > * EV Policy OID: 1.2.156.112559.1.1.6.1
> > >
> > > * Test Website: https://ev-ssl-test-1.95105813.cn/
> > >
> > > * CRL URLs:
> > > 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
> > >
> > > * OCSP URL:
> > > http://www.gdca.com.cn/TrustAUTH/ocsp
> > >
> > > * Audit: 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> Hello,
> 
> I have completed a read through of the English translations of the CP
> (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if there
> were any more recent translations?  It looks like the local language
> versions are 1.4 and 4.3 respectively.
> 
> Many thanks,
> 
> Andrew
> 
> On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson  wrote:
> 
> > This request from Guangdong Certificate Authority (GDCA) is to include the
> > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and
> > enabled EV treatment.
> >
> > GDCA is a nationally recognized CA that operates under China’s Electronic
> > Signature Law. GDCA’s customers are business corporations registered in
> > mainland China, government agencies of China, individuals or mainland China
> > citizens, servers of business corporations which have been registered in
> > mainland China, and software developers.
> >
> > The request is documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> >
> > And in the pending certificates list:
> > https://wiki.mozilla.org/CA:PendingCAs
> >
> > Summary of Information Gathered and Verified:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> >
> > Noteworthy points:
> >
> > * Root Certificate Download URL:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> >
> > * The primary documents are provided in Chinese.
> >
> > CA Document Repository: https://www.gdca.com.cn/
> > customer_service/knowledge_universe/cp_cps/
> > http://www.gdca.com.cn/cp/cp
> > http://www.gdca.com.cn/cps/cps
> > http://www.gdca.com.cn/cp/ev-cp
> > http://www.gdca.com.cn/cps/ev-cps
> >
> > Translations into English:
> > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> >
> > * CA Hierarchy: This root certificate has internally-operated subordinate
> > CAs
> > - 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)
> >
> > * This request is to turn on the Websites trust bit.
> >
> > CPS section 3.2.5: For domain verification, GDCA needs to check the
> > written materials which can be used to prove the ownership of corresponding
> > domain provided by applicant. Meanwhile, GDCA should ensure the ownership
> > of domain from corresponding registrant or other authoritative third-party
> > databases. During the verification, GDCA needs to perform the following
> > procedures:
> > 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.
> > If necessary, GDCA also need to take other review measures to confirm the
> > ownership of the domain name. Applicant can't refuse to the request for
> > providing appropriate assistance.
> >
> >
> > * EV Policy OID: 1.2.156.112559.1.1.6.1
> >
> > * Test Website: https://ev-ssl-test-1.95105813.cn/
> >
> > * CRL URLs:
> > 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
> >
> > * OCSP URL:
> > http://www.gdca.com.cn/TrustAUTH/ocsp
> >
> > * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian
> > LLP according to the WebTrust criteria.
> > WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> > WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> > WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf
> >
> > * Potentially Problematic Practices: None Noted
> > (http://wiki.mozilla.org/CA:Problematic_Practices)
> >
> > This begins the discussion of the request from Guangdong Certificate
> > Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn
> > on the Websites trust bit, and enabled EV treatment. At the conclusion of
> > this discussion I will provide a summary of issues noted and action items.
> > If there are outstanding issues, then an additional discussion may be
> > needed as follow-up. If 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

> 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 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

在 2016年9月17日星期六 UTC+8上午5:38:29，Percy写道：
> On Wednesday, August 3, 2016 at 2:45:23 PM UTC-7, Kathleen Wilson wrote:
> > This request from Guangdong Certificate Authority (GDCA) is to include the 
> > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> > enabled EV treatment.
> > 
> > GDCA is a nationally recognized CA that operates under China’s Electronic 
> > Signature Law. GDCA’s customers are business corporations registered in 
> > mainland China, government agencies of China, individuals or mainland China 
> > citizens, servers of business corporations which have been registered in 
> > mainland China, and software developers.
> > 
> > The request is documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > 
> > And in the pending certificates list:
> > https://wiki.mozilla.org/CA:PendingCAs
> > 
> > Summary of Information Gathered and Verified:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > 
> > Noteworthy points:
> > 
> > * Root Certificate Download URL:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > 
> > * The primary documents are provided in Chinese.
> > 
> > CA Document Repository: 
> > https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/
> > http://www.gdca.com.cn/cp/cp
> > http://www.gdca.com.cn/cps/cps
> > http://www.gdca.com.cn/cp/ev-cp
> > http://www.gdca.com.cn/cps/ev-cps
> > 
> > Translations into English:
> > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > 
> > * CA Hierarchy: This root certificate has internally-operated subordinate 
> > CAs
> > - 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)
> > 
> > * This request is to turn on the Websites trust bit.
> > 
> > CPS section 3.2.5: For domain verification, GDCA needs to check the written 
> > materials which can be used to prove the ownership of corresponding domain 
> > provided by applicant. Meanwhile, GDCA should ensure the ownership of 
> > domain from corresponding registrant or other authoritative third-party 
> > databases. During the verification, GDCA needs to perform the following 
> > procedures:
> > 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.
> > If necessary, GDCA also need to take other review measures to confirm the 
> > ownership of the domain name. Applicant can't refuse to the request for 
> > providing appropriate assistance.
> > 
> > 
> > * EV Policy OID: 1.2.156.112559.1.1.6.1
> > 
> > * Test Website: https://ev-ssl-test-1.95105813.cn/
> > 
> > * CRL URLs:
> > 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
> > 
> > * OCSP URL:
> > http://www.gdca.com.cn/TrustAUTH/ocsp
> > 
> > * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian 
> > LLP according to the WebTrust criteria.
> > WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> > WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> > WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf
> > 
> > * Potentially Problematic Practices: None Noted
> > (http://wiki.mozilla.org/CA:Problematic_Practices)
> > 
> > This begins the discussion of the request from Guangdong Certificate 
> > Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn 
> > on the Websites trust bit, and enabled EV treatment. At the conclusion of 
> > this discussion I will provide a summary of issues noted and action items. 
> > If there are outstanding issues, then an additional discussion may be 
> > needed as follow-up. If there are no outstanding issues, then I will 
> > recommend approval of this request in the bug.
> > 
> > Kathleen
> 
> https://www.ssllabs.com/ssltest/analyze.html?d=www.gdca.com.cn
> This server is vulnerable to the OpenSSL Padding Oracle vulnerability 
> (CVE-2016-2107) and 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Peter Bowen]

On Mon, Sep 19, 2016 at 1:56 AM,   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, 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

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 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Peter Bowen]

On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson  wrote:
> This request from Guangdong Certificate Authority (GDCA) is to include the 
> "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> enabled EV treatment.
>
> * CA Hierarchy: This root certificate has internally-operated subordinate CAs
> - 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)
>
> * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP 
> according to the WebTrust criteria.
> WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf

Kathleen and team,

I reviewed the annual audit reports linked in your email, including
the auditor's opinion and the management assertions.

Good:
- The reports and management assertion include an English language version
- The English versions are authoritative (no qualification the Chinese
language version holds in case of conflict)
- The reports clearly state they use the International Standard on
Assurance Engagements (ISAE) 3000 standard
- The report and assertion use the current version of the criteria
- The assertions include details of each CA in the appendix, including
an indication of whether it is a Root CA and a cryptographic hash
(fingerprint) associated with each CA

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.
- The opinions do not specify the list of Certification Authorities in scope
- The reports and asssertions do not specify the versions 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.
- The BR report repeats a bullet under "Maintained effective controls
to provide reasonable assurance that:"

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)
- The basic WebTrust for CA Management assertion does not include
Subordinate CA [cross-]certification in the list of CA services
- The basic WebTrust for CA  Management assertion does not include
"Subordinate CA Certificate Lifecycle Management Controls" in the list
of portions of criteria used
- 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.
- 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.
- 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"
- 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.

The WebTrust/PKI Task Force has published a draft set of illustrative
reports to use as a basis
(http://www.webtrust.org/practitioner-qualifications/item83253.pdf),
so it should be faily easy to resolve the missing bits.

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Percy]

On Wednesday, August 3, 2016 at 2:45:23 PM UTC-7, Kathleen Wilson wrote:
> This request from Guangdong Certificate Authority (GDCA) is to include the 
> "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> enabled EV treatment.
> 
> GDCA is a nationally recognized CA that operates under China’s Electronic 
> Signature Law. GDCA’s customers are business corporations registered in 
> mainland China, government agencies of China, individuals or mainland China 
> citizens, servers of business corporations which have been registered in 
> mainland China, and software developers.
> 
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> 
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
> 
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> 
> Noteworthy points:
> 
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> 
> * The primary documents are provided in Chinese.
> 
> CA Document Repository: 
> https://www.gdca.com.cn/customer_service/knowledge_universe/cp_cps/
> http://www.gdca.com.cn/cp/cp
> http://www.gdca.com.cn/cps/cps
> http://www.gdca.com.cn/cp/ev-cp
> http://www.gdca.com.cn/cps/ev-cps
> 
> Translations into English:
> CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> 
> * CA Hierarchy: This root certificate has internally-operated subordinate CAs
> - 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)
> 
> * This request is to turn on the Websites trust bit.
> 
> CPS section 3.2.5: For domain verification, GDCA needs to check the written 
> materials which can be used to prove the ownership of corresponding domain 
> provided by applicant. Meanwhile, GDCA should ensure the ownership of domain 
> from corresponding registrant or other authoritative third-party databases. 
> During the verification, GDCA needs to perform the following procedures:
> 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.
> If necessary, GDCA also need to take other review measures to confirm the 
> ownership of the domain name. Applicant can't refuse to the request for 
> providing appropriate assistance.
> 
> 
> * EV Policy OID: 1.2.156.112559.1.1.6.1
> 
> * Test Website: https://ev-ssl-test-1.95105813.cn/
> 
> * CRL URLs:
> 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
> 
> * OCSP URL:
> http://www.gdca.com.cn/TrustAUTH/ocsp
> 
> * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP 
> according to the WebTrust criteria.
> WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf
> 
> * Potentially Problematic Practices: None Noted
> (http://wiki.mozilla.org/CA:Problematic_Practices)
> 
> This begins the discussion of the request from Guangdong Certificate 
> Authority (GDCA) to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on 
> the Websites trust bit, and enabled EV treatment. At the conclusion of this 
> discussion I will provide a summary of issues noted and action items. If 
> there are outstanding issues, then an additional discussion may be needed as 
> follow-up. If there are no outstanding issues, then I will recommend approval 
> of this request in the bug.
> 
> Kathleen

https://www.ssllabs.com/ssltest/analyze.html?d=www.gdca.com.cn
This server is vulnerable to the OpenSSL Padding Oracle vulnerability 
(CVE-2016-2107) and insecure. Grade set to F.

Maybe someone who has more expertise than me could take a look at this?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org