]> Somos Inc.

US chris@appliedbits.com

Somos Inc.

US robjsliwa@gmail.com

Applications and Real-Time Secure Telephone Identity Revisited stir certificates delegate certificates oob This document describes a mechanism for delivering authenticated telephone call identity information using the VESPER framework for use where in-band signaling does not carry the identity end to end, or where there is no in-band path between the parties at all. By supporting an out-of-band (OOB) transport model, this approach enables entities to publish and retrieve signed PASSporT assertions independent of end-to-end delivery within an in-band signaling path such as a SIP-based VoIP network. These PASSporTs are signed with VESPER delegate certificates, which identify the entity holding the right-to-use for a telephone number and bind it to that entity's domain identity. This document also introduces support for Connected Identity to the STIR OOB model, enabling the called party to respond with a signed PASSporT asserting its identity, thereby binding the identities of both parties to the transaction and enhancing end-to-end accountability. The OOB mechanism provides a delivery path for PASSporTs where in-band delivery within a signaling path such as SIP is unavailable or is not the path used, enabling verifiers to confirm the association between the originating telephone number and the identity asserting authority as part of the broader VESPER trust framework. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Telephone Identity Revisited Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The STIR framework enables the signing and verification of telephone communications using PASSporT objects carried in SIP in Identity Header Fields defined in . 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) addresses this generally for STIR by defining an OOB delivery model. 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 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 . 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 , 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 . 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 , enabling both parties to authenticate their telephone numbers and establish end-to-end identity assurance, as also adopted by VESPER .

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 when, and only when, they appear in all capitals, as shown here. VESPER: Verifiable STI Presentation and Evidence for RTU . PASSporT: Personal Assertion Token as defined in . Delegate Certificate: A certificate issued to an entity asserting right-to-use for a telephone number, based on an authority token, as defined in and profiled in . 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 . 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 , 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 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 identifying a PASSporT Placement Service (PPS), carried in the pps-uris attribute (type 1) of the TN Attributes extension . 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 .

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.

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

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

Operations The mechanism is built from three operations against a PPS: Publish: the originating party places one or more signed PASSporTs for a given originating and destination pair into the PPS, so they can be retrieved by the destination party. A publish operation MAY also request a Connected Identity exchange, in which case the PPS returns a transaction handle that identifies the exchange. Retrieve: the destination party obtains the PASSporTs published for a given originating and destination pair, and, where a Connected Identity exchange was requested, learns the transaction handle. Respond: where Connected Identity is in use, the destination party places a signed response PASSporT against the transaction handle, which the originating party then retrieves. Each operation is authorized by the requesting party signing its request with its VESPER delegate certificate, so that the PPS and the counterparty can confirm the requester is authorized for the telephone number involved. The integrity of the published PASSporTs is bound to that authorization so that stored content cannot be substituted. The mechanism used to convey and authorize these operations is not defined here; an implementation may use any mechanism that authenticates the requesting party and protects the integrity of the request.

Required Properties An implementation of the VESPER OOB mechanism preserves the following properties, however the PPS interface is realized. Some of these properties are guaranteed cryptographically by the signed request and the signed PASSporT, while others are enforced by the PPS as a relied-upon party; the Security Considerations section discusses this distinction and its consequences. Authorization: publish, retrieve, and respond requests are authorized by the requesting party using its VESPER delegate certificate. The PPS and the counterparty can verify that the requester is authorized for the originating or destination identifier it is acting for, consistent with the certificate's TNAuthList. Scoping: retrieval is scoped to a specific originating and destination pair, so that a party can obtain only the PASSporTs intended for an exchange it is part of. Integrity: the authorization of a publish or respond request is bound to the PASSporT content it carries, so that the stored PASSporTs cannot be altered or substituted without detection. Replay resistance: requests are protected against replay, for example through a unique request identifier and a freshness window, and are scoped to a single transaction rather than reused. Confidentiality of the exchange: in a Connected Identity exchange, the transaction handle and the response are disclosed only to the parties of the original transaction. In particular, the response is made available only to the party that performed the original publish. Transport security: all PPS interactions occur over a server-authenticated secure transport.

Mechanism Flow The following sequence illustrates the mechanism. Steps 1 and 2 are the basic publish-and-retrieve flow for delivering a PASSporT from the originating party (A) to the destination party (B). Steps 3 and 4 are the optional Connected Identity exchange, in which B returns a signed response PASSporT for A to retrieve.

| | | (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 | | | | | ]]>

Figure 2 - VESPER OOB publish/retrieve (steps 1-2) and optional Connected Identity exchange (steps 3-4) In the basic flow, A publishes the PASSporTs it would otherwise have carried in the SIP Identity header field, and B retrieves and verifies them as part of terminating the call. In the Connected Identity flow, the transaction handle returned at publish ties B's response to the original transaction. B can respond only after retrieving the original PASSporTs, so that it has had the opportunity to verify A before asserting its own identity, and only A, as the original publisher, can retrieve B's response. The verification of the retrieved PASSporTs, in both directions, is described in the verification procedures below.

Authentication Service Procedures for VESPER OOB Authentication Services that sign PASSporTs for out-of-band delivery follow the core VESPER specification , 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.

Delegate Certificate Requirements Certificates used to sign PASSporTs in VESPER OOB are VESPER delegate certificates as defined and profiled in ; this document adds no requirements on the certificate beyond those of VESPER other than the one specific to out-of-band discovery below. For out-of-band operation, the signing certificate MUST carry one or more PPS URIs in the pps-uris attribute of the TN Attributes extension , enabling discovery of the associated OOB PASSporT Placement Service (PPS) as described in the PPS URI and OOB PPS Discovery section.

