rfc9060.original   rfc9060.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft Neustar Request for Comments: 9060 Neustar
Intended status: Standards Track February 21, 2021 Category: Standards Track June 2021
Expires: August 25, 2021 ISSN: 2070-1721
STIR Certificate Delegation Secure Telephone Identity Revisited (STIR) Certificate Delegation
draft-ietf-stir-cert-delegation-04
Abstract Abstract
The Secure Telephone Identity Revisited (STIR) certificate profile The Secure Telephone Identity Revisited (STIR) certificate profile
provides a way to attest authority over telephone numbers and related provides a way to attest authority over telephone numbers and related
identifiers for the purpose of preventing telephone number spoofing. identifiers for the purpose of preventing telephone number spoofing.
This specification details how that authority can be delegated from a This specification details how that authority can be delegated from a
parent certificate to a subordinate certificate. This supports a parent certificate to a subordinate certificate. This supports a
number of use cases, including those where service providers grant number of use cases, including those where service providers grant
credentials to enterprises or other customers capable of signing credentials to enterprises or other customers capable of signing
calls with STIR. calls with STIR.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 25, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9060.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation
4. Delegation of STIR Certificates . . . . . . . . . . . . . . . 4 4. Delegation of STIR Certificates
4.1. Scope of Delegation . . . . . . . . . . . . . . . . . . . 5 4.1. Scope of Delegation
5. Authentication Services Signing with Delegate Certificates . 6 5. Authentication Service Signing with Delegate Certificates
6. Verification Service Behavior for Delegate Certificate 6. Verification Service Behavior for Delegate Certificate
Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 7 Signatures
7. Acquiring Multiple Certificates in STIR . . . . . . . . . . . 7 7. Acquiring Multiple Certificates in STIR
8. Certification Authorities and Service Providers . . . . . . . 8 8. Certification Authorities and Service Providers
8.1. ACME and Delegation . . . . . . . . . . . . . . . . . . . 9 8.1. ACME and Delegation
8.2. Handling Multiple Certificates . . . . . . . . . . . . . 9 8.2. Handling Multiple Certificates
9. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 10 9. Alternative Solutions
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 11. Privacy Considerations
12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 13. References
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 13.1. Normative References
14.1. Normative References . . . . . . . . . . . . . . . . . . 12 13.2. Informative References
14.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] reviews the difficulties facing The STIR problem statement [RFC7340] reviews the difficulties facing
the telephone network that are enabled by impersonation, including the telephone network that are enabled by impersonation, including
various forms of robocalling, voicemail hacking, and swatting various forms of robocalling, voicemail hacking, and swatting
[RFC7375]. One of the most important components of a system to [RFC7375]. One of the most important components of a system to
prevent impersonation is the implementation of credentials which prevent impersonation is the implementation of credentials that
identify the parties who control telephone numbers. The STIR identify the parties who control telephone numbers. The STIR
certificates [RFC8226] specification describes a credential system certificate specification [RFC8226] describes a credential system
based on [X.509] version 3 certificates in accordance with [RFC5280] based on version 3 certificates [X.509] in accordance with [RFC5280]
for that purpose. Those credentials can then be used by STIR for that purpose. Those credentials can then be used by STIR
authentication services [RFC8224] to sign PASSporT objects [RFC8225] authentication services [RFC8224] to sign PASSporT objects [RFC8225]
carried in SIP [RFC3261] requests. carried in SIP [RFC3261] requests.
[RFC8226] specifies an extension to X.509 that defines a Telephony [RFC8226] specifies an extension to X.509 that defines a Telephony
Number (TN) Authorization List that may be included by certification Number (TN) Authorization List that may be included by certification
authorities (CAs) in certificates. This extension provides authorities (CAs) in certificates. This extension provides
additional information that relying parties can use when validating additional information that relying parties can use when validating
transactions with the certificate. When a SIP request, for example, transactions with the certificate. When a SIP request, for example,
arrives at a terminating administrative domain, the calling number arrives at a terminating administrative domain, the calling number
attested by the SIP request can be compared to the TN Authorization attested by the SIP request can be compared to the TN Authorization
List of the certificate that signed the PASSporT to determine if the List of the certificate that signed the PASSporT to determine if the
caller is authorized to use that calling number. caller is authorized to use that calling number.
Initial deployment of [RFC8226] has focused on the use of Service Initial deployment of [RFC8226] has focused on the use of Service
Provider Codes (SPCs) to attest the scope of authority of a Provider Codes (SPCs) to attest to the scope of authority of a
certificate. Typically, these codes are internal telephone network certificate. Typically, these codes are internal telephone network
identifiers such as the Operating Company Numbers (OCNs) assigned to identifiers such as the Operating Company Numbers (OCNs) assigned to
carriers in the United States. However, these network identifiers carriers in the United States. However, these network identifiers
are effectively unavailable to non-carrier entities, and this has are effectively unavailable to non-carrier entities, and this has
raised questions about how such entities might best participate in raised questions about how such entities might best participate in
STIR, when needed. Additionally, a carrier may sometimes operate STIR when needed. Additionally, a carrier may sometimes operate
numbers that are formally assigned to another carrier. [RFC8226] numbers that are formally assigned to another carrier. [RFC8226]
gave an overview of a certificate enrollment model based on gives an overview of a certificate enrollment model based on
"delegation," whereby the holder of a certificate might allocate a "delegation", whereby the holder of a certificate might allocate a
subset of that certificate's authority to another party. This subset of that certificate's authority to another party. This
specification details how delegation of authority works for STIR specification details how delegation of authority works for STIR
certificates. certificates.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification also uses the terms: This specification also uses the following terms:
delegation: the concept of STIR certificate delegation and its terms delegation: The concept of STIR certificate delegation and its terms
are defined in [RFC8226]. are defined in [RFC8226].
legitimate spoofing: the practice of selecting an alternative legitimate spoofing: The practice of selecting an alternative
presentation number for a telephone caller legitimately. presentation number for a telephone caller legitimately.
3. Motivation 3. Motivation
The most pressing need for delegation in STIR arises in a set of use 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 cases where callers want to use a particular calling number, but for
whatever reason, their outbound calls will not pass through the whatever reason, their outbound calls will not pass through the
authentication service of the service provider that controls that authentication service of the service provider that controls that
numbering resource. numbering resource.
One example would be an enterprise that places outbound calls through One example would be an enterprise that places outbound calls through
a set of service providers, for each call choosing a provider based a set of service providers; for each call, a provider is chosen based
on a least-cost routing algorithm or similar local policy. The on a least-cost routing algorithm or similar local policy. The
enterprise was assigned a calling number by a particular service enterprise was assigned a calling number by a particular service
provider, but some calls originating from that number will go out provider, but some calls originating from that number will go out
through other service providers. through other service providers.
A user might also roam from their usual service provider to a A user might also roam from their usual service provider to a
different network or administrative domain, for various reasons. different network or administrative domain for various reasons. Most
Most "legitimate spoofing" examples are of this form: where a user "legitimate spoofing" examples are of this form, where a user wants
wants to be able to use the main call-back number for their business to be able to use the main callback number for their business as a
as a calling party number, even when the user is away from the calling party number, even when the user is away from the business.
business.
These sorts of use cases could be addressed if the carrier who These sorts of use cases could be addressed if the carrier who
controls the numbering resource were able to delegate a credential controls the numbering resource were able to delegate a credential
that could be used to sign calls regardless of which network or that could be used to sign calls regardless of which network or
administrative domain handles the outbound routing for the call. In administrative domain handles the outbound routing for the call. In
the absence of something like a delegation mechanism, outbound the absence of something like a delegation mechanism, outbound
carriers may be forced to sign calls with credentials that do not carriers may be forced to sign calls with credentials that do not
cover the originating number in question. Unfortunately, that cover the originating number in question. Unfortunately, that
practice would be difficult to distinguish from malicious spoofing, practice would be difficult to distinguish from malicious spoofing,
and if it becomes widespread, it could erode trust in STIR overall. and if it becomes widespread, it could erode trust in STIR overall.
4. Delegation of STIR Certificates 4. Delegation of STIR Certificates
STIR delegate certificates are certificates containing a TNAuthList STIR delegate certificates are certificates containing a TNAuthList
object that have been signed with the private key of a parent object that have been signed with the private key of a parent
certificate that itself contains a TNAuthList object (either by-value certificate that itself contains a TNAuthList object (either by value
or by-reference, see Section 4.1). The parent certificate needs to or by reference; see Section 4.1). The parent certificate needs to
contain a basic constraints extension with the [RFC5280] cA boolean contain a basic constraints extension with the cA boolean set to
set to "true", indicating that the subject can sign certificates. "true" [RFC5280], indicating that the subject can sign certificates.
Every STIR delegate certificate identifies its parent certificate Every STIR delegate certificate identifies its parent certificate
with a standard [RFC5280] Authority Key Identifier extension. with a standard Authority Key Identifier extension [RFC5280].
The authority bestowed on the holder of the delegate certificate by The authority bestowed on the holder of the delegate certificate by
the parent certificate is recorded in the delegate certificate's the parent certificate is recorded in the delegate certificate's
TNAuthList. Because STIR certificates use the TNAuthList object TNAuthList. Because STIR certificates use the TNAuthList object
rather than the Subject Name for indicating the scope of their rather than the Subject Name for indicating the scope of their
authority, traditional [RFC5280] name constraints are not directly authority, traditional name constraints [RFC5280] are not directly
applicable to STIR. In a manner similar to the RPKI [RFC6480] applicable to STIR. In a manner similar to the Resource Public Key
"encompassing" semantics, each delegate certificate MUST have a Infrastructure (RPKI) [RFC6480] "encompassing" semantics, each
TNAuthList scope that is equal to or a subset of its parent delegate certificate MUST have a TNAuthList scope that is equal to or
certificate's scope: it must be "encompassed." For example, a parent a subset of its parent certificate's scope: it must be "encompassed".
certificate with a TNAuthList that attested authority for the For example, a parent certificate with a TNAuthList that attested
numbering range +1-212-555-1000 through 1999 could issue a authority for the numbering range +1-212-555-1000 through 1999 could
certificate to one delegate attesting authority for the range issue a certificate to one delegate attesting authority for the range
+1-212-555-1500 through 1599, and to another delegate a certificate +1-212-555-1500 through 1599 and, to another delegate, a certificate
for the individual number +1-212-555-1824. for the individual number +1-212-555-1824.
Delegate certificates MAY also contain a basic constraints extension Delegate certificates MAY also contain a basic constraints extension
with the cA boolean set to "true", indicating that they can sign with the cA boolean set to "true", indicating that they can sign
subordinate certificates for further delegates. As only end-entity subordinate certificates for further delegates. As only end-entity
certificates can actually sign PASSporTs, the holder of a STIR certificates can actually sign PASSporTs, the holder of a STIR
certificate with a "true" cA boolean may create a separate end-entity certificate with a "true" cA boolean may create a separate end-entity
certificate either with an identical TNAuthList to its parent, or certificate with either an identical TNAuthList to its parent or a
with a subset of the parents authority, that would be used to sign subset of the parent's authority, which would be used to sign
PASSporTs. PASSporTs.
4.1. Scope of Delegation 4.1. Scope of Delegation
The TNAuthList of a STIR certificate may contain one or more SPCs, or The TNAuthList of a STIR certificate may contain one or more SPCs,
one or more telephone number ranges, or even a mix of SPCs and one or more telephone number ranges, or even a mix of SPCs and
telephone number ranges. When delegating from a STIR certificate, a telephone number ranges. When delegating from a STIR certificate, a
child certificate may inherit from its parent either or both of the child certificate may inherit from its parent either or both of the
above, and this specification explicitly permits SPC-only parent above, and this specification explicitly permits SPC-only parent
certificates to delegate individual telephone numbers or ranges to a certificates to delegate individual telephone numbers or ranges to a
child certificate, as this will be necessary in some operating child certificate, as this will be necessary in some operating
environments. Depending on the sort of numbering resources that a environments. Depending on the sort of numbering resources that a
delegate has been assigned, various syntaxes can be used to capture delegate has been assigned, various syntaxes can be used to capture
the delegated resource. the delegated resource.
Some non-carrier entities may be assigned large and complex Some non-carrier entities may be assigned large and complex
allocations of telephone numbers, which may be only partially allocations of telephone numbers, which may be only partially
contiguous or entirely disparate. Allocations may also change contiguous or entirely disparate. Allocations may also change
frequently, in minor or significant ways. These resources may be so frequently in minor or significant ways. These resources may be so
complex, dynamic, or extensive that listing them in a certificate is complex, dynamic, or extensive that listing them in a certificate is
prohibitively difficult. Section 10.1 of [RFC8226] describes one prohibitively difficult. Section 10.1 of [RFC8226] describes one
potential way to address this, including the TNAuthList (specified in potential way to address this: including the TNAuthList (specified in
[RFC8226]) in the certificate by-reference rather than by value, [RFC8226]) in the certificate by reference rather than by value,
where a URL in the certificate points to a secure, dynamically- where a URL in the certificate points to a secure, dynamically
updated list of the telephone numbers in the scope of authority of a updated list of the telephone numbers in the scope of authority of a
certificate. For entities that are carriers in all but name, another certificate. For entities that are carriers in all but name, another
alternative is the allocation of an SPC; this yields much the same alternative is the allocation of an SPC; this yields much the same
property, as the SPC is effectively a pointer to an external database property, as the SPC is effectively a pointer to an external database
which dynamically tracks the numbers associated with the SPC. Either that dynamically tracks the numbers associated with the SPC. Either
of these approaches may make sense for a given deployment. of these approaches may make sense for a given deployment.
Certification path construction as detailed below treats by-reference Certification path construction as detailed below treats by-reference
TNAuthLists in a certificate as if it had been included by-value. TNAuthLists in a certificate as if they had been included by value.
Other non-carrier entities may have straightforward telephone number Other non-carrier entities may have straightforward telephone number
assignments, such as enterprises receiving a set of thousand blocks assignments, such as enterprises receiving a set of a thousand blocks
from a carrier that may be kept for years or decades. Particular from a carrier that may be kept for years or decades. Particular
freephone numbers may also have a long-term association with an freephone numbers may also have a long-term association with an
enterprise and its brand. For these sorts of assignments, assigning enterprise and its brand. For these sorts of assignments, assigning
an SPC may seem like overkill, and using the TN ranges of the an SPC may seem like overkill, and using the TN ranges of the
TNAuthList (by-value) is sufficient. TNAuthList (by value) is sufficient.
Whichever approach is taken to representing the delegated resource, Whichever approach is taken to represent the delegated resource,
there are fundamental trade-offs regarding when and where in the there are fundamental trade-offs regarding when and where in the
architecture a delegation is validated: that is, when the delegated architecture a delegation is validated -- that is, when the delegated
TNAuthList is checked to be "encompassed" by the TNAuthList of its TNAuthList is checked and determined to be "encompassed" by the
parent. This might be performed at the time the delegate certificate TNAuthList of its parent. This might be performed at the time the
is issued, or at the time that a verification service receives an delegate certificate is issued, at the time that a verification
inbound call, or potentially both. It is generally desirable to service receives an inbound call, or potentially both. It is
offload as much of this as possible to the certification process, as generally desirable to offload as much of this as possible to the
verification occurs during call setup and thus additional network certification process as verification occurs during call setup; thus,
dips could lead to perceptible delay, whereas certification happens additional network dips could lead to perceptible delay, whereas
outside of call processing as a largely administrative function. certification happens outside of call processing as a largely
Ideally, if a delegate certificate can supply a by-value TN range, administrative function. Ideally, if a delegate certificate can
then a verification service could ascertain that an attested calling supply a by-value TN range, then a verification service could
party number is within the scope of the provided certificate without ascertain that an attested calling party number is within the scope
requiring any additional transactions with a service. In practice, of the provided certificate without requiring any additional
verification services may already incorporate network queries into transactions with a service. In practice, verification services may
their processing (for example, to dereference the "x5u" field of a already incorporate network queries into their processing (for
PASSporT) that could piggyback any additional information needed by example, to dereference the "x5u" field of a PASSporT) that could
the verification service. piggyback any additional information needed by the verification
service.
Note that the permission semantics of the [RFC8226] TNAuthList are Note that the permission semantics of the TNAuthList [RFC8226] are
additive: that is, the scope of a certificate is the superset of all additive: that is, the scope of a certificate is the superset of all
of the SPCs and telephone number ranges enumerated in the TNAuthList. of the SPCs and telephone number ranges enumerated in the TNAuthList.
As SPCs themselves are effectively pointers to a set of telephone As SPCs themselves are effectively pointers to a set of telephone
number ranges, and a telephone number may belong to more than one number ranges, and a telephone number may belong to more than one
SPC, this may introduce some redundancy to the set of telephone SPC, this may introduce some redundancy to the set of telephone
numbers specified as the scope of a certificate. The presence of one 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 or more SPCs and one or more sets of telephone number ranges are
similarly treated additively, even if the telephone number ranges similarly treated additively, even if the telephone number ranges
turn out to be redundant to the scope of an SPC. turn out to be redundant to the scope of an SPC.
5. Authentication Services Signing with Delegate Certificates 5. Authentication Service Signing with Delegate Certificates
Authentication service behavior varies from [RFC8224] as follows, Authentication service behavior varies from [RFC8224] as follows,
although the same checks are performed by the authentication service although the same checks are performed by the authentication service
when comparing the calling party number attested in call signaling when comparing the calling party number attested in call signaling
with the scope of the authority of the signing certificate. with the scope of the authority of the signing certificate.
Authentication services SHOULD NOT use a delegate certificate without Authentication services SHOULD NOT use a delegate certificate without
validating that its scope of authority is encompassed by that of its validating that its scope of authority is encompassed by that of its
parent certificate, and if that certificate has its own parent, the parent certificate, and if that certificate has its own parent, the
entire certification path SHOULD be validated. entire certification path SHOULD be validated.
This delegation architecture does not require that a non-carrier This delegation architecture does not require that a non-carrier
entity act as its own authentication service. That function may be entity act as its own authentication service. That function may be
performed by any authentication service that holds the private key performed by any authentication service that holds the private key
corresponding to the delegate certificate, including one run by an corresponding to the delegate certificate, including one run by an
outbound service provider, a third party in an enterprise's outbound outbound service provider, a third party in an enterprise's outbound
call path, or in the SIP User Agent itself. call path, or in the SIP User Agent itself.
Note that authentication services creating a PASSporT for a call Note that authentication services creating a PASSporT for a call
signed with a delegate certificate MUST provide an "x5u" link signed with a delegate certificate MUST provide an "x5u" link
corresponding to the entire certification path, rather than just the corresponding to the entire certification path rather than just the
delegate certificate used to sign the call, as described in delegate certificate used to sign the call, as described in
Section 7. Section 7.
6. Verification Service Behavior for Delegate Certificate Signatures 6. Verification Service Behavior for Delegate Certificate Signatures
The responsibility of a verification service validating PASSporTs The responsibility of a verification service validating PASSporTs
signed with delegate certificates, while largely following baseline signed with delegate certificates, while largely following baseline
[RFC8224] and [RFC8225], requires some additional procedures. When specifications [RFC8224] and [RFC8225], requires some additional
the verification service dereferences the "x5u" parameter, it will procedures. When the verification service dereferences the "x5u"
acquire a certificate list rather than a single certificate. It MUST parameter, it will acquire a certificate list rather than a single
then validate all of the credentials in the list, identifying the certificate. It MUST then validate all of the credentials in the
parent certificate for each delegate through its Authority Key list, identifying the parent certificate for each delegate through
Identifier extension. its Authority Key Identifier extension.
While ordinarily, relying parties have significant latitude in While relying parties ordinarily have significant latitude in
certification path construction when validating a certification path, certification path construction when validating a certification path,
STIR assumes a more rigid hierarchical subordination model, rather STIR assumes a more rigid hierarchical subordination model rather
than one where relying parties may want to derive their own than one where relying parties may want to derive their own
certification path to particular trust anchors. If the certificates certification path to particular trust anchors. If the certificates
acquired from the "x5u" element of a PASSporT do not lead to an acquired from the "x5u" element of a PASSporT do not lead to an
anchor that the verification service trusts, it treats the validation anchor that the verification service trusts, it treats the validation
no differently than it would when a non-delegated certificate was no differently than it would when a non-delegated certificate was
issued by an untrusted root; in SIP, it MAY return a 437 "Unsupported issued by an untrusted root; in SIP, it MAY return a 437 "Unsupported
Credential" response if the call should be failed for lack of a valid Credential" response if the call should be failed for lack of a valid
Identity header. Identity header.
7. Acquiring Multiple Certificates in STIR 7. Acquiring Multiple Certificates in STIR
PASSporT [RFC8225] uses the "x5u" element to convey the URL where PASSporT [RFC8225] uses the "x5u" element to convey the URL where
verification services can acquire the certificate used to sign a verification services can acquire the certificate used to sign a
PASSporT. This value is mirrored by the "info" parameter of the PASSporT. This value is mirrored by the "info" parameter of the
Identity header when a PASSporT is conveyed via SIP. Commonly, this Identity header when a PASSporT is conveyed via SIP. Commonly, this
is an HTTPS URI. is an HTTPS URI.
When a STIR delegate certificate is used to sign a PASSporT, the When a STIR delegate certificate is used to sign a PASSporT, the
"x5u" element in the PASSporT will contain a URI indicating where a "x5u" element in the PASSporT will contain a URI indicating where a
certificate list is available. While baseline JSON Web Signature certificate list is available. While the baseline JSON Web Signature
(JWS) also supports an "x5c" element specifically for certificate (JWS) also supports an "x5c" element specifically for certificate
chains, in operational practice, certification paths are already chains, in operational practice, certification paths are already
being delivered in the STIR environment via the "x5u" element, so being delivered in the STIR environment via the "x5u" element, so
this specification RECOMMENDS implementations contain to use "x5u"; this specification RECOMMENDS that implementations continue to use
"x5c" is OPTIONAL for environments where it is known to be supported. "x5u". "x5c" is OPTIONAL for environments where it is known to be
That list will be a concatenation of PEM-encoded certificates of the supported. That list will be a concatenation of certificates encoded
type "application/pem-certificate-chain" defined in [RFC8555]. The with Privacy Enhanced Mail (PEM) of the type "application/pem-
certificate path [RFC5280] ordering MUST be ordered from the signer certificate-chain" defined in [RFC8555]. The certificate path
to the trust anchor. The list begins with the certificate used to [RFC5280] ordering MUST be ordered from the signer to the trust
sign the PASSporT, followed by its parent, and then any subsequent 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 grandparents, great-grandparents, and so on. The key identifier in
the Authority Key Identifier extension in the first certificate MUST the Authority Key Identifier extension in the first certificate MUST
appear in the Subject Key Identifier extension in the second appear in the Subject Key Identifier extension in the second
certificate. The key identifier pairing MUST match in this way certificate. The key identifier pairing MUST match in this way
throughout the entire chain of certificates. Note that ACME throughout the entire chain of certificates. Note that Automatic
[RFC8555] requires the first element in a pem-certificate-chain to be Certificate Management Environment (ACME) [RFC8555] requires the
an end-entity certificate. first element in a pem-certificate-chain to be an end-entity
certificate.
8. Certification Authorities and Service Providers 8. Certification Authorities and Service Providers
Once a telephone service provider has received a CA certificate Once a telephone service provider has received a CA certificate
attesting their numbering resources, they may delegate resources from attesting to their numbering resources, they may delegate resources
it as they see fit. Note that the allocation to a service provider from it as they see fit. Note that the allocation to a service
of a certificate with a basic constraints extension with the cA provider of a certificate with a basic constraints extension with the
boolean set to "true" does not require that a service provider act as cA boolean set to "true" does not require that a service provider act
a certification authority itself; serving as a certification as a certification authority itself; serving as a certification
authority is a function requiring specialized expertise and authority is a function requiring specialized expertise and
infrastructure. Certification authorities are for example infrastructure. Certification authorities are, for example,
responsible for maintain certificate revocation lists and related responsible for maintaining certificate revocation lists and related
functions, as well as publishing certification practice statements. functions as well as publishing certification practice statements. A
A third-party certification authority, including the same one that third-party certification authority, including the same one that
issued the service provider its parent certificate, could act as the issued the service provider its parent certificate, could act as the
CA that issues delegate certificates for the service provider, if the CA that issues delegate certificates for the service provider if the
necessary business relationships permit it. A service provider might necessary business relationships permit it. A service provider might
in this case act as a Token Authority (see Section 8.1) granting its in this case act as a Token Authority (see Section 8.1) granting its
customers permissions to receive certificates from the CA. customers permissions to receive certificates from the CA.
Note that if the same CA that issued the parent certificate is also Note that if the same CA that issued the parent certificate is also
issuing a delegate certificate, it may be possible to shorten the issuing a delegate certificate, it may be possible to shorten the
certification path, which reduces the work required of verification certification path, which reduces the work required of verification
services. The trade-off here is that if the CA simply issued a non- 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 delegate certificate (whose parent is the CA's trust anchor) with the
proper TNAuthList value, relying parties might not be able to proper TNAuthList value, relying parties might not be able to
ascertain which service provider owned those telephone numbers, ascertain which service provider owned those telephone numbers,
information which might be used to make an authorization decision on information that might be used to make an authorization decision on
the terminating side. However, some additional object in the the terminating side. However, some additional object in the
certificate outside of the TNAuthList could preserve that certificate outside of the TNAuthList could preserve that
information; this is a potential area for future work, and longer information; this is a potential area for future work, and longer
certification paths are the only mechanism currently defined. certification paths are the only mechanism currently defined.
All CAs must detail in their practices and policies a requirement to All CAs must detail in their practices and policies a requirement to
validate that the "encompassing" of a delegate certificate by its validate that the "encompassing" of a delegate certificate is done by
parent. Note that this requires that CAs have access to the its parent. Note that this requires that CAs have access to the
necessary industry databases to ascertain whether, for example, a necessary industry databases to ascertain whether, for example, a
particular telephone number is encompassed by an SPC. Alternatively, particular telephone number is encompassed by an SPC. Alternatively,
a CA may acquire an Authority Token (see Section 8.1) that affirms a CA may acquire an Authority Token (see Section 8.1) that affirms
that a delegation is in the proper scope. Exactly what operational that a delegation is in the proper scope. Exactly what operational
practices this entails may vary in different national telephone practices this entails may vary in different national telephone
administrations, and are thus left to the CP/CPS [RFC3647]. administrations and are thus left to the Certificate Policy /
Certification Practice Statement (CP/CPS) [RFC3647].
8.1. ACME and Delegation 8.1. ACME and Delegation
STIR deployments commonly use ACME [RFC8555] for certificate STIR deployments commonly use ACME [RFC8555] for certificate
acquisition, and it is anticipated that delegate certificates as well acquisition, and it is anticipated that delegate certificates will
will be acquired through an ACME interface. An entity can acquire a also be acquired through an ACME interface. An entity can acquire a
certificate from a particular CA by requesting an Authority Token certificate from a particular CA by requesting an Authority Token
[I-D.ietf-acme-authority-token] from the parent with the desired [ACME-CHAL] from the parent with the desired TNAuthList [ACME-TOKEN]
TNAuthList [I-D.ietf-acme-authority-token-tnauthlist] object. Note object. Note that if the client intends to do further subdelegation
that if the client intends to do further subdelegation of its own, it of its own, it should request a token with the "ca" Authority Token
should request a token with the "ca" Authority Token flag set. flag set.
The entity then presents that Authority Token to a CA to acquire a The entity then presents that Authority Token to a CA to acquire a
STIR delegate certificate. ACME returns an "application/pem- STIR delegate certificate. ACME returns an "application/pem-
certificate-chain" object, and that object would be suitable for certificate-chain" object, and that object would be suitable for
publishing as an HTTPS resource for retrieval with the PASSporT "x5u" publication as an HTTPS resource for retrieval with the PASSporT
mechanism as discussed in Section 7. If the CSR presented to the "x5u" mechanism as discussed in Section 7. If the Certificate
ACME server is for a certificate with the cA boolean set to "true", Signing Request (CSR) presented to the ACME server is for a
then the ACME server makes a policy decision to determine whether or certificate with the cA boolean set to "true", then the ACME server
not it is appropriate to issue that certificate to the requesting makes a policy decision to determine whether or not it is appropriate
entity. That policy decision will be reflected by the "ca" flag in to issue that certificate to the requesting entity. That policy
the Authority Token. decision will be reflected by the "ca" flag in the Authority Token.
Service providers that want the capability to rapidly age out Service providers that want the capability to rapidly age out
delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] delegated certificates can rely on the ACME Short-Term, Automatically
mechanism to automate the process of short-term certificate expiry. Renewed (STAR) [RFC8739] mechanism to automate the process of short-
term certificate expiry.
8.2. Handling Multiple Certificates 8.2. Handling Multiple Certificates
In some deployments, non-carrier entities may receive telephone In some deployments, non-carrier entities may receive telephone
numbers from several different carriers. This could lead to numbers from several different carriers. This could lead to
enterprises needing to maintain a sort of STIR keyring, with enterprises needing to maintain a sort of STIR keyring, with
different certificates delegated to them from different providers, different certificates delegated to them from different providers.
potentially issued by different CAs, which they choose between when These certificates are potentially issued by different CAs, which
signing a call. This could be the case regardless of which syntax is enterprises choose between when signing a call. This could be the
used in the TNAuthList to represent the scope of the delegation (see case regardless of which syntax is used in the TNAuthList to
Section 4.1). As noted in Section 8, if the parent certs use the represent the scope of the delegation (see Section 4.1). As noted in
same CA, it may be possible to shorten the certification path. Section 8, if the parent certs use the same CA, it may be possible to
shorten the certification path.
For non-carrier entities handling a small number of certificates, For non-carrier entities handling a small number of certificates,
this is probably not a significant burden. For cases where it this is probably not a significant burden. For cases where it
becomes burdensome, a few potential approaches exist. A delegate becomes burdensome, a few potential approaches exist. A delegate
certificate could be cross-certified with another delegate certificate could be cross-certified with another delegate
certificate via an Authority Information Access field containing the certificate via an Authority Information Access (AIA) field
URL of a Certificate Authority Issuer, so that a signer would only containing the URL of a Certificate Authority Issuer so that a signer
need to sign with a single certificate to inherit the privileges of would only need to sign with a single certificate to inherit the
the other certificate(s) it has cross-certified with. In very privileges of the other certificate(s) with which it has cross-
complex delegation cases, it might make more sense to establish a certified. In very complex delegation cases, it might make more
bridge CA that cross-certifies with all of the certificates held by sense to establish a bridge CA that cross-certifies with all of the
the enterprise, rather than requiring a mesh of cross-certification certificates held by the enterprise rather than requiring a mesh of
between a large number of certificates. Again, this bridge CA cross-certification between a large number of certificates. Again,
function would likely be performed by some existing CA in the STIR this bridge CA function would likely be performed by some existing CA
ecosystem. These procedures would however complicated the fairly in the STIR ecosystem. These procedures would, however, complicate
straightforward certification path reconstruction approach described the fairly straightforward certification path reconstruction approach
in Section 7 and would require further specification. described in Section 7 and would require further specification.
9. Alternative Solutions 9. Alternative Solutions
At the time this specification was written, STIR was only starting to At the time this specification was written, STIR was only starting to
see deployment. In some future environment, the policies that govern see deployment. In some future environment, the policies that govern
CAs may not permit them to issue intermediate certificates with a CAs may not permit them to issue intermediate certificates with a
TNAuthList object and a cA boolean set to "true" in the basic TNAuthList object and a cA boolean set to "true" in the basic
constraints certificate extension [RFC5280]. Similar problems in the constraints certificate extension [RFC5280]. Similar problems in the
web PKI space motivated the development of TLS subcerts web PKI space motivated the development of TLS subcerts [TLS-CRED],
[I-D.ietf-tls-subcerts], which substitutes a signed "delegated which substitutes a signed "delegated credential" token for a
credential" token for a certificate for such environments. A certificate for such environments. A comparable mechanism could be
comparable mechanism could be developed for the STIR space, allowing developed for the STIR space, which would allow STIR certificates to
STIR certificates to sign a data object which contains effectively sign a data object that contains effectively the same data as the
the same data as the delegate certificate specified here, including a delegate certificate specified here, including a public key that
public key that could sign PASSporTs. The TLS subcerts system has could sign PASSporTs. The TLS subcerts system has further explored
furthermore exploring leveraging ACME to issue short-lived leveraging ACME to issue short-lived certificates for temporary
certificates for temporary delegation as a means of obviating the delegation as a means of obviating the need for revocation.
need for revocation. Specification of a mechanism similar to TLS Specification of a mechanism similar to TLS subcerts for STIR is
subcerts for STIR is future work, and will be undertaken only if the future work and will be undertaken only if the market requires it.
market require it.
10. IANA Considerations 10. IANA Considerations
This document contains no actions for the IANA. This document has no IANA actions.
11. Privacy Considerations 11. Privacy Considerations
Any STIR certificate that identifies a narrow range of telephone Any STIR certificate that identifies a narrow range of telephone
numbers potentially exposes information about the entities that are numbers potentially exposes information about the entities that are
placing calls. As such a telephone number range is necessarily a placing calls. As such a telephone number range is a necessary
superset of the calling party number that is openly signaled during superset of the calling party number that is openly signaled during
call setup, the privacy risks associated with this mechanism are not call setup, the privacy risks associated with this mechanism are not
substantially greater than baseline STIR. See [RFC8224] for guidance substantially greater than baseline STIR. See [RFC8224] for guidance
on the use of anonymization mechanisms in STIR. on the use of anonymization mechanisms in STIR.
12. Security Considerations 12. Security Considerations
This document is entirely about security. As delegation can allow This document is entirely about security. As delegation can allow
signing in scenarios where unauthenticated "legitimate" spoofing signing-in scenarios where unauthenticated "legitimate" spoofing
would otherwise be used, it is hoped that delegation will improve the would otherwise be used, the hope is that delegation will improve the
overall security of the STIR ecosystem. For further information on overall security of the STIR ecosystem. For further information on
certificate security and practices, see [RFC5280], in particular its certificate security and practices, see [RFC5280], particularly its
Security Considerations. Also see the Security Considerations of security considerations. Also see the security considerations of
[RFC8226] for general guidance on the implications of the use of [RFC8226] for general guidance on the implications of the use of
certificates in STIR, and [RFC7375] for the STIR threat model. certificates in STIR and [RFC7375] for the STIR threat model.
Much of the security of delegation depends on the implementation of Much of the security of delegation depends on the implementation of
the encompassing semantics described in Section 4. When delegating the encompassing semantics described in Section 4. When delegating
from an SPC-based TNAuthList to a set of telephone number ranges, from an SPC-based TNAuthList to a set of telephone number ranges,
understanding the encompassing semantics may require access to understanding the encompassing semantics may require access to
industry databases that track the numbering assets of service industry databases that track the numbering assets of service
providers associated with a given SPC. In some operating providers associated with a given SPC. In some operating
environments, such databases might not exist. How encompassing is environments, such databases might not exist. How encompassing is
policed is therefore a matter outside the scope of this document, and policed is therefore a matter outside the scope of this document and
specific to operational profiles of STIR. specific to operational profiles of STIR.
The use of by-reference TNAuthLists as described in Section 4 entails The use of by-reference TNAuthLists as described in Section 4 means
that the TNAuthList associated with a certificate can change over that the TNAuthList associated with a certificate can change over
time; see the security considerations of [RFC3986] for more on the time; see the security considerations of [RFC3986] for more on the
implications of this property. It is considered a useful feature implications of this property. It is considered a useful feature
here due to the potential dynamism of large lists of telephone here due to the potential dynamism of large lists of telephone
numbers, but this dynamism entails that a relying party might once numbers, but this dynamism means that a relying party might at one
accept that a particular telephone number is associated with a point accept that a particular telephone number is associated with a
certificate, but later reject it for the same certificate as the certificate but later reject it for the same certificate as the
dynamic list changes. Also that note if the HTTPS service housing dynamic list changes. Also note that if the HTTPS service housing
the by-reference telephone number list is improperly secured, that the by-reference telephone number list is improperly secured, that
too can lead to vulnerabilities. Ultimately, the CA that issued a too can lead to vulnerabilities. Ultimately, the CA that issued a
delegated certificate populates the URL in the AIA field, and is delegated certificate populates the URL in the AIA field and is
responsible for making a secure selection. Service providers acting responsible for making a secure selection. Service providers acting
as CAs are directed to the cautionary words about running a CA in as CAs are directed to the cautionary words about running a CA in
Section 8 regarding the obligations this entails for certificate Section 8 regarding the obligations this entails for certificate
revocation and so on. revocation and so on.
13. Acknowledgments 13. References
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.
14. References
14.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 13, line 5 skipping to change at line 558
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
14.2. Informative References 13.2. Informative References
[I-D.ietf-acme-authority-token] [ACME-CHAL]
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Challenges Using an Authority Token", draft-ietf-acme- Challenges Using an Authority Token", Work in Progress,
authority-token-05 (work in progress), March 2020. Internet-Draft, draft-ietf-acme-authority-token-06, 12
July 2021, <https://datatracker.ietf.org/doc/html/draft-
ietf-acme-authority-token-06>.
[I-D.ietf-acme-authority-token-tnauthlist] [ACME-TOKEN]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson, Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", draft-ietf- "TNAuthList profile of ACME Authority Token", Work in
acme-authority-token-tnauthlist-06 (work in progress), Progress, Internet-Draft, draft-ietf-acme-authority-token-
March 2020. tnauthlist-08, 27 March 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-acme-
[I-D.ietf-acme-star] authority-token-tnauthlist-08>.
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-11 (work in
progress), October 2019.
[I-D.ietf-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", draft-ietf-tls-
subcerts-10 (work in progress), January 2021.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
skipping to change at page 14, line 9 skipping to change at line 600
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
RFC 7375, DOI 10.17487/RFC7375, October 2014, RFC 7375, DOI 10.17487/RFC7375, October 2014,
<https://www.rfc-editor.org/info/rfc7375>. <https://www.rfc-editor.org/info/rfc7375>.
[X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor
"Information technology - Open Systems Interconnection - Perales, A., and T. Fossati, "Support for Short-Term,
The Directory: Public-key and attribute certificate Automatically Renewed (STAR) Certificates in the Automated
frameworks", 2012. Certificate Management Environment (ACME)", RFC 8739,
DOI 10.17487/RFC8739, March 2020,
<https://www.rfc-editor.org/info/rfc8739>.
[TLS-CRED] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", Work in Progress,
Internet-Draft, draft-ietf-tls-subcerts-10, 24 January
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
tls-subcerts-10>.
[X.509] ITU-T, "Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509,
October 2016, <https://www.itu.int/rec/T-REC-X.509>.
Acknowledgments
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.
Author's Address Author's Address
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
Email: jon.peterson@team.neustar Email: jon.peterson@team.neustar
 End of changes. 70 change blocks. 
228 lines changed or deleted 233 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/