| Internet-Draft | CPS URI Certificate Extension | September 2025 |
| Sliwa & Wendt | Expires 9 March 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://github.com/appliedbits/draft-sliwa-stir-cert-cps-ext. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sliwa-stir-cert-cps-ext/.¶
Discussion of this document takes place on the Secure Telephone Identity Revisited Working Group mailing list (mailto:stir@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/stir/. Subscribe at https://www.ietf.org/mailman/listinfo/stir/.¶
Source for this draft and an issue tracker can be found at https://github.com/appliedbits/draft-sliwa-stir-cert-cps-ext.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 9 March 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC8224] and [RFC8225]. 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 [RFC8816]. 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 [I-D.wendt-stir-certificate-transparency].¶
This specification defines the syntax and semantics of the CPS URI certificate extension, describes how it is encoded in [X.509] certificates also defined in [RFC5280], 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 [RFC8226] and delegate certificates defined in [RFC9060] infrastructure, and supports enhanced transparency and automation in OOB PASSporT routing.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This [X.509] extension is non-critical, applicable only to end-entity certificates, and defined with ASN.1 [X.680] [X.681] [X.682] [X.683] later in this section.¶
This extension is intended for use in end-entity STI certificates [RFC8226] and delegate certificates [RFC9060] 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 [RFC8816] 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 [RFC8816], 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.¶
The extension ASN.1 module is defined as follows:¶
CPS-CERT-EXTENSION DEFINITIONS EXPLICIT TAGS ::=
BEGIN
id-pe OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 1 }
id-pe-cpsURI OBJECT IDENTIFIER ::= { id-pe TBD }
CPSURI ::= IA5String
END
¶
Certificates containing a CPSURI that is not an absolute HTTPS URI as defined in [RFC3986] 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.¶
The IA5String value MUST be an absolute URI [RFC3986] that:¶
The extension MUST be marked non-critical so that implementations that do not understand it can still validate the certificate.¶
A STIR Authentication Service (AS), defined in [RFC8224], that holds a Delegate Certificate containing id-pe-cpsURI SHOULD publish OOB PASSporTs to the indicated CPS.¶
A STIR Verification Service (VS), defined in [RFC8224] 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.¶
Figure 1 shows the message flow when the extension is present:¶
+------------+ (1) ACME w/ Authority Tokens +-----------+
| Enterprise |----------------------------->| 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
¶
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.¶
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 is requested to assign a new object identifier (OID) for the CPS URI certificate extension in the "PKIX Extension Registry" as follows:¶
TODO acknowledge.¶