draft-sliwa-stir-cert-cps-ext — CPS URI Certificate Extension for STI Certificates

draft-sliwa-stir-cert-cps-ext (Sliwa, Wendt) defines a non-critical X.509 v3 certificate extension that conveys the HTTPS URI of a Call Placement Service (CPS) associated with the telephone numbers and SPCs authorized in an STI certificate. I am a co-author. The draft is the discovery substrate that VESPER-OOB consumes: by embedding the CPS URI in the certificate itself, the URI becomes publicly verifiable through STI Certificate Transparency log monitoring once the certificate is logged. Currently at -02.

What the extension does

The CPS URI extension carries one or more absolute HTTPS URIs identifying CPS endpoints for the telephone numbers or SPCs covered by the certificate’s TNAuthList. Originating providers or enterprises that hold STI certificates with a TNAuthList can include a CPS URI extension declaring where PASSporTs signed by that certificate get published; verifiers monitoring the STI-CT logs can extract the binding from logged certificates and use it to identify the appropriate CPS for any incoming call needing out-of-band PASSporT retrieval.

The extension is non-critical — meaning implementations that don’t understand it can still validate the certificate — and designed to be fully backward compatible with existing STIR certificates and OOB APIs. It only provides a new way to discover CPS endpoints; it doesn’t change the OOB flows themselves or the cryptographic verification semantics.

ASN.1 structure

The extension is identified by an OID under the PKIX id-pe arc (specific assignment pending IANA action) and encodes the URI list as a SEQUENCE of IA5String values, each containing an absolute HTTPS URI. The full ASN.1 module follows standard PKIX patterns and integrates cleanly with existing STIR certificate tooling.

A certificate containing the extension might list a single primary CPS endpoint, or multiple endpoints for resilience and geographic locality. Verifiers can fail over across the listed endpoints based on local policy.

Validation considerations

Relying parties validating an STI certificate with the CPS URI extension perform standard certificate-chain validation plus checks specific to this extension:

• Each URI must be absolute and use the https scheme; certificates with non-conformant URIs are invalid.
• The certificate’s CT inclusion (via the SCT in VESPER certificates) provides the public-record grounding for the CPS URI binding — anyone monitoring the relevant logs sees the binding too.
• If an external CPS-discovery directory disagrees with the on-certificate URI, the resolution is a matter of local policy. Operators changing CPS endpoints should issue refreshed certificates with the updated URI before decommissioning the old endpoint, accounting for CT log propagation delay.

Status

Currently an individual draft (draft-sliwa-stir-cert-cps-ext, not yet draft-ietf-...). The work is referenced from RFC 9888 (formerly draft-ietf-stir-servprovider-oob) §4 as a proposed mechanism for embedding CPS information directly in STIR certificates, and is the discovery foundation that VESPER-OOB builds its transparent discovery model on. The proposed STIR working group recharter discussions have included this work as part of the extended scope the working group might formalize.