Secure Telephone Identity Credentials: Certificates
updated by
- rfc-9118 — Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates
Extracted elements (30)
Certificate freshness for STIR may be handled either by short-lived certificates (front-end burden on enrollment) or by online status protocols like OCSP (back-end burden on verification); no single mechanism is mandated, as implementation experience is needed to determine the optimal approach.
RSA PKCS #1 v1.5 is mandated only as a transitional mechanism due to its widespread use in existing PKIs; the long-term expectation is that ECDSA with P-256 will be the sole required algorithm as RSA support is eventually deprecated.
The TN Authorization List may be provided by reference (via id-ad-stirTNList AIA URI) rather than by value in the certificate itself, to prevent certificate bloat for large service providers who may control millions of telephone numbers.
Three enrollment models are described: top-down (CA acts with national numbering authorities), bottom-up (CA verifies control via an automated or manual test such as an SMS challenge), and delegation (certificate holders delegate authority to other parties, analogous to name constraints in hierarchical PKI).
Two non-exclusive approaches to asserting telephone number authority in certificates are defined: using the certificate subject (domain name or SPC) with an external data set to correlate numbers, and embedding the TN Authorization List extension directly in the certificate. Either approach is compatible with the STIR over-the-wire format in RFC 8224.
JWT Claim Constraints baseline claims ('iat', 'orig', 'dest') are considered permitted by default and SHOULD NOT be included in mustInclude; if the extension is absent entirely, these three claims MUST appear in every PASSporT the certificate signs.
The TNAuthorizationList inside the application/tnauthlist media type MUST be DER-encoded; this interoperability constraint applies to all consumers of TN Authorization Lists fetched via the id-ad-stirTNList AIA mechanism.
A CA that wishes to place constraints on JWT claims MUST include the JWT Claim Constraints certificate extension in issued certificates.
All certificates compliant with this specification MUST provide cryptographic keying material sufficient to generate ECDSA using P-256 and SHA-256 signatures (ES256) as required by PASSporT (RFC 8225).
For implementations compliant with this specification, three URI schemes are REQUIRED in the SIP Identity header 'info' parameter: the CID URI, the SIP URI, and the HTTP URI.
Future specifications that define certificate freshness mechanisms for STIR MUST note any privacy risks (per RFC 7258) associated with acquiring online status information and provide countermeasures where possible.
Implementations are REQUIRED to support SIP (via SUBSCRIBE/NOTIFY) as well as HTTP and HTTPS for dereferencing the Identity header 'info' parameter URI to acquire credentials.
Implementations MUST support both ECDSA with the P-256 curve and RSA PKCS #1 v1.5 for certificate signatures. RSA PKCS #1 v1.5 is mandated only as a transitional mechanism and is anticipated to be eventually deprecated.
In a TelephoneNumberRange, the count field MUST NOT make the number increase in length; formally, given TelephoneNumber of length D, TelephoneNumber + count MUST be less than 10^D.
In the JWT Claim Constraints extension, mustInclude indicates claims that MUST appear in the PASSporT in addition to iat, orig, and dest; if mustInclude is absent, iat, orig, and dest MUST appear in the PASSporT.
In the JWT Claim Constraints extension, permittedValues indicates that if the claim name is present in the PASSporT, the claim MUST contain one of the listed permitted values.
This specification RECOMMENDS distribution of private keys through PKCS #8 objects signed by a trusted entity, for example through the CMS package specified in RFC 5958.
Verifiers MUST support the AIA extension; the dereferenced URI from a CA certificate limits the set of TNs for certification paths that include that certificate.
When the id-ad-stirTNList accessMethod is used, the accessLocation MUST be an HTTPS URI; dereferencing it returns the complete DER-encoded TN Authorization List with Content-Type application/tnauthlist.
Acquiring online certificate status information (e.g., via OCSP) has the potential to disclose private information per RFC 7258; future freshness specifications MUST identify such risks and provide countermeasures.
The id-ad-stirTNList AIA accessMethod (OID id-ad 14) allows a verifier to fetch the complete DER-encoded TN Authorization List for a certificate by dereferencing an HTTPS URI embedded in the certificate's AIA extension.
The JWT Claim Constraints extension (id-pe-JWTClaimConstraints, OID id-pe 27) is a non-critical, end-entity certificate extension that constrains the JWT claims an authentication service may include in PASSporT objects it signs.
The TN Authorization List (TNAuthList) is an X.509 certificate extension (id-pe-TNAuthList, OID id-pe 26) that lists the telephone numbers, number ranges, or Service Provider Codes (SPCs) over which a certificate subject has authority.
IANA registered id-pe-TNAuthList (arc 26) and id-pe-JWTClaimConstraints (arc 27) in the 'SMI Security for PKIX Certificate Extension' registry (1.3.6.1.5.5.7.1), and id-ad-stirTNList (arc 14) in the 'SMI Security for PKIX Access Descriptor' registry.
IANA registered the 'application/tnauthlist' media type for DER-encoded TNAuthorizationList objects, used by issuers and relying parties of secure telephone identity certificates.
The TN Authorization List returned via a dereferenced AIA URI is served over HTTPS but is not itself a signed object; the server is trusted to faithfully return the list provided by the list generator, introducing a trust dependency on the server.
The TNAuthList extension can divulge to relying parties extraneous telephone numbers associated with a certificate, especially when AIA is used to link thousands of numbers to a single certificate; the SPC in a certificate can also be used to identify the carrier. Short-lived per-TN certificates are suggested as a privacy-preserving alternative.
JWTClaimConstraints is a SEQUENCE with optional mustInclude [0] (JWTClaimNames, a SEQUENCE OF IA5String) and optional permittedValues [1] (JWTClaimPermittedValuesList), with a constraint that at least one of the two components MUST be present.
TelephoneNumber is encoded as IA5String SIZE (1..15) restricted to the character set '0123456789#*'. TelephoneNumberRange is a SEQUENCE of start (TelephoneNumber) and count (INTEGER 2..MAX).
TNAuthorizationList is a SEQUENCE SIZE (1..MAX) OF TNEntry, where each TNEntry is a CHOICE among spc [0] (ServiceProviderCode, an IA5String), range [1] (TelephoneNumberRange), or one [2] (TelephoneNumber).