]> Somos, Inc.

US chris@appliedbits.com

Applications and Real-Time Secure Telephone Identity Revisited telephone number domain right-to-use service provider code delegate certificate declaration record 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.

Introduction The STIR architecture (, , ) establishes that a signer is authorized for the telephone numbers or service provider codes carried in the TNAuthList certificate extension , validated through the STIR certificate chain. This authorization may be held by an entity to which numbers have been assigned, including through delegation , 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 , 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 (, ) and domain control validation via existing challenge mechanisms such as those defined for ACME . 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 . 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.

Conventions and Definitions 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 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 . 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 and . 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 , that identifies the entity holding the TNAuthList authorization, as described in . 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 , 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 , a terminating provider, a service verifying on behalf of a device, a device, or another application.

Overview of the Binding 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.

Binding Process 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 . 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.

Phase 1: Domain control 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 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 : 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 . 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 . 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.

Phase 2: TNAuthList authorization The subject obtains a TNAuthList authority token from the responsible authority for the entries it covers: a numbering authority or responsible provider for telephone numbers, or a service provider code authority for an SPC. This is the same authority token construct used for ordinary STIR certificate issuance (, ). The token is scoped to specific telephone numbers or service provider codes, is verifiable by the CA against the responsible authority's credentials, and is consumed within a single issuance rather than held as a long-lived bearer credential. The authority issuing the token and the subject are frequently different entities; binding the two proofs is what makes that separation verifiable rather than assumed.

Phase 3: Binding issuance 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 (). 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.

| | <----- 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.

Issuance Requirements 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 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 and . 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 () 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 , so that domain control and telephone number authority are revalidated on a frequent basis.

Certificate Profile A bound certificate MUST conform to the STIR certificate profile in . Where the certificate is a delegate certificate, it MUST also conform to . 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 , 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 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 , the EnhancedJWTClaimConstraints extension of , and other elements permitted by ; these are out of scope for the binding defined here. Issuers SHOULD issue short-lived certificates as described in . 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.

What the Domain Identifier Denotes 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.

Limiting Issuance for a Domain 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 . A _validation-persist record () 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 . Before issuing a bound certificate, the CA MUST determine the Relevant RRSet for the domain in the SubjectAltName dNSName entry using the procedure in , 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 . 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 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 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 , 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.

CAA governs issuance only. As stated in , 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 . The CA's CAA lookup is exposed to DNS spoofing like any CAA lookup; the considerations of apply, and DNSSEC on the holder's zone protects it.

Monitoring Issuance for a Domain Where bound certificates are recorded in certificate transparency logs , 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 () 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.

Relationship to SIP Domain Certificates 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 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.

Examples 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 ; 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.

The TNAuthorizationList DER, as it appears in the extension value, with the EXPLICIT context tag on the spc CHOICE alternative:

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 , and do not include a leading "+".

The corresponding TNAuthorizationList DER, with the EXPLICIT context tag on the telephone number CHOICE alternative:

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 .

Relying Party Verification A relying party that validates a bound certificate MUST apply the following, in addition to the certificate validation procedures of . The same rules apply whatever the relying party is and however it obtained the certificate: through the x5u or x5c of a PASSporT carried in SIP 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 , 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.

Telephone Number to Domain Discovery 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 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.

STI Declaration Record 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 .

Location The declaration record is a DNS TXT record at the name formed by prepending the label _sti to the bound domain:

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 . 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.

Syntax 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.

WSP, ALPHA, and DIGIT are defined in .

Tags Tag Value Meaning v STI1 Version. REQUIRED, and first. p none, quarantine, reject, never How legitimate calls from the bound telephone numbers are originated and signed. REQUIRED. pm as p The same for messages from the bound telephone numbers, where it differs. If absent, p applies to messages. spc comma-separated list of service provider codes Service provider codes whose certificates may sign for the bound telephone numbers under relaxed alignment. align s (strict) or r (relaxed) Which certificates match the declaration (). Default s. sip domain name Domain at which SIP requests for the bound telephone numbers can be received ().

Declaration Values 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 . 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 , 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 , replying within a session initiated by another party, and appearing as the diverting party 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.

Alignment A call matches the declaration record when a PASSporT for the call's calling telephone number, carried in band in an Identity header field 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 . The declaration record depends on no mechanism beyond STIR. spc has no effect under strict alignment.

Applying the Declaration Record 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 . Fetch the TXT record at _sti.<domain>. Determine whether the call matches . Where the call carries no PASSporT, the relying party may obtain one out of band where an extension () 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.

SIP Destination 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 . The certificate presented at that destination is verified against the domain named by sip, as for any SIP domain . Where that domain is also the bound domain, one bound certificate serves both purposes, as described in ; 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.

Extending the Record This document defines the record, its syntax, and the base tags in . Other documents define additional tags by registering them as described in . 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.

Security Considerations 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. 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 () 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 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 , 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 (). Where the holder has delegated operation of its domain (), 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 (), 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 (). 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 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.

Privacy Considerations 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 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 .

IANA Considerations

Underscored DNS Node Name IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry : RR Type _NODE NAME Reference TXT _sti This document

STI Declaration Record Tags IANA is requested to create a registry titled "STI Declaration Record Tags". The registration policy is Expert Review . Each entry contains a tag name, a status of "current" or "reserved", a short description, and a reference. The designated expert checks that a proposed tag has a defined value syntax and relying party behavior in a publicly available document, does not duplicate or change the meaning of an existing tag, and follows the syntax in . A "reserved" entry holds a name for a definition expected in another document. The initial entries are: Tag Status Description Reference v current Version This document p current Declaration for calls This document pm current Declaration for messages This document spc current Service provider codes for relaxed alignment This document align current Alignment mode This document sip current SIP destination domain This document pps reserved Out-of-band PASSporT retrieval This document rua reserved Aggregate reporting This document alert reserved Threshold reporting This document

CAA Property Tag 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, This document relies on certificate extensions and token mechanisms registered by the documents it references, and requests no other IANA actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. RFC 8226 specifies the use of certificates for Secure Telephone Identity Credentials; these certificates are often called "Secure Telephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT. Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates. Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space. This document explores the applicability of STIR's Personal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support for both messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs. This document obsoletes RFC 6844. The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities (CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by the Automatic Certificate Management Environment (ACME) protocol to be required. The Certification Authority Authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of Certification Authorities that are authorized to issue certificates for the domain. RFC 8659 contains the core CAA specification, where Property Tags that restrict the issuance of certificates that certify domain names are defined. This specification defines a Property Tag that grants authorization to Certification Authorities to issue certificates that contain the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS-TRACK] The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios. This document updates RFC 8224. The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. However, the Secure Telephone Identity Revisited (STIR) framework provides no means for determining the identity of the called party in a conventional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP identity that accompanied STIR. It also considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination and preventing the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. TransUnion When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. Fastly Crosslayer Labs, Inc. Amazon Trust Services This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as multi-tenant hosting platforms, enterprise DNS environments, and IoT deployments. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/Browser Forum Baseline Requirements. Somos, Inc. Somos, Inc. TransNexus Twilio This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI ecosystem to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is to establish a level of trust within the STI ecosystem that relies on the verification of telephone numbers. This involves requiring STI certificates to be listed in an established log and refusing to honor those that are not. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. In the STI ecosystem, the primary role of CT is to provide verifiable trust by detecting the unauthorized issuance of duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR ecosystem, focusing on verifiable control over telephone number or service provider code resources.