draft-ietf-stir-certificate-transparency — STI Certificate Transparency

draft-ietf-stir-certificate-transparency (Wendt, Sliwa, Fenichel, Gaikwad) applies the Certificate Transparency (CT) framework (RFC 6962 / draft-ietf-trans-rfc6962-bis) to Secure Telephone Identity certificates. I am the primary author. Currently submitted to the IESG (Publication Requested), at revision -02. The draft is the foundation for the transparency-log-grounded trust elements that VESPER and its discovery infrastructure rely on; conceptual framing for that role lives on the VESPER topic page, which has a Certificate Transparency section discussing how CT integrates into the broader trust model.

What this draft specifies

The role of CT in the STI ecosystem. The draft establishes that STI Certification Authorities (CAs) MUST add issued certificates to STI Certificate Transparency (STI-CT) logs. This applies to both service-provider STI certificates (with TNAuthList containing SPC entries) and delegate certificates (RFC 9060, with TNAuthList containing telephone numbers or ranges). The result is a public, append-only, cryptographically verifiable record of certificate issuance — analogous to what WebPKI CT provides for TLS certificates, but contextualized for the telephone-number authority space.

Detecting unauthorized duplicate issuance. The primary trust property STI-CT provides is the verifiable detection of unauthorized duplicate issuance — situations where two certificates are issued asserting the same telephone-number or SPC authority. Because all issued certificates are logged, any party monitoring the relevant logs can detect when multiple certificates assert overlapping authority and raise the alarm. This closes a gap in the STIR trust model where, before CT, an attacker compromising or socially engineering a CA could obtain a certificate for telephone numbers they don’t legitimately control without that issuance being publicly visible.

Adapting RFC 6962 / 6962-bis primitives. The framework borrows the foundational mechanisms of WebPKI CT — log structure, Merkle tree construction, Signed Certificate Timestamps (SCTs), the API model — and contextualizes them for the STI-specific ecosystem. STI-CT logs operate on the same submission and audit patterns as WebPKI CT logs; the SCT format and verification semantics align. The differences are in policy and scope: who operates STI-CT logs, what STI-specific entries look like, and how the log content interacts with the STIR-specific data structures (TNAuthList, SPC, delegate-certificate hierarchies).

SCT embedding and verification. Following the WebPKI CT pattern, SCTs are embedded in issued certificates as a non-critical X.509 extension. Verifiers can confirm SCT presence during certificate validation without performing live log queries; auditing parties query logs to detect anomalies. Certificates without embedded SCTs are not CT-validated — deployments may choose to require CT-validated certificates as a policy matter.

Connection to the broader trust model. The draft frames STI-CT as a foundational mechanism that other STIR-related specifications can rely on. VESPER’s certificate profile (draft-wendt-stir-vesper) requires SCT embedding; the CPS URI extension defined by draft-sliwa-stir-cert-cps-ext is verifiable through STI-CT log monitoring; and the broader trust framework’s move toward auditable trust establishment depends on STI-CT existing as deployable infrastructure.

Status

Currently a working group document with WG consensus, heading toward IETF last call. Once published, STI Certificate Transparency becomes the foundational layer that VESPER and several other STIR-extension drafts assume in their trust model.