Open Bug 2011430 Opened 4 months ago Updated 1 month ago

D-Trust: Delayed publication of audit attestation letters in the CCADB

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: ana-laura.martorano, Assigned: ana-laura.martorano)

Details

(Whiteboard: [ca-compliance] [audit-delay] Next update 2026-10-02)

Preliminary Incident Report

Summary

  • Incident description: D-Trust did not upload the required Audit Attestation Letter(s) to the CCADB within the CCADB Policy deadline of 92 calendar days after the end date of the audit period. The 92-day deadline expired on 2026-01-07, and the Audit Attestation Letter(s) were uploaded to the CCADB on 2026-01-19.

  • Relevant policies:

  • CCADB Policy v2.0 (effective 2025-07-15), Section 5.2 “Audit Statement Content”,

  • Chrome Root Program Policy, v1.7 (effective 2025-07-15), Section 2 “Common CA Database”,

  • Apple Root Certificate Program (effective 2023-08-15),

  • Mozilla Root Store Policy v3.0 (effective 2025-03-15), Section 3.1.3 “Audit Parameters” and

  • Audit Requirements - Microsoft Trusted Root Certificate Program, Section D. “The Time Period Between the Assessment and the Auditor's Attestation”

  • Source of incident disclosure: Self-reported

Assignee: nobody → ana-laura.martorano
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance] [audit-delay]

It is noted in the four audit reports (Standard, BR, EV, and S/MIME), uploaded within CCADB Add/Update Root Request #2916, that the initial versions of those audit reports (version 1) were issued on 2025-12-10 and that versions 1.1 (except the S/MIME audit report) were issued on 2025-12-16 to correct a missing citation to the EV Guidelines for Root 2. The final version was issued on 2026-01-15 to correct typos (i.e. wrong date for CSM PKI CPS and Bug #1896190 was mentioned for the wrong Root CA).

When an audit report is not provided in a timely basis, policy dictates that the auditor provide an explanation. Section 5.2 of the CCADB Policy states, "An authoritative English language version of publicly available audit information MUST be uploaded to the CCADB no later than 92 calendar days from the point-in-time date or the end date of the period of time. In the event of a delay greater than 92 calendar days, the CA Owner MUST provide an explanatory letter signed by the Qualified Auditor."

In order to comply with this requirement, D-Trust must now obtain and provide an explanatory letter from its auditor, TÜV NORD CERT GmbH.

D-Trust should have filed notice of the reports in the CCADB in December, when they were initially received/issued, and then it should have communicated with CCADB Support if and when it foresaw problems that would require an amendment or re-issuance of the audit reports.

D-Trust is expected to improve its internal processes to ensure that future audit reports are promptly obtained, that they are filed upon issuance, and that CCADB Support is proactively engaged when amendments or re-issuance are anticipated.

Thank you for the comment. We have noted this.

We are in contact with our auditor to submit the Audit Attestation Letter(s).

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000022

  • Incident description: D-Trust did not upload the required Audit Attestation Letters (AALs) to the CCADB within the CCADB Policy deadline of 92 calendar days after the end date of the audit period.
    The audit period ended on 2025-10-07, the 92-day submission deadline expired on 2026-01-07, and the Audit Attestation Letters were uploaded to the CCADB on 2026-01-19.

  • Timeline summary:

    • Non-compliance start date: 2026-01-07
    • Non-compliance identified date: 2026-01-13
    • Non-compliance end date: 2026-01-19

  • Relevant policies:

    • CCADB Policy v2.0 (effective 2025-07-15), Section 5.2 “Audit Statement Content”
    • Chrome Root Program Policy, v1.7 (effective 2025-07-15), Section 2 “Common CA Database”
    • Apple Root Certificate Program (effective 2023-08-15)
    • Mozilla Root Store Policy v3.0 (effective 2025-03-15), Section 3.1.3 “Audit Parameters” and
    • Audit Requirements - Microsoft Trusted Root Certificate Program, Section D. “The Time Period Between the Assessment and the Auditor's Attestation”

  • Source of incident disclosure: Third Party reported

