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=8866668 https://bug1128392.bmoattachments.org/attachment.cgi?id=8866669 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
