Open Bug 1583470 Opened 3 months ago Updated 2 months ago

Camerfirma: audit gap

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: ana.lopes, Assigned: ana.lopes)

Details

(Whiteboard: [ca-compliance])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763

Steps to reproduce:

We have tried to update our audits in the CCADB to close the case (00000435) but we have not been able to do it because of a 25-day gap between the two last audit reports.

We have covered the period until April 14th with the WebTrust audits performed in 2017 and the period for the year 2018 for Standard Audit, but we do not have covered the period between April 14th, 2018 and May 8th, 2018 for BR and EV SSL Audit.

The GAP between the two audits took place because two major non-conformities were detected during the audit. Due to the scheme of the eIDAS audit, we had to solve the nonconformities before obtaining the favourable report and the certification.

It is important to stand out that those major non-conformities were already solved before May 8th and that is why the auditors issued the certificate of compliance at that time.

  1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

We tried to update the audit information in the CCADB but we could not do that.

With Mozilla staff help, we discovered that this 25-day gap is the reason that we could not update our audits in CCADB. The related information appears in the case number 00000435.

  1. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

When we discovered the problem, we gave the details about the problem to Mozilla team. Finally, they recommend that we open an incident report with all the information about the non-conformities detected that did not permit to obtain the eIDAS certificate in time and provoked the 25-day gap between audits.

  1. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

The SubCA involved has never stopped issuing certificates because of this problem

  1. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Not applicable.

  1. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

We have tried to update our audits in the CCADB in order to close the case (00000435) but we have not been able to do it because of a 25-day gap between the two last audit reports.

We have covered the period until April 14th, 2018 with the WebTrust audits that took in place in 2017 for Standard Audit and for BR and EV SSL Audit.

In 2018 we decided to change the WebTrust audit and obtain the eIDAS certification for BR and EV SSL Audit to cover the requirements. eIDAS certification is based on the ETSI EN 319 411 and its requirements are different.

We have the report that covers the period since April the 14th, 2018 in the case of Webtrust for CA (for Standard Audit), but not for ETSI EN 319 411 (for BR and EV SSL Audit)

In the case of ETSI EN 319 411 (for BR and EV SSL Audit), the auditors found several non-conformities under eIDAS scheme and in this case, we had to solve the non-conformities before obtaining the favourable report and the certification.

The non-conformities detected were the following:

a) Test certificates (SMIME): Some not allowed types are included in ASN.1 structure (in paragraph 4.2.3 of ETSI EN 319 412-5, annex B -wrong ASN.1 structure for qcType field-).

b) QCP-n (SMIME): Some certificates have been found without CountryName in the subject, and some certificates for public workers has been issued without Surname neither Pseudonym.

c) QCP-l (SMIME): There are some TSA certificates with a eIDAS QCP-l-qscd OID (0.4.0.194112.1.3), but they miss the qcStatement qscd (QcSSCD) .

d) QCP-w (TLS): There are some certificates that not fit the EVCP profile. There were missmatches like: subject field without businessCategory, jurisdictionCountryName, organizationName, serialNumber neither localityName, which is required in EV 9.2

e) (TLS) Additionally, certificates with length 0 in some fields have been found.

  1. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We did not detect the problem until we tried to update the new audit information in the CCADB.

We started the audits in time, but the problem is that we could not avoid the GAP because of the non-conformities detected.

  1. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

All the non-conformities detected were solved even before we detected the gap problem with the CCADB. We had to take the appropriate measures to solve each of the non-conformities and obtain the eIDAS certification, so we elaborated a remediation plan to solve them:

a) Although Camerfirma received the audit report from AENOR (2010/1041/PSC/01) on March 23rd, 2018, AC Camerfirma already detected and solved this issue on July 14th, 2017.

b) Camerfirma first became aware after the reception of the audit report from AENOR (2010/1041/PSC/01) on March, the 23rd of 2018 and solved it on April 10th, 2018.

c) Camerfirma first became aware after the reception of the audit report from AENOR (2010/1041/PSC/01) on March, the 23rd of 2018 and solved it on April 10th, 2018.

d) Camerfirma first became aware after the reception of the audit report from AENOR (2010/1041/PSC/01) on March 23rd, 2018. After reviewing this issue, this problem was discussed with the auditors and it was determined that there wasn’t any error and the non-conformity was retired.

e) Although Camerfirma received the audit report from AENOR (2010/1041/PSC/01) on March, 23rd, 2018, AC Camerfirma already detected (March 7th, 2018) and solved this issue in March 2017. We opened a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1443857) with this issue. This bug was solved on May 17th, 2018.

Summary: Audit gap → Camerfirma audit gap
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: wthayer → ana.lopes
Whiteboard: [ca-compliance]

It's not surprising that there were issues detected; changing audit schemes represents a significant challenge for CAs, even when based on the Baseline Requirements. Even changing auditors can present challenges, as new perspectives bring new insight (and this is why it's good to regularly change auditors).

  1. Did Camerfirma anticipate there would be issues?
  2. Did Camerfirma perform any steps beforehand, such as obtaining an audit report under ETSI while still maintaining continuous audit coverage under WebTrust, to ensure any issues would be resolved?
  3. Did Camerfirma management discuss such a process? If so, what were the reasons it wasn't pursued for this case?

All of this seems like it should have been wholly anticipated, and so understanding the thought process, concerns, and mitigations that were performed are useful to help better understand why mistakes were made, so that we can better prevent them in the future.

Flags: needinfo?(ana.lopes)
Type: defect → task
Summary: Camerfirma audit gap → Camerfirma: audit gap

Hi Ryan,

Please, find the answer to your questions below:

  1. Did Camerfirma anticipate there would be issues?

Camerfirma did not anticipate there would be issues. We were not conscious about the problem and the auditors did not mention the possibility of the issue either.

This has been our first experience changing the scheme. Our goal is to optimize the management of the multiple audit processes.

We still have some CAs in the WebTrust environment in Latin America that we will try to change to the ETSI scheme as long as the national supervisors let us do it.

This experience will result very valuable for future cases.

  1. Did Camerfirma perform any steps beforehand, such as obtaining an audit report under ETSI while still maintaining continuous audit coverage under WebTrust, to ensure any issues would be resolved?

Camerfirma did not think about performing two audits in parallel to maintain continuous audit coverage under WebTrust at any moment because it would have resulted very expensive for us.

From our point of view the right solution would have been to begin the ETSI audit with enough time to solve any non-conformities that would have been detected so that we could solve the non-conformities by the deadline without any gaps.

  1. Did Camerfirma management discuss such a process? If so, what were the reasons it wasn't pursued for this case?

Camerfirma management did not discuss such a process because they were not conscious about the possible impact of the problem.

Flags: needinfo?(ana.lopes)
You need to log in before you can comment on or make changes to this bug.