- 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.
During gap analysis and impact assessment of the changes to the BR in the context of SC31 – Browser Alignment, we noted that our legacy platform, using EJBCA as issuance backend includes a SingleExtension with an empty SEQUENCE when no SingleExtensions are selected. This is not in compliance with RFC 6960 section 4.2.1 when read in conjunction with RFC 5280 section 4.1 which allows for SEQUENCE size 1..MAX
- 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.
|September 07 2020
||Noticed issue with response, requested further testing
|September 07 2020
||Further testing showed that issue appeared to have been introduced in version 7.3.0 of EJBCA and that in particular it appeared to have come from EJBCAs OCSP Archive Cutoff addition.
|September 08 2020
||Informed Primekey of issue who created https://jira.primekey.se/browse/ECA-9426 for bug fix
- 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.
N/A No certificates affected
If revocation is required, decision and rationale for delaying revocation. See "Timeline for revocation breached"
- 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, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
- In a case involving 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
In line with industry requirements have always kept our software up to date and do test all new releases from suppliers. However this particular issue was not spotted during this testing phase until now.
- List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
We have informed Primekey of this issue and are awaiting release of new version which will solve the issue. We did consider rolling back however we required latest version in order to be compliant with changes implemented in Ballot SC31 for new Baseline Requirements.
For testing new releases we have added a full asn1 comparison check of OCSP responses from before/after to our testing procedures when OCSP changes are implemented.