diff options
Diffstat (limited to 'doc/rfc/rfc9060.txt')
| -rw-r--r-- | doc/rfc/rfc9060.txt | 633 |
1 files changed, 633 insertions, 0 deletions
diff --git a/doc/rfc/rfc9060.txt b/doc/rfc/rfc9060.txt new file mode 100644 index 0000000..5c3a182 --- /dev/null +++ b/doc/rfc/rfc9060.txt @@ -0,0 +1,633 @@ + + + + +Internet Engineering Task Force (IETF) J. Peterson +Request for Comments: 9060 Neustar +Category: Standards Track September 2021 +ISSN: 2070-1721 + + + Secure Telephone Identity Revisited (STIR) Certificate Delegation + +Abstract + + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + 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 (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Motivation + 4. Delegation of STIR Certificates + 4.1. Scope of Delegation + 5. Authentication Service Signing with Delegate Certificates + 6. Verification Service Behavior for Delegate Certificate + Signatures + 7. Acquiring Multiple Certificates in STIR + 8. Certification Authorities and Service Providers + 8.1. ACME and Delegation + 8.2. Handling Multiple Certificates + 9. Alternative Solutions + 10. IANA Considerations + 11. Privacy Considerations + 12. Security Considerations + 13. References + 13.1. Normative References + 13.2. Informative References + Acknowledgments + Author's Address + +1. Introduction + + The STIR problem statement [RFC7340] reviews the difficulties facing + the telephone network that are enabled by impersonation, including + various forms of robocalling, voicemail hacking, and swatting + [RFC7375]. One of the most important components of a system to + prevent impersonation is the implementation of credentials that + identify the parties who control telephone numbers. The STIR + certificate specification [RFC8226] describes a credential system + based on version 3 certificates [X.509] in accordance with [RFC5280] + for that purpose. Those credentials can then be used by STIR + authentication services [RFC8224] to sign PASSporT objects [RFC8225] + carried in SIP [RFC3261] requests. + + [RFC8226] 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. + + Initial deployment of [RFC8226] 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 when needed. Additionally, a carrier may sometimes operate + numbers that are formally assigned to another carrier. [RFC8226] + gives an overview of a certificate enrollment model based on + "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. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + This specification also uses the following terms: + + delegation: The concept of STIR certificate delegation and its terms + are defined in [RFC8226]. + + legitimate spoofing: The practice of selecting an alternative + presentation number for a telephone caller legitimately. + +3. Motivation + + 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. + + One example would be an enterprise that places outbound calls through + a set of service providers; for each 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. + + A user might also roam from their usual service provider to a + different network or administrative domain for various reasons. Most + "legitimate spoofing" examples are of this form, where a user wants + to be able to use the main callback number for their business as a + calling party number, even when the user is away from the business. + + 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. + +4. Delegation of STIR Certificates + + 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 + or by reference; see Section 4.1). The parent certificate needs to + contain a basic constraints extension with the cA boolean set to + "true" [RFC5280], indicating that the subject can sign certificates. + Every STIR delegate certificate identifies its parent certificate + with a standard Authority Key Identifier extension [RFC5280]. + + 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 name constraints [RFC5280] are not directly + applicable to STIR. In a manner similar to the Resource Public Key + Infrastructure (RPKI) [RFC6480] "encompassing" semantics, each + delegate certificate MUST have a TNAuthList scope that is equal to or + a subset of its parent certificate's scope: it must be "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, to another delegate, a certificate + for the individual number +1-212-555-1824. + + Delegate certificates MAY 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 with either an identical TNAuthList to its parent or a + subset of the parent's authority, which would be used to sign + PASSporTs. + +4.1. Scope of Delegation + + 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 + 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. + + 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 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 [RFC8226] describes one + potential way to address this: including the TNAuthList (specified in + [RFC8226]) in the certificate by reference rather than by value, + where a URL in the certificate points to a secure, 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 + 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 they had been included by value. + + 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) is sufficient. + + Whichever approach is taken to represent the delegated resource, + there are fundamental trade-offs regarding when and where in the + architecture a delegation is 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, 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 as verification occurs during call 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. + + Note that the permission semantics of the TNAuthList [RFC8226] 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. + +5. Authentication Service Signing with Delegate Certificates + + Authentication service behavior varies from [RFC8224] 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 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 be validated. + + 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. + + Note that authentication services creating a PASSporT for a call + signed with a delegate certificate MUST provide an "x5u" link + corresponding to the entire certification path rather than just the + delegate certificate used to sign the call, as described in + Section 7. + +6. Verification Service Behavior for Delegate Certificate Signatures + + The responsibility of a verification service validating PASSporTs + signed with delegate certificates, while largely following baseline + specifications [RFC8224] and [RFC8225], 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 then validate all of the credentials in the + list, identifying the parent certificate for each delegate through + its Authority Key Identifier extension. + + While relying parties ordinarily have significant latitude in + certification path construction when validating a certification path, + STIR assumes a more rigid hierarchical subordination 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 return a 437 "Unsupported + Credential" response if the call should be failed for lack of a valid + Identity header. + +7. Acquiring Multiple Certificates in STIR + + PASSporT [RFC8225] 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. + + 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 continue to use + "x5u". "x5c" is OPTIONAL for environments where it is known to be + supported. That list will be a concatenation of certificates encoded + with Privacy Enhanced Mail (PEM) of the type "application/pem- + certificate-chain" defined in [RFC8555]. The certificate path + [RFC5280] ordering MUST 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 + appear in the Subject Key Identifier extension in the second + certificate. The key identifier pairing MUST match in this way + throughout the entire chain of certificates. Note that Automatic + Certificate Management Environment (ACME) [RFC8555] requires the + first element in a pem-certificate-chain to be an end-entity + certificate. + +8. Certification Authorities and Service Providers + + 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, for example, + responsible for maintaining certificate revocation lists and related + functions as well as publishing certification practice statements. A + third-party certification authority, including the same one that + issued the service provider its parent certificate, could act as the + CA that issues delegate certificates for the service provider if the + necessary business relationships permit it. A service provider might + in this case act as a Token Authority (see Section 8.1) granting its + customers permissions to receive certificates from the CA. + + 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 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. + + 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 Section 8.1) that affirms + that a delegation is in the proper scope. Exactly what operational + practices this entails may vary in different national telephone + administrations and are thus left to the Certificate Policy / + Certification Practice Statement (CP/CPS) [RFC3647]. + +8.1. ACME and Delegation + + STIR deployments commonly use ACME [RFC8555] for certificate + acquisition, and it is anticipated that delegate certificates will + also be acquired through an ACME interface. An entity can acquire a + certificate from a particular CA by requesting an Authority Token + [ACME-CHAL] from the parent with the desired TNAuthList [ACME-TOKEN] + 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. + + 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 + publication as an HTTPS resource for retrieval with the PASSporT + "x5u" mechanism as discussed in Section 7. If the 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. + + Service providers that want the capability to rapidly age out + delegated certificates can rely on the ACME Short-Term, Automatically + Renewed (STAR) [RFC8739] mechanism to automate the process of short- + term certificate expiry. + +8.2. Handling Multiple Certificates + + 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. + These certificates are potentially issued by different CAs, which + 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 Section 4.1). As noted in + 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, + 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 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. 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 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, complicate + the fairly straightforward certification path reconstruction approach + described in Section 7 and would require further specification. + +9. Alternative Solutions + + 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 [RFC5280]. Similar problems in the + web PKI space motivated the development of TLS subcerts [TLS-CRED], + which substitutes a signed "delegated credential" token for a + certificate for such environments. A comparable mechanism could be + developed for the STIR space, which would allow STIR certificates to + sign a data object that contains effectively the same data as the + delegate certificate specified here, including a public key that + could sign PASSporTs. The TLS subcerts system has 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 and will be undertaken only if the market requires it. + +10. IANA Considerations + + This document has no IANA actions. + +11. Privacy Considerations + + 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 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 [RFC8224] for guidance + on the use of anonymization mechanisms in STIR. + +12. Security Considerations + + This document is entirely about security. As delegation can allow + signing-in scenarios where unauthenticated "legitimate" spoofing + would otherwise be used, the hope is that delegation will improve the + overall security of the STIR ecosystem. For further information on + certificate security and practices, see [RFC5280], particularly its + security considerations. Also see the security considerations of + [RFC8226] for general guidance on the implications of the use of + certificates in STIR and [RFC7375] for the STIR threat model. + + Much of the security of delegation depends on the implementation of + the encompassing semantics described in Section 4. 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 and + specific to operational profiles of STIR. + + The use of by-reference TNAuthLists as described in Section 4 means + that the TNAuthList associated with a certificate can change over + time; see the security considerations of [RFC3986] for more on the + implications of this property. It is considered a useful feature + here due to the potential dynamism of large lists of telephone + numbers, but this dynamism means that a relying party might at one + point accept that a particular telephone number is associated with a + certificate but later reject it for the same certificate as the + dynamic list changes. Also 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 and is + responsible for making a secure selection. Service providers acting + as CAs are directed to the cautionary words about running a CA in + Section 8 regarding the obligations this entails for certificate + revocation and so on. + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <https://www.rfc-editor.org/info/rfc3986>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, + "Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 8224, + DOI 10.17487/RFC8224, February 2018, + <https://www.rfc-editor.org/info/rfc8224>. + + [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion + Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, + <https://www.rfc-editor.org/info/rfc8225>. + + [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity + Credentials: Certificates", RFC 8226, + DOI 10.17487/RFC8226, February 2018, + <https://www.rfc-editor.org/info/rfc8226>. + + [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. + Kasten, "Automatic Certificate Management Environment + (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, + <https://www.rfc-editor.org/info/rfc8555>. + +13.2. Informative References + + [ACME-CHAL] + Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME + Challenges Using an Authority Token", Work in Progress, + Internet-Draft, draft-ietf-acme-authority-token-06, 12 + July 2021, <https://datatracker.ietf.org/doc/html/draft- + ietf-acme-authority-token-06>. + + [ACME-TOKEN] + Wendt, C., Hancock, D., Barnes, M., and J. Peterson, + "TNAuthList profile of ACME Authority Token", Work in + Progress, Internet-Draft, draft-ietf-acme-authority-token- + tnauthlist-08, 27 March 2021, + <https://datatracker.ietf.org/doc/html/draft-ietf-acme- + authority-token-tnauthlist-08>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. + Wu, "Internet X.509 Public Key Infrastructure Certificate + Policy and Certification Practices Framework", RFC 3647, + DOI 10.17487/RFC3647, November 2003, + <https://www.rfc-editor.org/info/rfc3647>. + + [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support + Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, + February 2012, <https://www.rfc-editor.org/info/rfc6480>. + + [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure + Telephone Identity Problem Statement and Requirements", + RFC 7340, DOI 10.17487/RFC7340, September 2014, + <https://www.rfc-editor.org/info/rfc7340>. + + [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", + RFC 7375, DOI 10.17487/RFC7375, October 2014, + <https://www.rfc-editor.org/info/rfc7375>. + + [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor + Perales, A., and T. Fossati, "Support for Short-Term, + Automatically Renewed (STAR) Certificates in the Automated + 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 + + Jon Peterson + Neustar, Inc. + + Email: jon.peterson@team.neustar |