]> Somos Inc.

robjsliwa@gmail.com

Somos Inc.

chris@appliedbits.com

Applications and Real-Time Secure Telephone Identity Revisited stir certificates delegate certificates 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. 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 (Secure Telephone Identity Revisited) framework provides a means of cryptographically asserting the identity of the calling party in a telephone call by using PASSporTs carried in SIP requests, as defined in and . To support deployment in environments where SIP Identity headers may be removed or are not end-to-end transmittable, such as in non-IP or hybrid telephony networks, the STIR Out-of-Band (OOB) mechanism was introduced in . In OOB scenarios, PASSporTs are published to a Call Placement Service (CPS) where they may be retrieved independently of the SIP signaling path. To enable discovery of the appropriate CPS for a given telephone number or SPC, this document defines a certificate extension that binds a CPS URI to the identity resources listed in the TNAuthList of the STI certificate. This CPS URI extension provides a verifiable association between a number resource and its corresponding CPS, enabling relying parties to discover CPS endpoints by observing STI Certificate Transparency (STI-CT) logs defined in . This specification defines the syntax and semantics of the CPS URI certificate extension, describes how it is encoded in certificates also defined in , and outlines validation procedures for Certification Authorities and relying parties. This extension is intended to be used in conjunction with existing STIR certificates defined in and delegate certificates defined in infrastructure, and supports enhanced transparency and automation in OOB PASSporT routing.

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.

The id-pe-cpsURI Certificate Extension This extension is non-critical, applicable only to end-entity certificates, and defined with ASN.1 later in this section. This extension is intended for use in end-entity STI certificates and delegate certificates that include TNAuthList values authorizing the use of specific telephone numbers or Service Provider Codes (SPCs). The CPS URI extension provides a means for the certificate holder to declare the HTTPS endpoint of a Call Placement Service (CPS) defined in that can be used to publish or retrieve PASSporTs for the covered resources. The presence of this extension allows relying parties to discover the CPS associated with a given telephone number without relying on static configuration or bilateral agreements. This facilitates scalable and verifiable Out-of-Band PASSporT delivery as defined in , using information already published in publicly logged STI certificates. The extension is encoded as an IA5String containing an absolute HTTPS URI and is identified by an object identifier (OID) assigned in the PKIX id-pe arc. Additional details about the encoding, semantics, and validation rules for the CPS URI are defined in the sections below.

ASN.1 Module Syntax The extension ASN.1 module is defined as follows:

Certificates containing a CPSURI that is not an absolute HTTPS URI as defined in MUST be considered invalid by relying parties. Note: The numeric assignment TBD is temporary. IANA will allocate a permanent arc under "PKIX SubjectPublicKeyInfo Certificate Extensions" during RFC publication.

Extension Semantics The IA5String value MUST be an absolute URI that: Uses the "https" scheme. Identifies the root of the CPS HTTPS API interface (e.g., "https://cps.example.net/oob/v1").

Criticality The extension MUST be marked non-critical so that implementations that do not understand it can still validate the certificate.

Processing Rules A STIR Authentication Service (AS), defined in , that holds a Delegate Certificate containing id-pe-cpsURI SHOULD publish OOB PASSporTs to the indicated CPS. A STIR Verification Service (VS), defined in that receives a PASSporT signed by such a certificate MAY derive the CPS endpoint by reading the extension, or MAY query an external discovery directory that is populated by monitoring the STI-CT logs. If the extension and an external directory disagree, verifiers SHOULD treat the call as unverifiable unless local policy states otherwise. Relying parties SHOULD ensure that the certificate containing the CPS URI is present in a trusted Certificate Transparency log before using the URI for OOB operations.

Use with Out-of-Band Figure 1 shows the message flow when the extension is present:

| CA / CT | +------------+ Delegate Cert w/ CPS URI ext +-----------+ | | | | (2) SIP INVITE + PASSporT | | v | | +-----------+ (3) GET CPS/PASSporT via HTTPS | | | VS/CPS |<---------------------------------+ | +-----------+ | ^ | | +------------+ +-----------------------------------| CT Monitor | +------------+ Figure 1 ]]>

The enterprise obtains a Delegate Certificate containing the CPS URI. The CA submits the certificate to STI-CT. On each call, the AS signs a PASSporT with Delegate Certificate containing SCT. The terminating VS reads the CPS URI from the certificate and fetches the PASSporT.

Operational Considerations Logging: CAs issuing certificates with id-pe-cpsURI MUST submit the certificate to STI-CT logs. Rotation: Changing a CPS hostname or path requires certificate re-issuance. Operators SHOULD minimize TTLs on old URIs during migration. Monitoring: Relying parties and CPS discovery services SHOULD monitor trusted STI-CT logs for new or updated CPS URI declarations to ensure timely access and detect misconfiguration.

Security Considerations The CPS URI certificate extension introduces a mechanism for associating telephone number resources with CPS endpoints through STI certificates. The following considerations apply: Misuse or Misissuance: A malicious or misconfigured entity may include a CPS URI in a certificate without authorization for the corresponding TNAuthList resources. Certification Authorities (CAs) MUST validate that the entity requesting the certificate has authority over the listed numbers or SPCs before issuing the certificate. URI Integrity: The CPS URI is not digitally signed independently of the certificate. Relying parties MUST validate the entire certificate chain and ensure the certificate is properly logged in a Certificate Transparency log before using the URI. Certificate Expiry and Revocation: CPS URI information may become outdated due to certificate expiration or revocation. Relying parties SHOULD evaluate certificate validity and revocation status when interpreting CPS mappings. Log Availability and Monitoring: Relying parties that depend on CT log monitoring for CPS discovery SHOULD monitor multiple trusted logs to ensure timely detection of CPS declarations and prevent omission attacks. Information Exposure: The publication of CPS URIs in publicly logged certificates may reveal deployment metadata. This exposure is consistent with existing STIR delegate certificate practices and does not introduce additional privacy risk beyond what is already present in TNAuthList usage.

IANA Considerations IANA is requested to assign a new object identifier (OID) for the CPS URI certificate extension in the "PKIX Extension Registry" as follows: Name: id-pe-cpsURI OID: to be assigned Description: Certificate extension for specifying a Call Placement Service (CPS) URI for STIR Out-of-Band PASSporTs Reference: This document

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] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [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. 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. International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union 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.