Hi Wyne here our answers to the ==Bad== issues we are working on the ==Meh== ones.
1 * 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. RMM -> EIDAS regulation has been an important milestone that took us to consider to setup a new hierarchy (2016) and writing a new CPS apart from the other hierarchies and CPS, even more when our final target is to distribute certificates only from the 2016 hierarchy. This request to incorporate the new 2016 roots affects only to eIDAS CPS (1.2.1). However, the CPS –no eIDAS (3.2.7) are still valid for the hierarchies (2003 and 2008). 2 * 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. RMM -> AC CAMERFIRMA GLOBAL FOR WEBSITES was audited for BR in the same way that was audited for EV. The absence of AC CAMERFIRMA GLOBAL FOR WEBSITES from the scope section of the attestation letter have been produced by a mistake, since this CA is detailed in Pag.32 of the same document. EV attestation letter follow the same model than BR. An auditor's note can be requested, if it is need it. 3 * 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. RMM -> Relationship with STARCOM as a delegated RA has been finalized since STARCOM stopped issuing certificates. STARCOM RA operator’s certificates are revoked from January 2018. Last certificate issued by STARCOM as a delegated RA was on December 2017. 4 * 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. RMM -> This issue is already clarified in our CPS last version that will be publish next March. 5 * 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. RMM -> This issue is already clarified in our CPS last version that will be publish next March. I was due to a misunderstanding of the BR. The procedure was corrected in November 2017. 6 * Camerfirma’s CAA domains are not documented in the CPS as required by BR section 2.2. RMM -> This issue is already included in our CPS last version that will be publish next March. AC Camerfirma use "camerfirma.com" as a CAA issuer record. 7 * 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). RMM -> This issue is already documented in our CPS last version that will be publish next March. In short, we use an email with a random value to domain contact that have to be sending back to the CA to prove domain control. BR 1.5.4 (3.2.2.4.2). 8 * 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 RMM -> Those few (four) misissued certificates are revoked from the very moment we were aware of that. We are opening a bug to explain this issue. Keep on working on ==Meh== ones Best regards Ramiro _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
