On Sat, Jun 7, 2025 at 2:33 PM Ryan Hurst <[email protected]> wrote: > > Aaron's "90 days + 1 second" example perfectly illustrates the point I was > making originally. This wasn't a documentation typo - it revealed a > fundamental gap between intended practice and actual implementation. The > response of changing the CPS to "less than 100 days" is exactly the race to > the bottom I'm concerned about. > > When Aaron says "we can't ever say 90 days in our CPS ever again," that's the > perverse incentive in action. We're pushing CAs to make their public > commitments vaguer rather than pushing them to invest in systems that ensure > those commitments are reliable. This is the problem we need to fix with > better processes and automation, not with less enforceable and less useful > governance. > The thread also reveals a troubling pattern. > > We hear about "good faith errors" and inevitable human mistakes in this > space constantly, yet this is an industry that has automated domain > validation, linting of issued certificates, logging all issuance on the web > via certificate transparency, and manages very large-scale cryptographic > operations for the world. The claim that policy compliance checking can't be > similarly automated doesn't hold up to scrutiny.
Let's start with disclosing which checks in the certificate issuance process are done by humans. What's become clear over a number of incidents is that CAs can have very low degrees of automation, creating the kind of situation where humans will have to be on the lookout for a slight abnormality among hundreds or thousands of other things, over 40 hours a week. That's not something humans can do. We really need to fix this as a community. These security relevant differences aren't in the CPS, audit reports or discussed in root program addition bugs. It does seem that we're barely able to get commitments to the bare minimum of BR requirements, rather than CAs working to improve their processes and policies. > > What we need is to stop treating CPSs as compliance artifacts written after > the fact and start making them operational documents that sit at the center > of how CAs work. A properly designed CPS should be machine-readable on one > side - directly governing issuance systems and preventing the very mismatches > we're debating - while remaining human-readable on the other for auditors and > relying parties. This is actually possible today; we just need to care enough > to do it. For DV yes, maybe. For OV and up it's going to be a harder slog. I do however think that there's a very real human element here in assessment. > > After 30 years in this space, I can't look at most CPSs and understand what a > CA actually does. But instead of accepting this as inevitable, we should be > demanding that these documents serve their intended purpose: clearly > communicating operational reality to everyone who needs to understand it. > > There are 8 billion people depending on this system. Are we really going to > allow fewer than 50 root CAs to keep treating their public commitments as > legal paperwork instead of operational specifications? > > The solution isn't weaker enforcement - it's making CPSs the living center of > CA operations, where policy drives practice instead of scrambling to document > it afterward. > > Ryan > > -- > You received this message because you are subscribed to the Google Groups > "[email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwbvoJQ%2BBSMVEsx4YJm-T3uyggu7YAY_z79aoXf_e3pXoA%40mail.gmail.com. Astra mortemque praestare gradatim -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0cmc5mKcKbLYZMQdP_-1jcyqqi0_wqXhmpCBRNqp%2BG2oxA%40mail.gmail.com.
