2073388 - SHECA: CP/CPS lacks explicit adherence statement

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[SHECA]

Preliminary Incident Report

Summary

• Incident description: SHECA TLS CP/CPS does not explicitly state adherence to the latest published version of the Chrome Root Program (CRP) Policy and the CCADB Policy. The current statement "For root certificates already included in the browser root store, compliance with the current root program shall be maintained." failed to independently reference the CRP Policy and the CCADB Policy. Additionally, the policies expect the CP/CPS itself, as the governing document, to declare adherence rather than limiting the commitment to only included root certificates. SHECA is preparing a corrected version and will publish it shortly.
• Relevant policies: Chrome Root Program Policy v1.8, Section 1.1.3; CCADB Policy v2.1, Section 4
• Source of incident disclosure: Third Party Reported.

Comment 1

[SHECA]

Hi, SHECA will publish the full report and the new version of CP/CPS soon.

Comment 2

[SHECA]

Hi, we have published the revised TLS CP/CPS. The original statement has been updated to:

This CP/CPS conforms to the latest published version of the Apple Root Certificate Program, the CCADB Policy, the Chrome Root Program Policy, the Microsoft Root Program Requirements, and the Mozilla Root Store Policy.

Meanwhile, we have identified that our S/MIME and Code‑Signing CP/CPS documents are also missing explicit adherence statements for the CCADB Policy. We have initiated their revision work.

Comment 3

[SHECA]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000261

• Incident description: SHECA TLS CP/CPS does not explicitly state adherence to the latest published version of the Chrome Root Program (CRP) Policy and the CCADB Policy. The current statement "For root certificates already included in the browser root store, compliance with the current root program shall be maintained." failed to independently reference the CRP Policy and the CCADB Policy. Additionally, the policies expect the CP/CPS itself, as the governing document, to declare adherence rather than limiting the commitment to only included root certificates.

  During subsequent incident investigation, we further identified that the S/MIME and CodeSigning CP/CPS documents also lacked the required explicit adherence statement for the CCADB Policy. All above‑mentioned gaps are reported within this full report, with corresponding coverage across timeline, root‑cause analysis and action items.

• Timeline summary:

  • Non-compliance start date: 2026-06-15 (Effective date of CRP v1.8)
  • Non-compliance identified date: 2026-09-16 (Third-party email received)
  • Non-compliance end date: 2026-09-28 (all CP/CPS revised and published)

• Relevant policies: Chrome Root Program Policy v1.8, Section 1.1.3; CCADB Policy v2.1, Section 4

• Source of incident disclosure: Third Party Reported

Impact

• Total number of certificates: 0
• Total number of “remaining valid” certificates: 0
• Affected certificate types: N/A
• Incident heuristic: N/A
• Was issuance stopped in response to this incident, and why or why not? No. The certificates issued were technically valid.
• Analysis: This was strictly a compliance violation of the CRP Section 1.1.3 and CCADB Policy Section 4 to explicitly state adherence to the latest published version of the policies.
• Additional considerations: N/A

Timeline

All times are UTC.

2026-02-05 16:57 Chrome Root Program Policy (CRP) v1.8 is published.

2026-02-26 06:30 The team completed the gap analysis for CRP v1.8 and noted the new requirements.

2026-03-20 18:43 CCADB Policy v2.1 is published and becomes effective, including a requirement to state adherence to the CCADB Policy in the CP/CPS by 2026-09-15.

2026-04-08 09:00 The team completed the gap analysis for CCADB Policy v2.1 and noted the new requirements.

2026-05-25 00:00 SHECA TLS CP/CPS v1.4, CodeSigning CP/CPS v1.1, S/MIME CP/CPS v1.1 take effect, with the statement: "For root certificates already included in the browser root store, compliance with the current root program shall be maintained."

2026-06-15 00:00 The Chrome Root Program Policy v1.8 requirement becomes effective.

2026-08-16 06:00 We identified multiple CAs with similar cases of missing CRP adherence statements by monitoring Bugzilla.

2026-08-17 13:00 Our compliance team re-assessed our CP/CPS and concluded that the existing text was not in violation but required improvement.

2026-09-01 02:00 We commenced a new round of CP/CPS revision work, including updating adherence statements for the latest policies.

2026-09-11 09:00 A draft of the revised CP/CPS was completed; finalization required subsequent review and approval.

2026-09-15 00:00 We missed the deadline of stating adherence to the CCADB Policy in the CP/CPS.

2026-09-16 13:36 We received a third-party email reporting this issue.

2026-09-16 14:00 We initiated incident investigation in accordance with our incident response SOP.

