]> Somos Inc.

US robjsliwa@gmail.com

Somos Inc.

US chris@appliedbits.com

AREA WG Working Group stir certificates delegate certificates oob This document defines a Discovery Service for STIR Out-of-Band (OOB) Call Placement Services (CPS). The Discovery Service enables Authentication Services (AS) and Verification Services (VS) to quickly determine which CPS is responsible for a given telephone number (TN) or Service Provider Code (SPC), allowing retrieval of PASSporTs even when SIP Identity headers are removed by non-IP or hybrid network segments. The Discovery Service leverages a CPS URI certificate extension, which allows STIR Certificates or Delegate Certificates to embed an HTTPS URI for the CPS serving the TNs or SPCs covered by the certificate. 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 In a STIR ecosystem, defined primarily by , , and , and specifically when enabling Out-of-Band (OOB) delivery of PASSporTs defined in , a Call Placement Service (CPS) plays a vital role, particularly when SIP Identity headers are lost or removed in non-IP or hybrid network environments. While the role of CPS was well established in , the challenge remained for the definition of discovering which CPS is responsible for a specific telephone number (TN) or Service Provider Code (SPC) in a secure, scalable, and interoperable way. This document introduces a CPS Discovery Service designed to solve that challenge. The CPS Discovery Service provides a transparent and cryptographically verifiable method for identifying the correct CPS for any given TN or SPC identified in the TNAuthList of a STIR certificate defined in , supporting OOB call authentication without requiring static configuration or bilateral agreements between service providers. The CPS Discovery Service operates by leveraging the CPS URI certificate extension defined in . This extension allows STIR Certificates or Delegate Certificates to encode an HTTPS URI pointing to the CPS responsible for the TNs or SPCs listed in the certificate's TNAuthList. Once such certificates are published to STIR Certificate Transparency (STI-CT) logs defined in , the CPS URI becomes immediately visible, auditable, and publicly verifiable by relying parties. To facilitate CPS discovery, the Discovery Service continuously monitors these CT logs, extracts CPS URIs from newly issued or updated certificates, and registers mappings from TNs or SPCs to CPS endpoints. These mappings are exposed via a simple REST API that supports fast, automated lookups by Authentication Services (AS) and Verification Services (VS). By combining CPS URI certificate extensions with CT monitoring and a queryable discovery interface, this approach enables automatic OOB CPS discovery. It can integrate with existing STIR framework components and requires only an additional lookup step to improve the robustness and scalability of Out-of-Band PASSporT delivery.

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.

Architectural Overview This document defines a mechanism for discovering Call Placement Services (CPS) responsible for specific telephone numbers (TNs) or Service Provider Codes (SPCs) by monitoring STI Certificate Transparency (STI-CT) logs for certificates that include a CPS URI extension. Entities that operate a CPS obtain delegate certificates with TNAuthList entries covering the TNs or SPCs they serve. These certificates include a CPS URI extension as defined in , indicating the HTTPS endpoint of the CPS. Once issued, these certificates are submitted to STI-CT logs. Any relying party may monitor STI-CT logs for new or updated certificates containing a CPS URI extension. Upon detection, the CPS URI and its associated TNAuthList entries are extracted and recorded. This enables parties to associate TNs or SPCs with corresponding CPS URIs based on the content of logged certificates. This approach provides the following properties: Transparency: CPS endpoint declarations are logged and auditable through STI-CT. Verifiability: Mappings are derived from signed certificates anchored in existing STIR trust infrastructure and supported by Signed Certificate Timestamps (SCTs). No bilateral provisioning: Originating and terminating parties do not require prior agreement or static configuration to determine the correct CPS. Compatibility: The mechanism is fully compatible with the STIR Out-of-Band (OOB) architecture as defined in and requires no modification to existing CPS publish or retrieve interfaces. While this discovery mechanism is inherently distributed, relying solely on STI-CT log monitoring and information published in signed certificates, it does not preclude the existence of centralized or convenience-based services that aggregate CPS URI data. Such services may offer simplified access patterns, enhanced performance, or monitoring utilities for relying parties. However, any such intermediary or cache-based service MUST preserve the verifiable nature of the CPS URI bindings by exposing the original certificate, Signed Certificate Timestamps (SCTs), and associated TNAuthList values. Consumers of CPS discovery data SHOULD validate the integrity and provenance of this information using the underlying CT log entries and certificate signatures, as defined in this document and related STIR specifications.

Components The discovery mechanism relies on existing STIR framework components and STI-CT logs. No new interfaces are required between entities. CPS operators signal the location of their service using a certificate extension, and relying parties extract and verify these declarations by monitoring CT logs.

Call Placement Service (CPS) A Call Placement Service (CPS), as defined in , is a network-accessible endpoint that stores PASSporTs for later retrieval during call verification. CPSs are used when SIP Identity headers are removed or unavailable, such as in non-IP or hybrid telephony environments. Originating entities publish PASSporTs to the CPS associated with the called party's number, and terminating entities retrieve them during call processing. This specification does not modify the behavior or interfaces of CPS endpoints. It only describes how CPS endpoint information is published and discovered using STIR certificates and delegate certificates and STI-CT.