Impact

  • Total number of certificates: N/A
  • Total number of "remaining valid" certificates: N/A
  • Affected certificate types: N/A
  • Incident heuristic: (2) This incident didn't affect any certifcates.
  • Was issuance stopped in response to this incident, and why or why not?: No, no certificates were affected.
  • Analysis:
  • Additional considerations:

Timeline

2025-07-17: Evaluation plan agreed between D-Trust and the auditor
2025-09-29: First day of the on-site evaluation
2025-10-07: Audit period end
2025-11-26: Attestation draft provided by the auditor to D-Trust
2025-11-27: D-Trust provided comments and requested minor corrections and clarifications
2025-12-02: Last day of the on-site evaluation
2025-12-10: First version of the Audit Attestation Letters issued and published by the auditor
2025-12-10: D-Trust identified missing EV Guideline citation and reported it to the auditor
2025-12-16: Updated versions of the Standard, TLS-BR and TLS-EV Audit Attestation Letters issued
2025-12-17: D-Trust reported additional issues, including typographical errors, incorrect references, and questioned the distribution of TLS-only Roots D-TRUST Root Class 3 CA 2 2009 and of D-TRUST Root Class 3 CA 2 EV 2009 in the S/MIME attestation
2026-01-05: Auditor returned from previously scheduled vacation; mandatory professional training followed
2026-01-07: CCADB submission deadline expired (92 days after audit period end)
2026-01-12: Auditor and D-Trust resumed discussions; it became apparent that the AALs had not yet been uploaded to the CCADB
2026-01-13 12:02 UTC: Notification received from the CCADB indicating that the submission timeframe had been exceeded
2026-01-15: Final Audit Attestation Letters issued, including S/MIME audit coverage aligned with CCADB disclosure state
2026-01-19: Audit Attestation Letters uploaded to the CCADB
2026-02-03: Distribution of the explanatory letter by the auditor, TÜV NORD CERT GmbH, to the root store providers

Related Incidents

Bug Date Description
https://bugzilla.mozilla.org/show_bug.cgi?id=1843265 2022-07-13 Delayed audit statements for intermediate CAs
https://bugzilla.mozilla.org/show_bug.cgi?id=1911335 2024-08-02 Delayed S/MIME audit report
https://bugzilla.mozilla.org/show_bug.cgi?id=1917224 2024-09-06 Delayed Annual Audit Report
https://bugzilla.mozilla.org/show_bug.cgi?id=1945197 2025-01-31 Late receipt and disclosure to CCADB of ETSI audit letters
https://bugzilla.mozilla.org/show_bug.cgi?id=2008260 2025-12-31 Delayed audit disclosure

Root Cause Analysis

Contributing Factor #1: Insufficient audit scope alignment

  • Description: At the time of the audit, there was no formally established audit mechanism to explicitly validate CCADB metadata against the intended technical audit scope prior to the
    Audit Attestation Letter (AAL) review and finalization phase. As a result, discrepancies between publicly disclosed CCADB metadata and the CA’s TLS-only issuance practice
    were identified during the AAL review phase, requiring additional clarification and decision-making late in the process.
  • Timeline: 2025-09-29 - 2026-01-15
  • Detection: Review of the Audit Attestation Letters
  • Interaction with other factors:
  • Root Cause Analysis methodology used: 5-Why Analysis

Contributing Factor #2: Insufficient submission governance and resource allocation

  • Description: The submission governance process did not sufficiently account for external dependencies such as auditor availability and extended reconciliation cycles
    once additional changes were identified. In addition, no explicit escalation mechanism existed to prioritize CCADB submission deadlines over continued document refinement.
  • Timeline: 025-10-07 to 2026-01-19
  • Detection: Identified after receipt of the CCADB notification indicating that the submission timeframe had been exceeded.
  • Interaction with other factors:
  • Root Cause Analysis methodology used: 5-Why Analysis