2026-09-17 02:25 We responded to the third-party email.

2026-09-18 08:05 We completed formal compliance analysis, confirming the non-compliance and applicable policy clauses.

2026-09-18 08:06 We published a preliminary incident report.

2026-09-20 00:00 SHECA TLS CP/CPS v1.5 becomes effective.

2026-09-23 09:15 Further investigation revealed that the S/MIME and CodeSigning CP/CPS also lacked the CCADB Policy adherence statement. We immediately initiated the revision and posted a comment under the case.

2026-09-28 00:00 The updated S/MIME and CodeSigning CP/CPS versions are published and take effect, non-compliance ended.

Related Incidents

Bug	Date	Description
https://bugzilla.mozilla.org/show_bug.cgi?id=2058261	2026-07-27	Like us, the CA failed to add the required attestations to their CP/CPS by the effective date.
https://bugzilla.mozilla.org/show_bug.cgi?id=2062418	2026-08-10	Like us, the CA failed to add the required attestations to their CP/CPS by the effective date.
https://bugzilla.mozilla.org/show_bug.cgi?id=2063908	2026-08-16	Like us, the CA failed to add the required attestations to their CP/CPS by the effective date.
https://bugzilla.mozilla.org/show_bug.cgi?id=2068900	2026-09-03	Like us, the CA failed to add the required attestations to their CP/CPS by the effective date.
https://bugzilla.mozilla.org/show_bug.cgi?id=2073779	2026-09-19	Like us, the CA failed to add the required attestations to their CP/CPS by the effective date.
https://bugzilla.mozilla.org/show_bug.cgi?id=2073583	2026-09-18	Like us, the CA failed to add the required attestations to their CP/CPS by the effective date.

Root Cause Analysis

The fundamental failure in this incident is that, despite SHECA identifying the explicit‑adherence requirements from CCADB Policy v2.1 and CRP Policy v1.8 during gap analysis, the CP/CPS wording failed to meet upstream policy specifications. Furthermore, required CP/CPS updates covering S/MIME and code‑signing document sets were not finalized prior to the CCADB Policy v2.1 compliance deadline. Three contributing factors led to this outcome: lack of a formal SOP for external‑policy‑to‑CP/CPS translation; fully‑manual external‑policy monitoring without automated tooling; and incomplete compliance‑milestone deadline management, absent of centralized ledgers and early‑warning controls.

Contributing Factor #1: Absence of standard SOP for external‑policy‑to‑CP/CPS translation, leading to inaccurate CP/CPS drafting

• Description: When converting external requirements from the CRP Policy and CCADB Policy into CP/CPS normative text, manual interpretation introduced wording deviations. The original statement used a generalised commitment language and tied the compliance obligation to root certificates included in browser root stores, rather than making the CP/CPS itself declare adherence to the root store policies as required. The clause failed to independently reference the formal names of the two policies, which did not meet the explicit statement requirement defined in CRP Policy v1.8 Section 1.1.3 and CCADB Policy v2.1 Section 4.

  To mitigate human interpretation errors in future policy translation work, SHECA plans to implement a formal SOP for external policy internalization (see Action Item 3 for details).

• Timeline: In this case, the wrong wordings in the CP/CPS were drafted by the compliance personnel in May 2026, but the SOP has not been in place historically.

• Detection: We detected this contributing factor through root cause analysis for this incident. Prior to this event, SHECA had maintained compliance with most Web PKI requirements, but the lack of standardized translation rules exposed risk of subtle wording misinterpretation when new CP/CPS attestation requirements were introduced.

• Interaction with other factors: This factor directly caused the substantive wording non-compliance found in the TLS CP/CPS. Even if deadlines were tracked well, insufficient standardization of policy translation would still create risk of invalid CP/CPS statements.

• Root Cause Analysis methodology used: 5 Whys

Contributing Factor #2: Lack of automated external policy tracking tool

• Description: SHECA’s existing workflow for external policy updates relies on manual monitoring. The team receives notification emails of upstream policy releases and organises cross-team meetings to summarise requirement changes. This fully manual tracking model introduces risks. In this incident, this manual limitation resulted in the adherence‑statement requirement not being extended to the S/MIME and Code‑Signing CP/CPS during the initial gap‑analysis and revision planning phase. Without automated cross‑document validation, granular per‑document requirements are prone to being missed, which amplifies risks introduced by policy‑interpretation gaps and weak deadline controls.
• Timeline: External policy monitoring has always been a manual control at SHECA.
• Detection: We detected this contributing factor through root cause analysis. Manual review worked adequately for major policy revisions in the past, but lacks robustness for catching granular clause requirements across multiple CP/CPS artefacts.
• Interaction with other factors: This factor amplified risks from both policy interpretation gaps and deadline management weaknesses. Manual tracking makes it easier to miss requirement details and overlook upcoming deadline milestones.
• Root Cause Analysis methodology used: 5 Whys

