x509 writes time in stringish way (see asn.1 UTCtime /generalizedtime) so leaf notafter theoretically can injected between notbefore and notafter after certificate is signed.
A day for certificate perpose is defined as 86,400 seconds (BR 6.3.2) On 2025년 6월 7일 오후 1시 49분 12초 GMT+09:00, Matt Palmer <[email protected]> 작성함: >On Fri, Jun 06, 2025 at 04:28:02PM -0700, 'Aaron Gable' via >[email protected] wrote: >> Just my personal 2c on the CPS conversation: >> >> On Thu, Jun 5, 2025 at 7:43 AM Mike Shaver <[email protected]> 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 a topic in the Google >Groups "[email protected]" group. >To unsubscribe from this topic, visit >https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/TqTpdOtOxfs/unsubscribe. >To unsubscribe from this group and all its topics, send an email to >[email protected]. >To view this discussion visit >https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/76dc881d-adf8-472c-829b-75a4378d1d2e%40mtasv.net. -- 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/89ABABE9-25D3-4918-A680-EB9FDE073C4E%40gmail.com.
