I don't think OV vs. DV makes much of a difference from a CPS perspective as most of the CPS document is about the processes and security involved in running a CA, not validating the entity behind a cert. There's only two sections involved in identity (3.2.3 and 3.2.5) compared to domain validation.
I definitely would support seeing more description in CPS docs around what's automated vs. human performed. It's a good place to start. On Sun, Jun 8, 2025 at 10:59 AM Watson Ladd <[email protected]> wrote: > 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 > . > -- 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/CAFK%3DoS9pdVo2LJQNWz5%2B0LCd%2BfOfNDr5XiyXikizgJeHdEpRcg%40mail.gmail.com.
