<?xml version="1.0" encoding="US-ASCII"?>
<!--
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. --> encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY I-D.ietf-acme-star SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-acme-star.xml">
<!ENTITY I-D.ietf-acme-authority-token SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-acme-authority-token.xml">
<!ENTITY I-D.ietf-acme-authority-token-tnauthlist SYSTEM "http://xml.resource.org/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/bibxml3/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 --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"  consensus="true" 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 ***** --> ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3" number="9060">

  <front>

    <!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->

    <title abbrev="STIR Cert Delegation">STIR Certificate Delegation">Secure Telephone Identity Revisited (STIR) Certificate Delegation</title>
    <seriesInfo name="RFC" value="9060"/>
    <author initials="J." surname="Peterson" fullname="Jon Peterson">
      <organization abbrev="Neustar">Neustar, Inc.</organization>
      <address>
        <email>jon.peterson@team.neustar</email>
      </address>
    </author>
    <date year="2021" />

    <!--    <area>
    ART
    </area>--> month="September"/>
    <keyword>SIP</keyword>
    <keyword>Secure Origin Identification</keyword>
    <keyword>Communication Security</keyword>
    <keyword>Certificates</keyword>
    <keyword>Public Key Infrastructure</keyword>
    <keyword>Real-Time Communication</keyword>
    <abstract>
      <t>
      The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

      <t>The <xref target="RFC7340">STIR target="RFC7340" format="default">STIR problem statement</xref> reviews the difficulties facing the telephone network that are enabled by impersonation, including various forms of robocalling, voicemail hacking, and swatting <xref target="RFC7375"/>. target="RFC7375" format="default"/>. One of the most important components of a system to prevent impersonation is the implementation of credentials which that identify the parties who control telephone numbers. The <xref target="RFC8226">STIR certificates</xref> STIR certificate specification <xref target="RFC8226" format="default"/> describes a credential system based on <xref target="X.509"/> version 3 certificates <xref target="X.509" format="default"/> in accordance with <xref target="RFC5280"/> target="RFC5280" format="default"/> for that purpose. Those credentials can then be used by STIR authentication services <xref target="RFC8224"/> target="RFC8224" format="default"/> to sign PASSporT objects <xref target="RFC8225"/> target="RFC8225" format="default"/> carried in SIP <xref target="RFC3261"/> target="RFC3261" format="default"/> requests.</t>
      <t><xref target="RFC8226"/> target="RFC8226" format="default"/> specifies an extension to X.509 that defines a Telephony Number (TN) Authorization List that may be included by certification authorities (CAs) in certificates. This extension provides additional information that relying parties can use when validating transactions with the certificate. When a SIP request, for example, arrives at a terminating administrative domain, the calling number attested by the SIP request can be compared to the TN Authorization List of the certificate that signed the PASSporT to determine if the caller is authorized to use that calling number.</t>
      <t>
    Initial deployment of <xref target="RFC8226"/> target="RFC8226" format="default"/> has focused on the use of Service Provider Codes (SPCs) to attest to the scope of authority of a certificate. Typically, these codes are internal telephone network identifiers such as the Operating Company Numbers (OCNs) assigned to carriers in the United States. However, these network identifiers are effectively unavailable to non-carrier entities, and this has raised questions about how such entities might best participate in STIR, STIR when needed. Additionally, a carrier may sometimes operate numbers that are formally assigned to another carrier. <xref target="RFC8226"/> gave target="RFC8226" format="default"/> gives an overview of a certificate enrollment model based on "delegation," "delegation", whereby the holder of a certificate might allocate a subset of that certificate's authority to another party. This specification details how delegation of authority works for STIR certificates.
      </t>
    </section>
    <section anchor="sec-2" title="Terminology">

