1838866 - SHECA: Failure to Respond to April 2023 Survey

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Chris Clements]

Section 9. Timely and Transparent Communications of the Chrome Root Program policy requires CA Owners respond to CCADB communications within 14 calendar days unless specified otherwise.

The “Google Chrome Root Program: April 2023 CA Owner Survey” CCADB mass email and survey was sent on April 24, 2023. CA Owners with certificates included in the Chrome Root Store were required to respond to the survey by June 9, 2023.

As of June 16, 2023, SHECA has not responded to the survey and an incident report is now requested.

Comment 1

[chenxiaotong]

Incident Report

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.

In June 16th SHECA was made aware of this problem via this Bugzilla.

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.

20230424 10:54 CST(UTC+8) “Google Chrome Root Program: April 2023 CA Owner Survey” CCADB mass email and survey have been sent to SHECA.
20230619 09:00 CST(UTC+8) SHECA is aware of this problem through Bugzilla notification.
20230619 10:00 CST(UTC+8) The investigation was initiated by Information Security & Compliance.
20230619 13:00 CST(UTC+8) SHECA began to prepare to fill out the survey.
20230619 19:18 CST(UTC+8) SHECA completed the survey and submitted it.

3.Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

CA has not stopped issuing certificates as this incident did not produce misissued certificates.

4.In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g., OCSP failures, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help measure the severity of each problem.
N/A

5.In a case involving TLS server certificates, 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 is also recommended that you use this form in your list “https://crt.sh/?sha256=[sha256-hash]”, unless circumstances dictate otherwise. When the incident being reported involves an SMIME certificate, if disclosure of personally identifiable information in the certificate may be contrary to applicable law, please provide at least the certificate serial number and SHA256 hash of the certificate. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
N/A

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

We regret that this survey was overlooked in the course of handling this incident. This is a management failure, and we should have been more careful in the job reassignment and handover process.
In fact, our attention was distracted during this period due to the reassignment of the personnel involved, and therefore we did not notice the survey in time. We acknowledge that this was an oversight on our part. After we became aware of the issue through Bugzilla bug, we took it stake it seriously and completed this survey immediately

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.

We launched an internal investigation immediately when we became aware of the issue through bugzilla, and quickly confirmed that the cause of the issue was due to the fact that we missed the survey because we didn’t update contacts in CCABD in time after the key person in charge was transferred.
By taking the following preventive measures, we will ensure that similar problems will not recur in the future.

1. We will develop clearer handover guidelines in the near future (expected within 1 month) to ensure that nothing is missed in the job reassignment and handover process. This will include detailed task lists, assignment of responsibilities and timelines to ensure a smooth handover process.
2. We have created a dedicated communication group to focus on similar issues. Several new colleagues have been added to the group compared to previous concerns, and there will be real-time communication and information exchange between our team members to ensure that such incidents do not occur again.
3. We will share informations by regular meetings, to ensure team members know the Root Program’s requires. If there are unexpected situations or special circumstances that require discussion of solutions, we will hold additional meetings as needed. These meetings are designed to facilitate communication and collaboration among team members in order to resolve issues and take appropriate action in time.

Comment 2

[chenxiaotong]

This incident report concludes our remediation of this bug.

Please let us know if there are any further questions or concerns about this bug.

Comment 3

[Ben Wilson]

Unless there are additional questions or issues to discuss, I believe this bug can be closed, and so I will schedule closure for Friday, 29-Sept-2023.