On Thu, Dec 12, 2024 at 7:30 AM Hanno Böck <[email protected]> wrote: > > I hope this is a good place to share these thoughts, but given it's the > "all things CA" discussion place, it seems to fit. > > In a recent post, Let's Encrypt mentions plans for very-short-lived > certificates with a lifetime of 6 days: > https://letsencrypt.org/2024/12/11/eoy-letter-2024/ > There have been other discussions going in similar directions, e.g., > a proposed 45 days cap on certs. > > I have some concerns with this direction. I think there were good > reasons to shorten certificate lifetimes in the past. Not having > multi-year certificates is a good thing, as we no longer have > multi-year transition periods to flush out things from the ecosystem. > It's probably also good to shorten cert lifetimes to values that > strongly encourage automation. > > I get why people want even shorter certs. People have been trying to > fix revocation, and I think everyone eventually got to the conclusion > that fixing revocation is hard. Replacing revocation with very short > certs is a natural idea. > But I think there's a point where the benefits of even shorter > lifetimes should be balanced against some downsides. > > One of the biggest improvements in the WebPKI/CA ecosystem in recent > years was the introduction of Certificate Transparency. And one of the > things CT has brought us was that it allows many people to monitor the > WebPKI ecosystem for irregularities. > > But that, of course, relies on people actually doing that. And > monitoring CT becomes more challenging with increasing volumes of > certificates. > > The volume of CT-logged certs is already enormous, and it's already > challenging to deal with this. I'm, e.g., scaninng CT-logged certs for > compromised keys. > > Many rely not on actually reading CT logs, but utilize crt.sh. It is > great that this service exists, but I'd like to point out the following: > * There's currently no other service like crt.sh. It's essentially a > single point of failure of a lot of "WebPKI security stuff" people do. > * crt.sh is experiencing challenges with availability and cert > backlogs, likely because dealing with this volume is challenging. > > In essence, many of us (me included) rely on crt.sh doing the hard work > to deal with CT logs. > > Imagining something like a more than 10x increase in cert volumes (which > would be the consequence of 6-day certs as the norm) probably means > many people will just stop utilizing CT to find security issues in the > WebPKI ecosystem. Add to that the fact that, depending on how fast the > Quantum Cryptopocalypse will materialize itself, we may also have to > increase the size per certificate quite substantially. > I think this should be considered when discussing very-short-lived > certs.
I share your concern over short-lived certificates, but for a different reason: key continuity. Key continuity has proven to be a much better security property than gratuitous key rotations based on reading of tea leaves by tasseomancers. I think the devil will be in the details. If the automated process reuses the same key in the default use case, then the policy change should not damage key continuity schemes. In this case, I'm guessing Let's Encrypt is analyzing a CSR to detect a compromised key since Josh Aas's post specifically names it as the problem being solved. If the process performs gratuitous key rotations in the default use case during a CSR submission, then it is probably doing more harm than good. And here, the "default use case" means whatever happens when `certbot --apache` or `certbot --nginx` is run to setup the automation. Jeff -- 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/CAH8yC8njkCLwvFf9uL6zQ7dOvcEOLdPr2YwJ-aDZ0Sz3%3D98Fgw%40mail.gmail.com.
