Proposed updates to delegate certificate standards

What’s happening with delegate certificates and STIR/SHAKEN? This article reviews how they’re to be used and previews proposed updates to the standard. Let’s have a look.

A delegate certificate refresher

Here are a few key points to understand about delegate certificates:

  1. Delegate certificates are used to by non-SHAKEN entities to demonstrate the caller’s authority to use the calling number.
  2. Delegate certificates are used to sign either base or RCD (Rich Call Data) PASSporTs.
    1. Delegate certificates must not be used to sign SHAKEN PASSporTs.
    2. If a SHAKEN PASSporT were signed with a delegate certificate, then the SHAKEN verification must fail.
  3. A SHAKEN-authorized provider may optionally use a base or RCD PASSporT it finds in the call, signed with a delegate certificate, as justification for providing full A-level attestation in a SHAKEN PASSporT it is creating for the call. But it does not have to. The signing provider may either ignore the base/RCD PASSporT or consider it along with other factors, such as:
    1. Identity of the customer
    2. Number of delegation levels
    3. The reputation of an identity in the certification path.
  4. When a SHAKEN-authorized provider signs a call, it shall discard the base PASSporT and not forward it with the call.
    1. However, if an RCD PASSporT was provided by the non-SHAKEN entity, signed with a delegate certificate, then the SHAKEN-authorized provider has the option to either include the RCD PASSporT with the call along with the SHAKEN PASSporT it creates or include the RCD claims from the RCD PASSporT in the SHAKEN PASSporT it creates and discard the RCD PASSporT. (This is explained in ATIS-1000094, the standards document for Rich Call Data.)

Delegate Certificates Bring Information into the SHAKEN Ecosystem

Delegate certificate call flow

Figure 1. Delegate Certificate Call Flow

Figure 1 illustrates a call flow for a situation where the authorized SHAKEN signer does not have an authenticated relationship between the caller and the calling telephone number. Maybe the non-SHAKEN entity got that telephone number from another provider. The authorized SHAKEN signer would therefore sign the call with either B- or C-level attestation.

In this scenario, the non-SHAKEN entity (e.g., an enterprise or Business Process Outsourcing agency calling on behalf of enterprise customers) could originate its calls with either a base or RCD PASSporT, signed with a delegate certificate, to demonstrate the caller’s authority to use the calling number.

With the base/RCD PASSporT, signed with a delegate certificate, the authorized SHAKEN signer has the option to provide full A-level attestation in the SHAKEN PASSporT it’s creating. But they don’t have to. The standards give the signing provider the flexibility to completely ignore the delegate certificate or consider it along with other factors to decide the attestation level.

Full details are available in ATIS-1000092 (ZIP file), the ATIS Standard on Signature-based Handling of Asserted information using toKENs (SHAKEN): Delegate Certificates.

Delegate certificate proposed updates

Delegate certificates must specify the authorized telephone number or numbers. This is called a TNAuthList. In simpler cases, the TNAuthList might contain one or more single telephone numbers or one or more telephone number ranges.

The biggest proposed change to ATIS-1000092 is adding support for the TNAuthList to be managed in an external OCSP (Online Certificate Status Protocol) service.

If the TNAuthList is large, the telephone number service provider (TNSP), acting as a subordinate Certification Authority (SubCA), may wish to manage TNAuthLists separately, outside of the delegate certificates it issues. In this case, the TNSP/SubCA puts the TNAuthList in an external OCSP service and provides a reference to this information in the delegate certificates it issues.

When a SHAKEN-authorized provider verifies the base/RCD PASSporT and delegate certificate and finds a reference to an OCSP, it queries the OCSP service to determine whether the delegate certificate is authorized for the calling telephone number.

Support for externally managed TNAuthLists and the OCSP query method would improve the scalability of delegate certificate usage for large enterprises and their voice service providers.

Delegate certificate status and usage

The standards are approved. The STI Governance Authority has approved delegate certificate usage. The STI Policy Administrator is ready.

We are not aware of delegate certificates being used widely in production at this time. However, we anticipate that this will change as voice service providers respond to market demand from their enterprise customers who are keen to use delegate certificates.

We should point out that delegate certificate use is optional. At this time, usage will be driven by market forces, not regulatory mandate. It will be interesting to see how this unfolds.

delegate concept

TransNexus solutions

TransNexus is a leader in developing innovative software to manage and protect telecommunications networks. The company has over 20 years’ experience in providing telecom software solutions including toll fraud prevention, robocall mitigation and prevention, TDoS prevention, analytics, routing, billing support, STIR/SHAKEN and SHAKEN certificate services.

Contact us today to learn more.

Request information

* required

This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.

Updated on September 29, 2022, to mention the option to either include RCD claims in the SHAKEN PASSporT or send both the SHAKEN PASSporT and the RCD PASSporT with the call.