draft-ietf-acme-authority-token-jwtclaimcon — JWTClaimConstraints profile of ACME Authority Token

draft-ietf-acme-authority-token-jwtclaimcon (Wendt, Hancock) defines a JWTClaimConstraints profile of the ACME Authority Token framework. I co-author with David Hancock. Currently -04 (25 July 2026). Working group document in the IETF ACME working group (not STIR — though the use case is STIR-aligned). The draft name on datatracker is truncated: the full conceptual name is “JWTClaimConstraints profile of ACME Authority Token”, but the datatracker slug abbreviates to jwtclaimcon.

What this draft specifies

The draft extends RFC 9447 (ACME Challenges Using Authority Token) with a new token type — the JWTClaimConstraints Authority Token — whose payload carries a set of JWTClaimConstraints as defined in RFC 9118 (Enhanced JWT Claim Constraints for STIR Certificates). When the token is presented during ACME issuance, it instructs the issuing certification authority to include the corresponding JWTClaimConstraints extension in the issued certificate.

The model parallels the existing TNAuthList profile of ACME Authority Token (RFC 9448), where a TNAuthList Authority Token issued by a Right-to-Use authority instructs the CA to include a TNAuthList extension binding the certificate to specific telephone-number authority. This new profile does the same job for JWTClaimConstraints — letting an authority assert what PASSporT claims (and what specific values within those claims) the issued certificate is authorized to sign for, with the assertion verifiably embedded in the certificate at issuance time.

Why JWTClaimConstraints in ACME

JWTClaimConstraints (RFC 9118) is an X.509 certificate extension that constrains which PASSporT claims and which specific claim values the holder of the certificate is authorized to sign. The extension is particularly relevant for delegate certificates (RFC 9060) where a parent CA wants to issue a subordinate certificate that’s restricted to specific operational scope — not just specific telephone numbers, but specific PASSporT content.

Before this draft, there was no standardized ACME mechanism for authoritatively conveying JWTClaimConstraints to a CA at issuance time. CAs could populate JWTClaimConstraints in certificates they issued, but the binding between the authority’s intent and what ended up in the certificate extension wasn’t carried in a verifiable token. This draft closes that gap: a JWTClaimConstraints Authority Token signed by the appropriate authority makes the claim-constraint scope verifiable end-to-end through the issuance flow.

Relevance to VESPER

VESPER’s certificate profile uses JWTClaimConstraints as an optional extension on delegate certificates — bounding what PASSporT content the certificate can sign for. VESPER’s issuance flow (described in draft-wendt-stir-vesper) extends ACME with both TNAuthList Authority Tokens (per RFC 9448) and JWTClaimConstraints Authority Tokens (per this draft). A VESPER delegate certificate can therefore be issued with both its TN authority and its claim-constraint scope bound at issuance time, with both bindings carried by signed authority tokens that the CA can verify before issuing.

Relevance to Rich Call Data

The Rich Call Data topic page covers the use case where JWTClaimConstraints prevents unauthorized RCD content. When a delegate certificate is issued to an enterprise authorized to sign with specific RCD content (brand information, logo URI, jurisdiction data, etc.), a JWTClaimConstraints Authority Token can constrain the certificate to only signing PASSporTs containing the authorized RCD claim values — closing the attack surface where a delegate cert holder might otherwise insert arbitrary RCD content into a signed PASSporT.

Comparison is exact, by construction

The value the ACME server checks is compared as an opaque string. The specification requires a direct octet-by-octet comparison of the two base64url strings, and forbids the server from decoding, re-encoding, canonicalizing, normalizing or otherwise transforming either value first. A value containing non-base64url characters, = padding, or any differing octet fails.

That rigidity is deliberate, and drawn from RFC 6943. Padded base64url, an alternate alphabet, non-DER BER, stray whitespace and a reordered ASN.1 SET can all encode the same logical constraint while producing different bytes. If the server were permitted to normalize before comparing, an attacker could present a constraint that compares equal to an authorized one but decodes differently. Treating the encoding as canonical and the comparison as exact removes the ambiguity, and puts the burden of producing a canonical encoding on the token issuer. The comparison should also run in constant time.

The server does not reconcile the two extensions

A certificate request can carry both a TNAuthList and JWTClaimConstraints, and the ACME server does not cross-check them. Nothing stops a requester from asking for an orig constraint that contradicts the TNAuthList — and if it does, no PASSporT can satisfy both, so the certificate fails verification for every call it is used on. It issues cleanly and is useless.

Responsibility for requesting mutually compatible extensions sits with the ACME account holder submitting the CSR. This is worth knowing before deploying: the failure is silent at issuance and total at verification.

Status

draft-ietf-acme-authority-token-jwtclaimcon-04 (25 July 2026), ACME working group document, in WG Last Call. Current revision and state on the IETF datatracker.