draft-ietf-stir-certificates-shortlived — Short-Lived Certificates for STI

draft-ietf-stir-certificates-shortlived (Peterson) defines short-lived certificates as the freshness mechanism for Secure Telephone Identity certificates. Currently at -05 (April 2026), in IESG. Standards Track. Sole-authored by Jon Peterson.

A short-lived STIR certificate is one valid for days or hours rather than the months or years typical of traditional PKI. The validity period is short enough that staleness becomes a non-issue — relying parties don’t need to perform freshness checks because any certificate within its validity window is fresh by construction. The trade-off is that the signer must acquire new certificates frequently; the draft addresses that operational requirement through ACME-based automated reissuance.

What this draft specifies

Short-lived certificate profile for STIR. The draft specifies how to issue and use short-lived certificates in the STIR context, including normative guidance on validity periods and the relationship to the STIR certificate profile defined in RFC 8226.

ACME-based automated reissuance. Short-lived certificates require frequent reissuance, which is operationally untenable without automation. The draft specifies use of the Automated Certificate Management Environment (ACME, RFC 8555) — or similar automated mechanisms — building on the STIR-specific ACME infrastructure already defined for TNAuthList authority tokens (RFC 9447, RFC 9448).

TN Authorization List interactions. Short-lived certificates have a particular interaction with the TN Authorization List in the STIR certificate profile. Because TN authority can change due to portability, reassignment, and churn, the validity-period choice must align with the TN-assignment volatility expected in the deployment. A certificate authorizing a specific telephone number that’s about to be ported needs to expire within the window of the impending port — otherwise the verifier could accept a stale assertion of authority. The draft discusses this interaction in the context of typical TN-management operational patterns.

Compromise resilience. If a private key is compromised, the certificate expires shortly anyway — limiting attacker value without any explicit revocation action. There’s no need to populate CRLs with revocations for keys whose certificates would expire within hours.

Industry adoption context

Today, the STIR/SHAKEN ecosystem relies on centralized Certificate Revocation List (CRL) infrastructure for revocation and freshness handling, primarily for service-provider STI certificates issued by the STI-PA-coordinated CA hierarchy. That model has worked at the scale of service-provider-level issuance, where the certificate population is bounded and reissuance is infrequent.

Beyond the centralized-CRL approach, short-lived certificates are the path most likely to be adopted going forward — for delegate certificates, for VESPER deployments, and for any extension of the trust framework that scales beyond service-provider-level issuance. The architectural advantages are direct: relying parties don’t need to perform freshness checks at all, the round-trip costs that revocation infrastructure would impose are eliminated, and key compromise becomes self-limiting through certificate expiration. For STIR specifically, where high-volume signing is the dominant pattern and where a single certificate may sign many calls during its brief lifetime, the architectural fit is strong.

VESPER mandate

VESPER’s certificate profile (draft-wendt-stir-vesper) requires short-lived certificates as the freshness model. The combination of short-lived issuance, ACME-based automation, and embedded SCTs (per Certificate Transparency) positions VESPER’s delegate certificates as low-staleness, high-auditability trust artifacts that don’t require revocation infrastructure to be deployed by every relying party. The VESPER topic page covers how the freshness mechanism integrates with the broader trust model.

Status

Currently draft-ietf-stir-certificates-shortlived-05, in IESG. Once published, the draft will be the IETF specification for short-lived STIR certificates — and the freshness mechanism that VESPER and other delegate-certificate-using extensions of the trust framework will operate on.