Securing SIP and RTP with STIR Certificates
draft-wendt-stir-secure-sip-rtp-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-11-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wendt-stir-secure-sip-rtp-00
Secure Telephone Identity Revisited C. Wendt
Internet-Draft Somos, Inc.
Intended status: Informational 1 November 2026
Expires: 5 May 2027
Securing SIP and RTP with STIR Certificates
draft-wendt-stir-secure-sip-rtp-00
Abstract
Certificates issued within the Secure Telephone Identity Revisited
(STIR) framework establish, through a governed issuance process, that
a party holds authority over telephone numbers or a service provider
code, and where a domain identifier is bound to that authority, that
the same party controls a domain. This document defines a
certificate profile for TLS built on the TNAuthList extension and on
the binding of telephone number authority to a domain identifier, so
that the provider operating an interface is identified by a service
provider code and by a validated domain rather than by prior
arrangement between the parties, and it specifies the use of TLS,
mutual TLS, and media protection across that interface. It applies
to the network to network interface between providers. It brings the
use of TLS with SIP up to date with TLS 1.3 and current certificate
identity practice, and places the issuance of the credentials on
which interconnection depends within a defined governance and
issuance framework.
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 5 May 2027.
Wendt Expires 5 May 2027 [Page 1]
Internet-Draft Securing SIP and RTP with STIR November 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Existing Specification Landscape . . . . . . . . . . . . 6
3.1. Core SIP Documents . . . . . . . . . . . . . . . . . . . 6
3.2. Certificate Identity and Connection Management . . . . . 6
3.3. TLS and Service Identity . . . . . . . . . . . . . . . . 7
3.4. Telephone Number Authority in Certificates . . . . . . . 7
3.5. Media Protection . . . . . . . . . . . . . . . . . . . . 8
4. Certificates for SIP over TLS . . . . . . . . . . . . . . . . 8
4.1. Domain Identity . . . . . . . . . . . . . . . . . . . . . 8
4.2. Names in the Certificate . . . . . . . . . . . . . . . . 9
4.3. Binding Domain Identity to Telephone Number Authority . . 10
4.4. Certificate Contents . . . . . . . . . . . . . . . . . . 11
5. Algorithms and TLS 1.3 . . . . . . . . . . . . . . . . . . . 12
5.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 12
5.2. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Signature Algorithms and Certificates . . . . . . . . . . 13
5.4. Interoperability Considerations . . . . . . . . . . . . . 14
5.5. The Post-Quantum Transition . . . . . . . . . . . . . . . 14
6. Securing the Media . . . . . . . . . . . . . . . . . . . . . 15
6.1. Media Security Baseline . . . . . . . . . . . . . . . . . 15
6.2. Properties of the Two Mechanisms . . . . . . . . . . . . 17
6.2.1. Protection Across the Interface . . . . . . . . . . . 18
6.2.2. Propagation of Keying Material Beyond the
Interface . . . . . . . . . . . . . . . . . . . . . . 18
6.2.3. Operational Cost . . . . . . . . . . . . . . . . . . 19
6.2.4. Selecting a Mechanism . . . . . . . . . . . . . . . . 19
6.3. Requirements for Signaling Anchored Keying . . . . . . . 20
6.4. Relationship to the Existing Best Practice . . . . . . . 20
6.5. Key Agreement for Media . . . . . . . . . . . . . . . . . 21
6.6. Termination of Media Security Associations . . . . . . . 21
Wendt Expires 5 May 2027 [Page 2]
Internet-Draft Securing SIP and RTP with STIR November 2026
6.7. Keying Mechanisms and Deployed Equipment . . . . . . . . 22
7. Media Resilience . . . . . . . . . . . . . . . . . . . . . . 23
8. Identified Protocol Gaps . . . . . . . . . . . . . . . . . . 23
9. Mutual TLS and Peer Authorization . . . . . . . . . . . . . . 25
9.1. Authentication . . . . . . . . . . . . . . . . . . . . . 25
9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 25
9.3. Interconnection Without Prior Arrangement . . . . . . . . 26
9.4. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 27
9.5. Limiting Issuance for an Interface Domain . . . . . . . . 27
10. Connection Management . . . . . . . . . . . . . . . . . . . . 27
10.1. Connection Reuse . . . . . . . . . . . . . . . . . . . . 28
10.2. Client Authentication and the Handshake . . . . . . . . 28
10.3. Long Lived Connections . . . . . . . . . . . . . . . . . 28
10.4. Server Name Indication . . . . . . . . . . . . . . . . . 28
11. Operational Considerations . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
15.1. Normative References . . . . . . . . . . . . . . . . . . 30
15.2. Informative References . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction
Interconnection between telephone service providers is moving onto
the public internet, and increasingly onto arrangements in which any
provider may exchange traffic with any other without a bilateral
agreement having been established in advance. A provider operating
such an interface needs to determine, at the moment a connection is
presented to it, which provider is at the other end and whether it is
prepared to exchange traffic with that provider. Where no agreement
precedes the connection, the receiving provider holds no
configuration describing the peer, and both determinations have to be
made from what the peer presents.
A certificate carrying the TNAuthList extension [RFC8226] asserts
authority over telephone numbers or a service provider code, and is
issued only after an authority responsible for those numbers has
validated that assertion. Where the certificate additionally carries
a domain identifier bound to that authority
[I-D.wendt-stir-tn-domain-binding], the issuer has validated control
of the domain in the same act, so the certificate identifies a
provider by a service provider code and by a domain that a relying
party can verify. The governance and issuance policy under which
such certificates are granted is what determines who may obtain one,
and therefore who may participate. Participation is established by
holding a credential rather than by agreement between the parties.
Wendt Expires 5 May 2027 [Page 3]
Internet-Draft Securing SIP and RTP with STIR November 2026
What has been missing is a specification of how that credential is
used at the interface itself: what a certificate presented for TLS
contains, how a peer authenticates it, what a peer is entitled to
conclude from it, and how the signaling and media it protects are
secured. This document supplies that.
The specifications defining the use of TLS with SIP are a further
obstacle. SIP [RFC3261] has supported TLS since publication, and the
documents describing how that support works were largely complete by
2010. TLS 1.3 [RFC9846] has since replaced the handshake, removed
renegotiation, and encrypted the certificate exchange; guidance for
representing and verifying service identity in certificates was
revised and republished as [RFC9525], narrowing the identifier types
in scope and removing practices the SIP documents still permit;
recommendations for the secure use of TLS were consolidated in
[RFC9325]; earlier TLS versions were deprecated [RFC8996]; and post-
quantum key agreement has been introduced. None of these changes
were made with SIP in mind, and none of the SIP documents have been
revisited in light of them.
Implementations have diverged accordingly. Deployments make locally
reasonable choices about which certificate identifier to populate and
which to check, whether and how to require a client certificate, and
how to decide that a presented certificate belongs to a peer whose
traffic they will carry. Interconnection is then arranged
bilaterally, and commonly falls back to address based access control,
with TLS providing confidentiality but not a usable peer identity.
A further reason for this document is the transition to post-quantum
cryptography. [NIST.IR.8547] deprecates the elliptic curve and RSA
algorithms in current use for both key establishment and signatures
after 2030 and disallows them after 2035. The SIP and STIR
specifications predate that timeline, and interconnection equipment
deployed now will be in service through it. This document identifies
where the transition touches SIP over TLS, SRTP, and STIR, and what
each step depends on, so that the pieces can be taken up in the
forums that own them.
This document therefore does three things. It sets out the
specifications that define the use of TLS and of media protection
with SIP, and where each has been overtaken. It defines a profile of
current practice for the interface between providers, including the
certificate profile described above and the protection of both
signaling and media across that interface. And it identifies the
points at which existing specifications require change rather than
profiling, which it does not undertake here.
Wendt Expires 5 May 2027 [Page 4]
Internet-Draft Securing SIP and RTP with STIR November 2026
1.1. Scope
This document is about the certificates used for TLS between
providers and what a peer concludes from them: what a certificate
contains, how its subject is validated, how a peer authenticates and
authorizes the party presenting it, and how the signaling and media
it protects are keyed. The use of TLS as a SIP transport, including
the TLS version, cipher suites, and how a certificate identifier is
matched against a SIP domain, is specified by
[I-D.wendt-sipcore-tls-updates]; this document narrows those rules
for the interface it covers and does not restate them. It does not
define new TLS mechanisms, new certificate extensions, or new
cryptographic algorithms. Where this document recommends a behavior
that differs from an existing specification, it identifies that
specification and the nature of the difference; it does not formally
update those documents.
This document applies to the network to network interface, that is,
to the signaling and media exchanged between the border elements of
two interconnected providers. It covers the protection of both
signaling and media across that interface, since the trust in each
derives from the same credential and the protection of one bounds
what the other achieves.
The user to network interface, between a provider and its own
subscribers, is out of scope. So is the treatment of signaling and
media within a provider's network. This scoping is deliberate and
distinguishes this profile from work that sought protection between
user agents: at the network to network interface the two border
elements are the endpoints of the segment being protected, and no
intermediary lies between them to terminate a security association.
Protection described here applies to a single interface between two
adjacent providers. Where a communication traverses more than one
such interface, each is protected independently. This document does
not provide, and does not claim, confidentiality between the calling
and called parties.
This document does not define SRTP transforms or RTP payload formats,
which are specified elsewhere and referenced here.
2. Conventions
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.
Wendt Expires 5 May 2027 [Page 5]
Internet-Draft Securing SIP and RTP with STIR November 2026
3. The Existing Specification Landscape
This section surveys the documents that together define the use of
TLS with SIP, and notes for each what it establishes and what has
changed since.
3.1. Core SIP Documents
[RFC3261] defines TLS as a SIP transport and the "sips" URI scheme
that requests its use. Section 26 sets out the security
architecture, including the expectation that peers inspect each other
certificates on interdomain connections. Its transport requirements
were written against TLS 1.0 [RFC5246] and its mandatory cipher
suite, TLS_RSA_WITH_AES_128_CBC_SHA, uses static RSA key exchange,
which does not exist in TLS 1.3. The base specification therefore
states a mandatory floor that a conforming modern implementation
cannot meet.
[RFC3263] defines how a SIP URI is resolved to a transport, address,
and port using NAPTR and SRV records, and is the mechanism by which a
TLS connection target is selected. Because the name used to reach a
host can differ from the name in the URI that was resolved, the
resolution procedure and the certificate matching procedure interact,
and that interaction is a recurring source of implementation
disagreement.
[RFC5630] clarifies the semantics of the "sips" URI scheme, which
[RFC3261] left open to more than one reading. It establishes that
"sips" requests TLS on each hop toward the target domain rather than
end to end.
3.2. Certificate Identity and Connection Management
[RFC5922] is the central document for certificate identity in SIP.
It specifies which identifiers in a certificate may represent a SIP
domain and how they are compared against the domain being reached.
It establishes that a SIP domain identity SHOULD be conveyed as a
subjectAltName of type uniformResourceIdentifier containing a "sip"
URI with no user part, that a dNSName entry is accepted only if no
matching "sip" URI entry is present, and that the Subject common name
may be examined only if no subjectAltName appears at all. It also
specifies the behavior of a peer that accepts a connection and
authenticates the sending domain, which is the basis for mutual
authentication in SIP as it exists today.
Two of those rules are now in conflict with [RFC9525], which
obsoletes the general service identity guidance that [RFC5922] was
written against. [RFC9525] establishes that service identity can be
Wendt Expires 5 May 2027 [Page 6]
Internet-Draft Securing SIP and RTP with STIR November 2026
expressed only in the subjectAltName extension and that the common
name is no longer valid for this purpose, and it scopes itself to
identifiers expressed as domain names, IP addresses, and SRV service
names. A "sip" URI entry is outside that scope. The result is that
the identifier type [RFC5922] prefers is not covered by current
service identity guidance, while the identifier type it treats as a
fallback, dNSName, is the one that general purpose TLS
implementations actually verify.
[RFC5923] defines connection reuse, allowing a TLS connection
established in one direction to carry requests in the other. It
requires that both peers be authenticated for such reuse, and is
therefore the principal reason mutual TLS is used in SIP. It was
written against a TLS version in which a server could request a
client certificate through renegotiation, an option TLS 1.3 does not
provide.
[RFC5924], an Experimental specification, defines an extended key
usage, id-kp-sipDomain, marking a certificate as issued for SIP
domain use and restricting the names in that certificate to use by a
SIP service. Its deployment is limited, and the consequences of its
presence or absence in a certificate used for SIP are not treated
consistently.
3.3. TLS and Service Identity
[RFC9846] defines TLS 1.3, which changes several properties the SIP
documents assume: the handshake is restructured, renegotiation is
removed in favor of post-handshake authentication, the certificate is
encrypted, and session resumption and early data are redefined.
[RFC9325] provides current recommendations for the secure use of TLS,
and [RFC8996] deprecates TLS 1.0 and 1.1. [RFC6066] defines the
server name indication extension, which is relevant wherever a single
host serves more than one SIP domain, a case [RFC5922] anticipates
through multiple certificate identities rather than through a
negotiated server name.
3.4. Telephone Number Authority in Certificates
[RFC8226] defines the TNAuthList certificate extension, which conveys
the telephone numbers, number ranges, or service provider codes for
which a certificate holder is authorized. Although developed for
signing PASSporTs, the extension is non critical and carries no
restriction on the protocols in which the certificate may be used.
[RFC9060] defines delegation of that authority to a subordinate
certificate.
Wendt Expires 5 May 2027 [Page 7]
Internet-Draft Securing SIP and RTP with STIR November 2026
[I-D.wendt-stir-tn-domain-binding] defines a binding between
telephone number authority and a domain identifier, established by an
issuing certification authority that validates control of the domain
and a telephone number authority token within a single issuance, so
that the resulting certificate attests that the same entity holds
both.
3.5. Media Protection
The protection of media is defined separately from the protection of
signaling, and the relationship between them determines what
protecting the signaling achieves. [RFC3711] defines SRTP. Where
keys for SRTP are carried in the session description [RFC4568], the
confidentiality of the media depends entirely on the protection of
the signaling that carries them. Where DTLS-SRTP [RFC5763] is used,
the signaling carries only a certificate fingerprint [RFC8122] and
the media keys are established in the media plane. A substantial
amount of interconnected traffic uses neither, and carries media with
no protection at all. [RFC8643] defines an opportunistic approach
for negotiating SRTP where support is not known in advance, intended
as a transitional mechanism for deployments moving toward encrypted
media.
[RFC8862] is the current best practice for securing media signaled
with SIP. It requires DTLS-SRTP, and defines a profile of STIR in
which a verification service confirms that the fingerprints carried
in the session description match the keys exchanged in the DTLS-SRTP
handshake, using the PASSporT mky claim to protect those fingerprints
and an msec PASSporT type to signal compliance. It was written for
an endpoint to endpoint model in which user agents implement both
STIR roles, and it predates DTLS 1.3 [RFC9147] and the introduction
of post-quantum key agreement. It also observes that media relays
and back to back user agents frequently terminate media security
associations, so that only hop by hop confidentiality is achievable
in many deployments [RFC7879].
4. Certificates for SIP over TLS
4.1. Domain Identity
A certificate used under this profile carries the domain of the
interface in a subjectAltName dNSName entry, and a peer verifying the
certificate verifies that entry, following the representation and
matching rules of [I-D.wendt-sipcore-tls-updates]. The
subjectAltName entry of type uniformResourceIdentifier containing a
"sip" URI, which [RFC5922] prefers, is not used at this interface.
Wendt Expires 5 May 2027 [Page 8]
Internet-Draft Securing SIP and RTP with STIR November 2026
The identities carried in signaling across this interface are
telephone numbers, expressed as a "tel" URI or as a "sip" URI with
the user=phone parameter, in which the host portion identifies the
domain to which the request is routed rather than forming part of the
identity. A telephone number carries no domain of its own, and no
association between a telephone number and a domain can be derived
from the number itself. That association is established at issuance
by the binding described in [I-D.wendt-stir-tn-domain-binding], which
is why a separate binding is required here and is not required for an
identity of the form user@domain, where the domain is part of the
identity.
The identity a peer verifies at this interface is therefore a domain
name, and it is the same identifier the binding associates with
telephone number authority. The domain that authenticates the
transport peer and the domain that corroborates the entity holding
the telephone numbers are the same value in the same certificate,
verified by the same path validation.
4.2. Names in the Certificate
A certificate used under this profile can carry two kinds of name: a
domain, and telephone number authority. Both appear in the
certificate and both are examined by a peer, and this section says
what each establishes.
The domain is the identifier a peer verifies. A provider publishes a
domain at which its interface is reached, and a connecting peer
verifies that domain against the presented certificate. Separately,
a provider holds a certificate binding a domain to the telephone
numbers or service provider code it is authorized for. A provider
that operates its interface under a domain it also has bound presents
one certificate that serves both, and a peer that validates it learns
both which party it is connected to and what that party is authorized
for.
Where the two domains differ, a peer learns less. If the interface
is operated under a domain that carries no bound telephone number
authority, validating the certificate establishes which party
operates the interface and nothing about its authority over telephone
numbers. A provider whose interface is operated on its behalf by
another party, under that party's domain, is in this position, as is
a provider that has bound one domain to its numbers and publishes its
interface under another.
An element accepting a connection under this profile MUST therefore
determine which of these cases applies rather than assume the first.
Where the certificate presented for the connection is a bound
Wendt Expires 5 May 2027 [Page 9]
Internet-Draft Securing SIP and RTP with STIR November 2026
certificate and the domain matched for the connection is the bound
domain, the authorization determination of Section 9 applies to the
party at the other end of the connection. Where it is not, the
authenticated identity is that of the party operating the interface
only, and any determination about telephone number authority is made
from the credential presented with each communication rather than
from the transport connection.
Deployments SHOULD operate an interface under a domain bound to the
telephone number authority of the provider on whose behalf traffic is
carried, so that the transport connection and the traffic carried
over it are attributable to the same party. Where an interface is
operated by one party on behalf of another, that arrangement is
visible to a peer as the difference described here, and this profile
does not treat it as an error.
Telephone number authority is carried in the TNAuthList extension
[RFC8226], conveying the telephone numbers, number ranges, or service
provider codes for which the subject is authorized. TNAuthList is a
non critical extension, so a TLS implementation that does not
recognize it ignores it and path validation is unaffected. [RFC8226]
places no restriction on the protocols in which such a certificate
may be used, and anticipates its use by protocols other than the ones
for which it was defined. In an interconnect context the useful
content is typically a service provider code identifying the provider
operating the SIP endpoint. Where a certificate is scoped to
specific telephone numbers, it is issued as a delegate certificate
[RFC9060] whose scope is encompassed by that of its parent.
Of the identifiers a certificate can carry, this profile uses one for
peer verification: the subjectAltName dNSName entry. The
subjectAltName uniformResourceIdentifier entry carrying a "sip" URI,
which [RFC5922] prefers, and the Subject common name are not used.
Telephone number authority is read from the TNAuthList extension and
is never used as a name to match.
4.3. Binding Domain Identity to Telephone Number Authority
A certificate carrying both a domain identifier and telephone number
authority asserts more than either alone only if the two were
validated together. [I-D.wendt-stir-tn-domain-binding] defines that
binding: the issuing certification authority validates control of the
domain and validates an authority token covering the telephone
numbers or service provider codes, and treats the two as a single
condition for issuance. The resulting certificate attests that the
same entity holds both.
Wendt Expires 5 May 2027 [Page 10]
Internet-Draft Securing SIP and RTP with STIR November 2026
This is the property that makes mutual TLS useful between
interconnected networks. Verifying a peer certificate establishes
which domain the peer is, and [RFC5922] already specifies how to
match it. What it does not establish is whether that domain is
entitled to originate traffic for a given provider or set of numbers,
which is why interconnect arrangements are made bilaterally and
enforced by address. A bound certificate carries that authorization
in the credential itself, validated by an issuer against the
numbering authority.
4.4. Certificate Contents
A certificate used under this profile carries the following:
* A subjectAltName dNSName entry containing the SIP domain, as
described above.
* Where telephone number authority is asserted, a TNAuthList
extension [RFC8226], bound to the domain identifier as described
in [I-D.wendt-stir-tn-domain-binding].
* An extended key usage extension [RFC5280] containing id-kp-
serverAuth where the certificate is presented when accepting a
connection, id-kp-clientAuth where it is presented when initiating
one, or both where one certificate is used for both roles.
* A key usage extension containing digitalSignature.
[RFC5924] defines id-kp-sipDomain to mark a certificate as issued for
SIP domain use. Where it is present, it is present in addition to
id-kp-serverAuth and id-kp-clientAuth rather than instead of them,
since a TLS implementation that finds an extended key usage extension
without the key purpose it requires will reject the certificate.
A peer that both accepts and initiates connections, as is normal
where connection reuse is in use, MAY present one certificate
carrying both key purposes or MAY hold two certificates, one for each
role, with the same domain and the same telephone number authority in
each. Both arrangements conform to this profile. The CA/Browser
Forum has moved against issuing publicly trusted certificates
carrying both id-kp-serverAuth and id-kp-clientAuth, and a
certification authority that follows those requirements can issue for
this profile only as two certificates. A certification authority
issuing under [RFC8226] is not bound by those requirements, but
permitting both arrangements lets either kind of issuer support the
profile.
Wendt Expires 5 May 2027 [Page 11]
Internet-Draft Securing SIP and RTP with STIR November 2026
Separate certificates, with separate keying material, MUST be used
for TLS session establishment and for PASSporT signing.
Both certificates may be issued by the same certification authority,
on the basis of the same validated domain control and telephone
number authority, so the separation adds an issuance rather than a
validation. The two keys are held in different places and their
compromise has different consequences, as discussed in Section 12.
The two certificates also differ in profile. A certificate used for
TLS carries the extended key usage values described above, and a
certificate used to sign PASSporTs carries the claim constraints and
validity period appropriate to that use. A single certificate
satisfying both sets of requirements would be constrained by neither.
5. Algorithms and TLS 1.3
5.1. Protocol Versions
[I-D.wendt-sipcore-tls-updates] requires TLS 1.3 [RFC9846] for SIP
and permits TLS 1.2 for interoperability. This profile narrows that
for the interface it covers: TLS 1.3 MUST be used, and earlier
versions MUST NOT be, including TLS 1.2, and including TLS 1.0 and
1.1 which are deprecated in any case [RFC8996]. Cipher suite
selection is determined by TLS 1.3 itself; the recommendations of
[RFC9325] apply where they concern configuration outside the cipher
suite.
This profile describes an interface that is newly deployed rather
than an existing one being retrofitted, and requiring a single
version removes the negotiation and downgrade considerations that
supporting more than one entails. Two of the properties this profile
depends on are available only in TLS 1.3. Ephemeral key agreement is
unconditional, so the forward secrecy that Section 6.2 relies on is a
property of the protocol rather than of the cipher suite selected.
And the hybrid post-quantum key agreement groups referenced in
Section 5.2 are defined for TLS 1.3, so a deployment negotiating an
earlier version cannot meet the key agreement requirements of this
profile.
Existing interconnection interfaces commonly specify TLS 1.2, and
equipment deployed for them may require updating before it can
participate in an interface conforming to this profile.
The version and cipher suite requirements of [RFC3261] predate TLS
1.3 and cannot be satisfied by a conforming TLS 1.3 implementation,
as described in Section 3. Updating them is outside the scope of
this profile and is specified in [I-D.wendt-sipcore-tls-updates].
Wendt Expires 5 May 2027 [Page 12]
Internet-Draft Securing SIP and RTP with STIR November 2026
5.2. Key Agreement
Key agreement determines whether traffic recorded today can be
decrypted later. An adversary that records a TLS session and its
handshake, and that later acquires the ability to solve the
underlying problem the key agreement rests on, recovers the traffic
keys. Ephemeral key exchange does not prevent this, because the
property it provides is protection against later compromise of a long
term key, not against the key agreement itself being broken.
This matters more for SIP than for many applications, because the
confidentiality lifetime of the traffic is long. Call detail,
calling and called numbers, and call patterns retain sensitivity for
many years, and where the media keys are carried in the session
description [RFC4568] the confidentiality of the conversation itself
depends entirely on the protection of the signaling that carried
them.
Implementations SHOULD therefore support a post-quantum key agreement
group and SHOULD negotiate one where both peers support it. Either a
hybrid group, which combines a post-quantum key encapsulation
mechanism with an elliptic curve exchange so that the resulting
secret is no weaker than the classical exchange alone, such as those
defined in [I-D.ietf-tls-ecdhe-mlkem], or a group using a post-
quantum mechanism alone, such as those defined in
[I-D.ietf-tls-mlkem], satisfies this requirement. Which to prefer is
a deployment choice; TLS 1.3 negotiates the group, so peers that
prefer differently still agree on one both support. General guidance
on adopting post-quantum cryptography in TLS based applications is
given in [I-D.ietf-uta-pqc-app].
Where DTLS-SRTP [RFC5763] is used, the media keys are established in
the media plane and the signaling carries only a fingerprint
[RFC8122], from which nothing is recoverable. In that case post-
quantum key agreement on the SIP connection protects signaling but
not media, and equivalent protection of the media requires the same
consideration in the media plane.
5.3. Signature Algorithms and Certificates
Certificates under this profile continue to use classical signature
algorithms. Forging a signature at some future point permits
impersonation from that point forward; it does not permit decryption
of traffic recorded earlier. The retroactive risk lies in key
agreement, not in authentication, and the two can therefore be
addressed on different timescales. This also avoids the
substantially larger certificates and handshakes that post-quantum
signature algorithms currently entail.
Wendt Expires 5 May 2027 [Page 13]
Internet-Draft Securing SIP and RTP with STIR November 2026
Different timescales do not mean authentication can be left as it is.
A signature verified today on a certificate or a PASSporT is relied
on later, in records of which party connected and which party signed
a communication, and an adversary that can later forge the signature
can later dispute or fabricate those records. Section 5.5 sets out
the order in which the transition applies to this interface and what
the signature step depends on.
5.4. Interoperability Considerations
Post-quantum and hybrid key agreement produce larger key shares than
elliptic curve groups, which increases the size of the ClientHello
and can cause it to be split across more than one packet.
Implementations and intermediaries that assume a ClientHello arrives
in a single record or a single datagram may fail in ways that are
difficult to diagnose. SIP interconnection commonly traverses
session border controllers and firewalls, so this population warrants
testing rather than assumption.
An implementation that encounters a key agreement group it does not
recognize is expected to select one it does support rather than to
fail the handshake. Implementations that reject unknown groups
outright prevent peers from offering new ones and should be
identified during interoperability testing.
Early data, or 0-RTT, MUST NOT be used for SIP. Early data is
replayable by design, and SIP requests are not safe to replay.
5.5. The Post-Quantum Transition
[NIST.IR.8547] sets a timeline for moving off the quantum-vulnerable
algorithms in current use: ECDSA, EdDSA, and RSA for signatures, and
ECDH, finite field DH, and RSA for key establishment are deprecated
after 2030 and disallowed after 2035. The equipment deployed under
this profile will be in service across those dates.
Neither the SIPCORE nor the STIR working group is the forum for
selecting post-quantum algorithms or their parameters. That work
belongs to the TLS, LAMPS, and JOSE working groups, to NIST, and to
the CA/Browser Forum for the Web PKI, and it is still settling. This
document therefore does not name post-quantum algorithms beyond the
key agreement groups already referenced in Section 5.2, which are the
part of the picture that has settled enough to deploy. What it does
is state where the transition touches this interface, in what order,
and what each step depends on, so that SIP and STIR follow the Web
PKI as it settles rather than diverging from it.
Wendt Expires 5 May 2027 [Page 14]
Internet-Draft Securing SIP and RTP with STIR November 2026
Key agreement comes first, because it is the retroactive risk.
Signaling and media recorded today can be decrypted later by an
adversary that later obtains the ability to break the key agreement,
and the confidentiality lifetime of call records is long.
Section 5.2 and Section 6.3 already require post-quantum key
agreement where both peers support it. That requirement depends on
nothing outside TLS 1.3 and DTLS 1.3 and can be met now.
Signatures come second. Forging a signature at some future point
permits impersonation and the fabrication of records from that point
forward; it does not permit decryption of traffic already recorded.
The transition can therefore follow the Web PKI's, and it has more
dependencies: a post-quantum signature algorithm registered for X.509
by LAMPS, a certificate profile for STI certificates that permits it,
a JOSE algorithm registration so that PASSporTs can be signed with
it, and TLS signature scheme registrations for the handshake. The
larger certificates and signatures that post-quantum algorithms
entail also bear on SIP in a way they do not bear on the web: a
PASSporT travels in a SIP header field, and the certificate chain in
a TLS handshake traverses session border controllers with their own
size limits. Those effects need measurement before a requirement is
written.
Certificate transparency is part of the signature transition. STI
certificate transparency [I-D.ietf-stir-certificate-transparency] is
built on [RFC6962], whose log signatures and Merkle tree hashes are
classical. The IETF's work on post-quantum transparency logs, in the
PLANTS working group, is where that transition is being worked out,
and STI certificate transparency is expected to follow it rather than
define its own.
Implementations under this profile SHOULD be built so that the
signature algorithm, the key agreement group, and the certificate
chain size they accept are configurable rather than fixed, and SHOULD
support the negotiation mechanisms that let a peer offer a new
algorithm without failing the handshake with a peer that lacks it, as
described in Section 5.4. That is the property that lets the
transition proceed by configuration when the dependencies above are
met.
6. Securing the Media
6.1. Media Security Baseline
Media across the interface MUST be protected using SRTP [RFC3711].
Two mechanisms for establishing the SRTP keys are in use, and both
are supported by this profile.
Wendt Expires 5 May 2027 [Page 15]
Internet-Draft Securing SIP and RTP with STIR November 2026
Signaling anchored keying, using security descriptions carried in the
session description [RFC4568], places the SRTP master keys in the SIP
signaling. It is the mechanism in general use at interconnection
interfaces today. Where it is used, every element on the signaling
path holds the media keys, and the confidentiality of the media is
therefore no stronger than the protection of the signaling on every
hop that carries it.
Media anchored keying, using DTLS-SRTP [RFC5763] [RFC5764],
establishes the SRTP keys through a handshake on the media path. The
signaling carries only a fingerprint of the endpoint credential
[RFC8122], from which the keys cannot be derived.
Either mechanism MAY be used. Both provide equivalent protection of
the media against an attacker on the interface itself when the
requirements of this profile are met. They differ in how far the
keying material propagates beyond that interface, and in operational
cost. Section 6.2 sets out both so that a deployment can select on
the basis of what it is exposed to. Where signaling anchored keying
is used, the requirements of Section 6.3 apply.
Where a peer is not known to support media protection at all,
[RFC8643] MAY be used to negotiate it opportunistically. This is a
transitional measure for moving deployments away from unprotected
media, not a durable configuration, and it provides no protection
against an attacker able to modify the signaling.
This document does not define SRTP transforms. A transform is the
pair of algorithms SRTP applies to each packet, one to encrypt the
payload and one to authenticate the packet, and the transforms
available are defined separately from the keying mechanisms that
establish the master key. [RFC3711] defines AES in counter mode with
HMAC-SHA1 authentication, [RFC6188] adds AES with 192 and 256 bit
keys in counter mode, and [RFC7714] defines AES-GCM, in which
encryption and authentication are performed as a single authenticated
encryption operation. Further transforms are under development in
the IETF.
A transform is not negotiated directly. It is selected through a
named set that also fixes the key length, the salt length, and the
length of the authentication tag: a crypto suite where security
descriptions are used [RFC4568], or a protection profile where DTLS-
SRTP is used [RFC5764]. Both are registered with IANA.
The transform in most common use at interconnection interfaces today,
AES_CM_128_HMAC_SHA1_80, authenticates packets with HMAC-SHA1. SHA-1
has been withdrawn by NIST and is no longer considered secure.
Implementations MUST support an AES-GCM transform [RFC7714] and
Wendt Expires 5 May 2027 [Page 16]
Internet-Draft Securing SIP and RTP with STIR November 2026
SHOULD negotiate it where both peers support it. Where an HMAC-SHA1
transform is negotiated for interoperability with a peer that
supports nothing else, the deployment accepts that packet
authentication rests on a withdrawn algorithm. A transform that does
not rest on SHA-1 for either function is expected from the IETF, and
this profile will reference it when it is available.
6.2. Properties of the Two Mechanisms
The two mechanisms are equivalent in most respects and differ in one
that is a security property and two that are operational. A
deployment selects between them on the basis of what it is exposed
to, and both are permitted by this profile.
The difference is smaller at this interface than the design of media
anchored keying suggests. Media anchored keying was specified for
use with SIP, but its mandatory use and its deployment at scale
followed from browser based communications, in which the signaling is
carried by a party that is not a party to the media [RFC8827]. In
that arrangement, keys placed in the signaling are disclosed to the
signaling party by construction, and withholding them from the
signaling is the property the mechanism exists to provide. At the
interface described here the two parties to the signaling are the two
parties to the media, and no third party is present in the signaling
path from which keys need to be withheld. That property is therefore
already provided by the topology, and the differences that remain are
the ones described below.
Arrangements in which media is exchanged among more than two elements
are a further reason media anchored keying is preferred in SIP
deployments generally. Conference mixing, announcement and
interactive response functions, recording, and transcoding introduce
media paths that differ from the signaling path and involve elements
that are not parties to the signaling. Those functions are performed
within a provider's network, on legs other than the interconnection
leg. The media association for a communication crossing the
interface described here is between two elements. Where an
intermediary is present at the interface itself, as in an arrangement
where one provider receives traffic on behalf of another, that
element terminates the association and re-originates it, which
produces a sequence of two party legs rather than a media path shared
among several elements.
Wendt Expires 5 May 2027 [Page 17]
Internet-Draft Securing SIP and RTP with STIR November 2026
6.2.1. Protection Across the Interface
Where the signaling is protected as required by this profile, with
TLS 1.3, mutual authentication, and ephemeral key agreement on every
hop, the two mechanisms protect the media across the interface
equally.
In both cases the keys are held by the two border elements, which are
the endpoints of the interface and hold the media in the clear
regardless, so neither protects a provider against its peer. In both
cases the channel that establishes or carries the keys provides
forward secrecy, so an adversary that later obtains a long term
private key recovers neither. In both cases the residual exposure is
to a break of the key agreement itself, which is addressed for both
by the requirements of Section 5.
Neither mechanism therefore offers better protection than the other
against an attacker observing the interface.
6.2.2. Propagation of Keying Material Beyond the Interface
At this interface the signaling and the media are exchanged between
the same two border elements, and commonly over the same path. An
attacker positioned on that path observes both under either
mechanism, and what it observes of the signaling is protected by TLS
in both cases. The mechanisms therefore do not differ in what they
expose to an attacker on the path.
They differ in where the keying material exists after the exchange.
Under media anchored keying the signaling carries only a fingerprint
of the endpoint credential, from which no key can be derived, and the
keys exist only in the elements that terminate the media. Under
signaling anchored keying the keys are carried in the session
description, and are therefore present wherever that signaling is
present. Signaling is captured for tracing, retained for operational
and regulatory purposes, and exported to monitoring, analytics, and
accounting systems as a matter of ordinary operation. The keys
consequently exist in data whose lifetime is unrelated to the
duration of the communication and in systems that have no role in
handling media.
Wendt Expires 5 May 2027 [Page 18]
Internet-Draft Securing SIP and RTP with STIR November 2026
The exposure this creates is compound rather than positional. An
attacker that captures media from the path, and that at any later
time obtains the corresponding signaling from a system that retained
or received it, recovers the media. Capture from the path alone is
not sufficient, and access to the retained signaling alone is not
sufficient. Under media anchored keying the second does not assist
the first, and media captured from the path remains unrecoverable
regardless of what signaling is subsequently obtained.
Signaling anchored keying also couples the two planes. Any failure
to protect the signaling on any hop that carries the keys is a
failure of media confidentiality, whereas under media anchored keying
a compromise of the signaling discloses the fact and the parties of a
communication but not its content.
The requirements of Section 6.3 apply to the interface, but the
handling of signaling within each provider's own network is outside
the scope of this profile, and signaling is commonly carried there
without protection. The condition on which signaling anchored keying
depends is therefore one a deployment can satisfy at the interface
and cannot verify beyond it. Media anchored keying does not depend
on that condition.
6.2.3. Operational Cost
Media anchored keying requires a handshake on the media path before
media can flow. This adds to the delay before a communication is
established and must be performed for every communication, which at
interconnection volumes is a material load on the border element.
Signaling anchored keying adds nothing beyond the signaling already
exchanged.
Authenticated encryption transforms bound the amount of data that may
be protected under a single key, and long lived communications may
approach that bound. Media anchored keying can rekey within the
media plane. Signaling anchored keying requires a new offer and
answer, which deployments are correspondingly less likely to perform.
6.2.4. Selecting a Mechanism
A deployment whose interface traverses the public internet, or whose
signaling is retained, exported, or handled beyond the interface in
ways it cannot constrain, is exposed to the propagation described
above and should weigh it accordingly. A deployment for which call
setup delay or handshake load at the border is the dominant
constraint, or which interconnects with peers that do not support
DTLS-SRTP, has a corresponding reason to use signaling anchored
keying.
Wendt Expires 5 May 2027 [Page 19]
Internet-Draft Securing SIP and RTP with STIR November 2026
Both mechanisms are in use and both are permitted here. What this
profile requires in either case is that the protection on which the
chosen mechanism depends is actually present: for signaling anchored
keying, that every hop carrying the keys is protected as required by
Section 6.3, and for both, that the key agreement protecting the
communication meets the requirements of Section 5.
6.3. Requirements for Signaling Anchored Keying
Where security descriptions [RFC4568] are used to establish SRTP
keys, every signaling hop that carries the keys MUST be protected as
described in Section 5. A deployment MUST NOT carry security
descriptions over an unprotected signaling hop, and MUST NOT accept
them on one.
Because the media keys are present in the signaling, they are
available to every element on the signaling path. A deployment using
signaling anchored keying accepts that the confidentiality of the
media extends only to parties outside that set of elements.
6.4. Relationship to the Existing Best Practice
[RFC8862] defines the current best practice for securing media
signaled with SIP, and this profile does not replace it. Where its
conditions can be met, the binding it defines, in which a PASSporT
carrying the mky claim protects the fingerprints in the session
description, remains the strongest available assurance that the keys
exchanged in the media plane are those the authenticated originator
intended.
Two of its assumptions do not hold in telephone network
interconnection. It places the authentication and verification
service roles in the user agents, whereas in interconnection those
roles are commonly performed by provider infrastructure. And it
observes that few certification authorities issue certificates for
telephone numbers, which is no longer the case: the credential
described in Section 4 is issued for exactly that purpose and is
chained to an authority for the numbers concerned.
The consequence is that the fingerprint binding of [RFC8862] can be
performed using the same credential that authenticates the signaling
peer and that carries telephone number authority. Where the media
security association is not terminated between the signing entity and
the verifying entity, this yields an assurance about the media that
is anchored in the same certificate as the assurance about the
identity.
Wendt Expires 5 May 2027 [Page 20]
Internet-Draft Securing SIP and RTP with STIR November 2026
6.5. Key Agreement for Media
The DTLS handshake that establishes SRTP keys is subject to the same
consideration described in Section 5.2 for signaling. An adversary
that records the handshake and the media, and that later acquires the
ability to break the key agreement, recovers the media keys and
therefore the conversation.
Implementations SHOULD support DTLS 1.3 [RFC9147] for DTLS-SRTP, and
SHOULD negotiate a hybrid post-quantum key agreement group where both
peers support it.
Which key agreement protects the conversation depends on the keying
mechanism. Under media anchored keying it is the one in the media
handshake, and protecting the signaling alone does not protect the
media. Under signaling anchored keying it is the one on every
signaling hop that carries the keys, and a recorded communication is
recovered in full if that key agreement is broken, since the media
keys were carried within it. This is a difference in the number of
operations an adversary performs rather than in the capability it
requires: an adversary able to break the key agreement protecting the
signaling is able to break the one protecting the media handshake,
and where both are recorded from the same path, media anchored keying
requires it to break the second as well rather than presenting a
different obstacle. The requirement in this section applies to both
handshakes for that reason.
6.6. Termination of Media Security Associations
An assurance about media that is anchored at an originating endpoint
is lost wherever an element terminates the media security association
and re-originates the media, as described in [RFC7879]. This is the
principal reason that end to end media security has not been achieved
in telephone networks, and it is why [RFC8862] observes that only hop
by hop confidentiality is available in many deployments.
Within the scope of this profile the difficulty does not arise. The
two border elements are the endpoints of the interface being
protected, and no element lies between them to terminate the
association. The assurance this profile provides is an assurance
about one interface, established between the two providers that
operate its endpoints.
An assurance that survives termination by an intermediary, and
therefore extends across more than one interface or into a provider's
own network, is a different problem. It is identified in Section 8
and is not addressed here.
Wendt Expires 5 May 2027 [Page 21]
Internet-Draft Securing SIP and RTP with STIR November 2026
6.7. Keying Mechanisms and Deployed Equipment
The two keying mechanisms are affected differently by the move to TLS
1.3 and by the post-quantum transition, and the difference reverses
the usual ordering of their strength for the time being.
Under signaling anchored keying, the media keys travel in the
signaling, so whatever protects the SIP connection protects them. A
border element that negotiates TLS 1.3 with a post-quantum key
agreement group on its SIP connection has, by that act alone,
protected the SRTP keys against later recovery. Nothing changes on
the media path: the SRTP transform, the packet format, and the media
gateway behind the border element are untouched. The exposure that
remains is the one Section 6.3 describes, that every element on the
signaling path holds the keys.
Under media anchored keying, the media keys come from the DTLS
handshake on the media path, and the protection of the SIP connection
does not reach them. Until that handshake runs DTLS 1.3 with a post-
quantum key agreement group, the media is protected by DTLS 1.2 key
agreement, which is exactly the recorded-now-recovered-later exposure
that Section 5.2 addresses for signaling. For the present,
therefore, signaling anchored keying over a TLS 1.3 connection with
post-quantum key agreement gives stronger protection against that
attack than DTLS-SRTP as deployed, while DTLS-SRTP retains its
advantage of keeping the keys off the signaling path. A deployment
choosing between them should weigh which of the two it is more
exposed to.
What has to change in deployed equipment follows from this. For
signaling anchored keying, the border element's TLS stack is the only
thing that changes: TLS 1.3, the post-quantum key agreement groups,
and the larger ClientHello they produce (Section 5.4). Media
gateways and session border controllers that terminate SRTP need, at
most, support for an authenticated encryption transform in place of
HMAC-SHA1 (Section 6.1), which is a transform change rather than a
keying change. For media anchored keying, the DTLS-SRTP
implementation in the media path, which in telephone networks is a
session border controller or media gateway rather than an endpoint,
has to move to DTLS 1.3 and carry the same post-quantum groups, and
the specification gap identified in Section 8 has to be closed first
so that implementers converge on one behavior. That is a larger
change, to equipment with longer replacement cycles than the border
element's TLS stack, and it is why this profile treats post-quantum
key agreement on the media handshake as a SHOULD that follows the
signaling rather than a requirement that can be met now.
Wendt Expires 5 May 2027 [Page 22]
Internet-Draft Securing SIP and RTP with STIR November 2026
7. Media Resilience
Telephone network interconnection increasingly traverses paths that
are not engineered for loss, while the RTP profile in common use for
interconnection predates the mechanisms developed for such paths.
[RFC8834] profiles the use of RTP for browser based communications,
and requires feedback and resilience mechanisms that interconnection
deployments generally do not negotiate.
The following are applicable to interconnected voice and are not
precluded by anything in this profile:
* Codec level redundancy, where the codec provides it. The in band
forward error correction of Opus [RFC6716] recovers isolated
losses at low cost, and is effective for speech where the codec is
available.
* Redundant encoding [RFC2198], which carries earlier payloads
alongside current ones and is generally more efficient for speech
than generic forward error correction.
* Generic forward error correction [RFC8627], which is applicable
but carries higher overhead for the packet sizes typical of voice.
* RTCP feedback [RFC4585], and the corresponding profile for use
with SRTP [RFC5124], without which a sender has no timely
indication of loss and no basis for adaptation.
Two constraints govern whether these are useful in practice. The
first is codec availability: interconnection continues to carry a
large volume of traffic using codecs that provide no in band
redundancy, and the resilience available to such traffic is limited
to mechanisms applied above the codec. The second is intermediary
behavior: elements that transcode, that do not pass unrecognized
payload types, or that do not forward RTCP feedback will defeat these
mechanisms regardless of what the endpoints negotiate.
Negotiation is where these mechanisms most often fail in practice
rather than in their operation. This is the same pattern described
for certificate identity in Section 3, and it is identified in
Section 8 accordingly.
8. Identified Protocol Gaps
The preceding sections describe what can be adopted as it stands and
what this profile constrains. This section identifies where existing
specifications require change, which this document does not
undertake.
Wendt Expires 5 May 2027 [Page 23]
Internet-Draft Securing SIP and RTP with STIR November 2026
The TLS version and cipher suite requirements of [RFC3261], and the
certificate identity rules of [RFC5922], cannot be reconciled with
current TLS practice by profiling alone. Updates to both are
specified in [I-D.wendt-sipcore-tls-updates].
The authorization of an authenticated peer, as distinct from its
authentication, has no specification for SIP. [RFC5922] defines how
a peer domain is matched but not how a receiving network determines
that the domain is entitled to originate for a given provider or set
of telephone numbers. This profile addresses that through the
credential described in Section 4; whether a corresponding SIP level
mechanism is required is left open.
An identity assurance about media that survives termination of the
media security association by an intermediary is not available.
Whether one can be defined, and at what layer, is a question this
profile identifies rather than answers.
The use of DTLS-SRTP with DTLS 1.3 is not specified. [RFC5764] and
the fingerprint handling of [RFC8842] were written against DTLS 1.2
[RFC6347], and the SRTP protection profiles and the use_srtp
extension have not been restated for DTLS 1.3 [RFC9147], whose record
layer and key schedule differ. The key exporter that [RFC5764]
relies on survives in DTLS 1.3, so the mechanism is expected to carry
over, but an implementer following the published specifications
arrives at DTLS 1.2, and that is what deployed implementations run.
The consequence for this profile is stated in Section 6.7.
Several choices in this profile are about TLS and DTLS rather than
about SIP, and are best judged by the working group responsible for
those protocols. The TLS working group's review is sought on:
requiring TLS 1.3 alone at a newly deployed interface; the treatment
of post-quantum key agreement in Section 5.2, Section 5.5, and
Section 6.7, including whether hybrid and pure groups should both be
permitted; the client authentication and connection management
choices of Section 10, which follow from the removal of
renegotiation; the prohibition of early data; and the DTLS 1.3 gap
above. Review by the working groups responsible for SRTP and for the
DTLS-SRTP specifications is sought on the transform and keying
questions of Section 6.1 and Section 6.7. The STIR working group is
where the certificate and algorithm dependencies identified in
Section 5.5 are coordinated, since the certificates are STIR
certificates; the SIP transport changes that this profile narrows are
the subject of [I-D.wendt-sipcore-tls-updates] in SIPCORE.
Wendt Expires 5 May 2027 [Page 24]
Internet-Draft Securing SIP and RTP with STIR November 2026
The negotiation of media resilience mechanisms for interconnection,
and the behavior of intermediaries with respect to them, may require
a profile or protocol work in the working group responsible for RTP.
This document identifies the requirement and does not specify it.
9. Mutual TLS and Peer Authorization
At the interface described by this profile both peers are providers,
and each has the same interest in knowing which provider it is
exchanging traffic with. Connections between border elements MUST
therefore be mutually authenticated. The element initiating the
connection MUST present a certificate conforming to Section 4, and
the element accepting the connection MUST request one and MUST verify
it.
9.1. Authentication
A peer verifying a presented certificate MUST validate the
certification path to a trust anchor it accepts, and MUST verify that
the domain of the peer it expected to reach matches a dNSName entry
in the certificate, applying the rules referenced in Section 4.1.
Both steps are required. Validating the path alone establishes only
that a certification authority the verifier trusts issued the
certificate to some party, and for a widely trusted authority that is
a large set of parties. A deployment that requests a client
certificate but does not verify the name within it will accept any
peer holding a certificate from any accepted authority. This
configuration is known to occur.
An accepting element MAY use the certificate authorities extension of
the TLS CertificateRequest message [RFC9846] to indicate the trust
anchors it accepts, which allows an initiating element that holds
more than one certificate to present the appropriate one.
9.2. Authorization
Authentication corroborates the domain of the peer. It does not
establish that the peer is entitled to send the traffic it is
sending. That is a separate determination, and one for which SIP
provides no mechanism.
Wendt Expires 5 May 2027 [Page 25]
Internet-Draft Securing SIP and RTP with STIR November 2026
Where the presented certificate carries a TNAuthList extension
[RFC8226] bound to the domain identifier as described in
[I-D.wendt-stir-tn-domain-binding], the service provider code it
contains identifies the provider operating the peer, as validated by
the issuer rather than as asserted by the peer. An accepting element
MAY use that value to determine whether the peer is one with which it
has an interconnection relationship, and to apply the policy
associated with that relationship.
This is a determination about the provider operating the interface.
It is not a determination about the telephone numbers of any
individual communication, which remains the function of the STIR
credential presented with that communication. An accepting element
that applies both MAY require consistency between them, treating a
communication whose signing credential is unrelated to the
authenticated peer as a matter for local policy.
9.3. Interconnection Without Prior Arrangement
This profile supports interconnection in which two providers exchange
traffic without a bilateral arrangement established in advance.
Where interconnection is bilateral, a provider authorizes a peer from
local configuration: an address range, a pinned certificate, or a
trust anchor provisioned for that peer. A provider receiving a
connection from a participant with which it has not previously
exchanged traffic has no such configuration to consult.
Authorization therefore derives from the credential. A provider
presenting a certificate that conforms to Section 4 and validates to
a trust anchor the receiving provider accepts has demonstrated to its
issuer control of the domain it presents and authority over the
telephone numbers or service provider code the certificate asserts
[I-D.wendt-stir-tn-domain-binding]. The set of trust anchors the
participants accept in common determines the set of providers able to
interconnect. The criteria under which certificates are issued and
revoked are determined by the authority operating the certification
hierarchy and are outside the scope of this document.
Two consequences follow for an element implementing this profile. A
participant is excluded by revocation of its certificate, or by the
issuer declining to reissue it where short lived certificates are
used, rather than by a configuration change at every peer. And
validating a presented certificate does not oblige a provider to
carry the traffic; local policy continues to apply, and a provider
may decline traffic from an authenticated participant on any grounds.
Wendt Expires 5 May 2027 [Page 26]
Internet-Draft Securing SIP and RTP with STIR November 2026
9.4. Trust Anchors
Certificates presented at this interface MUST be issued by a
certification authority operating under [RFC8226], and an element
MUST NOT accept a certificate for this interface on the basis of a
trust anchor from a certification hierarchy that does not issue under
[RFC8226].
A certificate used here carries telephone number authority in a
TNAuthList extension, co-validated with a domain identifier
[I-D.wendt-stir-tn-domain-binding]. A certification authority that
validates only control of a domain does not validate authority over
telephone numbers and cannot issue a certificate carrying that
assertion. Accepting a trust anchor from such a hierarchy would
admit any party that has demonstrated control of any domain.
An element SHOULD be able to add a trust anchor in advance of its
use, rather than in response to a handshake failure.
9.5. Limiting Issuance for an Interface Domain
A provider that operates its interface under a domain can limit which
certification authorities may issue certificates for that domain, and
through which ACME account, by publishing a CAA record [RFC8659].
[I-D.wendt-stir-tn-domain-binding] defines the issuesti Property Tag
for bound certificates, with the accounturi and validationmethods
parameters of [RFC8657], and a certification authority issuing a
bound certificate for use under this profile processes it as that
document specifies. The issue and issuewild Properties of [RFC8659]
do not govern these certificates, following the approach of issuemail
[RFC9495], so a provider's existing CAA records for its Web PKI
certificates neither block nor authorize them.
Where domain control is validated with a standing record, as with the
dns-persist-01 challenge [I-D.ietf-acme-dns-persist] that
[I-D.wendt-stir-tn-domain-binding] lists, the CAA record and the
validation record together name the certification authority and
account the provider has authorized, in two records at the provider's
domain.
10. Connection Management
The items in this section are consequences of using the certificate
for mutual authentication rather than properties of SIP over TLS
generally. Connection reuse requires both peers to be authenticated,
which requires the client certificate, which TLS 1.3 requires in the
initial handshake.
Wendt Expires 5 May 2027 [Page 27]
Internet-Draft Securing SIP and RTP with STIR November 2026
10.1. Connection Reuse
Connection reuse [RFC5923] allows a connection established in one
direction to carry requests in the other, and requires that both
peers be authenticated. That condition is met by Section 9, so reuse
is applicable across this interface and SHOULD be used, since
establishing a connection per direction doubles the handshake load
and the number of connections to be maintained without adding any
property.
An element that reuses a connection applies the authorization
determination of Section 9 to requests received on it in either
direction. The authenticated identity of the peer does not change
with the direction of a request.
10.2. Client Authentication and the Handshake
In TLS 1.3 a server cannot obtain a client certificate by
renegotiating an established connection, as renegotiation does not
exist. An accepting element that requires client authentication MUST
therefore request the certificate in the initial handshake. Post-
handshake authentication is defined by [RFC9846] but is not widely
implemented, and this profile does not rely on it.
Early data MUST NOT be used, as stated in Section 5.4.
10.3. Long Lived Connections
Connections between border elements are typically long lived, while
the certificates used to establish them are not, particularly where
the practices described in Section 11 are followed. Expiry of a
certificate does not invalidate a connection already established
under it, and an element SHOULD NOT tear down an established
connection solely because the certificate that authenticated it has
expired. The renewed certificate is presented at the next handshake.
An element SHOULD perform a TLS key update on a long lived connection
in accordance with the limits applicable to the negotiated cipher
suite.
10.4. Server Name Indication
Where a border element serves more than one domain on a single
address, an initiating element SHOULD include the server name
indication extension [RFC6066] carrying the domain it intends to
reach, so that the accepting element can present the corresponding
certificate. An accepting element that serves a single domain does
not depend on it, and MUST NOT reject a connection solely because it
Wendt Expires 5 May 2027 [Page 28]
Internet-Draft Securing SIP and RTP with STIR November 2026
is absent.
11. Operational Considerations
Certificates used for TLS under this profile are expected to be
short-lived, as described in [I-D.ietf-stir-certificates-shortlived],
and a border element renews its TLS certificate on the same cadence
as its signing certificate. Renewal does not interrupt established
connections (Section 10).
Further operational considerations will be added as the profile is
reviewed.
12. Security Considerations
This profile relies on the security properties of TLS 1.3 [RFC9846],
SRTP [RFC3711], DTLS-SRTP [RFC5763], and STIR certificates [RFC8226],
and on the binding of domain identity to telephone number authority
[I-D.wendt-stir-tn-domain-binding]. The considerations of those
documents, and of [RFC9325] and [RFC9525], apply.
Separate keys for TLS and for PASSporT signing are required because
the two are held in different places and their compromise has
different consequences. A TLS key is present on every border
element, the most exposed and widely distributed part of a
deployment, and its compromise permits impersonation at the transport
layer until the certificate expires. A signing key asserts authority
over telephone numbers, and its compromise permits an attacker to
originate signed communications from any number within the
certificate's scope. Using one key for both places the second
consequence on every element that terminates TLS.
The transform in common use for SRTP at interconnection interfaces
authenticates packets with HMAC-SHA1, which NIST has withdrawn.
Section 6.1 requires support for an authenticated encryption
transform for that reason, and a replacement for the HMAC-SHA1
transforms is needed from the IETF.
Further security considerations will be added as the profile is
reviewed.
13. IANA Considerations
This document has no IANA actions.
Wendt Expires 5 May 2027 [Page 29]
Internet-Draft Securing SIP and RTP with STIR November 2026
14. Acknowledgments
Thanks to Russ Housley for his review of this document.
15. References
15.1. Normative References
[I-D.wendt-sipcore-tls-updates]
Wendt, C., "TLS 1.3 and Certificate Identity for the
Session Initiation Protocol", Work in Progress, Internet-
Draft, draft-wendt-sipcore-tls-updates-00, 1 November
2026, <https://datatracker.ietf.org/doc/html/draft-wendt-
sipcore-tls-updates-00>.
[I-D.wendt-stir-tn-domain-binding]
Wendt, C., "Binding a Domain Identifier to Telephone
Number Authorization in STIR Certificates", Work in
Progress, Internet-Draft, draft-wendt-stir-tn-domain-
binding-02, 1 November 2026,
<https://datatracker.ietf.org/doc/html/draft-wendt-stir-
tn-domain-binding-02>.
[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>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, July 2002,
<https://www.rfc-editor.org/rfc/rfc3261>.
[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>.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, DOI 10.17487/RFC5922, June 2010,
<https://www.rfc-editor.org/rfc/rfc5922>.
[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>.
Wendt Expires 5 May 2027 [Page 30]
Internet-Draft Securing SIP and RTP with STIR November 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>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/rfc/rfc9325>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/rfc/rfc9525>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
15.2. Informative References
[I-D.ietf-acme-dns-persist]
Heurich, S., Birge-Lee, H., and M. Slaughter, "Automated
Certificate Management Environment (ACME) Challenge for
Persistent DNS TXT Record Validation", Work in Progress,
Internet-Draft, draft-ietf-acme-dns-persist-02, 20
September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-acme-dns-persist-02>.
[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-
05, 21 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-stir-
certificate-transparency-05>.
[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>.
Wendt Expires 5 May 2027 [Page 31]
Internet-Draft Securing SIP and RTP with STIR November 2026
[I-D.ietf-tls-ecdhe-mlkem]
Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
for TLSv1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-ecdhe-mlkem-05, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ecdhe-mlkem-05>.
[I-D.ietf-tls-mlkem]
Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
mlkem-11, 16 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
mlkem-11>.
[I-D.ietf-uta-pqc-app]
Reddy.K, T. and H. Tschofenig, "Post-Quantum Cryptography
Recommendations for TLS-based Applications", Work in
Progress, Internet-Draft, draft-ietf-uta-pqc-app-03, 4
July 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-uta-pqc-app-03>.
[NIST.IR.8547]
National Institute of Standards and Technology,
"Transition to Post-Quantum Cryptography Standards",
NIST IR 8547, October 2026,
<https://csrc.nist.gov/pubs/ir/8547/final>.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J.C., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997,
<https://www.rfc-editor.org/rfc/rfc2198>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, July 2002,
<https://www.rfc-editor.org/rfc/rfc3263>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/rfc/rfc3711>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<https://www.rfc-editor.org/rfc/rfc4568>.
Wendt Expires 5 May 2027 [Page 32]
Internet-Draft Securing SIP and RTP with STIR November 2026
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/rfc/rfc4585>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/rfc/rfc5124>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630,
DOI 10.17487/RFC5630, October 2009,
<https://www.rfc-editor.org/rfc/rfc5630>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/rfc/rfc5763>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/rfc/rfc5764>.
[RFC5923] Gurbani, V., Ed., Mahy, R., and B. Tate, "Connection Reuse
in the Session Initiation Protocol (SIP)", RFC 5923,
DOI 10.17487/RFC5923, June 2010,
<https://www.rfc-editor.org/rfc/rfc5923>.
[RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for
Session Initiation Protocol (SIP) X.509 Certificates",
RFC 5924, DOI 10.17487/RFC5924, June 2010,
<https://www.rfc-editor.org/rfc/rfc5924>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/rfc/rfc6066>.
Wendt Expires 5 May 2027 [Page 33]
Internet-Draft Securing SIP and RTP with STIR November 2026
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure
RTP", RFC 6188, DOI 10.17487/RFC6188, March 2011,
<https://www.rfc-editor.org/rfc/rfc6188>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
September 2012, <https://www.rfc-editor.org/rfc/rfc6716>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
[RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
in the Secure Real-time Transport Protocol (SRTP)",
RFC 7714, DOI 10.17487/RFC7714, December 2015,
<https://www.rfc-editor.org/rfc/rfc7714>.
[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
<https://www.rfc-editor.org/rfc/rfc7879>.
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017,
<https://www.rfc-editor.org/rfc/rfc8122>.
[RFC8627] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP
Payload Format for Flexible Forward Error Correction
(FEC)", RFC 8627, DOI 10.17487/RFC8627, July 2019,
<https://www.rfc-editor.org/rfc/rfc8627>.
[RFC8643] Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T.
Stach, "An Opportunistic Approach for Secure Real-time
Transport Protocol (OSRTP)", RFC 8643,
DOI 10.17487/RFC8643, August 2019,
<https://www.rfc-editor.org/rfc/rfc8643>.
[RFC8657] Landau, H., "Certification Authority Authorization (CAA)
Record Extensions for Account URI and Automatic
Certificate Management Environment (ACME) Method Binding",
RFC 8657, DOI 10.17487/RFC8657, November 2019,
<https://www.rfc-editor.org/rfc/rfc8657>.
Wendt Expires 5 May 2027 [Page 34]
Internet-Draft Securing SIP and RTP with STIR November 2026
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
"DNS Certification Authority Authorization (CAA) Resource
Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
<https://www.rfc-editor.org/rfc/rfc8659>.
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
DOI 10.17487/RFC8827, January 2021,
<https://www.rfc-editor.org/rfc/rfc8827>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
January 2021, <https://www.rfc-editor.org/rfc/rfc8834>.
[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)",
RFC 8842, DOI 10.17487/RFC8842, January 2021,
<https://www.rfc-editor.org/rfc/rfc8842>.
[RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices
for Securing RTP Media Signaled with SIP", BCP 228,
RFC 8862, DOI 10.17487/RFC8862, January 2021,
<https://www.rfc-editor.org/rfc/rfc8862>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/rfc/rfc8996>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9495] Bonnell, C., "Certification Authority Authorization (CAA)
Processing for Email Addresses", RFC 9495,
DOI 10.17487/RFC9495, October 2023,
<https://www.rfc-editor.org/rfc/rfc9495>.
Author's Address
Chris Wendt
Somos, Inc.
United States of America
Email: chris@appliedbits.com
Wendt Expires 5 May 2027 [Page 35]