Astra mortemque praestare gradatim On Sun, Jun 8, 2025, 10:44 AM Jeremy Rowley <rowley...@gmail.com> wrote:
> 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. > It's definitely been a source of incidents such as the Bremerhaven is not in Saxony one. > > I definitely would support seeing more description in CPS docs around > what's automated vs. human performed. It's a good place to start. > As some CAs has noted this would mean process improvements have to be rolled out with CPS changes, with a big revocation as the "prize" for messing up. Now obviously there's a degree to which the process is the product here, and proper identification of what process was in place at a time is essential. But at the same time the incentives towards vaguness are bad. > On Sun, Jun 8, 2025 at 10:59 AM Watson Ladd <watsonbl...@gmail.com> wrote: > >> On Sat, Jun 7, 2025 at 2:33 PM Ryan Hurst <ryan.hu...@gmail.com> 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 "dev-security-policy@mozilla.org" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to dev-security-policy+unsubscr...@mozilla.org. >> > 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 >> "dev-security-policy@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-policy+unsubscr...@mozilla.org. >> 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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACsn0ckZ1YMTe2T1FZEXqbi5H7Bbpn9Zse6vqnxHBrn5_dfKHg%40mail.gmail.com.
