1948600 - IZENPE: Outdated CPS for Izenpe Root

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[David]

This is a preliminary report to analyze why Izenpe has failed to submit CPS documents on time to CCADB as stated on Chrome Root Program (2.3 -Policy Disclosures)

Comment 1

[David]

Incident Report

Summary

Izenpe did not submit the last CPSs to CCADB on time and therefore it appears as outdated in CCADB.
According to Chrome Root Policy v1.6 section 2.3, the CA's policy documents must had been submitted to CCADB within 14 days of document's effective date.

Impact

None

Timeline

All times are UTC.

2024-11-08:

• 08:48 Izenpe CPS version 7.7 was published.
  2025-02-14:
• 14:48 An email from Chrome Root Program warns us about not disclosing CPS.
  2025-02-15:
• 00:00 Chrome Root Program Policy v1.6 is published.
  2025-02-17
• 11:10 A new request to CCADB has been sent to update the CPS info.

Root Cause Analysis

CPS document is maintained by a different group in Izenpe other than the PKI-SSL team and follows its own procedure (review and approval by
the security team, publishing in the web..) and this was not propertly comunicated.

Lessons Learned

What went well

Izenpe has always had an updated version of the CPS on its web page and they have been available and audited at https://www.izenpe.com/cps/ including the previous versions.

What didn't go well

We have misunderstood some CCADB mails advising us about outdated documents as we thought they were talking about the CP.

Where we got lucky

Action Items

Action Item	Kind	Due Date
Modifify the procedure of approving CPS to include CCADB	Prevent	2025-02-28
Create an internal task to ensure the actual CPS will not be outdated	Mitigate	2025-10-30
An internal monitoring to detect if a new CPS is published	Detect	2025-02-28

Appendix

Details of affected certificates

None

Comment 2

[Ben Wilson]

Dear David,

I’d like to take a moment to highlight the importance of prompt, complete, and consistent (weekly) communication regarding incident reports. Root store programs expect CAs to provide substantive weekly updates in Bugzilla (unless a "Next update" date has been set in the Whiteboard). This reporting process helps ensure transparency and trust in the Web PKI ecosystem.

We appreciate Izenpe’s efforts in this space and thus encourage continued diligence in responding to compliance matters. However, we have also noticed that the current Incident Report lacks sufficient detail. A more thorough report would help provide the desired resolution of issues identified. Could you expand the report with more details—such as the Impact, more Root Cause Analysis, and more Lessons Learned? This will help facilitate the resolution process.

Delays in communication or incomplete reports can slow the resolution of issues and may invite additional scrutiny from root programs. Ensuring that each comment is meaningful, rather than just a placeholder, will mitigate risks and demonstrate a commitment to best practices.

Thanks,

Ben

Comment 3

[David]

Hi Ben,
thanks for the comments. First, regarding the weekly update, it was my completely my fault I messed up with the weekly update and the earliest date I proposed int he action plan.
Regarding the lack of detail, tomorrow I will give it a try to expand the initial report and give more detail.
Thanks,

Comment 4

[David]

Incident Report

Summary

Izenpe failed to submit the last CPSs to CCADB on time and therefore they appeared as outdated in CCADB.
According to Chrome Root Policy v1.6 section 2.3, the CA's policy documents must had been submitted to CCADB within 14 days of document's effective date.

Impact

Although there has not been any direct impact on certificates or other PKI elements, 6 CPS versions, starting with 7.2 have not been disclosed and
therefore there has been a big gap in CCADB where issued certificates could not have been bound to a CPS version.

Timeline

All times are UTC.

2022-09-30:

• Izenpe CPS version 7.1 was uploaded to CCADB.

2022-10-17:

• Izenpe CPS version 7.2 was published.

2022-10-26

• Izenpe CPS version 7.3 was published.

2023-10-18

• Izenpe CPS version 7.4 was published.

2023-11-08

• Izenpe CPS version 7.5 was published.

2024-10-24

• Izenpe CPS version 7.6 was published.

2024-11-08:

• Izenpe CPS version 7.7 was published.

2024-12-10

• Email from CCADB where action was required.

2025-01-15:

• Email from CCADB where action was required.

2025-02-11:

• Email from CCADB where action was required.

2025-02-14:

• 14:48 An email from Chrome Root Program warns us about not disclosing CPS.

2025-02-15:

• 00:00 Chrome Root Program Policy v1.6 is published.

2025-02-17

• 11:10 A new request to CCADB has been sent to update the CPS info.

Root Cause Analysis

