| ▲ | hamdingers 10 hours ago | ||||||||||||||||||||||
It's actually 6 and 2/3rds! I'm trying to figure out a rationale for 160 hours and similarly coming up empty, if anyone knows I'd be interested. 200 would be a nice round number that gets you to 8 1/3 days, so it comes with the benefits of weekly rotation. | |||||||||||||||||||||||
| ▲ | mcpherrinm 7 hours ago | parent | next [-] | ||||||||||||||||||||||
I chose 160 hours. The CA/B Forum defines a "short-lived" certificate as 7 days, which has some reduced requirements on revocation that we want. That time, in turn, was chosen based on previous requirements on OCSP responses. We chose a value that's under the maximum, which we do in general, to make sure we have some wiggle room. https://bugzilla.mozilla.org/show_bug.cgi?id=1715455 is one example of why. Those are based on a rough idea that responding to any incident (outage, etc) might take a day or two, so (assuming renewal of certificate or OCSP response midway through lifetime) you need at least 2 days for incident response + another day to resign everything, so your lifetime needs to be at least 6 days, and then the requirement is rounded up to another day (to allow the wiggle, as previously mentioned). Plus, in general, we don't want to align to things like days or weeks or months, or else you can get "resonant frequency" type problems. We've always struggled with people doing things like renewing on a cronjob at midnight on the 1st monday of the month, which leads to huge traffic surges. I spend more time than I'd like convincing people to update their cronjobs to run at a randomized time. | |||||||||||||||||||||||
| ▲ | dtech 10 hours ago | parent | prev [-] | ||||||||||||||||||||||
It's less than 7 exactly so you cannot set it on a weekly rotation | |||||||||||||||||||||||
| |||||||||||||||||||||||