Just my personal 2c on the CPS conversation: On Thu, Jun 5, 2025 at 7:43 AM Mike Shaver <mike.sha...@gmail.com> wrote:
> The idea that requiring CPS correctness will be a "race to the bottom" is > similarly difficult for me to understand. The entire point of exceeding the > BRs is so that relying parties can depend on the things that a CA does that > exceed the BR minimum. Relying parties can only depend on those things if > they are reliably represented (by reference) in the certificate involved in > the trust decision. It's a race to the bottom if the industry *doesn't* > take material CPS error seriously, because then relying parties actually > *can't* depend on anything but the minimum of the BRs, regardless of what a > CA might want to claim in the certificates they issue. > I'll give a concrete example of how the current system means that CPSes have to be more general than we'd like: the Let's Encrypt 90 Days + 1 Second incident. Let's Encrypt thought that we were doing the right thing, by saying in our CPS that our certificates were valid for 90 days. That's an accurate, human-readable description of how the CA's certificates are compliant with the BRs' requirement that they be valid for 398 days or less. But then it turned out that the certificates were actually valid for 1 second more than 90 days. To be clear, this was a real error, and it exposed a real misunderstanding of how x509 validity periods work (inclusive of their end time). But the fix for that mistake was twofold: 1) Fix the issuance code to reduce the validity period of all certificates by one second; *and* 2) Change the CPS to say "less than 100 days". Are LE certs valid for less than 100 days? Yes, it's a true statement. But it's not an *optimally* *useful* statement -- the thing a human wants to read in that document is "90 days"! But we can't ever say "90 days" in our CPS ever again, just in case there's some other tiny error. Does some definition buried three RFCs deep mean that we're actually off every time IERS decides to insert a leap second? I strongly believe the answer is no, but the example is still illustrative. There are very strong incentives for CAs to write CPSes that are still "looser" than their actual practices: don't give a second-precision validity period, don't say exactly how many bits of entropy are in your serial, don't over-specify your OCSP or CRL URLs in case your CDN setup changes, etc. The cost to a CA of having an overly-specific CPS is mass revocations (which are not a punishment, but are undoubtedly a cost). The cost to a CA of having an under-specified CPS is, currently, nothing. I don't love this situation. I'd much prefer for LE's CPS to be *precise* as well as accurate. But the risk of tiny errors creeping into a human-maintained, non-machine-readable document is simply too high. Aaron -- 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/CAEmnErd0eBx2r%3DFtLVvm0BxJ%2BqHdVwVMebYhc%3DE3_4eDq%3Dr%2BPw%40mail.gmail.com.
