If you have received a call in the last few years with a green checkmark, "Verified", or (in the US) an FCC-mandated caller ID attestation, you have RFC 8226 to thank. It is the certificate half of STIR (Secure Telephone Identity Revisited), the technology stack better known by its marketing name STIR/SHAKEN, and it is the reason robocalls with spoofed numbers finally started getting throttled at the network edge.

The problem. SS7 and SIP were designed with the same trust model as early email: whatever the sender puts in the "From" field is what the recipient sees. Spoofing a caller ID number is trivial — literally a header value in a SIP INVITE. By the mid-2010s, roughly half of US mobile calls were fraudulent or unwanted. The industry needed a way for a terminating carrier to cryptographically verify that an originating carrier had authorized the use of a particular calling number.

What RFC 8226 actually defines. It is a profile of X.509 v3 certificates for asserting authority over telephone numbers. The key innovation is a new certificate extension called TNAuthList (Telephony Number Authorization List), an ASN.1 structure that binds a public key to either:

• A Service Provider Code (an SPC / OCN — the identifier a carrier already has in NANPA's registries), meaning "this cert holder can sign for any number this carrier legitimately serves"; or
• A list of specific telephone numbers or number ranges (encoded as E.164 strings), for enterprises or resellers who own particular DIDs.

The signing companion RFC (RFC 8224, PASSporT) defines a JWT-like token that a SIP proxy inserts into the Identity header of an INVITE. The receiving side fetches the cert via a URL in the header, walks up to a trusted anchor (in the US, the STI-PA / Policy Administrator run by iconectiv), and checks that the cert's TNAuthList actually covers the calling number.

Design decisions worth noting. The authors deliberately did not reuse the Web PKI. Telephone numbers are a distinct namespace with a different authority hierarchy — NANPA and national regulators, not ICANN and CAs like DigiCert. Reusing X.509 machinery (parsers, revocation, path building) while inventing a new namespace extension was the pragmatic middle path. They also allowed the TNAuthList to be delivered by reference (a URI pointing to the list) rather than inline, because a large carrier might be authoritative for millions of numbers and stuffing them all into the cert would be absurd.

Why it matters today. In the US, the FCC required all voice providers to implement STIR/SHAKEN in their IP networks by June 2021. Every "A" attestation you see on a modern call has been through a chain that terminates at a RFC 8226-conformant certificate. It has not eliminated robocalls — plenty still originate from providers that give blanket attestations, or from TDM segments where the token gets stripped — but it is the substrate that enables carriers to traceback and block bad originators within hours instead of weeks.

Quirk. The TNAuthList OID lives under the IETF SMI arc (1.3.6.1.5.5.7.1.26), sitting quietly next to OCSP and CRL Distribution Points in the certificate extensions registry. Most X.509 tooling still does not decode it prettily; you will see raw ASN.1 unless you patch OpenSSL.