Here is the incident report:
- 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 were alerted about this issue via the MSDP mail list on May 21:
- 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.
2019-05-21 15:30 Received notification of the problematic certificates
Reviewed request and verified the issue in these certificates.
2019-05-22 10:30:00 EST Revoked the certificates
2019-06-16: Released updated zlint with the new null parameter check to block any future attempts
We discussed the issue on the list and with PrimeKey and took a 2 pronged approach to resolving this:
a) Open a ticket with PrimeKey to have the CA updated. Currently it takes the parameters from the CSR and if those were not encoded properly (Encoded public key algorithm identifier MUST have NULL parameters), then the issued certificate will have issues
b) As a second independent check, we will use zlint once updated with the fix.
- 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.
Yes, we have not issued any additional certificates without the NULL since this incident was opened.
- 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.
We issued certificates with this issue between October 8th, 2018 and May 12, 2019. RSA encoded public key algorithm identifier MUST have NULL parameters, and these 8 certificates did not. See this as an example: https://crt.sh/?id=1257385456&opt=zlint
- 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.
This was a detailed encoding error within the certificates and we had assumed EJBCA addressed low level encoding issues like this.
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.
a) We updated our zlint preissuance check on June 16th to block any future requests.
b) The PrimeKey patch was released on June 20th and we're in the process of testing this update and we're planning to do the upgrade next week.