draft-ietf-stir-certificates-ocsp — OCSP Usage for STIR Certificates

draft-ietf-stir-certificates-ocsp (Peterson, Turner) defines how OCSP — the Online Certificate Status Protocol (RFC 6960) — is used for Secure Telephone Identity certificates, with extensions designed to handle the dynamism of telephone-number assignments. Currently at -14 (June 2026), approved by the IESG and in the RFC Editor queue. Standards Track.

The draft addresses a real operational problem in the STIR ecosystem: when a STIR certificate authorizes signing for specific telephone numbers (typical for delegate certificates under RFC 9060), the verifier needs a way to confirm not just that the certificate hasn’t been revoked, but that the certificate’s authority over the listed numbers is still current. Telephone numbers move — through portability, churn, reassignment — and a delegate certificate’s TNAuthList can become out-of-sync with actual authority faster than traditional revocation-cycle assumptions account for.

What this draft specifies

OCSP for telephone-number freshness. The draft RECOMMENDS OCSP usage in high-volume environments (HVE) for validating the freshness of telephone-number-based certificates, citing RFC 6960 as the underlying OCSP specification and incorporating selected optimizations from RFC 5019 (Lightweight OCSP Profile for High-Volume Environments). The use case is specifically high-volume — verifying many calls quickly using delegate certificates that may need real-time validity status.

Telephone-number-specific extensions. The draft defines new OCSP request and response extensions to compensate for the dynamism of TN assignments — letting a verifier ask the authority not just “is this certificate revoked” but implicitly “is this certificate’s claim over telephone number X still authoritative.” These extensions piggyback on OCSP’s existing extension mechanism, reusing the round-trip the verifier is already performing for status checking rather than adding new infrastructure.

Where OCSP fits in the broader certificate-freshness picture. The draft acknowledges that CRLs are widely used in STIR environments today, primarily for audit purposes rather than real-time status. CAs in the STIR architecture have implemented CRLs largely because they’re standard PKIX practice. For service-provider STI certificates based on Service Provider Codes, that pattern is unlikely to change. The OCSP draft specifically targets the delegate-certificate case — where TN Authorization Lists make CRLs less aligned with relying-party needs and where real-time status checking is the better fit.

OCSP stapling for STIR. The draft includes appendix discussion of OCSP stapling design considerations — how OCSP responses might be embedded in PASSporTs to avoid round-trip costs at the verification service. The stapling alternative explored Peterson’s earlier draft-peterson-stir-ocsp-staple work, with this draft assessing the fit and trade-offs.

Industry adoption context

OCSP has been broadly deprecated as a preferred revocation mechanism across modern PKI deployments. WebPKI implementations have progressively moved away from OCSP for several reasons — performance (round-trip cost on every verification), privacy (the OCSP responder learns which certificates a verifier is checking, building a fingerprint of the verifier’s activity), and reliability (responder availability becomes a hard dependency for trust). Let’s Encrypt deprecated OCSP support in 2025; major browser and OS vendors have been progressively reducing OCSP reliance for years.

The same trajectory applies to STIR. Industry adoption of OCSP-based STIR-certificate freshness is unlikely. The companion short-lived certificates draft addresses the same freshness problem through a mechanism much more aligned with the direction modern PKI has converged on — issuing certificates valid for hours or days rather than months or years, eliminating the need for relying parties to perform freshness checks at all. Short-lived certificates are the more probable dominant approach for STIR-certificate freshness in deployment.

Status

Currently draft-ietf-stir-certificates-ocsp-12, in IESG evaluation. The draft documents an OCSP-based approach specified at the IETF, but practical deployment in the STIR ecosystem is expected to favor the short-lived-certificate mechanism instead.