idnits 2.17.00 (12 Aug 2021) /tmp/idnits26693/draft-peterson-stir-certificates-shortlived-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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (21 April 2022) is 23 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) == Missing Reference: 'More TBD' is mentioned on line 259, but not defined == Unused Reference: 'ATIS-0300251' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC2392' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC5019' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC5912' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC5958' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC6818' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC7093' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC3647' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC5055' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC6961' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC7375' is defined on line 474, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ATIS-0300251' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 7093 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 23 warnings (==), 4 comments (--). 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 21 April 2022 5 Expires: 23 October 2022 7 Short-Lived Certificates for Secure Telephone Identity 8 draft-peterson-stir-certificates-shortlived-03 10 Abstract 12 When certificates are used as credentials to attest the assignment of 13 ownership of telephone numbers, some mechanism is required to provide 14 certificate freshness. This document specifies short-lived 15 certificates as a means of guaranteeing certificate freshness for 16 secure telephone identity (STIR), in particular relying on the 17 Automated Certificate Management Environment (ACME) to allow signers 18 to acquire certifcates as needed. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 23 October 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Short-lived certificates for STIR . . . . . . . . . . . . . . 3 56 4. Certificate Acquisition with ACME . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 9.2. Informative References . . . . . . . . . . . . . . . . . 10 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 The STIR problem statement [RFC7340] discusses many attacks on the 69 telephone network that are enabled by impersonation, including 70 various forms of robocalling, voicemail hacking, and swatting. One 71 of the most important components of a system to prevent impersonation 72 is the implementation of credentials which identify the parties who 73 control telephone numbers. The STIR certificates [RFC8226] 74 specification describes a credential system based on [X.509] version 75 3 certificates in accordance with [RFC5280] for that purpose. Those 76 credentials can then be used by STIR authentication services 77 [RFC8224] to sign PASSporT objects [RFC8225] carried in a SIP 78 [RFC3261] request. 80 The STIR certificates document specifies an extension to X.509 that 81 defines a Telephony Number (TN) Authorization List that may be 82 included by certificate authorities in certificates. This extension 83 provides additional information that relying parties can use when 84 validating transactions with the certificate: either in the form of 85 Service Provider Codes (SPCs) or telephone numbers. Telephone 86 numbers or number ranges are commonly used in delegate STIR 87 certificates [RFC9060]. When a SIP request, for example, arrives at 88 a terminating administrative domain, the calling number attested by 89 the SIP request can be compared to the TN Authorization List of the 90 delegate certificate that signed the request to determine if the 91 caller is authorized to use that calling number in SIP. 93 No specific recommendation is made in the STIR certificates document 94 for a means of determining the freshness of certificates with a TN 95 Authorization List. This document explores how short-lived 96 certificates could be used as a means of preserving that freshness. 97 Short-lived certificates also have a number of other desirable 98 properties that fulfill important operational requirements for 99 network operators. The use of the Automated Certificate Management 100 Environment (ACME) [RFC8555] to manage these short-lived certificates 101 is the focus of the architecture specified, in particular adapting 102 the Short-Term Automatically Renewed (STAR) [RFC8739] mechanism to 103 STIR. The interaction of STIR with ACME has already been explored in 104 [I-D.ietf-acme-authority-token-tnauthlist]. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Short-lived certificates for STIR 116 While there is no easy definition of what constitutes a "short-lived" 117 certificate, the term typically refers to certificates that are valid 118 only for days or even hours, as opposed to the months or years common 119 in traditional public key infrastructures. When the private keying 120 material associated with that has an expiry of months or years is 121 compromised by an adversary, the issuing authority must revoke the 122 certificate, which requires relying parties to review certificate 123 revocation lists or to access real-time status information with 124 protocols such as OCSP. Short-lived certificates offer an 125 alternative where, if compromised, certificates will shortly expire 126 anyway, and rather than revoking and reissuing the certificate in 127 response to a crisis, certificates routinely roll-over and cannot be 128 cached for a long term by relying parties, minimizing their value to 129 attackers. 131 One of the additional benefits of using short-lived certificates is 132 that they do not require relying parties to perform any certificate 133 freshness check. The trade-off is that the signer must acquire new 134 certificates frequently, so the cost of round-trip times to the 135 certificate authority is paid on the signer's side rather than the 136 verifier's side; however, in environments where many parties may rely 137 on a single certificate, or at least where a single certificate will 138 be used to sign many transactions during its short lifetime, the 139 overall architecture will incur fewer round-trip times to the 140 certificate authority and thus less processing delay. 142 In the STIR context, the TN Authorization List defined in [RFC8226] 143 adds a new wrinkle to the behavior of short-lived certificates, 144 especially when it is populated with telephone numbers or number 145 ranges instead of Service Provider Codes (SPCs). A subject may have 146 authority over multiple telephone numbers, but a particular 147 certificate issued to that subject could attest the authority over 148 all, some, or just one of those telephone numbers. Short-lived 149 certificates permit a more on-demand certification process, where 150 subjects acquire certificates as needed, potentially in reaction to 151 calls being placed. A STIR authentication service could even acquire 152 a new certificate on a per-call basis that can only sign for the 153 calling party number of the call in question. At the other end of 154 the spectrum, a large enterprise service provider could acquire a 155 certificate valid for millions of numbers, but expire the certificate 156 after a very short duration - on the order of hours - to reduce the 157 risk that the certificate would be compromised. 159 This inherent flexibility in the short-lived certificate architecture 160 would also permit authentication services to implement very narrow 161 policies for certificate usage. A large service provider who wanted 162 to avoid revealing which phone numbers they controlled, for example, 163 could provide no information in the certificate that signs a call 164 other than just the single telephone number that corresponds to the 165 calling party's number. How frequently the service provider feels 166 that they need to expire that certificate and acquire a new one is 167 entirely a matter of policy to them. This makes it much harder for 168 entities monitoring signatures over calls to guess who owns which 169 numbers, and provides a much more complicated threat surface for 170 attackers trying to compromise the service. 172 In order to reduce the burden on verification services, an 173 authentication service could also piggyback a short-lived certificate 174 onto the signed SIP request, so that no network lookup and consequent 175 round-trip delay would be required on the terminating side to acquire 176 the new certificate. [RFC8224] already provides a way of pointing to 177 a certificate in a MIME body associated with the SIP request. Future 178 work could specify other means of carrying certificates within SIP 179 requests via a header rather than a body, to optimize for 180 intermediaries adding and extracting these certificates. 182 4. Certificate Acquisition with ACME 184 One of the primary challenges facing short-lived certificates is 185 building an operational system that allows signers to acquire new 186 certificates and put them to immediate use. ACME [RFC8555] is 187 designed for exactly this purpose. After a client registers with an 188 ACME server, and the authority of the client for the names in 189 question is established (through means such as 190 [I-D.ietf-acme-authority-token-tnauthlist]), the client can at any 191 time apply for a certificate to be issued by sending an appropriate 192 JSON request to the server. That request will contain a CSR 193 [RFC2986] indicating the intended scope of authority as well the 194 validity interval of the certificate in question. Ultimately, this 195 will enable the client to download the certificate from a certificate 196 URL designated by the server. 198 ACME is based on the concept that clients establish accounts at an 199 ACME server, and that through challenges, the server learns which 200 identifiers it will issue for certificates requested for an account. 201 Any given certificate issued for an account can be for just one of 202 those identifiers, or potentially for more: this is determined by the 203 CSR that an ACME client creates for a particular order. Thus, a 204 service provider with authority for millions of identifiers - that 205 is, millions of telephone numbers - could create a CSR for an ACME 206 order that requests a certificate only associated with one of those 207 telephone numbers if it so desired. The same would be true of 208 certificates based on Service Provider Codes (SPCs) as described in 209 [RFC8226]: a service provider might have just one SPC or perhaps 210 many. ACME thus puts needed flexibility into the hands of the 211 clients requesting certificates to determine how much of their 212 authority they want to invest in any given certificate. 214 ACME also provides a mechanism that allows the assignee of a number 215 to delegate temporary authority for it to a user. ACME Short-Term 216 Automatically-Renewed (STAR [RFC8739]) certificates provide a 217 property of automatic renewal for ACME orders, one that assumes that 218 certificates issuance is based on a hierarchical delegation. A 219 short-term certificate attesting authority for a particular 220 identifier might be issued for an interval of 72 hours, for example, 221 by the owner of the identifier to a delegate. In the STAR model, the 222 interface used by the owner of the identifier and the delegate is out 223 of the scope of ACME, as it would be for an adaptation of STAR to 224 telephone numbers (likely it would be an interface similar to MODERN 225 [RFC8396]). STAR permits the delegate to acquire new certificates 226 directly from the ACME server at each renewal interval. Because the 227 owner of the identifier in STAR actually fulfills the ACME challenge 228 and retrieves the Order ID for the certificate, the owner may at any 229 time send a certificate termination request to the ACME server, which 230 will prevent the certificate from being renewed by the delegate at 231 the next renewal interval. 233 [I-D.ietf-acme-authority-token-tnauthlist] uses the ATC framework of 234 [I-D.ietf-acme-authority-token] to generate tokens that are provided 235 to the CA in response to ACME challenges. For a usage with short- 236 term certificates, it may make sense for the ATC tokens to have a 237 relatively long expiry, so that the ACME client does not have to 238 constantly return to the Token Authority for new tokens. 240 [TBD: More alignment on ACME and STAR in particular] 242 5. IANA Considerations 244 This document contains no actions for the IANA. 246 6. Privacy Considerations 248 Short-lived certificates provide attractive privacy properties when 249 compared to real-time status query protocols like OCSP, which require 250 relying parties to perform a network dip that can reveal a great deal 251 about the source and destination of communications. For STIR, these 252 problems are compounded by the presence of the TN Authorization List 253 extension to certificates. Short-lived certificates can minimize the 254 data that needs to appear in the TN Authorization List, and 255 consequently reduce the amount of information about the caller leaked 256 by certificate usage to an amount equal to what is leaked by the call 257 signaling itself. 259 [More TBD] 261 7. Security Considerations 263 This document is entirely about security. For further information on 264 certificate security and practices, see [RFC5280], in particular its 265 Security Considerations. 267 8. Acknowledgments 269 Stephen Farrell provided key input to the discussions leading to this 270 document. 272 9. References 274 9.1. Normative References 276 [ATIS-0300251] 277 ATIS Recommendation 0300251, "Codes for Identification of 278 Service Providers for Information Exchange", 2007. 280 [DSS] National Institute of Standards and Technology, U.S. 281 Department of Commerce | NIST FIPS PUB 186-4, "Digital 282 Signature Standard, version 4", 2013. 284 [I-D.ietf-acme-authority-token] 285 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 286 Challenges Using an Authority Token", Work in Progress, 287 Internet-Draft, draft-ietf-acme-authority-token-07, 25 288 October 2021, . 291 [I-D.ietf-acme-authority-token-tnauthlist] 292 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 293 "TNAuthList profile of ACME Authority Token", Work in 294 Progress, Internet-Draft, draft-ietf-acme-authority-token- 295 tnauthlist-08, 27 March 2021, 296 . 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 305 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 306 . 308 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 309 DOI 10.17487/RFC2818, May 2000, 310 . 312 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 313 Request Syntax Specification Version 1.7", RFC 2986, 314 DOI 10.17487/RFC2986, November 2000, 315 . 317 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 318 A., Peterson, J., Sparks, R., Handley, M., and E. 319 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 320 DOI 10.17487/RFC3261, June 2002, 321 . 323 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 324 Standards (PKCS) #1: RSA Cryptography Specifications 325 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 326 2003, . 328 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 329 Resource Identifier (URI): Generic Syntax", STD 66, 330 RFC 3986, DOI 10.17487/RFC3986, January 2005, 331 . 333 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 334 Algorithms and Identifiers for RSA Cryptography for use in 335 the Internet X.509 Public Key Infrastructure Certificate 336 and Certificate Revocation List (CRL) Profile", RFC 4055, 337 DOI 10.17487/RFC4055, June 2005, 338 . 340 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 341 Certificate Status Protocol (OCSP) Profile for High-Volume 342 Environments", RFC 5019, DOI 10.17487/RFC5019, September 343 2007, . 345 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 346 Housley, R., and W. Polk, "Internet X.509 Public Key 347 Infrastructure Certificate and Certificate Revocation List 348 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 349 . 351 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 352 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 353 DOI 10.17487/RFC5912, June 2010, 354 . 356 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 357 DOI 10.17487/RFC5958, August 2010, 358 . 360 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 361 Infrastructure Certificate and Certificate Revocation List 362 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 363 2013, . 365 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 366 Galperin, S., and C. Adams, "X.509 Internet Public Key 367 Infrastructure Online Certificate Status Protocol - OCSP", 368 RFC 6960, DOI 10.17487/RFC6960, June 2013, 369 . 371 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 372 "Enrollment over Secure Transport", RFC 7030, 373 DOI 10.17487/RFC7030, October 2013, 374 . 376 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 377 for Generating Key Identifiers Values", RFC 7093, 378 DOI 10.17487/RFC7093, December 2013, 379 . 381 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 382 Protocol (HTTP/1.1): Message Syntax and Routing", 383 RFC 7230, DOI 10.17487/RFC7230, June 2014, 384 . 386 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 387 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 388 . 390 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 391 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 392 May 2017, . 394 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 395 "Authenticated Identity Management in the Session 396 Initiation Protocol (SIP)", RFC 8224, 397 DOI 10.17487/RFC8224, February 2018, 398 . 400 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 401 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 402 . 404 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 405 Credentials: Certificates", RFC 8226, 406 DOI 10.17487/RFC8226, February 2018, 407 . 409 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 410 Kasten, "Automatic Certificate Management Environment 411 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 412 . 414 [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor 415 Perales, A., and T. Fossati, "Support for Short-Term, 416 Automatically Renewed (STAR) Certificates in the Automated 417 Certificate Management Environment (ACME)", RFC 8739, 418 DOI 10.17487/RFC8739, March 2020, 419 . 421 [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) 422 Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, 423 September 2021, . 425 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 426 "Information technology - Open Systems Interconnection - 427 The Directory: Public-key and attribute certificate 428 frameworks", 2012. 430 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 431 "Information Technology - Abstract Syntax Notation One: 432 Specification of basic notation". 434 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 435 "Information Technology - Abstract Syntax Notation One: 436 Information Object Specification". 438 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 439 "Information Technology - Abstract Syntax Notation One: 440 Constraint Specification". 442 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 443 "Information Technology - Abstract Syntax Notation One: 444 Parameterization of ASN.1 Specifications". 446 9.2. Informative References 448 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 449 Extensions (MIME) Part Two: Media Types", RFC 2046, 450 DOI 10.17487/RFC2046, November 1996, 451 . 453 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 454 Wu, "Internet X.509 Public Key Infrastructure Certificate 455 Policy and Certification Practices Framework", RFC 3647, 456 DOI 10.17487/RFC3647, November 2003, 457 . 459 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 460 Polk, "Server-Based Certificate Validation Protocol 461 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 462 . 464 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 465 Multiple Certificate Status Request Extension", RFC 6961, 466 DOI 10.17487/RFC6961, June 2013, 467 . 469 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 470 Telephone Identity Problem Statement and Requirements", 471 RFC 7340, DOI 10.17487/RFC7340, September 2014, 472 . 474 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 475 RFC 7375, DOI 10.17487/RFC7375, October 2014, 476 . 478 [RFC8396] Peterson, J. and T. McGarry, "Managing, Ordering, 479 Distributing, Exposing, and Registering Telephone Numbers 480 (MODERN): Problem Statement, Use Cases, and Framework", 481 RFC 8396, DOI 10.17487/RFC8396, July 2018, 482 . 484 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 485 "Information technology - Open Systems Interconnection - 486 The Directory: Selected Attribute Types", 2012. 488 Author's Address 490 Jon Peterson 491 Neustar, Inc. 492 Email: jon.peterson@team.neustar