Further Improving the CCADB Policy (FEEDBACK REQUESTED)

[Chris Clements]

All,

Following the community’s recent iteration and improvement on the updated CCADB Incident Reporting Guidelines (IRGs), the CCADB Steering Committee has collaborated on an updated draft of the CCADB Policy.

The set of proposed updates are available here.

Objectives for this update include:

• Clarifying Root Store Operator expectations related to CCADB disclosures. Some of these clarifications were motivated by public Incident Reports filed to Bugzilla over the past year.
• Creating opportunities to (a) remove redundant/similar requirements located across root program policies related to CCADB disclosures and (b) encourage future simplicity.
• Promoting simplicity and improving readability through a reorganization of normative and non-normative requirements.

Additionally, minor updates are proposed to the IRGs (e.g., further streamlining the incident reporting closure process).

These proposals should not be considered “final”, but instead a “work in-progress” that we hope to enhance through community contributions. We welcome your feedback on these proposed updates and recommendations by May 23, 2025. Please share your thoughts by replying to this email or, preferably, by suggesting edits directly on GitHub.

Thank you
-Chris, on behalf of the CCADB Steering Committee

[Chris Clements]

All,

Thank you to everyone who provided valuable feedback on the proposed updates to the CCADB Policy and the Incident Reporting Guidelines (IRGs). Both artifacts have been enhanced thanks to the insightful recommendations and suggestions.

We want to reiterate the original objectives for this update:

• Clarifying Root Store Operator expectations for CCADB disclosures.
• Streamlining requirements across different root programs to reduce redundancy.
• Enhancing the simplicity and readability of the policy.

We plan to publish the updated CCADB Policy and IRGs later in June, with an effective date of July 1, 2025.

We appreciate your continued collaboration in making the CCADB a more effective and transparent resource for the community.

-Chris, on behalf of the CCADB Steering Committee

[Chris Clements]

All,

The updated CCADB Policy and Incident Reporting Guidelines have been published with an effective date of July 15, 2025. This date is in line with the expectation that CA Owners will have updated their in-use TLS server authentication certificate validation methods for publicly-trusted hierarchies, following the recent CCADB enhancement.

CA Owners are strongly encouraged to align their CCADB disclosures with the expectations that become effective on July 15, 2025, as soon as reasonably possible. 

Please note, to comply with the updated CRL disclosure requirements described in Section 6.2, it is expected some CAs will need to update existing certificate records (e.g., modifying CRL disclosures to exactly match those included in certificates).

Thank you

-Chris, on behalf of the CCADB Steering Committee

[Dimitris Zacharopoulos (HARICA)]

Hi Chris,

Regarding the URLs of CRLDPs, it is non uncommon for a CA to change the URL of the CRLDP. Obviously, there are redirects until the certificates with the old URL expire. What is the expectation if there are multiple URLs to be included in CCADB?

Also, what is the process for switching from sharded to full CRLs and vice-versa?


Best regards,
Dimitris.

--
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/CAAbw9mApWKw1J2ZJ2-1ft7LgJK7CDiYvHKLFjtNEiH1EH%3DmYtQ%40mail.gmail.com.

[Rob Stradling]

> This date is in line with the expectation that CA Owners will have updated their in-use TLS server authentication certificate validation methods for publicly-trusted hierarchies, following the recent CCADB enhancement.

Hi Chris.  You may recall that I expressed surprise about this "expectation" at the recent CABForum F2F.  Allow me to explain.

The announcement for the recent CCADB enhancement said (emphasis mine):

• "The CCADB was updated to add the following TLS Certificate Domain and IP Address Control Validation Methods as options for selection by CA Owners"
• "CA Owners implementing any of these methods can disclose their use"

