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.
On August 1, during an investigation into Bugzilla # 1567061, we uncovered 2 certificates that were not disclosed to CCADB.
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.
August 1, 10am (AZ time) In response to Bugzilla # 1567061, we began a process of cross referencing all our internal and external documentation to confirm we had accurate reporting. The documentation we examined included the CP/CPS and audit reports for 2018 for each root, intermediate and cross certificate operated by Starfield.
August 1, 11am – Noon (AZ time) We worked with our Webtrust Auditor to ensure the cross certificates mentioned in the bug would be included in Appendix A on our 2019 report.
August 1 – August 5 We realized we did not include cross referencing the CCADB and added this to the project. It was at this time we became aware of 2 cross certificates that potentially were not disclosed to CCADB.
August 6 We verified our cross referencing was correct and that we are indeed not reporting these 2 certificates as required, prepared this incident report and engaged Starfield Governance and Policy Committee for incident review.
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.
This particular incident did not contain any certificate problems that would require stopping issuance.
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.
Issued Not Before: Jan 1 07:00:00 2014 GMT
Issued Not Before: May 3 07:00:00 2011 GMT
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.
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
We simply do not have a good explanation for how this was originally missed, but are working on our policies and practices to ensure such issues do not occur again in the future. Since learning that it was not reported we have a high degree of confidence in the robustness and completeness of our current scans.
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 have completed a thorough review of all certificates listed in our CP/CPS, our audit report and CCADB. This list has been cross referenced with certificate information pulled directly from our data store to ensure accuracy. This exercise allowed us to see where our both our external and internal documentation could improve to provide clarity and consistency. We are working to update both the CCADB and our audit reports.