]> Somos, Inc.

US chris@appliedbits.com

Somos, Inc.

US robjsliwa@gmail.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, in a manner that allows anyone to audit STI certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is establish a level of trust in the STI eco-system that verification of calls would required and refuse to honor STI certificates that do not appear in a log, effectively forcing STI CAs to add all issued certificates to the logs, establishing trust that STI certificates are unique to the authorized provider or assignee of a telephone number resource. The primary role of certificate transparency in the STI ecosystem is the avoidance of issuance of unauthorized or duplicate provider level certificates or, of particular importance, telephone number level delegate certificates. This provides a robust mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers. 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 misissued certificates by providing append-only logs of issued certificates. The logs do not themselves prevent misissuance, but they ensure that interested parties (particularly those named in certificates or certificate chains) can detect such misissuance. This general mechanism that could also be used for transparently logging metadata associations via JWTClaimConstraints defined in and or potentially other ways defined in future extensions of this document. 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 the direct use of the same fundamental protocols and processes of certificate transparency but applies them to 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 globally unique 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 public representation of the creation of certificates in order for the eco-system of interested parties to provide a publicly verifiable log of certificates created by Certification Authorities to protect against misissuance of certificates that may be misrepresenting information. There is three primary actors in the certificate transparency framework. There is the STI certification authorities that submit all created certificates to logs, this could be to one or more log services. The log services are network services that implement the protocol operations for submissions of STI certificates and queries. They are hosted by interested parties in the STI ecosystem and can accept certificate log submissions from any other CA participant. Monitors play the role of monitoring the CT logs to check for potential misissuance. This role can be played by any STI ecosystem participant that is interested in the trust of the ecosystem. The details that follow in this document will try to provide a high level overview of the use of Certificate Transparency for STI certificates. It will provide high level details with assumptions that the details of the use of Merkel Tree and API interfaces largely follow protocols and only when there is specific details and differences to will that be defined normatively.

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 Each log contains certificate chains, which can be submitted by anyone. It is expected that STI CAs will contribute all their newly issued certificates to one or more logs; however, it is possible for certificate holders can also directly contribute their own certificate chains, as can interested third parties. In order to avoid logs being rendered useless by the submission of large numbers of spurious certificates, it is required that each chain ends with a trust anchor that is accepted by the log. A log may also limit the length of the chain it is willing to accept; such chains must also end with an acceptable trust anchor. When a chain is accepted by a log, a signed timestamp is returned, which can later be 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 once certificate transparency is well established in the ecosystem to maintain trust. Those who are concerned about misissuance of provider or TN-based delegate certificates can monitor the logs, asking them regularly for all new entries, and can thus check whether domains 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 misissuance 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 misissued 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 ). The submitter SHOULD validate the returned SCT, as described in Section 8.1 of , if they understand its format and they intend to use it to construct an STI certificate.

Certificates Any entity can submit a certificate (Section 5.1 of ) to a log. Since it is anticipated that STIR 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 Merkle Tree of submitted certificate entries. Log procedures MUST follow log format and operation procedures defined in Section 4 of . Author note: Do we need a separate IANA registry for Log OIDs specific to STI eco-system?

Log Client Messages Log Client Messages and API MUST follow same protocols, formats and procedures as described in Section 5 of Author Note: I don't believe this is any parallel to TLS servers directly participating in CT in the STI world

STI Certification Authorities The Transparency Information X.509v3 extension including rules of inclusion in OCSP responses MUST follow descriptions and procedures defined in Section 7 of .

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.

STI Verification Service

Receiving SCTs and Inclusion Proofs STI Verification Services receive SCTs and inclusion proofs in certificates.

Reconstructing the TBSCertificate Validation of an SCT for a certificate (where the type of the TransItem is x509_sct_v2) uses the unmodified TBSCertificate component of the certificate.

Validating SCTs In order to make use of a received SCT, the STI Verification Service MUST first validate it as follows: Compute the signature input by constructing a TransItem of type x509_entry_v2, depending on the SCT's TransItem type. The TimestampedCertificateEntryDataV2 structure is constructed in the following manner: timestamp is copied from the SCT. tbs_certificate is the reconstructed TBSCertificate portion of the server certificate, as described in Section 8.1.2 of . issuer_key_hash is computed as described in Section 4.7 of . sct_extensions is copied from the SCT. Verify the SCT's signature against the computed signature input using the public key of the corresponding log, which is identified by the log_id. The required signature algorithm is one of the log's parameters. If the STI Verification Service does not have the corresponding log's parameters, it cannot attempt to validate the SCT. When evaluating compliance (see Section 8.1.6 of ), the STI Verification Service will consider only those SCTs that it was able to validate. Note that SCT validation is not a substitute for the normal validation of the server certificate and its chain.

Fetching Inclusion Proofs When a STI Verification Service has validated a received SCT but does not yet possess a corresponding inclusion proof, the STI Verification Service MAY request the inclusion proof directly from a log using get-proof-by-hash (Section 5.4 of ) or get-all-by-hash (Section 5.5 of ).

Validating Inclusion Proofs When a STI Verification Service has received, or fetched, an inclusion proof (and an STH), it SHOULD proceed to verify the inclusion proof to the provided STH. The STI Verification Service SHOULD also verify consistency between the provided STH and an STH it knows about. If the STI Verification Service holds an STH that predates the SCT, it MAY, in the process of auditing, request a new STH from the log (Section 5.2 of ) and then verify it by requesting a consistency proof (Section 5.3 of ). Note that if the STI Verification Service uses get-all-by-hash, then it will already have the new STH.

Evaluating Compliance It is up to a client's local policy to specify the quantity and form of evidence (SCTs, inclusion proofs, or a combination) needed to achieve compliance and how to handle noncompliance.

Monitor Monitors watch logs to check for correct behavior, for certificates of interest, or for both. For example, a monitor may be configured to report on all certificates that apply to a specific domain name when fetching new entries for consistency validation. A monitor MUST at least inspect every new entry in every log it watches, and it MAY also choose to keep copies of entire logs.

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 This document has no IANA actions, yet.

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.