I haven't been able to find any previous CCADB announcement regarding the Validation Methods field, and I also can't find any language in the newly updated CCADB Policy or in any of the Root Store policies that requires this field to be populated.  In contrast, there are clear MUST requirements for populating certain other fields (e.g., https://www.ccadb.org/policy#62-certificate-revocation-list-disclosures).

The reason for my surprise is that an "expectation" sounds like "SHOULD" or "MUST", whereas "options" and "can" sound like "MAY".  I have no problem with aiming to comply with clearly labelled SHOULD and MUST requirements that have achievable effective dates and that are enshrined in official policies, but ISTM that your "expectation" here is an implied and backdated "SHOULD" or "MUST" that is neither clearly labelled nor enshrined in policy.

Is there some other basis for your "expectation" that I've missed?

[Aaron Poulsen]

I am also interested to know if a process exists for transitioning from a full to partitioned CRL (or the reverse) in CCADB. I can't find any discussions that address this need.

CCADB states that at least one field must be populated. Can we simply provide values for both fields?

Aaron

[Ben Wilson]

For CRLite, populating both fields should not create a problem.  However, CAs should not populate the "Full CRL" field with more than one URL.

Thanks,

Ben

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/48947bbc-ca5d-4922-a9fd-9bb74fd82bf9n%40ccadb.org.

[Clint Wilson]

This is the same for Apple. Whatever is populated will be picked up, so as long as at least one of the fields is populated at all times CAs can switch between full and partitioned CRLs as they’d like (from Apple’s perspective).

Cheers,

-Clint

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZh0hjfGtc_6aKeF2vJtQqRh3SLpkTeSdiipDzePVgkOg%40mail.gmail.com.

[Chris Clements]

Hi Dimitris,

It seems switching between full and partitioned CRLs is acceptable so long as at least one of the two corresponding fields in the CCADB is accurately populated at all times. If there are multiple full CRL URLs during a period of transition, at least one of those will need to be disclosed to the CCADB. With that said, is there a suggested wording change for the CCADB Policy? 

Thank you

-Chris

[Chris Clements]

Hi Rob, 

Thank you for the explanation; I understand now how my previous wording and response at F2F 65 could have been more precise.

The expectation that the “Validation Methods” field in the CCADB is populated is based upon technical enforcement within the system.

1. Introduced in September 2022 during a major CCADB release, the Validation Methods field became a mandatory entry. Subsequently, whenever a root certificate was added to an "Add/Update Root Request" Case (minimally, for annual document disclosure requirements), the CCADB system enforced that this field be populated before a CA Owner could successfully select 'Submit to Root Store'. Attempting to submit without providing a value for this field results in an error.

2. Similarly, CA Owners attempting to include a root certificate in a "Root Inclusion Request" Case have to populate the Validation Methods field (and several other root record fields in the CCADB) before being able to successfully select 'Submit to Root Store'. Without this information, submission will again result in an error. 

The expectation that the field be populated with accurate information comes from Section 1 of the CCADB Policy that states: 

“Regardless of more specific provisions in these requirements, CA Owners have an overarching responsibility to keep the information in the CCADB about themselves, their operations and their certificates accurate, and to make updates in a timely fashion. Minimally, CA Owners with certificates included in a Root Store MUST ensure their information stored in the CCADB is kept up to date as changes occur.” 

Members at F2F 65 wanted a clear deadline for updating their information in this field. We chose July 15, 2025, to align with the deprecation of methods 3.2.2.4.2 and 3.2.2.4.15 from the CA/Browser Forum TLS Baseline Requirements.

Hopefully, this context helps better explain the expectation for the Validation Methods field in the CCADB. 

Thank you

-Chris

[Clint Wilson]

This is the same for Apple. Whatever is populated will be picked up, so as long as at least one of the fields is populated at all times CAs can switch between full and partitioned CRLs as they’d like (from Apple’s perspective).

Cheers,

-Clint

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZh0hjfGtc_6aKeF2vJtQqRh3SLpkTeSdiipDzePVgkOg%40mail.gmail.com.

[Rob Stradling]

Hi Chris.  Thanks for explaining.

I've always interpreted that portion of Section 1 as "...ensure their information stored in the CCADB is kept up to date as changes [to that information] occur", whereas in this thread we're talking about a situation where a CA Owner's information doesn't change but the CCADB's capacity to capture and store that information is enhanced (without any policy requirements being introduced relating to that enhancement).

To avoid any similar confusion in future, may I suggest updating the "as changes occur" language somehow to make it explicitly clear that CCADB enhancements also count as "changes" that "occur"?

[Dimitris Zacharopoulos (HARICA)]

On 27/6/2025 1:18 π.μ., Chris Clements wrote:

Hi Dimitris,

It seems switching between full and partitioned CRLs is acceptable so long as at least one of the two corresponding fields in the CCADB is accurately populated at all times. If there are multiple full CRL URLs during a period of transition, at least one of those will need to be disclosed to the CCADB. With that said, is there a suggested wording change for the CCADB Policy?

Hi Chris,

I believe my biggest concern comes from the recent change introducing the following sentence:

• "MUST match exactly as they appear in the certificates issued by the corresponding CA"

Since a CA may change URLs arbitrarily, it is clear that this rule will fail because there will be a moment in time where an early-issued end-entity certificate will have "URL A", and a later-issued certificate will have "URL B". In that case, CCADB will have either "URL A" or "URL B" causing issues with the policy.

I suggest removing this sentence. If I recall correctly, the purpose of this field was to offer an out-of-band CRL checking mechanism that Certificate Consumers may use in addition to the CRLDP URL in the actual certificates, or the lack of such an extension.

To assist with the interchange of full and partitioned URLs, I suggest removing the following two sentences because as described, the actual implementation is "either" and not "either or both":

• If populating a full and complete CRL URL:
  the JSON Array of Partitioned CRL URLs field MUST be empty.

• If populating a JSON Array of Partitioned CRL URLs:
  the full and complete CRL URL MUST be empty.

Best regards,
Dimitris.

[Corey Bonnell]

Hi Dimitris,

Comments inline.

• "MUST match exactly as they appear in the certificates issued by the corresponding CA"

 

I think the intent of this is to ensure that if a CRL URL is specified both in a certificate via the CRLDP and in CCADB, there’s no variation in casing, trailing slashes, etc. I don’t think it’s establishing a requirement for all certificates to include CRLDP. I agree that the language should be improved to make that clear.

 

Ø  If populating a full and complete CRL URL:

Ø  the JSON Array of Partitioned CRL URLs field MUST be empty.

Ø  If populating a JSON Array of Partitioned CRL URLs:

Ø  the full and complete CRL URL MUST be empty.

 

Can you expand on why it’s useful for both fields to be populated? I think this requirement to populate only one makes sense, because a full CRL’s scope will necessarily include all certificates issued by the CA. Thus, any partitioned CRL information is redundant and need not be specified if a full CRL is specified.

 

Thanks,

Corey

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/4572ee58-1af2-4c4a-90c8-e20bd6c8ea07%40harica.gr.

[Chris Clements]

Hi Corey,

I think the intent of this is to ensure that if a CRL URL is specified both in a certificate via the CRLDP and in CCADB, there’s no variation in casing, trailing slashes, etc. I don’t think it’s establishing a requirement for all certificates to include CRLDP.

This is correct and ensures there is parity between what we see in certificates and what we see disclosed to the CCADB (except in the rare case of transitory periods). 

In response to the CRL URL points originally raised by Dimitris and the separate updated information clarity raised by Rob, we’ve created this PR for a minor version increment of the CCADB Policy to 2.0.1. Continued comments are both welcome and appreciated. 

Thank you

-Chris

[Ben Wilson]

Hi All,

Section 6.2 of CCADB Policy (for the JSON Array of Partitioned CRL URLs) says, "CA Owners MUST ensure that each corresponding CRL contains a critical ‘Issuing Distribution Point’ extension and the ‘distributionPoint’ field of the extension MUST include a ‘UniformResourceIdentifier’. The value of the UniformResourceIdentifier MUST exactly match a URL, from which the CRL was accessed, present in the CCADB record associated with the CA certificate."  

John Schanck has pointed out that this language might be too permissive because "`distributionPoint` field can contain multiple URIs, so "match a URL [...] present in the CCADB record" implies that a CA could comply with this clause by listing each of the entries of their "JSON Array of Partitioned CRL URLs" in the `distributionPoint` field. A CRL with the full list of partitioned CRL URLs in its idp extension could be substituted for any other CRL in the list."

He is suggesting that the language be revised to read, "CA Owners MUST ensure that each corresponding CRL contains a critical 'Issuing Distribution Point' extension. The 'distributionPoint' field of that extension MUST include exactly one 'UniformResourceIdentifier' that matches a URL present in the CCADB record associated with the CA certificate. The extension MAY include other UniformResourceIdentifiers."

Are there any suggestions, recommendations, or improvements to address these concerns?

Ben

[Corey Bonnell]

Hi Ben,

RFC 5280, section 5.2.5 (which defines the syntax of the IDP CRL extension) says:

 

“The syntax and semantics for the distributionPoint field are the same as for the distributionPoint field in the cRLDistributionPoints extension (Section 4.2.1.13).”

 

Section 4.2.1.13 says:

 

“When the distributionPoint field is present, it contains either a

   SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.

   If the DistributionPointName contains multiple values, each name

   describes a different mechanism to obtain the same CRL.”

 

The issue that John describes requires a violation of the requirements above, as multiple IDP distributionPoint names/URLs within a given CRL must identify that same CRL. If the included names/URLs actually refer to CRLs that differ in scope/revoked entry content, then the “same CRL” rule is not being followed by the CA.

 

Perhaps it would be good to call this out in Mozilla policy, but I believe the CRL profile requirements in RFC 5280 address this concern.

 

Thanks,

Corey

To view this discussion visit https://groups.google.com/a/ccadb.org/d/msgid/public/CA%2B1gtaZ8TXSqnG_O697Qmc0ki7L-o20jBrZbiKq_LaMeo-e3Uw%40mail.gmail.com.