- 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.
We first became aware of the problem when this Bugzilla bug #1523680 was filed by Wayne Thayer on Jan 29, 2019.
- 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.
(all times below are GMT+1)
2019-01-29 18:01 We received notification via email that this bug was filed on Bugzilla.
2019-01-30 08:30 We started investigations on the raised issue. That included querying the involved OCSP responder for known and unknown certificates, reviewing the relevant sections of the Mozilla Root Store Policy and of the BR, and internal discussions on why the said OCSP responder was configured the way it was.
2019-01-30 15.30 We came to the conclusion that a change of configuration of the said OCSP responder was in order. Therefore a Change Request was filed into our internal configuration management system. The change was planned for next day early morning.
2019-1-31 08:30 The configuration of the said OCSP Responder was changed and the responder was immediately re-tested to make double-sure the change was effective.
- 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.
No certificate mis-issuance has occurred.
The OCSP responder's configuration was changed on Jan 31, 2019, at approx 08:30 (GMT+1) and the change was immediately effective.
- 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.
None (see point #3).
- 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.
Not applicable (see point #4).
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
It was our understanding that for the involved SubCA, since it only issues S/MIME certificates, the BR requirement <<MUST NOT respond with a "good" status for such [unknown] certificates>> was not applicable. After this bug was filed, we realized that our assumption was wrong, as we did not take into account the fact that such SubCA is not technically constrained.
- 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 addition to quickly correcting the configuration of the involved OCSP responder, an internal "awareness" meeting was held with the interested company departments aimed at clarifying that for any non-technically-constrained SubCA under our trusted Root, regardless of what kind of certificates it issues, the associated OCSP responder must be configured so as to never respond "good" for unknown certificates.