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

RFC 9475 — Messaging Use Cases and Extensions for STIR

RFC 9475 (Peterson, Wendt — December 2023) is the IETF specification that extends STIR from voice calling to text and multimedia messaging. It defines a new PASSporT extension type msg and an optional msgi claim for message-integrity, so the same cryptographic trust framework that authenticates a calling number can authenticate the originator of a text message. I am co-author. The document recognizes that the impersonation problem STIR addresses for voice — bad actors spoofing a calling number to defeat trust signals — recurs in messaging, and that the existing PASSporT and certificate machinery is the right tool to address it.

What it specifies

Two pieces of mechanism, both small:

  • A new PASSporT extension type — msg. Registered in the PASSporT Extensions registry per RFC 8225. A msg PASSporT asserts identity for an individual message rather than for a call or message stream. The base PASSporT claims (orig, dest, iat) carry their usual meaning; what’s new is that the asserted identity covers a single message rather than a call setup.
  • A new optional JWT claim — msgi. Stands for Message Integrity. Carries a digest computed over a MIME body containing the message. Registered in the JWT Claims registry. msgi is optional in msg PASSporTs (integrity may be provided by another mechanism, e.g. RFC 8591 S/MIME), and verification services MUST ignore msgi if it appears in any other PASSporT type. Authentication services MUST NOT include msgi in non-msg PASSporTs.

The choice to make msgi optional rather than mandatory is deliberate: in some deployments the message integrity is already guaranteed by an existing security layer, and signing a redundant digest into the PASSporT would just shift work without adding assurance. The required pieces are the msg type itself and the binding between PASSporT identity and the message it asserts identity for; the integrity element is operationally useful but not strictly required for the identity-assertion semantics to work.

Use cases the document explicitly covers

The document explores STIR-for-messaging across several deployment patterns, none of which require new protocol machinery beyond msg and msgi:

  • SIP MESSAGE method (RFC 3428). Inline messaging where the message body is carried as the payload of a SIP MESSAGE request. An Identity header field on the MESSAGE request carries a msg PASSporT asserting identity over the message body.
  • MSRP-based messaging (RFC 4975). Session-negotiated messaging where the SIP exchange establishes a session for message transport. The msg PASSporT carried on the session setup asserts identity for the session; further per-message integrity can be layered through other means.
  • SMS gateway scenarios. Scenarios where SMS originating on the legacy network needs to be carried into IP-based messaging with cryptographic identity. The PASSporT can be generated by the gateway acting as authentication service, with the same certificate hierarchy used for voice.
  • Emergency-services messaging. Non-interactive emergency communications increasingly use messaging, and STIR for messaging extends the same caller-identity guarantees to these flows. The document notes this as a particularly sensitive application.

Design choices worth knowing

One is the PASSporT-type-per-medium model. Rather than overloading the existing PASSporT types with messaging semantics, the document defines msg as its own type. This keeps verification logic simple — the type discriminator tells the verifier what semantic to apply — and keeps the registry extensible if future messaging variants need different treatment.

Another is the integrity-as-optional choice. The msgi claim being optional reflects that messaging deployments vary widely in how they handle integrity. SIP MESSAGE bodies in deployments using S/MIME already have message-level integrity; SMS-gateway scenarios may not. Making msgi mandatory would have forced redundancy in some deployments and unimplementable constraints in others. Optional with strict scoping (only valid in msg PASSporTs) is the right compromise.

A third is the certificate-framework reuse. Messaging-side STIR uses the same TNAuthList-bearing certificates and the same governance hierarchy (STI-GA, STI-PA, STI-CA in the US) as voice-side STIR. There’s no separate messaging-CA model; the msg PASSporT is signed by exactly the same certificate that would sign a voice-call PASSporT. This keeps the deployment cost low — every provider that already runs SHAKEN already has the credentials needed to sign messaging PASSporTs.

Where this document is referenced

  • RFC 8225 defines the PASSporT extension model that 9475 plugs into. The msg type registration follows the same pattern as shaken, div, rcd, and other registered extensions.
  • STIR extensions is the topic page that catalogs all the PASSporT extensions and auxiliary mechanisms; the messaging extension fits into that catalog as one more entry.
  • The companion work on messaging trust frameworks at the ATIS/SIP Forum IP-NNI Joint Task Force is where the operational profile of STIR-for-messaging is being developed for US deployment; that work is referenced from trust governance.