Lessons Learned

  • What went well: Once the missed CCADB submission deadline was brought to our attention through an external CCADB notification,
    the issue was promptly analyzed in coordination with the auditor, and the Audit Attestation Letters were finalized and uploaded without further delay.
  • What didn’t go well: Audit scope alignment with CCADB disclosures and explicit verification of CCADB upload status were not sufficiently formalized early in the audit cycle,
    which allowed the deadline risk to remain undetected until after the submission timeframe had elapsed.
  • Where we got lucky: We identified the issue ourselves and corrected it in the same day.
  • Additional:

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Introduce Audit CCADB capability “pre-flight” check Prevent Root Cause # 1 Documented validation of CCADB scope against audit scope 2026-11-01 (Next audit cycle) Planned
Define explicit CCADB submission escalation incl. deadline monitoring Prevent Root Cause # 2 Escalation path documented and tested 2026-02-18 Planned
Investigate and resolve CCADB S/MIME capability metadata discrepancy Prevent Root Cause # 1 CCADB metadata accurately reflects designed issuance capabilities Open Ongoing

Appendix

Below is the explanatory Letter regarding late audit attestation letter provision for D-Trust GmbH sent by our auditor to the following recipients: certificate-authority-program@apple.com; ciscopki-public@external.cisco.com; chrome-root-program@google.com; msroot@microsoft.com; certificates@mozilla.org on 2026-02-03.

Dear Madams and Sirs,
Dear Root Store Managers,

this is to inform you about the delay in the provision of D-Trust's Audit Attestation letters.

https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_Standard_Audit_V1.2.pdf
https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_TLS-BR_Audit_V1.2.pdf
https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_TLS-EV_Audit_V1.2.pdf
https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_SMIME-BR_Audit_V1.1.pdf

We issued a first version of the AALs on 2025-12-10 and an updated version of the Standard, TLS-BR and TLS-EV Attestation on 2025-12-16. Both dates were well before the submission deadline. We didn't realize that the AALs had not been made available to CCADB at that time. D-Trust's later request for additional changes collided with the planned absence of the responsible auditor and resulted in the late issuance of the final versions of the four AALs on 2026-01-16.
It turned out that a difference between CCADB settings and actual usage, namely TLS-only Roots being listed as SMIME-capable, resulted in CA-internal discussions about how to proceed and a corresponding delayed change request to the auditor.

Detailed Timeline:
2025-07-17: Evaluation plan agreed between D-Trust and the auditor
2025-09-29: First day of the on-site evaluation
2025-10-07: Audit Period End
2025-11-26: Attestation draft provided to D-Trust
2025-11-27: D-Trust commented the draft and requested some minor corrections and clarifications
2025-12-02: Last day of the on-site evaluation
2025-12-10: Version 1.0 of the AALs was issued and published on our website
2025-12-10: D-Trust reports that the citation of the EV Guidelines has been omitted for one of the Root CAs.
2025-12-16: An update of the AAL was issued and published on our website.
2025-12-16 EOB: The responsible auditor leaves for his planned Christmas vacation.
2025-12-17: D-Trust reports additional issues with the AAL, namely a typo at the validity date of the CSM-CPS (2025-11-25 instead of 2025-11-24) and bug 1896190 that was listed for Root CA D-TRUST Root Class 3 CA 2 2009 instead of D-TRUST Root Class 3 CA 2 EV 2009. In addition, D-Trust questioned the distribution of the Roots over the different AALs, namely the mentioning of TLS-only Roots in the SMIME attestation.
2026-01-05: The auditor returns from his planned vacation and receives the D-Trust e-mail from 2025-12-17. As he is out of office for the whole week due to yearly mandatory professional update trainings and as the requested changes had been understood as minor corrections, he postpones the corrections to the next week. At this time the auditor does not realize that the AALs have not yet been provided to CCADB, despite being available on the auditors website.
2026-01-07: CCADB submission deadline ends (92 days after audit period end)
2026-01-12: The auditor returns to the office and engages in discussions with D-Trust about the necessary corrections. At this time he learns that the AALs had not been made available to CCADB and hence that to submission deadline has been missed.
2026-01-15: Another update of the AAL was issued. The typos have been corrected. It was agreed that the questioned root distribution was not to be changed, as it was closely aligned to the settings in CCADB. According to the auditor's experience, a change in the distribution would have resulted in AAL validation errors.
2026-01-19: Updated AALs were published on our website.
2026-01-19: AALs have been provided to the CCADB.

