]> 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 legitimate 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 SCTs and how they are used in certificates and its specific use as part of the larger STIR framework for call authentication. This framework is defined for the specific use with both 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 and the concept of 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 transparency append-only 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 browser and web PKI environments, but provides a specific framework designed for STI certificates and their specific issuance and usage in a telecommunications and telephone number dependent eco-system. 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 service provider codes 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.

Terminology This section defines key terms used throughout the STI-CT framework to ensure clarity and consistency.

Authentication Service (AS) A service that signs the identity of a telephone call using Secure Telephone Identity (STI) certificates, ensuring the authenticity of the caller information. It ensures that STI Certificates contain SCTs.

Certificate Transparency (CT) A framework designed to provide an open and verifiable log of issued certificates. It aims to detect and prevent the misuse or mis-issuance of certificates by maintaining append-only logs that can be audited by any interested party.

Delegate Certificate A type of STI certificate that associates a specific telephone number or a range of telephone numbers with a particular entity used to delegate the right to use these numbers.

Log An append-only, cryptographically verifiable structure used in Certificate Transparency to record pre-certificate entries. Logs accept submissions, generate Signed Certificate Timestamps (SCTs), and maintain the integrity of the entries through a Merkle Tree structure.

Merkle Tree A cryptographic data structure used in logs to ensure the integrity and consistency of the entries. It is built by hashing individual log entries and combining them into a single root hash that represents the state of the entire log.

Precertificate A certificate issued by an CA that is intended to be submitted to a Certificate Transparency log before the final certificate is issued. The pre-certificate includes a special extension (the poison extension) that prevents it from being used as a valid certificate on its own.

Signed Certificate Timestamp (SCT) A data structure provided by a Certificate Transparency log in response to a pre-certificate submission. The SCT serves as a promise from the log to include the submitted pre-certificate in the log within a specified time frame (Maximum Merge Delay). It is included in the final certificate to prove that it has been logged.

STI Certification Authority (STI-CA) An entity responsible for issuing STI certificates in the Secure Telephone Identity ecosystem. The CA can also issue pre-certificates, which are submitted to CT logs before the final certificate is issued.

STI Subordinate Certification Authority (STI-SCA) An entity authorized by an CA to issue STI certificates under the authority of the STI-CA. The STI-SCA can also issue pre-certificates for submission to CT logs.

Signed Tree Head (STH) A cryptographically signed data structure that represents the current state of a Certificate Transparency log. It includes the root hash of the Merkle Tree and the number of entries in the log, allowing auditors to verify the integrity and consistency of the log.

TBSCertificate (To Be Signed Certificate) A component of an X.509 certificate that contains all the information about the certificate except the actual digital signature. The TBSCertificate includes fields such as the version, serial number, issuer, validity period, subject, and the subject's public key information. This component is signed by the certificate authority (CA) to create the final certificate. In the context of Certificate Transparency, the TBSCertificate of a pre-certificate is submitted to the log for inclusion.

Verification Service (VS) A service that verifies the authenticity of a telephone call by checking the validity of the PASSporT token, including verification that certificate contains valid SCTs.

STI Certificate Transparency Framework This section describes the format and operational procedures for logs in the STI Certificate Transparency (CT) framework.

Log Entries Logs in the STI CT framework are append-only structures that store entries in a Merkle Tree and use SHA-256 for data hashing. The entries consist of pre-certificates submitted by STI Certification Authorities (STI-CAs) or Subordinate Certification Authorities (STI-SCAs). The log entries help ensure that all issued STI certificates can be audited for legitimacy.

Precertificate Submission An STI-CA/STI-SCA submits a pre-certificate to a log before the actual STI certificate is issued. The pre-certificate submission must include all necessary intermediate certificates to validate the chain up to an accepted root certificate. The root certificate may be omitted from the submission. When a pre-certificate is submitted:

• The log verifies the chain of the pre-certificate up to a trusted root.
• If valid, the log generates and returns a Signed Certificate Timestamp (SCT) to the submitter.
• The SCT serves as a promise from the log that the pre-certificate will be included in the Merkle Tree within a defined Maximum Merge Delay (MMD).

Logs must publish a list of accepted root certificates, which aligns with those trusted in the STIR ecosystem. The inclusion of SCTs in the actual STI certificates is critical, as Verification Services (STI-VS) will only accept certificates that include valid SCTs.

Log Entry Structure Each log entry consists of the following components: ; struct { ASN.1Cert pre_certificate; ASN.1Cert precertificate_chain<0..2^24-1>; } PrecertChainEntry; ]]>

• pre_certificate: The pre-certificate submitted for auditing.
• precertificate_chain: A chain of certificates required to verify the pre-certificate, including intermediate certificates but excluding the root certificate.

Logs may impose a limit on the length of the certificate chain they will accept. The log verifies the validity of the pre-certificate chain up to an accepted root and, upon acceptance, stores the entire chain for future auditing.

Structure of the Signed Certificate Timestamp (SCT) The SCT is a data structure returned by the log when a pre-certificate is accepted. It is structured as follows:

• sct_version: The version of the SCT protocol, set to v1.
• id: The SHA-256 hash of the log's public key.
• timestamp: The timestamp of the SCT issuance.
• signed_entry: Contains the PreCert structure, which includes the issuer's key hash and the TBSCertificate component of the pre-certificate.
• extensions: Placeholder for future extensions.

The SCT is included in the final STI certificate, and VS services will check the presence and validity of SCTs to verify the legitimacy of the certificate.

Merkle Tree Structure Logs use a Merkle Tree structure, with each leaf corresponding to a MerkleTreeLeaf entry. The leaves are hashed to form the tree, which is continuously updated as new entries are added.

• version: The protocol version, set to v1.
• leaf_type: The type of the leaf, set to timestamped_entry.
• timestamped_entry: Contains the timestamp and the pre-certificate data.

The root hash of the Merkle Tree represents the state of the log at a given time and can be used to verify the inclusion of specific entries.

Signed Tree Head (STH) The log periodically signs the root of the Merkle Tree, producing a Signed Tree Head (STH), which ensures the integrity of the log over time.

• timestamp: The current time, ensuring it is more recent than the most recent SCT.
• tree_size: The number of entries in the Merkle Tree.
• sha256_root_hash: The root hash of the Merkle Tree.

Logs must produce an STH within the Maximum Merge Delay (MMD) to confirm that all SCTs issued have been incorporated into the Merkle Tree. Auditors and monitors can use the STH to verify that the log is operating correctly and that no entries have been tampered with.

STI-CT APIs This section outlines the API operations that clients of the STI-CT will use to interact with the logs. The APIs are designed to support the submission and verification of pre-certificates (precerts) within the STIR ecosystem. All operations are conducted over HTTPS and utilize JSON for data exchange. These APIs are based on RFC 6962, which defines the Certificate Transparency protocol. The APIs are designed to be specific for STIR ecosystem certificates.

Add Pre-certificate Chain to Log Endpoint:

• POST https://<log server>/stict/v1/add-pre-chain

Inputs:

• chain: An array of base64-encoded certificates representing the pre-certificate chain. The first element is the end-entity pre-certificate (TBSCertificate), and subsequent elements are certificates that chain up to a known root certificate.

Outputs:

• sct_version: The version of the Signed Certificate Timestamp (SCT) structure, in decimal. For this version, it should always be 1.
• id: The log ID, base64 encoded. This is the identifier for the log server that processed the submission.
• timestamp: The SCT timestamp, in decimal, representing the time when the SCT was issued.
• extensions: An opaque field reserved for future use. Currently, logs should set this to an empty string.
• signature: The SCT signature, base64 encoded, which is used to verify the SCT.

This endpoint allows an STI-CA or STI-SCA to submit a pre-certificate chain to the log for transparency. Upon submission, the log returns an SCT, which should be included in the final STI certificate before it is issued.

Retrieve Latest Signed Tree Head Endpoint:

• GET https://<log server>/stict/v1/get-sth

Inputs:

• No inputs required.

Outputs:

• tree_size: The number of entries in the log, in decimal.
• timestamp: The timestamp of the latest Signed Tree Head (STH), in decimal.
• sha256_root_hash: The SHA-256 hash of the root of the Merkle Tree, base64 encoded.
• tree_head_signature: A signature of the STH data, ensuring its integrity.

This endpoint retrieves the latest state of the log, represented by the Signed Tree Head, which can be used by clients to verify that entries have been properly incorporated into the log.

Retrieve Merkle Consistency Proof between Two Signed Tree Heads Endpoint:

• GET https://<log server>/ct/v1/get-sth-consistency

Inputs:

• first: The tree size of the first STH, in decimal.
• second: The tree size of the second STH, in decimal.

Outputs:

• consistency: An array of base64-encoded Merkle Tree nodes that provide a consistency proof between the two STHs.

This endpoint allows clients to verify that the log has been consistently maintained over time, by checking the consistency proof between two STHs.

Retrieve Merkle Audit Proof from Log by Leaf Hash Endpoint:

• GET https://<log server>/stict/v1/get-proof-by-hash

Inputs:

• hash: A base64-encoded SHA-256 hash of the leaf.
• tree_size: The size of the tree for which the proof is desired, in decimal.

Outputs:

• leaf_index: The 0-based index of the corresponding log entry.
• audit_path: An array of base64-encoded Merkle Tree nodes providing the audit proof.

This endpoint retrieves a Merkle audit proof, which can be used to verify that a particular entry is included in the log, ensuring that the log is append-only and that the SCT is valid.

Retrieve Entries from Log Endpoint:

• GET https://<log server>/stict/v1/get-entries

Inputs:

