idnits 2.17.1 draft-ietf-stir-cert-delegation-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-acme-authority-token-05 == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-06 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-10 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Standards Track February 21, 2021 5 Expires: August 25, 2021 7 STIR Certificate Delegation 8 draft-ietf-stir-cert-delegation-04 10 Abstract 12 The Secure Telephone Identity Revisited (STIR) certificate profile 13 provides a way to attest authority over telephone numbers and related 14 identifiers for the purpose of preventing telephone number spoofing. 15 This specification details how that authority can be delegated from a 16 parent certificate to a subordinate certificate. This supports a 17 number of use cases, including those where service providers grant 18 credentials to enterprises or other customers capable of signing 19 calls with STIR. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 25, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Delegation of STIR Certificates . . . . . . . . . . . . . . . 4 59 4.1. Scope of Delegation . . . . . . . . . . . . . . . . . . . 5 60 5. Authentication Services Signing with Delegate Certificates . 6 61 6. Verification Service Behavior for Delegate Certificate 62 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Acquiring Multiple Certificates in STIR . . . . . . . . . . . 7 64 8. Certification Authorities and Service Providers . . . . . . . 8 65 8.1. ACME and Delegation . . . . . . . . . . . . . . . . . . . 9 66 8.2. Handling Multiple Certificates . . . . . . . . . . . . . 9 67 9. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 10 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 14.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 The STIR problem statement [RFC7340] reviews the difficulties facing 80 the telephone network that are enabled by impersonation, including 81 various forms of robocalling, voicemail hacking, and swatting 82 [RFC7375]. One of the most important components of a system to 83 prevent impersonation is the implementation of credentials which 84 identify the parties who control telephone numbers. The STIR 85 certificates [RFC8226] specification describes a credential system 86 based on [X.509] version 3 certificates in accordance with [RFC5280] 87 for that purpose. Those credentials can then be used by STIR 88 authentication services [RFC8224] to sign PASSporT objects [RFC8225] 89 carried in SIP [RFC3261] requests. 91 [RFC8226] specifies an extension to X.509 that defines a Telephony 92 Number (TN) Authorization List that may be included by certification 93 authorities (CAs) in certificates. This extension provides 94 additional information that relying parties can use when validating 95 transactions with the certificate. When a SIP request, for example, 96 arrives at a terminating administrative domain, the calling number 97 attested by the SIP request can be compared to the TN Authorization 98 List of the certificate that signed the PASSporT to determine if the 99 caller is authorized to use that calling number. 101 Initial deployment of [RFC8226] has focused on the use of Service 102 Provider Codes (SPCs) to attest the scope of authority of a 103 certificate. Typically, these codes are internal telephone network 104 identifiers such as the Operating Company Numbers (OCNs) assigned to 105 carriers in the United States. However, these network identifiers 106 are effectively unavailable to non-carrier entities, and this has 107 raised questions about how such entities might best participate in 108 STIR, when needed. Additionally, a carrier may sometimes operate 109 numbers that are formally assigned to another carrier. [RFC8226] 110 gave an overview of a certificate enrollment model based on 111 "delegation," whereby the holder of a certificate might allocate a 112 subset of that certificate's authority to another party. This 113 specification details how delegation of authority works for STIR 114 certificates. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 This specification also uses the terms: 126 delegation: the concept of STIR certificate delegation and its terms 127 are defined in [RFC8226]. 129 legitimate spoofing: the practice of selecting an alternative 130 presentation number for a telephone caller legitimately. 132 3. Motivation 134 The most pressing need for delegation in STIR arises in a set of use 135 cases where callers want to use a particular calling number, but for 136 whatever reason, their outbound calls will not pass through the 137 authentication service of the service provider that controls that 138 numbering resource. 140 One example would be an enterprise that places outbound calls through 141 a set of service providers, for each call choosing a provider based 142 on a least-cost routing algorithm or similar local policy. The 143 enterprise was assigned a calling number by a particular service 144 provider, but some calls originating from that number will go out 145 through other service providers. 147 A user might also roam from their usual service provider to a 148 different network or administrative domain, for various reasons. 149 Most "legitimate spoofing" examples are of this form: where a user 150 wants to be able to use the main call-back number for their business 151 as a calling party number, even when the user is away from the 152 business. 154 These sorts of use cases could be addressed if the carrier who 155 controls the numbering resource were able to delegate a credential 156 that could be used to sign calls regardless of which network or 157 administrative domain handles the outbound routing for the call. In 158 the absence of something like a delegation mechanism, outbound 159 carriers may be forced to sign calls with credentials that do not 160 cover the originating number in question. Unfortunately, that 161 practice would be difficult to distinguish from malicious spoofing, 162 and if it becomes widespread, it could erode trust in STIR overall. 164 4. Delegation of STIR Certificates 166 STIR delegate certificates are certificates containing a TNAuthList 167 object that have been signed with the private key of a parent 168 certificate that itself contains a TNAuthList object (either by-value 169 or by-reference, see Section 4.1). The parent certificate needs to 170 contain a basic constraints extension with the [RFC5280] cA boolean 171 set to "true", indicating that the subject can sign certificates. 172 Every STIR delegate certificate identifies its parent certificate 173 with a standard [RFC5280] Authority Key Identifier extension. 175 The authority bestowed on the holder of the delegate certificate by 176 the parent certificate is recorded in the delegate certificate's 177 TNAuthList. Because STIR certificates use the TNAuthList object 178 rather than the Subject Name for indicating the scope of their 179 authority, traditional [RFC5280] name constraints are not directly 180 applicable to STIR. In a manner similar to the RPKI [RFC6480] 181 "encompassing" semantics, each delegate certificate MUST have a 182 TNAuthList scope that is equal to or a subset of its parent 183 certificate's scope: it must be "encompassed." For example, a parent 184 certificate with a TNAuthList that attested authority for the 185 numbering range +1-212-555-1000 through 1999 could issue a 186 certificate to one delegate attesting authority for the range 187 +1-212-555-1500 through 1599, and to another delegate a certificate 188 for the individual number +1-212-555-1824. 190 Delegate certificates MAY also contain a basic constraints extension 191 with the cA boolean set to "true", indicating that they can sign 192 subordinate certificates for further delegates. As only end-entity 193 certificates can actually sign PASSporTs, the holder of a STIR 194 certificate with a "true" cA boolean may create a separate end-entity 195 certificate either with an identical TNAuthList to its parent, or 196 with a subset of the parents authority, that would be used to sign 197 PASSporTs. 199 4.1. Scope of Delegation 201 The TNAuthList of a STIR certificate may contain one or more SPCs, or 202 one or more telephone number ranges, or even a mix of SPCs and 203 telephone number ranges. When delegating from a STIR certificate, a 204 child certificate may inherit from its parent either or both of the 205 above, and this specification explicitly permits SPC-only parent 206 certificates to delegate individual telephone numbers or ranges to a 207 child certificate, as this will be necessary in some operating 208 environments. Depending on the sort of numbering resources that a 209 delegate has been assigned, various syntaxes can be used to capture 210 the delegated resource. 212 Some non-carrier entities may be assigned large and complex 213 allocations of telephone numbers, which may be only partially 214 contiguous or entirely disparate. Allocations may also change 215 frequently, in minor or significant ways. These resources may be so 216 complex, dynamic, or extensive that listing them in a certificate is 217 prohibitively difficult. Section 10.1 of [RFC8226] describes one 218 potential way to address this, including the TNAuthList (specified in 219 [RFC8226]) in the certificate by-reference rather than by value, 220 where a URL in the certificate points to a secure, dynamically- 221 updated list of the telephone numbers in the scope of authority of a 222 certificate. For entities that are carriers in all but name, another 223 alternative is the allocation of an SPC; this yields much the same 224 property, as the SPC is effectively a pointer to an external database 225 which dynamically tracks the numbers associated with the SPC. Either 226 of these approaches may make sense for a given deployment. 227 Certification path construction as detailed below treats by-reference 228 TNAuthLists in a certificate as if it had been included by-value. 230 Other non-carrier entities may have straightforward telephone number 231 assignments, such as enterprises receiving a set of thousand blocks 232 from a carrier that may be kept for years or decades. Particular 233 freephone numbers may also have a long-term association with an 234 enterprise and its brand. For these sorts of assignments, assigning 235 an SPC may seem like overkill, and using the TN ranges of the 236 TNAuthList (by-value) is sufficient. 238 Whichever approach is taken to representing the delegated resource, 239 there are fundamental trade-offs regarding when and where in the 240 architecture a delegation is validated: that is, when the delegated 241 TNAuthList is checked to be "encompassed" by the TNAuthList of its 242 parent. This might be performed at the time the delegate certificate 243 is issued, or at the time that a verification service receives an 244 inbound call, or potentially both. It is generally desirable to 245 offload as much of this as possible to the certification process, as 246 verification occurs during call setup and thus additional network 247 dips could lead to perceptible delay, whereas certification happens 248 outside of call processing as a largely administrative function. 249 Ideally, if a delegate certificate can supply a by-value TN range, 250 then a verification service could ascertain that an attested calling 251 party number is within the scope of the provided certificate without 252 requiring any additional transactions with a service. In practice, 253 verification services may already incorporate network queries into 254 their processing (for example, to dereference the "x5u" field of a 255 PASSporT) that could piggyback any additional information needed by 256 the verification service. 258 Note that the permission semantics of the [RFC8226] TNAuthList are 259 additive: that is, the scope of a certificate is the superset of all 260 of the SPCs and telephone number ranges enumerated in the TNAuthList. 261 As SPCs themselves are effectively pointers to a set of telephone 262 number ranges, and a telephone number may belong to more than one 263 SPC, this may introduce some redundancy to the set of telephone 264 numbers specified as the scope of a certificate. The presence of one 265 or more SPCs and one or more sets of telephone number ranges are 266 similarly treated additively, even if the telephone number ranges 267 turn out to be redundant to the scope of an SPC. 269 5. Authentication Services Signing with Delegate Certificates 271 Authentication service behavior varies from [RFC8224] as follows, 272 although the same checks are performed by the authentication service 273 when comparing the calling party number attested in call signaling 274 with the scope of the authority of the signing certificate. 275 Authentication services SHOULD NOT use a delegate certificate without 276 validating that its scope of authority is encompassed by that of its 277 parent certificate, and if that certificate has its own parent, the 278 entire certification path SHOULD be validated. 280 This delegation architecture does not require that a non-carrier 281 entity act as its own authentication service. That function may be 282 performed by any authentication service that holds the private key 283 corresponding to the delegate certificate, including one run by an 284 outbound service provider, a third party in an enterprise's outbound 285 call path, or in the SIP User Agent itself. 287 Note that authentication services creating a PASSporT for a call 288 signed with a delegate certificate MUST provide an "x5u" link 289 corresponding to the entire certification path, rather than just the 290 delegate certificate used to sign the call, as described in 291 Section 7. 293 6. Verification Service Behavior for Delegate Certificate Signatures 295 The responsibility of a verification service validating PASSporTs 296 signed with delegate certificates, while largely following baseline 297 [RFC8224] and [RFC8225], requires some additional procedures. When 298 the verification service dereferences the "x5u" parameter, it will 299 acquire a certificate list rather than a single certificate. It MUST 300 then validate all of the credentials in the list, identifying the 301 parent certificate for each delegate through its Authority Key 302 Identifier extension. 304 While ordinarily, relying parties have significant latitude in 305 certification path construction when validating a certification path, 306 STIR assumes a more rigid hierarchical subordination model, rather 307 than one where relying parties may want to derive their own 308 certification path to particular trust anchors. If the certificates 309 acquired from the "x5u" element of a PASSporT do not lead to an 310 anchor that the verification service trusts, it treats the validation 311 no differently than it would when a non-delegated certificate was 312 issued by an untrusted root; in SIP, it MAY return a 437 "Unsupported 313 Credential" response if the call should be failed for lack of a valid 314 Identity header. 316 7. Acquiring Multiple Certificates in STIR 318 PASSporT [RFC8225] uses the "x5u" element to convey the URL where 319 verification services can acquire the certificate used to sign a 320 PASSporT. This value is mirrored by the "info" parameter of the 321 Identity header when a PASSporT is conveyed via SIP. Commonly, this 322 is an HTTPS URI. 324 When a STIR delegate certificate is used to sign a PASSporT, the 325 "x5u" element in the PASSporT will contain a URI indicating where a 326 certificate list is available. While baseline JSON Web Signature 327 (JWS) also supports an "x5c" element specifically for certificate 328 chains, in operational practice, certification paths are already 329 being delivered in the STIR environment via the "x5u" element, so 330 this specification RECOMMENDS implementations contain to use "x5u"; 331 "x5c" is OPTIONAL for environments where it is known to be supported. 332 That list will be a concatenation of PEM-encoded certificates of the 333 type "application/pem-certificate-chain" defined in [RFC8555]. The 334 certificate path [RFC5280] ordering MUST be ordered from the signer 335 to the trust anchor. The list begins with the certificate used to 336 sign the PASSporT, followed by its parent, and then any subsequent 337 grandparents, great-grandparents, and so on. The key identifier in 338 the Authority Key Identifier extension in the first certificate MUST 339 appear in the Subject Key Identifier extension in the second 340 certificate. The key identifier pairing MUST match in this way 341 throughout the entire chain of certificates. Note that ACME 342 [RFC8555] requires the first element in a pem-certificate-chain to be 343 an end-entity certificate. 345 8. Certification Authorities and Service Providers 347 Once a telephone service provider has received a CA certificate 348 attesting their numbering resources, they may delegate resources from 349 it as they see fit. Note that the allocation to a service provider 350 of a certificate with a basic constraints extension with the cA 351 boolean set to "true" does not require that a service provider act as 352 a certification authority itself; serving as a certification 353 authority is a function requiring specialized expertise and 354 infrastructure. Certification authorities are for example 355 responsible for maintain certificate revocation lists and related 356 functions, as well as publishing certification practice statements. 357 A third-party certification authority, including the same one that 358 issued the service provider its parent certificate, could act as the 359 CA that issues delegate certificates for the service provider, if the 360 necessary business relationships permit it. A service provider might 361 in this case act as a Token Authority (see Section 8.1) granting its 362 customers permissions to receive certificates from the CA. 364 Note that if the same CA that issued the parent certificate is also 365 issuing a delegate certificate, it may be possible to shorten the 366 certification path, which reduces the work required of verification 367 services. The trade-off here is that if the CA simply issued a non- 368 delegate certificate (whose parent is the CA's trust anchor) with the 369 proper TNAuthList value, relying parties might not be able to 370 ascertain which service provider owned those telephone numbers, 371 information which might be used to make an authorization decision on 372 the terminating side. However, some additional object in the 373 certificate outside of the TNAuthList could preserve that 374 information; this is a potential area for future work, and longer 375 certification paths are the only mechanism currently defined. 377 All CAs must detail in their practices and policies a requirement to 378 validate that the "encompassing" of a delegate certificate by its 379 parent. Note that this requires that CAs have access to the 380 necessary industry databases to ascertain whether, for example, a 381 particular telephone number is encompassed by an SPC. Alternatively, 382 a CA may acquire an Authority Token (see Section 8.1) that affirms 383 that a delegation is in the proper scope. Exactly what operational 384 practices this entails may vary in different national telephone 385 administrations, and are thus left to the CP/CPS [RFC3647]. 387 8.1. ACME and Delegation 389 STIR deployments commonly use ACME [RFC8555] for certificate 390 acquisition, and it is anticipated that delegate certificates as well 391 will be acquired through an ACME interface. An entity can acquire a 392 certificate from a particular CA by requesting an Authority Token 393 [I-D.ietf-acme-authority-token] from the parent with the desired 394 TNAuthList [I-D.ietf-acme-authority-token-tnauthlist] object. Note 395 that if the client intends to do further subdelegation of its own, it 396 should request a token with the "ca" Authority Token flag set. 398 The entity then presents that Authority Token to a CA to acquire a 399 STIR delegate certificate. ACME returns an "application/pem- 400 certificate-chain" object, and that object would be suitable for 401 publishing as an HTTPS resource for retrieval with the PASSporT "x5u" 402 mechanism as discussed in Section 7. If the CSR presented to the 403 ACME server is for a certificate with the cA boolean set to "true", 404 then the ACME server makes a policy decision to determine whether or 405 not it is appropriate to issue that certificate to the requesting 406 entity. That policy decision will be reflected by the "ca" flag in 407 the Authority Token. 409 Service providers that want the capability to rapidly age out 410 delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] 411 mechanism to automate the process of short-term certificate expiry. 413 8.2. Handling Multiple Certificates 415 In some deployments, non-carrier entities may receive telephone 416 numbers from several different carriers. This could lead to 417 enterprises needing to maintain a sort of STIR keyring, with 418 different certificates delegated to them from different providers, 419 potentially issued by different CAs, which they choose between when 420 signing a call. This could be the case regardless of which syntax is 421 used in the TNAuthList to represent the scope of the delegation (see 422 Section 4.1). As noted in Section 8, if the parent certs use the 423 same CA, it may be possible to shorten the certification path. 425 For non-carrier entities handling a small number of certificates, 426 this is probably not a significant burden. For cases where it 427 becomes burdensome, a few potential approaches exist. A delegate 428 certificate could be cross-certified with another delegate 429 certificate via an Authority Information Access field containing the 430 URL of a Certificate Authority Issuer, so that a signer would only 431 need to sign with a single certificate to inherit the privileges of 432 the other certificate(s) it has cross-certified with. In very 433 complex delegation cases, it might make more sense to establish a 434 bridge CA that cross-certifies with all of the certificates held by 435 the enterprise, rather than requiring a mesh of cross-certification 436 between a large number of certificates. Again, this bridge CA 437 function would likely be performed by some existing CA in the STIR 438 ecosystem. These procedures would however complicated the fairly 439 straightforward certification path reconstruction approach described 440 in Section 7 and would require further specification. 442 9. Alternative Solutions 444 At the time this specification was written, STIR was only starting to 445 see deployment. In some future environment, the policies that govern 446 CAs may not permit them to issue intermediate certificates with a 447 TNAuthList object and a cA boolean set to "true" in the basic 448 constraints certificate extension [RFC5280]. Similar problems in the 449 web PKI space motivated the development of TLS subcerts 450 [I-D.ietf-tls-subcerts], which substitutes a signed "delegated 451 credential" token for a certificate for such environments. A 452 comparable mechanism could be developed for the STIR space, allowing 453 STIR certificates to sign a data object which contains effectively 454 the same data as the delegate certificate specified here, including a 455 public key that could sign PASSporTs. The TLS subcerts system has 456 furthermore exploring leveraging ACME to issue short-lived 457 certificates for temporary delegation as a means of obviating the 458 need for revocation. Specification of a mechanism similar to TLS 459 subcerts for STIR is future work, and will be undertaken only if the 460 market require it. 462 10. IANA Considerations 464 This document contains no actions for the IANA. 466 11. Privacy Considerations 468 Any STIR certificate that identifies a narrow range of telephone 469 numbers potentially exposes information about the entities that are 470 placing calls. As such a telephone number range is necessarily a 471 superset of the calling party number that is openly signaled during 472 call setup, the privacy risks associated with this mechanism are not 473 substantially greater than baseline STIR. See [RFC8224] for guidance 474 on the use of anonymization mechanisms in STIR. 476 12. Security Considerations 478 This document is entirely about security. As delegation can allow 479 signing in scenarios where unauthenticated "legitimate" spoofing 480 would otherwise be used, it is hoped that delegation will improve the 481 overall security of the STIR ecosystem. For further information on 482 certificate security and practices, see [RFC5280], in particular its 483 Security Considerations. Also see the Security Considerations of 484 [RFC8226] for general guidance on the implications of the use of 485 certificates in STIR, and [RFC7375] for the STIR threat model. 487 Much of the security of delegation depends on the implementation of 488 the encompassing semantics described in Section 4. When delegating 489 from an SPC-based TNAuthList to a set of telephone number ranges, 490 understanding the encompassing semantics may require access to 491 industry databases that track the numbering assets of service 492 providers associated with a given SPC. In some operating 493 environments, such databases might not exist. How encompassing is 494 policed is therefore a matter outside the scope of this document, and 495 specific to operational profiles of STIR. 497 The use of by-reference TNAuthLists as described in Section 4 entails 498 that the TNAuthList associated with a certificate can change over 499 time; see the security considerations of [RFC3986] for more on the 500 implications of this property. It is considered a useful feature 501 here due to the potential dynamism of large lists of telephone 502 numbers, but this dynamism entails that a relying party might once 503 accept that a particular telephone number is associated with a 504 certificate, but later reject it for the same certificate as the 505 dynamic list changes. Also that note if the HTTPS service housing 506 the by-reference telephone number list is improperly secured, that 507 too can lead to vulnerabilities. Ultimately, the CA that issued a 508 delegated certificate populates the URL in the AIA field, and is 509 responsible for making a secure selection. Service providers acting 510 as CAs are directed to the cautionary words about running a CA in 511 Section 8 regarding the obligations this entails for certificate 512 revocation and so on. 514 13. Acknowledgments 516 We would like to thank Ines Robles, Richard Barnes, Chris Wendt, Dave 517 Hancock, Russ Housley, Benjamin Kaduk, and Sean Turner for key input 518 on this document. 520 14. References 522 14.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, 526 DOI 10.17487/RFC2119, March 1997, 527 . 529 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 530 Resource Identifier (URI): Generic Syntax", STD 66, 531 RFC 3986, DOI 10.17487/RFC3986, January 2005, 532 . 534 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 535 Housley, R., and W. Polk, "Internet X.509 Public Key 536 Infrastructure Certificate and Certificate Revocation List 537 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 538 . 540 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 541 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 542 May 2017, . 544 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 545 "Authenticated Identity Management in the Session 546 Initiation Protocol (SIP)", RFC 8224, 547 DOI 10.17487/RFC8224, February 2018, 548 . 550 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 551 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 552 . 554 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 555 Credentials: Certificates", RFC 8226, 556 DOI 10.17487/RFC8226, February 2018, 557 . 559 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 560 Kasten, "Automatic Certificate Management Environment 561 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 562 . 564 14.2. Informative References 566 [I-D.ietf-acme-authority-token] 567 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 568 Challenges Using an Authority Token", draft-ietf-acme- 569 authority-token-05 (work in progress), March 2020. 571 [I-D.ietf-acme-authority-token-tnauthlist] 572 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 573 "TNAuthList profile of ACME Authority Token", draft-ietf- 574 acme-authority-token-tnauthlist-06 (work in progress), 575 March 2020. 577 [I-D.ietf-acme-star] 578 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 579 Fossati, "Support for Short-Term, Automatically-Renewed 580 (STAR) Certificates in Automated Certificate Management 581 Environment (ACME)", draft-ietf-acme-star-11 (work in 582 progress), October 2019. 584 [I-D.ietf-tls-subcerts] 585 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 586 "Delegated Credentials for TLS", draft-ietf-tls- 587 subcerts-10 (work in progress), January 2021. 589 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 590 A., Peterson, J., Sparks, R., Handley, M., and E. 591 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 592 DOI 10.17487/RFC3261, June 2002, 593 . 595 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 596 Wu, "Internet X.509 Public Key Infrastructure Certificate 597 Policy and Certification Practices Framework", RFC 3647, 598 DOI 10.17487/RFC3647, November 2003, 599 . 601 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 602 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 603 February 2012, . 605 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 606 Telephone Identity Problem Statement and Requirements", 607 RFC 7340, DOI 10.17487/RFC7340, September 2014, 608 . 610 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 611 RFC 7375, DOI 10.17487/RFC7375, October 2014, 612 . 614 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 615 "Information technology - Open Systems Interconnection - 616 The Directory: Public-key and attribute certificate 617 frameworks", 2012. 619 Author's Address 621 Jon Peterson 622 Neustar, Inc. 624 Email: jon.peterson@team.neustar