appliedbits
LIBRARY  ·  IETF LIBRARY ENTRY
Last updated 2026-05-06 drafted

RFC 8226 — Secure Telephone Identity Credentials (Certificates)

RFC 8226 (Peterson, Turner — February 2018) is the IETF specification that defines the X.509 certificate profile for STIR. Together with RFC 8224 (the SIP authentication mechanism) and RFC 8225 (the PASSporT format), it forms the STIR base trio — 8226 is the credentials half of the story, the part that says what a certificate authorizing assertions about telephone numbers actually looks like on the wire and what extensions it carries. Every STIR signing certificate in deployment today derives from this profile.

What it specifies

Three pieces of mechanism, each carried forward into the deployed ecosystem:

  • The TNAuthList certificate extension. A new X.509 extension (id-pe-TNAuthList, OID 1.3.6.1.5.5.7.1.26) that carries a TNAuthorizationList structure — a SEQUENCE of TNEntry choices, each of which can express a Service Provider Code (SPC), a telephone number range, or an individual telephone number. This is the central data structure binding the certificate to specific telephone authority. The same TNAuthList content appears on the wire in RFC 9448 ACME identifier objects and Authority Tokens; it’s the canonical representation of TN authority in the STIR ecosystem.
  • JWT Claim Constraints primitives. Section 8 defines two ASN.1 structures — JWTClaimConstraints and JWTClaimPermittedValues — that constrain what a delegated certificate is permitted to assert in its PASSporT claims. A delegate certificate can be issued with constraints saying “this holder must include iat” or “this holder may only assert orig.tn values from a specific permitted list.” These primitives are the foundation that RFC 9118 extends and that the delegated-authority deployment model rests on.
  • The TN List by reference mechanism. Section 10 defines a new AIA accessMethod (id-ad-stirTNList) that lets the certificate point at an HTTPS URI returning the full DER-encoded TNAuthList rather than embedding it inline. This is operationally important for service providers with very large TN inventories — the certificate stays compact while the authoritative list is fetched on demand. The dereferenced payload uses the application/tnauthlist media type, also registered by this document.

The certificate profile itself is otherwise standard PKIX — RSA or ECDSA keys, the usual extensions (Basic Constraints, Key Usage, Extended Key Usage, AIA, CRL Distribution Points, SubjectAltName), with the TNAuthList extension as the STIR-specific addition.

Why the design choices matter

The TNEntry choice between SPC, range, and individual TN is what makes the certificate profile flexible enough to fit how telephone authority actually works in the network. A carrier holding an Operating Company Number (OCN) gets a certificate with an SPC entry; an enterprise with a specific number range gets a range entry; a delegate scenario where a single number is assigned out gets a one-TN entry. The same data structure covers all three cases without forcing a uniform representation.

The separation of TNAuthList from the certificate Subject DN is structural. The Subject identifies the certificate holder by some name (organizational identity, ACME-assigned name); the TNAuthList expresses what telephone authority that holder has. The two are bound by the same signature but represent different facts. This is what lets a certificate be issued to “AcmeCorp” while authorizing assertions over a specific TN range — the binding between Subject identity and TN authority is the certificate authority’s job to verify before issuance.

The JWT Claim Constraints structures were forward-looking when 8226 was published. The full delegation deployment pattern that uses them — RFC 9447 / 9448 for ACME-based issuance, RFC 9118 for the Enhanced Constraints, the active JWTClaimConstraints profile for delegated RCD signing — came later. But the ASN.1 primitives were in 8226 from the start, which is what made the later work possible without reopening the certificate-profile document.

Where this document is referenced

  • RFC 8224 and RFC 8225 are the two companion documents that form the STIR base trio. 8224 specifies how PASSporTs travel in SIP; 8225 defines the PASSporT format itself; 8226 defines what the certificates that sign PASSporTs look like.
  • RFC 9448 defines an ACME profile for obtaining certificates that conform to this document’s TNAuthList extension. Every certificate issued under the current STI-PA flow is an RFC 8226 certificate obtained through an RFC 9448 ACME exchange.
  • RFC 9118 (page forthcoming) extends the JWT Claim Constraints primitives defined here with an Enhanced version that supports more expressive constraints, used in the delegation deployments.
  • STIR is the topic page for the protocol layer.
  • Delegate certificates is the deployment context that uses this document’s TNAuthList extension and JWT Claim Constraints structures most heavily.