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:
- Certificates are issued with long validity periods, often one or two years.
- Certificates are obtained manually, by going to the Certificate Authority’s (CA) web page and presenting a credit card.
- Certificates are installed manually on the web server, leading to frequent cases when people forget to deploy the new certificate on time, and the server ends up “bricked”.
- Revocation is through Certificate Revocation Lists (CRLs) that include all certificates that have been revoked by a certain CA.
- The relying party can validate the certificate off-line, by only looking at the certificate itself, and possibly at revocation information that’s typically already stored in a local cache.
Surprise! Except for the first assumption, all others on this list are no longer valid in today’s environment…
- With the ACME protocol, certificates are fetched from the CA automatically, after the client proves it is authorized for the identity being asserted. Then, they are installed automatically. In fact the default frequency of certificate renewal which is 90 days means that any sane deployment is fully automated.
- CRLs are rarely used because they tend to grow into unmanageable sizes. When certificates absolutely need to be distrusted, this is typically done through a software update to browsers.
- The best practice is for certificates to be issued with an OCSP endpoint, and for the relying party to consult the OCSP server before deciding to trust the certificate.
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.