STIR/SHAKEN Certificate Chain, PASSporT & JWT

A STIR/SHAKEN certificate is an X.509 certificate that an approved STI-CA issues to a vetted voice provider. It binds the carrier’s public key to its Service Provider Code. The carrier signs each outbound call with the matching private key. The terminating carrier fetches the certificate, checks the signature, and reads the attestation level.

Every signed call carries a signed token. That token is a PASSporT, encoded as a JWT. The signing carrier’s private key produces the signature. The token rides inside the SIP INVITE as an Identity header. This article follows that token from creation to check. It covers the token layout, the signing step, the header format, and the STI-GA → STI-PA → STI-CA chain that gives the signature its weight. For attestation levels and FCC duties in plain language, start with the STIR/SHAKEN operator’s guide. This page stays at the wire level.

SIPNEX holds its own STIR/SHAKEN Service Provider certificate (SP-KI) and signs every originating call directly. What follows is how the signing works, from the carrier that does it.

What is a STIR/SHAKEN certificate?

A STIR/SHAKEN certificate is a standard X.509 certificate with one extra field. RFC 8226 calls that field the TN Authorization List (TNAuthList). The list can hold a Service Provider Code, single phone numbers, or number ranges. A carrier certificate carries the SPC. The certificate also holds the carrier’s public key and the STI-CA’s signature. The carrier publishes it at a public URL. Every PASSporT the carrier signs points back to that URL.

A checker looks at two more things: the validity dates and the issuer. Both come from the certificate itself. If the issuer is not an approved STI-CA, the signature counts for nothing.

STIR and SHAKEN, briefly

STIR stands for Secure Telephone Identity Revisited. It is the IETF layer: RFC 8224, RFC 8225, and RFC 8226. Those three documents define the PASSporT format, the JSON Web Signature method, and how a checker validates the result.

SHAKEN stands for Signature-based Handling of Asserted information using toKENs. ATIS and the SIP Forum wrote it. It says how to run STIR on live SIP networks: who issues certificates, how carriers trust each other, and what the attestation levels mean. Together they form the STIR/SHAKEN framework.

The framework exists because caller ID spoofing made illegal robocalls cheap and hard to trace. A signature puts a name on every call a carrier sends. The FCC required voice providers to implement STIR/SHAKEN on the IP parts of their networks by June 30, 2021. The rules and attestation guidance live in the STIR/SHAKEN operator’s guide. The rest of this page stays at the protocol layer.

The certificate chain

STIR/SHAKEN runs on a public key infrastructure (PKI) with three levels above the carrier:

STI-GA (Governance Authority) — the policy body. It sets the rules for the whole framework. In the US this is the Secure Telephone Identity Governance Authority. It operates under FCC direction, and ATIS works with its board to set those rules.

STI-PA (Policy Administrator) — runs the trust framework day to day. It keeps the list of approved Certificate Authorities. It enforces the STI-GA’s policies. And it issues Service Provider Code (SPC) tokens. A carrier presents its SPC token to an STI-CA to prove it may request a certificate. In the US, iconectiv is the STI-PA.

STI-CA (Certificate Authority) — issues certificates to carriers. An STI-CA issues one only to a carrier with a valid SPC token. That token is proof the STI-PA has cleared the carrier as a real voice provider, with an FCC filing and a listing in the Robocall Mitigation Database. The STI-CA then issues an SP-KI (Service Provider Key Identifier) certificate. It holds the carrier’s public key and is signed by the STI-CA’s root certificate.

SP-KI (Service Provider Key Identifier) — the certificate a carrier like SIPNEX holds. It lets the carrier sign outbound calls. It holds the public key. The carrier keeps the matching private key locked down and signs with it. When a far-end carrier receives a signed call, it pulls the public key from this certificate and checks the signature.

This chain — STI-GA → STI-PA → STI-CA → SP-KI — is a chain of trust. A far-end carrier trusts a signature because it can trace the signing certificate back to a known Certificate Authority. The Policy Administrator approved that authority under the Governance Authority’s rules.

Who can get a STIR/SHAKEN certificate?

