Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 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 other review measures to confirm > > > the >
Re: Guang Dong Certificate Authority (GDCA) root inclusion request
在 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
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: Remediation Plan for WoSign and StartCom
On Thursday, October 20, 2016 at 6:59:08 PM UTC-7, Percy wrote: > Kathleen, > As most users affected by this decision are Chinese, will you be able to make > the blog post available in Chinese on the security blog as well? You can ask > the Chinese firefox community or me to translate. > > As I stated earlier, there are almost no news of the distrust of > WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted > anything related to this. I believe it's paramount to prepare Chinese website > owners for the phasing out of the affected roots. Noted. I will look into how to get it translated into Chinese and how to make that version available as well. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
Kathleen, As most users affected by this decision are Chinese, will you be able to make the blog post available in Chinese on the security blog as well? You can ask the Chinese firefox community or me to translate. As I stated earlier, there are almost no news of the distrust of WoSign/StartCom on the Chinese Internet and WoSign/StartCom has not posted anything related to this. I believe it's paramount to prepare Chinese website owners for the phasing out of the affected roots. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
On 20/10/16 15:05, Kathleen Wilson wrote: > You are receiving this email because our records indicate that there > are non-technically-constrained intermediate certificates that chain > up to your root certificates that are included in Mozilla’s program > that have not been entered into the CA Community in Salesforce. > Please complete this requirement by November 14, 2016. I don't think we should set another deadline. We should remind them that the deadline was June, tell them to do it ASAP, and warn them that we could begin discussions about taking action at any time. > of Mozilla's CA Certificate Inclusion Policy, you are required to > provide public-facing documentation about the certificate > verification requirements and annual public attestation of > conformance to said requirements. There is an open question, raised by Peter Bowen in CAB Forum, of what to do about intermediate CAs which were created since the last audit. We should work out what to do about that, at least in the short term, before sending this message. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
On Thursday, October 20, 2016 at 2:24:19 PM UTC-7, Florian Weimer wrote: > > Does this requirement apply transitively sub-CAs of sub-CAs? > > It may make sense to stress explicitly that the “technically > constrained” refers to properties visible in the certificates > themselves, not technical measures in the certificate issuance process > (which I would consider organizational constraints, but opinions > probably differ). Good points. Updated draft... ~~ Subject: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs Dear Certification Authority, You are receiving this email because our records indicate that there are non-technically-constrained intermediate certificates that chain up to your root certificates that are included in Mozilla’s program that have not been entered into the CA Community in Salesforce. Please complete this requirement by November 14, 2016. Soon after that date, Mozilla will begin discussions in the mozilla.dev.security.policy forum about action to take for any remaining non-disclosed non-technically-constrained intermediate certificates and the CAs who are responsible for those CA hierarchies. The following was stated in Mozilla’s March 2016 CA Communication (https://wiki.mozilla.org/CA:Communications#March_2016): Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please see https://wiki.mozilla.org/CA:SalesforceCommunity for information about which intermediate certificate data you are expected to enter into the CA Community in Salesforce, and instructions on how to do so. In particular, CAs must add records to the CA Community in Salesforce for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program that are not Technically Constrained via Extended Key Usage and Name Constraint settings. Intermediate certificates are considered to be technically constrained, and do not need to be added to the CA Community in Salesforce if: - The intermediate certificate has the Extended Key Usage (EKU) extension and the EKU does not include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth; or - The EKU extension in the intermediate certificate includes the anyExtendedKeyUsage or id-kp-serverAuth KeyPurposeIds, and the intermediate certificate includes the Name Constraints extension as described in section 7.1.5 of the CA/Browser Forum's Baseline Requirements; or - The root certificate is not enabled with the Websites trust bit. Records should also be added to the CA Community in Salesforce for revoked certificates that were capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program and were not Technically Constrained via Extended Key Usage and Name Constraint settings. Regards, Kathleen Wilson, Mozilla CA Program Manager ~~ > > What about sub-CAs with outdated published policies which do not meet > Mozilla's requirements, but where the CA actually issues certificates > according to an unpublished policy which is likely conforming to > Mozilla's requirements? I'm not sure what that question means. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft Email - Non-Disclosed SubCAs
* Kathleen Wilson: > The following was stated in Mozilla’s March 2016 CA Communication > (https://wiki.mozilla.org/CA:Communications#March_2016): > Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any > certificate which directly or transitively chains to the root > certificates you currently have included in Mozilla's CA Certificate > Program, which are capable of being used to issue new certificates, > and which are not technically constrained as described in Section 9 of > Mozilla's CA Certificate Inclusion Policy, you are required to provide > public-facing documentation about the certificate verification > requirements and annual public attestation of conformance to said > requirements. This includes certificates owned by, operated by, or > issued by third parties, whether or not those issuing certificates are > already part of Mozilla's CA Certificate Program, if they have been > cross-signed by a certificate that directly or transitively chains to > your root certificate. Does this requirement apply transitively sub-CAs of sub-CAs? It may make sense to stress explicitly that the “technically constrained” refers to properties visible in the certificates themselves, not technical measures in the certificate issuance process (which I would consider organizational constraints, but opinions probably differ). What about sub-CAs with outdated published policies which do not meet Mozilla's requirements, but where the CA actually issues certificates according to an unpublished policy which is likely conforming to Mozilla's requirements? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
All, I have filed the following two bugs. WoSign Action Items: https://bugzilla.mozilla.org/show_bug.cgi?id=1311824 StartCom Action Items: https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 I will work on a security blog that will probably get posted early next week. It will point to these two bugs, and list the actions Mozilla plans to take. As we have been discussing, Mozilla plans to take the following actions: 1) Distrust certificates with a notBefore date after October 21, 2016 which chain up to the following affected roots. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the affected roots. a) This change will go into the Firefox 51 release train. b) The code will use the following Subject Distinguished Names to identify the root certificates, so that the control will also apply to cross-certificates of these roots. i) CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN ii) CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN iii) CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN iv) CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN v) CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL vi) CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL 2) Add the previously identified backdated SHA-1 certificates chaining up to these affected roots to OneCRL. 3) No longer accept audits carried out by Ernst & Young Hong Kong. 4) Remove these affected root certificates from Mozilla’s root store at some point in the future. If the CA's new root certificates are accepted for inclusion, then Mozilla may coordinate the removal date with the CA’s plans to migrate their customers to the new root certificates. Otherwise, Mozilla may choose to remove them at any point after March 2017. 5) Mozilla reserves the right to take further or alternative action. This discussion is still open, and I will still continue to appreciate your input on this topic. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Draft Email - Non-Disclosed SubCAs
All, Next week I expect to have a better capability for sending notification emails to CAs. The first email I would like to try this new tool on is regarding the CAs who have not disclosed all of their non-technically-constrained intermediate certificates in the CA Community in Salesforce (aka Common CA Database). Those CAs may be seen in the table here: https://crt.sh/mozilla-disclosures#undisclosedsummary I will appreciate your thoughtful and constructive feedback on the following draft of the email. ~~ Subject: ACTION REQUIRED: Non-Disclosed non-technically-constrained Intermediate Certs Dear Certification Authority, You are receiving this email because our records indicate that there are non-technically-constrained intermediate certificates that chain up to your root certificates that are included in Mozilla’s program that have not been entered into the CA Community in Salesforce. Please complete this requirement by November 14, 2016. Soon after that date, Mozilla will begin discussions in the mozilla.dev.security.policy forum about action to take for any remaining non-disclosed non-technically-constrained intermediate certificates and the CAs who are responsible for those CA hierarchies. The following was stated in Mozilla’s March 2016 CA Communication (https://wiki.mozilla.org/CA:Communications#March_2016): Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate. To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates. Please see https://wiki.mozilla.org/CA:SalesforceCommunity for information about which intermediate certificate data you are expected to enter into the CA Community in Salesforce, and instructions on how to do so. Regards, Kathleen Wilson, Mozilla CA Program Manager ~~ Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
On 19/10/16 15:13, okaphone.elektron...@gmail.com wrote: > Perhaps "haste" is not what you want here. How about "urgency"? I was using it in the sense of the English phrase "more haste, less speed": http://dictionary.cambridge.org/dictionary/english/more-haste-less-speed But yes, urgency is fine. 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
在 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: > > > > http://www.gdca.com.cn/crl/GDCA_Trus