Short Term Certificates in ACME: A New Alternative to Revocation

My coauthors and I just published RFC 8739 on Short-Term, Automatically Renewable (STAR) certificates in the ACME automated certificate management protocol. This post explains what STAR certificates are, why we see them as an essential next step for the global public key infrastructure (PKI) and how they are enabled by the new ACME protocol.
Some RFCs published by the IETF are fixes for well established technologies. This is true for my own TLS Best Current Practices and the more recent JWT BCP. In contrast, the STAR RFC aims to kickstart new technology that we see as essential to the new ways applications are being deployed. To see why, we need to dive into the theory – and the very different practice – of PKI.

If you’ve only learned the theory of public key infrastructure in school, you could be forgiven for having a traditional view of the certificate lifecycle:

Surprise! Except for the first assumption, all others on this list are no longer valid in today’s environment…

The STAR work aims to do away with the one remaining “old world” assumption, that of long validity periods.

The STAR Certificate’s Lifecycle #

Similarly to the shift from servers to containers (the Pets vs. Cattle analogy), STAR certificates are not managed individually. When a web site needs to be protected with STAR certificates, an ACME Certificate Order is created. This step can be done with a CLI and can of course itself be automated. In the case of STAR, an ACME Order corresponds to a sequence of short-term certificates, perhaps a hundred or more. When creating this initial Order, the requestor needs to generate a private key and include a traditional Certificate Signing Request (CSR).

Each of the certificates included in a STAR Order is valid for a short duration, say 72 hours, and they are issued sequentially. Halfway through the lifetime of each certificate, an agent installed on the web server goes off and fetches the next certificate from a highly available API endpoint on the Certificate Authority, also known as the ACME Server.

Remember that the certificate itself is not secret, so there’s no harm in making it openly available for anyone to pull. Of course, only the owner can make any use of it because only the owner has the corresponding private key.

This somewhat added complexity on the web server’s side pays off with great simplification on the client side: a client that needs to validate a STAR certificate is suddenly back to the good old days: there is no longer any need to query and cache CRLs, and no need for on-line validation with an OCSP server. The results are obvious: better performance, simplified and less error prone code paths, and because of the elimination of the on-line check, higher reliability.

A side effect of this solution is a significantly higher load on the Certificate Transparency (CT) infrastructure, which stores a copy of each publicly issued certificate. We spoke with the CT community and concluded that CT is scalable enough to cope with this extra load.

We just went through the happy path, where the certificate is valid and the client successfully establishes a connection. But what if the server is suspected to have been breached, and the certificate needs to be revoked? One REST call to the ACME server and the Order is cancelled, which means that no further certificates would be issued. As soon as the current certificate expires, the server will not be able to present a valid certificate for the private key it is holding and connection attempts will fail. There’s a bit of a subtlety here: revocation is not immediate, it only takes place when the newest current certificate expires. But in fact, due to caching effects revocation has never been immediate for CRLs and OCSP either. The recommended STAR certificate lifetimes were specified to be similar to the caching time frames for these older technologies.

STAR Certificates Enable Delegation #

Beyond just simplifying the common use case, STAR certificates enable entirely new use cases. The fact that revocation is easy and effective means that the private key can be handed to a less-than-fully-trusted entity and revoked as necessary. Think of a Content Delivery Network (CDN) which you want to present your web site’s data, but under the provision that this authority can be revoked at any moment. Or think of a large deployment of containers. Each HTTPS endpoint can hold its own private key, associated with a sequence of certificates, and those can be generated automatically and revoked on demand, also automatically.

Moreover, this can be done with no added latency (unlike the LURK proposal) and without the major pain of client-side migration, which is the case in the delegated credentials proposal, now being advanced by the TLS working group.

We are now working on a follow-on specification of STAR certificate delegation, and you can follow its progress at the IETF ACME working group.

To summarize, support for STAR certificates is a major new PKI capability enabled by the new ACME ecosystem. It comes with important short term benefits and promises longer term benefits that will help deploy TLS securely in ever more use cases.

Finally, I would like to thank my co-authors: Diego Lopez, Oscar Gonzalez de Dios, Antonio Agustin Pastor Perales and most of all, Thomas Fossati. Every RFC is a journey, and this one was made truly enjoyable by our partnership.


Now read this

Just Published: A New Version of the TLS Guidelines

Yaron Sheffer, Peter Saint-Andre and Thomas Fossati # There’s a new standard out, RFC 9325, with guidelines on secure use of TLS. This short post will explain some of the history behind it and why you might want to explore this document.... Continue →