Not every company that sends calls can get one. The STI-GA’s SPC Token Access Policy (version 1.2, adopted May 18, 2021) sets three tests. The STI-PA clears an entity for certificates only if it:

1. Has a current FCC Form 499A on file, or can show it paid the annual Resp Org fee to the FCC.
2. Has an Operating Company Number (OCN) or a Resp Org ID.
3. Has certified with the FCC that it implemented STIR/SHAKEN or meets the Robocall Mitigation Program rules, and is listed in the FCC database. A non-carrier Resp Org with direct toll-free number access from the Toll-Free Number Administrator also qualifies.

A call center or a PBX vendor with no 499A filing and no OCN fails the test. That is why such companies cannot sign their own calls. They ride on the certificate of the carrier that does.

How carriers implement STIR/SHAKEN

Here is the path a carrier follows to implement STIR/SHAKEN on its own certificate:

1. Meet the access policy. File the Form 499A, hold an OCN, and certify in the Robocall Mitigation Database.
2. Register with the STI-PA. Once registered, the carrier receives an SPC token.
3. Request a certificate. The carrier creates a key pair, keeps the private key, and presents the SPC token to an approved STI-CA. The STI-PA publishes the list of approved CAs.
4. Publish the certificate. The carrier hosts its public certificate at a URL. That URL goes into the x5u field of every token it signs.
5. Deploy the two services. RFC 8224 names them. The authentication service adds Identity headers to outbound calls. The verification service validates the headers on inbound calls.

What happens when a call is signed

Here is the exact sequence when SIPNEX signs an outbound call:

Step 1: Call origination. Your PBX sends a SIP INVITE to the SIPNEX SIP proxy. The Request-URI holds the called number. The From header holds your outbound caller ID.

Step 2: Trunk check and number check. SIPNEX first authenticates your trunk, by IP or by digest. Our signing service then reads the calling number in the From header. It compares that number with the DID list on your account. The check passes if we provisioned the number to you or ported it in for you.

Step 3: Attestation level. The result sets the level:

• Number verified for your account → A-level (Full Attestation)
• Known customer, but the number is not on the list → B-level (Partial Attestation)
• Call from a gateway or upstream source with no direct customer check → C-level (Gateway Attestation)

Step 4: PASSporT creation. Our signing service builds a PASSporT (Personal Assertion Token). It is a JSON object with these claims:

• orig — the calling number (your CID) in E.164 format
• dest — the called number in E.164 format
• iat — the issued-at time (Unix epoch seconds)
• attest — the attestation level (“A”, “B”, or “C”)
• origid — a unique ID for this call

Step 5: JWT signing. The SP-KI private key signs the PASSporT. The output is a JSON Web Signature (JWS). RFC 8225 requires support for the ES256 algorithm. The resulting JWT has three parts. The header names the algorithm, sets typ to passport, and carries the x5u certificate URL. The payload is the PASSporT. The third part is the signature. The far-end carrier follows the x5u URL to fetch the SIPNEX public certificate.

Step 6: Identity header insertion. The signed JWT goes into a SIP Identity header on the outbound INVITE. RFC 8224 defines this header. It also carries an info parameter with the certificate URL. The INVITE then moves to the next hop: the far-end carrier, or a transit carrier in between.

Step 7: Call proceeds. The call routes as normal. The Identity header rides with the INVITE through each hop. The signature is tamper-evident: any change to the PASSporT breaks it.

What happens when a call is verified

At the terminating carrier — the far-end carrier that serves the person being called:

Step 1: Header extraction. The carrier receives the INVITE and pulls the JWT out of the Identity header.

Step 2: Certificate retrieval. It reads the x5u URL from the JWT header and fetches the signing carrier’s SP-KI certificate. Most carriers cache the certificate for speed.

Step 3: Certificate validation. It confirms three things. A trusted STI-CA issued the certificate. The certificate has not expired. And it has not been revoked. This step traces the certificate back up the trust chain.

Step 4: Signature check. Using the public key from the certificate, it checks the JWT signature. A valid signature proves two things: nobody changed the PASSporT, and the named carrier really signed it.

