]> Somos, Inc.

US chris@appliedbits.com

Somos, Inc.

US robjsliwa@gmail.com

Applications and Real-Time Secure Telephone Identity Revisited telephone number domain 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.

Introduction The Secure Telephone Identity (STI) architecture, based on STI certificates , PASSporTs , and the SIP Identity header field , provides cryptographic integrity protection for calling information in real-time communications. These mechanisms enable relying parties to verify that a telephone number was not modified in transit and that it was signed using credentials authorized for that number. However, the STI architecture does not define how to verify that a telephone number is being used by the entity it was assigned to, nor does it provide a way to identify which originating providers are authorized to place calls from those numbers. In practice, telephone numbers appear across a wide range of digital contexts: in SIP signaling, on websites, in SMS and rich communication messages, and in email. Today, there is no standard mechanism for a relying party to verify that the entity asserting a telephone number is the same entity it was assigned to, or to confirm that an originating provider is one of the legitimate originators authorized for that number. This gap enables impersonation, unauthorized origination, and the presentation of misleading contact information across digital channels. VESPER addresses this by defining a delegate certificate that serves as a single, auditable trust artifact binding three things: the telephone numbers assigned to the responsible entity, the domain that entity controls and for which it holds certificate credentials, and the set of originating providers enabled as legitimate originators for calls from those telephone numbers. Because this binding is expressed in a standard X.509 certificate subject to the certificate policy defined in , it can be validated using widely deployed PKI mechanisms and recorded in a transparency system for ecosystem auditability. This document defines the certificate profile, the certificate repository and domain-controlled certificate discovery mechanism, the PASSporT usage profile, and the relationship to origination policy distribution.

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.

Overview

The VESPER Delegate Certificate The VESPER framework is built around a delegate certificate issued to the entity that holds the right-to-use for one or more telephone numbers. This certificate is issued under the certificate policy defined in , whose trust anchors govern the authority chain. The delegate certificate represents the issued credentials that bind telephone number authority to the assigned entity, which also holds domain credentials as a corroborating identity signal. Trust assertions in VESPER are expressions of what is certified in this credential, validated against the trust anchors defined in through the certificate chain. The certificate carries the following: Telephone number authority: one or more telephone numbers (or ranges) in the TNAuthList extension, representing the entity's right-to-use as assigned by a responsible provider or organization. The authority chain is established via a TNAuthList Authority Token issued by that responsible provider or organization and validated through the STI certificate chain. Originating provider enablement: one or more service provider codes (SPCs) in the same TNAuthList extension, identifying the originating providers authorized to originate calls from those telephone numbers. Both TN entries and SPC entries MAY appear together in a single TNAuthList, as permitted by . Domain credential: a DNS domain name in the SubjectAltName extension (dNSName), representing a domain the entity controls and for which it holds WebPKI credentials. This domain provides a corroborating identity signal that is independent of the telephone number ecosystem and enables certificate discovery via the repository defined in this document. Optional claim constraints: JWTClaimConstraints and/or EnhancedJWTClaimConstraints extensions, authorizing additional PASSporT claims (such as Rich Call Data) and optionally constraining their values. These constraints are backed by a JWTClaimConstraints Authority Token issued in accordance with . Transparency: a Signed Certificate Timestamp (SCT) embedded in the certificate, proving that the certificate was submitted to and recorded in a transparency log before use. Short-lived certificates MUST be used. Implementations MUST support the profile in and MUST convey the certificate chain inline using the x5c header parameter and MUST include the x5u header parameter referencing the certificate at its domain-controlled repository location.

