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

RFC 9448 — TNAuthList Profile of ACME Authority Token

RFC 9448 (Wendt, Hancock, Barnes, Peterson — September 2023) is the IETF specification that profiles the ACME Authority Token Challenge from RFC 9447 for STI certificates carrying the TNAuthList extension. It defines a new ACME identifier type — TNAuthList — and specifies what the Authority Token must contain, how the Token Authority validates the requestor’s authority over the telephone numbers or Service Provider Codes being claimed, and how the ACME server validates the token before issuing the certificate. I am the first author. The document is the operational mechanism behind certificate issuance in the US STI hierarchy — the ACME flow every SHAKEN-participating service provider runs to acquire its signing certificate.

What it specifies

The document binds the generic Authority Token substrate (RFC 9447) to the specific identifier type defined in RFC 8226 — TNAuthList, which can carry a Service Provider Code, an individual telephone number, a range of telephone numbers, or a combination of these. Four pieces of mechanism:

  • A new ACME identifier type — TNAuthList. Registered in the ACME Identifier Types registry per RFC 8555 §9.7.7. ACME clients include this in the identifiers field of a new-order request, with the value set to a base64url-encoded DER-serialization of the TNAuthList ASN.1 object. No padding characters in the encoding.
  • The Authority Token payload. Mandatory claims: exp (the token’s expiry), jti (a unique transaction identifier), and atc (the Authority Token Challenge claim defined in RFC 9447). Optional: iss (a URL identifying the Token Authority). For TNAuthList, the atc claim’s tktype is set to TNAuthList and tkvalue is set to the same base64url encoding of the TNAuthList that appears in the ACME identifier object.
  • Optional ca boolean in the atc claim. Signals whether the requested certificate is a CA certificate or an end-entity certificate. The ACME server verifies this against the Basic Constraints extension in the CSR — they must agree.
  • Validation procedure. The ACME server checks: the JWT signature is valid against the Token Authority’s certificate (referenced via x5u or another header mechanism); tktype is TNAuthList; tkvalue matches the identifier in the original ACME challenge; the token is unexpired; the fingerprint matches the client’s ACME account key; and ca matches the CSR. If all checks pass, the challenge is marked valid and the certificate is issued.

The Token Authority’s job is the substantive step. Before issuing the token, it must verify that the requesting party is authorized to assert the SPC, telephone numbers, or telephone number ranges in the TNAuthList. The mechanism for that verification is out of scope of the document — it depends on the Token Authority’s relationship with the requestor (a carrier issuing tokens to its enterprise customers; a regulator-operated service issuing tokens to recognized providers; a numbering administrator issuing tokens against its own records). What RFC 9448 specifies is the protocol envelope; the underlying authority verification is governance.

In US SHAKEN deployment, the industry term for an Authority Token issued by the STI-PA’s token API is the SPC Token — a 9448-compliant Authority Token whose TNAuthList contains a Service Provider Code. It is the concrete operational artifact behind the document’s abstract Authority Token mechanism, and the credential a service provider obtains from the STI-PA before running the ACME flow against an STI-CA.

VESPER — the domain-bound STIR identity extension I’m authoring — recommends 9448 TNAuthList Authority Tokens as Right-to-Use (RTU) evidence for a telephone number in delegate-certificate issuance. The same pattern extends to JWTClaimConstraints Authority Tokens (the JWTClaimConstraints draft) for VESPER scenarios where TN authority needs to be conveyed alongside claim constraints. In both cases the ACME Authority Token mechanism is the substrate VESPER relies on for binding the requestor’s RTU to the certificate the CA issues.

Design choices worth knowing

One is the delegation-friendly token scope. Because TNAuthList itself can express SPC, individual TNs, and ranges, a Token Authority can issue tokens for any subset of the requestor’s authority. A carrier that holds an SPC can issue a token to its enterprise customer for a specific telephone number range belonging to that customer; the customer then runs ACME to get a certificate covering only that range, without needing the carrier to issue the certificate directly. This is the substrate that delegate certificates ride on operationally — RFC 8226’s TNAuthList expressivity, plus RFC 9447’s generic challenge mechanism, plus this document’s binding of the two.

Another is the fingerprint and account-key binding model. The Token Authority isn’t asked to verify the fingerprint binds to a real ACME account — it just signs the fingerprint into the token. The ACME server, when the token is presented, checks the fingerprint matches the ACME account key it sees on the challenge response. This means the Token Authority’s trust-establishment burden is bounded: it has to verify real-world authority over numbers, not the integrity of the ACME ecosystem. Each side does what it knows how to do.

A third is the noncontiguous-TN guidance. The document includes operational advice about how to handle a service provider with a complex, noncontiguous set of telephone numbers under management. Best practice, the document recommends, is to split the noncontiguous set into multiple certificates representing the contiguous parts, rather than attempting to express the entire set in a single TNAuthList. This is small-print operational guidance, but it matters — it shaped how STI certificates get organized in actual deployment, where carriers and signing services typically hold multiple certificates rather than attempting one omnibus credential.

Where this document is referenced

  • RFC 9447 is the generic Authority Token Challenge substrate this document profiles. Read 9447 first if you want the mechanism in the abstract; this document picks up where 9447 ends.
  • draft-ietf-acme-authority-token-jwtclaimcon is an active draft I’m writing that profiles the same Authority Token machinery for certificates carrying JWTClaimConstraints / EnhancedJWTClaimConstraints — the delegation extension from RFC 8226 / RFC 9118. The JWTClaimConstraints profile is to delegated certs what 9448 is to base STI certs.
  • Delegate certificates describes the deployment pattern where a carrier issues tokens to its enterprise customers, who then run ACME to get certificates covering the carrier’s telephone numbers — the flow that RFC 9448 enables in protocol terms.
  • VESPER — see the body of this page — uses 9448 TNAuthList Authority Tokens (and JWTClaimConstraints Authority Tokens) as RTU evidence in delegate-certificate issuance.
  • For the operational framework that ties these certificates to US regulatory governance (STI-GA, STI-PA, ATIS-1000080), see SHAKEN. The current STI-PA certificate-issuance flow uses ACME with this profile.