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