<t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</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
    "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
    BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t><t> here.
        </t>
      <t>
	This specification also uses the following terms:
	</t><t>
	delegation: the
      </t>
      <dl newline="false">
	<dt>delegation:</dt><dd>The concept of STIR certificate delegation and its terms are defined in <xref target="RFC8226"/>.
	</t><t> target="RFC8226" format="default"/>.
      </dd>
      <dt>
	legitimate spoofing: the spoofing:</dt><dd>The practice of selecting an alternative presentation number for a telephone caller legitimately.
	</t>
      </dd></dl>
    </section>
    <section anchor="motive" title="Motivation"> 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 service provider that controls that numbering resource.
        </t><t>
      </t>
      <t>
    One example would be an enterprise that places outbound calls through a set of service providers, providers; for each call choosing call, a provider is chosen based on a least-cost routing algorithm or similar local policy. The enterprise was assigned a calling number by a particular service provider, but some calls originating from that number will go out through other service providers.
        </t><t>
      </t>
      <t>
            A user might also roam from their usual service provider to a different network or administrative domain, domain for various reasons. Most "legitimate spoofing" examples are of this form: form, where a user wants to be able to use the main call-back callback number for their business as a calling party number, even when the user is away from the business.
        </t><t>
      </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.
    In the absence of something like a delegation mechanism, outbound carriers may be forced to sign calls with credentials that do not cover the originating number 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>
    </section>
    <section anchor="deleg" title="Delegation numbered="true" toc="default">
      <name>Delegation of STIR Certificates"> Certificates</name>
      <t>
        STIR delegate certificates are certificates containing a TNAuthList object that have been signed with the private key of a parent certificate that itself contains a TNAuthList object (either by-value by value or by-reference, by reference; see <xref target="scope"/>). target="scope" format="default"/>). The parent certificate needs to contain a basic constraints extension with the <xref target="RFC5280"/> cA boolean set to "true", "true" <xref target="RFC5280" format="default"/>, indicating that the subject can sign certificates. Every STIR delegate certificate identifies its parent certificate with a standard <xref target="RFC5280"/> Authority Key Identifier extension.
	</t><t> extension <xref target="RFC5280" format="default"/>.
      </t>
      <t>
	The authority bestowed on the holder of the delegate certificate by the parent certificate is recorded in the delegate certificate's TNAuthList.
	Because STIR certificates use the TNAuthList object rather than the Subject Name for indicating the scope of their authority, traditional <xref target="RFC5280"/> name constraints <xref target="RFC5280" format="default"/> are not directly applicable to STIR. In a manner similar to the <xref target="RFC6480">RPKI</xref> target="RFC6480" format="default">Resource Public Key Infrastructure (RPKI)</xref> "encompassing" semantics, each delegate certificate MUST <bcp14>MUST</bcp14> have a TNAuthList scope that is equal to or a subset of its parent certificate's scope: it must be "encompassed." "encompassed". For example, a parent certificate with a TNAuthList that attested authority for the numbering range +1-212-555-1000 through 1999 could issue a certificate to one delegate attesting authority for the range +1-212-555-1500 through 1599, and 1599 and, to another delegate delegate, a certificate for the individual number +1-212-555-1824.
	</t><t>
      </t>
      <t>
	Delegate certificates MAY <bcp14>MAY</bcp14> also contain a basic constraints extension with the cA boolean set to "true", indicating that they can sign subordinate certificates for further delegates. As only end-entity certificates can actually sign PASSporTs, the holder of a STIR certificate with a "true" cA boolean may create a separate end-entity certificate  either with either an identical TNAuthList to its parent, parent or with a subset of the parents parent's authority, that which would be used to sign PASSporTs.
      </t>
      <section anchor="scope" title="Scope numbered="true" toc="default">
        <name>Scope of Delegation"> Delegation</name>
        <t>
	The TNAuthList of a STIR certificate may contain one or more SPCs, or one or more telephone number ranges, or even a mix of SPCs and telephone number ranges. When delegating from a STIR certificate, a child certificate may inherit from its parent either or both of the above, and this specification explicitly permits SPC-only parent certificates to delegate individual telephone numbers or ranges to a child certificate, as this will be necessary in some operating environments. Depending on the sort of numbering resources that a delegate has been assigned, various syntaxes can be used to capture the delegated resource.
    </t><t>
        </t>

        <t>
	  Some non-carrier entities may be assigned large and complex allocations of telephone numbers, which may be only partially contiguous or entirely disparate. Allocations may also change frequently, frequently in minor or significant ways. These resources may be so complex, dynamic, or extensive that listing them in a certificate is prohibitively difficult. Section 10.1 of

	  <xref target="RFC8226"/> target="RFC8226" sectionFormat="of" section="10.1"/> describes one potential way to address this, this: including the TNAuthList (specified in <xref target="RFC8226"/>) target="RFC8226" format="default"/>) in the certificate by-reference by reference rather than by value, where a URL in the certificate points to a secure, dynamically-updated dynamically updated list of the telephone numbers in the scope of authority of a certificate. For entities that are carriers in all but name, another alternative is the allocation of an SPC; this yields much the same property, as the SPC is effectively a pointer to an external database which that dynamically tracks the numbers associated with the SPC. Either of these approaches may make sense for a given deployment.

	  Certification path construction as detailed below treats by-reference TNAuthLists in a certificate as if it they had been included by-value.
    </t><t> by value.
        </t>
        <t>
    Other non-carrier entities may have straightforward telephone number assignments, such as enterprises receiving a set of a thousand blocks from a carrier that may be kept for years or decades. Particular freephone numbers may also have a long-term association with an enterprise and its brand. For these sorts of assignments, assigning an SPC may seem like overkill, and using the TN ranges of the TNAuthList (by-value) (by value) is sufficient.
    </t><t>
        </t>
        <t>

     Whichever approach is taken to representing represent the delegated resource, there are fundamental trade-offs regarding when and where in the architecture a delegation is validated: validated -- that is, when the delegated TNAuthList is checked and determined to be "encompassed" by the TNAuthList of its parent. This might be performed at the time the delegate certificate is issued, or at the time that a verification service receives an inbound call, or potentially both. It is generally desirable to offload as much of this as possible to the certification process, process as verification occurs during call setup and thus setup; thus, additional network dips could lead to perceptible delay, whereas certification happens outside of call processing as a largely administrative function. Ideally, if a delegate certificate can supply a by-value TN range, then a verification service could ascertain that an attested calling party number is within the scope of the provided certificate without requiring any additional transactions with a service. In practice, verification services 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>
        </t>
        <t>
	Note that the permission semantics of the <xref target="RFC8226"/> TNAuthList <xref target="RFC8226" format="default"/> are additive: that is, the scope of a certificate is the superset of all of the
	SPCs and telephone number ranges enumerated in the TNAuthList. As SPCs themselves are effectively pointers to a set of telephone number ranges, and a telephone number may
	belong to more than one SPC, this may introduce some redundancy to the set of telephone numbers specified as the scope of a certificate. The presence of
	one or more SPCs and one or more sets of
	telephone number ranges are similarly treated additively, even if the telephone number ranges turn out to be redundant to the scope of an SPC.
        </t>
      </section>
    </section>
    <section anchor="as" title="Authentication Services numbered="true" toc="default">
      <name>Authentication Service Signing with Delegate Certificates"> Certificates</name>
      <t>
	Authentication service behavior varies from <xref target="RFC8224"/> target="RFC8224" format="default"/> as follows, although the same checks are performed by the authentication service when comparing the calling party number attested in call signaling with the scope of the authority of the signing certificate. Authentication services SHOULD NOT <bcp14>SHOULD NOT</bcp14> use a delegate certificate without validating that its scope of authority is encompassed by that of its parent certificate, and if that certificate has its own parent, the entire certification path SHOULD <bcp14>SHOULD</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 authentication service that holds the private key corresponding to the delegate certificate, including one run by an outbound service provider, a third party in an enterprise's outbound call path, or in the SIP User Agent itself.
        </t><t>
      </t>
      <t>
	Note that authentication services creating a PASSporT for a call signed with a delegate certificate MUST <bcp14>MUST</bcp14> provide an "x5u" link corresponding to the entire certification path, path rather than just the delegate certificate used to sign the call, as described in <xref target="chain"/>. target="chain" format="default"/>.
      </t>
    </section>
    <section anchor="vs" title="Verification numbered="true" toc="default">
      <name>Verification Service Behavior for Delegate Certificate Signatures"> Signatures</name>
      <t>
	The responsibility of a verification service validating PASSporTs signed with delegate certificates, while largely following baseline specifications <xref target="RFC8224"/> target="RFC8224" format="default"/> and <xref target="RFC8225"/>, target="RFC8225" format="default"/>, requires some additional procedures. When the verification service dereferences the "x5u" parameter, it will acquire a certificate list rather than a single certificate. It MUST <bcp14>MUST</bcp14> then validate all of the credentials in the list, identifying the parent certificate for each delegate through its Authority Key Identifier extension.
	</t><t>
      </t>
      <t>
	While ordinarily, relying parties ordinarily have significant latitude in certification path construction when validating a certification path, STIR assumes a more rigid hierarchical subordination model, model rather than one where relying parties may want to derive their own certification path to particular trust anchors. If the certificates acquired from the "x5u" element of a PASSporT do not lead to an anchor that the verification service trusts, it treats the validation no differently than it would when a non-delegated certificate was issued by an untrusted root; in SIP, it MAY <bcp14>MAY</bcp14> return a 437 "Unsupported Credential" response if the call should be failed for lack of a valid Identity header.
      </t>
    </section>
    <section anchor="chain" title="Acquiring numbered="true" toc="default">
      <name>Acquiring Multiple Certificates in STIR"> STIR</name>
      <t>
	<xref target="RFC8225">PASSporT</xref> target="RFC8225" format="default">PASSporT</xref> uses the "x5u" element 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 Identity header when a PASSporT is conveyed via SIP. Commonly, this is an HTTPS URI.
	</t><t>
      </t>

      <t>
    When a STIR delegate certificate is used to sign a PASSporT, the "x5u" element in the PASSporT will contain a URI indicating where a certificate list is available. While
    the baseline JSON Web Signature (JWS) also supports an "x5c" element specifically for certificate chains, in operational practice, certification paths are already being delivered in the STIR environment via the "x5u" element, so this specification RECOMMENDS that implementations contain continue to use "x5u"; "x5u". "x5c" is OPTIONAL <bcp14>OPTIONAL</bcp14> for environments where it is known to be supported.

		That list will be a concatenation of PEM-encoded certificates encoded with Privacy Enhanced Mail (PEM) of the type "application/pem-certificate-chain" defined in <xref target="RFC8555"/>. target="RFC8555" format="default"/>. The <xref target="RFC5280">certificate target="RFC5280" format="default">certificate path</xref> ordering MUST <bcp14>MUST</bcp14> be ordered from the signer to the trust anchor.
		The list begins with the certificate used to sign the PASSporT, followed by its parent, and then any subsequent grandparents, great-grandparents, and so on. The key identifier in the Authority Key Identifier extension in the first certificate MUST <bcp14>MUST</bcp14> appear in the Subject Key Identifier extension in the second certificate. The key identifier pairing MUST <bcp14>MUST</bcp14> match in this way throughout the entire chain of certificates.  Note that <xref target="RFC8555">ACME</xref> target="RFC8555" format="default">Automatic Certificate Management Environment (ACME)</xref> requires the first element in a pem-certificate-chain to be an end-entity certificate.
      </t>
    </section>
    <section anchor="sp" title="Certification numbered="true" toc="default">
      <name>Certification Authorities and Service Providers"> 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 constraints extension with the cA boolean set to "true" does not require that a service provider act as a certification authority itself; serving as a certification authority is a function requiring specialized expertise and infrastructure. Certification authorities are are, for example example, responsible for maintain maintaining certificate revocation lists and related functions, 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 issues delegate certificates for the service provider, provider if the necessary business relationships permit it. A service provider might in this case act as a Token Authority (see <xref target="acme"/>) target="acme" format="default"/>) granting its customers permissions to receive certificates from the CA.
        </t><t>
      </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, which reduces the work required of verification services. The trade-off here is that 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 able to ascertain which service provider owned those telephone numbers, information which that might be used to make an authorization decision on the terminating side. However, some additional object in the certificate outside of the TNAuthList could preserve that information; this is a potential area for future work, and longer certification paths are the only mechanism currently defined.
        </t><t>
      </t>
      <t>
        All CAs must detail in their practices and policies a requirement to validate that the "encompassing" of a delegate certificate is done by its parent. Note 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"/>) target="acme" format="default"/>) that affirms that a delegation is in the proper scope. Exactly what operational practices this entails may vary in different national telephone administrations, administrations and are thus left to the <xref target="RFC3647">CP/CPS</xref>. target="RFC3647" format="default">Certificate Policy / Certification Practice Statement (CP/CPS)</xref>.
      </t>
      <section anchor="acme" title="ACME numbered="true" toc="default">
        <name>ACME and Delegation"> Delegation</name>
        <t>

	STIR deployments commonly use <xref target="RFC8555">ACME</xref> target="RFC8555" format="default">ACME</xref> for certificate acquisition, and it is anticipated that delegate certificates as well 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-authority-token">Authority target="I-D.ietf-acme-authority-token" format="default">Authority Token</xref> from the parent with the desired <xref target="I-D.ietf-acme-authority-token-tnauthlist">TNAuthList</xref> target="I-D.ietf-acme-authority-token-tnauthlist" format="default">TNAuthList</xref> object. Note that if the client intends to do further subdelegation of its own, it should request a token with the "ca" Authority Token flag set.
    </t><t>
        </t>
        <t>
   The entity then presents that Authority Token to a CA to acquire a STIR delegate certificate. ACME returns an "application/pem-certificate-chain" object, and that object would be suitable for publishing publication as an HTTPS resource for retrieval with the PASSporT "x5u" mechanism as discussed in <xref target="chain"/>. target="chain" format="default"/>. If the CSR Certificate Signing Request (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 policy decision will be reflected by the "ca" flag in the Authority Token.
   </t><t>
        </t>
        <t>
   Service providers that want the capability to rapidly age out delegated certificates can rely on the ACME Short-Term, Automatically Renewed (STAR) <xref target="I-D.ietf-acme-star">ACME STAR</xref> target="RFC8739" format="default"/> mechanism to automate the process of short-term certificate expiry.
        </t>
      </section>
      <section title="Handling numbered="true" toc="default">
        <name>Handling Multiple Certificates"> Certificates</name>
        <t>
    In some deployments, non-carrier entities may receive telephone numbers from several different carriers. This could lead to enterprises needing to maintain a sort of STIR keyring, with different certificates delegated to them from different providers, providers. These certificates are potentially issued by different CAs, which they enterprises choose between when signing a call. This could be the case regardless of which syntax is used in the TNAuthList to represent the scope of the delegation (see <xref target="scope"/>). target="scope" format="default"/>). As noted in <xref target="sp"/>, target="sp" format="default"/>, if the parent certs use the same CA, it may be possible to shorten the certification path.
            </t><t>
        </t>

        <t>
	  For non-carrier entities handling a small number of certificates, this is probably not a significant burden. For cases where it becomes burdensome, a few potential approaches exist. A delegate certificate could be cross-certified with another delegate certificate via an Authority Information Access (AIA) field containing the URL of a Certificate Authority Issuer, Issuer so that a signer would only need to sign with a single certificate to inherit the privileges of the other certificate(s) with which it has cross-certified with. cross-certified. In very complex delegation cases, it might make more sense to establish a bridge CA that cross-certifies with all of the certificates held by the enterprise, enterprise rather than requiring a mesh of cross-certification 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 would, however, complicate the fairly straightforward certification path reconstruction approach described in <xref target="chain"/> target="chain" format="default"/> and would require further specification.
        </t>
      </section>
    </section>
    <section anchor="alt" title="Alternative Solutions"> 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 permit them to issue intermediate certificates with a TNAuthList object and a cA boolean set to "true" in the basic constraints certificate extension <xref target="RFC5280"/>. target="RFC5280" format="default"/>. Similar problems in the web PKI space motivated the development of TLS subcerts <xref target="I-D.ietf-tls-subcerts"/>, target="I-D.ietf-tls-subcerts" format="default"/>, which substitutes a signed "delegated credential" token for a certificate for such environments. A comparable mechanism could be developed for the STIR space, allowing which would allow STIR certificates to sign
	a data object which that contains effectively the same data as the delegate certificate specified here, including a public key that could sign PASSporTs. The TLS subcerts system has furthermore exploring further explored leveraging ACME to issue short-lived certificates for temporary delegation as a means of obviating the need for revocation. Specification of a mechanism similar to TLS subcerts for STIR is future work, work and will be undertaken only if the market require requires it.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	This document contains has no actions for the IANA. IANA actions.
      </t>
    </section>
    <section anchor="priv" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
      Any STIR certificate that identifies a narrow range of telephone numbers potentially exposes information about the entities that are placing calls. As such a telephone number range is necessarily a necessary superset of the calling party number that is openly signaled during call setup, the privacy risks associated with this mechanism are not substantially greater than baseline STIR. See <xref target="RFC8224"/> target="RFC8224" format="default"/> for guidance on the use of anonymization mechanisms in STIR.

      </t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document is entirely about security. As delegation can allow signing in signing-in scenarios where unauthenticated "legitimate" spoofing would otherwise be used, it the hope is hoped that delegation will improve the overall security of the STIR ecosystem.  For further information on certificate security and practices, see <xref target="RFC5280"/>, in particular target="RFC5280" format="default"/>, particularly its Security Considerations. security considerations.  Also see the Security Considerations security considerations of <xref target="RFC8226"/> for general guidance on the implications of the use of certificates in STIR, STIR and <xref target="RFC7375"/> target="RFC7375" format="default"/> for the STIR threat model.
	  	  </t><t>
      </t>
      <t>
	  Much of the security of delegation depends on the implementation of the encompassing semantics described in <xref target="deleg"/>. target="deleg" format="default"/>. When delegating from 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 operating environments, such databases might not exist. How encompassing is policed is therefore a matter outside the scope of this document, document and specific to operational profiles of STIR.
		  </t><t>
      </t>

      <t>
	The use of by-reference TNAuthLists as described in <xref target="deleg"/> entails target="deleg" format="default"/> means that the TNAuthList associated with a certificate can change over time; see the security considerations of <xref target="RFC3986"/> target="RFC3986" format="default"/> 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 entails means that a relying party might once at one point accept that a particular telephone number is associated with a certificate, certificate but later reject it for the same certificate as the dynamic list changes. Also that note that if the HTTPS service housing the by-reference telephone number 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, field and is responsible for making a secure selection. Service providers acting as CAs are directed to the cautionary words about running a CA in <xref target="sp"/> target="sp" format="default"/> regarding the obligations this entails for certificate revocation and so on.
      </t>
    </section>

	    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>We would like to thank Ines Robles, Richard Barnes, Chris Wendt, Dave Hancock, Russ Housley, Benjamin Kaduk, and Sean Turner for key input on this document.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

	<references title="Normative References">
	&RFC2119;
    &RFC8174;
  &RFC5280;
&RFC8224;
&RFC8225;
&RFC8226;
&RFC8555;
&RFC3986;
<displayreference target="I-D.ietf-acme-authority-token" to="ACME-CHAL"/>
<displayreference target="I-D.ietf-acme-authority-token-tnauthlist" to="ACME-TOKEN"/>
<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.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8226.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
      </references>
    <references title="Informative References">
&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;
      <references>
        <name>Informative References</name>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-acme-authority-token.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-acme-authority-token-tnauthlist.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7375.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8739.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-tls-subcerts.xml"/>
	<reference anchor='X.509'> anchor="X.509" target="https://www.itu.int/rec/T-REC-X.509">
          <front>
            <title>Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks</title>
            <author>
              <organization>
ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8
              </organization>
            </author>
            <date year='2012' /> year="2016" month="October"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.509"></seriesInfo>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>We would like to thank <contact fullname="Ines Robles"/>, <contact fullname="Richard Barnes"/>, <contact fullname="Chris Wendt"/>, <contact fullname="Dave Hancock"/>, <contact fullname="Russ Housley"/>, <contact fullname="Benjamin Kaduk"/>, and <contact fullname="Sean Turner"/> for key input on this document.</t>
    </section>
  </back>

</rfc>