TN Attribute Certificate Extension for STI Certificates
draft-wendt-stir-cert-tn-attr-ext-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Chris Wendt , Robert Śliwa | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | stir at IETF-126 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wendt-stir-cert-tn-attr-ext-00
Secure Telephone Identity Revisited C. Wendt
Internet-Draft R. Śliwa
Intended status: Standards Track Somos Inc.
Expires: 7 January 2027 6 July 2026
TN Attribute Certificate Extension for STI Certificates
draft-wendt-stir-cert-tn-attr-ext-00
Abstract
This document specifies a non-critical X.509 v3 certificate extension
that conveys a set of self-asserted attributes describing the
telephone numbers identified in the certificate's TNAuthList. The
attributes are declared by the holder of the certificate about its
own telephone numbers and require no separate authority token,
because they describe or constrain only those numbers and grant no
authority to any other party. The extension defines an extensible
framework with an IANA registry of attribute types and seeds that
registry with four types: a PASSporT Placement Service (PPS) URI, a
do-not-originate indication, a do-not-originate-messaging indication,
and a set of authorized originating providers. Relying parties use
these self-declarations as policy signals, treating communications
that do not conform to them as candidates for blocking. The
mechanism is backward compatible with existing STIR certificates.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://github.com/appliedbits/draft-wendt-stir-cert-tn-attr-ext.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-wendt-stir-cert-tn-attr-ext/.
Discussion of this document takes place on the Secure Telephone
Identity Revisited Working Group mailing list (mailto:stir@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/stir/.
Subscribe at https://www.ietf.org/mailman/listinfo/stir/.
Source for this draft and an issue tracker can be found at
https://github.com/appliedbits/draft-wendt-stir-cert-tn-attr-ext.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Wendt & Śliwa Expires 7 January 2027 [Page 1]
Internet-Draft TN Attribute Certificate Extension July 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship to Other Specifications . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. The id-pe-tnAttributes Certificate Extension . . . . . . . . 5
3.1. The Self-Assertion Principle . . . . . . . . . . . . . . 6
3.2. ASN.1 Module Syntax . . . . . . . . . . . . . . . . . . . 7
3.3. Criticality . . . . . . . . . . . . . . . . . . . . . . . 9
4. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. PPS URIs (type 1) . . . . . . . . . . . . . . . . . . . . 9
4.2. Do Not Originate (type 2) . . . . . . . . . . . . . . . . 10
4.3. Do Not Originate Messaging (type 3) . . . . . . . . . . . 10
4.4. Authorized Originators (type 4) . . . . . . . . . . . . . 11
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 11
6. Distribution and Transparency . . . . . . . . . . . . . . . . 12
7. Lifecycle Considerations . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. TN Attributes Certificate Extension OID . . . . . . . . . 14
9.2. STIR TN Attribute Types Registry . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Wendt & Śliwa Expires 7 January 2027 [Page 2]
Internet-Draft TN Attribute Certificate Extension July 2026
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The STIR (Secure Telephone Identity Revisited) framework provides a
means of cryptographically asserting authority over the telephone
numbers used in a communication, using PASSporTs carried in SIP
requests as defined in [RFC8224] and [RFC8225], signed with
certificates that carry a TNAuthList extension [RFC8226]. A
certificate, including a delegate certificate [RFC9060], attests that
its holder has been validated as authorized for the telephone numbers
in its TNAuthList.
The holder of such a certificate is therefore in a unique position to
make verifiable statements about those same telephone numbers.
Because the certificate already establishes the holder's right to use
the numbers, statements the holder makes about how those numbers are
used, or about which providers may originate communications from
them, are trustworthy self-assertions: they describe or constrain the
holder's own numbers and grant no authority to any other party. This
document defines a certificate extension that carries such self-
asserted attributes, so that relying parties can obtain the number
holder's own declarations about a number and apply them as policy
signals.
These attributes are not authoritative in the sense of enabling a
service or conferring a capability. They are transparent
declarations of the number holder's intent. A relying party that
obtains them can recognize communications that do not conform to the
holder's declared intent, for example a call that purports to
originate from a number the holder has declared never originates
calls, and treat such communications as candidates for blocking. The
defending value of an attribute therefore comes from a relying party
being able to retrieve it, keyed by telephone number, and act on it.
These attributes express the number holder's intent regarding
outbound origination from the covered telephone numbers, and they are
evaluated within the STIR trust framework. STIR identity
information, carried as PASSporTs [RFC8225] signed with STIR
certificates and conveyed for example in a SIP Identity header field
[RFC8224] or, for messaging, as described in [RFC9475], is the means
by which conformance to that intent is attested for outbound voice
and messaging from a telephone number. The scope of these attributes
therefore follows the scope of STIR itself, rather than any
particular service or transport: a service that adopts STIR to attest
Wendt & Śliwa Expires 7 January 2027 [Page 3]
Internet-Draft TN Attribute Certificate Extension July 2026
origination from a telephone number participates in this framework
and inherits these attributes, whether it is carried over
interconnected networks or is otherwise proprietary. A service that
does not use STIR is not evaluated under it.
Because each attribute describes only the holder's own telephone
numbers and grants nothing to anyone else, no authority token is
required to assert it. This distinguishes the attributes defined
here from the authority recorded in the TNAuthList itself, which is
validated at issuance and represents delegated scope. The self-
asserted attributes are carried alongside that authority but are
semantically separate from it: a relying party MUST NOT interpret any
attribute defined here as extending or modifying the certificate's
scope of telephone number authority.
This document defines the extension and an extensible IANA registry
of attribute types, and seeds the registry with four types: a
PASSporT Placement Service (PPS) URI, a do-not-originate indication,
a do-not-originate-messaging indication, and a set of authorized
originating providers. Future specifications may register additional
types that meet the self-assertion criterion defined in the IANA
Considerations.
Note: One of the attribute types defined here carries the URI of a
PASSporT Placement Service (PPS). The service defined in [RFC8816]
is named the Call Placement Service (CPS). This document refers to
it as the PASSporT Placement Service (PPS). The two terms denote the
same architectural role. The PPS name is used to avoid acronym
collision with Certification Practice Statement (CPS) as used in
[RFC8226] and certificate policy practice, and because the service
places and serves PASSporTs and is not limited to telephone calls.
1.1. Relationship to Other Specifications
This document defines a certificate extension data format. It is
designed to compose with the broader STIR ecosystem:
* [RFC8226] defines the TNAuthList extension that records the
authority over which these attributes are asserted, and [RFC9060]
defines delegate certificates that carry such authority.
* [RFC8816] defines the Out-of-Band (OOB) architecture and the
PASSporT Placement Service concept, which it names the Call
Placement Service (CPS). The PPS URI attribute defined here
points to such a service.
Wendt & Śliwa Expires 7 January 2027 [Page 4]
Internet-Draft TN Attribute Certificate Extension July 2026
* [RFC9888] describes a service-provider OOB deployment model and
the possibility of embedding placement service information in STIR
certificates.
* [I-D.ietf-stir-certificate-transparency] defines STI Certificate
Transparency logs, which are one mechanism by which certificates
carrying this extension may be observed.
Retrieval of these attributes keyed by telephone number is out of
scope for this document. Mechanisms for distributing and querying
do-not-originate information by telephone number are already
deployed, and the same distribution and query mechanisms are expected
to carry the attributes defined here. In all cases the certificate
is the authoritative source of the attribute values, and the
distribution layer conveys them; see Section 6.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The id-pe-tnAttributes Certificate Extension
This extension is an X.509 [X.509] v3 certificate extension, profiled
for the Internet PKI by [RFC5280]. It is non-critical, applicable
only to end-entity certificates, and defined later in this section
with ASN.1 [X.680] [X.681] [X.682] [X.683] using the PKIX ASN.1
modules of [RFC5912].
The extension is intended for use in end-entity STI certificates
[RFC8226] and delegate certificates [RFC9060] whose TNAuthList
authorizes specific telephone numbers. It carries one or more typed
attributes, each a self-assertion by the certificate holder about
those numbers. In this document, the telephone numbers identified in
the certificate's TNAuthList are referred to as the covered telephone
numbers.
Wendt & Śliwa Expires 7 January 2027 [Page 5]
Internet-Draft TN Attribute Certificate Extension July 2026
A TNAuthList [RFC8226] may syntactically contain telephone number and
telephone number range entries, Service Provider Code (SPC) entries,
or a combination of both. The attributes defined in this document
describe telephone numbers, and they apply only to the telephone
number entries in the TNAuthList; they make no assertion about SPC
entries. This extension is therefore intended for certificates whose
TNAuthList authorizes telephone numbers. It has no effect in a
certificate whose TNAuthList contains only SPC entries, and a
producer SHOULD NOT include it in such a certificate.
3.1. The Self-Assertion Principle
Every attribute carried in this extension is a self-assertion by the
holder of the certificate about the telephone numbers in the
certificate's TNAuthList. An attribute does not require an authority
token, and is trustworthy without one, precisely because it describes
or constrains only the holder's own telephone numbers and grants no
authority, capability, or service to any other party.
The worst outcome an incorrect or malicious self-assertion can
produce is degradation of service to the asserting holder's own
numbers. An attribute cannot expand the holder's authority, cannot
confer authority on a third party, and cannot make a statement about
a resource the holder does not control. Where an attribute
references another party, as the authorized originating providers
attribute references SPCs, that reference is a statement of the
holder's own acceptance policy and confers nothing on the referenced
party; the referenced party's authority, if any, derives solely from
its own credentials.
This principle is the inclusion criterion for the IANA registry
defined in Section 9. An attribute type qualifies for registration
only if it satisfies it. Attributes that would grant authority,
enable a capability, or assert facts about resources outside the
holder's control do not qualify and belong in a token-gated mechanism
instead.
The container guarantees only provenance: every attribute in it was
asserted by the validated holder of the telephone numbers in the
certificate. Each attribute type defines its own semantics, given in
Section 4 for the types defined here and in the registering
specification for types added later.
Wendt & Śliwa Expires 7 January 2027 [Page 6]
Internet-Draft TN Attribute Certificate Extension July 2026
3.2. ASN.1 Module Syntax
The extension is identified by an object identifier (OID) assigned in
the PKIX id-pe arc defined in [RFC5280]. Its value is a sequence of
one or more typed attributes. Each attribute carries an integer
type, which keys into the IANA "STIR TN Attribute Types" registry
(Section 9), and a value whose syntax is defined by the registration
for that type. The set of types is extensible: the extension marker
in the object set below permits attributes of types not defined in
this module to be carried and, if unrecognized, skipped. A
specification that defines a new type registers it, with its value
syntax, and adds it to the object set; existing implementations that
do not recognize the new type are unaffected.
TN-ATTRIBUTES-EXTN
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tn-attributes(TBD0) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
id-pe
FROM PKIX1Explicit-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ;
-- TN Attributes Certificate Extension
ext-TNAttributes EXTENSION ::= {
SYNTAX TNAttributes
IDENTIFIED BY id-pe-tnAttributes }
id-pe-tnAttributes OBJECT IDENTIFIER ::= { id-pe TBD1 }
-- Information object class binding an attribute value type
-- to its registered integer identifier
TN-ATTRIBUTE ::= CLASS {
&id INTEGER UNIQUE,
Wendt & Śliwa Expires 7 January 2027 [Page 7]
Internet-Draft TN Attribute Certificate Extension July 2026
&Type
} WITH SYNTAX { TYPE &Type IDENTIFIED BY &id }
-- The extension value: one or more typed attributes
TNAttributes ::= SEQUENCE SIZE (1..MAX) OF TNAttribute
TNAttribute ::= SEQUENCE {
type TN-ATTRIBUTE.&id ({TNAttributeTypes}),
value TN-ATTRIBUTE.&Type ({TNAttributeTypes}{@type}) }
-- Set of attribute types defined in this document.
-- Extensible via the IANA registry; the marker permits
-- types registered by other specifications.
TNAttributeTypes TN-ATTRIBUTE ::= {
tnAttr-ppsURIs |
tnAttr-doNotOriginate |
tnAttr-doNotOriginateMessaging |
tnAttr-authorizedOriginators,
... }
tnAttr-ppsURIs TN-ATTRIBUTE ::=
{ TYPE PPSURIs IDENTIFIED BY 1 }
tnAttr-doNotOriginate TN-ATTRIBUTE ::=
{ TYPE DoNotOriginate IDENTIFIED BY 2 }
tnAttr-doNotOriginateMessaging TN-ATTRIBUTE ::=
{ TYPE DoNotOriginateMessaging IDENTIFIED BY 3 }
tnAttr-authorizedOriginators TN-ATTRIBUTE ::=
{ TYPE AuthorizedOriginators IDENTIFIED BY 4 }
-- Value syntaxes for the defined types
PPSURIs ::= SEQUENCE SIZE (1..MAX) OF IA5String
DoNotOriginate ::= NULL
DoNotOriginateMessaging ::= NULL
AuthorizedOriginators ::= SEQUENCE SIZE (1..MAX) OF SPC
SPC ::= IA5String
END
Note: The numeric module and OID assignments marked TBD are
temporary. IANA will allocate the permanent values during RFC
publication.
Wendt & Śliwa Expires 7 January 2027 [Page 8]
Internet-Draft TN Attribute Certificate Extension July 2026
3.3. Criticality
The extension MUST be marked non-critical, following the certificate
extension processing rules of [RFC5280], so that a relying party that
does not recognize it can still validate the certificate. An
attribute that a relying party does not understand, or whose type is
not in its supported set, is ignored.
4. Attribute Types
Each attribute type defines its value syntax and its semantics. A
relying party that does not support a given type ignores it. The
absence of an attribute is not an assertion: a relying party MUST NOT
infer a value, restrictive or permissive, for an attribute that is
not present. The restrictive attributes defined here constrain
behavior only when present.
Some attributes defined here are presence-only: they carry no value
of their own and make their assertion simply by being present in the
certificate. In the ASN.1 module such an attribute has the value
syntax NULL, which conveys nothing beyond the attribute's presence.
A given type SHOULD appear at most once in the extension. If a type
that is defined as single-valued appears more than once, a relying
party MUST treat the certificate's attribute set as ambiguous for
that type and ignore that type.
4.1. PPS URIs (type 1)
The value is a sequence of one or more absolute URIs [RFC3986], each
of which:
* Uses the "https" scheme.
* Identifies a PASSporT Placement Service (PPS) for the covered
telephone numbers (for example, "https://pps.example.net").
This attribute declares where PASSporTs for the covered telephone
numbers may be published and retrieved out of band [RFC8816]. The
URI locates the service; the interface a PPS exposes at that location
is not specified by this document and may differ between deployments.
A value that is not an absolute HTTPS URI MUST cause a relying party
to ignore that entry. Producers MAY include multiple URIs to express
redundancy or locality; selection among them is a matter of local
policy.
Wendt & Śliwa Expires 7 January 2027 [Page 9]
Internet-Draft TN Attribute Certificate Extension July 2026
This attribute is enabling rather than restrictive: it points a
relying party to a service. It satisfies the self-assertion
principle because it declares only where the holder publishes
PASSporTs for its own numbers and grants nothing to any other party.
4.2. Do Not Originate (type 2)
This attribute is presence-only. When present, it asserts that the
covered telephone numbers do not originate calls. A call here is the
STIR-attested session [RFC8224] established for a telephone number,
independent of whether it carries voice or video media. A relying
party that obtains this attribute for a number, and then sees a call
purporting to originate from that number, has a strong signal that
the call is illegitimate and SHOULD treat it as a candidate for
blocking according to local policy. Absence of the attribute is not
an assertion that the number does originate calls.
Note for Working Group consideration: this attribute treats a call as
a single channel regardless of media. Should number-based video
calling become established on the telephone network, the working
group may wish to consider whether to distinguish voice from video
origination through a separately registered attribute, for example a
do-not-originate-video declaration, so that a holder could indicate
that a number does not originate video calls specifically. This
document does not make that distinction; the extensible registry
defined in the IANA Considerations accommodates such a future type if
a need arises.
4.3. Do Not Originate Messaging (type 3)
This attribute is presence-only. When present, it asserts that the
covered telephone numbers do not originate messages. A relying party
that obtains this attribute for a number, and then sees a message
purporting to originate from that number, has a strong signal that
the message is illegitimate and SHOULD treat it as a candidate for
blocking according to local policy. Absence of the attribute is not
an assertion that the number does originate messages.
This attribute is the messaging counterpart of the do-not-originate
attribute (type 2), applying the same presence-only semantics to the
messaging channel. The two are parallel per-channel signals: do-not-
originate declares that the number does not originate calls, and do-
not-originate-messaging declares that it does not originate messages.
A number that originates neither carries both.
Wendt & Śliwa Expires 7 January 2027 [Page 10]
Internet-Draft TN Attribute Certificate Extension July 2026
4.4. Authorized Originators (type 4)
The value is a sequence of one or more SPCs, each identifying a
provider that the holder of the telephone numbers authorizes to
originate and attest communications from those numbers. A relying
party that obtains this attribute, and then sees a communication from
the covered number attested by a provider whose SPC is not in the
set, has a signal that the origination is unauthorized and SHOULD
treat it as a candidate for blocking according to local policy. The
providers named apply to origination across the channels the holder's
numbers support; this document does not distinguish per-channel
authorized originators, and a single set applies to both calls and
messaging.
This attribute is a statement of the holder's acceptance policy for
its own numbers. It confers no authority on the listed providers: a
listed provider's ability to sign for the number derives solely from
its own credentials, and a relying party MUST NOT interpret presence
in this set as STIR authority of any kind. Likewise, a relying party
MUST NOT interpret an SPC in this attribute as extending the
certificate's own telephone number authority. Absence of this
attribute imposes no origination restriction: the holder has declared
no authorized-originator set, and communications may be attested by
any provider as far as this attribute is concerned.
The do-not-originate and do-not-originate-messaging attributes each
take precedence, on their own channel, over the authorized-
originators attribute. Where do-not-originate is present, the
covered telephone numbers originate no calls regardless of any
authorized-originators value; where do-not-originate-messaging is
present, they originate no messages regardless of any authorized-
originators value. The authorized-originators attribute therefore
governs only origination on channels not closed by a do-not-originate
signal.
5. Processing Rules
A STIR Authentication Service [RFC8224] that holds a certificate
carrying a PPS URIs attribute SHOULD publish out-of-band PASSporTs
for the covered telephone numbers to one of the indicated PPS
endpoints.
A relying party that has obtained a certificate carrying this
extension, whether from a signed communication or by retrieval keyed
to a telephone number, validates the certificate chain to a trusted
STIR trust anchor before relying on any attribute. Having done so,
it applies each supported attribute according to that attribute's
semantics in Section 4. The restrictive attributes, do-not-
Wendt & Śliwa Expires 7 January 2027 [Page 11]
Internet-Draft TN Attribute Certificate Extension July 2026
originate, do-not-originate-messaging, and authorized-originators,
are policy signals: a relying party SHOULD treat a communication that
does not conform to a present restrictive attribute as a candidate
for blocking, subject to local policy.
The defending value of the restrictive attributes is realized only
when a relying party can obtain them for a number independently of
the communication being evaluated. The cases these attributes are
designed to catch, such as an unsigned communication from a do-not-
originate number or one attested by an unauthorized provider, are
exactly the cases in which the holder's own certificate is not
presented on the communication. In those cases the relying party
obtains the attributes by retrieving the holder's certificate keyed
by telephone number, by a mechanism outside the scope of this
document.
6. Distribution and Transparency
Retrieval and distribution of these attributes keyed by telephone
number are out of scope for this document and are left to other
specifications and to industry practice.
The certificate is the authoritative, signed source of the attribute
values. A relying party validates the certificate independently of
how it was obtained, so trust in an attribute derives from the
certificate rather than from whatever mechanism delivered it.
Transparency logs provide a monitoring mechanism by which
distributors can observe the attributes asserted for a telephone
number as certificates are issued, and populate the authoritative
information that relying parties consult.
A distribution mechanism SHOULD convey the signed certificate
together with the distributed information, so that a relying party
can verify each attribute directly against the certificate rather
than trust the distributor. Where the signed certificate is not
conveyed, the relying party depends on the distribution layer for the
integrity of the information. This document does not otherwise
mandate a distribution mechanism.
7. Lifecycle Considerations
The attributes reflect the holder's declarations at the time the
certificate was issued. Because they are carried in the certificate,
changing an attribute requires issuing a new certificate, and the
change takes effect at relying parties only after the new certificate
has propagated through the distribution mechanism in use. Attribute
currency therefore follows certificate lifetime. Short-lived
Wendt & Śliwa Expires 7 January 2027 [Page 12]
Internet-Draft TN Attribute Certificate Extension July 2026
certificates bound the interval over which a stale declaration
remains in use and are RECOMMENDED for this reason. This ties
attribute updates to the same validated issuance path as the
certificate itself, so that a declaration cannot be forged into the
distribution layer.
8. Security Considerations
The attributes defined here are self-assertions by the holder of the
telephone numbers in the certificate's TNAuthList. Their trust rests
on two things: the certificate having been validated at issuance as
authorizing the holder for those numbers, and the relying party
validating the certificate chain before acting on any attribute. A
relying party MUST validate the chain to a trusted STIR trust anchor;
the attribute values are not independently signed and derive their
integrity from the certificate.
Because each attribute describes or constrains only the holder's own
telephone numbers and grants nothing to any other party, the worst
outcome of an incorrect or malicious assertion is degradation of
service to the asserting holder's own numbers. An attribute cannot
expand the holder's authority or confer authority on a third party.
In particular, the authorized-originators attribute lists SPCs as a
statement of the holder's acceptance policy; it confers no STIR
authority on those providers, and a relying party MUST NOT treat
presence in that list as authority of any kind, nor as extending the
certificate's telephone number scope.
Misissuance is the relevant residual risk: a certificate that carries
these attributes without the holder having been properly validated
for the listed telephone numbers would carry self-assertions that
should not be trusted. The validation that binds a certificate to
its telephone numbers is the responsibility of the issuing CA and the
certificate profile in use, and is outside the scope of this
extension.
The restrictive attributes defend against impersonation only when a
relying party can retrieve them keyed by telephone number,
independently of the communication under evaluation, as discussed in
Section 6. A relying party that cannot perform such retrieval gains
no protection from them against the unsigned or wrongly-attested
cases. Reliance on a distribution mechanism for retrieval inherits
that mechanism's availability and integrity properties; because the
certificate is signed, a compromised distribution layer can suppress
or withhold attributes but cannot forge them.
Wendt & Śliwa Expires 7 January 2027 [Page 13]
Internet-Draft TN Attribute Certificate Extension July 2026
Publication of these attributes in retrievable or publicly logged
certificates may reveal deployment metadata about a number's usage.
This exposure is consistent with existing STIR certificate practice
and does not introduce privacy risk beyond what TNAuthList usage
already entails.
9. IANA Considerations
9.1. TN Attributes Certificate Extension OID
IANA is requested to assign an object identifier for the TN
Attributes certificate extension in the "SMI Security for PKIX
Certificate Extension" registry:
* Description: id-pe-tnAttributes
* Reference: (this document)
9.2. STIR TN Attribute Types Registry
IANA is requested to create a new registry, "STIR TN Attribute
Types", to record the integer type identifiers carried in the TN
Attributes certificate extension defined in this document.
Each entry records:
* Type: the integer identifier (the "type" field of a TNAttribute).
* Name: a short identifier for the attribute type.
* Value Syntax: the ASN.1 type of the attribute value.
* Reference: the defining specification.
The registration policy is Specification Required [RFC8126]. The
designated expert MUST verify that a requested type satisfies the
self-assertion criterion: the attribute describes or constrains only
the asserting holder's own telephone numbers, grants no authority,
capability, or service to any other party, and makes no assertion
about a resource the holder does not control. A type that would
grant authority, enable a capability, or assert facts about resources
outside the holder's control does not qualify and is to be refused,
as such a mechanism requires authorization beyond a self-assertion.
The registry is initialized with the following entries, all defined
in this document:
Wendt & Śliwa Expires 7 January 2027 [Page 14]
Internet-Draft TN Attribute Certificate Extension July 2026
+====+==========================+=======================+=========+
|Type|Name |Value Syntax |Reference|
+====+==========================+=======================+=========+
|1 |pps-uris |PPSURIs |(this |
| | | |document)|
+----+--------------------------+-----------------------+---------+
|2 |do-not-originate |DoNotOriginate |(this |
| | | |document)|
+----+--------------------------+-----------------------+---------+
|3 |do-not-originate-messaging|DoNotOriginateMessaging|(this |
| | | |document)|
+----+--------------------------+-----------------------+---------+
|4 |authorized-originators |AuthorizedOriginators |(this |
| | | |document)|
+----+--------------------------+-----------------------+---------+
Table 1
Type value 0 is reserved.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/rfc/rfc5912>.
Wendt & Śliwa Expires 7 January 2027 [Page 15]
Internet-Draft TN Attribute Certificate Extension July 2026
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/rfc/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/rfc/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/rfc/rfc8226>.
[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases",
RFC 8816, DOI 10.17487/RFC8816, February 2021,
<https://www.rfc-editor.org/rfc/rfc8816>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/rfc/rfc9060>.
[RFC9475] Peterson, J. and C. Wendt, "Messaging Use Cases and
Extensions for Secure Telephone Identity Revisited
(STIR)", RFC 9475, DOI 10.17487/RFC9475, December 2023,
<https://www.rfc-editor.org/rfc/rfc9475>.
[X.509] International Telecommunication Union, "Information
technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks",
ITU-T Recommendation X.509, ISO/IEC 9594-8, October 2016,
<https://www.itu.int/rec/T-REC-X.509>.
Wendt & Śliwa Expires 7 January 2027 [Page 16]
Internet-Draft TN Attribute Certificate Extension July 2026
[X.680] International Telecommunication Union, "Information
Technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation", ITU-T Recommendation
X.680, ISO/IEC 8824-1, August 2015,
<https://www.itu.int/rec/T-REC-X.680>.
[X.681] International Telecommunication Union, "Information
Technology - Abstract Syntax Notation One (ASN.1):
Information object specification", ITU-T Recommendation
X.681, ISO/IEC 8824-2, August 2015,
<https://www.itu.int/rec/T-REC-X.681>.
[X.682] International Telecommunication Union, "Information
Technology - Abstract Syntax Notation One (ASN.1):
Constraint specification", ITU-T Recommendation X.682,
ISO/IEC 8824-3, August 2015,
<https://www.itu.int/rec/T-REC-X.682>.
[X.683] International Telecommunication Union, "Information
Technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications",
ITU-T Recommendation X.683, ISO/IEC 8824-4, August 2015,
<https://www.itu.int/rec/T-REC-X.683>.
10.2. Informative References
[I-D.ietf-stir-certificate-transparency]
Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad,
"STI Certificate Transparency", Work in Progress,
Internet-Draft, draft-ietf-stir-certificate-transparency-
02, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-stir-certificate-transparency-02>.
[RFC9888] Peterson, J., "Out-of-Band Secure Telephone Identity
Revisited (STIR) for Service Providers", RFC 9888,
DOI 10.17487/RFC9888, June 2026,
<https://www.rfc-editor.org/rfc/rfc9888>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Chris Wendt
Somos Inc.
Email: chris@appliedbits.com
Wendt & Śliwa Expires 7 January 2027 [Page 17]
Internet-Draft TN Attribute Certificate Extension July 2026
Rob Śliwa
Somos Inc.
Email: robjsliwa@gmail.com
Wendt & Śliwa Expires 7 January 2027 [Page 18]