AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Wayne Thayer]

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

[David E. Ross]

On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:

[snipped]

NOTE: The fact that I have snipped some of the items under "==Bad=="
does not mean I consider them unimportant. However, the items on
which I comment I consider to be most important.

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

Is the above not sufficient to terminate the public review?

[snipped]

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

I would strongly suggest that further action be deferred until the cited
contract can be confirmed to have been terminated.

[snipped]

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

If Camerfirma had been already approved and its root added to the RSS
database, would not the above item be sufficient to remove that root?

[snipped]
--
David E. Ross
<http://www.rossde.com/>

President Trump: Please stop using Twitter. We need
to hear your voice and see you talking. We need to know
when your message is really your own and not your attorney's.

[Wayne Thayer]

On Fri, Mar 2, 2018 at 3:47 PM, David E. Ross via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]:
>
> [snipped]
>
> NOTE: The fact that I have snipped some of the items under "==Bad=="
> does not mean I consider them unimportant. However, the items on
> which I comment I consider to be most important.
>

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

> Is the above not sufficient to terminate the public review?
>

> My comment may be confusing. The newer CPS specifically covers the roots
we're discussing, and the CPS is compliant with policy with the exception
of things noted in other comments. I would like Camerfirma to comment on my
conclusion about the older CPS and it's applicability to the older roots.

[snipped]

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

> I would strongly suggest that further action be deferred until the cited
> contract can be confirmed to have been terminated.
>

> I would like to hear from Camerfirma on this, but StartCom did announce
that they have "terminated the company":
https://groups.google.com/d/msg/mozilla.dev.security.policy/DxbMjAN7VbY/VJ0W9LQhBwAJ


> [snipped]

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

> If Camerfirma had been already approved and its root added to the RSS
> database, would not the above item be sufficient to remove that root?
>

> It would be treated as an incident, but in isolation seems unlikely to
rise to the level of root removal.

[snipped]
> --
> David E. Ross
> <http://www.rossde.com/>
>
> President Trump: Please stop using Twitter. We need
> to hear your voice and see you talking. We need to know
> when your message is really your own and not your attorney's.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[ramiro...@gmail.com]

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

[ramiro...@gmail.com]

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

I have included an Auditor erratum note in https://bugzilla.mozilla.org/show_bug.cgi?id=986854

Regards
Ramiro

[mart...@camerfirma.com]

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

We've opened a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1443857

[kane...@gmail.com]

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.

[Wayne Thayer]

On Tue, Mar 6, 2018 at 4:45 AM, ramirommunoz--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

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

> Roots from the older hierarchies are currently included in the Mozilla CA
program, but the CPS that applies to these roots does not comply with
Mozilla policy (it hasn't been revised since 2015) - is that correct? If
so, how and when do you intend to correct the problem?

- Wayne

[Ramiro Muñoz]

> 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).
>
> Roots from the older hierarchies are currently included in the Mozilla
> CA program, but the CPS that applies to these roots does not comply with
> Mozilla policy (it hasn't been revised since 2015) - is that correct? If so,
> how and when do you intend to correct the problem?

RMM -> Certainly we have focused on the eIDAS CPS roots 2016 that is affecting
this bug.
Although the CPS version of the root (2003 and 2008) is dated 2015, procedures
and controls used to issue SSL certificates are the same for all roots and
fulfill the BR requirements as indicated by our WEBTRUST CA,BR,EVaudit
reports.
We are currently working on both DPC to fulfill the requirement of adaptation
to the RFC3647 structure required by CABFORUM. We plan to publish them next
April. In any case we will publish them before 2018-05-31 limit required by
CABFORUM providing a solution to this issue. Although we would like wait for
the April RFC3647 adapted version, If the community consider that a version
should be publish immediately, AC Camerfirma have no objection to do that.

Regards
Ramiro

[ramiro...@gmail.com]

Hi Wayne
Here my answers to the ==Meh== questions.

1 * 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)

RMM --> We are working on the "still open" bug to close it as soon as possible.


2 * CPS [5] section 1.2.1.1 appears to exempt test certificates from BR requirements.

RMM --> AC Camerfirma do not issue SSL test certificates anymore. AC Camerfirma will clarify this issue in the next CPS version

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

RMM --> See https://bugzilla.mozilla.org/show_bug.cgi?id=1390977.
At the moment a non-technical check over the CAA value is done by the RA Operator before issue any certificate.
We plan to have the CAA technical control in March 2018,

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

RMM --> We use this Root as a possible contingency. We would like to keep it as it. If the community considers it's a risk, AC Camerfirma has no objection to leave it out of the scope.

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

RMM -> AC Camerfirma will clarify this issue in the next CPS version. Since it was stated by BR AC Camerfirma has always performed domain validation.

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

RMM -> AC Camerfirma will correct this issue in the next CPS version. Nevertheless AC Camerfirma never ever has charged for OCSP access.

BR
Ramiro

[Ryan Sleevi]

Wayne,

Thank you for your detailed review of the CP/CPS.

In attempt to discuss continued trust, I have attempted to summarize the
patterns and issues of note, along with the timeline from reporting to
remediation. It is my goal that this will allow the public to make an
objective assessment of the risks introduced by Camerfirma, as well as the
responsiveness towards remediation. While the ecosystem continues to
improve both its understanding of the requirements and expectations, we
must nevertheless consider the full picture.