There have been various factors that have led us to this situation.
On one side, the CPS covers other certificates than SSL ones and it is maintained by a different team in Izenpe. So far, in their roadmap, it was not
considered to inform the SSL Team whether a new version of the CPS was published and we missed all the new versions of it.
On the other hand, we have repeatedly ignored the CCADB messages warning us about "action was required" where we could have seen where the problem was.
And finally we had not set a reminder about the CPS expiration date as we had done with the CP.

Lessons Learned

What went well

Izenpe has always complied with the requirement of publishing a new CPS/CP version at least once a year.
Every version, with its publication dates, have been upload to Izenpe web page at https://www.izenpe.com/cps/ and they have been checked by the auditors.

What didn't go well

As pointed at the Root causes, we misunderstood some CCADB mails advising us about outdated documents
as we thought they were talking about the CP and we did not verify the information.
Although we were not aware of the CPS new versions at this time,
we should have worried about uploading every year a new version of the CPS even if it had no changes and we have failed at this point.

Where we got lucky

Action Items

Action Item	Kind	Due Date
Review CCADB outdated documents	Remediation	2025-02-28
Modifify the procedure of approving CPS to include CCADB	Prevent	2025-02-28
Create an internal task to ensure the actual CPS will not be outdated	Mitigate	2025-10-30
An internal monitoring to detect if a new CPS is published	Detect	2025-02-28
Unify CP and CPS in one document	Prevent	2025-05-30

Appendix

Details of affected certificates

None

Comment 5

[David]

Regarding the action items, we have set a simple monitoring task to detect a new CPS version published and an alarm while raise to remind us it has to be disclosed to CCADB.
Also, we are still reviewing the CCADB to correct superseded documents.

Comment 6

[David]

Hi,
although we will still having a look to all documents in ccadb, so far we have not identified any outdated documents on it.
Soon we will start working on CP and CPS unification.
Regards,

Comment 7

[Ben Wilson]

Hi David,
Normally, I set the "next update" date upon your request.
Thanks,
Ben

Comment 8

[David]

My mistake. It makes all the sense.
Thanks

Comment 9

[Jeremy]

Can you provide more detail about the alert when the CPS is out of date? How does it work and who is getting notice?

Comment 10

[David]

Attachment: nagios_cps_7.8.jpg

Comment 11

[David]

Hi,
in this case we have configured our Nagios to test if a new version has been published. As the latest version of the CPS is the 7.7 one, we are monitoring that the 7.8 does not exist (checking http response is 404). In case this returns something different than a 404, an error raises and we are notified by email.
Regards,

Comment 12

[Malcolm D]

Hi David, how do you cope if the next version published is 8.0 instead of 7.8?

Comment 13

[David]

Hi Malcom,
we are not expecting that what has hapenned in the past, this is, CPS beeing published without being notified could happen again. The importance of communicating changes in the CPS has been notified to the people who publish the CPS as it impacts in the SSL compliance and they have included this in their procedure. This monitoring has been set to add an extra method to check this and version numbers have never had a gap so it can be a quite reliable way to detect it.
Regards,

Comment 14

[David]

Hi,
I would like to ask to set the Next Update for 2025-05-23, a week before the planned date for unification of CP and CPS.
Regards,

Comment 15

[David]

Hi,
this week we have finished merging the CP and CPS and the document has been approved by the security committee yesterday. We wiil upload today to our web and disclosure to CCADB the following monday.
Regards,

Comment 16

[David]

Hi,
the new CP/CPS was uploaded as planned. We plan to fill the Closure Report as soon as possible.
Reports,

Comment 17

[David]

Report Closure Summary

• Incident description:
  Izenpe has always renewed its CPS document on its website but did not upload the latest CPS document to CCADB before the previous one was outdated and within the 14 days of its publication.
• Incident Root Cause(s):

• CPS document is maintained by a different team within Izenpe as this document covers many other certificate profiles and changes made to it had not properly been communicated.
• Messages from CCADB were misunderstood.
• We had not set a reminder when the CPS expired as we had with the CP.

• Remediation description:
  First of all we updated the information in the CCADB. To ensure that a new CPS version is not published without internal notification, we have both set a monitoring task and modify the current approving procedure to be notified. And finally we have decided to unify both CP and CPS.
• Commitment summary:
  Izenpe must commit a more exhaustive comprehension on what surrounds all TLS world, regarding its requirements, controlling all the information related, understanding its notifications and so on. While some actions have been taken to fix this, we have missed some other like those related to this BUG. And this is where we have to pay more attention.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 18

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-07-01.