VESPER Out-of-Band OOB

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.¶

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

The STIR framework enables the signing and verification of telephone communications using PASSporT [RFC8225] objects carried in SIP [RFC3261] in Identity Header Fields defined in [RFC8224]. However, there are scenarios where SIP-based in-band transmission is not feasible or the Identity Header Field may not be supported, such as legacy TDM interconnects or where intermediary network elements strip SIP Identity headers. STIR Out-of-Band (OOB) [RFC8816] addresses this generally for STIR by defining an OOB delivery model. [RFC9888] applies that model to interconnected service providers, using provider-operated placement services discovered through service-provider advertisements, whereas this document applies the model to entities identified by VESPER delegate certificates, with placement services discovered through certificate transparency.¶

The VESPER framework [I-D.wendt-stir-vesper] composes existing STIR mechanisms into a trust framework in which an entity is identified by a domain identifier bound to its telephone number right-to-use, carried in a telephone-number-scoped delegate certificate. This document relies on that framework for the definition, issuance, and verification of VESPER delegate certificates and does not restate them here; it defines how PASSporTs signed with those certificates are delivered out of band.¶

This document describes how the VESPER framework is applied to an out-of-band delivery mechanism corresponding to the model described in [RFC8816]. It enables authorized delegate certificate holders to deliver PASSporTs over an out-of-band path for retrieval and validation by a STIR Verification Service, maintaining continuity of trust across heterogeneous networks.¶

The VESPER OOB delivery model is based on a publish-and-retrieve interface using an open discovery model for PASSporT Placement Services (PPS). This document describes the publish-and-retrieve mechanism and its required properties, building on the concepts in [RFC8816], rather than prescribing a specific interface. It utilizes the following:¶

• A mechanism for announcing the associated OOB PASSporT Placement Services (PPSs) using the PPS URI attribute of the TN Attributes extension defined in [I-D.wendt-stir-cert-tn-attr-ext].¶

• A discovery mechanism for OOB endpoints using STI certificate transparency log monitoring, where PPS URIs carried in delegate certificates become publicly discoverable when those certificates are logged.¶

It also optionally supports Connected Identity [RFC9970], enabling both parties to authenticate their telephone numbers and establish end-to-end identity assurance, as also adopted by VESPER [I-D.wendt-stir-vesper].¶

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.¶

VESPER: Verifiable STI Presentation and Evidence for RTU [I-D.wendt-stir-vesper].¶

PASSporT: Personal Assertion Token as defined in [RFC8225].¶

Delegate Certificate: A certificate issued to an entity asserting right-to-use for a telephone number, based on an authority token, as defined in [RFC9060] and profiled in [I-D.wendt-stir-vesper].¶

Authority Token: A signed assertion that authorizes the issuance of a delegate certificate and represents the authorization of a subject's right-to-use a telephone number and any associated claims, defined in [RFC9447].¶

PASSporT Placement Service (PPS): The service that stores signed PASSporTs published by an originating party and serves them to an authorized retrieving party, and that supports the optional Connected Identity response exchange. Earlier STIR out-of-band work, notably [RFC8816], refers to this role as a Call Placement Service (CPS). This document uses PASSporT Placement Service for two reasons. First, the CPS acronym collides with Certification Practice Statement (CPS) as used in [RFC8226] and certificate policy practice generally, which is a recurring source of ambiguity in a document that deals with both certificates and this service. Second, the service places and serves PASSporTs and is not limited to telephone calls; the same mechanism is intended to apply to applications beyond telephone calls, for which a PASSporT-centric name is more accurate.¶

PPS URI: A URI [RFC3986] identifying a PASSporT Placement Service (PPS), carried in the pps-uris attribute (type 1) of the TN Attributes extension [I-D.wendt-stir-cert-tn-attr-ext]. The PPS URI identifies the PASSporT Placement Service (PPS) for the telephone numbers covered by the certificate.¶

PPS Discovery: The process of identifying the PPS endpoint responsible for a given telephone number by monitoring STI-CT logs for delegate certificates carrying a PPS URI attribute as defined in [I-D.wendt-stir-cert-tn-attr-ext].¶

3. VESPER OOB Architectural Overview

