]> Somos, Inc.

US chris@appliedbits.com

Somos, Inc.

US robjsliwa@gmail.com

TransNexus

US alec.fenichel@transnexus.com

Twilio

US vanilgaikwad@twilio.com

Applications and Real-Time Secure Telephone Identity Revisited stir certificates delegate certificates 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). About This Document 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 Certificate Transparency (CT) aims to mitigate the problem of mis-issued certificates by providing append-only logs of issued certificates. The logs do not themselves prevent mis-issuance, but ensure that interested parties (particularly those named in certificates or certificate chains) can detect such mis-issuance. describes the core protocols and mechanisms for use of CT for the purposes of public TLS server certificates associated with a domain name as part of the public domain name system (DNS). This document describes a conceptually similar framework that directly borrows concepts like transparency receipts in the form of SCPs but also is more opinionated about the process and procedures for when the receipt is generated and how it is used outside of the certificate. This framework is defined for the specific use with Secure Telephone Identity (STI) certificates and delegate certificates . Telephone numbers (TNs) and their management and assignment by telephone service providers and Responsible Organizations (RespOrgs) for toll-free numbers share many similarities to the Domain Name System (DNS) where there is a global uniqueness and established association of telephone numbers to regulatory jurisdictions that manage the allocation and assignment of telephone numbers under country codes and a set of numeric digits for routing telephone calls and messages over telephone networks. STI Certificates use a TNAuthList extension defined in to specifically associate either telephone service providers or telephone numbers to the issuance of STI certificates and certificate change that are intended to represent the authorized right to use a telephone number. This trusted association can be establish via mechanisms such as Authority tokens for TNAuthList defined in . Certificate transparency is generally meant to provide a publicly verifiable and auditable representation of the creation of certificates in order to establish transparency and trust to interested parties as part of a stir related eco-system. There is three primary actors in the certificate transparency framework. There is the STI Certification Authorities (CAs) that submit all certificates to be issued to one or more log services. The log services are network services that implement the protocol operations for submissions of STI certificates and subsequent queries. They are hosted by interested parties in the STI ecosystem and can accept certificate log submissions from any other CA participant. The second role is the monitors that play the role of monitoring the CT logs to check for potential mis-issuance as well as auditing of the log services. This role can be played by any STI ecosystem participant interested in the trust of the ecosystem or the integrity of the telephone number or provider level certificates produced in the eco-system. CT provides a mechanism of a receipt or Signed Certificate Timestamp (SCT) that is provided as a result of submitting a certificate to the append-only log. The third actor role in the certificate transparency framework is the eco-system participants that can send and receive receipt(s) or SCT(s) to prove and validate that a certificate was submitted to a log(s) and optionally query the log directly for further validation. The details that follow in this document will detail the specific protocols and framework for Certificate Transparency associated with STI certificates. Most of the details borrow many of the concepts of certificate transparency defined in used in Web PKI environments, but provides a specific framework designed for STI certificates and their specific issuance and usage in a telecommunications environments. This general mechanism could also be used for transparently logging other important stir related metadata associations perhaps via JWTClaimConstraints defined in and or other ways defined in potential future extensions of this document.

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 Use of Certificate Transparency for STI Certificates CT log(s) contains certificate chains, which can be submitted by any CA authorized in a STIR eco-system. It is expected that these CAs will contribute all their newly issued certificates to one or more logs. Note, in it is possible for certificate holders to directly contribute their own certificate chains or interested third parties, however because in stir eco-systems that generally consist of entities that are authorized to be assigned telephone number resources, this does not seem to be a likely scenario. Generally, many stir eco-systems have a controlled set of CAs that are authorized to participate as valid trust anchors. It is required that each chain ends with a trust anchor that is accepted by the log which would include those authorized trust anchors or a subset of them. When a chain is accepted by a log, a signed timestamp is returned, which is later used to provide evidence to STIR verification services (VS), defined in , that the chain has been submitted. A VS can thus require that all certificates they accept as valid are accompanied by signed timestamps. Those concerned about mis-issuance of stir certificates can monitor the logs, asking them regularly for all new entries, and can thus check whether the providers or telephone numbers for which they are responsible have had certificates issued that they did not expect. What they do with this information, particularly when they find that a mis-issuance has happened, is beyond the scope of this document. However, broadly speaking, because many existing STI ecosystems have a connection to regulated and industry environments that govern the issuance of STI certificates, they can invoke existing mechanisms for dealing with issues such as mis-issued certificates, such as working with the CA to get the certificate revoked or with maintainers of trust anchor lists to get the CA removed.

Submitters Submitters submit certificates to logs for public auditing. In order to enable attribution of each logged certificate to its issuer, each submission MUST be accompanied by all additional certificates required to verify the chain up to an accepted trust anchor. The trust anchor (a root or intermediate CA certificate) MAY be omitted from the submission. If a log accepts a submission, it will return a Signed Certificate Timestamp (SCT) (see Section 4.8 ).

Certificates Any entity, generally a STIR CA, can submit defined certificates or defined delegate certificates or similarly defined STIR certificates to a log. Since it is anticipated that verification services could reject certificates that are not logged, it is expected that certificate issuers and subjects will be strongly motivated to submit them.

Log Format and Operation A log is a single, append-only, merkel-tree type of log of submitted certificate entries. Log procedures are RECOMMENDED to follow similar procedures and formats defined in Section 4 of , but in general only are required to follow the API interfaces defined in this document.

STIR Authentication Services STIR Authentication Services MUST present one or more SCTs from one or more logs by the inclusion of an array of SCTs as a 'sct' claim in the signed PASSporT defined in the next section of this document.

PASSporT Claim "sct" Definition and Usage This document defines a new JSON Web Token claim for "sct", Signed Certificate Timestamp, the value of which is a JSON object that can contains an array of one or more Signed Certificate Timestamps defined in , Section 4.8 corresponding to SCTs provided by different CT logs the certificate may have been submitted to. Example PASSporT with SCT Claim:

Clients There are various different functions clients of logs might perform. In this document, the client generally refers to the STI verification service defined in , or more generally an entity that performs the verification of a PASSporT defined in . We describe here some typical clients and how they should function.

Submission and Handling of SCTs

1. STI-CA/STI-SCA Submits STI Certificate to Transparency Logs Step 1: The STI Certificate Authority (STI-CA) or STI Subordinate Certificate Authority (STI-SCA) issues a new STI certificate. Step 2: The STI-CA/STI-SCA submits the issued STI certificate to one or more transparency logs using the 'submit-entry' API. /ct/v2/submit-entry Content-Type: application/json { "submission": "base64-encoded-sti-certificate", "type": 1, "chain": [ "base64-encoded-CA-cert-1", "base64-encoded-CA-cert-2" ] } Expected Response: { "sct": "base64-encoded-sct", "sth": "base64-encoded-signed_tree_head", "inclusion": "base64-encoded-inclusion_proof" } ]]>
2. Transparency Log Generates SCT: Step 3: Each transparency log processes the submission and generates a Signed Certificate Timestamp (SCT). Step 4: The transparency log returns the SCT to the STI-CA/STI-SCA.
3. STI-CA/STI-SCA Passes SCT(s) to STI-AS: Step 5: The STI-CA/STI-SCA passes the generated SCT(s) to the STI Authentication Service (STI-AS). This can be done via a non-prescriptive method such as including SCT(s) in the certificate issuance metadata or through a separate communication channel.
4. STI-AS Includes SCTs in sct Claim: Step 6: The STI-AS includes the SCTs in the sct claim of the PASSporT (Personal Assertion Token) when signing a call identity. Step 7: If some logs are slow to respond, their SCTs may be skipped to ensure timely processing.
5. STI-VS Verifies PASSporT and SCTs: Step 8: The STI Verification Service (STI-VS) receives the signed PASSporT from the STI-AS. Step 9: The STI-VS verifies that the PASSporT contains matching SCTs for the certificate it was signed with. The STI-VS checks for the presence of SCT(s) and trusts them for quick verification. Step 10: In the background, a separate process can periodically gather and verify the SCTs with the transparency logs to ensure their validity and integrity.

Example API Calls for Step-by-Step Flow

1. Submit Entry to Log: /ct/v2/submit-entry Content-Type: application/json { "submission": "base64-encoded-sti-certificate", "type": 1, "chain": [ "base64-encoded-CA-cert-1", "base64-encoded-CA-cert-2" ] } ]]>
2. Retrieve Latest STH (optional for background process): /ct/v2/get-sth Expected Response: { "sth": "base64-encoded-signed_tree_head_v2" } ]]>
3. Retrieve Merkle Inclusion Proof by Leaf Hash (optional for background process): /ct/v2/get-proof-by-hash?hash=base64-encoded-hash &tree_size=tree-size Expected Response: { "inclusion": "base64-encoded-inclusion_proof_v2", "sth": "base64-encoded-signed_tree_head_v2" } ]]>
4. Retrieve Entries and STH from Log (optional for background process): /ct/v2/get-entries?start=0&end=99 Expected Response: { "entries": [ { "log_entry": "base64-encoded-log-entry", "submitted_entry": { "submission": "base64-encoded-sti-certificate", "chain": [ "base64-encoded-CA-cert-1", "base64-encoded-CA-cert-2", "base64-encoded-trust-anchor-cert" ] }, "sct": "base64-encoded-sct" } ], "sth": "base64-encoded-signed_tree_head_v2" } ]]>

Monitor Monitors in the STIR/SHAKEN Certificate Transparency (CT) framework play a crucial role in maintaining the integrity and trust of the ecosystem. They ensure that no certificates are mis-issued, particularly concerning the TNAuthList field, which lists the telephone numbers an entity is authorized to use.

Monitor Workflow

1. Initialize Monitor: Step 1: Set up the Monitor to periodically query the transparency logs for new entries. The Monitor must be configured with the base URL of each log it intends to monitor. Step 2: Configure the Monitor with a list of telephone numbers (TNs) and associated entities to track.
2. Retrieve Latest STH: Step 3: The Monitor retrieves the latest Signed Tree Head (STH) from each log to determine the current state of the log. /ct/v2/get-sth Expected Response: { "sth": "base64-encoded-signed_tree_head_v2" } ]]>
3. Retrieve New Entries from Log: Step 4: Using the STH, the Monitor retrieves new entries from the log that have been added since the last known state. /ct/v2/get-entries?start=last_known_index &end=current_sth_index Expected Response: { "entries": [ { "log_entry": "base64-encoded-log-entry", "submitted_entry": { "submission": "base64-encoded-sti-certificate", "chain": [ "base64-encoded-CA-cert-1", "base64-encoded-CA-cert-2", "base64-encoded-trust-anchor-cert" ] }, "sct": "base64-encoded-sct" } ], "sth": "base64-encoded-signed_tree_head_v2" } ]]>
4. Decode and Verify Certificates: Step 5: Decode each retrieved certificate and verify its validity using the provided certificate chain. Extract the entity name and TNAuthList from the certificate.
5. Check for Mis-issuance: Step 6: Compare the TNAuthList and entity name from the newly issued certificate with the Monitor's configured list. Alarm if a certificate is issued in the name of a different entity for the same TNs.
6. Alarm and Reporting: Step 7: If a mis-issuance is detected, raise an alarm and log the details for further investigation and notify relevant stakeholders to rectify any confirmed mis-issuance.
7. Maintain State and Continuity: Step 8: Update the Monitor's last known state with the current STH index to ensure continuity in monitoring.

Auditing Auditing ensures that the current published state of a log is reachable from previously published states that are known to be good and that the promises made by the log, in the form of SCTs, have been kept. Audits are performed by monitors or STI Verification Services.

Security Considerations TODO Security

IANA Considerations

JSON Web Token Claim This document requests that the IANA add three new claims to the JSON Web Token Claims registry as defined in . Claim Name: "sct" Claim Description: Signed Certificate Timestamp Change Controller: IESG Specification Document(s): [RFCThis]

Normative References JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. 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. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. 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. 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.

Acknowledgments The authors would like to thank the authors and contributors to the protocols and ideas around Certificate Transparency which sets the basis for the STI eco-system to adopt in a very straight forward way, providing trust and transparency in the telephone number world.