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