Domain as a Corroborating Trust Credential Prior STIR specifications establish telephone number authority through the TNAuthList but do not bind that authority to the real-world entity to which the number was assigned. VESPER addresses this by also recording a domain credential held by that entity, a domain the entity controls and for which it holds WebPKI certificate credentials. The domain in the delegate certificate SubjectAltName corresponds to a domain the entity controls. Control of that domain, established through the entity's ability to obtain certificate credentials for it, provides a corroborating identity signal that is independent of the telephone number ecosystem. When a relying party validates a VESPER delegate certificate, it obtains verifiable evidence that a specific entity, which holds those domain credentials, has been assigned the telephone numbers in the certificate by a responsible provider or organization.

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 to originate communications using those numbers through mechanisms defined by the entity's own governance, such as sub-credentials or access control policies, without those individuals being identified in the delegate certificate itself. A single telephone number may be authorized for use by multiple users or agents, as is common in shared lines and call center deployments. The delegate certificate identifies the entity that holds the right-to-use for the telephone numbers it contains, not the individual users or agents originating communications on behalf of that entity. Where caller identity at the individual level is desired, mechanisms such as Rich Call Data or other PASSporT extensions provide optional paths for conveying that information.

Certificate Repository and Domain-Controlled Certificate Discovery An entity that holds a VESPER delegate certificate MUST publish 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 MUST match the dNSName SubjectAltName of the VESPER delegate certificate, validated through standard WebPKI TLS. No cross-signing between the STI delegate certificate and the web TLS certificate is required or defined. This specification defines two token representations derived from the delegate certificate: a PASSporT as defined in for use in SIP signaling, and a basic JWT form that provides portable proof of right-to-use for a telephone number in contexts outside of SIP signaling, such as cases where a traditional letter of authorization or other evidence of TN association is required. Each is defined in detail in the sections below.

VESPER Roles and Certificate Issuance

Roles The VESPER framework defines the following functional roles. 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 delegate certificate's private key to sign PASSporTs and RTU Tokens. Right-to-Use (RTU) Authority: the responsible provider or organization that allocates telephone numbers and issues TNAuthList Authority Tokens as RTU evidence for delegate certificate issuance (e.g., a TNSP or RespOrg). STI Certification Authority (STI CA): issues VESPER delegate certificates after validating RTU evidence and domain association, operating under the certificate policy defined in . Transparency Log Operator: records issued delegate certificates and returns SCTs to support ecosystem auditability and detection of mis-issuance.

Delegate Certificate Issuance Process In the VESPER framework, a delegate certificate is issued through the following sequence: The RTU Authority produces a TNAuthList Authority Token representing the right-to-use for the telephone number(s) being assigned. The STI CA operates under a certificate policy that recognizes the RTU Authority's authority to make this assignment. The certificate subject generates a CSR and presents it to the STI CA along with the TNAuthList Authority Token, validated via ACME mechanisms as defined in , , and . If additional PASSporT claims are to be authorized (e.g., Rich Call Data ), a JWTClaimConstraints Authority Token is also presented; the STI CA MUST NOT widen the constraints specified in that token. Upon successful validation, the STI CA issues a delegate certificate. STI CAs SHOULD issue short-lived certificates as specified in , and subjects SHOULD automate renewal. The issued certificate MUST be submitted to a transparency log as defined in . The resulting SCT MUST be embedded in the certificate prior to deployment. The issued delegate certificate MUST include: A TNAuthList extension , representing the telephone number(s) the certificate holder is authorized to use and, where applicable, the SPC(s) of authorized originating providers. TN entries and SPC entries MAY appear together in a single TNAuthList extension. If the certificate is intended to authorize additional PASSporT claims beyond , it MUST also include: A JWTClaimConstraints extension and/or EnhancedJWTClaimConstraints extension .

VESPER Certificate Profile VESPER delegate certificates MUST conform to the STIR certificate profile in and MUST support the short-lived certificate profile in . The certificate MUST contain the following: Subject: SHOULD include an Organization (O) field reflecting the entity's name. SubjectAltName: MUST include a dNSName entry carrying the entity's domain. This domain MUST be DNS-resolvable and MUST match the domain of the certificate repository host. TNAuthList : MUST include one or more TN entries representing telephone numbers assigned to the certificate subject, and MAY include one or more SPC entries identifying authorized originating providers. TN and SPC entries MAY appear together in a single TNAuthList extension. SCT: MUST include an embedded Signed Certificate Timestamp as defined in , proving the certificate was submitted to a transparency log prior to deployment. Relying parties MUST validate the embedded SCT as part of certificate validation. JWTClaimConstraints and/or EnhancedJWTClaimConstraints (OPTIONAL): MUST be present if the certificate is intended to authorize PASSporT claims beyond . The STI CA MUST NOT widen the constraints specified in the JWTClaimConstraints Authority Token. CAs SHOULD issue certificates with short validity intervals as specified in , and subjects SHOULD automate renewal.

