I must object to the attitude CAs seem to have against ”anonymous” accounts on Bugzilla. I think it must be hard to avoid noticing ”Wayne” on Bugzilla, who has been very active and asked many (understatement) questions. I understand that from the perspective of having to answer those questions it can sometimes be uncomfortable because experience has shown us that they often highlight shortcomings. But this would only be problematic for a CA if that CA were not committed to the principles of the webPKI community, and instead had other priorities.
I find it quite distasteful that some seem to have such low regard for community participants just because they choose to operate under a pseudonym. Best regards Zacharias On Sat, 7 Jun 2025 at 08:37, Seo Suchan <tjtn...@gmail.com> wrote: > 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 <mpal...@hezmatt.org> > 작성함: > >> 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/89ABABE9-25D3-4918-A680-EB9FDE073C4E%40gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/89ABABE9-25D3-4918-A680-EB9FDE073C4E%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAKDW-Ue3rbTcT5pAXwNySdmxrtvQqhCmGviCQTKoGpxCGUb87A%40mail.gmail.com.
