On Tuesday, March 6, 2018 at 3:45:47 AM UTC-8, ramiro...@gmail.com wrote: > 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
Several times you mention in your response: > This issue is already clarified in our CPS last version that will be publish > next March. Why wait an entire year to publish a new version of the CPS? The Certificate Practices Statement should be an accurate description of the certificate authority's current or near future operational practices, so you should be publishing new versions as necessary to reflect changes in operations. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
