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

RFC 9118 — Enhanced JWT Claim Constraints for STIR Certificates

RFC 9118 (Housley — August 2021) is the IETF specification that updates RFC 8226 with an Enhanced JWT Claim Constraints certificate extension. The original 8226 extension lets a certificate require that certain claims be present (mustInclude) or limit a claim to a permitted set of values (permittedValues). What it didn’t have was the inverse — a way to exclude specific claims from the PASSporT a delegate is allowed to sign. RFC 9118 adds that, plus carries forward all the original capabilities. The acknowledgements section explicitly credits me for identifying the operational need that motivated this work — the PASSporT Extension for Rich Call Data (RFC 9795) was the use case where exclusion semantics turned out to be necessary.

What it specifies

The Enhanced extension is a superset of 8226’s original:

  • mustInclude — claims that MUST be present in any PASSporT signed by this certificate. Carried forward unchanged from 8226.
  • permittedValues — claims that, if present, MUST take values from a permitted list. Carried forward unchanged.
  • mustExclude — new in 9118. A list of claims that MUST NOT be present in any PASSporT signed by this certificate. If a PASSporT signed by this cert contains any excluded claim, the verifier rejects the entire PASSporT.

The new ASN.1 structure (EnhancedJWTClaimConstraints) replaces the original JWTClaimConstraints and is registered under a new OID. Verifiers that don’t recognize the Enhanced extension’s OID treat it as a non-critical extension and ignore it — the document includes guidance for issuers and verifiers on the migration considerations.

Why exclusion was needed

The motivating case is delegation when the delegate shouldn’t be allowed to assert content the parent reserves. The RFC 9795 RCD work surfaced this: a parent certificate authorized to assert both telephone authority and rich call data might want to issue a delegate certificate that signs only ordinary calls (with the TN authority) but not RCD content. With only mustInclude and permittedValues, there was no clean way to say “you may sign PASSporTs but you may not include the rcd claim.” The Enhanced extension’s mustExclude makes that constraint expressible.

Excluding certain integrity-mechanism claims has structural implications — the document notes that excluding the RCD integrity claim, for example, would prevent the integrity protection mechanism from working properly. So the certificate issuer needs to coordinate exclusions with the delegate’s intended use case; arbitrary exclusion can break the protocol’s own semantics.

Where this document is referenced

  • RFC 8226 is the document this updates. Both extensions remain registered; new deployments generally use the Enhanced extension.
  • RFC 9795 is the PASSporT extension for Rich Call Data — the use case that motivated the Enhanced constraint mechanism. The relationship is direct: a parent certificate with RCD authority can issue a delegate cert that excludes the rcd claim, granting TN authority without RCD signing rights.
  • Delegate certificates is the topic page covering the deployment context — the Enhanced constraints are part of the toolkit for scoping delegate authority appropriately.
  • draft-ietf-acme-authority-token-jwtclaimcon is the active ACME profile I’m writing for issuing certificates carrying these constraints. Same generic Authority Token substrate as RFC 9447/9448, but the payload delivers the specific constraint scope rather than just TNAuthList.