10 ms·

https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/ https://www.chromium.org/Home/chromium-security/root-ca-poli... > *a re

https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/ https://www.chromium.org/Home/chromium-security/root-ca-poli... > *a reduction of TLS server authentication subscriber certificate maximum validity from 398 days to 90 days*. Reducing certificate lifetime encourages automation and the adoption of practices that will drive the ecosystem away from baroque, time-consuming, and error-prone issuance processes. These changes will allow for faster adoption of emerging security capabilities and best practices, and promote the agility required to transition the ecosystem to quantum-resistant algorithms quickly. Decreasing certificate lifetime will also reduce ecosystem reliance on “broken” revocation checking solutions that cannot fail-closed and, in turn, offer incomplete protection. Additionally, shorter-lived certificates will decrease the impact of unexpected Certificate Transparency Log disqualifications. Edit to add that the above is under the following, > *In a future policy update or CA/Browser Forum Ballot Proposal, we intend to introduce:*

xyzzy123 4y ago
Like most engineering choices it has upsides and downsides. I'm personally "pro choice" here and in favour of allowing system operators to decide how much and what kind of automation makes sense for them. TLS vulns in general are likely to need a server software or config upgrade in response, automated re-issuance is nice but doesn't significantly reduce overall toil. Revocation being "generally broken" sucks, but is not on my personal "top 50 security problems" that I care about. What very short lived certs do is create a tight runtime dependency between all deployed infrastructure working and JIT cert issuance systems & refresh code. IMHO this has analogous risks and benefits to JIT supply chains in real-world contexts. For some op models IMHO it IS better for a human to just put the thing on the server every year or two.

xyzzy123 4y ago

Like most engineering choices it has upsides and downsides. I'm personally "pro choice" here and in favour of allowing system operators to decide how much and what kind of automation makes sense for them. TLS vulns in general are likely to need a server software or config upgrade in response, automated re-issuance is nice but doesn't significantly reduce overall toil. Revocation being "generally broken" sucks, but is not on my personal "top 50 security problems" that I care about. What very short lived certs do is create a tight runtime dependency between all deployed infrastructure working and JIT cert issuance systems & refresh code. IMHO this has analogous risks and benefits to JIT supply chains in real-world contexts. For some op models IMHO it IS better for a human to just put the thing on the server every year or two.