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: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

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

[Percy]

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

[Gervase Markham]

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

[Kathleen Wilson]

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

[Florian Weimer]

* 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

[Kathleen Wilson]

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

[Kathleen Wilson]

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

[Gervase Markham]

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

[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: