]> Somos Inc.

chris@appliedbits.com

Somos Inc.

robjsliwa@gmail.com

Applications and Real-Time Secure Telephone Identity Revisited stir certificates delegate certificates tn attributes do not originate This document specifies a non-critical X.509 v3 certificate extension that conveys a set of self-asserted attributes describing the telephone numbers identified in the certificate's TNAuthList. The attributes are declared by the holder of the certificate about its own telephone numbers and require no separate authority token, because they describe or constrain only those numbers and grant no authority to any other party. The extension defines an extensible framework with an IANA registry of attribute types and seeds that registry with four types: a PASSporT Placement Service (PPS) URI, a do-not-originate indication, a do-not-originate-messaging indication, and a set of authorized originating providers. Relying parties use these self-declarations as policy signals, treating communications that do not conform to them as candidates for blocking. The mechanism is backward compatible with existing STIR certificates. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Telephone Identity Revisited Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The STIR (Secure Telephone Identity Revisited) framework provides a means of cryptographically asserting authority over the telephone numbers used in a communication, using PASSporTs carried in SIP requests as defined in and , signed with certificates that carry a TNAuthList extension . A certificate, including a delegate certificate , attests that its holder has been validated as authorized for the telephone numbers in its TNAuthList. The holder of such a certificate is therefore in a unique position to make verifiable statements about those same telephone numbers. Because the certificate already establishes the holder's right to use the numbers, statements the holder makes about how those numbers are used, or about which providers may originate communications from them, are trustworthy self-assertions: they describe or constrain the holder's own numbers and grant no authority to any other party. This document defines a certificate extension that carries such self-asserted attributes, so that relying parties can obtain the number holder's own declarations about a number and apply them as policy signals. These attributes are not authoritative in the sense of enabling a service or conferring a capability. They are transparent declarations of the number holder's intent. A relying party that obtains them can recognize communications that do not conform to the holder's declared intent, for example a call that purports to originate from a number the holder has declared never originates calls, and treat such communications as candidates for blocking. The defending value of an attribute therefore comes from a relying party being able to retrieve it, keyed by telephone number, and act on it. These attributes express the number holder's intent regarding outbound origination from the covered telephone numbers, and they are evaluated within the STIR trust framework. STIR identity information, carried as PASSporTs signed with STIR certificates and conveyed for example in a SIP Identity header field or, for messaging, as described in , is the means by which conformance to that intent is attested for outbound voice and messaging from a telephone number. The scope of these attributes therefore follows the scope of STIR itself, rather than any particular service or transport: a service that adopts STIR to attest origination from a telephone number participates in this framework and inherits these attributes, whether it is carried over interconnected networks or is otherwise proprietary. A service that does not use STIR is not evaluated under it. Because each attribute describes only the holder's own telephone numbers and grants nothing to anyone else, no authority token is required to assert it. This distinguishes the attributes defined here from the authority recorded in the TNAuthList itself, which is validated at issuance and represents delegated scope. The self-asserted attributes are carried alongside that authority but are semantically separate from it: a relying party MUST NOT interpret any attribute defined here as extending or modifying the certificate's scope of telephone number authority. This document defines the extension and an extensible IANA registry of attribute types, and seeds the registry with four types: a PASSporT Placement Service (PPS) URI, a do-not-originate indication, a do-not-originate-messaging indication, and a set of authorized originating providers. Future specifications may register additional types that meet the self-assertion criterion defined in the IANA Considerations. Note: One of the attribute types defined here carries the URI of a PASSporT Placement Service (PPS). The service defined in is named the Call Placement Service (CPS). This document refers to it as the PASSporT Placement Service (PPS). The two terms denote the same architectural role. The PPS name is used to avoid acronym collision with Certification Practice Statement (CPS) as used in and certificate policy practice, and because the service places and serves PASSporTs and is not limited to telephone calls.

Relationship to Other Specifications This document defines a certificate extension data format. It is designed to compose with the broader STIR ecosystem: defines the TNAuthList extension that records the authority over which these attributes are asserted, and defines delegate certificates that carry such authority. defines the Out-of-Band (OOB) architecture and the PASSporT Placement Service concept, which it names the Call Placement Service (CPS). The PPS URI attribute defined here points to such a service. describes a service-provider OOB deployment model and the possibility of embedding placement service information in STIR certificates. defines STI Certificate Transparency logs, which are one mechanism by which certificates carrying this extension may be observed. Retrieval of these attributes keyed by telephone number is out of scope for this document. Mechanisms for distributing and querying do-not-originate information by telephone number are already deployed, and the same distribution and query mechanisms are expected to carry the attributes defined here. In all cases the certificate is the authoritative source of the attribute values, and the distribution layer conveys them; see .

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.

The id-pe-tnAttributes Certificate Extension This extension is an X.509 v3 certificate extension, profiled for the Internet PKI by . It is non-critical, applicable only to end-entity certificates, and defined later in this section with ASN.1 using the PKIX ASN.1 modules of . The extension is intended for use in end-entity STI certificates and delegate certificates whose TNAuthList authorizes specific telephone numbers. It carries one or more typed attributes, each a self-assertion by the certificate holder about those numbers. In this document, the telephone numbers identified in the certificate's TNAuthList are referred to as the covered telephone numbers. A TNAuthList may syntactically contain telephone number and telephone number range entries, Service Provider Code (SPC) entries, or a combination of both. The attributes defined in this document describe telephone numbers, and they apply only to the telephone number entries in the TNAuthList; they make no assertion about SPC entries. This extension is therefore intended for certificates whose TNAuthList authorizes telephone numbers. It has no effect in a certificate whose TNAuthList contains only SPC entries, and a producer SHOULD NOT include it in such a certificate.

The Self-Assertion Principle Every attribute carried in this extension is a self-assertion by the holder of the certificate about the telephone numbers in the certificate's TNAuthList. An attribute does not require an authority token, and is trustworthy without one, precisely because it describes or constrains only the holder's own telephone numbers and grants no authority, capability, or service to any other party. The worst outcome an incorrect or malicious self-assertion can produce is degradation of service to the asserting holder's own numbers. An attribute cannot expand the holder's authority, cannot confer authority on a third party, and cannot make a statement about a resource the holder does not control. Where an attribute references another party, as the authorized originating providers attribute references SPCs, that reference is a statement of the holder's own acceptance policy and confers nothing on the referenced party; the referenced party's authority, if any, derives solely from its own credentials. This principle is the inclusion criterion for the IANA registry defined in . An attribute type qualifies for registration only if it satisfies it. Attributes that would grant authority, enable a capability, or assert facts about resources outside the holder's control do not qualify and belong in a token-gated mechanism instead. The container guarantees only provenance: every attribute in it was asserted by the validated holder of the telephone numbers in the certificate. Each attribute type defines its own semantics, given in for the types defined here and in the registering specification for types added later.

ASN.1 Module Syntax The extension is identified by an object identifier (OID) assigned in the PKIX id-pe arc defined in . Its value is a sequence of one or more typed attributes. Each attribute carries an integer type, which keys into the IANA "STIR TN Attribute Types" registry (), and a value whose syntax is defined by the registration for that type. The set of types is extensible: the extension marker in the object set below permits attributes of types not defined in this module to be carried and, if unrecognized, skipped. A specification that defines a new type registers it, with its value syntax, and adds it to the object set; existing implementations that do not recognize the new type are unaffected.

Note: The numeric module and OID assignments marked TBD are temporary. IANA will allocate the permanent values during RFC publication.

Criticality The extension MUST be marked non-critical, following the certificate extension processing rules of , so that a relying party that does not recognize it can still validate the certificate. An attribute that a relying party does not understand, or whose type is not in its supported set, is ignored.

Attribute Types Each attribute type defines its value syntax and its semantics. A relying party that does not support a given type ignores it. The absence of an attribute is not an assertion: a relying party MUST NOT infer a value, restrictive or permissive, for an attribute that is not present. The restrictive attributes defined here constrain behavior only when present. Some attributes defined here are presence-only: they carry no value of their own and make their assertion simply by being present in the certificate. In the ASN.1 module such an attribute has the value syntax NULL, which conveys nothing beyond the attribute's presence. A given type SHOULD appear at most once in the extension. If a type that is defined as single-valued appears more than once, a relying party MUST treat the certificate's attribute set as ambiguous for that type and ignore that type.

PPS URIs (type 1) The value is a sequence of one or more absolute URIs , each of which: Uses the "https" scheme. Identifies a PASSporT Placement Service (PPS) for the covered telephone numbers (for example, "https://pps.example.net"). This attribute declares where PASSporTs for the covered telephone numbers may be published and retrieved out of band . The URI locates the service; the interface a PPS exposes at that location is not specified by this document and may differ between deployments. A value that is not an absolute HTTPS URI MUST cause a relying party to ignore that entry. Producers MAY include multiple URIs to express redundancy or locality; selection among them is a matter of local policy. This attribute is enabling rather than restrictive: it points a relying party to a service. It satisfies the self-assertion principle because it declares only where the holder publishes PASSporTs for its own numbers and grants nothing to any other party.

Do Not Originate (type 2) This attribute is presence-only. When present, it asserts that the covered telephone numbers do not originate calls. A call here is the STIR-attested session established for a telephone number, independent of whether it carries voice or video media. A relying party that obtains this attribute for a number, and then sees a call purporting to originate from that number, has a strong signal that the call is illegitimate and SHOULD treat it as a candidate for blocking according to local policy. Absence of the attribute is not an assertion that the number does originate calls. Note for Working Group consideration: this attribute treats a call as a single channel regardless of media. Should number-based video calling become established on the telephone network, the working group may wish to consider whether to distinguish voice from video origination through a separately registered attribute, for example a do-not-originate-video declaration, so that a holder could indicate that a number does not originate video calls specifically. This document does not make that distinction; the extensible registry defined in the IANA Considerations accommodates such a future type if a need arises.

Do Not Originate Messaging (type 3) This attribute is presence-only. When present, it asserts that the covered telephone numbers do not originate messages. A relying party that obtains this attribute for a number, and then sees a message purporting to originate from that number, has a strong signal that the message is illegitimate and SHOULD treat it as a candidate for blocking according to local policy. Absence of the attribute is not an assertion that the number does originate messages. This attribute is the messaging counterpart of the do-not-originate attribute (type 2), applying the same presence-only semantics to the messaging channel. The two are parallel per-channel signals: do-not-originate declares that the number does not originate calls, and do-not-originate-messaging declares that it does not originate messages. A number that originates neither carries both.

Authorized Originators (type 4) The value is a sequence of one or more SPCs, each identifying a provider that the holder of the telephone numbers authorizes to originate and attest communications from those numbers. A relying party that obtains this attribute, and then sees a communication from the covered number attested by a provider whose SPC is not in the set, has a signal that the origination is unauthorized and SHOULD treat it as a candidate for blocking according to local policy. The providers named apply to origination across the channels the holder's numbers support; this document does not distinguish per-channel authorized originators, and a single set applies to both calls and messaging. This attribute is a statement of the holder's acceptance policy for its own numbers. It confers no authority on the listed providers: a listed provider's ability to sign for the number derives solely from its own credentials, and a relying party MUST NOT interpret presence in this set as STIR authority of any kind. Likewise, a relying party MUST NOT interpret an SPC in this attribute as extending the certificate's own telephone number authority. Absence of this attribute imposes no origination restriction: the holder has declared no authorized-originator set, and communications may be attested by any provider as far as this attribute is concerned. The do-not-originate and do-not-originate-messaging attributes each take precedence, on their own channel, over the authorized-originators attribute. Where do-not-originate is present, the covered telephone numbers originate no calls regardless of any authorized-originators value; where do-not-originate-messaging is present, they originate no messages regardless of any authorized-originators value. The authorized-originators attribute therefore governs only origination on channels not closed by a do-not-originate signal.

Processing Rules A STIR Authentication Service that holds a certificate carrying a PPS URIs attribute SHOULD publish out-of-band PASSporTs for the covered telephone numbers to one of the indicated PPS endpoints. A relying party that has obtained a certificate carrying this extension, whether from a signed communication or by retrieval keyed to a telephone number, validates the certificate chain to a trusted STIR trust anchor before relying on any attribute. Having done so, it applies each supported attribute according to that attribute's semantics in . The restrictive attributes, do-not-originate, do-not-originate-messaging, and authorized-originators, are policy signals: a relying party SHOULD treat a communication that does not conform to a present restrictive attribute as a candidate for blocking, subject to local policy. The defending value of the restrictive attributes is realized only when a relying party can obtain them for a number independently of the communication being evaluated. The cases these attributes are designed to catch, such as an unsigned communication from a do-not-originate number or one attested by an unauthorized provider, are exactly the cases in which the holder's own certificate is not presented on the communication. In those cases the relying party obtains the attributes by retrieving the holder's certificate keyed by telephone number, by a mechanism outside the scope of this document.

Distribution and Transparency Retrieval and distribution of these attributes keyed by telephone number are out of scope for this document and are left to other specifications and to industry practice. The certificate is the authoritative, signed source of the attribute values. A relying party validates the certificate independently of how it was obtained, so trust in an attribute derives from the certificate rather than from whatever mechanism delivered it. Transparency logs provide a monitoring mechanism by which distributors can observe the attributes asserted for a telephone number as certificates are issued, and populate the authoritative information that relying parties consult. A distribution mechanism SHOULD convey the signed certificate together with the distributed information, so that a relying party can verify each attribute directly against the certificate rather than trust the distributor. Where the signed certificate is not conveyed, the relying party depends on the distribution layer for the integrity of the information. This document does not otherwise mandate a distribution mechanism.

Lifecycle Considerations The attributes reflect the holder's declarations at the time the certificate was issued. Because they are carried in the certificate, changing an attribute requires issuing a new certificate, and the change takes effect at relying parties only after the new certificate has propagated through the distribution mechanism in use. Attribute currency therefore follows certificate lifetime. Short-lived certificates bound the interval over which a stale declaration remains in use and are RECOMMENDED for this reason. This ties attribute updates to the same validated issuance path as the certificate itself, so that a declaration cannot be forged into the distribution layer.

Security Considerations The attributes defined here are self-assertions by the holder of the telephone numbers in the certificate's TNAuthList. Their trust rests on two things: the certificate having been validated at issuance as authorizing the holder for those numbers, and the relying party validating the certificate chain before acting on any attribute. A relying party MUST validate the chain to a trusted STIR trust anchor; the attribute values are not independently signed and derive their integrity from the certificate. Because each attribute describes or constrains only the holder's own telephone numbers and grants nothing to any other party, the worst outcome of an incorrect or malicious assertion is degradation of service to the asserting holder's own numbers. An attribute cannot expand the holder's authority or confer authority on a third party. In particular, the authorized-originators attribute lists SPCs as a statement of the holder's acceptance policy; it confers no STIR authority on those providers, and a relying party MUST NOT treat presence in that list as authority of any kind, nor as extending the certificate's telephone number scope. Misissuance is the relevant residual risk: a certificate that carries these attributes without the holder having been properly validated for the listed telephone numbers would carry self-assertions that should not be trusted. The validation that binds a certificate to its telephone numbers is the responsibility of the issuing CA and the certificate profile in use, and is outside the scope of this extension. The restrictive attributes defend against impersonation only when a relying party can retrieve them keyed by telephone number, independently of the communication under evaluation, as discussed in . A relying party that cannot perform such retrieval gains no protection from them against the unsigned or wrongly-attested cases. Reliance on a distribution mechanism for retrieval inherits that mechanism's availability and integrity properties; because the certificate is signed, a compromised distribution layer can suppress or withhold attributes but cannot forge them. Publication of these attributes in retrievable or publicly logged certificates may reveal deployment metadata about a number's usage. This exposure is consistent with existing STIR certificate practice and does not introduce privacy risk beyond what TNAuthList usage already entails.

IANA Considerations

TN Attributes Certificate Extension OID IANA is requested to assign an object identifier for the TN Attributes certificate extension in the "SMI Security for PKIX Certificate Extension" registry: Description: id-pe-tnAttributes Reference: (this document)

STIR TN Attribute Types Registry IANA is requested to create a new registry, "STIR TN Attribute Types", to record the integer type identifiers carried in the TN Attributes certificate extension defined in this document. Each entry records: Type: the integer identifier (the "type" field of a TNAttribute). Name: a short identifier for the attribute type. Value Syntax: the ASN.1 type of the attribute value. Reference: the defining specification. The registration policy is Specification Required . The designated expert MUST verify that a requested type satisfies the self-assertion criterion: the attribute describes or constrains only the asserting holder's own telephone numbers, grants no authority, capability, or service to any other party, and makes no assertion about a resource the holder does not control. A type that would grant authority, enable a capability, or assert facts about resources outside the holder's control does not qualify and is to be refused, as such a mechanism requires authorization beyond a self-assertion. The registry is initialized with the following entries, all defined in this document: Type Name Value Syntax Reference 1 pps-uris PPSURIs (this document) 2 do-not-originate DoNotOriginate (this document) 3 do-not-originate-messaging DoNotOriginateMessaging (this document) 4 authorized-originators AuthorizedOriginators (this document) Type value 0 is reserved.

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] 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 Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality. 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 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. 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. International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union 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. The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Personal Assertion Tokens (PASSporTs) either in-band, within the headers of a Session Initiation Protocol (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers for cases in which in-band STIR conveyance is not universally available. 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 eco-system to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is for the establishment of a level of trust in the STI eco-system that depends on the verification of telephone numbers requiring and refusing to honor STI certificates that do not appear in a established log. 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. The primary role of CT in the STI ecosystem is for verifiable trust in the avoidance of issuance of unauthorized 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 eco-system, focusing on verifiable control over telephone number or service provider code resources.

Acknowledgments TODO acknowledge.