]> 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 This document defines a mechanism for binding a domain identifier to telephone number authority 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 the subject controls 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 same entity holds both. 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.

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

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 authority: the authorization for an entity to use the telephone numbers or to hold the service provider code carried in a TNAuthList extension , established by the authority responsible for those entries, such as a numbering authority, responsible provider, or service provider code authority. TNAuthList authority token: a signed assertion of TNAuthList authority 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 authority in which the entries are telephone numbers, representing authorization for an entity to use those numbers. Domain identifier: a DNS domain name controlled by the certificate subject, carried in a SubjectAltName dNSName entry . Bound certificate: a STIR certificate issued under this document, carrying a co-validated TNAuthList and domain identifier.

Overview of the Binding A bound certificate asserts a single composite fact: the entity that controls the domain identifier in the certificate is the same entity that holds the TNAuthList authority in the certificate. 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 authority: the subject presents a TNAuthList authority token attesting authorization for the telephone numbers or service provider codes, validated by the issuing CA against the authority responsible for that token. 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 authority 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. Either challenge is sufficient on its own. The choice follows existing ACME practice and is operational. 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 authority as explicit signals, and depends on, rather than specifies, the entity verification they rest on.

Phase 2: TNAuthList authority The subject obtains a TNAuthList authority token from the authority responsible 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 authority credential from another and combine them itself, a relying party would have no assurance that the same entity legitimately held both. Requiring the CA to validate both before issuing makes the certificate a first-party attestation that the binding was verified, not merely asserted. 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 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 authority, nor one that carries TNAuthList authority 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. Reuse of a prior TNAuthList authority token validation is NOT permitted; a token MUST be validated for each issuance. 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 controlled by the subject. 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 authority. 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.

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 example-comms.net, 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 exampleretail.com is the same entity that holds the right-to-use for the telephone number 12015550100. 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, in addition to the STIR certificate validation procedures defined in and , MUST apply the following. The relying party MUST validate the certificate chain to a trusted STIR trust anchor. The relying party MUST treat the domain identifier in the SubjectAltName dNSName entry as the identity of the entity holding the TNAuthList authority in the certificate only when the certificate is valid under the above checks. The domain identifier carries this meaning by virtue of the issuance binding; a relying party MUST NOT infer TNAuthList authority 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.

Security Considerations The security of the binding depends on the issuing CA performing both validations within a single issuance. The central guarantee is that a relying party need not trust the subject's self-assertion of either domain control or TNAuthList authority; it relies instead on the CA having validated both and bound them in a single issued certificate. An issuer that issued a certificate carrying a domain identifier without a correspondingly validated TNAuthList authority, or vice versa, would defeat the guarantee; the requirements in this document prohibit such issuance. Domain control validation establishes control at the time of issuance and does not by itself attest to the legal identity of the organization controlling the domain. As described in , the broader entity verification that establishes the entity-to-domain association is performed under the CA's certificate policy and is out of scope for this document. The binding reflects the state validated at the time of issuance. Its currency over time is maintained by reissuance rather than by ongoing monitoring: each issuance re-checks domain control and requires a freshly validated TNAuthList authority token, and short-lived certificates as described in bound the interval over which a stale, mistaken, or compromised binding remains usable. The lifecycle of the underlying entity-to-domain association on which domain control rests is maintained under the CA's certificate policy, as described in . The reuse of a recent domain control validation permitted in the issuance requirements widens, by the reuse window, the interval between domain control being demonstrated and the binding being issued. CAs SHOULD keep this window short consistent with their policy.

IANA Considerations This document has no IANA actions. It relies on certificate extensions and token mechanisms registered by the documents it references.

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