Numeracle, Inc. (“Numeracle”) hereby files these reply comments to the Federal Communications Commission’s (“FCC” or “Commission”) Further Notice of Proposed Rulemaking in the above-captioned proceedings.1
I. Executive Summary
Numeracle, in its original comments, advocated for the Commission to provide guidance to create best practices to accurately identify the calling party associated with the authorized number when the originating voice service provider does not have the ability to provide A level attestation. There were several comments addressing the important and necessary role of originating and intermediate voice service providers to implement rigorous policies to sign calls with A attestation to reduce large volume of C attestations.
Various commenters addressed the attestation challenge for enterprises and referenced the use of delegated certificates. There is overwhelming support for the Commission to insist the STIR/SHAKEN governance authority incorporate protocols to securely and accurately identity enterprise calls within the structure of the call authentication framework.
Proposals for addressing the enterprise challenge have been identified and researched by the ATIS SIP Forum IPNNI Joint Task Force. Some commenters indicated existing innovation to address these solutions and therefore the enterprise challenge does not create an undue hardship on the implementation of STIR/SHAKEN.
Numeracle requests the Commission to maintain the established timelines and insist the STIR/SHAKEN Governance Authority incorporate protocols to securely and accurately identity enterprise calls to maintain the integrity of the call authentication framework.
II. The Complex Scenarios Posed By Enterprises Do Not Create an Undue Hardship on the Implementation of STIR/SHAKEN
Enterprise call scenarios, as it relates to implementation of STIR/SHAKEN, is not a reason to consider extensions for deployment of STIR/SHAKEN by voice service providers or intermediate providers. There is a fundamental misunderstanding among commenters as it relates to the enterprise challenge. One commenter stated the enterprise challenge creates an undue hardship on implementing STIR/SHAKEN2. The challenges related to complex enterprise scenarios does not create an undue hardship on originating voice service providerswhen implementing STIR/SHAKEN.
The challenge posed by enterprise calls is two-fold: 1) How is the enterprise’s identity verified and associated with their authorized number?; and 2) How is this number and identity securely provided to the originating service provider to assign full attestation when signing the call?.
According to the SHAKEN Standard on assigning attestation levels, the voice service provider must establish a policy to decide what constitutes “legitimate right to assert a telephone number”. The standard goes so far to also state the reputation of the voice service provider may be impacted by how rigorous of a policy is defined and implemented.3
Numeracle requests the Commission require originating voice service providers to implement STIR/SHAKEN within the time period and to encourage the establishment of rigorous local policies for asserting the information obtained to sign a call in support of authenticated caller ID information.
III. The Commission Should Insist the STIR/SHAKEN Governance Authority Incorporate Protocols to Securely and Accurately Identity Enterprise Calls Within the Structure of the Call Authentication Framework
Numeracle, in its original comments, presented how most enterprise calls will be signed with a C level attestation using base SHAKEN standard implementation. Some commenters identified the concern of inundated C level attestations4due to the voice service providers inability to assert to the identity or number authorization. Multiple requests for Commission involvement in setting best practices and protocols for enterprise A level attestations5 demonstrates the need for a STIR/SHAKEN standard to be defined.
Continuing from Numeracle’s original comments, the below diagrams expand uponDelegated Certificate and Central Telephone Number Database (Central Database) from the ATIS SIP Forum IPNNI Joint Task Force, Study of Full Attestation Alternatives for Enterprises6.
a. Base SHAKEN Deployment for Enterprise
Figure 1 shows the structure and relationship between the STI-Governance Authority (ATIS7), STI-Policy Administrator, STI-Certificate Authority (e.g. TransNexus8) and an originating service provider (e.g. Verizon). In this framework, there is only one STI-GA, one STI-PA and multiple STI-CA and originating service providers. The STI-GA’s mission is to ensure the integrity of the issuance, management, security and use of STI certificates in compliance with SHAKEN. The STI-GA also oversees and manages the operations of the STIPA (iConectiv9).10 The STI-PA is responsible for approving STI-CA’s and issuing SPCTokens to originating service providers (OSP). The OSP will use the SPC Token to obtain a certificate from the STI-CA of their choice. When an originating service provider signs all originating calls from their network with their certificate, calls terminating on multiple service providers can easily be traced back to the originating service provider. Essentially, bad actor operating as originating service providers will be quickly identified for corrective measures to be taken.
Based on SHAKEN standards, the originating service provider will establish a rigorous policy to identify the entity of the caller and authorization for the use of the number to sign with A attestation.
Utilizing either the Central Database or Delegate Certificate, the originating service provider can access the number and identity information to provide A level attestation. Both approaches advocate for a “Know You Customer” (KYC) process on the identity of the caller and a process for the authorized use of the telephone number.
b. Central Telephone Number Database for A Level Attestation for Enterprise Calls
For the Central Database to be used by the originating service provide as a source for number and identity assertion, the Enterprise will be vetted by the Central Database operator and then submit numbers to be associated with the enterprise for outbound dialing. The Central Database operator will obtain verification from the telephone number provider as to the enterprise’s authority to use the number. The originating service provider can assert a SHAKEN “A” attestation level through a data dip to the Central Database at the time the call is originated.
The information to be asserted in the Central Database model is outside the STI governance authority model. According to the Study of Full Attestation Alternatives for Enterprises, the Central Database model could include multiple databases11 much like CNAM databases for terminating carriers. Multiple CNAM (name and number) registries incentivizes poor data to be sold to service providers to offer a competitive lower rate. This approach, while a plausible workaround, is not aligned with the TRACED Act’s objective to provide subscribers with trusted authenticated caller identification information.
c. Delegate Certificate for A Level Attestation for Enterprise Calls
Figure 1 represents the base STIR/SHAKEN framework to vouch for caller ID information sharing through the use of digital “certificates” issued through a neutral governance process.12 The Delegate Certificate model utilizes x.50913 and existing caller authentication framework to extend the asserted information to the originating voice service provider in a secure and trusted manner.
Building on the existing role and responsibility of the STI-PA, SPC Tokens are issued to an approved Subordinate-CA. Using the SPC Token, the Subordinate-CA obtains a CA certificate. This trust model allows for the telephone number provider to issue an end entity delegate certificate to the originating service provider. With sharing validated information, the originating service provider can assert to the entity and number authorization of the enterprise call.
The value of delegated certificates is based on real-time data at origination of call, integrity of asserted information, traceback support and oversight. Delegated Certificate leverages the existing STIR/SHAKEN governance for approvals and revocation ofSubordinate-CA’s. Several commenters supported the use of Delegate Certificates14.
The Commission should ensure that as industry deploys STIR/SHAKEN, the needs of legal callers to establish A level attestation despite the lack of a simple one-to-one relationship with an originating voice service provider should be to the same security standard ofSTIR/SHAKEN certificates. The Commission should encourage the standards body to act swiftly on approving enterprise attestation standards.
Founder & CEO
P.O. Box 2523
Arlington, VA 22202
1. Call Authentication Trust Anchor, Report and Order and Further Notice of Proposed Rulemaking, FCC 20-42 (rel.March 31, 2020) (“Order” or “Notice”).
2. AT&T Comments - WC Docket Nos. 17-97 and 20-67 at 16-20 (filed May 15, 2020).
3. See ATIS & SIP Forum, Joint ATIS/SIP Forum Standard—Signature-Based Handling of Asserted InformationUsing toKENs (SHAKEN), ATIS-1000074, at 4 (2017), https://access.atis.org/apps/group_public/download.php/46770/ATIS-1000074-E.zip § 5.2.3.A. (“SHAKEN Attestation Standard”).
4. Verizon Comments - WC Docket Nos. 17-97 and 20-67 at 9-10 (filed May 15, 2020); INCOMPAS Comments - WC Docket Nos. 17-97 and 20-67 at 16-20 (filed May 15, 2020).
5. Cloud Communications Alliance - WC Docket Nos. 17-97 and 20-67 at 3-5 (filed May 15, 2020); INCOMPAS Comments - WC Docket Nos. 17-97 and 20-67 at 10-11 (filed May 15, 2020); Securus Technologies, Inc. - WCDocket Nos. 17-97 and 20-67 at 4 (filed May 18, 2020).
6. ATIS SIP Forum IPNNI Joint Task Force, Study of Full Attestation Alternatives for Enterprises and Business Entities with Multi-Homing and Other Arrangements, Draft § 8 (2019) (“Study of Full Attestation”).
10. Secure Telephone Identity – Governance Authority (STI-GA) Operating Procedures, (September 24, 2019).
11. Study of Full Attestation at 16 (March 30, 2020).
12. The STIR/SHAKEN credentials are based on an X.509 credential system. X.509 is a specific standard for a typeof public key infrastructure system that uses certificates to facilitate secure Internet communications. See generally.
13. IETF, Internet x.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC5280 (2008), https://tools.ietf.org/html/rfc5280.
14. Cloud Communications Alliance - WC Docket Nos. 17-97 and 20-67 at 3-5 (filed May 15, 2020); INCOMPAS Comments - WC Docket Nos. 17-97 and 20-67 at 10-11 (filed May 15, 2020); Securus Technologies, Inc. - WCDocket Nos. 17-97 and 20-67 at 4 (filed May 18, 2020); See Ex Parte Letter from Beth Choroser, Comcast, Corp., toMarlene H. Dortch, FCC, CG Docket No. 17-59 and 20-67 (May 12, 2020).