Closed Bug 1732745 Opened 2 months ago Closed 1 month ago

Certainly: Root CRL validity period exceeds maximum by one second

Categories

(NSS :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wthayer, Assigned: wthayer)

Details

(Whiteboard: [ca-compliance])

On 22-September 2021, Certainly reviewed bug #1731164 as part of a routine weekly compliance meeting. At this time it was recognized that Certainly’s two current root CRLs are valid from 1-April 2021 00:00:00 UTC to 1-April 2022 00:00:00 UTC. Further research was conducted and it was determined that these CRLs may not comply with BR section 4.9.7 which states that, “The value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.”

A full incident report is being prepared.

Assignee: bwilson → wthayer
Status: NEW → ASSIGNED
Whiteboard: [ca-compliance]

1. How your CA first became aware of the problem
On 22-September 2021, Certainly reviewed bug #1731164 as part of a routine weekly compliance meeting. At this time it was recognized that Certainly’s two current root CRLs are valid from 1-April 2021 00:00:00 UTC to 1-April 2022 00:00:00 UTC. Further research was conducted and it was determined that these CRLs may not comply with BR section 4.9.7 which states that, “The value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.”

2. A timeline of the actions your CA took in response.
4/1 Root CRLs issued as part of root key generation ceremony
9/22 20:30 UTC Discussed bug #1731164 and determined that Certainly may be affected by a similar issue
9/23 14:47 UTC Informed Certainly’s Policy Management Authority
9/23 21:35 UTC Initiated Incident Management process
9/23 22:50 UTC Informed our auditors
9/27 16:30 UTC Posted preliminary incident report
9/28 17:30 UTC Internal meeting held to identify root cause and remediation actions, and begin planning ceremony to issue replacement CRLs
9/29 18:00 UTC Team analyzed other potential date-related issues such as OCSP response lifetimes and publishing intervals. No additional date-related compliance issues were identified.
10/4 22:08 UTC Full incident report posted

3. Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident.
Certificate issuance was not stopped because this problem did not result in misissuance of any certificates.

This problem will be corrected prior to the next root CRL issuance ceremony.

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.)
Two CRLs were impacted, but no certificates were misissued.

5. In a case involving certificates, the complete certificate data for the problematic certificates.
Two CRLs were impacted, but no certificates were misissued.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
When we developed the profiles for our two current root CRLs, we followed past practices in interpreting the BR requirement for the nextUpdate field of a root CRL in terms of months. Specifically, we used an overly simplistic interpretation of the following language from section 4.9.7:

“The value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.”

This resulted in our first root CRLs being intentionally created and “valid” from 1-April 2021 00:00:00 UTC to 1-April 2022 00:00:00 UTC.

Similar certificate validity period errors have been reported in the past (e.g. bug #1667744), and in retrospect we should have been able to apply these lessons to OCSP responses and CRLs. It was not until the recent publication of bug #1731164, in which a similar problem with CRLs for end-entity certificates was reported, that we successfully identified the problem with our root CRLs.

In addition, while the validity period of a certificate is well defined in RFC 5280 section 4.1.2.5 as being “inclusive,” CRL validity periods are not defined. Only after reading bug #1731164, analyzing the BR language, revisiting the discussion on certificate validity periods, and applying the “default deny” principle were we able to conclude that the validity period was one second more than permitted.

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 believe that the Certainly compliance and incident management processes were effective in detecting and responding to this issue. We will continue to refine those processes and will remediate this issue as follows:

  • We will confirm that our OCSP responses are compliant (complete)
  • We will publish new fully compliant root CRLs by 1-November 2021
  • We will raise this issue with the CAB Forum Validation subcommittee by 4-November 2021. If there is agreement on the need to clarify the language, we will offer to draft the changes.
  • We will reduce our OCSP nextUpdate interval by one second for consistency.

We are also aware of the proposal to develop a CRL linter under the ZLint project (https://github.com/zmap/zlint/issues/458) and intend to follow that work and to begin using the linter to verify future CRLs.

This week's update:

  • We are currently on track to publish new root CRLs by 1-November.
  • We raised this issue with the CAB Forum Validation subcommittee last week and it was discussed (minutes). There was apparent consensus that the BRs should be clarified, so we drafted ballot SC52. We'll continue to help move this ballot forward.
  • We expect to reduce our OCSP nextUpdate interval in the next week.

This week's update:

  • We remain on track to publish new roots CRLs by 1-November.
  • We have addressed some of the feedback received on ballot SC52.
  • We have deployed and verified the change that reduces the validity interval of our OCSP responses by 1 second.

This week's update:

  • We remain on track to publish new roots CRLs by 1-November.
  • We have addressed all of the feedback received on ballot SC52 and expect the proposer to start the discussion period soon. (Certainly is only an Interested Party in the CAB Forum and as such may not introduce ballots)

This week's update:

  • Updated CRLs with a validity interval of 364 days were signed on 28-October and published in 29-October
  • We updated the validity interval ballot (SC52) based on a comment from the proposer

All remediation steps have been completed.

I will close this bug on or about Thursday, 4-Nov-2021, unless there are any questions or concerns.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.