Although we were under the impression that a first draft had been provided for review early in the process, it turns out that CAs need much more time for a thorough review of provided drafts than we had anticipated. For the future, we intend to provide at least the fixed parts of the attestation content like PKI hierarchy and the foreseen distribution of the Roots in the different AAL versions according to the CCADB settings even earlier to give CA's enough time for review.

Best regards

Matthias Wiedenhorst

[In response to Comment 5.]

Thank you for helping the community pilot new expectations described in the draft CCADB Policy update.

Looking at D-Trust’s audit statements, we have two observations we’d like to better understand.

(Q1): The most recent audit statements (e.g., 1 and 2) describe an audit period of 2024-10-08 to 2025-10-07.

The attestation goes on to state: “The audit was based on the following policy and practice statement documents of the CA / TSP”, which then references:

  • Certificate Policy of D-Trust GmbH, version 5.7 as of 2025-11-13, D-Trust GmbH, valid from 2025-11-13
  • D-TRUST Trust Service Practice Statement (TSPS), version 2.7 as of 2025-11-13,
    D-Trust GmbH, valid from 2025-11-13
  • Certification Practice Statement of the D-TRUST CSM PKI, version 4.9 as of 2025-11-24, valid from 2025-11-24, D-Trust GmbH

These referenced policies were published a month after the audit period ended. Can you please help us understand this discrepancy?

(Q2): Given the same audit references described above, we understand D-Trust had multiple policies in effect over the audit period (e.g., this TSPS (2024-12-18) and this TPSPS (2025-06-30)).

Can you please explain (a) whether the Qualified Auditor assessed the operational practices using the actual in-force policies (rather than the single version listed) and (b) if so, why they are not explicitly referenced in the attestation letters?

Flags: needinfo?(ana-laura.martorano)

Dear chrome-root-program-team,

Thank you for raising these questions. We have discussed your observations directly with our Qualified Auditor. Below we provide the clarification received.

(Q1) Reference to policy versions published after the audit period

The audit period covered 2024-10-08 to 2025-10-07. The document assessment phase started in July 2025. For example, D-Trust provided TSPS version 2.5 to the auditor on 2025-07-17.

As a result of the document review and the subsequent onsite assessment, the auditor requested clarifications and refinements. These led to updated document versions (e.g., TSPS versions 2.6 and 2.7). The final published versions therefore bear dates shortly after the end of the formal audit period. The assessment covered also all changes introduced since the previous audit including the TSPS versions 2.3 and 2.4.
According to the auditor, and based on the agreed Audit Attestation Letter (AAL) templates, it is common practice to reference only the latest approved versions of the applicable CP, CPS, and TSPS documents in the attestation letter, even if earlier versions were in force during parts of the audit period.

The auditor confirmed that the audit itself covered the operational practices throughout the full audit period, including the document versions that were effective at the respective times.

(Q2) Multiple in-force policy versions during the audit period

(a) Assessment against in-force policies
The Qualified Auditor confirmed that the audit covered the operational practices against the policies and procedures that were actually in force during the respective parts of the audit period. The assessment included reviewing changes since the previous audit and validating their implementation.

(b) Why earlier versions are not explicitly referenced
Our understanding is that the structure and content of ETSI Audit Attestation Letters follow agreed templates and established practice between the auditing bodies (ACAB-C) and the CCADB.

As this referencing model is part of that framework, any modification to this practice would require agreement between ACAB-C and the CCADB at governance level.

If the community considers an adjustment beneficial for transparency, this topic would therefore need to be addressed within the CCADB–ACAB-C framework and procedures. The auditor confirmed that they are happy to discuss this as part of the regular meetings.

