Further Improving the CCADB Policy and Incident Reporting Guidelines (FEEDBACK REQUESTED)
Ryan Dickson
Hi everyone,
Following the set of updates made to the CCADB Policy last June, the CCADB Steering Committee has collaborated on a set of updates to further clarify Root Store Operator expectations related to CCADB disclosures.
Updates are also planned for the CCADB Incident Reporting Guidelines (IRGs).
The set of proposed updates is available here (“clean” policy / IRG).
Change summary:
Policy
Clarify expectations for subordinate CA ownership disclosure.
Effective September 15, 2026, require additional disclosures within PKI policy documents to more clearly establish the scope and applicability of policy documents.
Clarify audit expectations for CAs serving time-stamping use cases.
Clarify expectations related to explanatory letter disclosures for delayed audit statements.
Encourage Qualified Auditors to review public incident reports and offer an opinion on incident handling and remediation.
For audit periods beginning on or after January 15, 2027, audit statements must disclose sampling methodologies.
Clarify CRL disclosure expectations. Specifically, this policy update considers a new field (i.e., "All Full CRL URIs for This Hierarchy") being added to the CCADB that will expect a a properly formatted JSON array for the complete set of distinct HTTP URLs appearing in the `crlDistributionPoints` extension of the unexpired certificates issued by that CA. CA Owners can expect separate standard CCADB Enhancement Request communications regarding the deployment of this field, which will occur before the updated policy becomes effective.
IRGs
Clarify that audit findings must be the subject of an incident report.
Describe how Qualified Auditors can be involved in the incident reporting process.
Highlight that CA Owners should request a nextUpdate date “whiteboard” label to align with the soonest Action Item.
Highlight how CA Owners may add additional data fields to incident report appendices.
These proposals should not be considered “final”, but instead a “work in-progress” that we hope to enhance through community contributions. We welcome community feedback on these proposed updates and recommendations by March 1, 2026. Please share your thoughts by replying to this email or, preferably, by suggesting edits directly on GitHub.
Thank you,
Ryan (on behalf of the CCADB Steering Committee)
Roman Fischer
Dear Ryan,
Thanks for the opportunity to comment on the draft.
We noticed the increase in scope to also cover Time Stamping. This is a significant change and will also require us to change the scope of our audits and internal controls. Can you help us understand the reasoning behind this major change?
Thank you
Roman
--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
public+un...@ccadb.org.
To view this discussion visit
https://groups.google.com/a/ccadb.org/d/msgid/public/CADEW5O88LBdGN4p06JR4RWdPdHAAt%2BNYAb879a_wS1LqUxbgKg%40mail.gmail.com.
Ryan Dickson
Hi Roman,
Thank you for reviewing the proposed CCADB Policy updates.
> We noticed the increase in scope to also cover Time Stamping. This is a significant change and will also require us to change the scope of our audits and internal controls. Can you help us understand the reasoning behind this major change?
Adding the “Time Stamping” trust purpose to the “Audit Disclosures” table in Section 5 was intended to close an unintended gap in the existing CCADB audit disclosure expectations.
Background:
Each CA certificate disclosed to the CCADB is associated with “derived trust bits.” For simplicity and as we standardize terminology across the CCADB and CCADB Policy with other ecosystem tools (like crt.sh) these are sometimes referred to as “trust purposes.” A general description of how those values are set in the CCADB is available here.
The CCADB Policy aims to describe common audit disclosure expectations for the trust bit values assigned to CA certificates by the CCADB. Today’s policy references Server Authentication, Client Authentication, Code Signing, and Secure Email.
The gap:
My understanding is that the Code Signing BRs establish third-party audit expectations for issuing certificates containing both the id-kp-timeStamping EKU and the CA/Browser Forum Reserved Certificate Policy Identifier for timestamping (2.23.140.1.4.2).
Since “Time Stamping” is not listed in the audit disclosure table within Section 5 of the CCADB Policy, it could be interpreted to mean that for a PKI Hierarchy that only issues timestamping certificates (i.e., does not also have the Code Signing trust bit assigned), there are no CCADB audit disclosure expectations.
Expectations:
We expected the following outcomes from the change.
For CA certificates…
…with the Time Stamping trust purpose and issuing time stamping certificates, we’d expect they are already following the Code Signing BR audit expectations. This change now promotes improved transparency of those audit statements by ensuring their disclosure.
…with the Time Stamping trust purpose but not issuing time stamping certificates, we’d expect this change to highlight this point and result in the CA Owner requesting the removal of the unused trust purpose from the “granting” Root Store Operator. If the CA Owner wishes to retain the trust bit, they’d need to ensure the relevant audit expectations are satisfied.
…without the Time Stamping trust purpose, no change.
Specific to SwissSign, we do not see any CA certificates disclosed to the CCADB that contain the “Time Stamping” trust purpose. Can you help us better understand how this update would result in new changes to your audit scope(s) and internal controls?
Thanks,
Ryan
Roman Fischer
Dear Ryan,
My remark was not tailored to SwissSign as we don't provide code signing certificates/services. It was just to understand the change in scope. Your explanation was very clear and detailed and I now understand where the gap was that this change closes. 👍
Thanks a lot & kind regards
Roman
大倉惇
Hello Ryan,
We would like to inquire about the "Can Auditors participate in the reporting process?" field being added to the Incident Reporting Guidelines (IRGs).
Could you please confirm if the "auditor participation" required for this field is satisfied by complying with the following new requirement under CCADB Policy "5.2 Audit Statement Content"? Specifically, we understand this to mean including the auditor's review of incident reports in the annual audit statement as described below:
13. All incidents disclosed by the CA Owner, or reported by a third party, and all findings reported by an auditor, that, at any time during the audit period, occurred, were open in Bugzilla, or were reported to a Root Store Operator. For each, auditors SHOULD review the publicly-disclosed incident reports for consistency with audit evidence obtained and indicate whether (a) the scope, impact, and root cause are accurately and fairly described; and whether (b) the corrective actions described by the CA Owner are aligned with the factors that led to the incident and are intended to mitigate the risks associated with the identified root cause(s).
If our understanding is incorrect, we would appreciate it if you could provide further clarification on what is expected for this requirement.
Best regards,
Jun, Cybertrust Japan