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.
SwissSign took notice of this issue as it was reported in 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.
- 20200506 14:16 CEST Email from @andrewayer.com is acknowledged by our mail gateway and is investigated by our Advanced Threat Protection
- 20200506 14:17 CEST The message is classified as potentially malicious and/or spam
- 20200507 07:55 PDT Opening of this bug
- 20200508 08:00 CEST SwissSign took notice of the this Bugzilla and validated the information
- 20200508 08:15 CEST The team responsible for firstname.lastname@example.org is contacted
- 20200508 10:00 CEST The mentioned mail has not been found in the mailbox. A search order is given to the IT department
- 20200508 10:30 CEST The mail has been found in quarantine. (see entry from 20200506)
- 20200508 14:15 CEST Further investigations indicate that the attached pem-file has been identified as a potential threat. This is the standard configuration of the cloud-based ATP.
- 20200508 19:15 CEST Reply to the Andrew
- 20200508 19:15 CEST Posting in Bugzilla
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.
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.
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.
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Our logs show that the added pem-file is most probably the reason why the mail has been classified as malicious. We did not have any knowledge of this mail therefore were not able to react accordingly.
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 are convinced that the configuration of our malware/spam protection is implemented according to current best-practices. We have no plans to change the current settings as it potentially lowers the safeguards for our company. However we are currently checking with the IT-department to delete pem-files and still send the rest of the mail to the info-inbox.