rfc9060xml2.original.xml   rfc9060.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="utf-8"?>
<!--
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-acme-star SYSTEM "http://xml.resource.org/public/rfc/bibxml3/r <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
eference.I-D.ietf-acme-star.xml">
<!ENTITY I-D.ietf-acme-authority-token SYSTEM "http://xml.resource.org/public/rf
c/bibxml3/reference.I-D.ietf-acme-authority-token.xml">
<!ENTITY I-D.ietf-acme-authority-token-tnauthlist SYSTEM "http://xml.resource.or
g/public/rfc/bibxml3/reference.I-D.ietf-acme-authority-token-tnauthlist.xml">
<!ENTITY I-D.ietf-tls-subcerts SYSTEM "http://xml.resource.org/public/rfc/bibxml
3/reference.I-D.ietf-tls-subcerts.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3261.xml">
<!ENTITY RFC7340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7340.xml">
<!ENTITY RFC7375 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7375.xml">
<!ENTITY RFC8224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8224.xml">
<!ENTITY RFC8225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8225.xml">
<!ENTITY RFC8226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8226.xml">
<!ENTITY RFC8555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8555.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5280.xml">
<!ENTITY RFC3647 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3647.xml">
<!ENTITY RFC6480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6480.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3986.xml">
]>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-stir-cert-delegation-04"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-stir-cert-delegation-04" ipr="trust200902" obsoletes="" upd ates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRe fs="true" sortRefs="true" version="3" number="9060">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="STIR Certificate Delegation">Secure Telephone Identity Revisi
if the full title is longer than 39 characters --> ted (STIR) Certificate Delegation</title>
<seriesInfo name="RFC" value="9060"/>
<title abbrev="STIR Cert Delegation">STIR Certificate Delegation</title> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="Neustar">Neustar, Inc.</organization>
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <address>
<organization abbrev="Neustar">Neustar, Inc.</organization> <email>jon.peterson@team.neustar</email>
<address> </address>
<email>jon.peterson@team.neustar</email> </author>
</address> <date year="2021" month="September"/>
</author>
<date year="2021" />
<!-- <area>
ART
</area>-->
<keyword>SIP</keyword> <keyword>SIP</keyword>
<keyword>Secure Origin Identification</keyword> <keyword>Secure Origin Identification</keyword>
<keyword>Communication Security</keyword> <keyword>Communication Security</keyword>
<keyword>Certificates</keyword> <keyword>Certificates</keyword>
<keyword>Public Key Infrastructure</keyword> <keyword>Public Key Infrastructure</keyword>
<keyword>Real-Time Communication</keyword> <keyword>Real-Time Communication</keyword>
<abstract> <abstract>
<t> <t>
The Secure Telephone Identity Revisited (STIR) certificate profile provide s a way to attest authority over telephone numbers and related identifiers for t he purpose of preventing telephone number spoofing. This specification details h ow that authority can be delegated from a parent certificate to a subordinate ce rtificate. This supports a number of use cases, including those where service pr oviders grant credentials to enterprises or other customers capable of signing c alls with STIR. The Secure Telephone Identity Revisited (STIR) certificate profile provide s a way to attest authority over telephone numbers and related identifiers for t he purpose of preventing telephone number spoofing. This specification details h ow that authority can be delegated from a parent certificate to a subordinate ce rtificate. This supports a number of use cases, including those where service pr oviders grant credentials to enterprises or other customers capable of signing c alls with STIR.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<section title="Introduction"> <t>The <xref target="RFC7340" format="default">STIR problem statement</xre
f> reviews the difficulties facing the telephone network that are enabled by imp
<t>The <xref target="RFC7340">STIR problem statement</xref> reviews the diff ersonation, including various forms of robocalling, voicemail hacking, and swatt
iculties facing the telephone network that are enabled by impersonation, includi ing <xref target="RFC7375" format="default"/>. One of the most important compone
ng various forms of robocalling, voicemail hacking, and swatting <xref target="R nts of a system to prevent impersonation is the implementation of credentials th
FC7375"/>. One of the most important components of a system to prevent impersona at identify the parties who control telephone numbers. The STIR certificate spec
tion is the implementation of credentials which identify the parties who control ification <xref target="RFC8226" format="default"/> describes a credential syste
telephone numbers. The <xref target="RFC8226">STIR certificates</xref> specific m based on version 3 certificates <xref target="X.509" format="default"/> in acc
ation describes a credential system based on <xref target="X.509"/> version 3 ce ordance with <xref target="RFC5280" format="default"/> for that purpose. Those c
rtificates in accordance with <xref target="RFC5280"/> for that purpose. Those c redentials can then be used by STIR authentication services <xref target="RFC822
redentials can then be used by STIR authentication services <xref target="RFC822 4" format="default"/> to sign PASSporT objects <xref target="RFC8225" format="de
4"/> to sign PASSporT objects <xref target="RFC8225"/> carried in SIP <xref targ fault"/> carried in SIP <xref target="RFC3261" format="default"/> requests.</t>
et="RFC3261"/> requests.</t> <t><xref target="RFC8226" format="default"/> specifies an extension to X.5
09 that defines a Telephony Number (TN) Authorization List that may be included
<t><xref target="RFC8226"/> specifies an extension to X.509 that defines by certification authorities (CAs) in certificates. This extension provides addi
a Telephony Number (TN) Authorization List that may be included by certification tional information that relying parties can use when validating transactions wit
authorities (CAs) in certificates. This extension provides additional informati h the certificate. When a SIP request, for example, arrives at a terminating adm
on that relying parties can use when validating transactions with the certificat inistrative domain, the calling number attested by the SIP request can be compar
e. When a SIP request, for example, arrives at a terminating administrative doma ed to the TN Authorization List of the certificate that signed the PASSporT to d
in, the calling number attested by the SIP request can be compared to the TN Aut etermine if the caller is authorized to use that calling number.</t>
horization List of the certificate that signed the PASSporT to determine if the <t>
caller is authorized to use that calling number.</t> Initial deployment of <xref target="RFC8226" format="default"/> has focused
<t> on the use of Service Provider Codes (SPCs) to attest to the scope of authority
Initial deployment of <xref target="RFC8226"/> has focused on the use of Ser of a certificate. Typically, these codes are internal telephone network identifi
vice Provider Codes (SPCs) to attest the scope of authority of a certificate. Ty ers such as the Operating Company Numbers (OCNs) assigned to carriers in the Uni
pically, these codes are internal telephone network identifiers such as the Oper ted States. However, these network identifiers are effectively unavailable to no
ating Company Numbers (OCNs) assigned to carriers in the United States. However, n-carrier entities, and this has raised questions about how such entities might
these network identifiers are effectively unavailable to non-carrier entities, best participate in STIR when needed. Additionally, a carrier may sometimes oper
and this has raised questions about how such entities might best participate in ate numbers that are formally assigned to another carrier. <xref target="RFC8226
STIR, when needed. Additionally, a carrier may sometimes operate numbers that ar " format="default"/> gives an overview of a certificate enrollment model based o
e formally assigned to another carrier. <xref target="RFC8226"/> gave an overvie n "delegation", whereby the holder of a certificate might allocate a subset of t
w of a certificate enrollment model based on "delegation," whereby the holder of hat certificate's authority to another party. This specification details how del
a certificate might allocate a subset of that certificate's authority to anothe egation of authority works for STIR certificates.
r party. This specification details how delegation of authority works for STIR c </t>
ertificates.
</t>
</section>
<section anchor="sec-2" title="Terminology">
<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when
, they appear in all
capitals, as shown here.</t><t>
This specification also uses the terms:
</t><t>
delegation: the concept of STIR certificate delegation and its terms are
defined in <xref target="RFC8226"/>.
</t><t>
legitimate spoofing: the practice of selecting an alternative presentatio
n number for a telephone caller legitimately.
</t>
</section> </section>
<section anchor="sec-2" numbered="true" toc="default">
<section anchor="motive" title="Motivation"> <name>Terminology</name>
<t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>
This specification also uses the following terms:
</t>
<dl newline="false">
<dt>delegation:</dt><dd>The concept of STIR certificate delegation and it
s terms are defined in <xref target="RFC8226" format="default"/>.
</dd>
<dt>
legitimate spoofing:</dt><dd>The practice of selecting an alternative pre
sentation number for a telephone caller legitimately.
</dd></dl>
</section>
<section anchor="motive" numbered="true" toc="default">
<name>Motivation</name>
<t>
The most pressing need for delegation in STIR arises in a set of use cases where callers want to use a particular calling number, but for whatever reason, their outbound calls will not pass through the authentication service of the ser vice provider that controls that numbering resource. The most pressing need for delegation in STIR arises in a set of use cases where callers want to use a particular calling number, but for whatever reason, their outbound calls will not pass through the authentication service of the ser vice provider that controls that numbering resource.
</t><t> </t>
One example would be an enterprise that places outbound calls through a set <t>
of service providers, for each call choosing a provider based on a least-cost ro One example would be an enterprise that places outbound calls through a set
uting algorithm or similar local policy. The enterprise was assigned a calling n of service providers; for each call, a provider is chosen based on a least-cost
umber by a particular service provider, but some calls originating from that num routing algorithm or similar local policy. The enterprise was assigned a calling
ber will go out through other service providers. number by a particular service provider, but some calls originating from that n
</t><t> umber will go out through other service providers.
A user might also roam from their usual service provider to a differ </t>
ent network or administrative domain, for various reasons. Most "legitimate spoo <t>
fing" examples are of this form: where a user wants to be able to use the main c A user might also roam from their usual service provider to a differ
all-back number for their business as a calling party number, even when the user ent network or administrative domain for various reasons. Most "legitimate spoof
is away from the business. ing" examples are of this form, where a user wants to be able to use the main ca
</t><t> llback number for their business as a calling party number, even when the user i
s away from the business.
</t>
<t>
These sorts of use cases could be addressed if the carrier who controls the numbering resource were able to delegate a credential that could be used to sign calls regardless of which network or administrative domain handles the outbound routing for the call. These sorts of use cases could be addressed if the carrier who controls the numbering resource were able to delegate a credential that could be used to sign calls regardless of which network or administrative domain handles the outbound routing for the call.
In the absence of something like a delegation mechanism, outbound carriers m ay be forced to sign calls with credentials that do not cover the originating nu mber in question. Unfortunately, that practice would be difficult to distinguish from malicious spoofing, and if it becomes widespread, it could erode trust in STIR overall. In the absence of something like a delegation mechanism, outbound carriers m ay be forced to sign calls with credentials that do not cover the originating nu mber in question. Unfortunately, that practice would be difficult to distinguish from malicious spoofing, and if it becomes widespread, it could erode trust in STIR overall.
</t> </t>
</section> </section>
<section anchor="deleg" numbered="true" toc="default">
<section anchor="deleg" title="Delegation of STIR Certificates"> <name>Delegation of STIR Certificates</name>
<t> <t>
STIR delegate certificates are certificates containing a TNAuthList obje STIR delegate certificates are certificates containing a TNAuthList obje
ct that have been signed with the private key of a parent certificate that itsel ct that have been signed with the private key of a parent certificate that itsel
f contains a TNAuthList object (either by-value or by-reference, see <xref targe f contains a TNAuthList object (either by value or by reference; see <xref targe
t="scope"/>). The parent certificate needs to contain a basic constraints extens t="scope" format="default"/>). The parent certificate needs to contain a basic c
ion with the <xref target="RFC5280"/> cA boolean set to "true", indicating that onstraints extension with the cA boolean set to "true" <xref target="RFC5280" fo
the subject can sign certificates. Every STIR delegate certificate identifies it rmat="default"/>, indicating that the subject can sign certificates. Every STIR
s parent certificate with a standard <xref target="RFC5280"/> Authority Key Iden delegate certificate identifies its parent certificate with a standard Authority
tifier extension. Key Identifier extension <xref target="RFC5280" format="default"/>.
</t><t> </t>
<t>
The authority bestowed on the holder of the delegate certificate by the p arent certificate is recorded in the delegate certificate's TNAuthList. The authority bestowed on the holder of the delegate certificate by the p arent certificate is recorded in the delegate certificate's TNAuthList.
Because STIR certificates use the TNAuthList object rather than the Subje Because STIR certificates use the TNAuthList object rather than the Subje
ct Name for indicating the scope of their authority, traditional <xref target="R ct Name for indicating the scope of their authority, traditional name constraint
FC5280"/> name constraints are not directly applicable to STIR. In a manner simi s <xref target="RFC5280" format="default"/> are not directly applicable to STIR.
lar to the <xref target="RFC6480">RPKI</xref> "encompassing" semantics, each del In a manner similar to the <xref target="RFC6480" format="default">Resource Pub
egate certificate MUST have a TNAuthList scope that is equal to or a subset of i lic Key Infrastructure (RPKI)</xref> "encompassing" semantics, each delegate cer
ts parent certificate's scope: it must be "encompassed." For example, a parent c tificate <bcp14>MUST</bcp14> have a TNAuthList scope that is equal to or a subse
ertificate with a TNAuthList that attested authority for the numbering range +1- t of its parent certificate's scope: it must be "encompassed". For example, a pa
212-555-1000 through 1999 could issue a certificate to one delegate attesting au rent certificate with a TNAuthList that attested authority for the numbering ran
thority for the range +1-212-555-1500 through 1599, and to another delegate a ce ge +1-212-555-1000 through 1999 could issue a certificate to one delegate attest
rtificate for the individual number +1-212-555-1824. ing authority for the range +1-212-555-1500 through 1599 and, to another delegat
</t><t> e, a certificate for the individual number +1-212-555-1824.
Delegate certificates MAY also contain a basic constraints extension with </t>
the cA boolean set to "true", indicating that they can sign subordinate certifi <t>
cates for further delegates. As only end-entity certificates can actually sign P Delegate certificates <bcp14>MAY</bcp14> also contain a basic constraints
ASSporTs, the holder of a STIR certificate with a "true" cA boolean may create a extension with the cA boolean set to "true", indicating that they can sign subo
separate end-entity certificate either with an identical TNAuthList to its par rdinate certificates for further delegates. As only end-entity certificates can
ent, or with a subset of the parents authority, that would be used to sign PASSp actually sign PASSporTs, the holder of a STIR certificate with a "true" cA boole
orTs. an may create a separate end-entity certificate with either an identical TNAuthL
</t> ist to its parent or a subset of the parent's authority, which would be used to
<section anchor="scope" title="Scope of Delegation"> sign PASSporTs.
<t> </t>
The TNAuthList of a STIR certificate may contain one or more SPCs, or one <section anchor="scope" numbered="true" toc="default">
or more telephone number ranges, or even a mix of SPCs and telephone number ran <name>Scope of Delegation</name>
ges. When delegating from a STIR certificate, a child certificate may inherit fr <t>
om its parent either or both of the above, and this specification explicitly per The TNAuthList of a STIR certificate may contain one or more SPCs, one or
mits SPC-only parent certificates to delegate individual telephone numbers or ra more telephone number ranges, or even a mix of SPCs and telephone number ranges
nges to a child certificate, as this will be necessary in some operating environ . When delegating from a STIR certificate, a child certificate may inherit from
ments. Depending on the sort of numbering resources that a delegate has been ass its parent either or both of the above, and this specification explicitly permit
igned, various syntaxes can be used to capture the delegated resource. s SPC-only parent certificates to delegate individual telephone numbers or range
</t><t> s to a child certificate, as this will be necessary in some operating environmen
Some non-carrier entities may be assigned large and complex allocations of t ts. Depending on the sort of numbering resources that a delegate has been assign
elephone numbers, which may be only partially contiguous or entirely disparate. ed, various syntaxes can be used to capture the delegated resource.
Allocations may also change frequently, in minor or significant ways. These reso </t>
urces may be so complex, dynamic, or extensive that listing them in a certificat
e is prohibitively difficult. Section 10.1 of <xref target="RFC8226"/> describes <t>
one potential way to address this, including the TNAuthList (specified in <xref Some non-carrier entities may be assigned large and complex allocations
target="RFC8226"/>) in the certificate by-reference rather than by value, where of telephone numbers, which may be only partially contiguous or entirely dispar
a URL in the certificate points to a secure, dynamically-updated list of the te ate. Allocations may also change frequently in minor or significant ways. These
lephone numbers in the scope of authority of a certificate. For entities that ar resources may be so complex, dynamic, or extensive that listing them in a certif
e carriers in all but name, another alternative is the allocation of an SPC; thi icate is prohibitively difficult.
s yields much the same property, as the SPC is effectively a pointer to an exter
nal database which dynamically tracks the numbers associated with the SPC. Eithe <xref target="RFC8226" sectionFormat="of" section="10.1"/> describes on
r of these approaches may make sense for a given deployment. Certification path e potential way to address this: including the TNAuthList (specified in <xref ta
construction as detailed below treats by-reference TNAuthLists in a certificate rget="RFC8226" format="default"/>) in the certificate by reference rather than b
as if it had been included by-value. y value, where a URL in the certificate points to a secure, dynamically updated
</t><t> list of the telephone numbers in the scope of authority of a certificate. For en
Other non-carrier entities may have straightforward telephone number assignm tities that are carriers in all but name, another alternative is the allocation
ents, such as enterprises receiving a set of thousand blocks from a carrier tha of an SPC; this yields much the same property, as the SPC is effectively a point
t may be kept for years or decades. Particular freephone numbers may also have a er to an external database that dynamically tracks the numbers associated with t
long-term association with an enterprise and its brand. For these sorts of assi he SPC. Either of these approaches may make sense for a given deployment.
gnments, assigning an SPC may seem like overkill, and using the TN ranges of the
TNAuthList (by-value) is sufficient. Certification path construction as detailed below treats by-reference T
</t><t> NAuthLists in a certificate as if they had been included by value.
Whichever approach is taken to representing the delegated resource, there a </t>
re fundamental trade-offs regarding when and where in the architecture a delegat <t>
ion is validated: that is, when the delegated TNAuthList is checked to be "encom Other non-carrier entities may have straightforward telephone number assignm
passed" by the TNAuthList of its parent. This might be performed at the time the ents, such as enterprises receiving a set of a thousand blocks from a carrier th
delegate certificate is issued, or at the time that a verification service rece at may be kept for years or decades. Particular freephone numbers may also have
ives an inbound call, or potentially both. It is generally desirable to offload a long-term association with an enterprise and its brand. For these sorts of ass
as much of this as possible to the certification process, as verification occurs ignments, assigning an SPC may seem like overkill, and using the TN ranges of th
during call setup and thus additional network dips could lead to perceptible de e TNAuthList (by value) is sufficient.
lay, whereas certification happens outside of call processing as a largely admin </t>
istrative function. Ideally, if a delegate certificate can supply a by-value TN <t>
range, then a verification service could ascertain that an attested calling part
y number is within the scope of the provided certificate without requiring any a Whichever approach is taken to represent the delegated resource, there are
dditional transactions with a service. In practice, verification services may al fundamental trade-offs regarding when and where in the architecture a delegation
ready incorporate network queries into their processing (for example, to derefer is validated -- that is, when the delegated TNAuthList is checked and determine
ence the "x5u" field of a PASSporT) that could piggyback any additional informat d to be "encompassed" by the TNAuthList of its parent. This might be performed a
ion needed by the verification service. t the time the delegate certificate is issued, at the time that a verification s
</t><t> ervice receives an inbound call, or potentially both. It is generally desirable
Note that the permission semantics of the <xref target="RFC8226"/> TNAuth to offload as much of this as possible to the certification process as verificat
List are additive: that is, the scope of a certificate is the superset of all of ion occurs during call setup; thus, additional network dips could lead to percep
the tible delay, whereas certification happens outside of call processing as a large
ly administrative function. Ideally, if a delegate certificate can supply a by-v
alue TN range, then a verification service could ascertain that an attested call
ing party number is within the scope of the provided certificate without requiri
ng any additional transactions with a service. In practice, verification service
s may already incorporate network queries into their processing (for example, to
dereference the "x5u" field of a PASSporT) that could piggyback any additional
information needed by the verification service.
</t>
<t>
Note that the permission semantics of the TNAuthList <xref target="RFC822
6" format="default"/> are additive: that is, the scope of a certificate is the s
uperset of all of the
SPCs and telephone number ranges enumerated in the TNAuthList. As SPCs th emselves are effectively pointers to a set of telephone number ranges, and a tel ephone number may SPCs and telephone number ranges enumerated in the TNAuthList. As SPCs th emselves are effectively pointers to a set of telephone number ranges, and a tel ephone number may
belong to more than one SPC, this may introduce some redundancy to the se t of telephone numbers specified as the scope of a certificate. The presence of belong to more than one SPC, this may introduce some redundancy to the se t of telephone numbers specified as the scope of a certificate. The presence of
one or more SPCs and one or more sets of one or more SPCs and one or more sets of
telephone number ranges are similarly treated additively, even if the tel ephone number ranges turn out to be redundant to the scope of an SPC. telephone number ranges are similarly treated additively, even if the tel ephone number ranges turn out to be redundant to the scope of an SPC.
</t> </t>
</section> </section>
</section> </section>
<section anchor="as" numbered="true" toc="default">
<section anchor="as" title="Authentication Services Signing with Delegate <name>Authentication Service Signing with Delegate Certificates</name>
Certificates"> <t>
<t> Authentication service behavior varies from <xref target="RFC8224" format
Authentication service behavior varies from <xref target="RFC8224"/> as f ="default"/> as follows, although the same checks are performed by the authentic
ollows, although the same checks are performed by the authentication service whe ation service when comparing the calling party number attested in call signaling
n comparing the calling party number attested in call signaling with the scope o with the scope of the authority of the signing certificate. Authentication serv
f the authority of the signing certificate. Authentication services SHOULD NOT u ices <bcp14>SHOULD NOT</bcp14> use a delegate certificate without validating tha
se a delegate certificate without validating that its scope of authority is enco t its scope of authority is encompassed by that of its parent certificate, and i
mpassed by that of its parent certificate, and if that certificate has its own p f that certificate has its own parent, the entire certification path <bcp14>SHOU
arent, the entire certification path SHOULD be validated. LD</bcp14> be validated.
</t><t> </t>
<t>
This delegation architecture does not require that a non-carrier entity act as its own authentication service. That function may be performed by any authent ication service that holds the private key corresponding to the delegate certifi cate, including one run by an outbound service provider, a third party in an ent erprise's outbound call path, or in the SIP User Agent itself. This delegation architecture does not require that a non-carrier entity act as its own authentication service. That function may be performed by any authent ication service that holds the private key corresponding to the delegate certifi cate, including one run by an outbound service provider, a third party in an ent erprise's outbound call path, or in the SIP User Agent itself.
</t><t> </t>
Note that authentication services creating a PASSporT for a call signed w <t>
ith a delegate certificate MUST provide an "x5u" link corresponding to the entir Note that authentication services creating a PASSporT for a call signed w
e certification path, rather than just the delegate certificate used to sign the ith a delegate certificate <bcp14>MUST</bcp14> provide an "x5u" link correspondi
call, as described in <xref target="chain"/>. ng to the entire certification path rather than just the delegate certificate us
</t> ed to sign the call, as described in <xref target="chain" format="default"/>.
</section> </t>
<section anchor="vs" title="Verification Service Behavior for Delegate Ce </section>
rtificate Signatures"> <section anchor="vs" numbered="true" toc="default">
<t> <name>Verification Service Behavior for Delegate Certificate Signatures</n
The responsibility of a verification service validating PASSporTs signed ame>
with delegate certificates, while largely following baseline <xref target="RFC82 <t>
24"/> and <xref target="RFC8225"/>, requires some additional procedures. When th The responsibility of a verification service validating PASSporTs signed
e verification service dereferences the "x5u" parameter, it will acquire a certi with delegate certificates, while largely following baseline specifications <xre
ficate list rather than a single certificate. It MUST then validate all of the c f target="RFC8224" format="default"/> and <xref target="RFC8225" format="default
redentials in the list, identifying the parent certificate for each delegate thr "/>, requires some additional procedures. When the verification service derefere
ough its Authority Key Identifier extension. nces the "x5u" parameter, it will acquire a certificate list rather than a singl
</t><t> e certificate. It <bcp14>MUST</bcp14> then validate all of the credentials in th
While ordinarily, relying parties have significant latitude in certificat e list, identifying the parent certificate for each delegate through its Authori
ion path construction when validating a certification path, STIR assumes a more ty Key Identifier extension.
rigid hierarchical subordination model, rather than one where relying parties ma </t>
y want to derive their own certification path to particular trust anchors. If th <t>
e certificates acquired from the "x5u" element of a PASSporT do not lead to an a While relying parties ordinarily have significant latitude in certificati
nchor that the verification service trusts, it treats the validation no differen on path construction when validating a certification path, STIR assumes a more r
tly than it would when a non-delegated certificate was issued by an untrusted ro igid hierarchical subordination model rather than one where relying parties may
ot; in SIP, it MAY return a 437 "Unsupported Credential" response if the call sh want to derive their own certification path to particular trust anchors. If the
ould be failed for lack of a valid Identity header. certificates acquired from the "x5u" element of a PASSporT do not lead to an anc
</t> hor that the verification service trusts, it treats the validation no differentl
</section> y than it would when a non-delegated certificate was issued by an untrusted root
; in SIP, it <bcp14>MAY</bcp14> return a 437 "Unsupported Credential" response i
f the call should be failed for lack of a valid Identity header.
</t>
</section>
<section anchor="chain" numbered="true" toc="default">
<name>Acquiring Multiple Certificates in STIR</name>
<t>
<xref target="RFC8225" format="default">PASSporT</xref> uses the "x5u" el
ement to convey the URL where verification services can acquire the certificate
used to sign a PASSporT. This value is mirrored by the "info" parameter of the I
dentity header when a PASSporT is conveyed via SIP. Commonly, this is an HTTPS U
RI.
</t>
<section anchor="chain" title="Acquiring Multiple Certificates in STIR"> <t>
<t>
<xref target="RFC8225">PASSporT</xref> uses the "x5u" element to convey t
he URL where verification services can acquire the certificate used to sign a PA
SSporT. This value is mirrored by the "info" parameter of the Identity header wh
en a PASSporT is conveyed via SIP. Commonly, this is an HTTPS URI.
</t><t>
When a STIR delegate certificate is used to sign a PASSporT, the "x5u" eleme nt in the PASSporT will contain a URI indicating where a certificate list is ava ilable. While When a STIR delegate certificate is used to sign a PASSporT, the "x5u" eleme nt in the PASSporT will contain a URI indicating where a certificate list is ava ilable. While
baseline JSON Web Signature (JWS) also supports an "x5c" element specificall y for certificate chains, in operational practice, certification paths are alrea dy being delivered in the STIR environment via the "x5u" element, so this specif ication RECOMMENDS implementations contain to use "x5u"; "x5c" is OPTIONAL for e nvironments where it is known to be supported. the baseline JSON Web Signature (JWS) also supports an "x5c" element specifi cally for certificate chains, in operational practice, certification paths are a lready being delivered in the STIR environment via the "x5u" element, so this sp ecification RECOMMENDS that implementations continue to use "x5u". "x5c" is <bcp 14>OPTIONAL</bcp14> for environments where it is known to be supported.
That list will be a concatenation of PEM-encoded certificates of That list will be a concatenation of certificates encoded with Pr
the type "application/pem-certificate-chain" defined in <xref target="RFC8555"/> ivacy Enhanced Mail (PEM) of the type "application/pem-certificate-chain" define
. The <xref target="RFC5280">certificate path</xref> ordering MUST be ordered fr d in <xref target="RFC8555" format="default"/>. The <xref target="RFC5280" forma
om the signer to the trust anchor. t="default">certificate path</xref> ordering <bcp14>MUST</bcp14> be ordered from
The list begins with the certificate used to sign the PASSporT, f the signer to the trust anchor.
ollowed by its parent, and then any subsequent grandparents, great-grandparents, The list begins with the certificate used to sign the PASSporT, f
and so on. The key identifier in the Authority Key Identifier extension in the ollowed by its parent, and then any subsequent grandparents, great-grandparents,
first certificate MUST appear in the Subject Key Identifier extension in the sec and so on. The key identifier in the Authority Key Identifier extension in the
ond certificate. The key identifier pairing MUST match in this way throughout th first certificate <bcp14>MUST</bcp14> appear in the Subject Key Identifier exten
e entire chain of certificates. Note that <xref target="RFC8555">ACME</xref> re sion in the second certificate. The key identifier pairing <bcp14>MUST</bcp14> m
quires the first element in a pem-certificate-chain to be an end-entity certific atch in this way throughout the entire chain of certificates. Note that <xref t
ate. arget="RFC8555" format="default">Automatic Certificate Management Environment (A
</t> CME)</xref> requires the first element in a pem-certificate-chain to be an end-e
</section> ntity certificate.
</t>
</section>
<section anchor="sp" numbered="true" toc="default">
<name>Certification Authorities and Service Providers</name>
<t>
Once a telephone service provider has received a CA certificate attesting to
their numbering resources, they may delegate resources from it as they see fit.
Note that
the allocation to a service provider of a certificate with a basic constrain
ts extension with the cA boolean set to "true" does not require that a service p
rovider act as a certification authority itself; serving as a certification auth
ority is a function requiring specialized expertise and infrastructure. Certific
ation authorities are, for example, responsible for maintaining certificate revo
cation lists and related functions as well as publishing certification practice
statements. A third-party certification authority, including the same one that
issued the service provider its parent certificate, could act as the CA that iss
ues delegate certificates for the service provider if the necessary business rel
ationships permit it. A service provider might in this case act as a Token Autho
rity (see <xref target="acme" format="default"/>) granting its customers permiss
ions to receive certificates from the CA.
</t>
<t>
Note that if the same CA that issued the parent certificate is also issuing
a delegate certificate, it may be possible to shorten the certification path, wh
ich reduces the work required of verification services. The trade-off here is th
at if the CA simply issued a non-delegate certificate (whose parent is the CA's
trust anchor) with the proper TNAuthList value, relying parties might not be abl
e to ascertain which service provider owned those telephone numbers, information
that might be used to make an authorization decision on the terminating side. H
owever, some additional object in the certificate outside of the TNAuthList coul
d preserve that information; this is a potential area for future work, and longe
r certification paths are the only mechanism currently defined.
</t>
<t>
All CAs must detail in their practices and policies a requirement to val
idate that the "encompassing" of a delegate certificate is done by its parent. N
ote that this
requires that CAs have access to the necessary industry databases
to ascertain whether, for example, a particular telephone number is encompassed
by an SPC. Alternatively, a CA may acquire an Authority Token (see <xref target
="acme" format="default"/>) that affirms that a delegation is in the proper scop
e. Exactly what operational practices this entails may vary in different nationa
l telephone administrations and are thus left to the <xref target="RFC3647" form
at="default">Certificate Policy / Certification Practice Statement (CP/CPS)</xre
f>.
</t>
<section anchor="acme" numbered="true" toc="default">
<name>ACME and Delegation</name>
<t>
<section anchor="sp" title="Certification Authorities and Service Providers" STIR deployments commonly use <xref target="RFC8555" format="default">ACM
> E</xref> for certificate acquisition, and it is anticipated that delegate certif
icates will also be acquired through an ACME interface. An entity can acquire a
certificate from a particular CA by requesting an <xref target="I-D.ietf-acme-au
thority-token" format="default">Authority Token</xref> from the parent with the
desired <xref target="I-D.ietf-acme-authority-token-tnauthlist" format="default"
>TNAuthList</xref> object. Note that if the client intends to do further subdele
gation of its own, it should request a token with the "ca" Authority Token flag
set.
</t>
<t> <t>
Once a telephone service provider has received a CA certificate attesting th The entity then presents that Authority Token to a CA to acquire a STIR deleg
eir numbering resources, they may delegate resources from it as they see fit. No ate certificate. ACME returns an "application/pem-certificate-chain" object, and
te that that object would be suitable for publication as an HTTPS resource for retrieva
the allocation to a service provider of a certificate with a basic constrain l with the PASSporT "x5u" mechanism as discussed in <xref target="chain" format=
ts extension with the cA boolean set to "true" does not require that a service p "default"/>. If the Certificate Signing Request (CSR) presented to the ACME serv
rovider act as a certification authority itself; serving as a certification auth er is for a certificate with the cA boolean set to "true", then the ACME server
ority is a function requiring specialized expertise and infrastructure. Certific makes a policy decision to determine whether or not it is appropriate to issue t
ation authorities are for example responsible for maintain certificate revocatio hat certificate to the requesting entity. That policy decision will be reflected
n lists and related functions, as well as publishing certification practice stat by the "ca" flag in the Authority Token.
ements. A third-party certification authority, including the same one that issu </t>
ed the service provider its parent certificate, could act as the CA that issues <t>
delegate certificates for the service provider, if the necessary business relati Service providers that want the capability to rapidly age out delegated certi
onships permit it. A service provider might in this case act as a Token Authorit ficates can rely on the ACME Short-Term, Automatically Renewed (STAR) <xref targ
y (see <xref target="acme"/>) granting its customers permissions to receive cert et="RFC8739" format="default"/> mechanism to automate the process of short-term
ificates from the CA. certificate expiry.
</t><t> </t>
Note that if the same CA that issued the parent certificate is also issuing </section>
a delegate certificate, it may be possible to shorten the certification path, wh <section numbered="true" toc="default">
ich reduces the work required of verification services. The trade-off here is th <name>Handling Multiple Certificates</name>
at if the CA simply issued a non-delegate certificate (whose parent is the CA's <t>
trust anchor) with the proper TNAuthList value, relying parties might not be abl In some deployments, non-carrier entities may receive telephone numbers from
e to ascertain which service provider owned those telephone numbers, information several different carriers. This could lead to enterprises needing to maintain
which might be used to make an authorization decision on the terminating side. a sort of STIR keyring, with different certificates delegated to them from diffe
However, some additional object in the certificate outside of the TNAuthList cou rent providers. These certificates are potentially issued by different CAs, whic
ld preserve that information; this is a potential area for future work, and long h enterprises choose between when signing a call. This could be the case regardl
er certification paths are the only mechanism currently defined. ess of which syntax is used in the TNAuthList to represent the scope of the dele
</t><t> gation (see <xref target="scope" format="default"/>). As noted in <xref target="
All CAs must detail in their practices and policies a requirement to val sp" format="default"/>, if the parent certs use the same CA, it may be possible
idate that the "encompassing" of a delegate certificate by its parent. Note that to shorten the certification path.
this
requires that CAs have access to the necessary industry databases
to ascertain whether, for example, a particular telephone number is encompassed
by an SPC. Alternatively, a CA may acquire an Authority Token (see <xref target
="acme"/>) that affirms that a delegation is in the proper scope. Exactly what o
perational practices this entails may vary in different national telephone admin
istrations, and are thus left to the <xref target="RFC3647">CP/CPS</xref>.
</t> </t>
<section anchor="acme" title="ACME and Delegation">
<t>
STIR deployments commonly use <xref target="RFC8555">ACME</xref> for cert
ificate acquisition, and it is anticipated that delegate certificates as well wi
ll be acquired through an ACME interface. An entity can acquire a certificate fr
om a particular CA by requesting an <xref target="I-D.ietf-acme-authority-token"
>Authority Token</xref> from the parent with the desired <xref target="I-D.ietf-
acme-authority-token-tnauthlist">TNAuthList</xref> object. Note that if the clie
nt intends to do further subdelegation of its own, it should request a token wit
h the "ca" Authority Token flag set.
</t><t>
The entity then presents that Authority Token to a CA to acquire a STIR deleg
ate certificate. ACME returns an "application/pem-certificate-chain" object, and
that object would be suitable for publishing as an HTTPS resource for retrieval
with the PASSporT "x5u" mechanism as discussed in <xref target="chain"/>. If th
e CSR presented to the ACME server is for a certificate with the cA boolean set
to "true", then the ACME server makes a policy decision to determine whether or
not it is appropriate to issue that certificate to the requesting entity. That p
olicy decision will be reflected by the "ca" flag in the Authority Token.
</t><t>
Service providers that want the capability to rapidly age out delegated certi
ficates can rely on the <xref target="I-D.ietf-acme-star">ACME STAR</xref> mecha
nism to automate the process of short-term certificate expiry.
</t>
</section>
<section title="Handling Multiple Certificates">
<t> <t>
In some deployments, non-carrier entities may receive telephone numbers from For non-carrier entities handling a small number of certificates, this
several different carriers. This could lead to enterprises needing to maintain is probably not a significant burden. For cases where it becomes burdensome, a f
a sort of STIR keyring, with different certificates delegated to them from diffe ew potential approaches exist. A delegate certificate could be cross-certified w
rent providers, potentially issued by different CAs, which they choose between w ith another delegate certificate via an Authority Information Access (AIA) field
hen signing a call. This could be the case regardless of which syntax is used in containing the URL of a Certificate Authority Issuer so that a signer would onl
the TNAuthList to represent the scope of the delegation (see <xref target="scop y need to sign with a single certificate to inherit the privileges of the other
e"/>). As noted in <xref target="sp"/>, if the parent certs use the same CA, it certificate(s) with which it has cross-certified. In very complex delegation cas
may be possible to shorten the certification path. es, it might make more sense to establish a bridge CA that cross-certifies with
</t><t> all of the certificates held by the enterprise rather than requiring a mesh of c
For non-carrier entities handling a small number of certificates, this is pr ross-certification between a large number of certificates. Again, this bridge CA
obably not a significant burden. For cases where it becomes burdensome, a few po function would likely be performed by some existing CA in the STIR ecosystem.
tential approaches exist. A delegate certificate could be cross-certified with a These procedures would, however, complicate the fairly straightforward certifica
nother delegate certificate via an Authority Information Access field containing tion path reconstruction approach described in <xref target="chain" format="defa
the URL of a Certificate Authority Issuer, so that a signer would only need to ult"/> and would require further specification.
sign with a single certificate to inherit the privileges of the other certificat
e(s) it has cross-certified with. In very complex delegation cases, it might mak
e more sense to establish a bridge CA that cross-certifies with all of the certi
ficates held by the enterprise, rather than requiring a mesh of cross-certificat
ion between a large number of certificates. Again, this bridge CA function would
likely be performed by some existing CA in the STIR ecosystem. These procedures
would however complicated the fairly straightforward certification path reconst
ruction approach described in <xref target="chain"/> and would require further s
pecification.
</t> </t>
</section>
</section> </section>
<section anchor="alt" numbered="true" toc="default">
<name>Alternative Solutions</name>
<t>
At the time this specification was written, STIR was only starting to see
deployment. In some future environment, the policies that govern CAs may not pe
rmit them to issue intermediate certificates with a TNAuthList object and a cA b
oolean set to "true" in the basic constraints certificate extension <xref target
="RFC5280" format="default"/>. Similar problems in the web PKI space motivated t
he development of TLS subcerts <xref target="I-D.ietf-tls-subcerts" format="defa
ult"/>, which substitutes a signed "delegated credential" token for a certificat
e for such environments. A comparable mechanism could be developed for the STIR
space, which would allow STIR certificates to sign
a data object that contains effectively the same data as the delegate cer
tificate specified here, including a public key that could sign PASSporTs. The T
LS subcerts system has further explored leveraging ACME to issue short-lived cer
tificates for temporary delegation as a means of obviating the need for revocati
on. Specification of a mechanism similar to TLS subcerts for STIR is future work
and will be undertaken only if the market requires it.
</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="alt" title="Alternative Solutions"> <name>IANA Considerations</name>
<t> <t>
At the time this specification was written, STIR was only starting to see This document has no IANA actions.
deployment. In some future environment, the policies that govern CAs may not pe </t>
rmit them to issue intermediate certificates with a TNAuthList object and a cA b
oolean set to "true" in the basic constraints certificate extension <xref target
="RFC5280"/>. Similar problems in the web PKI space motivated the development of
TLS subcerts <xref target="I-D.ietf-tls-subcerts"/>, which substitutes a signed
"delegated credential" token for a certificate for such environments. A compara
ble mechanism could be developed for the STIR space, allowing STIR certificates
to sign
a data object which contains effectively the same data as the delegate ce
rtificate specified here, including a public key that could sign PASSporTs. The
TLS subcerts system has furthermore exploring leveraging ACME to issue short-liv
ed certificates for temporary delegation as a means of obviating the need for re
vocation. Specification of a mechanism similar to TLS subcerts for STIR is futur
e work, and will be undertaken only if the market require it.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document contains no actions for the IANA.
</t>
</section> </section>
<section anchor="priv" title="Privacy Considerations"> <section anchor="priv" numbered="true" toc="default">
<name>Privacy Considerations</name>
<t> <t>
Any STIR certificate that identifies a narrow range of telephone numbers p otentially exposes information about the entities that are placing calls. As suc h a telephone number range is necessarily a superset of the calling party number that is openly signaled during call setup, the privacy risks associated with th is mechanism are not substantially greater than baseline STIR. See <xref target= "RFC8224"/> for guidance on the use of anonymization mechanisms in STIR. Any STIR certificate that identifies a narrow range of telephone numbers p otentially exposes information about the entities that are placing calls. As suc h a telephone number range is a necessary superset of the calling party number t hat is openly signaled during call setup, the privacy risks associated with this mechanism are not substantially greater than baseline STIR. See <xref target="R FC8224" format="default"/> for guidance on the use of anonymization mechanisms i n STIR.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document is entirely about security. As delegation can allow signi
ng-in scenarios where unauthenticated "legitimate" spoofing would otherwise be u
sed, the hope is that delegation will improve the overall security of the STIR e
cosystem. For further information on certificate security and practices, see <x
ref target="RFC5280" format="default"/>, particularly its security consideration
s. Also see the security considerations of <xref target="RFC8226"/> for general
guidance on the implications of the use of certificates in STIR and <xref targe
t="RFC7375" format="default"/> for the STIR threat model.
</t>
<t>
Much of the security of delegation depends on the implementation of the
encompassing semantics described in <xref target="deleg" format="default"/>. Wh
en delegating from an SPC-based TNAuthList to a set of telephone number ranges,
understanding the encompassing semantics may require access to industry database
s that track the numbering assets of service providers associated with a given S
PC. In some operating environments, such databases might not exist. How encompas
sing is policed is therefore a matter outside the scope of this document and spe
cific to operational profiles of STIR.
</t>
<section anchor="Security" title="Security Considerations"> <t>
<t>This document is entirely about security. As delegation can allow signi The use of by-reference TNAuthLists as described in <xref target="deleg"
ng in scenarios where unauthenticated "legitimate" spoofing would otherwise be u format="default"/> means that the TNAuthList associated with a certificate can c
sed, it is hoped that delegation will improve the overall security of the STIR e hange over time; see the security considerations of <xref target="RFC3986" forma
cosystem. For further information on certificate security and practices, see <x t="default"/> for more on the implications of this property.
ref target="RFC5280"/>, in particular its Security Considerations. Also see the
Security Considerations of <xref target="RFC8226"/> for general guidance on the
implications of the use of certificates in STIR, and <xref target="RFC7375"/> f
or the STIR threat model.
</t><t>
Much of the security of delegation depends on the implementation of the
encompassing semantics described in <xref target="deleg"/>. When delegating fro
m an SPC-based TNAuthList to a set of telephone number ranges, understanding the
encompassing semantics may require access to industry databases that track the
numbering assets of service providers associated with a given SPC. In some opera
ting environments, such databases might not exist. How encompassing is policed i
s therefore a matter outside the scope of this document, and specific to operati
onal profiles of STIR.
</t><t>
The use of by-reference TNAuthLists as described in <xref target="deleg
"/> entails that the TNAuthList associated with a certificate can change over ti
me; see the security considerations of <xref target="RFC3986"/> for more on the
implications of this property. It is considered a useful feature here due to the
potential dynamism of large lists of telephone numbers, but this dynamism entai
ls that a relying party might once accept that a particular telephone number is
associated with a certificate, but later reject it for the same certificate as t
he dynamic list changes. Also that note if the HTTPS service housing the by-refe
rence telephone number list is improperly secured, that too can lead to vulnerab
ilities. Ultimately, the CA that issued a delegated certificate populates the UR
L in the AIA field, and is responsible for making a secure selection. Service pr
oviders acting as CAs are directed to the cautionary words about running a CA in
<xref target="sp"/> regarding the obligations this entails for certificate revo
cation and so on.
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments"> It is considered a useful feature here due to the potential dynamism of l
<t>We would like to thank Ines Robles, Richard Barnes, Chris Wendt, Dave H arge lists of telephone numbers, but this dynamism means that a relying party mi
ancock, Russ Housley, Benjamin Kaduk, and Sean Turner for key input on this docu ght at one point accept that a particular telephone number is associated with a
ment.</t> certificate but later reject it for the same certificate as the dynamic list cha
nges. Also note that if the HTTPS service housing the by-reference telephone num
ber list is improperly secured, that too can lead to vulnerabilities. Ultimately
, the CA that issued a delegated certificate populates the URL in the AIA field
and is responsible for making a secure selection. Service providers acting as CA
s are directed to the cautionary words about running a CA in <xref target="sp" f
ormat="default"/> regarding the obligations this entails for certificate revocat
ion and so on.
</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<displayreference target="I-D.ietf-acme-authority-token" to="ACME-CHAL"/>
<displayreference target="I-D.ietf-acme-authority-token-tnauthlist" to="ACME-TOK
EN"/>
<displayreference target="I-D.ietf-tls-subcerts" to="TLS-CRED"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8224.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8225.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8226.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8555.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Normative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ac
&RFC2119; me-authority-token.xml"/>
&RFC8174;
&RFC5280;
&RFC8224;
&RFC8225;
&RFC8226;
&RFC8555;
&RFC3986;
</references> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ac
<references title="Informative References"> me-authority-token-tnauthlist.xml"/>
&I-D.ietf-acme-authority-token;
&I-D.ietf-acme-authority-token-tnauthlist;
&RFC3261;
&RFC6480;
&RFC7340;
&RFC7375;
&RFC3647;
&I-D.ietf-acme-star;
&I-D.ietf-tls-subcerts;
<reference anchor='X.509'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6480.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7375.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3647.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8739.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-tl
s-subcerts.xml"/>
<reference anchor="X.509" target="https://www.itu.int/rec/T-REC-X.509">
<front>
<title>Information technology - Open Systems Interconnection - The D irectory: Public-key and attribute certificate frameworks</title> <title>Information technology - Open Systems Interconnection - The D irectory: Public-key and attribute certificate frameworks</title>
<author> <author>
<organization> <organization>
ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8 ITU-T
</organization> </organization>
</author> </author>
<date year='2012' /> <date year="2016" month="October"/>
</front> </front>
</reference> <seriesInfo name="ITU-T Recommendation" value="X.509"></seriesInfo>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>We would like to thank <contact fullname="Ines Robles"/>, <contact full
name="Richard Barnes"/>, <contact fullname="Chris Wendt"/>, <contact fullname="D
ave Hancock"/>, <contact fullname="Russ Housley"/>, <contact fullname="Benjamin
Kaduk"/>, and <contact fullname="Sean Turner"/> for key input on this document.<
/t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 49 change blocks. 
512 lines changed or deleted 499 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/