On Fri, Jun 06, 2025 at 04:28:02PM -0700, 'Aaron Gable' via dev-security-policy@mozilla.org wrote: > 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.
[...] > 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". To be clear, either of these fixes would have been sufficient, correct? (A useful adjunct to (1) would have been a lint to ensure that the issued certificate did, indeed, match the requirements of the CPS with regards to validity period). > 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"! Is it, though? Marketing materials, end-user documentation, sure, go with 90 days, it's close enough for government work. In a CPS, though, correctness matters. If a CPS says "we will not issue a certificate for more than 90 days", then the sort of weirdo that actually reads CPSes might come to rely on that, for some reason, and failing to abide by that might potentially cause some sort of problem. By being "looser" with the CPS language, you're ensuring that (absent Hyrum's Law, violation of which is not listed in 4.9.1.1) nobody comes to rely on a behaviour which turns out to not be valid. > 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, I think there's a case to be made, in the leap second example particularly, that the cause of that issue would be a *lack* of second-precision validity period. "90 days" is ambiguous in its mapping to the actual certificate contents. If the CPS said "we will not issue a certificate with a validity period of greater than 7,776,000 seconds", then it would be easier to map that to a lint, which would prevent misissuance. Being so precise might also have triggered the thought "hey, does 'not before' and 'not after' mean that it's valid *at* those times?", catching the actual problem LE saw, in advance. > 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. The problem of woefully under-specified CPSes is a big one, and it's something that does need attention. But I'd prefer a CPS that was looser over one which was specific but wrong, because at least then I know when I'm entering mysterious, unexplored lands. Like Majikthise and Vroomfondel, I demand rigidly defined areas of doubt and uncertainty. Your examples are nicely illustrative of the value of this principle. If a CPS specifies that cert serials have (say) 64 bits of entropy, I might decide that's not enough to stop some attack I'm worried about, and I'll decide to implement additional mitigations. If you *actually* have, say, 100 bits, then no harm done -- I'm doubly protected. But if you claim to have 100 bits, I might decide to not implement that additional mitigation, figuring the 100 bits protects me. If you then fail to have 100 bits, I'm toast. Similarly, for OCSP/CRL URLs, if your CPS says "here they are", I might forego the extra coding effort required to, say, pull them out of each individual certificate I'm looking at, because hey, they're in the CPS, they can't change without notice. If the CPS didn't specify them, then yeah, I'd have to take the extra time to do it properly, but at least when you go and change the URLs, everything still works. > I don't love this situation. I'd much prefer for LE's CPS to be *precise* as > well as accurate. There's a concept in physics (which I will admit I have not seriously studied in some years, so my explanation might be a little fuzzy) of "excessive precision". The idea is that, when making measurements, estimates, and such like, that it is possible to be *too* precise, and that this is problematic for various reasons -- not least of which is people see the unnecessary precision and think it's more meaningful than it is. I make this observation to note that, while precision in a CPS is a good property to have, being overly precise has its own downsides (beyond the need for occasional mass-revocations). > But the risk of tiny errors creeping into a > human-maintained, non-machine-readable document is simply too high. I don't concede that a CPS is any more vulnerable to errors than anything else we fallible meat sacks touch. Errors creep into anything that humans have anything at all to do with. We deal with it by having things like change control and review, redundancy, and "closed-loop" feedback systems. Without such controls, it would be entirely possible for someone to make the "tiny error" of changing the validity period value in a cert profile to change the leading '7' in '7,776,000' to a '9', making for some CPS-violating certificates. I'm guessing that LE probably has about 17 different ways in which that that error would be identified before a "live" certificate went out, even though it's a tiny, single character error. - Matt -- 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/76dc881d-adf8-472c-829b-75a4378d1d2e%40mtasv.net.
