1610448 - Firmaprofesional: 2019 audit Finding #1 - 6.2 Identification and Authorization

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[chemalogo]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

An external eIDAS and ETSI audit

Actual results:

This finding was found

Expected results:

To get a non-qualified audit report

Comment 1

[chemalogo]

It has been verified that, although the web application enables the revocation of certificates and prompt registration of the requests, in the rest of the cases (e.g. requests for revocation by email, telephone, etc.) no record of revocation request is kept. As a result, we could not find evidence that the status information of certificates is changed in less than 24 hours since a revocation request is received.
In addition, as indicated by the TSP, in some cases (e.g. request revocation by telephone) there is no explicit check to ensure the request revocation is originated by an authorized person. However, the TSP has stated that no cases of non-authorized revocation have happened during the audit period.

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.

Due to last eIDAS audit carried out in March 2019, it was identified that the revocations of certificates which were not carried out through web, were not supported by evidences. Despite the fact that there were not evidences of the revocations being revoked in less than 24 hours, they were carried out correctly.

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 2019-05-19 19:45, this Non Conformity was registered in our JIRA (Ticketing System) and an action plan was established in which it was defined the obligation of establishing a revocation process.

On 2019-10-11 13:44, The Revocation process was defined by Firmaprofesional’s COO in which all the revocations must be registered in our JIRA system, regardless if they are made through mail, telephone ...

Due to that, the revocation management time, the applicant and the entire process are recorded accurately.

In order to ensure that the revocation is requested by an authorized person, the revocation must be requested through the mail that appears on the certificate or with the certificate revocation number.

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.

Since October 14th, 2019 the new revocation process has been implemented in the Company.

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

In mid-2018, a migration was made to the Ticketing Management System used by the operations department, moving from OTRS to JIRA. The revocation management process was not fully migrated to the JIRA system, so although the revocation is made within the stipulated period, this cannot be evidenced in all cases.

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

Since October 14th, 2019 the new revocation process has been implemented in the Company.

Comment 2

[Ryan Sleevi]

Thanks for filing this.

I think one of the things that's important is understanding how this came to be, not just that it was resolved. While it's good to hear it was resolved, did Firmaprofesional ever track these issues? Was there a design decision as part of the migration (from OTRS to JIRA)? Was this examined in previous audits? Understanding when this issue was introduced, how it came to be, and how it went undetected, seems useful to understanding how to systemically prevent such issues, and not just track the resolution.

Comment 3

[chemalogo]

From Firmaprofesional we utterly agree with your point of view.

As stated previously, this came to be in the following way: in mid-2018, a migration was made to the Ticketing Management System used by the operations department, moving from OTRS to JIRA. The revocation management process was not fully migrated to the JIRA system, so although the revocation is made within the stipulated period, this cannot be evidenced in all cases.

We had evidence while we were using OTRS, we have evidence also now with JIRA and we do not have evidence during the transition period.
I think that it is important to remind that the finding is the lack of evidence during a specific period of time, not that the change of status information of certificates has taken more than 24 hours since a revocation request is received.

The decision of changing from OTRS to JIRA was a strategic decision of moving some services to the cloud, using market leaders in its areas.

Comment 4

[Ryan Sleevi]

Wayne: I don't have further questions.

Comment 5

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.