Certificate hierarchy & trust anchors — the SHAKEN PKI

The SHAKEN certificate hierarchy is the public-key infrastructure that makes a STIR signature mean something. A signature is only as trustworthy as the chain of authority behind the key that produced it, and in STIR/SHAKEN that chain has a deliberately small number of moving parts: a single root of trust, a managed set of certificate authorities anchored to it, and the Service Provider certificates those authorities issue. This page walks the hierarchy end to end — what each layer is, what binds the layers together cryptographically, and how a verifier reconstructs the chain at call time. It is a consolidating hub; the deeper threads (delegation, the authority-token issuance flow, the draft work extending the PKI) each have their own pages, linked where they belong.

The trust model

At the root of the SHAKEN PKI sits the STI Policy Administrator (STI-PA). The STI-PA is the operational authority that decides which certificate authorities the ecosystem will trust. It does not itself sign call PASSporTs, and in the deployed model it does not issue Service Provider certificates directly. Its job is narrower and more structural: it maintains the list of approved STI Certification Authorities (STI-CAs), and it publishes the trust anchors — the CA certificates — that every verification service is expected to honor. A verifier that trusts a SHAKEN signature is, transitively, trusting the STI-PA’s judgment about which CAs belong on that list.

Below the STI-PA are the STI-CAs. These are the entities that actually issue end-entity certificates to Service Providers. Multiple STI-CAs operate concurrently; a Service Provider chooses which one to source certificates from based on commercial and operational fit. What makes an STI-CA an STI-CA, rather than an arbitrary certificate authority, is that the STI-PA has authorized it and placed its certificate on the trusted list. An STI-CA that is removed from the list stops being a trust anchor the moment verifiers refresh their copy of the list, which is the lever the governance model relies on for enforcement.

At the bottom of the hierarchy are Service Providers, the subscribers. A Service Provider obtains an end-entity certificate from an STI-CA and uses the corresponding private key to sign the calls it originates. The certificate is what ties that signing key back to a recognized position in the trust framework: it was issued by a CA the STI-PA approved, and it carries an explicit statement of what telephone-numbering authority the Service Provider holds.

The practical consequence of this shape is that trust is distributed but anchored. Verification services across the ecosystem do not need to know about every Service Provider in advance. They need only the STI-PA’s trusted-CA list. Anything a verifier can chain back to a CA on that list is trusted; anything it cannot is not. The governance arrangement that sits behind the STI-PA — the separation of policy-making from enforcement from issuance — is treated under trust governance and in the SHAKEN operational profile; the focus here is the certificate machinery itself.

The certificate

A SHAKEN Service Provider certificate is an ordinary X.509 certificate in almost every respect. It has a subject, an issuer, a validity window, a public key, and a signature from the issuing STI-CA. What distinguishes it is a single non-standard extension: the TNAuthList, defined in RFC 8226. The TNAuthList is the field that turns a generic certificate into a statement about telephone numbering authority. It binds the certificate — and therefore the key inside it — to one of two kinds of authority: a Service Provider Code (the SPC, carried operationally as an OCN in the North American context), or an explicit set of telephone numbers or number ranges.

The TNAuthList is the heart of the model. When a verifier later checks a signature, the question it is really answering is not merely “is this signature cryptographically valid” but “was the key that produced it authorized to assert this calling number.” The TNAuthList in the signing certificate is where that authorization is recorded. A certificate scoped to an SPC asserts authority over whatever numbers that code administers; a certificate scoped to explicit numbers asserts authority only over those.

The obvious question is how an STI-CA knows that the requesting Service Provider is actually entitled to the SPC or numbers it claims, rather than asserting authority it does not hold. That is the job of the authority token. Before an STI-CA issues a certificate carrying a given TNAuthList, the Service Provider must present proof of its right to that authority. In SHAKEN this proof is an SPC token — an authority token, issued by an STI-PA-designated token authority, that the CA validates as part of issuance. The token is consumed through an ACME-based mechanism (RFC 9447): the certificate request and the token validation are automated so that issuance can run at the scale the ecosystem requires. The token mechanism and its TNAuthList ACME profile are specified at the IETF, and the RFC 9448 page covers the authority-token flow in detail. The point to carry forward here is that the TNAuthList in a deployed certificate is not self-asserted — it is backed by a token the CA verified before signing.

