Re: Guang Dong Certificate Authority (GDCA) root inclusion request
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
在 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
在 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
在 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
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: DRAFT - BR Self Assessments
在 2017年4月4日星期二 UTC+8上午1:47:34，Kathleen Wilson写道： > I updated https://wiki.mozilla.org/CA:BRs-Self-Assessment to add a section > called 'Annual BR Self Assessment', which states: > "CAs with included root certificates that have the Websites trust bit set > must do an annual self-assessment of their compliance with the BRs, and must > update their CP and CPS documents at least once every year." > > I added a section about this to the root inclusion/update Information > Checklist: > https://wiki.mozilla.org/CA:Information_checklist#Baseline_Requirements_Self_Assessement > > And I updated ACTION 2 of the CA Communication > https://mozillacaprogram.secure.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a05o03WrzBC > to include a link to this. > > Thanks, > Kathleen Hi Kathleen We have a question about completing the BR self assessment, is it necessary that all the BRs requirements appear in relevant sections of the CP/CPS? Or for some BRs requirements that are not specifically disclosed in the CP/CPS, CAs can explain their rules and practices to show that they meet or exceed these requirements? 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
在 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
在 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
在 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
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
