idnits 2.17.1 draft-ietf-stir-cert-delegation-02.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 (March 9, 2020) is 1502 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-04 == Outdated reference: A later version (-13) exists of draft-ietf-acme-authority-token-tnauthlist-05 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-06 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 March 9, 2020 5 Expires: September 10, 2020 7 STIR Certificate Delegation 8 draft-ietf-stir-cert-delegation-02 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 September 10, 2020. 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 Certificate Chains in STIR . . . . . . . . . . . . 7 64 8. Certification Authorities and Service Providers . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 10 74 14.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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 to have its CA boolean set to "true", indicating 162 that that it can sign certificates. Every STIR delegate certificate 163 identifies its parent certificate with a standard [RFC5280] Authority 164 Key Identifier. 166 The authority bestowed on the holder of the delegate certificate by 167 the parent certificate is recorded in the delegate certificate's 168 TNAuthList. Because STIR certificates use the TNAuthList object 169 rather than the Subject Name for indicating the scope of their 170 authority, traditional [RFC5280] name constraints are not directly 171 applicable to STIR. In a manner similar to the RPKI [RFC6480] 172 "encompassing" semantics, each delegate certificate must have a 173 TNAuthList scope that is equal to or a subset of its parent 174 certificate's scope: it must be "encompassed." For example, a parent 175 certificate with a TNAuthList that attested authority for the 176 numbering range +1-212-555-1000 through 1999 could issue a 177 certificate to one delegate attesting authority for the range 178 +1-212-555-1500 through 1599, and to another delegate a certificate 179 for the individual number +1-212-555-1824. 181 Delegate certificates may themselves be issued with the CA boolean 182 set to "true" so that they can serve as parent certificates to 183 further delegates; effectively, this delegate certificate is a cross- 184 certificate, as its issuer is not the same as its subject. In the 185 STIR 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. [RFC8226] Section 10.1 describes one 205 potential way to address this, including the TNAuthList in the 206 certificate by-reference rather than by value, where a URL in the 207 certificate points to a secure, dynamically-updated list of the 208 telephone numbers in the scope of authority of a certificate. For 209 entities that are carriers in all but name, another alternative is 210 the allocation of an SPC; this yields much the same property, as the 211 SPC is effectively a pointer to an external database which 212 dynamically tracks the numbers associated with the SPC. Either of 213 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 surely 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 baseline 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 in turn has its own parent, the entire certificate path 264 should be 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 certificate chain, 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 AKID object. 289 While ordinarily, relying parties have significant latitude in path 290 construction when validating a certificate chain, STIR assumes a more 291 rigid hierarchical subordination model, rather than one where relying 292 parties may want to derive their own chains to particular trust 293 anchors. If the certificate chain acquired from the "x5u" element of 294 a PASSporT does not lead to an anchor that the verification service 295 trusts, it treats the validation no differently than it would when a 296 non-delegated certificate was issued by an untrusted root; in SIP, it 297 MAY return a 437 "Unsupported Credential" response if the call should 298 be failed for lack of a valid Identity header. 300 7. Acquiring Certificate Chains in STIR 302 PASSporT [RFC8225] uses the "x5u" element to convey the URL where 303 verification services can acquire the certificate used to sign a 304 PASSporT. This value is mirrored by the "info" parameter of the 305 Identity header when a PASSporT is conveyed via SIP. Commonly, this 306 is an HTTPS URI. 308 When a STIR delegate certificate is used to sign a PASSporT, the 309 "x5u" element in the PASSporT will contain a URI indicating where a 310 certificate list is available. While baseline JWS also supports an 311 "x5c" element specifically for certificate chains, in operational 312 practice, chains are already being delivered in the STIR environment 313 via the "x5u" element, so this specification recommends continuing to 314 use "x5u". That list will be a concatenation of PEM encoded 315 certificates of the type "application/pem-certificate-chain" defined 316 in [RFC8555]. The list begins with the certificate used to sign the 317 PASSporT, followed by its parent, and then any subsequent 318 grandparents, great-grandparents, and so on. The ordering MUST 319 conform to the AKID/SKID order chain encoded in the certs themselves. 320 Note that ACME requires the first element in a pem-certificate-chain 321 to be an end-entity certificate; STIR relaxes this requirement, as CA 322 certificates are permitted to sign PASSporTs, so the first element in 323 a pem-certificate-chain used for STIR MAY be a CA certificate. 325 8. Certification Authorities and Service Providers 327 Once a telephone service provider has received a CA certificate 328 attesting their numbering resources, they may delegate from it as 329 they see fit. Note that the allocation to a service provider of a 330 certificate with the CA boolean set to "true" does not require that a 331 service provider act as a certification authority itself; serving as 332 a certification authority is a function requiring specialized 333 expertise and infrastructure. A third-party certification authority, 334 including the same one that issued the service provider its parent 335 certificate, could act as the CA that issues delegate certificates 336 for the service provider, if the necessary business relationships 337 permit it. A service provider might in this case act as a Token 338 Authority (see Section 8.1) granting its customers permissions to 339 receive certificates from the CA. 341 Note that if the same CA that issued the parent certificate is also 342 issuing a delegate certificate, it may be possible to shorten the 343 certificate chain, which reduces the work required of verification 344 services. The trade-off here is that if the CA simply issued a non- 345 delegate certificate (whose parent is the CA's root certificate) with 346 the proper TNAuthList value, relying parties might not be able to 347 ascertain which service provider owned those telephone numbers, 348 information which might be used to make an authorization decision on 349 the terminating side. However, some additional object in the 350 certificate outside of the TNAuthList could preserve that 351 information; this is a potential area for future work. 353 All CAs must detail in their practices and policies a requirement to 354 validate that the "encompassing" of a delegate certificate by its 355 parent. Note that this requires that CAs have access to the 356 necessary industry databases to ascertain whether, for example, a 357 particular telephone number is encompassed by an SPC. Alternatively, 358 a CA may acquire an Authority Token that affirms that a delegation is 359 in the proper scope. Exactly what operational practices this entails 360 may vary in different national telephone administrations, and are 361 thus left to the CP/CPS. 363 8.1. ACME and Delegation 365 STIR deployments commonly use ACME [RFC8555] for certificate 366 acquisition, and it is anticipated that delegate certificates as well 367 will be acquired through an ACME interface. An entity can acquire a 368 certificate from a particular CA by requesting an Authority Token 369 [I-D.ietf-acme-authority-token] from the parent with the desired 370 TNAuthList [I-D.ietf-acme-authority-token-tnauthlist] object. Note 371 that if the client intends to do further subdelegation of its own, it 372 should request a token with the "ca" Authority Token flag set. 374 The entity then presents that Authority Token to a CA to acquire a 375 STIR delegate certificate. ACME returns an "application/pem- 376 certificate-chain" object with suitable for publishing as an HTTPS 377 resource for retrieval with the PASSporT "x5u" mechanism as discussed 378 in Section 7. If the CSR presented to the ACME server is for a 379 certificate with the CA boolean set to "true", then the ACME server 380 makes a policy decision to determine whether or not it is appropriate 381 to issue that certificate to the requesting entity. That policy 382 decision will be reflected by the "ca" flag in the Authority Token. 384 Service providers that want the capability to rapidly revoke 385 delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] 386 mechanism to automate the process of short-term certificate expiry. 388 8.2. Handling Multiple Certificates 390 In some deployments, non-carrier entities may receive telephone 391 numbers from several different carriers. This could lead to 392 enterprises needing to maintain a sort of STIR keyring, with 393 different certificates delegated to them from different providers, 394 potentially issued by different CAs, which they choose between when 395 signing a call. This could be the case regardless of which syntax is 396 used in the TNAuthList to represent the scope of the delegation (see 397 Section 4.1). 399 For a small number of certificates, this is probably not a 400 significant burden. For cases where it becomes burdensome, a few 401 potential approaches exist. A delegate certificate could be cross- 402 certified with another delegate certificate via an Authority 403 Information Access field containing the URL of a Certificate 404 Authority Issuer, so that a signer would only need to sign with a 405 single certificate to inherit the privileges of the other 406 certificate(s) it has cross-certified with. In very complex 407 delegation cases, it might make more sense to establish a bridge CA 408 that cross-certifies with all of the certificates held by the 409 enterprise, rather than requiring a mesh of cross-certification 410 between a large number of certificates. Again, this bridge CA 411 function would likely be performed by some existing CA in the STIR 412 ecosystem. 414 9. Alternative Solutions 416 At the time this specification was written, STIR was only starting to 417 see deployment. In some future environments, the policies that 418 govern CAs may not permit them to issue intermediate certificates 419 with a TNAuthList object and a "ca" boolean set to "true". Similar 420 problems in the web PKI space motivated the development of TLS 421 subcerts [I-D.ietf-tls-subcerts], which substitutes a signed 422 "delegated credential" token for a certificate for such environments. 423 A comparable mechanism could be developed for the STIR space, 424 allowing STIR certificates to sign a data object which contains 425 effectively the same data as the delegate certificate specified here, 426 including a public key that could sign PASSporTs. The TLS subcerts 427 system has furthermore developed ways for the issuer of a delegated 428 credential to revoke it, as well as exploring the potential 429 interaction with ACME to issue short-lived certificates for temporary 430 delegation. Specification of a TLS subcerts analog for STIR is 431 deferred here to future work, at such a time as market players 432 require it. 434 10. IANA Considerations 436 This document contains no actions for the IANA. 438 11. Privacy Considerations 440 Any STIR certificate that identifies a narrow range of telephone 441 numbers potentially exposes information about the entities that are 442 placing calls. As this information is necessarily a superset of the 443 calling party number that is openly signaled during call setup, the 444 privacy risks associated with this mechanism are not substantially 445 greater than baseline STIR. See [RFC8224] for guidance on the use of 446 anonymization mechanisms in STIR. 448 12. Security Considerations 450 This document is entirely about security. For further information on 451 certificate security and practices, see [RFC5280], in particular its 452 Security Considerations. Also see the Security Considerations of 453 [RFC8226] for general guidance on the implications of the use of 454 certificates in STIR. 456 13. Acknowledgments 458 We would like to thank Richard Barnes, Chris Wendt, Dave Hancock, 459 Russ Housley, and Sean Turner for key input to the discussions 460 leading to this document. 462 14. References 464 14.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, 468 DOI 10.17487/RFC2119, March 1997, 469 . 471 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 472 A., Peterson, J., Sparks, R., Handley, M., and E. 473 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 474 DOI 10.17487/RFC3261, June 2002, 475 . 477 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 478 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 479 May 2017, . 481 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 482 "Authenticated Identity Management in the Session 483 Initiation Protocol (SIP)", RFC 8224, 484 DOI 10.17487/RFC8224, February 2018, 485 . 487 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 488 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 489 . 491 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 492 Credentials: Certificates", RFC 8226, 493 DOI 10.17487/RFC8226, February 2018, 494 . 496 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 497 Kasten, "Automatic Certificate Management Environment 498 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 499 . 501 14.2. Informative References 503 [I-D.ietf-acme-authority-token] 504 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 505 Challenges Using an Authority Token", draft-ietf-acme- 506 authority-token-04 (work in progress), November 2019. 508 [I-D.ietf-acme-authority-token-tnauthlist] 509 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 510 "TNAuthList profile of ACME Authority Token", draft-ietf- 511 acme-authority-token-tnauthlist-05 (work in progress), 512 November 2019. 514 [I-D.ietf-acme-star] 515 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 516 Fossati, "Support for Short-Term, Automatically-Renewed 517 (STAR) Certificates in Automated Certificate Management 518 Environment (ACME)", draft-ietf-acme-star-11 (work in 519 progress), October 2019. 521 [I-D.ietf-tls-subcerts] 522 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 523 "Delegated Credentials for TLS", draft-ietf-tls- 524 subcerts-06 (work in progress), February 2020. 526 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 527 Housley, R., and W. Polk, "Internet X.509 Public Key 528 Infrastructure Certificate and Certificate Revocation List 529 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 530 . 532 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 533 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 534 February 2012, . 536 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 537 Telephone Identity Problem Statement and Requirements", 538 RFC 7340, DOI 10.17487/RFC7340, September 2014, 539 . 541 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 542 "Information technology - Open Systems Interconnection - 543 The Directory: Public-key and attribute certificate 544 frameworks", 2012. 546 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 547 "Information technology - Open Systems Interconnection - 548 The Directory: Selected Attribute Types", 2012. 550 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 551 "Information Technology - Abstract Syntax Notation One: 552 Specification of basic notation". 554 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 555 "Information Technology - Abstract Syntax Notation One: 556 Information Object Specification". 558 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 559 "Information Technology - Abstract Syntax Notation One: 560 Constraint Specification". 562 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 563 "Information Technology - Abstract Syntax Notation One: 564 Parameterization of ASN.1 Specifications". 566 Author's Address 568 Jon Peterson 569 Neustar, Inc. 571 Email: jon.peterson@team.neustar