| Internet-Draft | STIR TN-Domain Binding | November 2026 |
| Wendt | Expires 5 May 2027 | [Page] |
This document defines a mechanism for binding a domain identifier to telephone number authorization within a STIR certificate. A certificate produced under this mechanism carries, as a co-validated pair, the telephone numbers or service provider codes a subject is authorized for in a TNAuthList extension and a domain identifying the subject in a SubjectAltName dNSName entry. The binding is established at issuance by requiring proof of domain control and validation of a TNAuthList authority token within a single certificate issuance, such that the resulting certificate attests that the responsible authority for the TNAuthList entries and the party controlling the domain both authorized the issuance. The mechanism applies to STIR certificates whose TNAuthList contains telephone number entries, service provider code entries, or both, allowing a domain to be bound to the right-to-use holder for a set of numbers or to the provider identified by a service provider code. This document defines the issuance conformance requirements and the relying party verification rule that together make the binding meaningful. It does not define telephone number or service provider code authorization or domain validation, both of which are specified elsewhere and referenced here. It also defines the STI declaration record, a DNS record published at the bound domain in which the holder of the telephone numbers declares how legitimate calls and messages from them are originated and signed, so that a relying party can recognize ones that are not, and the requirements that any mechanism for discovering the domain bound to a telephone number must meet.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The STIR architecture ([RFC8224], [RFC8225], [RFC8226]) establishes that a signer is authorized for the telephone numbers or service provider codes carried in the TNAuthList certificate extension [RFC8226], validated through the STIR certificate chain. This authorization may be held by an entity to which numbers have been assigned, including through delegation [RFC9060], or by a provider identified by a service provider code. However, STIR does not establish a verifiable identity for the entity that holds this authorization, nor does it bind that identity to an Internet identifier that a relying party can recognize across contexts.¶
A domain name is a stable, globally unique Internet identifier for which well-established mechanisms exist to prove control. If a STIR certificate could attest that the entity authorized for a set of telephone numbers or service provider codes is the same entity that controls a particular domain, a relying party would gain an independent, corroborating identity signal bound to that authorization. For a certificate carrying telephone numbers, the domain identifies the right-to-use holder for those numbers. For a certificate carrying a service provider code, the domain identifies the provider. In both cases the value of the binding depends entirely on the two facts being established independently and then bound together by the issuer, rather than merely asserted by the subject.¶
The need for this binding is specific to identifiers that carry no inherent domain association. A telephone number is administered independently of the DNS, so nothing in the number indicates which domain, if any, is associated with its holder. An identifier already expressed in URI form, such as a SIP URI in a PASSporT orig or dest field [RFC8225], carries its domain as part of the identifier and its authority is the domain owner, so no issuance-time binding is required to associate the two. This document therefore addresses TNAuthList authorization, where the association does not exist unless an issuer establishes it.¶
This document defines that binding. It specifies how an issuing Certification Authority co-validates the TNAuthList authorization and domain control within a single issuance, what the resulting certificate contains, and how a relying party verifies the binding. The mechanism reuses existing components without modification: TNAuthList authorization via authority tokens ([RFC9447], [RFC9448]) and domain control validation via existing challenge mechanisms such as those defined for ACME [RFC8555]. The contribution of this document is the requirement that these two proofs be bound together at issuance and the verification rule that relies on that binding.¶
Once a telephone number is bound to a domain, the holder of the number can use DNS to publish statements about its numbers that change more often than a certificate is issued: whether its calls are signed, which providers may sign for them, whether a number originates calls at all, where out-of-band PASSporTs are placed, and where SIP requests for its numbers can be sent. This document defines that record, published at _sti under the bound domain and modeled on DMARC [RFC7489]. A relying party that receives a call carrying only a telephone number has to find the domain bound to the number before it can read the record. This document states the requirements a mechanism for that lookup must meet and leaves the mechanism to other documents.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the following terms.¶
TNAuthList authorization: an entity's right to use the telephone numbers, or its holdership of the service provider code, carried in a TNAuthList extension [RFC8226]. It is granted by the responsible authority for those entries: a numbering authority or responsible provider for telephone numbers, or a service provider code authority for a code. This document uses "authority" only for the party that grants the authorization and in the term "authority token".¶
TNAuthList authority token: a signed assertion by the responsible authority of TNAuthList authorization for the entries it covers, validated during STIR certificate issuance, as defined in [RFC9447] and [RFC9448]. For telephone number entries this attests right-to-use of the numbers; for service provider code entries it attests holdership of the code.¶
Right-to-Use (RTU): the case of TNAuthList authorization in which the entries are telephone numbers.¶
Domain identifier: a DNS domain name, carried in a SubjectAltName dNSName entry [RFC5280], that identifies the entity holding the TNAuthList authorization, as described in Section 6.1.¶
Bound certificate: a STIR certificate issued under this document, carrying a co-validated TNAuthList and domain identifier.¶
Holder: the entity that holds the TNAuthList authorization in a bound certificate.¶
Bound domain: the domain identifier of a bound certificate.¶
STI declaration record, or declaration record: the DNS TXT record defined in Section 9, published by a holder at its bound domain. The holder's declaration is its statement, as the party authorized for the telephone numbers, of how legitimate calls and messages from them are originated and signed.¶
Relying party: any party that validates a bound certificate or applies a declaration record, such as a STIR verification service [RFC8224], a terminating provider, a service verifying on behalf of a device, a device, or another application.¶
A bound certificate asserts a single composite fact: the authority responsible for the TNAuthList entries and the party controlling the domain identifier both authorized the same issuance, so that the domain identifies the entity authorized for those entries. This composite fact is established at issuance and is not derivable from either proof alone.¶
The binding rests on two independent proofs:¶
Proof of domain control: the subject demonstrates control of the domain identifier, using an existing domain control validation mechanism.¶
Proof of TNAuthList authorization: the subject presents a TNAuthList authority token for the telephone numbers or service provider codes, validated by the issuing CA against the responsible authority that issued it.¶
Neither proof is defined by this document. What this document defines is the requirement that both be satisfied within a single issuance, and that the issued certificate carry both results as a bound pair, so that a relying party validating the certificate can rely on the composite fact.¶
The binding is produced by a three-phase process. The first two phases each establish one proof using mechanisms that already exist; the third phase binds the two results into one certificate. The phases are described here to give an operational picture; the normative conformance requirements are stated in Section 5.¶
Phase 1 establishes control of the domain identifier. Phase 2 establishes TNAuthList authorization for the telephone numbers or service provider codes. Phase 3 is a single certificate issuance that requires both proofs and binds their results. The following diagram shows the process at a glance.¶
+-------------+ +-------------------+
| Subject | | TNAuthList |
| (domain + | | Authority |
| TN or SPC | | (numbering auth / |
| authority) | | provider / SPC |
| | | authority) |
+------+------+ +---------+---------+
| Phase 2: request authority evidence |
| --------------------------------------------+
| |
| <-------- TNAuthList authority token --------+
| (proves TN right-to-use or SPC holdership)
|
| Phase 1 + Phase 3: single issuance request to CA
| (CSR + domain challenge + authority token)
v
+------+-------------------------------------------------+
| STI Certification Authority |
| |
| Phase 1: validate domain control (e.g. dns-01) |
| Phase 2 check: validate TNAuthList authority token |
| Phase 3: bind validated domain + validated TNAuthList |
| into one certificate |
+------+-------------------------------------------------+
|
| bound certificate (domain in SAN + TN/SPC in
| TNAuthList)
v
+------+-------------------+
| Bound certificate |
+--------------------------+
¶
The subject proves control of the domain identifier that will appear in the SubjectAltName. This document does not define a new mechanism for this; it reuses domain control validation as already deployed for the Web PKI. The challenge types defined for ACME [RFC8555] are directly applicable:¶
dns-01: the subject provisions a DNS TXT record containing a key-authorization value under a well-known name in the zone of the domain. This proves control of the zone.¶
http-01: the subject serves a key-authorization value at a well-known path under the domain. This proves control of content served at the domain.¶
dns-persist-01 [I-D.ietf-acme-dns-persist]: the subject publishes a standing TXT record at _validation-persist under the domain naming the CA and the ACME account permitted to validate it. The record stays in place across issuances. Because bound certificates are short-lived and reissued often, and because the party operating the domain is often not the subject, a standing record that names the issuing CA and account suits this binding better than a per-order token: the domain holder provisions it once, and every reissuance revalidates against it. A CA MUST validate the exact domain identifier that will appear in the certificate and MUST NOT rely on a validation scoped to subdomains by that challenge's wildcard policy.¶
Control of the domain may be exercised on the subject's behalf by another party, as described in Section 6.1. The challenge then shows that the party operating the domain authorized the issuance.¶
Any one of these is sufficient on its own. The choice follows existing ACME practice and is operational. A domain holder that delegates the challenge to another party can limit what that party may obtain, as described in Section 6.2. This document does not restrict the set of usable challenge types: any domain control validation challenge standardized for ACME, including mechanisms that may be defined in the future, is equally applicable, provided it demonstrates current authorized control of the domain.¶
Domain control verification is an explicit, cryptographically demonstrable signal. The operational act of provisioning the required records in public DNS, or serving the required content under the domain, demonstrates current authorized control of the domain by the party performing it. This is distinct from the broader entity verification, often referred to as know-your-customer (KYC), through which a provider or authority establishes the customer relationship that associates a real-world entity with its domain. That verification is out of scope here and is neither defined nor replaced by this document. This document relies on domain control and telephone number authorization as explicit signals, and depends on, rather than specifies, the entity verification they rest on.¶
The subject places a single certificate issuance request to the CA that carries both proofs: a Certificate Signing Request naming the domain identifier in its SubjectAltName, a domain control challenge response, and the TNAuthList authority token. The CA validates domain control and validates the authority token, and only if both succeed issues a certificate whose SubjectAltName carries the validated domain and whose TNAuthList carries the validated telephone numbers or service provider codes.¶
The reason both proofs are evaluated within one issuance, rather than assembled from separately obtained credentials, is that the trustworthiness of the binding depends on a single party having confirmed both at the same time. If a subject could obtain a domain credential from one source and a TNAuthList authorization credential from another and combine them itself, a relying party would have no assurance that both authorities approved the pairing. Requiring the CA to validate both before issuing makes the certificate a first-party attestation that the binding was verified, not merely asserted. The two proofs are frequently supplied by different parties: the authority token by the number authority, and the domain challenge by whoever operates the domain, which may be the entity itself or a party acting for it (Section 6.1). The binding does not require them to be the same party; it requires both to have authorized the issuance.¶
The following sequence shows the issuance in full.¶
Subject STI-CA TNAuthList Auth
| | |
| (Phase 2 done earlier) |
| request authority evidence -----------> |
| <----- TNAuthList authority token ----- |
| | |
| 1. issuance request (CSR w/ domain SAN + token)
| ---------------> | |
| 2. domain challenge (dns-01 / http-01) |
| <--------------- | |
| provision TXT / serve resource |
| ---------------> | |
| | validate domain |
| | 3. validate token --> |
| | <--- token valid ----- |
| | 4. both OK? yes |
| <----- bound certificate (domain + TN/SPC) |
| | |
¶
If either proof fails at step 4, the CA does not issue, and the subject receives an error rather than a certificate.¶
An issuing Certification Authority that issues bound certificates under this document MUST satisfy all of the following within a single certificate issuance.¶
The CA MUST validate control of the domain identifier that will appear in the SubjectAltName dNSName entry of the certificate. The CA MUST use an established domain control validation mechanism. The challenge-based mechanisms defined for ACME, in [RFC8555] and in documents that register additional challenge types, are suitable and RECOMMENDED. This document does not define a new domain control validation mechanism.¶
The CA MUST validate a TNAuthList authority token covering the telephone numbers or service provider codes that will appear in the TNAuthList extension of the certificate, in accordance with [RFC9447] and [RFC9448]. The CA MUST NOT include in the TNAuthList any telephone number or service provider code not covered by a validated TNAuthList authority token.¶
The CA MUST treat the two validations as a single atomic condition for issuance. If either the domain control validation or the TNAuthList authority token validation fails, the CA MUST NOT issue the certificate. The CA MUST NOT issue a certificate that carries a domain identifier without a corresponding validated TNAuthList authorization, nor one that carries TNAuthList authorization bound to an unvalidated domain identifier.¶
The two validations MAY be performed in any order within the issuance, and MAY reuse a recent prior domain control validation for the same domain identifier and the same subject account, provided the reused validation is within the validity window permitted by the CA's policy. CAs SHOULD keep that window short. Reuse of a prior TNAuthList authority token validation is NOT permitted; a token MUST be validated for each issuance. A CA using a persistent challenge such as dns-persist-01 (Section 4.1) validates the standing record at each issuance and does not rely on reuse.¶
This document does not mandate a particular issuance protocol. The challenge and authority token mechanisms defined for ACME are used and RECOMMENDED here because they are established and deployed, but other automated certificate issuance protocols could be adapted to satisfy the requirements above, provided they perform the same two validations and treat them as a single atomic condition for issuance. Because the currency of the binding depends on how often those validations are repeated, automated issuance is RECOMMENDED in any case. For the same reason, bound certificates SHOULD be short-lived, as described in [I-D.ietf-stir-certificates-shortlived], so that domain control and telephone number authority are revalidated on a frequent basis.¶
A bound certificate MUST conform to the STIR certificate profile in [RFC8226]. Where the certificate is a delegate certificate, it MUST also conform to [RFC9060]. A bound certificate MUST contain the following.¶
A SubjectAltName extension containing exactly one dNSName entry carrying the validated domain identifier. The domain identifier MUST be a DNS-resolvable domain name that identifies the subject, as described in Section 6.1, and MUST NOT be a wildcard name. The binding is to that exact name: a bound certificate for a domain says nothing about its parent or child domains.¶
A TNAuthList extension [RFC8226] containing one or more entries, which may be telephone number entries, service provider code entries, or both. Every entry MUST be covered by a TNAuthList authority token validated during issuance.¶
A bound certificate MAY additionally carry the JWTClaimConstraints extension of [RFC8226], the EnhancedJWTClaimConstraints extension of [RFC9118], and other elements permitted by [RFC8226]; these are out of scope for the binding defined here. Issuers SHOULD issue short-lived certificates as described in [I-D.ietf-stir-certificates-shortlived].¶
This document associates no new semantics with the Subject distinguished name and does not require organizational identity to be present in the certificate. The domain identifier in the SubjectAltName is the identifier this document binds to the TNAuthList authorization.¶
The domain identifier is carried in the SubjectAltName, not in the Subject Common Name, consistent with current PKI practice of conveying domain identity in the SubjectAltName rather than the Common Name. This binding adds a SubjectAltName dNSName entry and neither relies on nor alters the Subject distinguished name. It is therefore compatible with certificate profiles that specify Subject Common Name content for their own purposes; a certificate may carry such Common Name content and a bound domain identifier in its SubjectAltName without conflict.¶
The domain identifier is the domain that identifies the entity holding the TNAuthList authorization, that is, the right-to-use holder for telephone number entries or the provider for a service provider code: the domain under which that entity presents itself, for example in its web site, its email, and the URLs it sends in messages. Control of that domain may be exercised on the entity's behalf by another party, such as a provider, a hosting platform, or a contact center operator, which performs domain control validation for the issuance and publishes the declaration record. The domain of a party acting on the entity's behalf is not a substitute for the entity's own domain.¶
A hosted subdomain that the entity uses as its public identifier, such as smallbiz.provider.example, satisfies this requirement. A provider's own domain bound to telephone numbers held by its customer does not, because it misstates which entity holds the TNAuthList authorization. Domain control validation cannot distinguish a domain's registrant from its operator, so this requirement is applied under the CA's certificate policy rather than by the validation itself.¶
A domain holder that lets another party pass domain control validation for its domain, for example by delegating the _acme-challenge name to that party by CNAME, lets that party obtain bound certificates naming the domain for any TNAuthList entries the party holds authority tokens for. The holder can bound that in advance with a CAA record [RFC8659]. A _validation-persist record (Section 4.1) names the CA and account the holder has authorized to validate; an issuesti Property is what prevents any other CA from issuing through a different challenge, and the two are meant to be published together.¶
This document defines the CAA Property Tag issuesti. An issuesti Property authorizes the CA identified by its issuer domain name to issue bound certificates for the domain. Its value has the same syntax as the issue Property defined in [RFC8659].¶
Before issuing a bound certificate, the CA MUST determine the Relevant RRSet for the domain in the SubjectAltName dNSName entry using the procedure in [RFC8659], and:¶
If the Relevant RRSet is empty or contains no issuesti Property, the domain has not restricted issuance of bound certificates, and the CA proceeds with the validations in Section 5.¶
If the Relevant RRSet contains one or more issuesti Properties, the CA MUST NOT issue unless at least one of them names the CA's issuer domain name. An issuesti Property with a malformed value is treated as if its issuer domain name were empty, which permits no CA.¶
The issue and issuewild Properties do not restrict issuance of bound certificates, and issuesti does not restrict issuance of any other certificate, following the approach issuemail [RFC9495] takes for email certificates. A domain holder that publishes CAA for its Web PKI certificates therefore does not block or authorize bound certificates by doing so.¶
The accounturi and validationmethods parameters defined in [RFC8657] apply to issuesti with the meaning given there. With accounturi, the holder limits issuance to a specific ACME account, such as the account of the party operating the domain on its behalf. With validationmethods, it limits the domain control validation methods the CA may use. Unlike the declaration record, CAA is inherited: under the procedure in [RFC8659], a CA that finds no CAA RRSet at the domain climbs toward the root, so an issuesti Property at a holder's apex also governs issuance for a subdomain it has delegated, unless that subdomain publishes its own. A CA that does not support a parameter present in a matching issuesti Property MUST NOT treat that Property as authorizing issuance.¶
universal-exports.example. IN CAA 0 issuesti (
"q-branch.example; "
"accounturi=https://acme.q-branch.example/acct/007" )
¶
CAA governs issuance only. As stated in [RFC8659], a relying party does not use CAA records when verifying a certificate, and the absence of an issuesti Property has no bearing on the verification in Section 7. The CA's CAA lookup is exposed to DNS spoofing like any CAA lookup; the considerations of [RFC8659] apply, and DNSSEC on the holder's zone protects it.¶
Where bound certificates are recorded in certificate transparency logs [I-D.ietf-stir-certificate-transparency], a domain holder can monitor the logs for certificates naming its domain and detect a binding it did not authorize, whichever path produced it. CAA (Section 6.2) limits issuance in advance; monitoring detects what CAA does not prevent. A domain holder that publishes a declaration record SHOULD monitor for bound certificates naming its domain where logs are available. The same holder has reason to watch Web PKI transparency logs for TLS certificates it did not request, since those are the earliest public sign that another party has passed domain control validation for its domain.¶
[RFC5922] also places a domain identifier in the SubjectAltName of a certificate used with SIP, and the two uses are compatible but serve different purposes.¶
In [RFC5922] the SubjectAltName carries the identity that a peer verifies. A party connecting to a SIP domain compares the domain it intended to reach against the identities in the presented certificate, and the certificate is accepted for that connection if one of them matches. The domain identifier is the name being matched.¶
In this document the dNSName is an attribute of the subject. It is co-validated with the TNAuthList at issuance and records which entity holds the telephone number authorization the certificate asserts. It is not, by virtue of this binding, a statement about which name a connecting peer should match.¶
A single certificate may serve both purposes, and where a subject operates an interface under the same domain that is bound to its telephone number authorization, the domain a connecting peer matches and the domain bound here are the same value. That is a property of the deployment rather than of the binding, and a certificate that satisfies one use does not necessarily satisfy the other.¶
The reason a binding is required at all follows from the identifiers involved. For an identity of the form user@domain, the domain administers the namespace that contains the identity, so a certificate establishing control of the domain also establishes authorization over identities within it, and no further association is needed. A telephone number is administered independently of the DNS, so control of a domain establishes nothing about authorization for a number, and authorization for a number establishes nothing about any domain. This document supplies, at issuance, the association that a domain-form identity carries inherently.¶
The following examples illustrate the two principal cases. The certificate fields are shown in the textual style produced by common certificate tooling, omitting fields not relevant to the binding. The TNAuthList extension is identified by the object identifier id-pe-TNAuthList (1.3.6.1.5.5.7.1.26) and its value is the DER encoding of the TNAuthorizationList structure defined in [RFC8226]; because most tooling does not decode this extension natively, both the decoded contents and the DER octets are shown. Values are illustrative.¶
The first example is a certificate issued to a service provider. Its TNAuthList carries a single service provider code, and its SubjectAltName carries the domain that identifies that provider.¶
Certificate:
Data:
Subject: O=Drax Telecom
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:drax-telecom.example
id-pe-TNAuthList (1.3.6.1.5.5.7.1.26):
TNAuthorizationList:
spc [0]: "1234"
¶
The TNAuthorizationList DER, as it appears in the extension value, with the EXPLICIT context tag on the spc CHOICE alternative:¶
30 08 A0 06 16 04 31 32 33 34
30 08 SEQUENCE (TNAuthorizationList), 8 octets
A0 06 [0] EXPLICIT (spc), 6 octets
16 04 IA5String, 4 octets
31 32 33 34 "1234"
¶
In this case a relying party that validates the certificate learns that the entity holding service provider code 1234 is the same entity that controls drax-telecom.example, because the issuing CA validated both within a single issuance.¶
The second example is a certificate issued to a business entity that holds the right-to-use for a telephone number. Its TNAuthList carries that telephone number, and its SubjectAltName carries the business's domain. While a TNAuthorizationList may contain more than one entry, a certificate scoped to a single telephone number is RECOMMENDED. Telephone numbers in the TNAuthorizationList are IA5Strings restricted to the digits and symbols permitted by [RFC8226], and do not include a leading "+".¶
Certificate:
Data:
Subject: O=Universal Exports Ltd
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:universal-exports.example
id-pe-TNAuthList (1.3.6.1.5.5.7.1.26):
TNAuthorizationList:
one [2]: "12025550100"
¶
The corresponding TNAuthorizationList DER, with the EXPLICIT context tag on the telephone number CHOICE alternative:¶
30 0F A2 0D 16 0B 31 32 30 32 35 35 35 30 31 30 30
30 0F SEQUENCE (TNAuthorizationList), 15 octets
A2 0D [2] EXPLICIT (one), 13 octets
16 0B IA5String, 11 octets
31 32 30 32 35 35 35 30 31 30 30 "12025550100"
¶
In this case a relying party learns that the entity that controls universal-exports.example is the same entity that holds the right-to-use for the telephone number 12025550100. A relying party MUST NOT extend that conclusion to any telephone number not present in the TNAuthList.¶
A certificate MAY carry both telephone number entries and service provider code entries in a single TNAuthorizationList, in which case the domain identifier is bound to all of them, as permitted by [RFC8226].¶
A relying party that validates a bound certificate MUST apply the following, in addition to the certificate validation procedures of [RFC8226]. The same rules apply whatever the relying party is and however it obtained the certificate: through the x5u or x5c of a PASSporT [RFC8225] carried in SIP [RFC8224] or delivered out of band, or by other means.¶
The relying party MUST validate the certificate chain to a trust anchor it accepts. As in [RFC8226], which trust anchors a relying party accepts is a matter of its configuration and is not specified by this document. A certificate that meets the requirements of this document is a bound certificate whichever trust anchor it chains to.¶
The relying party MUST treat the domain identifier in the SubjectAltName dNSName entry as the identity of the entity holding the TNAuthList authorization in the certificate only when the certificate is valid under the above checks. The identity is the exact domain in the dNSName entry; a relying party MUST NOT treat a bound certificate for a parent or child domain as establishing a binding for the domain in question. The domain identifier carries this meaning by virtue of the issuance binding; a relying party MUST NOT infer TNAuthList authorization from the domain identifier independently of the TNAuthList, nor infer domain association for any telephone number or service provider code not present in the TNAuthList.¶
When a relying party obtains the certificate by retrieving it from a location under the domain identifier, the relying party MAY treat successful retrieval over an authenticated channel for that domain as reinforcing the domain control evidence, but this retrieval is not a substitute for the issuance binding established above. This document does not require that a bound certificate be published under its domain identifier.¶
A relying party that receives a call or message signed with a bound certificate learns the bound domain from the certificate. A relying party that receives an unsigned call, or one signed with a certificate that is not bound, has only the telephone number. To find the declaration record in that case, it needs the domain bound to the number.¶
This document does not define a discovery mechanism. Any mechanism used to find the domain bound to a telephone number MUST provide the following:¶
Authority: it returns a domain for a telephone number only where a bound certificate establishes the binding, that is, where the two validations of Section 5 were performed in a single issuance.¶
Currency: an association lapses unless revalidated, so that a telephone number that is disconnected, reassigned, or ported stops returning the former holder's domain. An association lapses no later than the expiry of the last bound certificate supporting it.¶
Integrity: a relying party can detect a false association, either because the response is authenticated or because the relying party accepts the association only once a bound certificate naming both the telephone number and the domain verifies.¶
Privacy: where a lookup is made by or on behalf of an individual, such as a called party's device, a service verifying on behalf of that device, or an agent acting for a person, no single party learns both which telephone number was looked up and on whose behalf.¶
A mechanism returns every current association for a telephone number and does not choose among them. Where more than one domain is returned, the relying party decides by verification: an association is confirmed by a bound certificate for the telephone number whose domain identifier is that domain.¶
A bound certificate is itself a discovery mechanism for any call or message signed with it. Other mechanisms, such as a registry built from bound certificates, are defined in other documents.¶
A holder publishes a declaration record at its bound domain to declare how it originates and signs calls and messages from the telephone numbers bound to that domain. A relying party uses the declaration to recognize calls and messages that do not match it. The record is modeled on DMARC [RFC7489].¶
The declaration record is a DNS TXT record at the name formed by prepending the label _sti to the bound domain:¶
_sti.universal-exports.example. IN TXT (
"v=STI1; p=reject; spc=1234; align=r" )
¶
The record applies to every telephone number bound to that domain by a current bound certificate. It lists no telephone numbers. A relying party looks up the record only at the bound domain itself and does not look at its parent or child domains. A holder that wants different declarations for different groups of telephone numbers binds each group to a different domain, for example outbound.universal-exports.example and inbound.universal-exports.example, and publishes a record at each.¶
A holder whose domain is operated by another party can delegate the record, for example with a CNAME at _sti.<domain> pointing to a name the operator maintains.¶
The zone containing the record SHOULD be signed with DNSSEC [RFC4033].¶
A relying party that finds more than one TXT record beginning with v=STI1 at the name MUST treat the domain as having no declaration record. TXT records at the name that do not begin with v=STI1 are ignored.¶
A domain with no declaration record declares nothing. That is not the same as p=none, which states that the holder publishes for visibility only. A relying party treats a record that does not parse, or whose p value is missing or not recognized, as no record. A temporary DNS failure is not evidence that no record exists, and a relying party does not treat it as one.¶
The record is a list of tag=value pairs separated by semicolons. Whitespace around tags, values, and separators is ignored. Tag names are case-insensitive. The v tag MUST be first. A relying party MUST ignore tags it does not recognize.¶
sti-record = sti-version *(sep sti-tag) [sep] sti-version = "v" *WSP "=" *WSP "STI1" sep = *WSP ";" *WSP sti-tag = tag-name *WSP "=" *WSP tag-value tag-name = ALPHA *(ALPHA / DIGIT / "_") tag-value = 1*(%x21-3A / %x3C-7E)¶
none: the holder publishes for visibility only. Relying parties apply their own treatment.¶
quarantine: calls from the bound telephone numbers are signed at origination, but some reach relying parties over paths that remove the Identity header field [RFC8224]. An unsigned call is suspect but not conclusively illegitimate.¶
reject: every legitimate call from the bound telephone numbers is signed in a way that matches Section 9.5, in band or out of band. A call that does not is not legitimate.¶
never: the bound telephone numbers do not originate calls, or messages where pm is absent or also never. A call or message with one of them as the originating identity is not legitimate, signed or not, and neither is any other STIR assertion presenting one of them as the originator. Answering a call, including returning a connected identity response [RFC9970], replying within a session initiated by another party, and appearing as the diverting party [RFC8946] are not origination.¶
The disposition of a call is a decision of the relying party under its local policy. The record states the holder's expectation and does not oblige the relying party to act on it.¶
A call matches the declaration record when a PASSporT for the call's calling telephone number, carried in band in an Identity header field [RFC8224] or obtained out of band by a mechanism defined in another document, verifies under a certificate that meets the alignment rule:¶
Strict (align=s): the certificate is a bound certificate whose domain identifier is the domain publishing the record and whose TNAuthList contains the calling telephone number.¶
Relaxed (align=r): the strict condition, or a certificate whose TNAuthList contains a service provider code listed in spc.¶
Both conditions are tested on the TNAuthList of a certificate validated as described in [RFC8226]. The declaration record depends on no mechanism beyond STIR. spc has no effect under strict alignment.¶
A relying party applies a declaration record as follows:¶
Determine the bound domain: from the bound certificate of a verified PASSporT for the call, or, for the calling telephone number, by a discovery mechanism meeting Section 8.¶
Fetch the TXT record at _sti.<domain>.¶
Determine whether the call matches Section 9.5. Where the call carries no PASSporT, the relying party may obtain one out of band where an extension (Section 9.8) provides for it.¶
Apply its local policy to the result, taking account of p, or pm for a message.¶
Where discovery returns more than one domain for a telephone number, the domain whose bound certificate verifies a PASSporT for the call determines which declaration record applies. How a relying party treats a call for which no domain's certificate verifies, when the domains publish different declarations, is a matter of local policy.¶
A relying party SHOULD cache a declaration record for its DNS time to live.¶
The sip tag names a domain at which the holder, or a party acting for it, receives SIP requests for the bound telephone numbers. A SIP entity that sends a request for a bound telephone number to the holder resolves the domain as described in [RFC3263]. The certificate presented at that destination is verified against the domain named by sip, as for any SIP domain [RFC5922]. Where that domain is also the bound domain, one bound certificate serves both purposes, as described in Section 6.4; where it differs, the domain named by sip is published by the holder at its bound domain, which lets a peer associate the interface with the holder. The tag does not change routing through the network; whether a SIP entity uses it is a matter of local policy. A holder that does not receive SIP requests for its numbers omits the tag.¶
This document defines the record, its syntax, and the base tags in Section 9.3. Other documents define additional tags by registering them as described in Section 12.2. A tag's definition states its value syntax and what a relying party does with it. An extension MUST NOT change the meaning of the base tags. A relying party ignores tags it does not recognize, so a record carrying extension tags remains usable by a relying party that implements only this document.¶
The following tag names are reserved for extensions:¶
pps: the location of a service from which PASSporTs for calls and messages from the bound telephone numbers can be retrieved out of band.¶
rua and alert: reporting by relying parties to the holder, as aggregate reports and as immediate reports when non-conforming calls for one telephone number exceed a threshold within a window.¶
The binding is only as strong as the requirement that one CA validate both proofs in one issuance. A subject that could obtain a certificate for its domain from one source and a credential for its telephone numbers from another, and present the two together, would be asserting the association itself. A CA that issued a certificate carrying a domain identifier without a validated TNAuthList authority token for its entries, or the reverse, would make the same assertion on the subject's behalf. Section 5 prohibits both.¶
The binding states what was validated at issuance. A telephone number can be reassigned, and a domain can change hands, while a certificate naming both is still valid. Short-lived certificates ([I-D.ietf-stir-certificates-shortlived]) bound how long such a certificate remains usable, and reuse of a prior domain control validation extends that interval by the reuse window, which is why Section 5 asks CAs to keep it short.¶
Domain control validation proves that whoever controls the domain, or the content served at it, authorized the issuance. It does not prove who that party is, and a relying party that treats the domain identifier as a legal identity has gone beyond what the binding establishes. Of the challenge types in Section 4.1, http-01 is satisfied by control of web content alone, which is more often delegated, and more often compromised, than control of the zone. A domain holder can exclude it with the validationmethods parameter of issuesti (Section 6.2).¶
Where the holder has delegated operation of its domain (Section 6.1), the delegate can obtain bound certificates naming that domain for any telephone numbers it holds authority tokens for, including numbers belonging to the delegate itself or to its other customers. This is the same trust a domain holder extends to any party that passes Web PKI validation for it. The holder limits it by delegating a subdomain rather than the domain, by publishing an issuesti Property with accounturi (Section 6.2), which also defeats a party that briefly gains control of the zone or web content, and by monitoring transparency logs for certificates naming its domain (Section 6.3). The reverse pairing, an attacker's own domain bound to telephone numbers it does not hold, is not available, because the authority token cannot be obtained for those numbers.¶
A spoofed DNS response can suppress a declaration record, substitute one, or misdirect a discovery lookup or an out-of-band retrieval. It cannot make a forged PASSporT verify, because signing keys are carried in certificates and an attacker's domain holds no bound certificate for the victim's telephone number. This is why Section 9 asks that the zone be signed with DNSSEC. How a relying party treats a declaration record from an unsigned zone is a matter of its local policy.¶
A declaration of reject or never is what lets a relying party identify calls that spoof the holder's telephone numbers. It is also what lets a party in control of the holder's DNS cause the holder's own calls to be treated as spoofed. The zone carrying the record, and the zone of any party operating it for the holder, warrants the protection given to any record that directs how the holder's traffic is handled.¶
A declaration record lists no telephone numbers and carries no information about individuals.¶
A discovery lookup or a fetch of a declaration record made by a network relying party handling a call reveals nothing that party does not already hold. The same lookup made by or on behalf of an individual reveals to the party answering it who is calling that individual, or whom that individual is contacting. The privacy requirement in Section 8 applies to the discovery lookup. A device fetching a declaration record over DNS also reveals the holder to its resolver, and can avoid that by using Oblivious DNS over HTTPS [RFC9230].¶
IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:¶
| RR Type | _NODE NAME | Reference |
|---|---|---|
| TXT |
_sti
|
This document |
IANA is requested to add the following entry to the "Certification Authority Restriction Properties" registry within the "Public Key Infrastructure using X.509 (PKIX) Parameters" registry group:¶
| Tag | Meaning | Reference |
|---|---|---|
issuesti
|
Authorization Entry for STIR Bound Certificates | This document, Section 6.2 |
This document relies on certificate extensions and token mechanisms registered by the documents it references, and requests no other IANA actions.¶