| Internet-Draft | STIR Certs Short | November 2026 |
| Peterson | Expires 6 May 2027 | [Page] |
When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The STIR problem statement [RFC7340] discusses many attacks on the telephone network that are enabled by impersonation, including various forms of robocalling, voicemail hacking, and swatting. One of the most important components of a system to prevent impersonation is the implementation of credentials that identify the parties who control telephone numbers. The STIR certificates [RFC8226] specification describes a credential system based on [X.509] version 3 certificates in accordance with [RFC5280] for that purpose. Those credentials can then be used by STIR authentication services [RFC8224] to sign PASSporT objects [RFC8225] carried in a SIP [RFC3261] request.¶
The STIR certificates document specifies an extension to X.509 that defines a Telephony Number (TN) Authorization List that may be included by certification authorities in certificates. This extension provides additional information that relying parties can use when validating transactions with the certificate: either in the form of Service Provider Codes (SPCs) or telephone numbers. Telephone numbers or number ranges are used in delegate STIR certificates [RFC9060]. When a SIP request arrives at a terminating administrative domain, for example, the calling number attested by the SIP request can be compared to the TN Authorization List of the delegate certificate that signed the request to determine if the caller is authorized to use that calling number in SIP.¶
No specific recommendation is made in the STIR certificates document for a means of determining the freshness of certificates with a TN Authorization List. This document specifies how short-lived certificates could be used as a means of preserving that freshness. Short-lived certificates also have a number of other desirable properties that fulfill important operational requirements for network operators. A mechanism such as the Automated Certificate Management Environment (ACME) [RFC8555] could be leveraged to manage these short-lived certificates, as well as various web-based interfaces or other out-of-band mechanisms. The interaction of STIR with ACME has already been explored in [RFC9448], so it provides a potentially attractive way of delivering short-lived certificates.¶
As the use of short-lived certificates described below involves a certificate chain included by-value in the PASSporT header, this document specifies the use of "x5c" in the PASSporT header when short-lived certificates are present.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
While there is no easy definition of what constitutes a "short-lived" certificate, the term typically refers to certificates that are valid only for days or even hours, as opposed to the months or years common in traditional public key infrastructures. When the private keying material associated with a certificate with an expiry of months or years is compromised by an adversary, relying parties must review certificate revocation lists (CRLs) or access real-time status information with protocols such as OCSP to learn that the certificate has been revoked. Short-lived certificates offer an alternative where, if compromised, certificates will shortly expire anyway, so CRLs and OCSP are less meaningful. Such certificates cannot be cached for a long term by relying parties, minimizing their value to attackers.¶
One of the additional benefits of using short-lived certificates is that they do not require relying parties to perform any certificate freshness check. The trade-off is that the signer must acquire new certificates frequently, so the cost of round-trip times to the certification authority is paid on the signer's side rather than the verifier's side; however, in environments where many parties may rely on a single certificate, or at least where a single certificate will be used to sign many transactions during its short lifetime, the overall architecture will incur fewer round-trip times to the certification authority and thus less processing delay.¶
In the STIR context, the TN Authorization List defined in [RFC8226] adds a new wrinkle to the behavior of short-lived certificates, especially when the TN Authorization List is populated with telephone numbers or number ranges instead of Service Provider Codes (SPCs). A subject may have authority over multiple telephone numbers, but a particular short-lived certificate issued to that subject could attest the authority over all, some, or just one of those telephone numbers. Short-lived certificates permit a more on-demand certification process, where subjects acquire certificates as needed, potentially in reaction to calls being placed. A STIR authentication service could even acquire a new certificate on a per-call basis that can only sign for the calling party number of the call in question, as it would expire immediately thereafter. At the other end of the spectrum, a large enterprise service provider could acquire a certificate valid for millions of numbers, but expire the certificate after a very short duration - on the order of hours - to reduce the risk that the certificate would be compromised.¶
This inherent flexibility in the short-lived certificate architecture would also permit authentication services to implement very narrow policies for certificate usage. A large service provider who wanted to avoid revealing which phone numbers they controlled, for example, could provide no information in the certificate that signs a call other than just the single telephone number that corresponds to the calling party's number. How frequently the service provider feels that they need to expire that certificate and acquire a new one is entirely a matter of local policy. This makes it much harder for entities monitoring signatures over calls to guess who owns which numbers, and provides a much more complicated threat surface for attackers trying to compromise the service.¶
In order to reduce the burden on verification services, an authentication service could also piggyback a short-lived certificate onto the PASSporT, so that no network lookup and consequent round-trip delay would be required on the terminating side to acquire the new certificate. In particular, the poor cacheability of short-lived certificates may require frequent fetches of certificates via the "x5u" PASSporT header element when relying parties validate PASSporTs.¶
As an optimization, this specification specifies the conveyance of the certificate chain for a short-lived certificate via the "x5c" JWS header element ([RFC7515] Section 4.1.6). The "x5c" element contains a base64 encoded PEM representation of the certificate chain. STIR Verification service implementations compliant with this specification MUST support the "x5c" element; authentication services MUST use the "x5c" format for PASSporTs signed by certificates with a valid lifetime shorter than one week. The one-week threshold reflects the point below which certificate caching by verification services ceases to provide much benefit, so that conveying the certificate by reference would require frequent fetches at call time; it also corresponds to the threshold below which the Web PKI exempts certificates from revocation status requirements [CABF-BR].¶
The presence of x5c creates PASSporT objects that are considerably larger than typical RFC8225 tokens, and the longer the certificate chain, the larger the PASSporT header will be. But provided the certificate chain leads to a trusted certification authority, "x5c" precludes the need for a round-trip time before validation at the STIR verification service. The root certificate SHOULD NOT be included in the chain: verification services rely on their own trust anchors, so a root conveyed in "x5c" adds no security value and only increases the size of every PASSporT. It may nonetheless be included in deployment environments where verifiers require the complete chain, at the cost of that additional overhead.¶
An example PASSporT header with an "x5c" element with three certificates (including the root) in its chain might look as follows:¶
{ "typ":"passport",
"ppt":"div",
"alg":"ES256",
"x5c":
["MIICkTCCAjigAwIBAgIUb689vcv/kTP7N6J7Gz9YZU21WT4wCgYIKoZIzj0EAwIw
SzELMAkGA1UEBhMCVVMxFjAUBgNVBAoMDUFjbWUgQ0EsIEluYy4xJDAiBgNVBAMM
G0FjbWUgU0hBS0VOIEludGVybWVkaWF0ZSBDQTAeFw0yNDA3MDgxNDI4MjVaFw0y
NDA3MDkxNDI4MjVaMFUxCzAJBgNVBAYTAlVTMR4wHAYDVQQKDBVBY21lIEVudGVy
cHJpc2UsIEluYy4xJjAkBgNVBAMMHVNIQUtFTiBUTi1BdXRobi1MaXN0IEJ5IFZh
bHVlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEuxmGGgRklHe0GyGbgANc4182
z3y6LdJ9Xp0r6xWspI/K3msUWD3ijxA5iYEKUBLofBMbwHiDS4CfMldTHUuMFqOB
7zCB7DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTbmpeh0wHlpxvtJlVbI6mD+idq
cjAfBgNVHSMEGDAWgBTNsw0NkoZNWYL1bn2vwna5gwp0szAOBgNVHQ8BAf8EBAMC
B4AwNAYIKwYBBQUHAQEEKDAmMCQGA1UdH4YdaHR0cHM6Ly9zdGlwYS5hY21lLWNh
LmNvbS9jcmwwVgYIKwYBBQUHARoESjBIoRMwERYLMTcwMzU1NTIwMDACAgPoog0W
CzE3MDM1NTUxMjM0oRMwERYLMTU3MTU1NTMwMDACAgfQog0WCzE1NzE1NTUyMzQ1
MAoGCCqGSM49BAMCA0cAMEQCIFzV0EyHdMXStqzROJkL6CO06+6FuFYZGIod9iMw
Yyr2AiAmEK1smeSAdoFYG5WTIGfjB13xAWn7EQH0SDkqOKKBwA==",
"MIICKjCCAdGgAwIBAgIUPV/XdduqC44On5FKIjmcqwWO1JkwCgYIKoZIzj0EAwIw
QzELMAkGA1UEBhMCVVMxFjAUBgNVBAoMDUFjbWUgQ0EsIEluYy4xHDAaBgNVBAMM
E0FjbWUgU0hBS0VOIFJvb3QgQ0EwHhcNMjQwNzA4MTQyODI1WhcNMzQwNzA5MTQy
ODI1WjBLMQswCQYDVQQGEwJVUzEWMBQGA1UECgwNQWNtZSBDQSwgSW5jLjEkMCIG
A1UEAwwbQWNtZSBTSEFLRU4gSW50ZXJtZWRpYXRlIENBMFkwEwYHKoZIzj0CAQYI
KoZIzj0DAQcDQgAE0wypYKOwsS8JU0Ahx4niuirUv0M9v01vUDHiSfFzWbeAlbK/
hWlVYHADeFoRC7cIldDJ3iupafdxVgQggPp+/aOBmjCBlzAPBgNVHRMBAf8EBTAD
AQH/MB0GA1UdDgQWBBTNsw0NkoZNWYL1bn2vwna5gwp0szAfBgNVHSMEGDAWgBRL
Uq0usIR/TU27Y5vNN94V7xKnzTAOBgNVHQ8BAf8EBAMCAQYwNAYIKwYBBQUHAQEE
KDAmMCQGA1UdH4YdaHR0cHM6Ly9zdGlwYS5hY21lLWNhLmNvbS9jcmwwCgYIKoZI
zj0EAwIDRwAwRAIgUoAbid+kGFQWdQnLpJGwc4c4JoYohenmm3y2duOBN58CIEDm
nWAQfT1HWvZt2M6q0nOopZLwrt/9LzkBJqomRgzr",
"MIIB6zCCAZGgAwIBAgIUGEca/xMNdZbTZUP8DsxrnbR246AwCgYIKoZIzj0EAwIw
QzELMAkGA1UEBhMCVVMxFjAUBgNVBAoMDUFjbWUgQ0EsIEluYy4xHDAaBgNVBAMM
E0FjbWUgU0hBS0VOIFJvb3QgQ0EwHhcNMjIwNTA3MDQ1ODIyWhcNNDIwNTA3MDQ1
ODIyWjBDMQswCQYDVQQGEwJVUzEWMBQGA1UECgwNQWNtZSBDQSwgSW5jLjEcMBoG
A1UEAwwTQWNtZSBTSEFLRU4gUm9vdCBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEH
A0IABL7UD1CBpsNNq0EzDa90JUQV9etsUe8YOyOXpFB/9A8ahDj6HAJxuZJigSCG
dG6npehdHMeDHzHsPHMLy22qH6OjYzBhMB0GA1UdDgQWBBRLUq0usIR/TU27Y5vN
N94V7xKnzTAfBgNVHSMEGDAWgBRLUq0usIR/TU27Y5vNN94V7xKnzTAPBgNVHRMB
Af8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAKBggqhkjOPQQDAgNIADBFAiEA+U9j
0vQpHOx4nF+jytmr/bpotH001R09zZiywozSydwCIE6hI66JwnmqRKeJ9OeTNyM5
asC7YWEm3bQqgukw/uEs"]
}
¶
This example includes the root certificate for illustrative purposes; per the guidance above, a typical deployment would omit the final entry in the "x5c" array, conveying only the end-entity and intermediate certificates. [RFC8224] provides a way of pointing to a certificate in a MIME body associated with the SIP request, but for out-of-band uses of STIR, having the certificate embedded in the PASSporT itself is a superior option. Note that for backward compatibility reasons, implementations MAY include both "x5u" and "x5c" in the PASSporT header, but the certificate chain referenced by "x5u" MUST be the same as the chain conveyed in "x5c".¶
One of the primary challenges facing short-lived certificates is building an operational system that allows signers to acquire new certificates and put them to immediate use. ACME [RFC8555] is designed for exactly this purpose. After a client registers with an ACME server, and the authority of the client for the names in question is established (through means such as [RFC9448]), the client can at any time apply for a certificate to be issued by submitting an order to the server (ACME [RFC8555], Section 7.4). The order identifies the scope of authority requested and may indicate the desired validity interval of the certificate through its "notBefore" and "notAfter" fields; the client then finalizes the order by submitting a CSR [RFC2986] for that scope. Ultimately, this will enable the client to download the certificate from a certificate URL designated by the server.¶
ACME is based on the concept that clients establish accounts at an ACME server, and that through challenges, the server learns which identifiers it will issue for certificates requested for an account. Any given certificate issued for an account can be for just one of those identifiers, or potentially for more: this is determined by the CSR that an ACME client creates for a particular order. Thus, a service provider with authority for millions of identifiers - that is, millions of telephone numbers - could create a CSR for an ACME order that requests a certificate only associated with one of those telephone numbers if it so desired. The same would be true of certificates based on Service Provider Codes (SPCs) as described in [RFC8226]: a service provider might have just one SPC or perhaps many. ACME thus provides flexibility to clients requesting certificates to determine how much of their authority they want to invest in any given certificate.¶
[RFC9448] uses the Authority Token Challenge (ATC) framework of [RFC9447] to generate tokens that are provided to the CA in response to ACME challenges. For a usage with short-term certificates, it may make sense for the ATC tokens to have a relatively long expiry, so that the ACME client does not have to constantly return to the Token Authority for new tokens. This could potentially be used with the ACME STAR [RFC8739] mechanism as well.¶
Short-lived certificates shift the cost of certificate freshness from the verification side to the authentication service, which makes the reachability of the certification authority and its ACME interface operationally critical to call signing. An authentication service that fails to renew a certificate before it expires will produce PASSporTs that fail verification, and its calls will be treated accordingly by terminating services. Operators therefore need to renew certificates in advance of expiry with enough lead time to absorb CA latency and transient failures, recognizing that the shorter the certificate lifetime, the tighter that renewal margin becomes. Operators are also encouraged to stagger renewals and apply backoff on failure rather than retry aggressively against a busy CA; the ACME STAR mechanism [RFC8739] can remove the client from the synchronous acquisition path by pre-issuing renewed certificates. Useful signals to monitor include renewal success rate and lead-time margin, ACME error rates, and the rate of verification failures attributable to expired certificates, which indicates a renewal pipeline falling behind.¶
Conveying the certificate chain in "x5c" trades a network round-trip for increased message size: the chain travels in every PASSporT, enlarging the SIP Identity header by roughly the size of the chain. This is a deliberate exchange of originating-side overhead for the elimination of call-time fetches on the terminating side, but operators should be aware that larger headers can interact poorly with SIP transport, including fragmentation over UDP and intermediaries that impose header-size limits. The size cost is minimized by keeping the TNAuthorizationList as small as the deployment allows, keeping certificate chains short, and omitting the root certificate from the chain where deployment conditions permit.¶
This document contains no actions for the IANA.¶
Short-lived certificates provide attractive privacy properties when compared to real-time status protocols like OCSP, which require relying parties to perform a network query that can reveal a great deal about the source and destination of communications. For STIR, these problems are compounded by the presence of the TN Authorization List extension to certificates. Short-lived certificates can minimize the data that needs to appear in the TN Authorization List, and consequently reduce the amount of information about the caller leaked by certificate usage to an amount equal to what is leaked by the call signaling itself.¶
The exposure created by the compromise of a certificate's private key is a function of both the scope of authority in its TN Authorization List and the time remaining before it expires. Short-lived certificates control the second of these: an attacker in possession of a compromised key can use it only until the certificate expires, which for certificates valid for hours is likely to be sooner than revocation information (such as traditional CRLs) would reach relying parties in any case. Operators choosing certificate lifetimes should weigh both factors, and may prefer shorter lifetimes for certificates with broader scope. Note, however, that a broad-scope short-lived certificate still compares favorably to current practices, wherein for example certificates bearing a Service Provider Code effectively authorize signing for any calling number, and are valid for a year or more. Note also that narrowing the scope of individual certificates provides limited protection against compromise of the signing infrastructure itself, as an attacker who controls an authentication service and its ACME account can request new certificates of whatever scope that account is authorized for.¶
For further information on certificate security and practices, see [RFC5280], in particular its Security Considerations. Implementations should note the Security Considerations of [RFC8226] for guidance on STIR certificate usage. The Security Considerations of [RFC8555] are relevant to the use of ACME to acquire short-lived certificates, as are those of [RFC8739].¶
Stephen Farrell, Jack Rickard, Simon Castle, Chris Wendt, Alec Feichnel, Eric Rescorla and Ning Zhang provided key input to this document.¶