Thank you all for your replies. We tested and verified many problems mentioned by Erwann In conclusion the problems mentioned by Erwann are: 1,No SAN in certificate 2,MIME type of AIA URI and CRLDP is test/plain 3,OCSP signer certificate's public key, valid period and extension. 4,root key generation ceremony. 5,Crl number field in crl downloaded from CRLDP 6,issue relate to oca2-SHA1 and oca2-SHA256 with same serial number.
Since we have two inclusion request (GT/EV), I'll explain separately. For EV: 1, No SAN Status: No problem. We checked our EV test website and other EV certificate (and the issuing model), EV subject certificate have SAN 2, MIME type status： Fixed. The problem of MIME type is not within the CA issuing system (this means no problem with certificates' fields) but in the downloading server of AIA url and CRLDP. This problem is fixed by now 3, OCSP signer certificate Status: Fixed. The OCSP signing certificate issuing model is fixed by now, new ocsp signing certificate will have at least 2048 bits public key and valid period is set to 1000 days(33month). OCSP system for EV is updated and fixed by now. 4, root key generation ceremony. Status: No problem. We discussed this issue with our auditor. Below is our reply: Because our root was generated in August 2012 and we became aware of BRs in 2013 Dec, we did not require auditor to issue the audit report about root key generation. Although the auditor did not issue an audit report about the root key generation, they actually observed the root key generation ceremony on site and performed all required audit procedures according to the Trust Service Principles and Criteria for CA v2.0 and WebTrust Audit Criteria and WebTrust EV Audit Criteria V1.4 which have same root key generation requirements with Webtrust BR Audit Criteria. No issue was identified. If the auditor cannot obtain reasonable assurance that all requirements are followed, it will not be possible to issue the unqualified WT opinions in 2012. Following Mozilla's root certificate inclusion policy (https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy): "Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. Note that the CA's first Baseline Requirements audit may be a Point in Time audit. " And it's our first BR audit, so the auditor performed a Point in Time Pre-Issuance Readiness audit in this April. Since this is a point in time audit, the auditor only evaluated the design effectiveness. In the next audit, the operating effectiveness for a period will be evaluated. 5, CRL number field in crl downloaded from CRLDP Status: Confirmed and fixing. We discussed this issue with our auditor: Our auditor performed the audit according to the Trust Service Principles and Criteria for CA v2.0 , SSL BR audit criteria V1.1 and WebTrust EV Audit Criteria V1.4. Except the SAN extension and root key generation requirements, other issues raised are not specified in these audit criteria, so they are not in the scope of audit. This is why the auditor did not find these issues. Crl number field means "Section" in the old crl system of CFCA, for example the 0~500 certificates have same crl number "1", which means they are in section one. an update will take place soon in this system to ensure every detail comply to x509/RFC5280. We will take measures to make sure similar problems won't happen again, and these features will not be missed in the future audit/report. We will provide details in next reply within this Public discussion. 6, issue relate to oca2-SHA1 and oca2-SHA256 Status: No problem. EV system has no problem relate to this issue. For GT: We are still investigating the issue relate to oca2-SHA1 and oca2-SHA256 with same serial number (How did it happen and what should we do). We will include information relate to GT root in the next reply. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