Status Update:

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Introduce Audit CCADB capability “pre-flight” check Prevent Root Cause # 1 Documented validation of CCADB scope against audit scope 2026-11-01 (Next audit cycle) Ongoing
Define explicit CCADB submission escalation incl. deadline monitoring Prevent Root Cause # 2 Escalation path documented and tested 2026-02-18 Ongoing
Investigate and resolve CCADB S/MIME capability metadata discrepancy Prevent Root Cause # 1 CCADB metadata accurately reflects designed issuance capabilities Open Ongoing

In response to Comment 7:

Thank you for the additional explanation.

“According to the auditor, and based on the agreed Audit Attestation Letter (AAL) templates, it is common practice to reference only the latest approved versions of the applicable CP, CPS, and TSPS documents in the attestation letter, even if earlier versions were in force during parts of the audit period.”

I want to clarify why this approach does not meet the requirements of CCADB Policy 5.2.

Policy documents have effective dates that show when their requirements apply. This allows relying parties, auditors, and the community to understand which rules were in force during the audit period. When an audit report or audit attestation lists only policy versions that became effective after the audit period, it is unclear which requirements were actually assessed. This affects the ability of others to understand the scope of the audit.

CCADB Policy 5.2 states:

“7. List of the CA Owner’s applicable policy documents (with version numbers and publication dates) referenced during the audit;”

The audit report must list all policy documents that were referenced during the audit. If more than one version of a policy was in force during the audit period, then each version must be listed. A document that becomes effective after the audit period cannot be used to show compliance during that period. If document changes were needed to meet audit requirements, those changes must be effective within the audit period or else an audit finding is necessary.

Thank you for explaining that the auditor reviewed the versions that were in force during the audit period. However, if those versions are not listed in the audit report, then the community cannot confirm what was reviewed. The audit report is the public record of the audit. Internal auditor notes cannot replace the information required by CCADB Policy.

The CA Owner is responsible for ensuring that the audit report complies with CCADB Policy. If a template does not include required information, the CA Owner must ensure that the final audit report is updated so that it complies with CCADB Policy 5.2. Templates do not override the policy requirements.

For the current audit period, the audit report must meet the requirements of CCADB Policy as written.