Contributing Factor #3: Inadequate management of compliance deadline milestones

• Description: SHECA did not maintain a centralized deadline ledger for external policy effective dates, so there was no formal early warning mechanism for upcoming compliance cutoffs. When the CP/CPS revision work was underway from the beginning of September, there was no established trigger to escalate and expedite the review, approval and publication workflow. As a result, the updated CP/CPS documents were not published before the CCADB Policy v2.1 effective date of 2026-09-15.
• Timeline: Compliance milestone deadlines were not systematically logged or centrally managed prior to this incident.
• Detection: We detected this contributing factor through root cause analysis. Previously, deadline awareness depended on individuals rather than a shared controlled register.
• Interaction with other factors: This factor turned the identified requirement gap into an overdue compliance breach. Even with correct policy interpretation, missing deadline controls would risk late delivery of required CP/CPS changes.
• Root Cause Analysis methodology used: 5 Whys

Lessons Learned

What went well:

• Our compliance personnel successfully identified the requirement to add adherence statements in the CP/CPS.
• Our monitoring of Bugzilla triggered an additional compliance assessment in August.
• We had initiated a new round of CP/CPS revisions prior to the incident, which included planned improvements to the policy adherence statements.
• During incident reporting, we further discovered that the CCADB Policy also applies to S/MIME and Code Signing CP/CPS; we promptly filed updates and launched revision work.

What didn't go well:

• We failed to accurately translate the upstream policy requirement into compliant CP/CPS wording.
• The additional compliance assessment contained a misjudgment: the team concluded that the existing CP/CPS was non‑violating and only required discretionary improvements, rather than identifying it as non‑compliant.

Where we got lucky:

• N/A

Additional:

• N/A

Action items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Update TLS, S/MIME and Code Signing CP/CPS documents with required adherence statements	Mitigate	Factor #1	All three CP/CPS documents are published.	2026-09-28	Complete
Perform additional review of CCADB Policy v2.1 and CRP v1.8	Mitigate	Factor #1	The review is completed.	2026-10-31	Ongoing
Develop SOP for external policy internalization: any upstream policy change will mandatorily trigger a CP/CPS self-assessment; the self-assessment output will be documented in a written report; a gap analysis will be performed item by item against the report findings; the compliance team will generate CP/CPS revision recommendations based on the gap analysis; revision proposals will undergo cross validation with AI-assisted review; and the final version together with supporting analysis materials will be submitted to the security certification committee for approval.	Prevent	Factor #1	The SOP is developed.	2026-10-31	Ongoing
Develop automated tracking tool for external policy updates. Functions: monitor external policy releases; summarize new requirements; perform gap analysis against CP/CPS	Prevent	Factor #2	The tool is developed and tested.	2026-12-31	Ongoing
Develop compliance deadline ledger with pre-defined alert triggers	Prevent	Factor #3	The ledger is developed.	2026-10-31	Ongoing

Appendix

N/A

Comment 4

[SHECA]

Action items are in progress.

Comment 5

[SHECA]

SHECA requests to set the next update date to 2026-10-31.

Comment 6

[SHECA]

Action items Update

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Update TLS, S/MIME and Code Signing CP/CPS documents with required adherence statements	Mitigate	Factor #1	All three CP/CPS documents are published.	2026-09-28	Complete
Perform additional review of CCADB Policy v2.1 and CRP v1.8	Mitigate	Factor #1	The review is completed.	2026-10-31	Complete
Develop SOP for external policy internalization: any upstream policy change will mandatorily trigger a CP/CPS self-assessment; the self-assessment output will be documented in a written report; a gap analysis will be performed item by item against the report findings; the compliance team will generate CP/CPS revision recommendations based on the gap analysis; revision proposals will undergo cross validation with AI-assisted review; and the final version together with supporting analysis materials will be submitted to the security certification committee for approval.	Prevent	Factor #1	The SOP is developed.	2026-10-31	Complete
Develop automated tracking tool for external policy updates. Functions: monitor external policy releases; summarize new requirements; perform gap analysis against CP/CPS	Prevent	Factor #2	The tool is developed and tested.	2026-12-31	Ongoing
Develop compliance deadline ledger with pre-defined alert triggers	Prevent	Factor #3	The ledger is developed.	2026-10-31	Complete