Binding a Domain Identifier to Telephone Number Authority in STIR Certificates
draft-wendt-stir-tn-domain-binding-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) | |
|---|---|---|---|
| Author | Chris Wendt | ||
| 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-tn-domain-binding-00
Secure Telephone Identity Revisited C. Wendt
Internet-Draft Somos, Inc.
Intended status: Standards Track 6 July 2026
Expires: 7 January 2027
Binding a Domain Identifier to Telephone Number Authority in STIR
Certificates
draft-wendt-stir-tn-domain-binding-00
Abstract
This document defines a mechanism for binding a domain identifier to
telephone number authority within a STIR certificate. A certificate
produced under this mechanism carries, as a co-validated pair, the
telephone numbers or service provider codes a subject is authorized
for in a TNAuthList extension and a domain the subject controls in a
SubjectAltName dNSName entry. The binding is established at issuance
by requiring proof of domain control and validation of a TNAuthList
authority token within a single certificate issuance, such that the
resulting certificate attests that the same entity holds both. The
mechanism applies to STIR certificates whose TNAuthList contains
telephone number entries, service provider code entries, or both,
allowing a domain to be bound to the right-to-use holder for a set of
numbers or to the provider identified by a service provider code.
This document defines the issuance conformance requirements and the
relying party verification rule that together make the binding
meaningful. It does not define telephone number or service provider
code authorization or domain validation, both of which are specified
elsewhere and referenced here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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.
Wendt Expires 7 January 2027 [Page 1]
Internet-Draft STIR TN-Domain Binding July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Overview of the Binding . . . . . . . . . . . . . . . . . . . 4
4. Binding Process . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Phase 1: Domain control . . . . . . . . . . . . . . . . . 5
4.2. Phase 2: TNAuthList authority . . . . . . . . . . . . . . 6
4.3. Phase 3: Binding issuance . . . . . . . . . . . . . . . . 6
5. Issuance Requirements . . . . . . . . . . . . . . . . . . . . 7
6. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 8
6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Relying Party Verification . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The STIR architecture ([RFC8224], [RFC8225], [RFC8226]) establishes
that a signer is authorized for the telephone numbers or service
provider codes carried in the TNAuthList certificate extension
[RFC8226], validated through the STIR certificate chain. This
authority may be held by an entity to which numbers have been
assigned, including through delegation [RFC9060], or by a provider
identified by a service provider code. However, STIR does not
establish a verifiable identity for the entity that holds this
authority, nor does it bind that identity to an Internet identifier
that a relying party can recognize across contexts.
Wendt Expires 7 January 2027 [Page 2]
Internet-Draft STIR TN-Domain Binding July 2026
A domain name is a stable, globally unique Internet identifier for
which well-established mechanisms exist to prove control. If a STIR
certificate could attest that the entity authorized for a set of
telephone numbers or service provider codes is the same entity that
controls a particular domain, a relying party would gain an
independent, corroborating identity signal bound to that authority.
For a certificate carrying telephone numbers, the domain identifies
the right-to-use holder for those numbers. For a certificate
carrying a service provider code, the domain identifies the provider.
In both cases the value of the binding depends entirely on the two
facts being established independently and then bound together by the
issuer, rather than merely asserted by the subject.
This document defines that binding. It specifies how an issuing
Certification Authority co-validates the TNAuthList authority and
domain control within a single issuance, what the resulting
certificate contains, and how a relying party verifies the binding.
The mechanism reuses existing components without modification:
TNAuthList authority via authority tokens ([RFC9447], [RFC9448]) and
domain control validation via existing challenge mechanisms such as
those defined for ACME [RFC8555]. The contribution of this document
is the requirement that these two proofs be bound together at
issuance and the verification rule that relies on that binding.
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.
This document uses the following terms.
TNAuthList authority: the authorization for an entity to use the
telephone numbers or to hold the service provider code carried in a
TNAuthList extension [RFC8226], established by the authority
responsible for those entries, such as a numbering authority,
responsible provider, or service provider code authority.
TNAuthList authority token: a signed assertion of TNAuthList
authority for the entries it covers, validated during STIR
certificate issuance, as defined in [RFC9447] and [RFC9448]. For
telephone number entries this attests right-to-use of the numbers;
for service provider code entries it attests holdership of the code.
Wendt Expires 7 January 2027 [Page 3]
Internet-Draft STIR TN-Domain Binding July 2026
Right-to-Use (RTU): the case of TNAuthList authority in which the
entries are telephone numbers, representing authorization for an
entity to use those numbers.
Domain identifier: a DNS domain name controlled by the certificate
subject, carried in a SubjectAltName dNSName entry [RFC5280].
Bound certificate: a STIR certificate issued under this document,
carrying a co-validated TNAuthList and domain identifier.
3. Overview of the Binding
A bound certificate asserts a single composite fact: the entity that
controls the domain identifier in the certificate is the same entity
that holds the TNAuthList authority in the certificate. This
composite fact is established at issuance and is not derivable from
either proof alone.
The binding rests on two independent proofs:
1. Proof of domain control: the subject demonstrates control of the
domain identifier, using an existing domain control validation
mechanism.
2. Proof of TNAuthList authority: the subject presents a TNAuthList
authority token attesting authorization for the telephone numbers
or service provider codes, validated by the issuing CA against
the authority responsible for that token.
Neither proof is defined by this document. What this document
defines is the requirement that both be satisfied within a single
issuance, and that the issued certificate carry both results as a
bound pair, so that a relying party validating the certificate can
rely on the composite fact.
4. Binding Process
The binding is produced by a three-phase process. The first two
phases each establish one proof using mechanisms that already exist;
the third phase binds the two results into one certificate. The
phases are described here to give an operational picture; the
normative conformance requirements are stated in Section 5.
Phase 1 establishes control of the domain identifier. Phase 2
establishes TNAuthList authority for the telephone numbers or service
provider codes. Phase 3 is a single certificate issuance that
requires both proofs and binds their results. The following diagram
shows the process at a glance.
Wendt Expires 7 January 2027 [Page 4]
Internet-Draft STIR TN-Domain Binding July 2026
+-------------+ +-------------------+
| Subject | | TNAuthList |
| (domain + | | Authority |
| TN or SPC | | (numbering auth / |
| authority) | | provider / SPC |
| | | authority) |
+------+------+ +---------+---------+
| Phase 2: request authority evidence |
| --------------------------------------------+
| |
| <-------- TNAuthList authority token --------+
| (proves TN right-to-use or SPC holdership)
|
| Phase 1 + Phase 3: single issuance request to CA
| (CSR + domain challenge + authority token)
v
+------+-------------------------------------------------+
| STI Certification Authority |
| |
| Phase 1: validate domain control (e.g. dns-01) |
| Phase 2 check: validate TNAuthList authority token |
| Phase 3: bind validated domain + validated TNAuthList |
| into one certificate |
+------+-------------------------------------------------+
|
| bound certificate (domain in SAN + TN/SPC in
| TNAuthList)
v
+------+-------------------+
| Bound certificate |
+--------------------------+
4.1. Phase 1: Domain control
The subject proves control of the domain identifier that will appear
in the SubjectAltName. This document does not define a new mechanism
for this; it reuses domain control validation as already deployed for
the Web PKI. The challenge types defined for ACME [RFC8555] are
directly applicable:
* dns-01: the subject provisions a DNS TXT record containing a key-
authorization value under a well-known name in the zone of the
domain. This proves control of the zone.
* http-01: the subject serves a key-authorization value at a well-
known path under the domain. This proves control of content
served at the domain.
Wendt Expires 7 January 2027 [Page 5]
Internet-Draft STIR TN-Domain Binding July 2026
Either challenge is sufficient on its own. The choice follows
existing ACME practice and is operational.
Domain control verification is an explicit, cryptographically
demonstrable signal. The operational act of provisioning the
required records in public DNS, or serving the required content under
the domain, demonstrates current authorized control of the domain by
the party performing it. This is distinct from the broader entity
verification, often referred to as know-your-customer (KYC), through
which a provider or authority establishes the customer relationship
that associates a real-world entity with its domain. That
verification is out of scope here and is neither defined nor replaced
by this document. This document relies on domain control and
telephone number authority as explicit signals, and depends on,
rather than specifies, the entity verification they rest on.
4.2. Phase 2: TNAuthList authority
The subject obtains a TNAuthList authority token from the authority
responsible for the entries it covers: a numbering authority or
responsible provider for telephone numbers, or a service provider
code authority for an SPC. This is the same authority token
construct used for ordinary STIR certificate issuance ([RFC9447],
[RFC9448]). The token is scoped to specific telephone numbers or
service provider codes, is verifiable by the CA against the
responsible authority's credentials, and is consumed within a single
issuance rather than held as a long-lived bearer credential. The
authority issuing the token and the subject are frequently different
entities; binding the two proofs is what makes that separation
verifiable rather than assumed.
4.3. Phase 3: Binding issuance
The subject places a single certificate issuance request to the CA
that carries both proofs: a Certificate Signing Request naming the
domain identifier in its SubjectAltName, a domain control challenge
response, and the TNAuthList authority token. The CA validates
domain control and validates the authority token, and only if both
succeed issues a certificate whose SubjectAltName carries the
validated domain and whose TNAuthList carries the validated telephone
numbers or service provider codes.
The reason both proofs are evaluated within one issuance, rather than
assembled from separately obtained credentials, is that the
trustworthiness of the binding depends on a single party having
confirmed both at the same time. If a subject could obtain a domain
credential from one source and a TNAuthList authority credential from
another and combine them itself, a relying party would have no
Wendt Expires 7 January 2027 [Page 6]
Internet-Draft STIR TN-Domain Binding July 2026
assurance that the same entity legitimately held both. Requiring the
CA to validate both before issuing makes the certificate a first-
party attestation that the binding was verified, not merely asserted.
The following sequence shows the issuance in full.
Subject STI-CA TNAuthList Auth
| | |
| (Phase 2 done earlier) |
| request authority evidence -----------> |
| <----- TNAuthList authority token ----- |
| | |
| 1. issuance request (CSR w/ domain SAN + token)
| ---------------> | |
| 2. domain challenge (dns-01 / http-01) |
| <--------------- | |
| provision TXT / serve resource |
| ---------------> | |
| | validate domain |
| | 3. validate token --> |
| | <--- token valid ----- |
| | 4. both OK? yes |
| <----- bound certificate (domain + TN/SPC) |
| | |
If either proof fails at step 4, the CA does not issue, and the
subject receives an error rather than a certificate.
5. Issuance Requirements
An issuing Certification Authority that issues bound certificates
under this document MUST satisfy all of the following within a single
certificate issuance.
The CA MUST validate control of the domain identifier that will
appear in the SubjectAltName dNSName entry of the certificate. The
CA MUST use an established domain control validation mechanism. The
challenge-based mechanisms defined for ACME [RFC8555] are suitable
and RECOMMENDED. This document does not define a new domain control
validation mechanism.
The CA MUST validate a TNAuthList authority token covering the
telephone numbers or service provider codes that will appear in the
TNAuthList extension of the certificate, in accordance with [RFC9447]
and [RFC9448]. The CA MUST NOT include in the TNAuthList any
telephone number or service provider code not covered by a validated
TNAuthList authority token.
Wendt Expires 7 January 2027 [Page 7]
Internet-Draft STIR TN-Domain Binding July 2026
The CA MUST treat the two validations as a single atomic condition
for issuance. If either the domain control validation or the
TNAuthList authority token validation fails, the CA MUST NOT issue
the certificate. The CA MUST NOT issue a certificate that carries a
domain identifier without a corresponding validated TNAuthList
authority, nor one that carries TNAuthList authority bound to an
unvalidated domain identifier.
The two validations MAY be performed in any order within the
issuance, and MAY reuse a recent prior domain control validation for
the same domain identifier and the same subject account, provided the
reused validation is within the validity window permitted by the CA's
policy. Reuse of a prior TNAuthList authority token validation is
NOT permitted; a token MUST be validated for each issuance.
6. Certificate Profile
A bound certificate MUST conform to the STIR certificate profile in
[RFC8226]. Where the certificate is a delegate certificate, it MUST
also conform to [RFC9060]. A bound certificate MUST contain the
following.
A SubjectAltName extension containing exactly one dNSName entry
carrying the validated domain identifier. The domain identifier MUST
be a DNS-resolvable domain name controlled by the subject.
A TNAuthList extension [RFC8226] containing one or more entries,
which may be telephone number entries, service provider code entries,
or both. Every entry MUST be covered by a TNAuthList authority token
validated during issuance.
A bound certificate MAY additionally carry the JWTClaimConstraints
extension of [RFC8226], the EnhancedJWTClaimConstraints extension of
[RFC9118], and other elements permitted by [RFC8226]; these are out
of scope for the binding defined here. Issuers SHOULD issue short-
lived certificates as described in
[I-D.ietf-stir-certificates-shortlived].
This document associates no new semantics with the Subject
distinguished name and does not require organizational identity to be
present in the certificate. The domain identifier in the
SubjectAltName is the identifier this document binds to the
TNAuthList authority.
The domain identifier is carried in the SubjectAltName, not in the
Subject Common Name, consistent with current PKI practice of
conveying domain identity in the SubjectAltName rather than the
Common Name. This binding adds a SubjectAltName dNSName entry and
Wendt Expires 7 January 2027 [Page 8]
Internet-Draft STIR TN-Domain Binding July 2026
neither relies on nor alters the Subject distinguished name. It is
therefore compatible with certificate profiles that specify Subject
Common Name content for their own purposes, such as the SHAKEN
profile (ATIS-1000074, ATIS-1000080, ATIS-1000084), which uses the
Common Name to mark a certificate as a SHAKEN certificate. A
certificate may carry such Common Name content and a bound domain
identifier in its SubjectAltName without conflict.
6.1. Examples
The following examples illustrate the two principal cases. The
certificate fields are shown in the textual style produced by common
certificate tooling, omitting fields not relevant to the binding.
The TNAuthList extension is identified by the object identifier id-
pe-TNAuthList (1.3.6.1.5.5.7.1.26) and its value is the DER encoding
of the TNAuthorizationList structure defined in [RFC8226]; because
most tooling does not decode this extension natively, both the
decoded contents and the DER octets are shown. Values are
illustrative.
The first example is a certificate issued to a service provider. Its
TNAuthList carries a single service provider code, and its
SubjectAltName carries the domain that identifies that provider. The
Common Name marks it as a SHAKEN certificate, illustrating
coexistence with the SHAKEN profile.
Certificate:
Data:
Subject: CN=SHAKEN, O=Example Communications Inc
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:example-comms.net
id-pe-TNAuthList (1.3.6.1.5.5.7.1.26):
TNAuthorizationList:
spc [0]: "1234"
The TNAuthorizationList DER, as it appears in the extension value,
with the EXPLICIT context tag on the spc CHOICE alternative:
30 08 A0 06 16 04 31 32 33 34
30 08 SEQUENCE (TNAuthorizationList), 8 octets
A0 06 [0] EXPLICIT (spc), 6 octets
16 04 IA5String, 4 octets
31 32 33 34 "1234"
Wendt Expires 7 January 2027 [Page 9]
Internet-Draft STIR TN-Domain Binding July 2026
In this case a relying party that validates the certificate learns
that the entity holding service provider code 1234 is the same entity
that controls example-comms.net, because the issuing CA validated
both within a single issuance.
The second example is a certificate issued to a business entity that
holds the right-to-use for a telephone number. Its TNAuthList
carries that telephone number, and its SubjectAltName carries the
business's domain. While a TNAuthorizationList may contain more than
one entry, a certificate scoped to a single telephone number is
RECOMMENDED. Telephone numbers in the TNAuthorizationList are
IA5Strings restricted to the digits and symbols permitted by
[RFC8226], and do not include a leading "+".
Certificate:
Data:
Subject: O=Example Retail LLC
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:exampleretail.com
id-pe-TNAuthList (1.3.6.1.5.5.7.1.26):
TNAuthorizationList:
one [2]: "12015550100"
The corresponding TNAuthorizationList DER, with the EXPLICIT context
tag on the telephone number CHOICE alternative:
30 0F A2 0D 16 0B 31 32 30 31 35 35 35 30 31 30 30
30 0F SEQUENCE (TNAuthorizationList), 15 octets
A2 0D [2] EXPLICIT (one), 13 octets
16 0B IA5String, 11 octets
31 32 30 31 35 35 35 30 31 30 30 "12015550100"
In this case a relying party learns that the entity that controls
exampleretail.com is the same entity that holds the right-to-use for
the telephone number 12015550100. A relying party MUST NOT extend
that conclusion to any telephone number not present in the
TNAuthList.
A certificate MAY carry both telephone number entries and service
provider code entries in a single TNAuthorizationList, in which case
the domain identifier is bound to all of them, as permitted by
[RFC8226].
Wendt Expires 7 January 2027 [Page 10]
Internet-Draft STIR TN-Domain Binding July 2026
7. Relying Party Verification
A relying party that validates a bound certificate, in addition to
the STIR certificate validation procedures defined in [RFC8224] and
[RFC8226], MUST apply the following.
The relying party MUST validate the certificate chain to a trusted
STIR trust anchor. Where the certificate carries an embedded Signed
Certificate Timestamp, the relying party validates it as it would for
any STIR certificate.
The relying party MUST treat the domain identifier in the
SubjectAltName dNSName entry as the identity of the entity holding
the TNAuthList authority in the certificate only when the certificate
is valid under the above checks. The domain identifier carries this
meaning by virtue of the issuance binding; a relying party MUST NOT
infer TNAuthList authority from the domain identifier independently
of the TNAuthList, nor infer domain association for any telephone
number or service provider code not present in the TNAuthList.
When a relying party obtains the certificate by retrieving it from a
location under the domain identifier, the relying party MAY treat
successful retrieval over an authenticated channel for that domain as
reinforcing the domain control evidence, but this retrieval is not a
substitute for the issuance binding established above.
8. Security Considerations
The security of the binding depends on the issuing CA performing both
validations within a single issuance. The central guarantee is that
a relying party need not trust the subject's self-assertion of either
domain control or TNAuthList authority; it relies instead on the CA
having validated both and bound them in a single issued certificate.
An issuer that issued a certificate carrying a domain identifier
without a correspondingly validated TNAuthList authority, or vice
versa, would defeat the guarantee; the requirements in this document
prohibit such issuance.
Domain control validation establishes control at the time of issuance
and does not by itself attest to the legal identity of the
organization controlling the domain. As described in Section 4.1,
the broader entity verification that establishes the entity-to-domain
association is performed under the CA's certificate policy and is out
of scope for this document.
The binding reflects the state validated at the time of issuance.
Its currency over time is maintained by reissuance rather than by
ongoing monitoring: each issuance re-checks domain control and
Wendt Expires 7 January 2027 [Page 11]
Internet-Draft STIR TN-Domain Binding July 2026
requires a freshly validated TNAuthList authority token, and short-
lived certificates as described in
[I-D.ietf-stir-certificates-shortlived] bound the interval over which
a stale, mistaken, or compromised binding remains usable. The
lifecycle of the underlying entity-to-domain association on which
domain control rests is maintained under the CA's certificate policy,
as described in Section 4.1.
The reuse of a recent domain control validation permitted in the
issuance requirements widens, by the reuse window, the interval
between domain control being demonstrated and the binding being
issued. CAs SHOULD keep this window short consistent with their
policy.
9. IANA Considerations
This document has no IANA actions. It relies on certificate
extensions and token mechanisms registered by the documents it
references.
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>.
[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>.
[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>.
Wendt Expires 7 January 2027 [Page 12]
Internet-Draft STIR TN-Domain Binding July 2026
[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>.
[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>.
[RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim
Constraints for Secure Telephone Identity Revisited (STIR)
Certificates", RFC 9118, DOI 10.17487/RFC9118, August
2021, <https://www.rfc-editor.org/rfc/rfc9118>.
[RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt,
"Automated Certificate Management Environment (ACME)
Challenges Using an Authority Token", RFC 9447,
DOI 10.17487/RFC9447, September 2023,
<https://www.rfc-editor.org/rfc/rfc9447>.
[RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList Profile of Automated Certificate Management
Environment (ACME) Authority Token", RFC 9448,
DOI 10.17487/RFC9448, September 2023,
<https://www.rfc-editor.org/rfc/rfc9448>.
10.2. Informative References
[I-D.ietf-stir-certificates-shortlived]
Peterson, J., "Short-Lived Certificates for Secure
Telephone Identity", Work in Progress, Internet-Draft,
draft-ietf-stir-certificates-shortlived-06, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-stir-
certificates-shortlived-06>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
Author's Address
Chris Wendt
Somos, Inc.
United States of America
Email: chris@appliedbits.com
Wendt Expires 7 January 2027 [Page 13]