Secure Telephone Identity Revisited (STIR) Certificate Delegation
Extracted elements (26)
Delegation is needed because enterprises and other non-carrier entities place outbound calls through service providers that do not control the numbering resources being attested. Without delegation, outbound carriers would sign calls with credentials not covering the originating number, which is indistinguishable from malicious spoofing and erodes STIR trust.
Encompassing validation is designed to occur at certificate issuance time rather than (or in addition to) call-setup verification time, because certificate issuance is an administrative function outside call processing, whereas verification occurs during call setup where extra network dips cause perceptible delay.
Longer certification paths (via intermediate CA certificates) are the only currently defined mechanism to preserve information about which service provider owned the telephone numbers; a non-delegated certificate issued directly by the trust anchor CA would lose that provider attribution.
STIR uses a rigid hierarchical subordination model for certification path validation rather than allowing relying parties to derive their own paths, simplifying verification services that need only follow the chain supplied in 'x5u'.
TLS delegated credentials (TLS subcerts) are identified as a potential alternative architecture if CA policies prevent issuing intermediate certificates with the cA boolean and TNAuthList. Specification of a STIR analogue is deferred as future work pending market need.
'x5u' is preferred over 'x5c' for certificate chain delivery because operational STIR deployments already use 'x5u', making 'x5c' a disruptive change with no clear benefit in the existing ecosystem.
ACME returns an 'application/pem-certificate-chain' object suitable for direct publication as an HTTPS resource accessible via the PASSporT 'x5u' mechanism, aligning certificate acquisition and delivery workflows.
Entities receiving telephone numbers from multiple carriers may need to maintain a 'STIR keyring' of delegate certificates from different providers and different CAs, selecting the appropriate certificate per call. Cross-certification via AIA or a bridge CA could simplify this but would require further specification.
Authentication services creating a PASSporT signed with a delegate certificate MUST provide an 'x5u' link corresponding to the entire certification path rather than just the delegate certificate.
Authentication services SHOULD NOT use a delegate certificate without validating that its scope of authority is encompassed by that of its parent certificate, and if that certificate has its own parent, the entire certification path SHOULD be validated.
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'. This mirrors RPKI 'encompassing' semantics.
If certificates acquired from the 'x5u' element do not lead to a trusted anchor, the verification service MAY return a 437 'Unsupported Credential' SIP response if the call should be failed for lack of a valid Identity header.
Implementations SHOULD continue to use the 'x5u' element rather than 'x5c' for delivering certification paths in STIR, since 'x5u' is already established in operational practice. 'x5c' is OPTIONAL for environments where it is known to be supported.
The certificate path ordering in the PEM certificate chain MUST be ordered from the signer to the trust anchor, beginning with the certificate used to sign the PASSporT.
The key identifier in the Authority Key Identifier extension in each certificate MUST appear in the Subject Key Identifier extension in the next certificate, and this pairing MUST match throughout the entire chain.
When the verification service dereferences the 'x5u' parameter and acquires a certificate list, it MUST validate all of the credentials in the list, identifying the parent certificate for each delegate through its Authority Key Identifier extension.
A STIR certificate identifying a narrow telephone number range exposes information about the entities placing calls. However, since the TN range is a necessary superset of the calling party number already openly signaled in call setup, the privacy risks are not substantially greater than baseline STIR.
A STIR delegate certificate is an X.509v3 certificate containing a TNAuthList extension, signed by the private key of a parent certificate that also contains a TNAuthList. The parent MUST have a basic constraints extension with the cA boolean set to 'true', and every delegate certificate MUST include a standard Authority Key Identifier extension identifying its parent.
A TNAuthList may be included by reference rather than by value, where a URL in the certificate points to a dynamically updated list of telephone numbers. Certification path construction treats by-reference TNAuthLists as if included by value.
ACME (RFC 8555) is the anticipated mechanism for acquiring delegate certificates. An entity requests an Authority Token from the parent with the desired TNAuthList; if further subdelegation is intended, the token request should include the 'ca' Authority Token flag.
Delegate certificates MAY themselves carry a basic constraints cA boolean of 'true', enabling further subdelegation. A CA-capable delegate that wants to sign PASSporTs must create a separate end-entity certificate with a TNAuthList equal to or a subset of its own.
Service providers can use ACME STAR (RFC 8739) to issue short-lived, automatically renewed delegate certificates, enabling rapid aging out of delegated credentials without relying on revocation infrastructure.
The TNAuthList of a STIR certificate may contain SPCs, telephone number ranges, or a mix of both. Permission semantics are additive: the certificate's scope is the superset of all enumerated SPCs and TN ranges.
By-reference TNAuthLists allow the authority scope of a certificate to change over time. If the HTTPS service hosting the by-reference list is improperly secured, it introduces vulnerabilities. Relying parties may accept a number at one point and reject it later as the dynamic list changes.
Security of the delegation model depends critically on enforcement of 'encompassing' semantics. When delegating from an SPC-based TNAuthList to telephone number ranges, verifying encompassing may require access to industry numbering databases that may not exist in all operating environments; how this is policed is left to operational profiles.
When a delegate certificate is used, the 'x5u' PASSporT element contains a URI pointing to a concatenation of PEM-encoded certificates of media type 'application/pem-certificate-chain' (defined in RFC 8555), ordered from signer to trust anchor.