CCADB Policy Mis-alignment: Authoritative Language, Audit Statement Content

[Wayne]

On briefly reviewing CA's Certificate Policies and Audits at random a few issues arose in respect to CCADB policy. My intent here isn't to highlight a specific CA at fault, but to note that there seems to be a theme of these policies not being adhered to. To that end while I'm talking about a specific CA in each issue, it impacts more than just one.

CCADB Policy 5.1: Audit Statement Content
Since version 1.2 effective February 15, 2023 there has been this language affecting audit reports:
- List of the CA Owner's applicable policy documents (with version numbers and publication dates) referenced during the audit;

As an example if we look at ACCV's TLS BR audit from 2023-06-28 they mention: "ACCV’s Certification Practice Statement (CPS) – v4.0.11; and"

Now, this is compatible with the baseline requirements that don't impose the publication date requirement but not CCADB policy. I am under the impression that audits are automatically checked via the Audit Letter Validation process, how does this function in practice and does it need updated?

As an aside it seems ACCV have an updated CPS that isn't included in their CCADB record? The record points at a 4.0.13 CPS, while the website has a 5.0.2. Please be advised that minotaurs may be present if attempting to find this page on your own.

Authoritative Language
Since CCADB Policy 1.0 there has been wording to the effect of:
As of June 1 2017, CAs must provide English versions of any Certificate Policy and Certification Practice Statement documents which are not originally in English, with version numbers matching the document they are a translation of. The English version is not required to be authoritative in all cases of dispute, but the CA must attest that the translation is not materially different to the original.

With that in mind and with Actalis as an example how does this CPS comply:
1.2 Document Identification
This document is the Certification Practice Statement (CPS) applying to SSL Server and Code Signing certificates issued by Actalis S.p.A. Version and time of last revision are indicated on the first page. This document is published on Actalis’ web site in two languages: Italian and English. In the event of any inconsistency between the two versions, the Italian version takes precedence.

What is the actual process for checking certificate policies against CCADB policy? I was checking a few policies for their 1.4.2 text and stumbled on these so there are doubtless more issues...

- Wayne

[Chris Clements]

Hi Wayne,

Thank you for your observations and questions. Responding from the CCADB Steering Committee perspective, inline, below.

On briefly reviewing CA's Certificate Policies and Audits at random a few issues arose in respect to CCADB policy. My intent here isn't to highlight a specific CA at fault, but to note that there seems to be a theme of these policies not being adhered to. To that end while I'm talking about a specific CA in each issue, it impacts more than just one. 

 

CCADB Policy 5.1: Audit Statement Content 

Since version 1.2 effective February 15, 2023 there has been this language affecting audit reports: 

- List of the CA Owner's applicable policy documents (with version numbers and publication dates) referenced during the audit; 

 

As an example if we look at ACCV's TLS BR audit from 2023-06-28 they mention: "ACCV’s Certification Practice Statement (CPS) – v4.0.11; and" 

 

Now, this is compatible with the baseline requirements that don't impose the publication date requirement but not CCADB policy. I am under the impression that audits are automatically checked via the Audit Letter Validation process, how does this function in practice and does it need updated?

Correct, ALV does perform automated checking for audit statement content within the CCADB. However, it does not currently provide any validation checks for the CA Owner’s applicable policy documents referenced during the audit. This could be an ALV enhancement request and would have to be aligned with resourcing and prioritization within the CCADB Steering Committee. Today, a CCADB Root Store Operator would need to manually review and identify the CA Owner policy documents (including version numbers and publication dates) while processing a CCADB Case, or thereafter.

In the past, we have discussed adding separate automation to flag policy update failures, for example, when a policy document has gone stale (i.e., not updated within the past year). This enhancement currently has our attention.

As an aside it seems ACCV have an updated CPS that isn't included in their CCADB record? The record points at a 4.0.13 CPS, while the website has a 5.0.2. Please be advised that minotaurs may be present if attempting to find this page on your own.

For this specific reference, it appears that the 5.0.2 version of the CPS applies to the ‘ACCV ROOT ECC EIDAS 2023’ and ‘ACCV ROOT RSA EIDAS 2023’ root CA certificates, which are not currently included in any of the root stores of the CCADB Root Store Operators. The CCADB records for these root CA certificates do reflect this version of the CPS.

Authoritative Language
Since CCADB Policy 1.0 there has been wording to the effect of:
As of June 1 2017, CAs must provide English versions of any Certificate Policy and Certification Practice Statement documents which are not originally in English, with version numbers matching the document they are a translation of. The English version is not required to be authoritative in all cases of dispute, but the CA must attest that the translation is not materially different to the original. 

 

With that in mind and with Actalis as an example how does this CPS comply: 

1.2 Document Identification 

This document is the Certification Practice Statement (CPS) applying to SSL Server and Code Signing certificates issued by Actalis S.p.A. Version and time of last revision are indicated on the first page. This document is published on Actalis’ web site in two languages: Italian and English. In the event of any inconsistency between the two versions, the Italian version takes precedence.

Section 5 of the current CCADB Policy (Version 1.3) states: “CA Owners must provide at least an authoritative English version of any CP, CPS, or combined CP/CPS which are not originally in English, with version numbers matching the document they are a translation of.”

A statement indicating that a native-language version takes precedence over an English language version does not necessarily mean there’s observed non-compliance with the CCADB Policy. It does, however, highlight opportunities for future non-conformance where a material difference between language versions *does* exist. This is something that the individual CCADB Root Store Operators may wish to investigate with this CA Owner, as this behavior may violate individual Root Program policies.

What is the actual process for checking certificate policies against CCADB policy? I was checking a few policies for their 1.4.2 text and stumbled on these so there are doubtless more issues...

The question seems to depend on the perspective from which it’s being asked.

CCADB Root Store Operators who process CCADB Cases while on rotation should be reviewing policy document additions and removals for completeness by following an agreed-upon standard operating procedure that includes well-defined checks (i.e., Is the policy retrievable from the URL provided? Is the document type selected correct? Is the document's last update date correct? etc.).

Root Stores and CA Owners alike can use the CCADB Self-Assessment to trace CA policy documents to the CCADB Policy (and other policies and requirements), but this is done outside of the CCADB itself.

Thanks again for sharing your observations and asking these questions.

-Chris

 

--
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 on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/d3c89dcc-2e90-4d0e-a088-5a29066c6665n%40ccadb.org.