Because the SPC token proves a right-to-use rather than simply identifying the requester, the certificate that results is a durable, verifiable claim of authority. The Service Provider can sign with it for the life of the certificate without re-proving its authority on every call. The proof happens once, at issuance; the certificate carries it forward.

Delegation

The base model assumes the Service Provider that holds the TNAuthList authority is also the party doing the signing. That assumption does not always hold. An enterprise may hold numbers from one carrier but originate its calls through another; a communications-platform provider may originate on behalf of many customers whose numbers trace to many underlying carriers. This is the “customer-of-customer” problem: the party with the operational signing position is not the party with the recognized authority over the numbers.

RFC 9060 certificate delegation is the mechanism that resolves this without breaking the trust chain. It lets a Service Provider that holds authority issue a constrained certificate to a downstream party — delegating signing authority for a specific subset of its numbers. The delegate certificate’s TNAuthList is bounded to that subset, and a verifier walking the chain confirms that the delegate’s scope is properly contained within the issuer’s scope, all the way back to a trusted anchor. The carrier remains the recognized authority; the downstream party does the signing. The full operational treatment — how the constraint is encoded, how the SHAKEN profile operationalizes it, and where the model is heading — is on the delegate certificates page. For the purposes of this hub, the salient fact is that delegation is an extension of the same hierarchy, not a separate PKI: a delegate certificate chains back through its issuing Service Provider certificate to the same STI-CA and the same STI-PA anchor.

How certificates feed signing and verification

The certificate hierarchy exists to serve two operations: signing, performed by the originating side, and verification, performed by the terminating side. The certificate is the bridge between them.

On the originating side, the authentication service holds the Service Provider’s STI private key. When it signs a call, it constructs a PASSporT — the signed token carrying the calling and called numbers and, in SHAKEN, the attestation claim — and signs it with that private key. Into the SIP Identity header it places the signature along with a pointer, the x5u parameter, that is a URL where the corresponding certificate can be fetched. The private key never travels; only the signature and the pointer to the public certificate do.

On the terminating side, the verification service receives the Identity header, reads the x5u URL, and fetches the certificate. From there it does the work the whole hierarchy was built to make possible. It verifies the PASSporT signature against the public key in that certificate. It builds the certificate chain from that end-entity certificate back through the issuing STI-CA. It checks that the chain terminates at a trust anchor on the STI-PA’s trusted-CA list. And it checks that the TNAuthList in the certificate actually covers the calling number being asserted — a signature from a valid certificate is meaningless if the certificate’s authority does not extend to the number in the call. Only when all of these hold does the signature count as verified.

This is the moment the entire structure pays off. The verifier did not need a prior relationship with the originating Service Provider. It needed the certificate (fetched at call time from the x5u URL) and the STI-PA’s list of trusted anchors. Everything else — issuer authorization, numbering authority, signature validity — is recoverable from the certificate and the chain it sits in.

The surrounding draft work

The PKI described here is the deployed baseline, and several strands of draft and emerging work extend it rather than replace it. Short-lived certificates shrink the window in which a compromised or wrongly issued certificate can do damage, trading longer validity for more frequent, automated reissuance. OCSP brings online revocation checking so that a verifier can learn a certificate has been revoked before its natural expiry. Certificate transparency adds public, append-only logging of issuance events, making misissuance detectable rather than invisible — a property the WebPKI has long relied on. And the CPS URI certificate extension lets a certificate point at the certification practice statement governing its issuance. Each of these layers onto the same X.509-plus-TNAuthList substrate and the same STI-PA-anchored chain; none of them changes the fundamental shape of the hierarchy.

Where this sits

This page is the hub for the SHAKEN PKI as a whole — the trust anchors, the certificate authorities, the TNAuthList-bearing certificates, and the chain a verifier walks back to the root. The delegate certificates page is the depth treatment of one specific extension of this hierarchy, the one that lets authority and signing position separate cleanly. The cert-related draft work — short-lived certificates, OCSP, certificate transparency, the CPS URI extension — are the directions in which this same PKI is being hardened and made more transparent. Read this page for the shape of the whole; follow the links for the parts that are moving.