Secure Telephone Identity Revisited C. Wendt Internet-Draft R. Śliwa Intended status: Standards Track Somos, Inc. Expires: 7 January 2027 6 July 2026 VESPER - Verifiable STI Presentation and Evidence for RTU draft-wendt-stir-vesper-08 Abstract This document defines VESPER (Verifiable STI Presentation and Evidence for RTU), a framework that composes existing STIR mechanisms into a system in which a relying party can verify that a telephone number was assigned to a specific entity and that the same entity controls a specific domain. VESPER builds on the telephone-number- to-domain binding defined in [I-D.wendt-stir-tn-domain-binding], the STIR certificate and PASSporT specifications, ACME-based authority token issuance, and certificate transparency. This document describes the roles, the certificate usage, a domain-hosted certificate repository and discovery model, a PASSporT usage profile for SIP signaling, and a portable Right-to-Use Token for use outside of SIP. It defines the framework and its composition; the new normative binding it relies on is specified in [I-D.wendt-stir-tn-domain-binding]. 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 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 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Wendt & Śliwa Expires 7 January 2027 [Page 1] Internet-Draft VESPER July 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Framework Overview . . . . . . . . . . . . . . . . . . . . . 3 3.1. The VESPER Delegate Certificate . . . . . . . . . . . . . 3 3.2. Domain as a Corroborating Trust Credential . . . . . . . 5 3.3. Scope of Entity Verification . . . . . . . . . . . . . . 5 3.4. User Identity and Delegation . . . . . . . . . . . . . . 5 3.5. Certificate Repository and Domain-Controlled Discovery . 6 3.6. Token Representations . . . . . . . . . . . . . . . . . . 6 4. VESPER Roles . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Certificate Issuance . . . . . . . . . . . . . . . . . . . . 7 6. PASSporT Usage Profile . . . . . . . . . . . . . . . . . . . 7 6.1. Authentication Service Behavior . . . . . . . . . . . . . 7 6.2. Verification Service Behavior . . . . . . . . . . . . . . 8 6.3. Connected Identity . . . . . . . . . . . . . . . . . . . 8 7. Right-to-Use Token . . . . . . . . . . . . . . . . . . . . . 8 8. Delivery Outside In-Band Signaling . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Secure Telephone Identity (STI) architecture, based on STI certificates [RFC8226], PASSporTs [RFC8225], and the SIP Identity header field [RFC8224], provides cryptographic integrity protection for calling information in real-time communications. These mechanisms verify that a telephone number was not modified in transit and that it was signed using credentials authorized for that number. They do not, on their own, establish that a telephone number is being used by the entity it was assigned to, or carry a verifiable entity identity that a relying party can recognize across channels. Wendt & Śliwa Expires 7 January 2027 [Page 2] Internet-Draft VESPER July 2026 VESPER addresses these gaps not by inventing new cryptographic machinery but by composing mechanisms that already exist. The one genuinely new element VESPER depends on, the binding of telephone number authority to a domain identifier within a single certificate, is specified separately in [I-D.wendt-stir-tn-domain-binding]. Everything else in this document describes how that bound certificate, together with STIR PASSporTs, ACME-based authority tokens, certificate transparency, and the existing STIR certificate profile, fit together into a usable trust framework. The result is a framework in which a delegate certificate serves as a single, auditable trust artifact: it carries the telephone numbers assigned to an entity and the domain that entity controls, and it is recorded in a transparency log. This document defines the roles, the certificate repository and discovery model, the PASSporT usage profile, and the portable Right-to-Use Token, and it points to the binding specification for the underlying credential semantics. 2. Conventions and Definitions 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. This document uses terms defined in [RFC8226], [RFC9060], and [I-D.wendt-stir-tn-domain-binding], including TNAuthList, delegate certificate, domain identifier, and bound certificate. The VESPER delegate certificate referred to throughout this document is a bound certificate as defined in [I-D.wendt-stir-tn-domain-binding], used within the framework described here. 3. Framework Overview 3.1. The VESPER Delegate Certificate The VESPER framework is built around a delegate certificate [RFC9060] issued to the entity that holds the right-to-use for one or more telephone numbers and that controls a domain. This certificate is a bound certificate as defined in [I-D.wendt-stir-tn-domain-binding]: its TNAuthList and its SubjectAltName domain identifier are co- validated at issuance, so the certificate attests that the same entity holds both. VESPER uses this bound certificate as the anchor for all of its trust assertions. Wendt & Śliwa Expires 7 January 2027 [Page 3] Internet-Draft VESPER July 2026 The VESPER delegate certificate is telephone number scoped: the telephone numbers in its TNAuthList represent the subject's right-to- use. It is delegated from a parent certificate held by the authority responsible for that right-to-use, typically the subject's TNSP or a responsible provider or organization that is authoritative in the telephone network and identified by a service provider code (SPC). Following the delegation model of [RFC9060], Section 4.1, the parent certificate may be SPC scoped, and the telephone number scope of the VESPER delegate certificate MUST be encompassed by the parent's scope. The chain therefore expresses that an SPC-identified, network-authoritative provider has delegated the right-to-use of specific telephone numbers to the subject of the VESPER delegate certificate. The certificate carries the following, all as defined in their respective specifications: * Telephone number authority: one or more telephone numbers in the TNAuthList extension [RFC8226], representing the entity's right- to-use. * Optional self-asserted TN attributes: a VESPER delegate certificate MAY carry the TN Attributes extension [I-D.wendt-stir-cert-tn-attr-ext], through which the number holder expresses self-asserted attributes about its own numbers, such as the originating providers it authorizes, do-not-originate status, and text-enabled status. These attributes are carried in a dedicated extension, are distinct from the telephone number authority in the TNAuthList, and do not extend or modify it. * Domain identifier: a domain name in the SubjectAltName [RFC5280], bound to the telephone number authority as defined in [I-D.wendt-stir-tn-domain-binding]. * Optional claim constraints: JWTClaimConstraints [RFC8226] or EnhancedJWTClaimConstraints [RFC9118], authorizing additional PASSporT claims such as Rich Call Data [RFC9795]. * Transparency: an embedded Signed Certificate Timestamp as defined in [I-D.ietf-stir-certificate-transparency]. VESPER deployments use short-lived certificates as described in [I-D.ietf-stir-certificates-shortlived], convey the certificate chain inline using the x5c header parameter, and include the x5u header parameter referencing the certificate at its domain-hosted repository location. Wendt & Śliwa Expires 7 January 2027 [Page 4] Internet-Draft VESPER July 2026 3.2. Domain as a Corroborating Trust Credential Prior STIR specifications establish telephone number authority through the TNAuthList but do not bind that authority to the entity to which the number was assigned. VESPER relies on the binding defined in [I-D.wendt-stir-tn-domain-binding] to add a domain identifier as a corroborating signal: a domain the entity controls and for which it holds credentials. Because the domain identifier and the telephone number authority are co-validated at issuance, a relying party that validates a VESPER delegate certificate obtains evidence that a specific entity, identified by its domain, has been assigned the telephone numbers in the certificate. The strength of this signal comes from two independent trust chains, telephone number assignment and domain control, corroborating the same entity. 3.3. Scope of Entity Verification VESPER binds two mechanically verifiable facts: control of a domain and authority to use a telephone number. Entity verification, often referred to as know-your-customer (KYC), and the legal identity of the entity are out of scope for VESPER. Whatever real-world verification a certificate authority performs at issuance is governed by CA policy and reflected in the domain identifier; VESPER neither defines nor replaces it. A relying party does not inspect any provider's onboarding process. It verifies the cryptographic binding of domain control to telephone number authority against publicly auditable infrastructure, as the Web PKI does for domain-bound certificates. The domain identifier serves as a persistent, publicly verifiable network identifier to which telephone number authority is bound; the association between that identifier and a real-world entity is established and maintained outside this framework. 3.4. User Identity and Delegation The VESPER delegate certificate authorizes the entity that holds it to use the telephone numbers it contains. Within that entity, individual users or automated agents may be further authorized through the entity's own governance, without being identified in the delegate certificate. A single telephone number may be authorized for use by multiple users or agents, as is common in shared lines and call center deployments. Where caller identity at the individual level is desired, mechanisms such as Rich Call Data [RFC9795] or other PASSporT extensions provide optional paths for conveying that information. Wendt & Śliwa Expires 7 January 2027 [Page 5] Internet-Draft VESPER July 2026 3.5. Certificate Repository and Domain-Controlled Discovery An entity that holds a VESPER delegate certificate publishes that certificate at a stable HTTPS location under its domain. The specific path is not prescribed; any HTTPS URL whose domain matches the dNSName SubjectAltName of the delegate certificate is valid. The TLS certificate on the hosting server matches the dNSName SubjectAltName of the VESPER delegate certificate, validated through standard Web PKI TLS. No cross-signing between the STI delegate certificate and the web TLS certificate is required or defined. Because the domain in the delegate certificate and the domain hosting it are the same, retrieval of the certificate from its domain provides a convenient discovery path and reinforces the domain association at retrieval time, as described in [I-D.wendt-stir-tn-domain-binding]. 3.6. Token Representations This framework uses two token representations derived from the delegate certificate: a PASSporT as defined in [RFC8225] for use in SIP signaling, and a portable Right-to-Use Token, a JWT [RFC7519] that provides portable proof of right-to-use for contexts outside of SIP signaling, such as cases where evidence of telephone number association is required. Each is described in the sections below. 4. VESPER Roles The VESPER framework uses the roles defined for the binding in [I-D.wendt-stir-tn-domain-binding] and adds the operational roles needed for the framework. 1. Domain Operator: the entity that controls a domain and holds the right-to-use for one or more telephone numbers. The Domain Operator is the subject of the VESPER delegate certificate, publishes the certificate at a stable HTTPS location under its domain, and uses the certificate's private key to sign PASSporTs and Right-to-Use Tokens. 2. Right-to-Use (RTU) Authority: the responsible provider or organization, authoritative in the telephone network and identified by a service provider code, that allocates telephone numbers and issues RTU Authority Tokens, as described in [I-D.wendt-stir-tn-domain-binding]. The RTU Authority holds the SPC-scoped parent certificate from which the VESPER delegate certificate is delegated, and its scope encompasses the telephone numbers in the delegate certificate per [RFC9060], Section 4.1. Wendt & Śliwa Expires 7 January 2027 [Page 6] Internet-Draft VESPER July 2026 3. STI Certification Authority: issues VESPER delegate certificates as bound certificates in accordance with [I-D.wendt-stir-tn-domain-binding]. 4. Transparency Log Operator: records issued delegate certificates and returns SCTs, as defined in [I-D.ietf-stir-certificate-transparency]. 5. Certificate Issuance VESPER delegate certificates are issued as bound certificates in accordance with [I-D.wendt-stir-tn-domain-binding], which requires that domain control and telephone number Right-to-Use be co-validated within a single issuance. The telephone number authority is established through an RTU Authority Token issued by the RTU Authority and validated via ACME mechanisms ([RFC9447], [RFC9448], [I-D.ietf-acme-authority-token-jwtclaimcon]). Where additional PASSporT claims are to be authorized, a JWTClaimConstraints Authority Token [I-D.ietf-acme-authority-token-jwtclaimcon] is presented during issuance. A VESPER delegate certificate is recorded in a transparency log and carries an embedded Signed Certificate Timestamp as defined in [I-D.ietf-stir-certificate-transparency], so that VESPER delegate certificates are publicly auditable. Transparency is a requirement of the VESPER framework rather than of the underlying binding, which is defined independently of it. The certificate profile is otherwise that of a bound certificate, which conforms to [RFC8226] and [RFC9060]. 6. PASSporT Usage Profile This section describes how VESPER uses PASSporTs in SIP signaling. The construction and validation steps below apply the procedures of [RFC8224] and [RFC8225]; the one verification step specific to the telephone-number-to-domain binding is defined in [I-D.wendt-stir-tn-domain-binding] and referenced here. 6.1. Authentication Service Behavior When originating a call or message, the Authentication Service: * Constructs a PASSporT containing orig, dest, iat, and any optional claims authorized by the certificate, as defined in [RFC8225]. * Signs the PASSporT using a VESPER delegate certificate whose TNAuthList authorizes the orig telephone number. Wendt & Śliwa Expires 7 January 2027 [Page 7] Internet-Draft VESPER July 2026 * Conveys the certificate chain inline using the x5c header parameter and includes the x5u header parameter containing the HTTPS URL of the certificate at its domain-hosted repository location. 6.2. Verification Service Behavior Upon receiving a PASSporT, the Verification Service applies the validation procedures of [RFC8224] and [RFC8226], namely validating the PASSporT signature, validating the certificate chain to a trusted STIR trust anchor, confirming the TNAuthList authorizes the orig telephone number, validating the embedded SCT, and, where claim constraints are present, confirming that asserted claims conform. In addition, the Verification Service applies the binding verification rule defined in [I-D.wendt-stir-tn-domain-binding]: it confirms that the domain in the x5u URL matches the dNSName SubjectAltName of the signing certificate, and treats the domain identifier as the identity of the right-to-use holder only as bound to the TNAuthList. The PASSporT is rejected if any validation fails. 6.3. Connected Identity When VESPER is used with Connected Identity [RFC9970], the destination party returns a PASSporT of type rsp in a SIP 200 OK, signed using a VESPER delegate certificate authorized for the dest telephone number. The rsp PASSporT includes the original orig and dest values and a fresh iat. The originating party verifies the rsp PASSporT using the same validation steps above, applied to the dest telephone number and the destination party's certificate. 7. Right-to-Use Token The Right-to-Use (RTU) Token is a JWT [RFC7519] signed by the private key of the VESPER delegate certificate, with the certificate chain conveyed in the JOSE header using the x5c parameter. The delegate certificate is the trust artifact; the token signature demonstrates that the presenter holds the corresponding private key. The token provides portable evidence of right-to-use outside of SIP signaling. The RTU Token includes: * iss: the entity's domain identifier, matching the dNSName SubjectAltName of the signing certificate * iat and exp: issuance and expiration times; exp is set to a short validity interval to limit the replay surface Wendt & Śliwa Expires 7 January 2027 [Page 8] Internet-Draft VESPER July 2026 * orig: the telephone number being asserted, consistent with the TNAuthList of the signing certificate The token may include additional claims authorized by the JWTClaimConstraints extension of the signing certificate, such as Rich Call Data [RFC9795]. 8. Delivery Outside In-Band Signaling The VESPER trust artifacts defined in this document, the PASSporT and the Right-to-Use Token, are independent of how they are conveyed. They are signed by the VESPER delegate certificate and verified against the same bound certificate regardless of the path they travel. Where in-band signaling does not carry the artifact end to end, or where there is no in-band path between the parties, the same artifact can be conveyed through other mechanisms, including out-of- band publish-and-retrieve delivery. Such delivery mechanisms are specified separately and are not required in order to implement VESPER. 9. Security Considerations VESPER provides verifiable evidence that an entity identified by a domain identifier, and validated as holding the right-to-use for one or more telephone numbers, produced a signature over a communication. A successful verification establishes that the PASSporT or Right-to- Use Token was signed by a delegate certificate whose TNAuthList authorizes the asserted telephone number, that the same certificate binds a co-validated domain identifier, and that the certificate is recorded in a transparency log. It does not establish that the content of a communication is legitimate, and it attests to the identity of the entity only to the assurance carried by the domain identifier; the strength of that identification is the strength of the domain validation performed at issuance, as discussed in [I-D.wendt-stir-tn-domain-binding]. The assurance rests on two independent trust chains, the delegation of telephone number right-to-use and the validation of domain control, co-validated into a single certificate. Because they are bound at issuance, an adversary cannot forge the association by compromising only one: a delegate certificate for a telephone number does not confer control of an unrelated domain, and control of a domain does not confer right-to-use for numbers that were not delegated. The security of the co-validation, and the prohibition on issuing a certificate that carries one without the other, are defined in [I-D.wendt-stir-tn-domain-binding]. Wendt & Śliwa Expires 7 January 2027 [Page 9] Internet-Draft VESPER July 2026 VESPER requires delegate certificates to be recorded in a transparency log [I-D.ietf-stir-certificate-transparency]. A certificate that improperly binds a domain to telephone numbers, through CA error or compromise, is therefore publicly observable, allowing the affected domain holder, the number authority, and independent monitors to detect it. Transparency does not prevent misissuance, but it makes covert misissuance impractical and bounds how long a mistaken or malicious binding can go unnoticed. VESPER inherits the security properties and considerations of the mechanisms it composes. PASSporT signature and validation, certificate path validation, and handling of the SIP Identity header field are as defined in [RFC8224], [RFC8225], [RFC8226], and [RFC9060]; certificate issuance, including validation of the RTU Authority Token, is defined in [RFC9447], [RFC9448], and [I-D.wendt-stir-tn-domain-binding]. VESPER neither weakens nor overrides these, and a weakness in any composed mechanism is inherited by the framework. Replay of a captured PASSporT or Right-to-Use Token is mitigated by the freshness of the iat claim, by a short exp interval on the Right- to-Use Token, and by the STIR replay mitigations of [RFC8224]. VESPER deployments use short-lived certificates [I-D.ietf-stir-certificates-shortlived], which reduce reliance on revocation and bound the interval over which a compromised key or stale binding remains usable; relying parties enforce certificate validity windows. 10. IANA Considerations This document has no IANA actions. 11. Acknowledgments The authors would like to acknowledge Jon Peterson for valuable feedback on this work, and the STIR working group for the foundational specifications on which VESPER builds. 12. References 12.1. Normative References [I-D.ietf-stir-certificate-transparency] Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad, "STI Certificate Transparency", Work in Progress, Internet-Draft, draft-ietf-stir-certificate-transparency- 02, 18 May 2026, . Wendt & Śliwa Expires 7 January 2027 [Page 10] Internet-Draft VESPER July 2026 [I-D.wendt-stir-tn-domain-binding] Wendt, C., "Binding a Domain Identifier to Telephone Number Authority in STIR Certificates", Work in Progress, Internet-Draft, draft-wendt-stir-tn-domain-binding-00, 6 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5280] 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, May 2008, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, September 2021, . Wendt & Śliwa Expires 7 January 2027 [Page 11] Internet-Draft VESPER July 2026 [RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "Automated Certificate Management Environment (ACME) Challenges Using an Authority Token", RFC 9447, DOI 10.17487/RFC9447, September 2023, . [RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token", RFC 9448, DOI 10.17487/RFC9448, September 2023, . 12.2. Informative References [I-D.ietf-acme-authority-token-jwtclaimcon] Wendt, C. and D. Hancock, "JWTClaimConstraints profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-jwtclaimcon-03, 30 June 2026, . [I-D.ietf-stir-certificates-shortlived] Peterson, J., "Short-Lived Certificates for Secure Telephone Identity", Work in Progress, Internet-Draft, draft-ietf-stir-certificates-shortlived-06, 6 July 2026, . [I-D.wendt-stir-cert-tn-attr-ext] Wendt, C. and R. Śliwa, "TN Attribute Certificate Extension for STI Certificates", Work in Progress, Internet-Draft, draft-wendt-stir-cert-tn-attr-ext-00, 6 July 2026, . [RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates", RFC 9118, DOI 10.17487/RFC9118, August 2021, . [RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT) Extension for Rich Call Data", RFC 9795, DOI 10.17487/RFC9795, July 2025, . Wendt & Śliwa Expires 7 January 2027 [Page 12] Internet-Draft VESPER July 2026 [RFC9970] Peterson, J. and C. Wendt, "Connected Identity for Secure Telephone Identity Revisited (STIR)", RFC 9970, DOI 10.17487/RFC9970, June 2026, . Authors' Addresses Chris Wendt Somos, Inc. United States of America Email: chris@appliedbits.com Rob Śliwa Somos, Inc. United States of America Email: robjsliwa@gmail.com Wendt & Śliwa Expires 7 January 2027 [Page 13]