The VESPER OOB architecture enables the out-of-band signing, publishing, discovery, and verification of PASSporTs using a trust framework based on delegate certificates and transparency mechanisms. The out-of-band path is a general mechanism for delivering PASSporTs from an originating party to a destination party, independent of any particular signaling protocol. It may operate alongside an in-band signaling path, such as a SIP call in which the PASSporT would otherwise travel in an Identity header field, or it may be the sole channel between the two parties, as in messaging, non-SIP signaling, or other applications where there is no in-band path to carry the PASSporT. Figure 1 illustrates the flow of identity data between the authentication service, the out-of-band PASSporT Placement Service (PPS), and the verification service, with the in-band signaling path shown as an optional parallel path.¶

        +--------------------+  Originate communication over an
        |   Authentication   |  in-band signaling path, if any
        |     Service        |  (e.g. SIP INVITE with RFC8224
        | (Originating Party)|   Identity Header Field)
        +---------+----------+-------------------+
                  |                              |
                  | 1. Publish PASSporT with     |
                  |    Delegate Certificate      |
                  v                          .~~~~~~~~~~.
        +---------+----------+           .-''             '-.
        |        PPS         |        ,.'    In-band         '.
        |                    |       /    signaling path     |
        +---------+----------+      |    (e.g. SIP), if any  /
                  ^                  '.___..~~~~~~..______.'
                  |                              |
                  | 2. Retrieve PASSporT         |
                  |                              |
        +---------+----------+                   |
        |    Verification    |                   |
        |      Service       |<------------------+
        | (Destination Party)|  Receive communication over the
        +--------------------+  in-band signaling path, if any

Figure 1 - Architecture showing out-of-band PASSporT delivery alongside an optional in-band signaling path¶

4. VESPER OOB Mechanism

This section describes how PASSporTs are delivered out of band through a PASSporT Placement Service (PPS), and how Connected Identity allows the called party to return a signed response. Following the approach of [RFC8816], this document describes the mechanism and the properties an implementation must preserve, rather than prescribing a specific API. A PPS interface that provides these operations and preserves these properties is conformant; implementers may adopt an existing publish-and-retrieve interface or define their own.¶

   A (Originating)              PPS               B (Destination)
        |                         |                       |
        | 1. Publish PASSporT(s)  |                       |
        |    for (orig=A,dest=B), |                       |
        |    authorized by A's    |                       |
        |    delegate certificate |                       |
        | ----------------------> |                       |
        |   (handle, if Connected |                       |
        |     Identity requested) |                       |
        | <---------------------- |                       |
        |                         |  2. Retrieve PASSporT(s)
        |                         |     for (orig=A,dest=B),
        |                         |     authorized by B's
        |                         |     delegate certificate
        |                         | <-------------------- |
        |                         |  PASSporT(s) (+ handle
        |                         |  if Connected Identity)
        |                         | --------------------> |
        |                         |                       |
        |                         |  3. Respond with rsp  |
        |                         |     PASSporT against  |
        |                         |     handle, authorized
        |                         |     by B's delegate cert
        |                         | <-------------------- |
        | 4. Retrieve rsp         |                       |
        |    PASSporT for handle, |                       |
        |    authorized by A's    |                       |
        |    delegate certificate |                       |
        | ----------------------> |                       |
        | <---------------------- |                       |
        |    rsp PASSporT         |                       |
        |                         |                       |

5. Authentication Service Procedures for VESPER OOB

Authentication Services that sign PASSporTs for out-of-band delivery follow the core VESPER specification [I-D.wendt-stir-vesper], together with the additional procedures in this section that are specific to the out-of-band case.¶

The role of the Authentication Service is to author the PASSporT: to construct and sign it using the VESPER delegate certificate and the VESPER PASSporT usage profile, asserting the originating identity. This authored PASSporT is the same artifact regardless of how it is delivered. In the in-band case it travels with the communication, for example in a SIP Identity header field; in the out-of-band case it is the PASSporT placed in the PASSporT Placement Service (PPS) for the destination party to retrieve. Out-of-band delivery may be the sole path between the two parties, as in messaging or other applications where there is no in-band path that can carry the PASSporT, or it may run alongside an in-band copy of the same PASSporT. In all of these cases the authoring of the PASSporT is unchanged; what is specific to out-of-band operation is that the authored PASSporT is published to a PPS rather than, or in addition to, being carried in band. The subsections below state the certificate properties this relies on and the delivery step that is specific to out-of-band operation.¶

6. PPS URI and OOB PPS Discovery

PPS URIs are associated with VESPER delegate certificates through the pps-uris attribute (type 1) of the TN Attributes extension defined in [I-D.wendt-stir-cert-tn-attr-ext]. This attribute carries one or more HTTPS URIs identifying the PPS endpoints responsible for publishing and serving PASSporTs for the telephone numbers covered by the certificate's TNAuthList.¶

When a VESPER delegate certificate carrying a PPS URI attribute is submitted to a Secure Telephone Identity Certificate Transparency (STI-CT) log [I-D.ietf-stir-certificate-transparency], the PPS URI becomes publicly visible and verifiable. Parties that wish to discover the PPS for a given telephone number do so by monitoring STI-CT logs for delegate certificates that carry a PPS URI attribute, extracting the telephone numbers and PPS URI from each certificate, and associating the covered telephone numbers with the indicated PPS endpoint. This approach provides a transparent, cryptographically verifiable discovery mechanism that does not require bilateral provisioning or static configuration between service providers.¶

