RFC 9060 — STIR Certificate Delegation — library

RFC 9060 (Peterson — September 2021) is the IETF specification that defines how STIR certificate authority is delegated from a parent certificate to a subordinate one. The motivation is a specific deployment pattern: a calling number is assigned by one service provider, but the call originates through a different provider — an enterprise routing outbound calls through multiple carriers via least-cost routing, a roaming user, an aggregator acting on behalf of the assigned carrier. Without delegation, the outbound carrier either signs with its own credential (which doesn’t cover the originating number) or the call is signed at attestation level B or C with diminished trust. With delegation, the carrier holding the number can issue a credential the enterprise uses to sign with full attestation regardless of the routing path.

What it specifies

The mechanism layers cleanly on top of RFC 8226:

Delegation through standard X.509 PKI. A parent certificate (with cA=true in its Basic Constraints extension) signs a child certificate. The child carries its own TNAuthList; the parent identifies itself in the child via a standard Authority Key Identifier extension.
“Encompassing” scope semantics, RPKI-style. Each delegate certificate MUST have a TNAuthList scope that is equal to or a subset of its parent’s TNAuthList scope. A parent with authority over a number range can delegate the full range or a sub-range to a child; a parent with an SPC can delegate individual numbers or ranges from within that SPC’s numbering inventory. (Standard X.509 name constraints don’t apply because STIR uses TNAuthList rather than Subject Name for scope.)
Multi-level delegation. A delegate certificate can itself carry cA=true to sign further sub-delegates. The chain of TNAuthList encompassment must hold throughout — each child scope must fit within its immediate parent’s.
PASSporT signing semantics. Only end-entity certificates (cA=false) can actually sign PASSporTs. A delegate cert marked cA=true is an issuing authority, not a signing credential — it must issue an end-entity sub-cert if it wants to sign calls.

The document is short — 12 pages — because most of the mechanism is just standard PKI machinery with the additional encompassment constraint on TNAuthList.

Why this matters operationally

Without delegation, the enterprise-routing-through-multiple-carriers case has no clean solution. The outbound carrier either signs with its own credential and asserts attestation level B (which the regulatory framework is increasingly de-emphasizing) or the call goes unsigned. Neither outcome is good for the trust framework — the legitimate-spoofing case looks indistinguishable from malicious spoofing if the protocol can’t authenticate it.

Delegation makes the case workable. The carrier holding the number issues a delegate certificate to the enterprise. The enterprise’s outbound calls — through whichever provider handles them — are signed by the enterprise itself with a credential that traces back to the carrier’s TN authority. The verification side sees a chain that ends at the carrier holding the number, regardless of which provider physically routed the call.

Where this document is referenced

Delegate certificates is the topic page covering the broader delegation deployment pattern, including how it composes with attestation levels, RTU evidence, and the carrier-to-enterprise issuance flow.
RFC 8226 is the certificate profile this document delegates from.
RFC 9447 and RFC 9448 define the ACME mechanism for issuing delegate certificates through Authority Tokens — the deployed flow today is RFC 8226 + RFC 9060 delegation + RFC 9447/9448 ACME issuance.
VESPER, the domain-bound STIR extension I’m authoring, builds further extensions on top of the delegation model defined here — VESPER certificates are delegate certificates with additional bindings (domain identity, embedded SCT) that strengthen the trust evidence.