This request is for inclusion of the Camerfirma CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 (GCSR2016) as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=986854
* BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=8907536 * Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8839575 * Root Certificate Download URL: http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/ * CP/CPS: http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_v_1_2_1_EN.pdf * This request is to turn on the Websites and Email trust bits. EV treatment is requested. * EV Policy OIDs: 1.3.6.1.4.1.17326.10.16.3.5.1 (CCR2016), 1.3.6.1.4.1.17326.10.8.12.1.2 (GCSR2016) * Test Websites * CCR2016: https://cev.camerfirma.com expired https://cevrv.camerfirma.com revoked https://cevok.camerfirma.com valid * GCSR2016: https://csev.camerfirma.com expired https://csevrv.camerfirma.com revoked https://csevok.camerfirma.com valid * CRL URLs: CCR2016: http://crl.camerfirma.com/chambersofcommerceroot-2016.crl GCSR2016: http://crl.camerfirma.com/globalchambersignroot-2016.crl * OCSP URLs: http://ocsp.camerfirma.com/ * Audit: Annual audits are performed by AUREN according to the WebTrust for CA, EV, and BR audit criteria. WebTrust: https://bugzilla.mozilla.org/attachment.cgi?id=8890729 BR: https://bugzilla.mozilla.org/attachment.cgi?id=8890727 EV: https://bugzilla.mozilla.org/attachment.cgi?id=8890726 I’ve reviewed the CPS, BR Self Assessment, and related information for the CCR2016 and GCSR2016 inclusion requests that are being tracked in this bug [1] and have the following comments: ==Good== * Subordinate CAs issued under these roots are constrained to specific purposes via EKU. * Audit reports include English translations and contain most of the required information, with the exception of SHA-256 fingerprints and the full address of the auditor. * The CA hierarchies and applicable usages and policies are clearly described in section 1.2 of the CPS. ==Meh== * Camerfirma has had a number of recent compliance issues as listed below: Resolved: * Non-BR-compliant OCSP responders: https://bugzilla.mozilla.org/show_bug.cgi?id=1426233 * CAA checking failure: https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 * Duplicate SANs and without localityName or stateOrProvinceName: https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 * Invalid DNS Names: https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 (just resolved today) Still Open: * Non-printable characters in OU field: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 (this issue was reported by Camerfirma) * CPS [5] section 1.2.1.1 appears to exempt test certificates from BR requirements. * Section 3.1.8.2.2 of the CPS implies that CAA checking is done manually. While this isn’t forbidden, it is easily susceptible to errors. * CPS section 1.2.1.4.1.3 states that the GCSR2016 “is only used for the purpose of carrying out the accreditation processes with different browsers.” We recently decided to relax the requirements for inclusion, but this statement does imply that there is no value to Mozilla users in enabling the websites trust bit for this root. * CPS section 1.5.5 indicates that delegated RAs are permitted, but it does not clearly indicate that domain validation functions may not be delegated. * CPS section 2.5.3 states that “Camerfirma currently offers the OCSP service free-of-charge but reserves the right to invoice for these services.” If OCSP service were to be blocked for all but paying users, I believe that would be a BR violation. ==Bad== * The inclusion request references a much older CPS [3] that doesn't list the 2016 versions of these roots or comply with current policies. I only reviewed the newer CPS [5], but this CPS (section 1.2.1) doesn't cover the older roots that are currently included. I believe this is a compliance issue with the currently included AC Camerfirma roots. * I am unable to locate a BR audit for the GCSR2016, but the websites trust bit has been requested. I first thought that this root was not intended for serverAuth, but section 1.2.1.4 of the CPS indicates that there is an “AC CAMERFIRMA GLOBAL FOR WEBSITES” subordinate CA that chains to this root. Both roots are covered by the latest EV audit. * Last year, Camerfirma signed a contract with StartCom as a delegated RA. While I don’t believe the Startcom distrust plan [2] specifically forbade this, it was found that Camerfirma was not performing domain validation on the OV certificates [4] as required by the BRs. * The BR section 2.2 requirement that “The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version” is not clearly stated in the CPS. Also, the final paragraph of section 1.2 implies that the CPS takes precedence over BR requirements. * CPS section 3.1.8.2.2 displays a misunderstanding of BR section 3.2.2.8 when it states that ‘This last procedure will not be necessary if the certificate issuance uses “Certificate Transparency” as indicated in the CABFORUM BRs. CA-Browser Forum BR 1.4.4.’ The BRs only exempt CAA checking prior to issuing the actual certificate because checking is required prior to issuing the corresponding pre-certificate. * Camerfirma’s CAA domains are not documented in the CPS as required by BR section 2.2. * Camerfirma’s BR Self Assessment states that they use BR methods 2 and 4 for domain validation, but the methods are not clearly documented in the CPS as required by Mozilla policy section 2.2(3). * There are a few published, misissued, and currently unrevoked certificates in the CCR2016 hierarchy: https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01 This begins the 3-week comment period for this request [6]. I will greatly appreciate your thoughtful and constructive feedback on the acceptance of these roots into the Mozilla Root program. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=986854 [2] https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ [3] http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1350615 [5] http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_v_1_2_1_EN.pdf [6] https://wiki.mozilla.org/CA/Application_Process _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