The discovery process follows these steps:¶

1. A VESPER delegate certificate carrying a TNAuthList and a PPS URI attribute is issued and submitted to a STI-CT log, generating an SCT.¶

2. A monitoring party observes the log, verifies the certificate chain to a trusted STI root, validates the SCT, and extracts the telephone-number-to-PPS mappings.¶

3. Authentication Services and Verification Services consult these mappings to identify the appropriate PPS endpoint for a given call.¶

4. PASSporTs are published or retrieved using the discovered PPS URI as part of the OOB authentication process.¶

Implementations MAY maintain local caches of telephone-number-to-PPS mappings, respecting certificate validity periods when using extracted data. PPS operators SHOULD publish delegate certificates in multiple STI-CT logs to ensure broad visibility. The PPS URI MUST resolve to a reachable and operational PPS that supports the VESPER OOB mechanism defined in this document.¶

The mechanism permits a certificate to carry more than one PPS URI, so that an operator can advertise multiple PPS instances, including regional or edge instances. Where multiple instances are advertised, an implementation can select among them or fail over between them using local policy such as lowest latency or geographic proximity. The degree of redundancy that is appropriate is a matter of deployment experience and local policy, and is not specified here.¶

7. Verification Service Procedures for VESPER OOB

Verification Services that retrieve and validate PASSporTs via the VESPER OOB model MUST implement the following procedures in addition to those defined fundamentally in [RFC8224] and specific to VESPER defined in [I-D.wendt-stir-vesper].¶

8. Security Considerations

PASSporTs in VESPER OOB are signed using VESPER delegate certificates, which a verifier validates using the full VESPER verification [I-D.wendt-stir-vesper]. This dependence on the signed PASSporT and its VESPER delegate certificate, rather than on the delivery path, is what allows a verifier to establish the originating identity independently of how the PASSporT was delivered out of band.¶

The publish, retrieve, and respond operations are authorized as described in the VESPER OOB Mechanism section, with each request signed by the requesting party's VESPER delegate certificate, scoped to a single transaction, and protected against replay through a unique request identifier and a short freshness window. Because the integrity of a published PASSporT is bound to that authorization, stored content cannot be substituted without detection.¶

A PPS is not assumed to be an openly writable, anonymously accessible endpoint. PPS operators are expected to administer their own admission controls governing which parties may reach the service at all, for example through operator-managed credentials, peering arrangements, or network-level access policy. The design of that admission layer is a matter for the operator and is out of scope for this document. Within an admitted context, the requirement that each operation be signed by the requesting party's VESPER delegate certificate is what authorizes the specific action on a specific telephone number. This is an appropriate use of the delegate certificate: the certificate is the cryptographic representation of the subject's right-to-use for the telephone numbers in its TNAuthList, so a request signed by it, and scoped to those numbers, expresses exactly the authorization needed to publish or retrieve PASSporTs for them. A party cannot use this mechanism to publish for a telephone number it does not hold a valid certificate for.¶

The authentication of the requester and the integrity of each PASSporT are cryptographic and do not depend on the PPS behaving honestly: a verifier validates each retrieved PASSporT and its signing certificate independently, so a misbehaving or compromised PPS cannot cause acceptance of a forged or altered identity assertion. Other properties, such as scoping retrieval to the intended originating and destination pair and keeping a Connected Identity exchange confidential to its two parties, are enforced by the PPS as a relied-upon party rather than guaranteed cryptographically by the signed request alone. A compromised PPS could therefore affect the availability of PASSporTs, or the confidentiality and scoping of an exchange, even though it cannot forge the identities asserted within. The degree of additional assurance an operator places on PPS behavior is a matter of deployment and local policy.¶

In a Connected Identity exchange, the transaction handle and the response are sensitive. The Confidentiality property required in the VESPER OOB Mechanism section limits their disclosure to the parties of the original transaction, with the response made available only to the party that performed the original publish. A further concern is that the existence or pending state of a transaction handle can itself be sensitive: to avoid confirming a handle to an unauthorized requester, a PPS should not distinguish, in its observable behavior, between a handle that does not exist and one the requester is not authorized to access.¶

A PPS handles identity data and is exposed to request-volume abuse, so operators should apply rate limiting and should retain identity data only as long as operationally necessary.¶

9. IANA Considerations

This document has no IANA actions.¶

10. References

Acknowledgments

The authors thank the contributors of the STIR working group, whose out-of-band work informed the mechanism described in this document for PASSporT delivery signed with VESPER delegate certificates.¶

Authors' Addresses