Greetings, I've given the CP V1.6 and CPS V4.5 docs a quick looking through and have the following comments:
* Please don't protect your PDFs for printing * 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. * 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. * 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) * 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." * 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. * 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. * 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. * 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. Thanks, Andrew On Sat, Apr 22, 2017 at 5:08 AM, wangsn1206--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 在 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