Step 5: PASSporT validation. It then reads the claims. Is the iat time fresh? RFC 8224 recommends a sixty-second window. Does orig match the From header? Does dest match the called number?

Step 6: Attestation applied. If every check passes, the carrier feeds the attestation level into its call treatment. A-level calls may show a “Verified” mark on the handset. B and C calls get neutral or cautious treatment. If a check fails — a bad signature, an expired certificate, a changed PASSporT — the call is treated as unsigned.

Why this design makes reseller A-level attestation unreliable

The design explains the reseller limit covered in A-level vs B-level attestation.

The signing carrier’s private key makes the signature. With it, the carrier makes a claim it must stand behind: “I, SIPNEX, named by this certificate, attest at A-level that this caller may use this number.”

That claim only means something if the signer knows, on its own, that the caller owns the number. At SIPNEX, that knowledge sits in our DID provisioning records. We assigned the number, or we verified it during porting. The evidence runs in a straight line: carrier assigns number → carrier confirms the customer’s right to it → carrier signs at A-level.

Add a reseller and the line breaks. The reseller assigns the number. The upstream carrier signs the call. But the upstream carrier never assigned that number. It only has the reseller’s word that the number belongs to the end customer. It cannot check that claim itself. Most upstream carriers will not sign at A-level on a reseller’s word alone. If the claim is false, the blame lands on the signing carrier’s certificate.

This is not a policy choice. It follows from how PKI trust works. A signature is only as good as the signer’s ability to check the claim. A direct carrier checks directly. A carrier signing for a reseller’s customer cannot.

Frequently asked questions

What is a PASSporT in STIR/SHAKEN?

A PASSporT (Personal Assertion Token) is the JSON object, defined in RFC 8225, that carries the caller identity claim in STIR/SHAKEN. It holds the calling number, the called number, the attestation level (A, B, or C), a timestamp, and a unique call ID. The signing carrier signs it with its private key and places it in a SIP Identity header on the outbound INVITE. The far-end carrier checks the signature against the signing carrier’s public certificate.

What is an SP-KI certificate?

An SP-KI (Service Provider Key Identifier) certificate is the STIR/SHAKEN certificate issued to a voice carrier so it can sign outbound calls. An approved STI-CA issues it after the carrier proves its status: an FCC filing plus a Robocall Mitigation Database listing. The certificate holds the carrier’s public key. The carrier keeps the private key and signs PASSporT tokens with it.

SIPNEX holds its own SP-KI certificate. We do not borrow an upstream carrier’s certificate. That is why we can give our customers’ calls direct A-level attestation.

What do STIR and SHAKEN stand for?

STIR is Secure Telephone Identity Revisited, the IETF standard in RFC 8224, 8225, and 8226. SHAKEN is Signature-based Handling of Asserted information using toKENs, the ATIS and SIP Forum profile that runs STIR on carrier SIP networks. STIR defines the token and the signature. SHAKEN defines the certificate chain, the attestation levels, and the carrier-to-carrier trust model. Together they are the STIR/SHAKEN framework the FCC mandates for US voice providers.

Can STIR/SHAKEN be spoofed or bypassed?

The signature itself cannot be forged without the signing carrier’s private key, which stays locked down. But there are gaps. A call that crosses a non-SIP segment (a TDM or SS7 hop) can lose its Identity header and arrive unsigned. A carrier with weak security could, in theory, have its private key stolen.

The attestation level is also only as good as the signer’s checks. A carrier that signs at A-level without checking number rights is compliant on paper but weakens the whole model. FCC tools, such as RMD rules, traceback duties, and certification audits, exist to close those gaps over time.

Does STIR/SHAKEN add latency to call setup?

Very little. The signing step takes tens of milliseconds. The first certificate fetch by the far-end carrier adds a fraction of a second. Carriers cache certificates, so later calls from the same signer skip that lookup. The total effect on post-dial delay is hard to notice. It sits well inside the normal PDD swing caused by routing and network conditions. SIPNEX signs every call with its own certificate.

---

SIPNEX holds its own SP-KI certificate and signs every originating call directly — no middle carriers, no borrowed attestation, no gaps in the trust chain. Get A-level attestation from the signing carrier or see our rates.