• start: The 0-based index of the first entry to retrieve, in decimal.
• end: The 0-based index of the last entry to retrieve, in decimal.

Outputs:

• entries: An array of objects, each containing:
• leaf_input: The base64-encoded MerkleTreeLeaf structure.
• extra_data: The base64-encoded unsigned data related to the log entry. For a pre-certificate entry, this will include the entire PrecertChainEntry.

This endpoint allows clients to retrieve a range of entries from the log, which can be used to verify the integrity of the log and audit the inclusion of specific entries.

Retrieve Accepted Root Certificates Endpoint:

• GET https://<log server>/stict/v1/get-roots

Inputs:

• No inputs required.

Outputs:

• certificates: An array of base64-encoded root certificates that are accepted by the log.

This endpoint provides a list of root certificates that the log accepts for verifying certificate chains.

Retrieve Entry and Merkle Audit Proof Endpoint:

• GET https://<log server>/stict/v1/get-entry-and-proof

Inputs:

• leaf_index: The index of the desired entry, in decimal.
• tree_size: The size of the tree for which the proof is desired, in decimal.

Outputs:

• leaf_input: The base64-encoded MerkleTreeLeaf structure.
• extra_data: The base64-encoded unsigned data related to the log entry, similar to the output in get-entries.
• audit_path: An array of base64-encoded Merkle Tree nodes providing the audit proof.

This endpoint is typically used for debugging or for in-depth verification of specific entries in the log.

Clients This section describes various roles clients of STI-CT perform. Any inconsistency detected by clients could serve as evidence that a log has not behaved correctly, and the signatures on the data structures prevent the log from denying any misbehavior.

Submitters (STI-CA/STI-SCA) Submitters in the STI-CT framework are typically STI Certification Authorities (STI-CAs) or Subordinate Certification Authorities (STI-SCAs). These entities submit pre-certificates to the log as described in the APIs section. The returned Signed Certificate Timestamp (SCT) can then be used to construct the final STI certificate, which includes one or more SCTs.

AS/VS Clients AS and VS services interact with SCTs and the underlying logs to ensure the authenticity and validity of telephone calls.

• AS: The Authentication Service should use valid certificates that contain SCT(s). The SCT(s) can be validated by computing the signature input from the SCT data as well as the certificate and verifying the signature using the corresponding log's public key. AS MUST reject SCTs whose timestamps are in the future.
• VS: The Verification Service receives the signed PASSporT token and verifies that the included SCTs in the certificate used to sign the PASSporT. VS MUST reject Certificates that do not have valid SCT(s) and fail PASSporT validation.

Monitor Monitors in the STI-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: * 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. * Configure the Monitor with a list of telephone numbers (TNs) and associated entities to track.
2. Retrieve Latest STH: * The Monitor retrieves the latest Signed Tree Head (STH) from each log to determine the current state of the log. * API Call: GET https://<log server>/stict/v1/get-sth
3. Retrieve New Entries from Log: - Using the STH, the Monitor retrieves new entries from the log that have been added since the last known state. - API Call: GET https://<log server>/stict/v1/get-entries?start=last_known_index&end=current_sth_index
4. Decode and Verify Certificates: - 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: - 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: - If a mis-issuance is detected, raise an alarm and log the details for further investigation. Notify relevant stakeholders to rectify any confirmed mis-issuance.
7. Maintain State and Continuity: - Update the Monitor's last known state with the current STH index to ensure continuity in monitoring.
8. STH Verification and Consistency Check: - After retrieving a new STH, verify the STH signature. - If not keeping all log entries, fetch a consistency proof for the new STH with the previous STH (GET https://<log server>/stict/v1/get-sth-consistency) and verify it. - Go to Step 5 and repeat the process.

Auditor Auditors are responsible for verifying the consistency and correctness of the log, ensuring that the log behaves according to the expected protocol. Auditors can operate as standalone services or as part of another client role, such as a monitor or an VS.

Auditor Functions

1. STH Verification: - Auditors can fetch STHs periodically and verify their signatures to ensure the log is maintaining its integrity. - API Call: GET https://<log server>/stict/v1/get-sth
2. Consistency Proof Verification: - Auditors verify the consistency of a log over time by requesting a consistency proof between two STHs. - API Call: GET https://<log server>/stict/v1/get-sth-consistency
3. Audit Proof Verification: - A certificate accompanied by an SCT can be verified against any STH dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle audit proof. - API Call: GET https://<log server>/stict/v1/get-proof-by-hash
4. Cross-Checking Logs: - Auditors can cross-check entries across different logs by comparing SCTs and verifying that entries are consistently logged across the ecosystem.
5. Error and Inconsistency Detection: - Any discrepancies or failures in verification processes can be logged as evidence of potential log misbehavior, and appropriate actions can be taken based on the findings.

Security Considerations TODO Security

IANA Considerations None at this time.

Normative References This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate 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. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. 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. 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 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.