STIR delegate certificates are certificates containing a TNAuthList object that have been signed with the private key of a parent certificate that itself contains a TNAuthList object (either by value or by reference; see Section 4.1
). The parent certificate needs to contain a basic constraints extension with the cA boolean set to "true" [RFC 5280
], indicating that the subject can sign certificates. Every STIR delegate certificate identifies its parent certificate with a standard Authority Key Identifier extension [RFC 5280
The authority bestowed on the holder of the delegate certificate by the parent certificate is recorded in the delegate certificate's TNAuthList. Because STIR certificates use the TNAuthList object rather than the Subject Name for indicating the scope of their authority, traditional name constraints [RFC 5280
] are not directly applicable to STIR. In a manner similar to the [RFC 6480
] "encompassing" semantics, each delegate certificate MUST
have a TNAuthList scope that is equal to or a subset of its parent certificate's scope: it must be "encompassed". For example, a parent certificate with a TNAuthList that attested authority for the numbering range +1-212-555-1000 through 1999 could issue a certificate to one delegate attesting authority for the range +1-212-555-1500 through 1599 and, to another delegate, a certificate for the individual number +1-212-555-1824.
Delegate certificates MAY
also contain a basic constraints extension with the cA boolean set to "true", indicating that they can sign subordinate certificates for further delegates. As only end-entity certificates can actually sign PASSporTs, the holder of a STIR certificate with a "true" cA boolean may create a separate end-entity certificate with either an identical TNAuthList to its parent or a subset of the parent's authority, which would be used to sign PASSporTs.
The TNAuthList of a STIR certificate may contain one or more SPCs, one or more telephone number ranges, or even a mix of SPCs and telephone number ranges. When delegating from a STIR certificate, a child certificate may inherit from its parent either or both of the above, and this specification explicitly permits SPC-only parent certificates to delegate individual telephone numbers or ranges to a child certificate, as this will be necessary in some operating environments. Depending on the sort of numbering resources that a delegate has been assigned, various syntaxes can be used to capture the delegated resource.
Some non-carrier entities may be assigned large and complex allocations of telephone numbers, which may be only partially contiguous or entirely disparate. Allocations may also change frequently in minor or significant ways. These resources may be so complex, dynamic, or extensive that listing them in a certificate is prohibitively difficult. Section 10.1
of RFC 8226
describes one potential way to address this: including the TNAuthList (specified in [RFC 8226
]) in the certificate by reference rather than by value, where a URL in the certificate points to a secure, dynamically updated list of the telephone numbers in the scope of authority of a certificate. For entities that are carriers in all but name, another alternative is the allocation of an SPC; this yields much the same property, as the SPC is effectively a pointer to an external database that dynamically tracks the numbers associated with the SPC. Either of these approaches may make sense for a given deployment. Certification path construction as detailed below treats by-reference TNAuthLists in a certificate as if they had been included by value.
Other non-carrier entities may have straightforward telephone number assignments, such as enterprises receiving a set of a thousand blocks from a carrier that may be kept for years or decades. Particular freephone numbers may also have a long-term association with an enterprise and its brand. For these sorts of assignments, assigning an SPC may seem like overkill, and using the TN ranges of the TNAuthList (by value) is sufficient.
Whichever approach is taken to represent the delegated resource, there are fundamental trade-offs regarding when and where in the architecture a delegation is validated -- that is, when the delegated TNAuthList is checked and determined to be "encompassed" by the TNAuthList of its parent. This might be performed at the time the delegate certificate is issued, at the time that a verification service receives an inbound call, or potentially both. It is generally desirable to offload as much of this as possible to the certification process as verification occurs during call setup; thus, additional network dips could lead to perceptible delay, whereas certification happens outside of call processing as a largely administrative function. Ideally, if a delegate certificate can supply a by-value TN range, then a verification service could ascertain that an attested calling party number is within the scope of the provided certificate without requiring any additional transactions with a service. In practice, verification services may already incorporate network queries into their processing (for example, to dereference the "x5u" field of a PASSporT) that could piggyback any additional information needed by the verification service.
Note that the permission semantics of the TNAuthList [RFC 8226
] are additive: that is, the scope of a certificate is the superset of all of the SPCs and telephone number ranges enumerated in the TNAuthList. As SPCs themselves are effectively pointers to a set of telephone number ranges, and a telephone number may belong to more than one SPC, this may introduce some redundancy to the set of telephone numbers specified as the scope of a certificate. The presence of one or more SPCs and one or more sets of telephone number ranges are similarly treated additively, even if the telephone number ranges turn out to be redundant to the scope of an SPC.