1733000 - QuoVadis: revocation services validity set to expected value plus one second

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Stephen Davidson]

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.

We’ve been following the bug posted by GTS (https://bugzilla.mozilla.org/show_bug.cgi?id=1731164), and have been investigating both the DigiCert and QuoVadis CAs. On 9/24, GTS informed us that the QuoVadis OCSP services were off by one second because of the inclusive requirement of the start time. QuoVadis OCSP responses are good for 48 hours, which is shorter than the requirement found in Baseline Requirements section 4.9.10. However, the QuoVadis CPS states the maximum validity period of an OCSP response is 48 hours. Because time is inclusive of the start and end time, all OCSP responses set to 48 hours in EJBCA were actually valid for 48 hours and 1 second. The same is true of our CRL service, with validity periods being 1 second longer than defined in the CPS.

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.

9/23 - Notified by GTS that our OCSP responses are 48 hours plus one second. We looked into the configuration and found that this is true. The CPS has strict language about the lifecycle of OCSP being limited to 48 hours, meaning the extra second is not accounted for in the CPS. We contacted PrimeKey and asked them to update their software to account for the 1 second issue. See https://jira.primekey.se/browse/ECA-10327. We updated the QV CPS to accurately describe revocation services timing.
9/24 - CPS approved by PMA and published.
TBD - Update to EJBCA 7.8.0.1 when available.

3. 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.

We have stopped issuing CRL and OCSP responses outside of the timeline specified in the QuoVadis CPS.

4. 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.

The SHA 256 fingerprints of impacted issuing CAs are attached.

5. 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.

The SHA 256 fingerprints of impacted issuing CAs are attached.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The CRL and OCSP settings in EJBCA are set at 72 and 48 hours respectively. It has been verified now that revocation service settings in EJBCA calculate the validity time as exclusive of start time, instead of inclusive. Validity period calculations were thought to have been fixed in a previous EJBCA update v7.4.3. This has proven incorrect for CRL and OCSP which require a configuration of the target time minus one second to be accurate. This misunderstanding of EJBCA settings carried over to the CPS when the setting was documented. We’ve updated our CPS to increase the maximum validity of OCSP to account for differences in time calculations between RFC 5280 and software implementations. We’ve confirmed that an updated EJBCA release for next month will modify the time calculations to match RFC 5280 and the CA/B Forum BRs. See https://jira.primekey.se/browse/ECA-10327.

7. 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’ve updated the CPS to ensure maximum times are accurate. We’ve also made it a policy to ensure maximum times are under the CA/B Forum requirements so any type of calculation issues are nonrelevant. The DigiCert CPS already reflects this approach. The QuoVadis CPS was updated to reflect this approach for OCSP and CRLs.

Comment 1

[Stephen Davidson]

Attachment: Issuing CAs affected by the "plus second" on revocation services

These issuing CAs were impacted by the "plus second" on revocation services beyond the target validity period defined in the CPS.

Comment 2

[Stephen Davidson]

This bug related to compliance with terminology used in our CPS, so the correction was to amend the CPS. Our settings for CRL and OCSP are well within the maximum validity periods specified in the BR requirements.
However the issue identified here may affect other CAs using EJBCA. As noted it will be corrected in the EJBCA versions noted in https://jira.primekey.se/browse/ECA-10327. We will, of course, routinely upgrade as versions are released.
We'll have no other updates on the substance of this bug.

Comment 3

[Ben Wilson]

Unless there are objections, I'll plan to close this matter on or about next Wed. 13-Oct-2021.