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 On Tue, Aug 27, 2024 at 10:41 AM 'Chris Clements' via CCADB Public < [email protected]> wrote: > 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 > > > On Tue, Aug 20, 2024 at 3:30 AM 'Martijn Katerbarg' via CCADB Public < > [email protected]> wrote: > >> >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): >> >>> >>> >>> 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. >>> >>> >>> Aaron >>> >>> On Mon, Aug 19, 2024, 08:11 'Dimitris Zacharopoulos (HARICA)' via CCADB >>> Public <[email protected]> wrote: >>> >>>> 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. >>>> >>>> >>>> >>>> On 19/8/2024 5:00 μ.μ., 'Martijn Katerbarg' via CCADB Public wrote: >>>> >>>> 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: >>>> >>>>> On Fri, Aug 16, 2024 at 7:15 PM Chris Clements <[email protected]> >>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>> 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/d71c388f-8853-4a4b-9d49-a9aa4635ef50n%40ccadb.org >>>> <https://groups.google.com/a/ccadb.org/d/msgid/public/d71c388f-8853-4a4b-9d49-a9aa4635ef50n%40ccadb.org?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/381e5c16-52ab-4ef7-9c0c-ede928dc0a4d%40harica.gr >>>> <https://groups.google.com/a/ccadb.org/d/msgid/public/381e5c16-52ab-4ef7-9c0c-ede928dc0a4d%40harica.gr?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/CAEmnErckLgLskiQUUzY7ATW6W%3DWfnzMw6GzJKEeh7yu6%2B9frVw%40mail.gmail.com >>> <https://groups.google.com/a/ccadb.org/d/msgid/public/CAEmnErckLgLskiQUUzY7ATW6W%3DWfnzMw6GzJKEeh7yu6%2B9frVw%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/2c0b9fa9-cf19-4a74-8a09-b38f70fffa7dn%40ccadb.org >> <https://groups.google.com/a/ccadb.org/d/msgid/public/2c0b9fa9-cf19-4a74-8a09-b38f70fffa7dn%40ccadb.org?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/CAAbw9mDwnBM0B%2Bj8oAN-GdQ7EiMcTNVWOfzZQgsNSaeZO8u9Zw%40mail.gmail.com > <https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mDwnBM0B%2Bj8oAN-GdQ7EiMcTNVWOfzZQgsNSaeZO8u9Zw%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/CADQzZquzoOXEKDFCgrJUnpHYOLBPJQUZtJy7-Ws269vLU033_w%40mail.gmail.com.
