Summary

  • The STI Certificate Transparency draft, revision 05, is an active STIR working-group Internet-Draft in IETF Last Call, scheduled to end 5 November 2026. It proposes logging call-signing certificates and embedding signed certificate timestamps, or SCTs, before issuance.
  • A verification service checks a call's PASSporT signature, certificate chain and embedded SCT with cached trust material. It makes no synchronous log query on the call path. The SCT is the log's promise to incorporate a precertificate within a maximum merge delay.
  • A separate monitor must examine newly logged certificates and compare their TNAuthList and entity names with the telephone numbers or service-provider codes it watches. Detection, investigation, revocation and changes to trust lists occur on a different clock from the call.

Picture two certificates that name different organizations but claim the same telephone number. One arrives with an apparently valid call; both have log receipts. A verifier can check the signature and the receipt locally, while a monitor may not yet have compared the second certificate with the number's legitimate holder. This is a hypothetical sequence used to test the proposed architecture. The draft does not report such an incident.

The draft takes the append-only machinery of RFC 6962 into the Secure Telephone Identity system. STI certificates carry authority information for numbers or provider codes through the TNAuthList framework of RFC 8226; RFC 9060 provides delegate certificates for number ranges. A certification authority submits a precertificate and its intermediate chain to a log. The log checks that the chain reaches a root on its published accepted-root list, then issues an SCT. The certification authority embeds that receipt in the final certificate.

The receipt outruns the investigation

An SCT is a signed commitment by a log to place the precertificate into its Merkle tree within the maximum merge delay. At issuance, the receipt does not contain a monitor's verdict on who should control the number. The draft expects logs to produce signed tree heads within that merge window. An auditor can later request an inclusion proof and compare successive tree heads for consistency. The receipt, the recorded entry and the independent audit are three events, with different witnesses.

The split has an obvious operational advantage. Under draft §7.2, a call-signing certificate carries its SCT in an X.509 extension. The authentication service may validate the receipt locally and cache the result when activating the certificate. A verification service receiving a SIP Identity header checks the PASSporT signature, the delegate-certificate chain to an accepted STI trust anchor and the SCT signature against a trusted log key. The draft expressly keeps log queries off the live call path. A call does not have to wait while a public log answers a query or a monitor finishes its sweep.

That fast path also defines the limit of the answer. A log can accept a chain anchored at an allowed root and issue a receipt before any number holder has inspected the new TNAuthList claim. A valid receipt records a promise from that log; the monitor is the actor assigned to notice an unexpected claimant. Moving the monitor's work into every live call would change the architecture's timing bargain. Treating the receipt as the monitor's finished investigation would quietly abolish the investigation.

The monitor workflow in the draft is concrete. It stores each log's address, the numbers or service-provider codes it watches, and its last seen signed tree head. It retrieves new entries, decodes their chains, and compares both TNAuthList and entity name against its configured inventory. A conflicting claimant triggers an alarm. The monitor then advances its checkpoint and checks the new tree head's signature and append-only consistency. An auditor can go further, testing inclusion against a tree head after the merge delay. A system without the correct number inventory can read every log entry and still miss the conflict it was meant to find.

A public log still needs an owner for the alarm

The draft leaves the response to confirmed mis-issuance with the STI ecosystem. It names possible routes: work with the certification authority to revoke the certificate, or with the maintainers of trust-anchor lists to remove the authority. Those are different interventions. Revoking one credential targets one claimant; removing a root changes the acceptance boundary for a wider population of certificates. A monitor's alert is evidence for investigation, not a switch it can automatically throw for every verifier.

The API choice shows how narrowly the proposal tries to reuse an existing system. Its log endpoints keep RFC 6962 semantics, with /stict/v1/ recommended as an operational path label over the compatible /ct/v1/ interface. The difficult new question is institutional: which organization inventories a number or provider code, watches each relevant log, decides a match is illegitimate, and has authority to act before another call is signed? A path prefix does not assign those jobs.

The missing deployment fact is a measured interval from certificate issuance to monitor alert and final disposition, tied to actual log and number inventories. Without that record, the draft establishes a procedure, not a measured detection window. An operator choosing this architecture should set that clock deliberately. Fast verification is worth having. It becomes dangerous only when the organization quietly assumes the slow audit finished first.

STI CT draft · RFC 6962 · RFC 8226 · RFC 9060 · RFC 8224