VESPER Authentication and Verification Procedures These procedures extend the baseline STIR authentication and verification models defined in , , and .

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 JWTClaimConstraints in the certificate. Signs the PASSporT using a VESPER delegate certificate whose TNAuthList authorizes the orig telephone number and that contains an embedded SCT. Conveys the certificate chain inline using the x5c header parameter. Includes the x5u header parameter containing the HTTPS URL of the delegate certificate at its location in the domain-controlled repository.

Verification Service Behavior Upon receiving a PASSporT, the Verification Service MUST: Validate the PASSporT signature. Validate the certificate trust chain against the trust anchors defined in using the x5c header parameter. Confirm the TNAuthList extension authorizes the orig telephone number. Validate the embedded SCT. If JWTClaimConstraints or EnhancedJWTClaimConstraints extensions are present, verify that all asserted claims conform to those constraints. Confirm that the domain in the x5u URL matches the dNSName SubjectAltName of the signing certificate. The PASSporT MUST be rejected if any of the above checks fail.

Connected Identity When VESPER is used with Connected Identity , 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 MUST include the original orig and dest values and a fresh iat. The originating party MUST verify the rsp PASSporT using the same certificate validation steps above, applied to the dest telephone number and the destination party's certificate.

RTU Token The RTU Token is a JWT 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 primary trust artifact; the RTU Token signature demonstrates that the presenter holds the corresponding private key. The token is intended for distribution contexts where portable evidence of right-to-use is needed outside of SIP signaling. The RTU Token MUST include: iss: the entity's domain (matching the dNSName SubjectAltName of the signing certificate) iat, exp: issuance and expiration times; exp SHOULD be set to a short validity interval to limit the replay surface 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 (e.g., Rich Call Data ).

Security Considerations VESPER provides verifiable evidence that an entity authorized to use one or more telephone numbers has signed a communication, with the delegate certificate serving as the primary trust artifact. The primary security properties are: prevention of unauthorized parties from asserting telephone number authority; prevention of over-claiming beyond what the certificate authorizes; and ecosystem auditability through certificate transparency. The certificate repository MUST be served over HTTPS and implementations SHOULD apply rate limiting to reduce the effectiveness of automated probing. The x5u URL in PASSporT headers MUST reference the certificate at its domain-controlled repository location; Verification Services MUST confirm the domain in the x5u URL matches the dNSName SubjectAltName of the signing certificate, providing proof of domain control without requiring a network fetch. The embedded SCT MUST be validated as defined in to confirm the certificate was publicly recorded before use. Short-lived certificates reduce dependence on revocation; relying parties MUST enforce certificate validity windows and SHOULD enforce freshness checks on PASSporT iat claims using existing STIR replay mitigations.

IANA Considerations This document defines no new IANA registrations. VESPER uses existing PASSporT claims defined in and certificate extensions defined in and .

Acknowledgments The authors would like to acknowledge Jon Peterson for valuable feedback on this document, and the STIR working group for the foundational specifications on which VESPER builds.

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. RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials; these certificates are often called "Secure Telephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT. 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. This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates. This document extends Personal Assertion Token (PASSporT), a token for conveying cryptographically signed call information about personal communications, to include rich metadata about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller- and call-specific information beyond human-readable display name, comparable to the "Caller ID" function common on the telephone network. It is also enhanced with an integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use cases. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. TransUnion Somos The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework, however, provides no means for determining the identity of the called party in a traditional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and 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, as well as the spoofing of mid-dialog or dialog- terminating events by intermediaries or third parties. Somos Inc. Somos Inc. This document defines an authority token profile for the validation of JWTClaimConstraints and EnhancedJWTClaimConstraints certificate extensions within the Automated Certificate Management Environment (ACME) protocol. This profile is based on the Authority Token framework and establishes the specific ACME identifier type, challenge mechanism, and token format necessary to authorize a client to request a certificate containing these constraints. TransUnion When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. 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. 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.