1649502 - Firmaprofesional: 2020 Audit Report Finding 1 out of 4

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[chemalogo]

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

Steps to reproduce:

Annual audit

Actual results:

Findings were found

Expected results:

An unqualified audit report

Comment 1

[chemalogo]

"We could not evidence that the CPS includes all required information regarding how revocation status information is made available beyond the validity period of the qualified certificates, including the period over which the revocation status information is made available; how the revocation status information is provided in the case of CA's key compromise or how the revocation status information is provided in the case of TSP termination."

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.

It is a finding identified in the annual eIDAS audit carried out in March 2020.

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

On 2020-04-14 13:43, this Non Conformity was registered in our JIRA (Ticketing System) and an action plan was established.
On 2020-04-16 16:09 The specific points of the ETSI and the obligations were studied.
On 2020-05-21 10:14 The different actions are detailed. Among the different technical and procedural options that exist it seems that the only viable one is the issuance of a lastCRL. This CRL will contain all the certificates that have been revoked during the lifetime of the CA, regardless of whether they are expired.

Once the different measures are deployed, the CPS will be updated.

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

It does not apply.

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

It does not apply.

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

It does not apply.

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

The certificate lifecycle management tool, EJBCA EE does not provide automated mechanisms that allow compliance with these requirements:
a) the period over which the revocation status information is made available;
b) how the revocation status information is provided in the case of CA's key commitment;
c) how the revocation status information is provided in the case of TSP termination (see clause 6.4.9);
On the other hand, mechanisms b) and c) have not been able to identify a technically feasible way that maintains confidence in the information published over time.

Additionally, it was thought that they were partially covered by the following clause of the Firmaprofesional Activity Cessation Plan:
2.4. Maintenance of information related to certificates

As indicated in the section "Service transfer", Firmaprofesional will try to reach an agreement with a Trust Service Provider to transfer its services and obligations. In the event that such agreement is not reached, the information will be notarized and be informed to the competent body (supervisory Body, pursuant eIDAS) in any case.

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

In July the company will define the process of the issuance of a last CRL and the CPS will be updated.

Comment 2

[Ryan Sleevi]

On 2020-04-14 13:43, this Non Conformity was registered in our JIRA (Ticketing System) and an action plan was established.

Could you explain why an incident was not reported until 2020-06-30? https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report encourages CAs to report as soon as they're aware of an incident.

In July the company will define the process of the issuance of a last CRL and the CPS will be updated.

We are now near the end of July and there have been no updates. Per https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed , the expectation was for weekly updates in the absence of further confirmation.

Comment 3

[Maria Jose Prieto]

• On 2020-04-14 13:43, this Non Conformity was registered in our JIRA (Ticketing System) and an action plan was established.

Could you explain why an incident was not reported until 2020-06-30? https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
encourages CAs to report as soon as they're aware of an incident.

This year the auditors did not send us the final report of the eIDAS Audit until June, due to the workload and the exceptional circumstances of the Covid-19. However, Firmaprofesional registered a ticket in Jira with this "Possible Non-Conformity" from the moment we learned of it with the first draft of the report, as a preventive measure

• In July the company will define the process of the issuance of a last CRL and the CPS will be updated.

We are now near the end of July and there have been no updates. Per https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed , the expectation was for weekly updates in the absence of
further confirmation.

Due to the recent update of several ICAs we have delayed the update until next week.

Comment 4

[Ryan Sleevi]

(In reply to Maria Jose Prieto from comment #3)

• On 2020-04-14 13:43, this Non Conformity was registered in our JIRA (Ticketing System) and an action plan was established.

Could you explain why an incident was not reported until 2020-06-30? https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
encourages CAs to report as soon as they're aware of an incident.

This year the auditors did not send us the final report of the eIDAS Audit until June, due to the workload and the exceptional circumstances of the Covid-19. However, Firmaprofesional registered a ticket in Jira with this "Possible Non-Conformity" from the moment we learned of it with the first draft of the report, as a preventive measure

This doesn't really answer my question at all, though. When you created a ticket in Jira, why weren't Mozilla and other root programs that have a disclosure requirement (such as Microsoft) notified? Why wait for the report to notify of a compliance issue?

We are now near the end of July and there have been no updates. Per https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed , the expectation was for weekly updates in the absence of
further confirmation.

Due to the recent update of several ICAs we have delayed the update until next week.

I mean, I guess that's technically "an update", but "we'll update next week" is... not particularly inspiring.

Comment 5

[chemalogo]

This doesn't really answer my question at all, though. When you created a ticket in Jira, why weren't Mozilla and other root programs that have a disclosure requirement (such as Microsoft) notified? Why wait for the report to notify of a compliance issue?

As you may know, during audits there are findings that become "non-conformities" in the final report and other that become "observations" or even improvement opportunities. This is why we waited until the final report,

We decided to do this because, in the end, yes, it is a non-conformity and in the end a compliance issue, but not a security risk issue.

I mean, I guess that's technically "an update", but "we'll update next week" is... not particularly inspiring.

This week we will update the CPS, with information on the mechanisms on how revocation status information will be made available beyond the validity period of the qualified certificates, including the period over which the revocation status information is made available; how the revocation status information will be provided in the case of CA's key compromise or how the revocation status information is provided in the case of TSP termination.

Comment 6

[chemalogo]

Find the last version of the Firmaprofesional CPS at: https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-200806-EN-sFP.pdf

The main page is: https://www.firmaprofesional.com/cps.

Changes are:

• Procedure for generating the last CRL in case of key compromise or termination of service. Section 4.10
• New versions of INFRAESTRUCTURA, CFEA, OTC and SIGNE subordinate CA certificates are added. Sub sections of 1.3.2 Certification Authority (CA)

Comment 7

[Ben Wilson]

Unless there are other questions or issues, I intend to close this bug on or about 17-Sept-2020 as the audit finding has been addressed in the CPS. On an unrelated matter, during my review I noticed that section 5.7.3 of the CPS does not include a statement that Firmaprofesional will notify Mozilla and other root stores immediately upon discovery of a key compromise or other similar vulnerability. Language to this effect should be added in the next version of the CPS.