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 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 displays a misunderstanding of BR section 
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 (

8 * There are a few published, misissued, and currently unrevoked certificates 
in the CCR2016 hierarchy: 

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

dev-security-policy mailing list

Reply via email to