Internet-Draft STIR Certs Short July 2023
Peterson Expires 28 January 2024 [Page]
Network Working Group
Intended Status:
Standards Track
J. Peterson

Short-Lived Certificates for Secure Telephone Identity


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.

Status of This Memo

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

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 28 January 2024.

1. Introduction

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 which 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 certificate 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 explores 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 [I-D.ietf-acme-authority-token-tnauthlist], so it provides a potentially attractive way of delivering short-lived certificates.

2. Terminology

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.

3. Short-lived certificates for STIR

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, the issuing authority must revoke the certificate, which requires relying parties to review certificate revocation lists or to access real-time status information with protocols such as OCSP. Short-lived certificates offer an alternative where, if compromised, certificates will shortly expire anyway, and rather than revoking and reissuing the certificate in response to a crisis, certificates routinely roll-over and 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 certificate 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 certificate 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 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 policy to them. 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 signed SIP request, so that no network lookup and consequent round-trip delay would be required on the terminating side to acquire the new certificate. [RFC8224] already provides a way of pointing to a certificate in a MIME body associated with the SIP request. Another potential delivery mechanism would be the "x5c" parameter of the PASSporT itself, which would convey the entire X.509 certificate chain as a base64 encoded PKIX value. This would make PASSporTs larger, but it also obviates the need for downloading the certificate from a URI through "x5u."

4. Certificate Acquisition with ACME

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 [I-D.ietf-acme-authority-token-tnauthlist]), the client can at any time apply for a certificate to be issued by sending an appropriate JSON request to the server. That request will contain a CSR [RFC2986] indicating the intended scope of authority as well the validity interval of the certificate in question. 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 puts needed flexibility into the hands of the clients requesting certificates to determine how much of their authority they want to invest in any given certificate.

[I-D.ietf-acme-authority-token-tnauthlist] uses the ATC framework of [I-D.ietf-acme-authority-token] 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.

5. IANA Considerations

This document contains no actions for the IANA.

6. Privacy Considerations

Short-lived certificates provide attractive privacy properties when compared to real-time status query protocols like OCSP, which require relying parties to perform a network dip 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.

7. Security Considerations

This document is entirely about security. For further information on certificate security and practices, see [RFC5280], in particular its Security Considerations. The Security Considerations of [RFC8555] are relevant to the use of ACME to acquire short-lived certificates.

8. Acknowledgments

Stephen Farrell provided key input to the discussions leading to this document.

9. References

9.1. Normative References

ATIS Recommendation 0300251, "Codes for Identification of Service Providers for Information Exchange", .
National Institute of Standards and Technology, U.S. Department of Commerce | NIST FIPS PUB 186-4, "Digital Signature Standard, version 4", .
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Challenges Using an Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-09, , <>.
Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-tnauthlist-13, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, , <>.
Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, , <>.
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, , <>.
Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, , <>.
Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, , <>.
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <>.
Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, , <>.
Peterson, J., "Secure Telephone Identity Revisited (STIR) Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, , <>.
ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", .
ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, "Information Technology - Abstract Syntax Notation One: Specification of basic notation".
ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, "Information Technology - Abstract Syntax Notation One: Information Object Specification".
ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, "Information Technology - Abstract Syntax Notation One: Constraint Specification".
ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, "Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications".

9.2. Informative References

Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, , <>.
Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, DOI 10.17487/RFC7375, , <>.
ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, "Information technology - Open Systems Interconnection - The Directory: Selected Attribute Types", .

Author's Address

Jon Peterson
Neustar, Inc.