(In reply to Enrico Entschew from comment #7)

Dear chrome-root-program-team,

Thank you for raising these questions. We have discussed your observations directly with our Qualified Auditor. Below we provide the clarification received.

(Q1) Reference to policy versions published after the audit period

The audit period covered 2024-10-08 to 2025-10-07. The document assessment phase started in July 2025. For example, D-Trust provided TSPS version 2.5 to the auditor on 2025-07-17.

As a result of the document review and the subsequent onsite assessment, the auditor requested clarifications and refinements. These led to updated document versions (e.g., TSPS versions 2.6 and 2.7). The final published versions therefore bear dates shortly after the end of the formal audit period. The assessment covered also all changes introduced since the previous audit including the TSPS versions 2.3 and 2.4.
According to the auditor, and based on the agreed Audit Attestation Letter (AAL) templates, it is common practice to reference only the latest approved versions of the applicable CP, CPS, and TSPS documents in the attestation letter, even if earlier versions were in force during parts of the audit period.

The auditor confirmed that the audit itself covered the operational practices throughout the full audit period, including the document versions that were effective at the respective times.

Dear Enrico,

To the best of my understanding of the audit scheme (which should apply to both WebTrust or ETSI), evenif the auditor requested clarifications and refinements against the at-the-time effective versions of CP/CPS or TSPS documents, only the effective documents of the Audit Period should be listed in the AALs, because those were the Normative documents effective during the audit period. If the TSPS versions 2.6 and 2.7 were created after the end of the audit period to remediate some issue in the previous TSPS, this is part of an activity of the next audit period.

If those clarifications and refinements were not associated with non-conformities, of course the TSP can make the necessary improvements which would be audited at the next audit cycle.

Is this accurate?

(Q2) Multiple in-force policy versions during the audit period

(a) Assessment against in-force policies
The Qualified Auditor confirmed that the audit covered the operational practices against the policies and procedures that were actually in force during the respective parts of the audit period. The assessment included reviewing changes since the previous audit and validating their implementation.

Exactly. This includes any normative document changed within the audit period. TSPS 2.6 and 2.7 became effective after the audit period.

(b) Why earlier versions are not explicitly referenced
Our understanding is that the structure and content of ETSI Audit Attestation Letters follow agreed templates and established practice between the auditing bodies (ACAB-C) and the CCADB.

As this referencing model is part of that framework, any modification to this practice would require agreement between ACAB-C and the CCADB at governance level.

If the community considers an adjustment beneficial for transparency, this topic would therefore need to be addressed within the CCADB–ACAB-C framework and procedures. The auditor confirmed that they are happy to discuss this as part of the regular meetings.

The ACAB-c AAL templates available from https://www.acab-c.com/downloads/, which are being used by other ETSI Accredited Assessment Bodies, explicitly state that the letter must contain a "list of the CA policy and practice statement documents (with version numbers) referenced during the audit". Please notice the plural in the word "documents". Having reviewed a number of AALs from ETSI-audited CAs, I can confirm that page 5 of the AALs contain multiple versions of the normative CA/TSP documents.

I will note that, as you state, this is your (D-Trust's) understanding and not that of your Auditor so perhaps you might want to clarify with them and confirm or revise that statement.

(In reply to Dimitris Zacharopoulos from comment #10)

The ACAB-c AAL templates available from https://www.acab-c.com/downloads/, which are being used by other ETSI Accredited Assessment Bodies, explicitly state that the letter must contain a "list of the CA policy and practice statement documents (with version numbers) referenced during the audit". Please notice the plural in the word "documents". Having reviewed a number of AALs from ETSI-audited CAs, I can confirm that page 5 of the AALs contain multiple versions of the normative CA/TSP documents.

I will note that, as you state, this is your (D-Trust's) understanding and not that of your Auditor so perhaps you might want to clarify with them and confirm or revise that statement.

Dear Dimitris,
as one of the editors of the AAL template set, I don't fully agree with your comment about the content of the templates.
It’s good to hear that there are already attestations listing also the different versions and applicability dates. However, when creating that part of the attestation, we had the common understanding that it would be sufficient to reference the latest version of each applicable document, even if that has a date after the actual audit period, as all previous versions together with their respective applicability dates are visible in the documents itself. We thought it would be natural that at any time only the version valid at that time could be applied and didn't realize a benefit from repeating versions and validity dates in the attestation. The plural in "documents" you are referring to was meant to address the fact that for some Root CAs there are a number of different CP or CPS documents applicable, in the sense of CPS_1 and CPS_2, not CPS_1, version 1 and CPS_1, version 2.

In the light of this discussion, we acknowledge that it improves transparency and reduces the possibilities of misunderstanding or misinterpretation if we explicitly call out the different versions together with the periods they have been applied for. It has been discussed in the regular ACAB-c working group meeting this week and the templates will be amended as soon as possible with an explicit requirement to reference all document versions with their validity dates that fall into the audit period.

(In reply to Matthias Wiedenhorst from comment #11)

(In reply to Dimitris Zacharopoulos from comment #10)

The ACAB-c AAL templates available from https://www.acab-c.com/downloads/, which are being used by other ETSI Accredited Assessment Bodies, explicitly state that the letter must contain a "list of the CA policy and practice statement documents (with version numbers) referenced during the audit". Please notice the plural in the word "documents". Having reviewed a number of AALs from ETSI-audited CAs, I can confirm that page 5 of the AALs contain multiple versions of the normative CA/TSP documents.

I will note that, as you state, this is your (D-Trust's) understanding and not that of your Auditor so perhaps you might want to clarify with them and confirm or revise that statement.

Thank you Mattias for the quick response.

Dear Dimitris,
as one of the editors of the AAL template set, I don't fully agree with your comment about the content of the templates.
It’s good to hear that there are already attestations listing also the different versions and applicability dates. However, when creating that part of the attestation, we had the common understanding that it would be sufficient to reference the latest version of each applicable document, even if that has a date after the actual audit period, as all previous versions together with their respective applicability dates are visible in the documents itself.

Understood. When you say "we", are you referring to ACAB-c?

We thought it would be natural that at any time only the version valid at that time could be applied and didn't realize a benefit from repeating versions and validity dates in the attestation. The plural in "documents" you are referring to was meant to address the fact that for some Root CAs there are a number of different CP or CPS documents applicable, in the sense of CPS_1 and CPS_2, not CPS_1, version 1 and CPS_1, version 2.

Understood, thanks for clarifying.

In the light of this discussion, we acknowledge that it improves transparency and reduces the possibilities of misunderstanding or misinterpretation if we explicitly call out the different versions together with the periods they have been applied for. It has been discussed in the regular ACAB-c working group meeting this week and the templates will be amended as soon as possible with an explicit requirement to reference all document versions with their validity dates that fall into the audit period.

Excellent. Consistency in Audit Attestation Letters is very helpful to the readers/consumers of those letters.

(In reply to Dimitris Zacharopoulos from comment #12)

Understood. When you say "we", are you referring to ACAB-c?

Sorry. I was referring to ACAB-c working group 1, which is responsible for the AAL templates.

Excellent. Consistency in Audit Attestation Letters is very helpful to the readers/consumers of those letters.

I absolutely agree with that.

Dear all,
Following your feedback, we entered into a discussion with our Qualified Auditor. As outlined above, the topic was also discussed internally within the dedicated ACAB-C working group. As a result, the Audit Attestation Letters have been updated to explicitly list all CP/CPS/TSPS document versions, including their respective validity periods, that were applicable during the audit period.

The revised Audit Attestation Letters are provided below:
https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_Standard_Audit_V1.3.pdf
https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_TLS-BR_Audit_V1.3.pdf
https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_TLS-EV_Audit_V1.3.pdf
https://www.tuev-nord.de/fileadmin/Sites/TUEV_NORD/Zertifikate/Certification/IT-Zertifikate/de/AA2025121001_D-Trust-CAs_SMIME-BR_Audit_V1.2.pdf

We acknowledge that the public audit record must clearly and transparently reflect the normative document versions in force during the assessed period, and we appreciate the constructive discussion that helped align expectations.

Status Update:

Action Items 2 and 3 have been fully completed.

Action Item 2: The defined escalation path has been conceptually developed, formally documented, internally trained and tested. Responsibilities have been consolidated from two previously distributed roles into one clearly accountable role. The process will be mandatorily applied at the end of each respective audit period.

The process includes a structured deadline monitoring mechanism. In the event of defined deadlines being exceeded, predetermined measures are triggered to ensure a controlled and traceable response and to prevent any delayed publication of the respective Audit Attestation Letter (AAL). Should there be any indication that the implemented measures may not be successful, D-Trust will promptly contact CCADB Support.

Action Item 3: The CCADB S/MIME capability metadata discrepancy is successfully resolved with the assistance of CCADB Support.

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Introduce Audit CCADB capability “pre-flight” check Prevent Root Cause # 1 Documented validation of CCADB scope against audit scope 2026-11-01 (Next audit cycle) Ongoing
Define explicit CCADB submission escalation incl. deadline monitoring Prevent Root Cause # 2 Escalation path documented and tested 2026-02-18 Completed
Investigate and resolve CCADB S/MIME capability metadata discrepancy Prevent Root Cause # 1 CCADB metadata accurately reflects designed issuance capabilities 2026-02-13 Completed

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Flags: needinfo?(ana-laura.martorano)

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.

Weekly update: Nothing new to report. D-Trust continues to monitor this ticket.
We request that the deadline for the next update be set for October 2, 2026.

Flags: needinfo?(bwilson)
Whiteboard: [ca-compliance] [audit-delay] → [ca-compliance] [audit-delay] Next update 2026-10-02
Flags: needinfo?(bwilson)
You need to log in before you can comment on or make changes to this bug.