Skip to content

Instantly share code, notes, and snippets.

View vanbroup's full-sized avatar
✔️

Paul van Brouwershaven vanbroup

✔️
View GitHub Profile
@aarongable
aarongable / ccadb-incident-report.md
Last active August 7, 2023 22:30
Draft proposal for overhauling the CCADB Incident Reporting Requirements (https://www.ccadb.org/cas/incident-report)

Incidents

Incidents happen. Things do not always go as planned, and that can be okay. However, when incidents occur, the underlying issue (i.e., root cause) should be identified and remediated to discourage the incident from occurring again. Formally documenting the incident in a report encourages an understanding of all contributing root cause(s), and it presents the opportunity to clearly communicate a remediation plan to reduce the probability of its reoccurrence.

Depending on the root programs in which a CA Owner participates, it may be required to:

These reports provide lessons learned and transparency about the steps the CA takes to address the immediate issue and prevent future issues. If the underlying problem goes unfixed, then other issues that share the same root cause will subsequently surfa

On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.

  1. Support for keeping a long-lived (disk) cache of OCSP responses.

    This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server