Issue 1: Invalid dNSNames/CNs (
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
2014-09-25 - https://crt.sh/?id=5129200&opt=cablint issued
2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
2017-08-13 - Jonathan Rudenberg contacts the CA
2017-08-16 - Kathleen Wilson opens a Bugzilla incident
2017-08-17 - Camerfirma Responds
2017-09 - Scheduled remediation
2017-12 - First attempted remediation
2018-02-14 - Actual remediation, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33

Issue 2: Unrevoked Internal Servernames (
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
2016-10-01 - Deadline for revoking internal server name certificates
2017-08-24 - Camerfirma shares list of misissued certificates affected by
Issue 1, along with their response
2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify and
revoke internal server name certificates -
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123&opt=ocsp
2017-11-28 - Gerv Markham highlights that Camerfirma has still not
responded to outstanding questions -
https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
2017-12-21 - Camerfirma responds to the substance of the questions

Issue 3 - Improperly Configured OCSP -
https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
configurations at
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by
Camerfirma
2017-12-22 - Camerfirma confirms the issue is resolved. It took one of
their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to
implement these changes. Camerfirma did not self-report this
non-compliance, despite acknowledging it on 12-12.
2018-01-03 - Camerfirma completes a minimal incident report with all
required information.

Issue 4 - Improper CAA checking (
https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
2017-09-08 - Baseline Requirements require checking CAA
2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
Camerfirma
2017-11-29 - Camerfirma confirms misissuance, believing it was valid
because they found "and for which CAA was checked" to be confusing and
indicating that CAA checking was optional.
2017-11-29 - Camerfirma claims CAA checking is activated on all RAs

Issue 5 - Duplicate dNSNames and invalid localityName/stateOrProvinceName (
https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
2017-04-17 - Issue reported
2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
is apparently a Camerfirma issue, and with improper logging as well as
certificate configuration.
2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
Note: No response was provided by Camerfirma in this incident report.

Issue 6 - Out of date CP/CPSes
2016-06 - Last published version of the CPS at
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
2018-05 - Next proposed update of the CPS, as stated elsewhere on this
thread

I'm not sure whether to track issues with the new hierarchy, so I will
simply note the following:
2017-08-23 - Last issued certificate with invalid dNSName (
https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01
)
2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
requirements that "CAs conforming to this profile MUST use either the
PrintableString or UTF8String encoding of DirectoryString, with two
exceptions" (
https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 )

Notable is that Camerfirma includes the organizationIdentifier,
OID 2.5.4.97, in their certificates. This is documented in the CPS [5] from
the original message, within Section 3.1.1, with the validation process
described in 3.1.8.1. However, the CP/CPS lacks details as to the
construction and validation - it appears to be a construction of "VAT"
[member state] "-" [VAT number]


In this, we see a pattern of issues, with a strong reliance on trusting RAs
(which included entities such as StartCom, known to not be validating
correctly) and, when failure detected, on technical controls. We see a
pattern of delayed remediation, misunderstanding of expectations in the
face of misissuance, and misunderstandings of the requirements themselves.
If there is any one remark that perfectly captures this, it would be found
in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 , provided on
2017-12-21 (i.e. after many of these issues)

"AC Camerfirma is a small CA that uses an in-house developed CA software
and is supported by our RA trusted operators and the continuous training
they receive. AC Camerfirma has been working with this technology and staff
for 17 years without problems and we have dedicated a big effort improving
it along those years. Due to the number of TLS certificates issued on
previous years, this working method was appropriate and suitable for us.
The increase of certificates issued, increasing technical requirements and
the analysis of these reported problems have helped us to realize the need
to extend the technical controls in the CA application to cover all
possible and new requirements and introduce a new person in charge of
coordinating these implementations."

I think it's problematic to suggest "without problems", and concerning that
it required a "big effort" to improving. It equally remains
problematic/concerning that the in-house CA software has continued to show
issues.

Camerfirma states that it believes those issues remediated, in part, by
extending technical controls. Yet many of these failures also highlight
problems in the design of the system (and its reliance on RAs) and the
staff tasked with understanding and implementing compliance.

In the midst of all of this overhaul at Camerfirma, the 2016 root was
created. The existing roots still show problems (such as their CP/CPS
issues), and it seems energy has been focused on the new root, despite it
operating for a considerable time on the legacy infrastructure and subject
to issues as recently as 3 months ago.

If, despite the evidence, we are to believe that Camerfirma has remediated
the technical issues (via the technical controls deployed in February 2018)
and has remediated the policy issues (via the onboarding of new staff
tasked with ensuring compliance in December 2017), then it seems minimally
appropriate to suggest that a new, Camerfirma 2018 root be created and
established. Camerfirma's 2016 root can be used to cross-certify this, thus
supporting those users on Microsoft platforms for which 2016 is trusted,
while providing greater assurance that the issuance and trust is
appropriate. Such an inclusion should not occur until a key generation
ceremony report, a point in time audit, and a period of time audit report
have been provided for the new 2018 root, which would mean would not be
reconsidered for at least 3 months, at a minimum. This would also ensure
that Camerfirma has completed its remediation steps for its existing set of
hierarchy, such as updating the CP/CPS, demonstrating that the new controls
and personnel are equipped to maintain a globally trusted CA.

Further, given Camerfirma's statements that their investment in compliance
is with regards to the 2016 root, and the issue the prior roots have had
(both from policy compliance and issuance), it seems that we should also
begin discussing at what point trust in those legacy roots should be
removed, up to and including disallowing new certificates from it if
existing certificates are to remain trusted, as new issuance will be
on/from the 2018 root (through the 2016 path, for Windows users)

[ramiro...@gmail.com]

Hi Ryan
Many thanks for your report. I will try to answer to your concerns about our root inclusión.

All previous bugs as you said are closed successfully.

>
> Issue 5 - Duplicate dNSNames and invalid localityName/stateOrProvinceName (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> 2017-04-17 - Issue reported
> 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
> is apparently a Camerfirma issue, and with improper logging as well as
> certificate configuration.
> 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
> Note: No response was provided by Camerfirma in this incident report.
>

We were not aware that an answer from us was needed. The incident report provided by StartCom was coordinated with us.

>
> Issue 6 - Out of date CP/CPSes
> 2016-06 - Last published version of the CPS at
> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> 2018-05 - Next proposed update of the CPS, as stated elsewhere on this
> thread
>

We already have a new CPS version, next week we will publish it, and a new version when it was RFC 3647 compliant.

>
> I'm not sure whether to track issues with the new hierarchy, so I will
> simply note the following:
> 2017-08-23 - Last issued certificate with invalid dNSName (
> https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01
> )
> 2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
> requirements that "CAs conforming to this profile MUST use either the
> PrintableString or UTF8String encoding of DirectoryString, with two
> exceptions" ( https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 )
>

there is an open bug https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 where previous bug are treated.

>
> Notable is that Camerfirma includes the organizationIdentifier,
> OID 2.5.4.97, in their certificates. This is documented in the CPS [5] from
> the original message, within Section 3.1.1, with the validation process
> described in 3.1.8.1. However, the CP/CPS lacks details as to the
> construction and validation - it appears to be a construction of "VAT"
> [member state] "-" [VAT number]
>

website certificates profile is defined in ETSI EN 319 412-4. This standard refers ETSI EN 319 412-1 where this OID is defined. VAT is as defined in CPS section 3.1.8.2.3

>
> In this, we see a pattern of issues, with a strong reliance on trusting RAs
> (which included entities such as StartCom, known to not be validating
> correctly) and, when failure detected, on technical controls. We see a
> pattern of delayed remediation, misunderstanding of expectations in the
> face of misissuance, and misunderstandings of the requirements themselves.
> If there is any one remark that perfectly captures this, it would be found
> in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 , provided on
> 2017-12-21 (i.e. after many of these issues)
>

We rely on our RA network and we train them and audit them for assure a correct validation. As a result of https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 technical controls were deployed to avoid misissuance, misunderstandings and reduce this dependency on trusting RAs.

>
> "AC Camerfirma is a small CA that uses an in-house developed CA software
> and is supported by our RA trusted operators and the continuous training
> they receive. AC Camerfirma has been working with this technology and staff
> for 17 years without problems and we have dedicated a big effort improving
> it along those years. Due to the number of TLS certificates issued on
> previous years, this working method was appropriate and suitable for us.
> The increase of certificates issued, increasing technical requirements and
> the analysis of these reported problems have helped us to realize the need
> to extend the technical controls in the CA application to cover all
> possible and new requirements and introduce a new person in charge of
> coordinating these implementations."
>
> I think it's problematic to suggest "without problems", and concerning that
> it required a "big effort" to improving. It equally remains
> problematic/concerning that the in-house CA software has continued to show
> issues.
>

When we said “without problems” means that our practices and tools (PKI platform included) has passed many audit successfully. Sure, we have to improve (this very process, and every control, audits, certifications helps us to improve it). Just to let the community know, this is the list of AC Camerfirma SA last audit process:
ETSI 319 401 Audited by TÜV-IT (2017-2019) https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf
ETSI 319 401 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf
ETSI 319 411-1 Audited by TÜV-IT (2017-2019) https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf
ETSI 319 411-1 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf
ETSI 319 411-2 Audited by TÜV-IT (2017-2019) https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/9725UE_s.pdf
ETSI 319 411-2 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf
ETSI 319 421 Audited by CSQA (2017-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/certificatocamerfirma2017.pdf
WEBTRUST FOR CA Audited by AUREN (2017) https://cert.webtrust.org/SealFile?seal=2283&file=pdf
WEBTRUST BR Audited by AUREN (2017-2018) https://cert.webtrust.org/SealFile?seal=2284&file=pdf
WEBTRUST EV Audited by AUREN (2017-2018) https://cert.webtrust.org/SealFile?seal=2285&file=pdf
ISO 27001 Audited by AENOR (2016-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_27001_AENOR.pdf
ISO 20000 Audited by AENOR (2016-2019) http://docs.camerfirma.com/publico/DocumentosWeb/certificaciones/ISO_20000_AENOR.pdf.

In spite of the issues arisen, hope that at least this could count on our favor when a decision about our root inclusion were taken.

Creating a new root 2018 is unfeasible for us for the following reasons:
•Root 2016 is already audited and incorporated into the European TSL based on the favorable evaluation of our national supervisor body for both the issuance of S/MIME, WEB and TSU certificates.
•Root is already recognized by other comunities such as Microsoft and Adobe.
•Root 2016 is already accredited in the Spanish public administration & Public Services.
•And above all, because the problems found so far have not incorporated a significant risk to the user community and they have been solved by incorporating technical controls and specific resources that currently allow us to commit with the ecosystem requirements.

Best Regards
Ramiro

[Ryan Sleevi]

On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Ryan
> Many thanks for your report. I will try to answer to your concerns about
> our root inclusión.
>

> All previous bugs as you said are closed successfully.
>
> >

> > Issue 5 - Duplicate dNSNames and invalid
> localityName/stateOrProvinceName (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> > 2017-04-17 - Issue reported
> > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
> > is apparently a Camerfirma issue, and with improper logging as well as
> > certificate configuration.
> > 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
> > Note: No response was provided by Camerfirma in this incident report.
> >

> We were not aware that an answer from us was needed. The incident report
> provided by StartCom was coordinated with us.
> >

> > Issue 6 - Out of date CP/CPSes
> > 2016-06 - Last published version of the CPS at
> >
> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> > 2018-05 - Next proposed update of the CPS, as stated elsewhere on this
> > thread
> >

> We already have a new CPS version, next week we will publish it, and a new
> version when it was RFC 3647 compliant.
>
> >

> > I'm not sure whether to track issues with the new hierarchy, so I will
> > simply note the following:
> > 2017-08-23 - Last issued certificate with invalid dNSName (
> >
> https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01
> > )
> > 2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
> > requirements that "CAs conforming to this profile MUST use either the
> > PrintableString or UTF8String encoding of DirectoryString, with two
> > exceptions" (
> https://crt.sh/?cablint=261&iCAID=50473&minNotBefore=2011-01-01 )
> >

> there is an open bug https://bugzilla.mozilla.org/show_bug.cgi?id=1443857
> where previous bug are treated.
>
> >

> > Notable is that Camerfirma includes the organizationIdentifier,
> > OID 2.5.4.97, in their certificates. This is documented in the CPS [5]
> from
> > the original message, within Section 3.1.1, with the validation process
> > described in 3.1.8.1. However, the CP/CPS lacks details as to the
> > construction and validation - it appears to be a construction of "VAT"
> > [member state] "-" [VAT number]
> >

> website certificates profile is defined in ETSI EN 319 412-4. This
> standard refers ETSI EN 319 412-1 where this OID is defined. VAT is as
> defined in CPS section 3.1.8.2.3
>
> >

> > In this, we see a pattern of issues, with a strong reliance on trusting
> RAs
> > (which included entities such as StartCom, known to not be validating
> > correctly) and, when failure detected, on technical controls. We see a
> > pattern of delayed remediation, misunderstanding of expectations in the
> > face of misissuance, and misunderstandings of the requirements
> themselves.
> > If there is any one remark that perfectly captures this, it would be
> found
> > in https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 , provided
> on
> > 2017-12-21 (i.e. after many of these issues)
> >

> We rely on our RA network and we train them and audit them for assure a
> correct validation. As a result of
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c30 technical
> controls were deployed to avoid misissuance, misunderstandings and reduce
> this dependency on trusting RAs.
>
> >

> > "AC Camerfirma is a small CA that uses an in-house developed CA software
> > and is supported by our RA trusted operators and the continuous training
> > they receive. AC Camerfirma has been working with this technology and
> staff
> > for 17 years without problems and we have dedicated a big effort
> improving
> > it along those years. Due to the number of TLS certificates issued on
> > previous years, this working method was appropriate and suitable for us.
> > The increase of certificates issued, increasing technical requirements
> and
> > the analysis of these reported problems have helped us to realize the
> need
> > to extend the technical controls in the CA application to cover all
> > possible and new requirements and introduce a new person in charge of
> > coordinating these implementations."
> >
> > I think it's problematic to suggest "without problems", and concerning
> that
> > it required a "big effort" to improving. It equally remains
> > problematic/concerning that the in-house CA software has continued to
> show
> > issues.
> >

> Creating a new root 2018 is unfeasible for us for the following reasons:
> •Root 2016 is already audited and incorporated into the European TSL based
> on the favorable evaluation of our national supervisor body for both the
> issuance of S/MIME, WEB and TSU certificates.
> •Root is already recognized by other comunities such as Microsoft and
> Adobe.
> •Root 2016 is already accredited in the Spanish public administration &
> Public Services.
> •And above all, because the problems found so far have not incorporated a
> significant risk to the user community and they have been solved by
> incorporating technical controls and specific resources that currently
> allow us to commit with the ecosystem requirements.

The path I provided ensures every one of those things continues to work.

Can you please elaborate more as to why it is unfeasible?

>

[ramiro...@gmail.com]

Hi Ryan

Sure, this could work for browsers validation, but our concern is about Web Certificates for Spanish Public administration.
Spanish Public Administration is AC Camerfirma main customer.
Additionally, Roots should be accepted by public administration validation services.

So, if we provide a new root 2018, first of all, we should pass a new eIDAS conformity assessment for the new roots and then send it to administration validation services to be accepted by each particular public service.
We have been working for month to be our root 2016 recognized by Spanish public services. We hope this could be improved in a future but nowadays is so complicated.

We have been waiting for Mozilla 2016 root inclusion for many years, and we have to going back to the starting point ?
Root 2016 are not having problems, we have issue only a few SSL certificates. It has nothing to do with StartCom, Have technical controls to avoid related problems found with RA validation and other, have no CPS problems.... I don't know how creating a new root 2018 can improve our trust for the community, in contrast, it will produce an economic damage and time consuming tasks for Camerfirma.

Regards
Ramiro

[Ryan Sleevi]

On Fri, Mar 23, 2018 at 1:12 PM ramirommunoz--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thursday, March 22, 2018 at 10:43:49 PM UTC+1, Ryan Sleevi wrote:

> Hi Ryan
>
> Sure, this could work for browsers validation, but our concern is about
> Web Certificates for Spanish Public administration.
> Spanish Public Administration is AC Camerfirma main customer.

Additionally, Roots should be accepted by public administration validation
> services.

And cross-signing covers this.

>
> So, if we provide a new root 2018, first of all, we should pass a new
> eIDAS conformity assessment for the new roots and then send it to
> administration validation services to be accepted by each particular public
> service.

This is not correct. Cross-signing the 2018 Root with the 2016 root allows
all services that support your 2016 root to continue to work without
disruption. From the point of view of clients, you’ve just added another
intermediate certificate.

> We have been working for month to be our root 2016 recognized by Spanish
> public services. We hope this could be improved in a future but nowadays is
> so complicated.

Yes, but the cross-signing of the 2018 root with the 2016 root will ensure
all the work you have done for 2016 is applied.

>
> We have been waiting for Mozilla 2016 root inclusion for many years, and
> we have to going back to the starting point ?
> Root 2016 are not having problems, we have issue only a few SSL
> certificates. It has nothing to do with StartCom, Have technical controls
> to avoid related problems found with RA validation and other, have no CPS
> problems.... I don't know how creating a new root 2018 can improve our
> trust for the community, in contrast, it will produce an economic damage
> and time consuming tasks for Camerfirma.
>

I’m afraid this statement is not correct, and it’s based on an unfortunate
understanding about what is being proposed - and how PKI works.

None of what you’ve described is required by what I have proposed here.


> Regards
> Ramiro

[ramiro...@gmail.com]

Hi Ryan

Thanks again for your remarks.
In the end I am going to learn something of PKI :-).
Surely I do not get a full understanding of you solution, but public administration is requiring a EU qualified Web certificate this means that should be included in the EUTL. I do know other solution for a new root but a new conformity assessment.

Nevertheless, let me insist. In which aspects a new root 2018 improve our trustworthiness instead of the current root 2016?

Best Regards
Ramiro

[ramiro...@gmail.com]

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

New versions of CPS are being published today in our WebSite.

http://www.camerfirma.com/en/area-de-usuario/jerarquia-politicas-y-practicas-de-certificacion/

CPS-EIDAS (2016 root) v 1.2.3
CPS (2003 2008 roots) v.3.3

Regards
Ramiro

[Wayne Thayer]

Hi Ramiro,

On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Ryan
>

> Thanks again for your remarks.
> In the end I am going to learn something of PKI :-).
> Surely I do not get a full understanding of you solution, but public
> administration is requiring a EU qualified Web certificate this means that
> should be included in the EUTL. I do know other solution for a new root but
> a new conformity assessment.
>

> If the "2016" roots are included in the EUTL, then they can be used to
sign ("cross-sign") a new "2018" root (or roots) that will then inherit the
trust from the "2016" root. From the perspective of the EUTL, the new root
would look like a new intermediate CA certificate.

Nevertheless, let me insist. In which aspects a new root 2018 improve our
> trustworthiness instead of the current root 2016?
>

> This is the wrong question to ask. For all the reasons stated in earlier
messages, the Mozilla community appears to have concluded that the 2016
roots are not trustworthy. If that is the case, then the proposal that you
create a new root answers the question that I think you should be asking:
"How can Camerfirma regain the community's trust?" Submitting a new root
that has been audited, has no history of misissuance, and complies in every
way with our policies has been proposed as one possible way to increase
confidence in your CA. If you have been following this mailing list, you
have seen that this same action has been recommended to other CAs that are
in this situation.


> Best Regards

[Adrian R.]

Hello
can you please sign the PDF files on that site?

the very first page of CPS_eidas_EN_v_1_2_3.pdf says
"Document valid only in digital format digitally signed by the Policy Authority"

but the PDF that i was offered to download is not signed and was delivered via a plain http link, are those working draft versions and not final?


I also looked at a few of the older/other versions published there:

CPS_EN_v_3_3.pdf - PDF not signed but that phrase is not present either.

CPS_eidas_v_1_2_1_EN.pdf - (april 2017) same phrase is present on the first page but the PDF file is not signed.

CPS_eidas_EN_v_1_1.pdf - (nov 2016) - signed PDF (and that phrase is not present)

~~~~
Adrian R.

[ramiro...@gmail.com]

On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote:
> Hi Ramiro,
>
> On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > Hi Ryan
> >
> > Thanks again for your remarks.
> > In the end I am going to learn something of PKI :-).
> > Surely I do not get a full understanding of you solution, but public
> > administration is requiring a EU qualified Web certificate this means that
> > should be included in the EUTL. I do know other solution for a new root but
> > a new conformity assessment.
> >
> > If the "2016" roots are included in the EUTL, then they can be used to
> sign ("cross-sign") a new "2018" root (or roots) that will then inherit the
> trust from the "2016" root. From the perspective of the EUTL, the new root
> would look like a new intermediate CA certificate.

Wayne, the EUTL do not include ROOTS, only SubCA. It doesn't works in this way. Our hypothetical new 2018 root should issue a SubCA for WEBSITE certificates and this SubCA should be included in the EUTL, previously we should pass a new conformity assessment and send it to our National Supervisor body..and so on.

>
> Nevertheless, let me insist. In which aspects a new root 2018 improve our
> > trustworthiness instead of the current root 2016?
> >
> > This is the wrong question to ask. For all the reasons stated in earlier
> messages, the Mozilla community appears to have concluded that the 2016
> roots are not trustworthy. If that is the case, then the proposal that you
> create a new root answers the question that I think you should be asking:
> "How can Camerfirma regain the community's trust?" Submitting a new root
> that has been audited, has no history of misissuance, and complies in every
> way with our policies has been proposed as one possible way to increase
> confidence in your CA. If you have been following this mailing list, you
> have seen that this same action has been recommended to other CAs that are
> in this situation.
>

Wayne, all issues stated are already resolved, Moreover actually 2016 root is not affected by those problems. That's why I do not see the difference between 2016 root and a new 2018 root.

Nevertheless We offer a "Point in time audit" over 2016 root in order to provide to the community a clear assurance that all technical controls are in place and fulfill the BR requirements. Previously, to start from a clean point, We offer as well to revoke all WebSite certificates issued under this root.

We think that this proposal should provide a similar situation that we would have if a new 2018 root were set up.

Regards
Ramiro

[ramiro...@gmail.com]

Hi Adrian
Thank you for your feedback.
Already signed and published.
We have cleaned the webpage with the last CPS for the sake of simplicity.
There is a historical CPS version inside the documents.
Best Regards
Ramiro

[Wayne Thayer]

On Wed, Mar 28, 2018 at 3:45 AM, ramirommunoz--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote:

> > Hi Ramiro,
> >
> > On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via
> dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > Hi Ryan
> > >
> > > Thanks again for your remarks.
> > > In the end I am going to learn something of PKI :-).
> > > Surely I do not get a full understanding of you solution, but public
> > > administration is requiring a EU qualified Web certificate this means
> that
> > > should be included in the EUTL. I do know other solution for a new
> root but
> > > a new conformity assessment.
> > >
> > > If the "2016" roots are included in the EUTL, then they can be used to
> > sign ("cross-sign") a new "2018" root (or roots) that will then inherit
> the
> > trust from the "2016" root. From the perspective of the EUTL, the new
> root
> > would look like a new intermediate CA certificate.
>

> Wayne, the EUTL do not include ROOTS, only SubCA. It doesn't works in this
> way. Our hypothetical new 2018 root should issue a SubCA for WEBSITE
> certificates and this SubCA should be included in the EUTL, previously we
> should pass a new conformity assessment and send it to our National
> Supervisor body..and so on.
>

> In that case, the new "2018" root(s) could be used to cross-sign the older
roots to provide a transition that allows your "2016" roots to be trusted
in Mozilla products until the "2018" SubCAs are added to the EUTL.

> >
> > Nevertheless, let me insist. In which aspects a new root 2018 improve our
> > > trustworthiness instead of the current root 2016?
> > >
> > > This is the wrong question to ask. For all the reasons stated in
> earlier
> > messages, the Mozilla community appears to have concluded that the 2016
> > roots are not trustworthy. If that is the case, then the proposal that
> you
> > create a new root answers the question that I think you should be asking:
> > "How can Camerfirma regain the community's trust?" Submitting a new root
> > that has been audited, has no history of misissuance, and complies in
> every
> > way with our policies has been proposed as one possible way to increase
> > confidence in your CA. If you have been following this mailing list, you
> > have seen that this same action has been recommended to other CAs that
> are
> > in this situation.
> >
>

> Wayne, all issues stated are already resolved, Moreover actually 2016 root
> is not affected by those problems. That's why I do not see the difference
> between 2016 root and a new 2018 root.
>

> Documented misissuance from the 2016 roots:
https://crt.sh/?caid=50473&opt=cablint,zlint,x509lint&minNotBefore=2011-01-01

Moreover, all of the CPS issues that I identified apply to the 2016 roots,
and many of the other issues - such as CAA failures - apply equally to
these roots. So why do you believe that the '2016 root is not affected by
those problems'?

[ramiro...@gmail.com]

Hi Wayne
Thank you again for your answer

I fully understand the proposed solution about 2018 roots but as I previously said some concerns arise, not only for timing issues, but also from unexpected behaviours in some environment (EUTL, Spanish Public Administration validation platforms...etc) that could have a significant impact in our certificate distribution, so if we can we would like to avoid this solution.

What about Camerfirma proposal:

1.- A complete revocation of any SSL certificate issued by 2016 root
2.- "Point in time" BR audit
3.- Start issuing certificates from a clean environment from 2016 root

This would be a quicker and good solution for us and we think this guarantee the community that everything is corrected and ok from this point on.

Best Regards
Ramiro

[westm...@gmail.com]

Hi, Ramiro.
But how will the problems persecuting your CA disappear, even if the root is sterile.

Andrew

[ramiro...@gmail.com]

Thank you Andrew for your comment.

We have already solve the problems located in this bug, and develop the technical controls that will avoid to be replicated in the future.

Our proposal is:

Revoke all certificates issued under this root. This is not strictly necessary since all live certificates under this root are correctly issued.

Provide a "point in time" BR audit to prove to the community that all control are placed to avoid new misissued certificates, and that this root fulfill BR requirement.

Finally starting to issue new certificates.

IOHO these actions can avoid to start a new root from the scratch.

I do know if this answer your question.

BR
Ramiro

[Tom Prince]

On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> I fully understand the proposed solution about 2018 roots but as I previously said some concerns arise, [...]


That is unfortunate for Camerfirma, but it is not Mozilla or this lists issue. While people have provided some suggestions on how you can create a root that *might* be acceptable, I don't think any of the participants care if Camerfirma has a root accepted; given the issues previously identified and the responses to those issues, I think a number of participants would be just as happy if Camerfirma doesn't get accepted.

>
> [...] A complete revocation of any SSL certificate issued by 2016 root [...]

There are at least a couple of problems with this
1. Revocation, while a useful tool to have, there are a number of issues surrounding it, including distribution of those revocations. Given that the root isn't currently trusted it doesn't make sense for Mozilla to start trusting it but also need to ship a bunch of revocations for mis-issued certificates from it.
2. Given the issues that have already occured with this root, there is going to be questions of whether all the certificates that it has issued are properly recorded, so that they can now be revoked. That is, given the existing issues, how can Mozilla be confident that all the certificates will be revoked. This is not a question of willingness, but rather capability to identify and revoke all the certificates signed by this root.

-- Tom

[Julian Inza]

I think the Camerfirma proposed solution is as acceptable as a new root with cross certification.

At the end, you trust on that specific CA either directly or through the cross certification mechanism.

Cross certification generates several problems for environments not based in browsers.

EU TSL (Trusted Service Status List) has been already been issued (this means the approval of a Supervisory Body). See also http://tlbrowser.tsl.website/tools/

Confomity Assessment Bodies audits have been carried out.

Shorter hierarchies are better maintained and generate less problems.

At the end we are dealing about how security and operational meassures are taken by a CA and how to demonstrate them to those with the power to withdraw the CA from a Trusted List.

These past years european legislation regarding qualified trust services has evolved to define the European Regulation UE 910/2014 (also known as EIDAS). With that unbrella, several technical standards have been published, among them EN 319 412 and EN 319 411. Those standards include requirements from "CAB Forum Baseline Requirements Documents" and "Extended Validation SSL Certificate Guidelines". Withs those standards, Conformity Assessment Bodies (CABs) audit certification authorities. CABs also are audited by National Accreditation Bodies and their Assessment Reports are analyzed by National Supervisory Bodies, which in turn can request additional inofmation before approving the qualified status and including the CA in the TSL.

This appears as an European-American confrontation.

Of course, any service can be improved, and Mozilla rules for CA inclusion in the Mozilla root program conforms a consistent verification framework.

But at the end, CABs also perform their duty harmonizing requirements from ETSI standards and CAB Forum requirements, to assess Certification Authorities which not only issue SSL certificates, but also natural person certificates for qualified electronic signatures, legal person certificates for qualified electronic seals, qualified electronic tiestamping, and other rlated trust services.

So, one of the critical poits would be to identify what CABs are not doing well when assessing CAs.

Because once CABs issue their Conformity Assessment Report stating thay some specific CA is complying with all requirements, the problem is not in the CA, is in the CAB.

Sorry for this long description of the European PKI Assessment model, but I thought it could be useful.

Best regards

Julián Inza

[Ryan Sleevi]

On Mon, Apr 2, 2018 at 11:02 AM, Julian Inza via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió:

> I think the Camerfirma proposed solution is as acceptable as a new root
> with cross certification.
>
> At the end, you trust on that specific CA either directly or through the
> cross certification mechanism.
>
> Cross certification generates several problems for environments not based
> in browsers.
>

Such as?

>
> EU TSL (Trusted Service Status List) has been already been issued (this
> means the approval of a Supervisory Body). See also
> http://tlbrowser.tsl.website/tools/

I fail to see the issue here. Does the EU TSL prevent the issuance of
intermediates? If not, then this is an entirely irrelevant point.

> Confomity Assessment Bodies audits have been carried out.
>
> Shorter hierarchies are better maintained and generate less problems.
>

I see nothing to support the claim that shorter hierarchies are better
maintained or generate less problems. The entire hierarchy is relevant to
trust, and if there is a question about a part of the hierarchy (for
example, the 2016 root), then it's necessary to excise those parts that are
problematic, to ensure a reliable starting point.

> At the end we are dealing about how security and operational meassures are
> taken by a CA and how to demonstrate them to those with the power to
> withdraw the CA from a Trusted List.
>
> These past years european legislation regarding qualified trust services
> has evolved to define the European Regulation UE 910/2014 (also known as
> EIDAS). With that unbrella, several technical standards have been
> published, among them EN 319 412 and EN 319 411. Those standards include
> requirements from "CAB Forum Baseline Requirements Documents" and "Extended
> Validation SSL Certificate Guidelines". Withs those standards, Conformity
> Assessment Bodies (CABs) audit certification authorities. CABs also are
> audited by National Accreditation Bodies and their Assessment Reports are
> analyzed by National Supervisory Bodies, which in turn can request
> additional inofmation before approving the qualified status and including
> the CA in the TSL.
>
> This appears as an European-American confrontation.
>

I don't think this is a particularly useful framing. Indeed, it sets an
unnecessary framing when, as others have pointed out, this approach has
been consistently applied to both WebTrust and ETSI audited CAs.

> Of course, any service can be improved, and Mozilla rules for CA inclusion
> in the Mozilla root program conforms a consistent verification framework.
>
> But at the end, CABs also perform their duty harmonizing requirements from
> ETSI standards and CAB Forum requirements, to assess Certification
> Authorities which not only issue SSL certificates, but also natural person
> certificates for qualified electronic signatures, legal person certificates
> for qualified electronic seals, qualified electronic tiestamping, and other
> rlated trust services.
>
> So, one of the critical poits would be to identify what CABs are not doing
> well when assessing CAs.
>
> Because once CABs issue their Conformity Assessment Report stating thay
> some specific CA is complying with all requirements, the problem is not in
> the CA, is in the CAB.
>
> Sorry for this long description of the European PKI Assessment model, but
> I thought it could be useful.
>

I don't think it's particularly useful or relevant to the matter at hand,
and doesn't provide new information as to the matters being discussed.

[ramiro...@gmail.com]

El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió:

> On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > I fully understand the proposed solution about 2018 roots but as I previously said some concerns arise, [...]
>
>
> That is unfortunate for Camerfirma, but it is not Mozilla or this lists issue. While people have provided some suggestions on how you can create a root that *might* be acceptable, I don't think any of the participants care if Camerfirma has a root accepted; given the issues previously identified and the responses to those issues, I think a number of participants would be just as happy if Camerfirma doesn't get accepted.
>

Hi Tom
I'm just trying to provide a different scenario than create a new root. Sure that many participants do not care about our particular situation:-(, but this make a big difference for us and also for our customers. If the only way to going forward is to create a new root, we will do it, but our obligation is trying to provide a more convenient solution for Camerfirma without jeopardize the trustworthiness of the ecosystem.

> >
> > [...] A complete revocation of any SSL certificate issued by 2016 root [...]
>
> There are at least a couple of problems with this
> 1. Revocation, while a useful tool to have, there are a number of issues surrounding it, including distribution of those revocations. Given that the root isn't currently trusted it doesn't make sense for Mozilla to start trusting it but also need to ship a bunch of revocations for mis-issued certificates from it.

I do know fully understand your comment. We would like to start from the beginning with this SubCA linked to the 2016 Root. We are talking about one hundred or less certificates. This SubCA is already placed in the EUTL that’s why we insist in this solution.

> 2. Given the issues that have already occured with this root, there is going to be questions of whether all the certificates that it has issued are properly recorded, so that they can now be revoked.

No problems are open with those certificates. They are all disclosed and CT logged.

> That is, given the existing issues, how can Mozilla be confident that all the certificates will be revoked. This is not a question of willingness, but rather capability to identify and revoke all the certificates signed by this root.
>

We offer an external “point in time” BR audit to prove that this situation has been reached.

> -- Tom

BR
Ramiro

[okaphone.e...@gmail.com]

On Monday, 2 April 2018 19:22:02 UTC+2, ramiro...@gmail.com wrote:
> El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió:
> > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> > > I fully understand the proposed solution about 2018 roots but as I previously said some concerns arise, [...]
> >
> >
> > That is unfortunate for Camerfirma, but it is not Mozilla or this lists issue. While people have provided some suggestions on how you can create a root that *might* be acceptable, I don't think any of the participants care if Camerfirma has a root accepted; given the issues previously identified and the responses to those issues, I think a number of participants would be just as happy if Camerfirma doesn't get accepted.
> >
>
> Hi Tom
> I'm just trying to provide a different scenario than create a new root. Sure that many participants do not care about our particular situation:-(, but this make a big difference for us and also for our customers. If the only way to going forward is to create a new root, we will do it, but our obligation is trying to provide a more convenient solution for Camerfirma without jeopardize the trustworthiness of the ecosystem.

Creating a new root by itself will not solve anything. The problem you have is with trust. It's up to you to offer a root that can be used as a trust anchor. Reasons why the 2016 root has become unsuitable for this have been discussed in detail.

The way out can be creating a new root, but that makes only sense if/when you are sure all problems have been solved and will not happen with the certificates that would be issued from this new root. If you are not 100% sure about this, the new root will most likely soon become as useless (for thrust) as the old one. Please don't do it before you are ready.

CU Hans

[ramiro...@gmail.com]

Thank Hans for your comments.

Completely agree with you about that a new root by itself do not solve the problem.

We have been working on those aspect detected by Wayne at the beginning of this thread. CPS issues, CAA issues..etc. So we think we are now ready to keep on with the root inclusion. Are we 100% sure ?, No one can assure that of their own systems, but we have placed controls to avoid the known problems, and detect the unknown ones.

The issue now is choosing the starting point.

1.- New root 2018

2.- 2016 root, after revoke all certificates (< 100 units) and pass an "Point in Time" BR compliant audit. (Camerfirma proposal)

3.- We have send two root to the inclusion process. "Chambers of commerce root 2016", this is the root which has issue a few(4) missunsed certificates https://crt.sh/?cablint=273&iCAID=50473&minNotBefore=2011-01-01, all of them revoked. But we have sent "Chambersign Global Root 2016" as well, and this root is free of issuing errors.

Our claim to the community is to use as starting point option 2 or option 3.

Best Regards
Ramiro

[okaphone.e...@gmail.com]

You still don't seem to understand. This is not about hoops you need to jump through to get your root included. It is about trust and it is entirely up to you to do whatever is needed to (re)gain that.

You won't get any "requirements" other than the ones you already know all about. Some people here may offer you advice they think will help you move forward with this. But if that doesn't suit you for one reason or another then that is just your choice, no problem. And if you do choose to follow somebody's advice, that doesn't imply your root will be included. It's just what they think is your best option. But as I said, creating a new root won't help you one bit if the problems have not been solved in a way that makes sure they won't happen again. Or if further problems will surface.

The bottom line is nothing more and nothing less than making it sufficiently plausible as a CA that the root you would like to see included is (and will stay) a suitable trust anchor. How you want to do that is your decision. The community will and can not make that decision for you. All they have for you is feedback (see above).

(Actually I have no idea why I'm telling you all this. You should already understand it as a CA. Anyway, just trying to help... ;-)

CU Hans

[Matt Palmer]

On Tue, Apr 03, 2018 at 05:19:32AM -0700, ramirommunoz--- via dev-security-policy wrote:
> Completely agree with you about that a new root by itself do not solve the problem.

The phrase you're looking for is "necessary but not sufficient". That is,
it is necessary to create new roots to restore trust, but not sufficient to
do so. You also have to demonstrate a high degree of competence in running
a CA, and understanding and responding to legitimate concerns.

> The issue now is choosing the starting point.
>
> 1.- New root 2018
>
> 2.- 2016 root, after revoke all certificates (< 100 units) and pass an
> "Point in Time" BR compliant audit. (Camerfirma proposal)

The problem with the 2016 roots is that there is no way to rehabilitate them
to the point that they will be as worthy of trust as new, fresh roots, for
several reasons.

Firstly, revocation is "fail open". Not every relying party checks
revocation information, and when the checks are made but they fail, it is
*usually* OK to continue, so user agents do so.

Revocation is the ejection seat of PKI. It's the option of last resort when
everything else has gone to hell, and you can only hope it does the job.
You don't build a crappy fighter aircraft whose wings fall off periodically,
and then justify it by saying "oh, it's OK, it's got an ejection seat". No,
you build the best 'plane you can, and you add the ejection seat as the
"well, it's *slightly* better than nothing" final option. Because they hurt
to use. A lot. And for various reasons they don't always work quite right.
But they give you a better chance of survival than a crash.

However, back to the point at hand: even if revocation were 100% reliable,
there's still the possibility of incomplete enumeration of certificates. I
cannot think of a way you could possibly prove that there is zero chance of
there being undisclosed certificates chaining to the old roots. New roots,
on the other hand, have that zero chance, because they're new, and have been
under effective audited control since day zero. So, again, new roots would
be more trustworthy than the old roots.

- Matt

[ramiro...@gmail.com]

Thanks for you help Hans

Regards
Ramiro

[ramiro...@gmail.com]

Thanks for your comments Matt

Regards
Ramiro

[Wayne Thayer]

Thanks everyone for your input. This discussion has reached the conclusion
that Mozilla should deny the inclusion request for the AC Camerfirma
CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT -
2016

As suggested, AC Camerfirma is welcome to submit a new inclusion request
for a newly generated root using a new key pair.

- Wayne