appliedbits
LIBRARY  ·  IETF LIBRARY ENTRY
Last updated 2026-08-15 drafted

draft-wendt-stir-tn-domain-binding — Binding a Domain to TN Authority

draft-wendt-stir-tn-domain-binding defines a mechanism for binding a domain identifier to telephone number authority inside a STIR certificate. I am the sole author. Currently draft-wendt-stir-tn-domain-binding-01, published 5 August 2026, expiring 6 February 2027. Individual draft, IESG state “I-D Exists” — not adopted by a working group, no stream, no responsible AD. Standards Track intent.

I’m writing this draft, so the framing here is from inside the work.

The gap it addresses

STIR establishes that a signer is authorized for the telephone numbers or service provider codes in the TNAuthList extension (RFC 8226), validated through the certificate chain. That authority may be held by an entity numbers were assigned to, including through delegation (RFC 9060), or by a provider identified by a service provider code. What STIR does not establish is a verifiable identity for the entity holding that authority, or a binding from that entity to an internet identifier a relying party recognizes across contexts.

A domain name is a stable, globally unique identifier with well-established mechanisms for proving control. If a STIR certificate can attest that the entity authorized for a set of numbers is the same entity that controls a particular domain, a relying party gains a corroborating identity signal bound to that authority. For a certificate carrying telephone numbers, the domain identifies the right-to-use holder. For one carrying a service provider code, the domain identifies the provider.

The gap is specific to identifiers that carry no inherent domain association. A telephone number is administered independently of the DNS, so nothing in the number says which domain, if any, belongs to its holder. An identifier already in URI form — a SIP URI in a PASSporT orig or dest — carries its domain as part of the identifier and its authority is the domain owner, so no issuance-time binding is needed. This draft therefore addresses TNAuthList authority only.

The binding

A bound certificate asserts one composite fact: the entity that controls the domain in the certificate is the entity that holds the TNAuthList authority in the certificate. That fact is established at issuance and is not derivable from either proof alone.

It rests on two independent proofs, neither of which this draft defines:

  1. Proof of domain control — the subject demonstrates control of the domain using an existing domain control validation mechanism. The ACME challenge types (RFC 8555) apply directly: dns-01, provisioning a TXT record under a well-known name in the zone, or http-01, serving a key-authorization value at a well-known path. Either is sufficient on its own, and the draft does not restrict the set of usable challenge types.
  2. Proof of TNAuthList authority — the subject presents a TNAuthList authority token from the authority responsible for the entries, validated by the CA. This is the same construct used for ordinary STIR certificate issuance (RFC 9447, RFC 9448). The token is scoped to specific numbers or SPCs and is consumed within a single issuance rather than held as a long-lived bearer credential.

Issuance requirements

A CA issuing bound certificates must satisfy all of the following within a single issuance:

  • Validate control of the domain that will appear in the SubjectAltName dNSName entry, using an established mechanism. ACME challenge-based mechanisms are RECOMMENDED.
  • Validate a TNAuthList authority token covering every entry that will appear in the TNAuthList, per RFC 9447 and RFC 9448. The CA MUST NOT include any entry not covered by a validated token.
  • Treat the two validations as a single atomic condition. If either fails, the CA MUST NOT issue. It must not issue a certificate carrying a domain without corresponding validated TNAuthList authority, nor one carrying TNAuthList authority bound to an unvalidated domain.

The two validations may run in either order. A recent prior domain control validation for the same domain and subject account may be reused within the CA’s policy window; reuse of a prior authority-token validation is not permitted, and a token must be validated for each issuance.

The reason both proofs are evaluated in one issuance, rather than assembled from separately obtained credentials, is that the binding’s trustworthiness depends on a single party having confirmed both at the same time. If a subject could obtain a domain credential from one source and an authority credential from another and combine them itself, a relying party would have no assurance the same entity legitimately held both. Requiring the CA to validate both before issuing makes the certificate a first-party attestation that the binding was verified rather than asserted.

Certificate profile

A bound certificate conforms to the STIR certificate profile in RFC 8226, and to RFC 9060 where it is a delegate certificate. It carries a SubjectAltName extension with exactly one dNSName entry holding the validated domain, and a TNAuthList extension with one or more entries — telephone numbers, service provider codes, or both — every one covered by a token validated during issuance. A certificate scoped to a single telephone number is RECOMMENDED where the TNAuthList carries numbers.

The draft associates no new semantics with the Subject distinguished name and does not require organizational identity in the certificate. The domain goes in the SubjectAltName, not the Common Name, consistent with current PKI practice, so a profile that specifies Common Name content for its own purposes can carry both without conflict. JWTClaimConstraints (RFC 8226) and EnhancedJWTClaimConstraints (RFC 9118) may also be present and are out of scope for the binding.

Relying party verification

Beyond the STIR validation procedures of RFC 8224 and RFC 8226, a relying party must validate the chain to a trusted STIR trust anchor, and may treat the SubjectAltName domain as the identity of the entity holding the TNAuthList authority only when the certificate passes those checks. It must not infer TNAuthList authority from the domain independently of the TNAuthList, nor infer a domain association for any number or SPC absent from the TNAuthList.

Where the relying party obtained the certificate by retrieving it from a location under the domain, successful retrieval over an authenticated channel may reinforce the domain-control evidence, but does not substitute for the issuance binding.

Freshness

The binding reflects state validated at issuance, and its currency is maintained by reissuance rather than by monitoring. Each issuance re-checks domain control and requires a freshly validated authority token, and short-lived certificates bound the interval over which a stale, mistaken or compromised binding stays usable. The draft therefore RECOMMENDS automated issuance and says bound certificates SHOULD be short-lived. That dependency is still in IESG evaluation with open DISCUSSes, so it is a recommendation resting on a document that is not yet an RFC.

What it does not do

Domain control validation establishes control at issuance. It does not attest to the legal identity of the organization controlling the domain. The broader entity verification — the know-your-customer process through which a provider or authority associates a real-world entity with its domain — is performed under the CA’s certificate policy and is explicitly out of scope. The draft relies on domain control and telephone number authority as explicit signals and depends on, rather than specifies, the entity verification underneath them.

The draft has no IANA actions; it reuses certificate extensions and token mechanisms registered by the documents it references.

Relationship to VESPER

VESPER already carries a SubjectAltName domain in its delegate-certificate profile as one of three trust elements, alongside TNAuthList entries and an embedded SCT. This draft factors the domain-to-TN-authority binding out as a standalone mechanism specified against base STIR issuance, so it can be applied to any STIR certificate whose TNAuthList carries telephone numbers or service provider codes, whether or not the deployment is VESPER.

Status

draft-wendt-stir-tn-domain-binding-01 (5 August 2026), individual draft. Per the individual-draft convention used across this library, my own individual drafts get entries. Current revision and state on the IETF datatracker.