Certificate Holders Entities responsible for telephone numbers or SPCs, such as service providers or enterprises, obtain STIR certificates or delegate certificates with TNAuthList entries covering those resources. These certificates may optionally as defined in this document include a CPS URI extension indicating the HTTPS endpoint of the CPS that serves those numbers to facilitate discovery. When these certificates are submitted to a recognized STI-CT log, the CPS URI becomes visible to relying parties monitoring the log. This allows third parties to discover the CPS associated with a number without requiring pre-provisioning or bilateral configuration.

Transparency Log Monitors Any party may monitor STI-CT logs for certificates containing a CPS URI extension. Upon detecting a new or updated certificate, the monitor performs the following: Verifies the certificate chain to a trusted STI root Validates the certificate's Signed Certificate Timestamps (SCTs) Extracts the TNAuthList and CPS URI from the certificate Associates the covered TNs or SPCs with the indicated CPS URI Monitors may use this data to maintain a local registry or cache of TN to CPS and SPC to CPS mappings. These mappings can be used by Authentication Services or Verification Services during call processing.

CPS Discovery Mechanisms This section describes the mechanism by which Call Placement Service (CPS) information is discovered through monitoring of STI-CT logs. This method provides a distributed, cryptographically verifiable, and interoperable means of associating telephone numbers (TNs) or Service Provider Codes (SPCs) with CPS endpoints.

Certificate-Based CPS Publication CPS operators often associated with entities authorized for telephone numbers or SPCs obtain STIR certificates or delegate certificates containing a TNAuthList and the CPS URI certificate extension as defined in . The CPS URI identifies the CPS HTTPS endpoint where Out-of-Band (OOB) PASSporTs can be published or retrieved for the associated identifiers. These certificates are submitted to one or more recognized STI-CT logs. Each submission yields a Signed Certificate Timestamp (SCT), which proves inclusion in the log and enables public verification.

Discovery via Log Monitoring Relying parties (e.g., Authentication Services, Verification Services, or intermediary discovery components) monitor STI-CT logs for new or updated certificates that include a CPS URI extension. Upon detection, the monitor performs the following steps: Verifies the certificate chain to a trusted STI root. Validates the SCT(s) associated with the certificate. Extracts the TNAuthList and the CPS URI extension. Associates the covered TNs or SPCs with the CPS URI. The resulting mappings are used to determine the appropriate CPS endpoint during call placement and verification. This process allows discovery to be performed in real-time or asynchronously using CT log clients, without requiring direct interaction with the certificate holder or CPS operator.

End-to-End Process Summary A STIR certificate or delegate certificate is issued containing TNAuthList and CPS URI. The certificate is logged in an STI-CT log, generating SCTs. A monitoring system observes the log and extracts TN-CPS and SPC-CPS mappings. Authentication or Verification Services consult the mappings to identify the CPS endpoint corresponding to a given TN or SPC. PASSporTs are published or retrieved using the discovered CPS URI as part of the OOB authentication process. This approach removes the need for authoritative registries, REST-based discovery interfaces, or bilateral provisioning agreements. All discovery is based on cryptographic credentials and public transparency logs, ensuring an auditable and interoperable discovery process.

Expected Monitor Behavior Parties that wish to perform CPS discovery may monitor one or more STI-CT logs for delegate certificates containing the CPS URI extension. Monitors are expected to: Validate certificate chains to STI trust anchors. Verify inclusion of certificates via Signed Certificate Timestamps (SCTs). Extract the CPS URI and TNAuthList from certificates. Associate telephone numbers or SPCs with the declared CPS URI. Monitors may use this information to enable Authentication Services (AS) or Verification Services (VS) to locate the appropriate CPS endpoint. Implementations may maintain local caches or registries based on the extracted data, respecting certificate validity periods and revocation status when available.

Security Considerations The CPS discovery mechanism relies on the integrity of STIR delegate certificates and STI-CT logs. Several security considerations apply: Misissued Certificates: A CPS URI could be falsely claimed in a certificate. Relying parties must validate that certificates are issued by trusted STIR Certification Authorities and verify TNAuthList accuracy during issuance. Log Misbehavior: CT logs may omit or backdate entries. Implementations should monitor multiple CT logs and validate Signed Certificate Timestamps (SCTs) to ensure visibility and integrity. Stale or Revoked Certificates: CPS mappings derived from expired or revoked certificates may lead to incorrect routing. Implementations should check certificate validity and revocation status before using extracted mappings. Information Exposure: CPS URIs and TNAuthList entries are publicly logged. This may reveal operational details but does not introduce new exposures beyond existing STIR practices. This mechanism inherits the security properties of the STIR certificate infrastructure and CT logging, offering verifiable, auditable discovery without requiring bilateral trust.

IANA Considerations This document has no IANA actions.

Somos Inc. Somos Inc. This document specifies a non-critical X.509 v3 certificate extension that conveys the HTTPS URI of a Call Placement Service (CPS) associated with the telephone numbers authorized in a STIR Delegate Certificate. The extension enables originators and verifiers of STIR PASSporTs to discover, with a single certificate lookup, where Out- of-Band (OOB) PASSporTs can be retrieved. The mechanism removes bilateral CPS provisioning, allows ecosystem-scale discovery backed by STI Certificate Transparency (STI-CT), and is fully backward compatible with existing STIR certificates and OOB APIs. 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. 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. 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.

Acknowledgments TODO acknowledge.