idnits 2.17.1 draft-ietf-stir-cert-delegation-03.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 (July 13, 2020) is 1381 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-09 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 July 13, 2020 5 Expires: January 14, 2021 7 STIR Certificate Delegation 8 draft-ietf-stir-cert-delegation-03 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 January 14, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acquiring Multiple Certificates in STIR . . . . . . . . . . . 7 64 8. Certification Authorities and Service Providers . . . . . . . 8 65 8.1. ACME and Delegation . . . . . . . . . . . . . . . . . . . 8 66 8.2. Handling Multiple Certificates . . . . . . . . . . . . . 9 67 9. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 9 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 14.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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. One 82 of the most important components of a system to prevent impersonation 83 is the implementation of credentials which identify the parties who 84 control telephone numbers. The STIR certificates [RFC8226] 85 specification describes a credential system based on [X.509] version 86 3 certificates in accordance with [RFC5280] for that purpose. Those 87 credentials can then be used by STIR authentication services 88 [RFC8224] to sign PASSporT objects [RFC8225] carried in SIP [RFC3261] 89 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 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 3. Motivation 126 The most pressing need for delegation in STIR arises in a set of use 127 cases where callers want to use a particular calling number, but for 128 whatever reason, their outbound calls will not pass through the 129 authentication service of the service provider that controls that 130 numbering resource. 132 One example would be an enterprise that places outbound calls through 133 a set of service providers, for each call choosing a provider based 134 on a least-cost routing algorithm or similar local policy. The 135 enterprise was assigned a calling number by a particular service 136 provider, but some calls originating from that number will go out 137 through other service providers. 139 A user might also roam from their usual service provider to a 140 different network or administrative domain, for various reasons. 141 Most "legitimate spoofing" examples are of this form: where a user 142 wants to be able to use the main call-back number for their business 143 as a calling party number, even when the user is away from the 144 business. 146 These sorts of use cases could be addressed if the carrier who 147 controls the numbering resource were able to delegate a credential 148 that could be used to sign calls regardless of which network or 149 administrative domain handles the outbound routing for the call. In 150 the absence of something like a delegation mechanism, outbound 151 carriers may be forced to sign calls with credentials that do not 152 cover the originating number in question. Unfortunately, that 153 practice would be difficult to distinguish from malicious spoofing, 154 and if it becomes widespread, it could erode trust in STIR overall. 156 4. Delegation of STIR Certificates 158 STIR delegate certificates are certificates containing a TNAuthList 159 object that have been signed with the private key of a parent 160 certificate that itself contains a TNAuthList object. The parent 161 certificate needs contain a basic constraints extension with the cA 162 boolean set to "true", indicating that the subject can sign 163 certificates. Every STIR delegate certificate identifies its parent 164 certificate with a standard [RFC5280] Authority Key Identifier 165 extension. 167 The authority bestowed on the holder of the delegate certificate by 168 the parent certificate is recorded in the delegate certificate's 169 TNAuthList. Because STIR certificates use the TNAuthList object 170 rather than the Subject Name for indicating the scope of their 171 authority, traditional [RFC5280] name constraints are not directly 172 applicable to STIR. In a manner similar to the RPKI [RFC6480] 173 "encompassing" semantics, each delegate certificate must have a 174 TNAuthList scope that is equal to or a subset of its parent 175 certificate's scope: it must be "encompassed." For example, a parent 176 certificate with a TNAuthList that attested authority for the 177 numbering range +1-212-555-1000 through 1999 could issue a 178 certificate to one delegate attesting authority for the range 179 +1-212-555-1500 through 1599, and to another delegate a certificate 180 for the individual number +1-212-555-1824. 182 Delegate certificates may also contain a basic constraints extension 183 with the cA boolean set to "true", indicating that they can sign 184 subordinate certificates for further delegates. In the STIR 185 ecosystem, CA certificates may be used to sign PASSporTs; this 186 removes the need for creating a redundant end-entity certificate with 187 an identical TNAuthList to its parent, though if for operational or 188 security reasons certificate holders wish to do so, they may. 190 4.1. Scope of Delegation 192 STIR certificates may have a TNAuthList containing one or more SPCs, 193 one or more telephone number ranges, or both. When delegating from a 194 STIR certificate, a child certificate may inherit from its parent 195 either of the above. Depending on the sort of numbering resources 196 that a delegate has been assigned, various syntaxes can be used to 197 capture the delegated resource. 199 Some non-carrier entities may be assigned large and complex 200 allocations of telephone numbers, which may be only partially 201 contiguous or entirely disparate. Allocations may also change 202 frequently, in minor or significant ways. These resources may be so 203 complex, dynamic, or extensive that listing them in a certificate is 204 prohibitively difficult. Section 10.1 of [RFC8226] describes one 205 potential way to address this, including the TNAuthList (specified in 206 [RFC8226]) in the certificate by-reference rather than by value, 207 where a URL in the certificate points to a secure, dynamically- 208 updated list of the telephone numbers in the scope of authority of a 209 certificate. For entities that are carriers in all but name, another 210 alternative is the allocation of an SPC; this yields much the same 211 property, as the SPC is effectively a pointer to an external database 212 which dynamically tracks the numbers associated with the SPC. Either 213 of these approaches may make sense for a given deployment. 215 Other non-carrier entities may have straightforward telephone number 216 assignments, such as enterprises receiving a set of thousand blocks 217 from a carrier that may be kept for years or decades. Particular 218 freephone numbers may also have a long-term association with an 219 enterprise and its brand. For these sorts of assignments, assigning 220 an SPC may seem like overkill, and using the TN ranges of the 221 TNAuthList (by-value) is sufficient. 223 Whichever approach is taken to representing the delegated resource, 224 there are fundamental trade-offs regarding when and where in the 225 architecture a delegation is validated: that is, when the delegated 226 TNAuthList is checked to be "encompassed" by the TNAuthList of its 227 parent. This might be performed at the time the delegate certificate 228 is issued, or at the time that a verification service receives an 229 inbound call, or potentially both. It is generally desirable to 230 offload as much of this as possible to the certification process, as 231 verification occurs during call setup and thus additional network 232 dips could lead to perceptible delay, whereas certification happens 233 outside of call processing as a largely administrative function. 234 Ideally, if a delegate certificate can supply a by-value TN range, 235 then a verification service could ascertain that an attested calling 236 party number is within the scope of the provided certificate without 237 requiring any additional network dip. In practice, verification 238 services may already incorporate network queries into their 239 processing (for example, to deference the "x5u" field of a PASSporT) 240 that could piggyback any additional information needed by the 241 verification service. 243 Note that the permission semantics of the [RFC8226] TNAuthList are 244 additive: that is, the scope of a certificate is the superset of all 245 of the SPCs and telephone number ranges enumerated in the TNAuthList. 246 As SPCs themselves are effectively pointers to a set of telephone 247 number ranges, and a telephone number may belong to more than one 248 SPC, this may introduce some redundancy to the set of telephone 249 numbers specified as the scope of a certificate. The presence of one 250 or more SPCs and one or more sets of telephone number ranges should 251 similarly be treated additively, even if the telephone number ranges 252 turn out to be redundant to the scope of an SPC. 254 5. Authentication Services Signing with Delegate Certificates 256 Authentication service behavior for delegate certificates is little 257 changed from [RFC8224] STIR behavior. The same checks are performed 258 by the authentication service, comparing the calling party number 259 attested in call signaling with the scope of the authority of the 260 signing certificate. Authentication services SHOULD NOT use a 261 delegate certificate without validating that its scope of authority 262 is encompassed by that of its parent certificate, and if that 263 certificate has a own parent, the entire certification path SHOULD be 264 validated. 266 This delegation architecture does not require that a non-carrier 267 entity act as its own authentication service. That function may be 268 performed by any authentication service that holds the private key 269 corresponding to the delegate certificate, including one run by an 270 outbound service provider, a third party in an enterprise's outbound 271 call path, or in the SIP User Agent itself. 273 Note that authentication services creating a PASSporT for a call 274 signed with a delegate certificate MUST provide an "x5u" link 275 corresponding to the entire certification path, rather than just the 276 delegate certificate used to sign the call, as described in 277 Section 7. 279 6. Verification Service Behavior for Delegate Certificate Signatures 281 The responsibility of a verification service validating PASSporTs 282 signed with delegate certificates, while largely following baseline 283 [RFC8224] and [RFC8225], requires some additional procedures. When 284 the verification service dereferences the "x5u" parameter, it will 285 acquire a certificate list rather than a single certificate. It MUST 286 then validate all of the credentials in the list, identifying the 287 parent certificate for each delegate through its Authority Key 288 Identifier extension. 290 While ordinarily, relying parties have significant latitude in 291 certification path construction when validating a certification path, 292 STIR assumes a more rigid hierarchical subordination model, rather 293 than one where relying parties may want to derive their own 294 certification path to particular trust anchors. If the certificates 295 acquired from the "x5u" element of a PASSporT do not lead to an 296 anchor that the verification service trusts, it treats the validation 297 no differently than it would when a non-delegated certificate was 298 issued by an untrusted root; in SIP, it MAY return a 437 "Unsupported 299 Credential" response if the call should be failed for lack of a valid 300 Identity header. 302 7. Acquiring Multiple Certificates in STIR 304 PASSporT [RFC8225] uses the "x5u" element to convey the URL where 305 verification services can acquire the certificate used to sign a 306 PASSporT. This value is mirrored by the "info" parameter of the 307 Identity header when a PASSporT is conveyed via SIP. Commonly, this 308 is an HTTPS URI. 310 When a STIR delegate certificate is used to sign a PASSporT, the 311 "x5u" element in the PASSporT will contain a URI indicating where a 312 certificate list is available. While baseline JWS also supports an 313 "x5c" element specifically for certificate chains, in operational 314 practice, certification path are already being delivered in the STIR 315 environment via the "x5u" element, so this specification recommends 316 continuing to use "x5u". That list will be a concatenation of PEM- 317 encoded certificates of the type "application/pem-certificate-chain" 318 defined in [RFC8555]. The certificate path [RFC5280] ordering MUST 319 be organized from the trust anchor towards the signer. The list 320 begins with the certificate used to sign the PASSporT, followed by 321 its parent, and then any subsequent grandparents, great-grandparents, 322 and so on. The key identifier in the Authority Key Identifier 323 extension in the first certificate MUST appear in the Subject Key 324 Identifier extension in the second certificate. The key identifier 325 pairing MUST match in this way throughout the entire chain of 326 certificates. Note that ACME [RFC8555] requires the first element in 327 a pem-certificate-chain to be an end-entity certificate; however, 328 STIR relaxes this requirement, because CA certificates are permitted 329 to sign PASSporTs, so for STIR, the first element in a pem- 330 certificate-chain used for STIR MAY be a CA certificate. 332 8. Certification Authorities and Service Providers 334 Once a telephone service provider has received a CA certificate 335 attesting their numbering resources, they may delegate resources from 336 it as they see fit. Note that the allocation to a service provider 337 of a certificate with a basic constraints extension with the cA 338 boolean set to "true" does not require that a service provider act as 339 a certification authority itself; serving as a certification 340 authority is a function requiring specialized expertise and 341 infrastructure. A third-party certification authority, including the 342 same one that issued the service provider its parent certificate, 343 could act as the CA that issues delegate certificates for the service 344 provider, if the necessary business relationships permit it. A 345 service provider might in this case act as a Token Authority (see 346 Section 8.1) granting its customers permissions to receive 347 certificates from the CA. 349 Note that if the same CA that issued the parent certificate is also 350 issuing a delegate certificate, it may be possible to shorten the 351 certification path, which reduces the work required of verification 352 services. The trade-off here is that if the CA simply issued a non- 353 delegate certificate (whose parent is the CA's trust anchor) with the 354 proper TNAuthList value, relying parties might not be able to 355 ascertain which service provider owned those telephone numbers, 356 information which might be used to make an authorization decision on 357 the terminating side. However, some additional object in the 358 certificate outside of the TNAuthList could preserve that 359 information; this is a potential area for future work. 361 All CAs must detail in their practices and policies a requirement to 362 validate that the "encompassing" of a delegate certificate by its 363 parent. Note that this requires that CAs have access to the 364 necessary industry databases to ascertain whether, for example, a 365 particular telephone number is encompassed by an SPC. Alternatively, 366 a CA may acquire an Authority Token that affirms that a delegation is 367 in the proper scope. Exactly what operational practices this entails 368 may vary in different national telephone administrations, and are 369 thus left to the CP/CPS [RFC3647]. 371 8.1. ACME and Delegation 373 STIR deployments commonly use ACME [RFC8555] for certificate 374 acquisition, and it is anticipated that delegate certificates as well 375 will be acquired through an ACME interface. An entity can acquire a 376 certificate from a particular CA by requesting an Authority Token 377 [I-D.ietf-acme-authority-token] from the parent with the desired 378 TNAuthList [I-D.ietf-acme-authority-token-tnauthlist] object. Note 379 that if the client intends to do further subdelegation of its own, it 380 should request a token with the "ca" Authority Token flag set. 382 The entity then presents that Authority Token to a CA to acquire a 383 STIR delegate certificate. ACME returns an "application/pem- 384 certificate-chain" object with suitable for publishing as an HTTPS 385 resource for retrieval with the PASSporT "x5u" mechanism as discussed 386 in Section 7. If the CSR presented to the ACME server is for a 387 certificate with the cA boolean set to "true", then the ACME server 388 makes a policy decision to determine whether or not it is appropriate 389 to issue that certificate to the requesting entity. That policy 390 decision will be reflected by the "ca" flag in the Authority Token. 392 Service providers that want the capability to rapidly revoke 393 delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] 394 mechanism to automate the process of short-term certificate expiry. 396 8.2. Handling Multiple Certificates 398 In some deployments, non-carrier entities may receive telephone 399 numbers from several different carriers. This could lead to 400 enterprises needing to maintain a sort of STIR keyring, with 401 different certificates delegated to them from different providers, 402 potentially issued by different CAs, which they choose between when 403 signing a call. This could be the case regardless of which syntax is 404 used in the TNAuthList to represent the scope of the delegation (see 405 Section 4.1). 407 For a small number of certificates, this is probably not a 408 significant burden. For cases where it becomes burdensome, a few 409 potential approaches exist. A delegate certificate could be cross- 410 certified with another delegate certificate via an Authority 411 Information Access field containing the URL of a Certificate 412 Authority Issuer, so that a signer would only need to sign with a 413 single certificate to inherit the privileges of the other 414 certificate(s) it has cross-certified with. In very complex 415 delegation cases, it might make more sense to establish a bridge CA 416 that cross-certifies with all of the certificates held by the 417 enterprise, rather than requiring a mesh of cross-certification 418 between a large number of certificates. Again, this bridge CA 419 function would likely be performed by some existing CA in the STIR 420 ecosystem. 422 9. Alternative Solutions 424 At the time this specification was written, STIR was only starting to 425 see deployment. In some future environments, the policies that 426 govern CAs may not permit them to issue intermediate certificates 427 with a TNAuthList object and a cA boolean set to "true" in the basic 428 constraints certificate extension [RFC5280]. Similar problems in the 429 web PKI space motivated the development of TLS subcerts 430 [I-D.ietf-tls-subcerts], which substitutes a signed "delegated 431 credential" token for a certificate for such environments. A 432 comparable mechanism could be developed for the STIR space, allowing 433 STIR certificates to sign a data object which contains effectively 434 the same data as the delegate certificate specified here, including a 435 public key that could sign PASSporTs. The TLS subcerts system has 436 furthermore developed ways for the issuer of a delegated credential 437 to revoke it, as well as exploring the potential interaction with 438 ACME to issue short-lived certificates for temporary delegation. 439 Specification of a mechanism similar to TLS subcerts for STIR is 440 future work, and will be undertaken only if the market require it. 442 10. IANA Considerations 444 This document contains no actions for the IANA. 446 11. Privacy Considerations 448 Any STIR certificate that identifies a narrow range of telephone 449 numbers potentially exposes information about the entities that are 450 placing calls. As this information is necessarily a superset of the 451 calling party number that is openly signaled during call setup, the 452 privacy risks associated with this mechanism are not substantially 453 greater than baseline STIR. See [RFC8224] for guidance on the use of 454 anonymization mechanisms in STIR. 456 12. Security Considerations 458 This document is entirely about security. For further information on 459 certificate security and practices, see [RFC5280], in particular its 460 Security Considerations. Also see the Security Considerations of 461 [RFC8226] for general guidance on the implications of the use of 462 certificates in STIR. 464 13. Acknowledgments 466 We would like to thank Richard Barnes, Chris Wendt, Dave Hancock, 467 Russ Housley, and Sean Turner for key input to the discussions 468 leading to this document. 470 14. References 471 14.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 479 A., Peterson, J., Sparks, R., Handley, M., and E. 480 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 481 DOI 10.17487/RFC3261, June 2002, 482 . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 485 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 486 May 2017, . 488 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 489 "Authenticated Identity Management in the Session 490 Initiation Protocol (SIP)", RFC 8224, 491 DOI 10.17487/RFC8224, February 2018, 492 . 494 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 495 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 496 . 498 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 499 Credentials: Certificates", RFC 8226, 500 DOI 10.17487/RFC8226, February 2018, 501 . 503 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 504 Kasten, "Automatic Certificate Management Environment 505 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 506 . 508 14.2. Informative References 510 [I-D.ietf-acme-authority-token] 511 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 512 Challenges Using an Authority Token", draft-ietf-acme- 513 authority-token-05 (work in progress), March 2020. 515 [I-D.ietf-acme-authority-token-tnauthlist] 516 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 517 "TNAuthList profile of ACME Authority Token", draft-ietf- 518 acme-authority-token-tnauthlist-06 (work in progress), 519 March 2020. 521 [I-D.ietf-acme-star] 522 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 523 Fossati, "Support for Short-Term, Automatically-Renewed 524 (STAR) Certificates in Automated Certificate Management 525 Environment (ACME)", draft-ietf-acme-star-11 (work in 526 progress), October 2019. 528 [I-D.ietf-tls-subcerts] 529 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 530 "Delegated Credentials for TLS", draft-ietf-tls- 531 subcerts-09 (work in progress), June 2020. 533 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 534 Wu, "Internet X.509 Public Key Infrastructure Certificate 535 Policy and Certification Practices Framework", RFC 3647, 536 DOI 10.17487/RFC3647, November 2003, 537 . 539 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 540 Housley, R., and W. Polk, "Internet X.509 Public Key 541 Infrastructure Certificate and Certificate Revocation List 542 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 543 . 545 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 546 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 547 February 2012, . 549 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 550 Telephone Identity Problem Statement and Requirements", 551 RFC 7340, DOI 10.17487/RFC7340, September 2014, 552 . 554 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 555 "Information technology - Open Systems Interconnection - 556 The Directory: Public-key and attribute certificate 557 frameworks", 2012. 559 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 560 "Information technology - Open Systems Interconnection - 561 The Directory: Selected Attribute Types", 2012. 563 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 564 "Information Technology - Abstract Syntax Notation One: 565 Specification of basic notation". 567 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 568 "Information Technology - Abstract Syntax Notation One: 569 Information Object Specification". 571 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 572 "Information Technology - Abstract Syntax Notation One: 573 Constraint Specification". 575 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 576 "Information Technology - Abstract Syntax Notation One: 577 Parameterization of ASN.1 Specifications". 579 Author's Address 581 Jon Peterson 582 Neustar, Inc. 584 Email: jon.peterson@team.neustar