Questions regarding which policy documentation to keep in CCADB

[Martijn Katerbarg]

All,

 

We’ve had an internal discussion at Sectigo regarding which information relating to CP and CPS documents needs to be kept within CCADB, and which old information must be removed.

 

We’re opting to open a public thread for this as we’re not only interested in seeing the point of view of the CCADB members, but other CAs and the community as well.  At present, we see different CAs taking different approaches.

 

Let us start by quoting a few requirements, from CCADB and root stores:

 

The Chrome Root Program states (https://www.chromium.org/Home/chromium-security/root-ca-policy/#2-chrome-root-program-participant-policies): "The Chrome Root Program considers CA policy documentation in the CCADB to be authoritative."

 

The CCADB Policy states (https://www.ccadb.org/policy#5-policies-audits-and-practices): "The URLs to such CPs, CPSes and audits, and any metadata about them such as the name of the auditor or the date of the audit, must be updated as new information becomes available."

 

Our questions here boil down to (1) What is the scope of “updated”? and (2) What does it mean for a superseded CP or CPS document whose details have not been removed from CCADB “to be authoritative”?

 

For CP and CPS information, it’s possible (and sometimes even necessary) to add multiple entries. These entries can however also be removed at a later time. Consider the regular occurrence of a CA publishing a CPS update: What update are root stores / CCADB expecting out of these options:

 

• The new CPS should be added, and the old CPS should be deleted as it is no longer in effect for new certificate issuance.
• The new CPS should be added, but the old CPS should be kept in place as long as there are unexpired certificates under its policy.
• The new CPS should be added. Older entries should be kept indefinitely to serve as an archive overview.

 

Or, would any of these 3 options currently be seen as a valid practice?

 

Regards,

Martijn

[Mike Shaver]

On Fri, Aug 16, 2024 at 7:10 AM 'Martijn Katerbarg' via CCADB Public <pub...@ccadb.org> wrote:

What update are root stores / CCADB expecting out of these options:

 

• The new CPS should be added, and the old CPS should be deleted as it is no longer in effect for new certificate issuance.
• The new CPS should be added, but the old CPS should be kept in place as long as there are unexpired certificates under its policy.
• The new CPS should be added. Older entries should be kept indefinitely to serve as an archive overview.

As a community member, I would prefer 3, but would want at least 2 as long as there are unexpired certs that are trusted by currently-supported browsers or operating systems.

I think the most common practice is 1, though?

A related question: what, if any, information should CAs provide about material changes between adjacent CPS versions? There is a wide range of practices here, but I think at least a summary of the changes or a list of affected sections would be helpful in a number of ways.

Mike

[Clint Wilson]

Thanks for starting this discussion. As an additional note, the Apple Root Program Policy states:

"CA providers must strictly adhere to their Certificate Policy (CP) and/or Certification Practices Statement (CPS) document(s) as disclosed within the CCADB (and not marked as “Deleted”).

Note: This extends to all policy documents the CA provider publishes in relation to its CAs included in the Apple Root Program, such as TSPS documents.”

The parenthetical in the first sentence is intended to provide some clarity around which CP/CPS documents are considered authoritative when disclosed to the CCADB. If a non-authoritative CP/CPS is not marked as “Deleted”, then it’s difficult to ascertain with a high degree of confidence and consistency across the corpus of CAs which CP/CPS is authoritative for a given CA. Ideally, a Root CA should only have at most either:

1. One CP and one CPS; or

2. One CP/CPS

at any given time. With multi-purpose Root CAs, this can be a bit more complex, but I think this would be a good target.

I think it’s worth noting that 1 & 3 are, I believe, mostly the same; that is, Policy Documents marked as “Deleted” in the CCADB are not removed from the database.

Regarding the “change log” sections of Policy Documents, I agree there’s not much specific guidance on what is desired or expected here. Both a summary of the changes and a list of sections in which changes occurred seem particularly valuable to me; are there any other suggestions or ideas from the community on this?

Cheers!

-Clint

--
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/CADQzZqsV%2BOdGz3DZMy2ZPOiXo64DBDW7AB--ctauEBafJFE1uw%40mail.gmail.com.

[Chris Clements]

Hi Martijn,

Providing the Chrome Root Program’s perspective below and feedback from others is welcome.

(1) What is the scope of “updated”?

In general, we rely on the information disclosed to the CCADB to serve as a canonical source of truth for the CAs represented in the Chrome Root Store, and those CAs transitively trusted in Chrome through those certificates. 

The CCADB has, and continues to add, processing logic and reporting to measure compliance with various ecosystem requirements (e.g., BRs, Root Store Operator policies, etc.). This logic heavily depends on data disclosed by CAs to the CCADB. One example is that CCADB will warn on any policy document that’s not been updated within the last year, in line with the expectations of Section 2 of the Baseline Requirements (e.g., TLS BRs). 

A simple way of thinking about the scope of “updated" is to consider the moment any data disclosed to the CCADB is no longer accurate (e.g., the in-force CP for a given PKI hierarchy is incremented from Version 1.1 to Version 1.2), it should be replaced with data that is accurate. 

(2) What does it mean for a superseded CP or CPS document whose details have not been removed from CCADB “to be authoritative”?

Technically, policy documents are not removed from the CCADB. A CA Owner can identify a policy document as non-current (i.e., they have been superseded by a newer version) by selecting a “Delete" button in an ‘Add/Update Root Request’ case, or by directly updating the ‘Policies and Practices Information’ fields on ICA records. Despite the current “Delete” label, the CCADB does retain a copy of the document for long term use. The CCADB Steering Committee plans to update this label as part of a larger enhancement request in the near future. 

For CP and CPS information, it’s possible (and sometimes even necessary) to add multiple entries. These entries can however also be removed at a later time. Consider the regular occurrence of a CA publishing a CPS update: What update are root stores / CCADB expecting out of these options: 

1. The new CPS should be added, and the old CPS should be deleted as it is no longer in effect for new certificate issuance.  
2. The new CPS should be added, but the old CPS should be kept in place as long as there are unexpired certificates under its policy. 
3. The new CPS should be added. Older entries should be kept indefinitely to serve as an archive overview.

The Chrome Root Program prefers CA Owners behave similar to #1, but as described above, “delete” is not the most appropriate term for the non-current versions of the policy documents. In actuality, the system behavior is more consistent with #3 due to document archive functionality.

Thank you

-Chris

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/915D2153-57F7-4340-A280-AAF3FAF998C8%40apple.com.

[Ben Wilson]

Hi Martijn,

I think the middle option is the best choice, and the first bulleted item is a second-best choice, although any of them are appropriate. CAs themselves are required by Item 7 of Section 3.3 of Mozilla Root Store Policy to maintain an archive of CPs and CPSes. They cannot rely on the CCADB for maintaining records of historic CPs and CPSes. It has been a very common practice to remove/delete outdated CPs and CPSes from being listed in the CCADB.

Thanks,

Ben

--

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/SA1PR17MB65036E72E1BCC94752CB7B53E3812%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Mike Shaver]

On Fri, Aug 16, 2024 at 7:15 PM Chris Clements <ccle...@google.com> wrote:

(e.g., the in-force CP for a given PKI hierarchy is incremented from Version 1.1 to Version 1.2), it should be replaced with data that is accurate. 

1. The new CPS should be added, and the old CPS should be deleted as it is no longer in effect for new certificate issuance.  
2. The new CPS should be added, but the old CPS should be kept in place as long as there are unexpired certificates under its policy. 
3. The new CPS should be added. Older entries should be kept indefinitely to serve as an archive overview.

The Chrome Root Program prefers CA Owners behave similar to #1, but as described above, “delete” is not the most appropriate term for the non-current versions of the policy documents. In actuality, the system behavior is more consistent with #3 due to document archive functionality.

OK, I may be confused here and talking nonsense, but I don’t think that there is necessarily (or even likely) a single in-force CP for a given PKI hierarchy at a given time. A policy is bound to a cert via the CPSUri when that cert is issued, and the policy relating to that cert is then immutably fixed. That’s why we’ve seen revocations necessary for certs issued in ways that didn’t match the contents of CPSUri at the time that the cert was issued, since the only way to remedy that is to issue an new cert bound to the updated policy.

At the moment that a new CPS comes into effect, it actually relates to _none_ of the live certs in the hierarchy, and depending on the update schedule for the CPS, it might not at any point even apply to a plurality of such live certs. CCADB should at least have all the CPS documents that apply to any live certs under a registered root, IMO, and they should all be treated as equally “active”.

Unfortunately, this weak binding (requires that a human go to a URL and pick the one that applies to the date range and cert type) sort of sucks in terms of clarity and garbage collection.

If I were designing this system now, I would probably make the rules be:

- CPS documents are markdown-enhanced text files

- each CPS gets a unique URL, ideally with a human-readable/collatable version number as a component

= either a content-addressable hash-carrying URL hierarchy hosted under ccadb.org, or

= is accompanied by a CPSHash property in the cert

- a CPS is marked “obsolete” or “expired” or whatever the definitions WG comes up with once there are no valid certs left that reference the CPS in question 

That would let the matching of applicable CPS to cert be mechanically performable, rather than the gross version-walking-in-an-HTML-index that has to happen now. Making it be markdown would mean fewer changes that are due to formatting, and improve the ease of mechanical analysis.

I’m squinting through some meaty jet lag so that proposed system probably has some issues, but I think that it’s important that we establish whether a CPS is per-cert, or per-hierarchy; if the latter, then maybe move it into the roots themselves and save some handshake bytes?

Mike

[Martijn Katerbarg]

Thank you all for the feedback so far. Firstly, I wanted to clarify that we’re aware that none of the data is ever really removed from CCADB. The mentions of deleting items in my original post referred to the CCADB option to mark them as deleted.

In response to Clint:

>I think it’s worth noting that 1 & 3 are, I believe, mostly the same; that is, Policy Documents marked as “Deleted” in the CCADB are not removed from the database.

The difference between these options that I was attempting to convey is that, in option 1, “old” CPSes are marked as deleted; whereas in option 3, they are not.  With that clarification, we take note that Apple sees option 1 as the preferred option at this moment.

Since Chris has expressed the same preference on behalf of the Chrome root program, would it be appropriate to declare that option 1 is the requirement?

>Regarding the “change log” sections of Policy Documents, I agree there’s not much specific guidance on what is desired or expected here. Both a summary of the changes and a list of sections in which changes occurred seem particularly valuable to me; are there any other suggestions or ideas from the community on this?

I think the recent changes in the Chrome Root Program Policy are a good step forward in resolving this. Specifically:

“To promote simplicity and clarity, these CA policy documents SHOULD be:
…..

available in Markdown.”

I presume this was added partially to aid in comparing different versions.

In response to Ben:

>I think the middle option is the best choice, and the first bulleted item is a second-best choice, although any of them are appropriate.

It seems Mozilla has a different preferred approach (Option #2), but does not set a hard requirement on this.

In response to Mike:

> I think the most common practice is 1, though?

Both options 1 and 2 seem to be common at present.

> = is accompanied by a CPSHash property in the cert

The CPSURI is not a required field for end-entity certificates, so I’m not sure any new CPSHash property would be a required field in the future.

> a CPS is marked “obsolete” or “expired” or whatever the definitions WG comes up with once there are no valid certs left that reference the CPS in question

While such an approach *might* work for the TLS WebPKI (though I’m not a fan of the approach), it might cause issues when looking at S/MIME and Code Signing, in which certificates are still useful after expiration. Different policies for TLS compared to other certificates seems like it would open the door to incorrect executions down the line. A unified approach here would be strongly preferred.

As some final thoughts to all:

It remains unclear if any of the root programs would categorise any of the 3 options as either MUST or MUST NOT. Currently, I’d summarise it as preferred approaches. Since the preferred approaches also do not fully align, would the CCADB Steering Committee be willing to discuss a singular, unified approach, and clarify the requirement in a future CCADB policy update?

Document archival for “deleted” CP/CPSes is only available for Root Certificates in CCADB, as far as we can tell. Many Intermediate Certificate records have “Same as Parent” set, but that is not the case for all. If “Same as Parent” is not set, the applicable CP/CPSes are entered via freeform text fields in the Intermediate Certificate record. As such, we currently understand that these fields should always have only the last published version listed (within 7 days after publication).

Regards,

Martijn

Op zaterdag 17 augustus 2024 om 11:03:02 UTC+2 schreef Mike Shaver:

[Dimitris Zacharopoulos (HARICA)]

Apologies for top-posting.

It's a bit unclear to me "why" this distinction (of a CP/CPS being declared as "deleted" or not in CCADB) is important. IMO this is a source of confusion and may lead to many different interpretations of the expectations.

A CP/CPS has an effective date, just like the BRs. When a new version of a CP/CPS is released, it has a new effective date. This doesn't mean the previous CP/CPS documents are not useful for a public PKI (either for TLS or Code Signing, S/MIME, etc), or that it should be marked as "deleted" or "obsolete".

As an example why old versions are useful, when a CA performs a Domain Validation, this is performed at time X and could be re-used for X+398 days. This means that a certificate for the same Domain Name could be issued with a CP/CPS  of version X, and a re-newed certificate could be issued under a newer CP/CPS but it would include a Domain Validation that was performed under the rules of a previous CP/CPS (at time X).

CCADB should try to keep things as simple as possible. When a new version of a CP, CPS, or a CP/CPS is uploaded, it should just add it to the "Repository" of documents associated with a certain CA. Relying Parties should know how to process and read these documents and how to process their effective dates. I don't think there is a need to flag a document "deleted" or "obsolete" because there are important elements in each CP/CPS version. As Ben highlighted, CAs are already required to publish all the versions of their CP/CPS documents on their public website. It would only make sense to flag a document in CCADB as "withdrawn" (or similar) to indicate that the information of that document is incorrect, or uploaded by mistake.

I also disagree with the complexity introduced by Martijn's suggestions. IMO simplicity should drive any rules around this issue.


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 on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/d71c388f-8853-4a4b-9d49-a9aa4635ef50n%40ccadb.org.

[Aaron Gable]

I agree that older versions of CP/CPS documents are important and useful, and ideally should be exposed for parties who want to see versions that were in effect when older certificates were validated or issued.

But the reality is that, for example, Let's Encrypt's CCADB pages were nearly unreadable due to the huge listing of historical CP/CPS documents. It was also incredibly difficult to tell which documents were relevant because we had made a change from separate CP and CPS to a combined CP/CPS. The UI simply displays all historical documents, with no ability to filter by when they were in force, and no ability to easily see which newer document replaced them. So we decided to go through and mark all historical versions of our documents as "deleted" to make the pages readable and usable again.

Ideally, there would be a nice in-between. But today, keeping many historical document versions active results in an unfortunate user experience.

Aaron

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/381e5c16-52ab-4ef7-9c0c-ede928dc0a4d%40harica.gr.

[Dimitris Zacharopoulos (HARICA)]

On 19/8/2024 6:23 μ.μ., 'Aaron Gable' via CCADB Public wrote:

I agree that older versions of CP/CPS documents are important and useful, and ideally should be exposed for parties who want to see versions that were in effect when older certificates were validated or issued.

But the reality is that, for example, Let's Encrypt's CCADB pages were nearly unreadable due to the huge listing of historical CP/CPS documents. It was also incredibly difficult to tell which documents were relevant because we had made a change from separate CP and CPS to a combined CP/CPS. The UI simply displays all historical documents, with no ability to filter by when they were in force, and no ability to easily see which newer document replaced them. So we decided to go through and mark all historical versions of our documents as "deleted" to make the pages readable and usable again.

Ideally, there would be a nice in-between. But today, keeping many historical document versions active results in an unfortunate user experience.

Would it make sense for CCADB to automatically mark a previous version as "superseded" when a new version is uploaded?

Dimitris.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAEmnErckLgLskiQUUzY7ATW6W%3DWfnzMw6GzJKEeh7yu6%2B9frVw%40mail.gmail.com.

[Martijn Katerbarg]

>I also disagree with the complexity introduced by Martijn's suggestions. IMO simplicity should drive any rules around this issue.

My tentative suggestions for tweaking the policy language are rather aimed at making things simpler by ensuring that each party is following the same practices, which is something that is currently not occurring. Fully agreed that simplicity is the way to go with this. Trying to establish with the root program owners what the current rules actually are, would be a first step forward in that process.

Op maandag 19 augustus 2024 om 19:50:59 UTC+2 schreef Dimitris Zacharopoulos (HARICA):

[Chris Clements]

Hi Martijn, et al., 

The CCADB Steering Committee had the opportunity to review and discuss the constructive feedback provided in this thread (thanks for that!). As previously hinted, we were planning to make some changes to policy document handling in the CCADB as a larger enhancement request, and this is an opportunity to collect some feedback.

Currently, new policy documents are always added as new records in the CCADB. References get added (A) to Root Certificate record(s) via an ‘Add/Update Root Request’ Case after a Root Store Operator syncs the information from the Case with the root record(s) (as they do today), or (B) directly on Intermediate Certificate records by CA Owners (as they are today).

Here is how we think publishing new policy documents (e.g., CP, CPS, or CP/CPS) could be handled in the CCADB going forward:

1. When a new policy document is added and associated with a Root Certificate record, if a previous version of that document exists (i.e., an earlier version of the policy document being added), we will expect that the previous version of that document would then be “superseded”. “Superseded” intends to avoid potential confusion from the existing term “Delete” and other suggested terms (i.e., “Archived”, “Obsolete”, “Withdrawn”, etc.), since previous policy documents can still be applicable in the ecosystem. Further:

• All policy document records would be updated in the CCADB to include a new field: Policy Document Superseded Date.

• During the “Add/Update Root Request” Case process, when adding a new policy document and associating it with applicable Root Certificate records, the CA Owner can select any existing policy document and click a new Supersede button to edit that document record and to specify the date it was superseded.

• When editing an existing policy document that has already been synced with Root Certificate record(s), only the Policy Document Superseded Date field can be edited.

• All fields for new policy documents that are being added to the Case can be edited until the Case is submitted for Root Store Operator review (as they are today). 

• During the deployment of this enhancement and for previously “Deleted” policy document records, we can set the Policy Document Superseded Date field to the Last Modified Date. CA Owners will have the ability to edit this date as needed on the policy document record.

• In the CCADB, the reference to a superseded policy document will behave the same as those that are “Deleted” today, with the various options that allow a user to hide or reveal superseded documents. 

• In an ‘Add/Update Root Request’ Case, a warning will be presented for existing policy documents that have not been superseded after 335 days. The warning will progress to an error at 365 days, aligned with the annual update requirement of Section 2 in the CA/Browser Forum’s TLS, S/MIME, and Code Signing Baseline Requirements. 

• In the CCADB, all references to policy documents on Root Certificate records will have a File Archive Association (as they do today). 

2. CA Owners can directly add and modify references to policy documents on their Intermediate Certificate records or identify the policy documents to be the same as the parent record (as they do today). Further:

• On the Intermediate Certificate record, we will add the ability to identify if the CP, CPS, or CP/CPS is the same as the parent record, rather than only having the ability to identify “CP/CPS same as parent”, which is today’s current state in the CCADB.

• When an Intermediate Certificate record is modified with policy document information and saved, that policy document will automatically be archived and identified as superseded. The Policy Document Superseded Date field will be populated on the archive record with the date the Intermediate Certificate record was modified and saved.

• On the Intermediate Certificate record, a warning will be presented for existing policy documents that have not been superseded after 335 days. A new warning will be presented at 365 days, aligned with the annual update requirement of Section 2 in the CA/Browser Forum’s TLS, S/MIME, and Code Signing Baseline Requirements.

These proposed changes have simplicity in mind, while also: 

1. allowing the CCADB to have similar logic of showing only the latest version of policy document(s) in default views;

2. providing more explicit “closure” for when a document has been superseded by another; and

3. avoiding confusion about a policy document having different states beyond effective and superseded. 

Again, we appreciate the feedback on this thread and value the community's perspective on this proposal.

Thank you

-Chris, on behalf of the CCADB Steering Committee

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/2c0b9fa9-cf19-4a74-8a09-b38f70fffa7dn%40ccadb.org.

[Mike Shaver]

I think this all makes sense, except for using the last-modified date to backfill the new “superseded” date. Unless it’s a practice to update a document itself when it is superseded by another, that last-modified is actually the date when it *started* to have effect, not when it ended. That would be pretty confusing!

Because of the mixture of doc types I’m not sure that you can get anything mechanically that approximates the superseding date, so it might just be better to leave that field empty/missing, and display it as “before Oct 31, 2024”, maybe linking to the document about putting this practice in place. I think it’s better to just admit that the system doesn’t know some of the dates than to make consumers try to figure out if the date is “real” or not.

Mike

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mDwnBM0B%2Bj8oAN-GdQ7EiMcTNVWOfzZQgsNSaeZO8u9Zw%40mail.gmail.com.

[Dimitris Zacharopoulos (HARICA)]

Thanks Chris and the CCADB Steering Committee for this proposed plan,

If I remember correctly, in the Add/Update Root Request when a CP/CPS document is added, there is a field indicating the effective date of that document. If CCADB could be automated to set this particular field as the "Policy Document Superseded Date" in the previous superseded documents, it would be very helpful and would ensure consistency between the latest and previous versions of the documents in the DB on the date issue.


Best regards,
Dimitris.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mDwnBM0B%2Bj8oAN-GdQ7EiMcTNVWOfzZQgsNSaeZO8u9Zw%40mail.gmail.com.

[Chris Clements]

Thank you both for the quick feedback! 

I think this all makes sense, except for using the last-modified date to backfill the new “superseded” date. Unless it’s a practice to update a document itself when it is superseded by another, that last-modified is actually the date when it *started* to have effect, not when it ended. That would be pretty confusing! 

 

Because of the mixture of doc types I’m not sure that you can get anything mechanically that approximates the superseding date, so it might just be better to leave that field empty/missing, and display it as “before Oct 31, 2024”, maybe linking to the document about putting this practice in place. I think it’s better to just admit that the system doesn’t know some of the dates than to make consumers try to figure out if the date is “real” or not.

The "Policy Document Superseded Date" field would appear on all policy document records as a new field, but we were proposing populating it with the "Last Modified Date" only for those policy document records that were previously marked as “Deleted”. This would represent when the CA Owner last edited the policy document record through their action of selecting “delete”. Policy document records that were not marked as deleted would not have a value for "Policy Document Superseded Date" and would continue to be visible in the Case UI. CA Owners could mark those records as superseded at any point in the future.

If I remember correctly, in the Add/Update Root Request when a CP/CPS document is added, there is a field indicating the effective date of that document. If CCADB could be automated to set this particular field as the "Policy Document Superseded Date" in the previous superseded documents, it would be very helpful and would ensure consistency between the latest and previous versions of the documents in the DB on the date issue.

Your recollection is correct. This approach could be viable for CA Owners who utilize the same URL for the “Document Link”, but that is atypical and the CCADB would not otherwise be able to understand the relationship between the multiple policy document records.

Another approach we could consider would be when the CA Owner selects any existing policy document record in the Case UI and clicks the new “Supersede” button the "Policy Document Superseded Date" field could auto populate with the current date. We previously proposed clicking this button would require the CA Owner to manually select the date, but maybe we auto populate the date and still offer the CA Owner the ability to edit it, if needed.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/6b3629ad-d975-447f-b3b2-e1c3e162c191%40harica.gr.

[Dimitris Zacharopoulos (HARICA)]

On 28/8/2024 10:58 μ.μ., 'Chris Clements' via CCADB Public wrote:

If I remember correctly, in the Add/Update Root Request when a CP/CPS document is added, there is a field indicating the effective date of that document. If CCADB could be automated to set this particular field as the "Policy Document Superseded Date" in the previous superseded documents, it would be very helpful and would ensure consistency between the latest and previous versions of the documents in the DB on the date issue.

Your recollection is correct. This approach could be viable for CA Owners who utilize the same URL for the “Document Link”, but that is atypical and the CCADB would not otherwise be able to understand the relationship between the multiple policy document records.

Some CAs have a URL pointing always to the "latest version" of the corresponding document but I believe the guidance from the CCADB steering committee was to link to a specific version of the document. Is it ok for CAs to add URLs that point to the "latest version" of the document?

Another way to flag a specific document, is by title. If a CA uses multiple documents, each document must have a distinct name, and for this name, a specific version. Let's assume the CA has a document named "MyCA Certificate Policy Document" and "MyCA Certification Practice Statement Document". When the CA updates the version of "MyCA Certificate Policy Document" it must include the effective date, which could be correlated with the at-the-time current version of the document with the same title, and set the "Policy Document Superseded Date" automatically. The other document would remain unchanged. It sounds complicated but I think it's worth the effort to avoid mix-ups with dates which may cause unintended incidents/policy violations.

Another approach we could consider would be when the CA Owner selects any existing policy document record in the Case UI and clicks the new “Supersede” button the "Policy Document Superseded Date" field could auto populate with the current date. We previously proposed clicking this button would require the CA Owner to manually select the date, but maybe we auto populate the date and still offer the CA Owner the ability to edit it, if needed.

I understand the complexity when multiple CP or CPS documents exist. The last approach sounds risky because a CA Owner might overlook and not set the correct field. Usually it takes a few days between the creation of a new version of a CP/CPS and the update in CCADB so the "current date" will be an incorrect default most of the time. If there is no way to correlate the superseded with the updated CP/CPS effective date, I think it's better to leave it blank.

Thanks,
Dimitris.

[Chris Clements]

Thanks for the feedback, Dimitris.

Some CAs have a URL pointing always to the "latest version" of the corresponding document but I believe the guidance from the CCADB steering committee was to link to a specific version of the document. Is it ok for CAs to add URLs that point to the "latest version" of the document?

Currently, we see some CA Owners using a URL with a specific version of the document and others using a URL that points to where the latest version of the document can be found. Both are acceptable. The POLICY DOCUMENTS guide states: "If the link to your CA’s most current policy document remains constant, then you can simply edit the document object to update the date, add policy identifiers, update comments, and update the list of applicable root certificates."

I understand the complexity when multiple CP or CPS documents exist. The last approach sounds risky because a CA Owner might overlook and not set the correct field. Usually it takes a few days between the creation of a new version of a CP/CPS and the update in CCADB so the "current date" will be an incorrect default most of the time. If there is no way to correlate the superseded with the updated CP/CPS effective date, I think it's better to leave it blank.

We agree with the approach of leaving the field blank to reduce risk. We’ll look for additional opportunities for automation in the future.

--
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/c5a54377-df08-4ed5-8131-b7d2021f22cd%40harica.gr.

[Mike Shaver]

On Thu, Sep 5, 2024 at 3:23 PM 'Chris Clements' via CCADB Public <pub...@ccadb.org> wrote:

Currently, we see some CA Owners using a URL with a specific version of the document and others using a URL that points to where the latest version of the document can be found. Both are acceptable. The POLICY DOCUMENTS guide states: "If the link to your CA’s most current policy document remains constant, then you can simply edit the document object to update the date, add policy identifiers, update comments, and update the list of applicable root certificates."

Naive question: if a policy document can change without the URL changing, how does one find the policy under which a given certificate was issued? Doesn't cpsUri have to point to the policy that governed the issuance of the certificate?

Mike

 

[Clint Wilson]

In the context of the TLS and S/MIME Baseline Requirements, the cPSuri is not required to point to the specific document(s) which govern the certificate in which it may be found. The requirement is only that the cPSuri contain a "HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA”.

As far as I understand, CA/B Forum Guideline documents don’t require CAs to maintain availability of CPs/CPSes which are not currently authoritative for the issuance of new certificates. Root Programs do require maintenance of such an archive [1] and the CCADB’s (alongside incorporating Root Program Policies') requirement for disclosure of all CPs/CPSes [2] effectively creates a secondary, consistently structured source of this archive. In theory (and often in practice), the cPSuri should at minimum point to a repository containing the archive of active and historical (but still authoritative) CPs/CPSes, but it may be a substantial amount of effort to identify the document(s) governing any given leaf certificate. Part of the intent with the CCADB storing the effective date, and superseded date in the future, is to make it a little bit easier for relying and interested parties to find and validate that information — hopefully improving the overall situation your (not naive, imo) question highlights.

It’s also worth pointing out that including the cPSuri is not recommended and generally provides very little practical value. That could be changed and improved, but given the current direction of managing CAs and their policies at scale, I suspect such efforts may not be exceptionally fruitful.

Cheers,

-Clint 

[1] - https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses

[2] - https://www.ccadb.org/policy#5-policies-audits-and-practices

--
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/CADQzZquKwxKpJDfii7_ixs_zpZRqho9iuBp5-r9s_pgbLU9H2w%40mail.gmail.com.

[Clint Wilson]

Hi All,

The CCADB Steering Committee plans to move forward with introducing the changes described below by Chris [1] into the production instance of the CCADB. There are semi-related future enhancements we hope to make beyond the scope of these near-term changes that we expect will further address areas of inconsistency, confusion, and/or transparency that are currently lacking. For now, if there are any final points of feedback folks would like to make, please do so as soon as possible.

Thank you!

-Clint

[1] - https://groups.google.com/a/ccadb.org/g/public/c/CIR6vB52Z-g/m/91ZZ3e9vCgAJ

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/9C03D8B5-C6E1-4AA6-9BFF-471E33E4D119%40apple.com.

[Rob Stradling]

Thanks Clint, Chris et al.

> On the Intermediate Certificate record, we will add the ability to identify if the CP, CPS, or CP/CPS is the same as the parent record, rather than only having the ability to identify “CP/CPS same as parent”, which is today’s current state in the CCADB.

Please could you also reflect this enhancement in https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatv2 somehow?

One further thought...

How are CA Owners expected to populate the single "CP/CPS Last Updated Date" field on an Intermediate Certificate record when multiple non-superseded policy documents are applicable, each of which could have been updated on different dates?

Should "Last Updated Date" become a per-document field instead?

---

From: 'Clint Wilson' via CCADB Public
Sent: Thursday, September 19, 2024 23:24
To: public
Cc: Mike Shaver; Chris Clements; Dimitris Zacharopoulos (HARICA); Clint Wilson
Subject: Re: Questions regarding which policy documentation to keep in CCADB

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/067DEA69-2F04-4C52-B771-A2706FF8525E%40apple.com.

[Ben Wilson]

Hi Rob,

There will be three fields for "Last Updated Date" --one for CP, one for CPS, and one for CP/CPS.

Ben

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB4729B42F59C16FEA6D600DF9AA6C2%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Rob Stradling]

Great.  That works.  Thanks Ben.

Please add those fields to https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatv2 too.

---

From: 'Ben Wilson' via CCADB Public <pub...@ccadb.org>
Sent: 20 September 2024 15:47
To: Rob Stradling <r...@sectigo.com>
Cc: public <pub...@ccadb.org>; Clint Wilson <cli...@apple.com>; Mike Shaver <mike....@gmail.com>; Chris Clements <ccle...@google.com>; Dimitris Zacharopoulos (HARICA) <dzac...@harica.gr>

Subject: Re: Questions regarding which policy documentation to keep in CCADB

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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

[Rob Stradling]

> Please add those fields to https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatv2 too.

Just chasing up on this...

CCADB records that formerly had "CP/CPS Same as Parent" ticked now have "CP Same As Parent" and "CPS Same As Parent" ticked but, crucially, "CP/CPS Same As Parent" has been unticked.

AllCertificateRecordsCSVFormatv2 still only includes the "CP/CPS Same As Parent" field, which has been set to "false" for almost all Intermediate Certificate records.  Consequently, crt.sh's "incomplete disclosure" tracking (e.g., https://crt.sh/mozilla-disclosures#disclosureincompletesummary) has gone haywire, false positively flagging nearly every intermediate certificate.

Please append the following fields to AllCertificateRecordsCSVFormatv2 as soon as possible:

• "CP Same As Parent"
• "CPS Same As Parent"
• "CP Last Updated"
• "CPS Last Updated"

Thanks!

---

From: 'Rob Stradling' via CCADB Public <pub...@ccadb.org>
Sent: 20 September 2024 16:33
To: Ben Wilson <bwi...@mozilla.com>

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB472974C25744C4D3260C142CAA6C2%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Chris Clements]

Thanks for calling attention to these two issues Rob. We'll investigate and respond.  

-Chris

[Chris Clements]

CCADB records that formerly had "CP/CPS Same as Parent" ticked now have "CP Same As Parent" and "CPS Same As Parent" ticked but, crucially, "CP/CPS Same As Parent" has been unticked.

These values have been restored.

Please append the following fields to AllCertificateRecordsCSVFormatv2 as soon as possible:
"CP Same As Parent"
"CPS Same As Parent"
"CP Last Updated"
"CPS Last Updated"

These have been appended to the AllCertificateRecordsCSVFormatv2 report. We've also appended the "Certificate Practice & Policy Statement" field, which can be used in the future to describe the location of a combined CP/CPS. 

We'll plan to convey the larger policy document related enhancement separately in the future, but hopefully restoring the "CP/CPS Same as Parent" values and appending the report resolves the crt.sh "incomplete disclosure" tracking issue. Thanks again, Rob!

[Rob Stradling]

Hi Chris.  Thanks for the quick action!

I've implemented corresponding updates to the code that produces crt.sh's CCADB disclosure pages.  There are now fewer false positives!  🙂

One further issue I've noticed is that CP/CPS policy document URLs from Root Certificate records currently appear in the "Certificate Practice Statement (CPS) URL" field in the CSV file rather than the "Certificate Practice & Policy Statement" field.  But perhaps your "larger policy document related enhancement separately in the future" already plans to address this?

---

From: Chris Clements <ccle...@google.com>
Sent: 25 September 2024 20:07
To: Rob Stradling <r...@sectigo.com>
Cc: Ben Wilson <bwi...@mozilla.com>; public <pub...@ccadb.org>; Clint Wilson <cli...@apple.com>; Mike Shaver <mike....@gmail.com>; Dimitris Zacharopoulos (HARICA) <dzac...@harica.gr>

[Chris Clements]

One further issue I've noticed is that CP/CPS policy document URLs from Root Certificate records currently appear in the "Certificate Practice Statement (CPS) URL" field in the CSV file rather than the "Certificate Practice & Policy Statement" field.  But perhaps your "larger policy document related enhancement separately in the future" already plans to address this?

Correct on both accounts. This issue (which existed before the recent update) was one of the drivers for creating the new fields and we expect the upcoming enhancement to resolve it.