PASSporT Construction Requirements PASSporTs delivered over VESPER OOB are constructed and signed as defined in the VESPER PASSporT usage profile . VESPER OOB adds no requirements on the content of the PASSporT itself; the orig, dest, and iat claims and the x5c and x5u headers are populated as that profile specifies. The one requirement specific to OOB is delivery: rather than, or in addition to, carrying the PASSporT in a SIP Identity header field, the Authentication Service publishes the signed PASSporT to the PPS identified by the PPS URI in the signing certificate, using the publish operation of the VESPER OOB mechanism.

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 . 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 , 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: A VESPER delegate certificate carrying a TNAuthList and a PPS URI attribute is issued and submitted to a STI-CT log, generating an SCT. 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. Authentication Services and Verification Services consult these mappings to identify the appropriate PPS endpoint for a given call. 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.

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 and specific to VESPER defined in .

Retrieval and Validation Process PPS URI Resolution: Determine the PPS URI for the given telephone number by consulting telephone-number-to-PPS mappings derived from monitoring STI-CT logs for delegate certificates carrying a PPS URI attribute, as described in the PPS URI and OOB PPS Discovery section of this document. PASSporT Retrieval: Perform the retrieve operation of the VESPER OOB mechanism against the resolved PPS, scoped to the originating and destination pair and authorized by the verifier's VESPER delegate certificate, as described in the VESPER OOB Mechanism section. Multiple PASSporT Handling: If the retrieved response contains multiple PASSporTs, the verifier MUST validate each PASSporT independently. All PASSporTs MUST share the same orig, dest, and iat values and MUST be signed by the same delegate certificate. If any PASSporT fails validation, the verifier SHOULD reject the entire set and SHOULD log the failure for diagnostic purposes. The verifier MAY apply local policy to determine which PASSporT types are actionable.

PASSporT Validation Once retrieved, the verifier validates the PASSporT and its signing certificate exactly as specified by the VESPER framework , which applies the procedures of and the VESPER certificate and binding checks. VESPER OOB places no additional requirements on this validation and does not modify it; the only difference from the in-band case is that the PASSporT was obtained by retrieval from the PPS rather than from a SIP Identity header field. The verifier applies the full VESPER verification to each retrieved PASSporT before relying on it, so that end-to-end trust in the originating identity is established even across heterogeneous network paths or in the absence of SIP Identity header delivery.

Connected Identity Validation When a Connected Identity response PASSporT (rsp) is retrieved by the Verification Service (VS), it MUST be validated in accordance with and the VESPER framework . The rsp PASSporT and its signing certificate are validated using the full VESPER verification, as for any VESPER PASSporT; the requirements below are those specific to the Connected Identity response in the out-of-band context. The rsp PASSporT MUST be signed using a VESPER delegate certificate valid for the dest telephone number of the original call. The distinction from originating-direction verification is that the responder is asserting control over the dest number, so the signing certificate's TNAuthList MUST authorize that number. The VS MUST confirm that the orig and dest claims in the rsp PASSporT match those of the original transaction, and that the iat claim is within an acceptable freshness interval as defined by local policy. If these validations succeed, the verifier can confirm that the called party has cryptographically asserted its identity using a VESPER-authorized certificate, completing the Connected Identity flow. Any failure MUST cause the rsp PASSporT to be rejected.

Security Considerations PASSporTs in VESPER OOB are signed using VESPER delegate certificates, which a verifier validates using the full VESPER verification . 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.

IANA Considerations This document has no IANA actions.

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality. The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. However, the Secure Telephone Identity Revisited (STIR) framework provides no means for determining the identity of the called party in a conventional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP identity that accompanied STIR. It also considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination and preventing the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. Somos, Inc. Somos, Inc. TransNexus Twilio This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR eco-system, focusing on verifiable control over telephone number or service provider code resources. Somos, Inc. Somos, Inc. This document defines VESPER (Verifiable STI Presentation and Evidence for RTU), a framework that extends the STIR architecture to cryptographically bind telephone number authority, domain identity, and originating provider authorization in a single delegate certificate. The delegate certificate is issued under the certificate policy defined under a STIR compliant eco-system and carries the assigned telephone numbers and authorized originating providers in a TNAuthList extension, the responsible entity's domain in a SubjectAltName, and an embedded Signed Certificate Timestamp (SCT) proving the certificate was recorded in a public transparency log prior to use. VESPER enables relying parties to verify that a telephone number was assigned to the entity whose domain is presented, and that calls from those numbers are originated by an authorized originating provider. The framework defines a certificate profile and issuance process grounded in existing STIR and ACME authority token mechanisms, a domain-hosted certificate repository with domain-controlled certificate discovery enabling cross-channel trust signals, a PASSporT usage profile for SIP signaling, and certificate transparency to support ecosystem auditability and detection of mis- issuance. Somos Inc. Somos Inc. This document specifies a non-critical X.509 v3 certificate extension that conveys a set of self-asserted attributes describing the telephone numbers identified in the certificate's TNAuthList. The attributes are declared by the holder of the certificate about its own telephone numbers and require no separate authority token, because they describe or constrain only those numbers and grant no authority to any other party. The extension defines an extensible framework with an IANA registry of attribute types and seeds that registry with four types: a PASSporT Placement Service (PPS) URI, a do-not-originate indication, a do-not-originate-messaging indication, and a set of authorized originating providers. Relying parties use these self-declarations as policy signals, treating communications that do not conform to them as candidates for blocking. The mechanism is backward compatible with existing STIR certificates. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Personal Assertion Tokens (PASSporTs) either in-band, within the headers of a Session Initiation Protocol (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers for cases in which in-band STIR conveyance is not universally available.

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.