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:

* BR Self Assessment is here:

* Summary of Information Gathered and Verified:

* Root Certificate Download URL:


* This request is to turn on the Websites and Email trust bits. EV
treatment is requested.

* EV Policy OIDs: (CCR2016), (GCSR2016)

* Test Websites
  * CCR2016: expired revoked valid

  * GCSR2016: expired revoked valid



* Audit: Annual audits are performed by AUREN according to the WebTrust for
CA, EV, and BR audit criteria.

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:

* 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.

* Camerfirma has had a number of recent compliance issues as listed below:
    * Non-BR-compliant OCSP responders:
    * CAA checking failure:
    * Duplicate SANs and without localityName or stateOrProvinceName:
    * Invalid DNS Names: (just resolved today)
Still Open:
    * Non-printable characters in OU field: (this issue was
reported by Camerfirma)
* CPS [5] section appears to exempt test certificates from BR
* Section of the CPS implies that CAA checking is done manually.
While this isn’t forbidden, it is easily susceptible to errors.
* CPS section 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.

* 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 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
* 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.
* 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:,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

dev-security-policy mailing list

Reply via email to