draft-wendt-stir-cert-tn-attr-ext — TN Attribute Certificate Extension for STI Certificates

draft-wendt-stir-cert-tn-attr-ext defines a certificate extension in which the holder of an STI certificate declares things about its own telephone numbers. I co-author it with Rafał Śliwa of Somos. Individual draft, Standards Track intent.

I’m writing this draft, so the framing here is from inside the work.

The idea

A STIR certificate, including a delegate certificate under RFC 9060, says its holder was validated as authorized for the numbers in its TNAuthList. That makes the holder the one party whose statements about those numbers can be trusted without any further authority: a statement that only describes or constrains the holder’s own numbers grants nothing to anyone else. The draft calls this the self-assertion principle, and it is the test for what the extension may carry.

The worst an incorrect or malicious declaration can do is degrade service to the holder’s own numbers. A declaration cannot expand the holder’s authority, confer authority on a third party, or speak for a resource the holder does not control. A relying party must not read any attribute as extending or modifying the certificate’s scope of number authority. Attributes that would grant authority or enable a capability belong in a token-gated mechanism instead.

The extension

id-pe-tnAttributes is a non-critical X.509 v3 extension for end-entity STI certificates and delegate certificates whose TNAuthList names specific telephone numbers. It carries one or more typed attributes. Attributes apply only to the telephone-number entries in the TNAuthList, not to SPC entries, so a certificate whose TNAuthList holds only SPCs should not carry it.

A relying party that does not understand an attribute ignores it. The absence of an attribute is not an assertion, so a relying party must not infer a value, restrictive or permissive, from it. A single-valued type that appears more than once is treated as ambiguous and ignored.

The four seeded attribute types

PPS URIs (type 1). One or more HTTPS URIs for a PASSporT Placement Service: where PASSporTs for the covered numbers can be published and retrieved out of band. The PPS is the role RFC 8816 calls the Call Placement Service, renamed to avoid a collision with Certification Practice Statement. An authentication service holding a certificate with this attribute should publish out-of-band PASSporTs to one of the listed services. The draft does not specify the interface a PPS exposes.

Do not originate (type 2). Presence-only. The covered numbers do not originate calls, with voice and video treated as one channel. A call claiming one of those numbers should be treated as a blocking candidate.

Do not originate messaging (type 3). Presence-only. The same declaration for messages. A number that originates neither carries both.

Authorized originators (type 4). A set of SPCs naming the providers the holder authorizes to originate and attest communications from its numbers, across calls and messaging. A communication attested by a provider outside the set should be treated as a blocking candidate. The list confers nothing on the providers named: a listed provider’s ability to sign still comes only from its own credentials. Do-not-originate and do-not-originate-messaging each take precedence on their own channel.

Where the defense comes from

The restrictive attributes catch the cases where the holder’s certificate is not on the call: an unsigned call from a do-not-originate number, or one attested by an unauthorized provider. A relying party only gets that protection if it can retrieve the holder’s certificate by telephone number, independently of the communication it is evaluating. The draft leaves that retrieval out of scope and expects the mechanisms already used to distribute do-not-originate data to carry these attributes too.

The certificate stays the authoritative source. A distribution mechanism should convey the signed certificate with the data so a relying party can verify each attribute itself; a compromised distribution layer can then suppress attributes but not forge them. Certificate transparency logs let distributors observe new declarations as certificates are issued.

This is what separates it from the list-based Do Not Originate model. A DNO list entry is data a list operator holds; here the declaration is signed by the holder’s own validated credential, and a list becomes one way of distributing it. The authorized-originators attribute carries the same declaration as the DNO+ framework, inside the certificate.

Lifecycle

Declarations reflect the holder’s intent at issuance. Changing one means issuing a new certificate, and the change reaches relying parties only once the new certificate has propagated. Short-lived certificates are recommended for that reason, since they bound how long a stale declaration stays in use.

Security and privacy

Trust rests on the certificate having been validated for the numbers at issuance and on the relying party validating the chain to a STIR trust anchor before acting. The residual risk is misissuance: a certificate issued without proper validation for the numbers carries declarations that should not be trusted, and that validation belongs to the CA and the certificate profile. Published declarations reveal how a number is used, which the draft treats as within what TNAuthList already exposes.

Status

draft-wendt-stir-cert-tn-attr-ext-00 (6 July 2026), individual draft. Per the individual-draft convention used across this library, my own individual drafts get entries. Current revision and state on the IETF datatracker.