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 <https://cabforum.org/working-groups/server/baseline-requirements/requirements/#2-publication-and-repository-responsibilities> ). 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 <https://docs.google.com/document/d/1qAVihgbo7TuH3xqq2zbxhxHajQnJwbHUGEFf2VjxoZQ/edit#heading=h.upew9wcirumy>" 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 On Fri, Aug 16, 2024 at 1:05 PM 'Clint Wilson' via CCADB Public < [email protected]> wrote: > 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 > > On Aug 16, 2024, at 4:25 AM, Mike Shaver <[email protected]> wrote: > > On Fri, Aug 16, 2024 at 7:10 AM 'Martijn Katerbarg' via CCADB Public < > [email protected]> 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 > > >> - >> >> >> - >> >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqsV%2BOdGz3DZMy2ZPOiXo64DBDW7AB--ctauEBafJFE1uw%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqsV%2BOdGz3DZMy2ZPOiXo64DBDW7AB--ctauEBafJFE1uw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > 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 [email protected]. > 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 > <https://groups.google.com/a/ccadb.org/d/msgid/public/915D2153-57F7-4340-A280-AAF3FAF998C8%40apple.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mDk%3DYPiDEepC2J2tUmAYt3OZ%2Bs_YZatU%3DfsCTdot6UJmg%40mail.gmail.com.
