idnits 2.17.1 draft-peterson-stir-certificates-shortlived-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2489 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 253, but not defined == Unused Reference: 'ATIS-0300251' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC2392' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC5019' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC5912' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC5958' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC6818' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC7093' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC3647' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC5055' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC6961' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC7375' is defined on line 455, 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' == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-07 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-00 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 ** Downref: Normative reference to an Informational draft: draft-peterson-acme-telephone (ref. 'I-D.peterson-acme-telephone') ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** 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 normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-04) exists of draft-ietf-modern-problem-framework-02 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 7 errors (**), 0 flaws (~~), 28 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 July 3, 2017 5 Expires: January 4, 2018 7 Short-Lived Certificates for Secure Telephone Identity 8 draft-peterson-stir-certificates-shortlived-01.txt 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 http://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 January 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 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 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Short-lived certificates for STIR . . . . . . . . . . . . . . 3 57 4. Certificate Acquisition with ACME . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 The STIR problem statement [RFC7340] discusses many attacks on the 70 telephone network that are enabled by impersonation, including 71 various forms of robocalling, voicemail hacking, and swatting. One 72 of the most important components of a system to prevent impersonation 73 is the implementation of credentials which identify the parties who 74 control telephone numbers. The STIR certificates 75 [I-D.ietf-stir-certificates] specification describes a credential 76 system based on [X.509] version 3 certificates in accordance with 77 [RFC5280] for that purpose. Those credentials can then be used by 78 STIR authentication services [I-D.ietf-stir-rfc4474bis] to sign 79 PASSporT objects [I-D.ietf-stir-passport] carried in a SIP [RFC3261] 80 request. 82 The STIR certificates document specifies an extension to X.509 that 83 defines a Telephony Number (TN) Authorization List that may be 84 included by certificate authorities in certificates. This extension 85 provides additional information that relying parties can use when 86 validating transactions with the certificate. When a SIP request, 87 for example, arrives at a terminating administrative domain, the 88 calling number attested by the SIP request can be compared to the TN 89 Authorization List of the certificate that signed the request to 90 determine if the caller is authorized to use that calling number in 91 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. 98 Short-lived certificates also have a number of other desirable 99 properties that fulfill important operational requirements for 100 network operators. The use of the Automated Certificate Management 101 Environment (ACME) [I-D.ietf-acme-acme] to manage these short-lived 102 certificates is the focus of the architecture specified, in 103 particular adapting the Short-Term Automatically Renewed (STAR) 104 [I-D.ietf-acme-star] mechanism to STIR. The interaction of STIR with 105 ACME has already been explored in [I-D.peterson-acme-telephone]. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in RFC 112 2119 [RFC2119]. 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. Sha certificateort-lived certificates offer 125 an alternative where, if compromised, certificates will shortly 126 expire anyway, and rather than revoking and reissuing the certificate 127 in response to a crisis, certificates routinely roll-over and cannot 128 be cached for a long term by relying parties, minimizing their value 129 to 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 143 [I-D.ietf-stir-certificates] adds a new wrinkle to the behavior of 144 short-lived certificates. Because a subject may have authority over 145 multiple telephone numbers, a certificate issued to that subject 146 could attest the authority over all, some, or just one of those 147 telephone numbers. If an authentication service wanted to acquire a 148 new certificate on a per-call basis, for example, they could acquire 149 a certificate that can only sign for the calling party number of the 150 call in question. At the other end of the spectrum, a large service 151 provider could acquire a certificate valid for millions of numbers, 152 but expire the certificate after a very short duration - on the order 153 of hours - to reduce the risk that the certificate would be 154 compromised. 156 This inherent flexibility in the short-lived certificate architecture 157 would also permit authentication services to implement very narrow 158 policies for certificate usage. A large service provider who wanted 159 to avoid revealing which phone numbers they controlled, for example, 160 could provide no information in the certificate that signs a call 161 other than just the single telephone number that corresponds to the 162 calling party's number. How frequently the service provider feels 163 that they need to expire that certificate and acquire a new one is 164 entirely a matter of policy to them. This makes it much harder for 165 entities monitoring signatures over calls to guess who owns which 166 numbers, and provides a much more complicated threat surface for 167 attackers trying to compromise the service. 169 In order to reduce the burden on verification services, an 170 authentication service could also piggyback a short-lived certificate 171 onto the signed SIP request, so that no network lookup and consequent 172 round-trip delay would be required on the terminating side to acquire 173 the new certificate. [I-D.ietf-stir-rfc4474bis] already provides a 174 way of pointing to a certificate in a MIME body associated with the 175 SIP request. Future work could specify other means of carrying 176 certificates within SIP requests via a header rather than a body, to 177 optimize for intermediaries adding and extracting these certificates. 179 4. Certificate Acquisition with ACME 181 One of the primary challenges facing short-lived certificates is 182 building an operational system that allows signers to acquire new 183 certificates and put them to immediate use. ACME 184 [I-D.ietf-acme-acme] is designed for exactly this purpose. After a 185 client registers with an ACME server, and the authority of the client 186 for the names in question is established (through means such as 187 [I-D.peterson-acme-telephone]), the client can at any time apply for 188 a certificate to be issued by sending an appropriate JSON request to 189 the server. That request will contain a CSR [RFC2986] indicating the 190 intended scope of authority as well the validity interval of the 191 certificate in question. Ultimately, this will enable the client to 192 download the certificate from a certificate URL designated by the 193 server. 195 ACME is based on the concept that clients establish accounts at an 196 ACME server, and that through challenges, the server learns which 197 identifiers it will issue for certificates requested for an account. 198 Any given certificate issued for an account can be for just one of 199 those identifiers, or potentially for more: this is determined by the 200 CSR that an ACME client creates for a particular order. Thus, a 201 service provider with authority for millions of identifiers - that 202 is, millions of telephone numbers - could create a CSR for an ACME 203 order that requests a certificate only associated with one of those 204 telephone numbers if it so desired. The same would be true of 205 certificates based on Service Provider Codes (SPCs) as described in 206 [I-D.ietf-stir-certificates]: a service provider might have just one 207 SPC or perhaps many. ACME thus puts needed flexibility into the 208 hands of the clients requesting certificates to determine how much of 209 their authority they want to invest in any given certificate. 211 ACME also provides a mechanism that allows the assignee of a number 212 to delegate temporary authority for it to a user. ACME Short-Term 213 Automatically-Renewed (STAR [I-D.ietf-acme-star]) certificates 214 provide a property of automatical renewal for ACME orders, one that 215 assumes that certificates issuance is based on a hierarchical 216 delegation. A short-term certificate attesting authority for a 217 particular identifier might be issued for an interval of 72 hours, 218 for example, by the owner of the identifer to a delegate. In the 219 STAR model, the interface used by the owner of the identifier and the 220 delegate is out of the scope of ACME, as it would be for an 221 adaptation of STAR to telephone numbers (likely it would be an 222 interface similar to MODERN [I-D.ietf-modern-problem-framework]). 223 STAR permits the delegate to acquire new certificates directly from 224 the ACME server at each renewal interval. Because the owner of the 225 identifier in STAR actually fulfills the ACME challenge and retrieves 226 the Order ID for the certificate, the owner may at any time send a 227 certificate termination request to the ACME server, which will 228 prevent the certificate from being renewed by the delegate at the 229 next renewal interval. 231 [TBD: More on adapting STAR] 233 [TBD: What needs to fixed for the TN Authorization List extension, 234 including both TN and SPC cases>] 236 5. IANA Considerations 238 This document contains no actions for the IANA. 240 6. Privacy Considerations 242 Short-lived certificates provide attractive privacy properties when 243 compared to real-time status query protocols like OCSP, which require 244 relying parties to perform a network dip that can reveal a great deal 245 about the source and destination of communications. For STIR, these 246 problems are compounded by the presence of the TN Authorization List 247 extension to certificates. Short-lived certificates can minimize the 248 data that needs to appear in the TN Authorization List, and 249 consequently reduce the amount of information about the caller leaked 250 by certificate usage to an amount equal to what is leaked by the call 251 signaling itself. 253 [More TBD] 255 7. Security Considerations 257 This document is entirely about security. For further information on 258 certificate security and practices, see [RFC5280], in particular its 259 Security Considerations. 261 8. Acknowledgments 263 Stephen Farrell provided key input to the discussions leading to this 264 document. 266 9. References 268 9.1. Normative References 270 [ATIS-0300251] 271 ATIS Recommendation 0300251, "Codes for Identification of 272 Service Providers for Information Exchange", 2007. 274 [DSS] National Institute of Standards and Technology, U.S. 275 Department of Commerce | NIST FIPS PUB 186-4, "Digital 276 Signature Standard, version 4", 2013. 278 [I-D.ietf-acme-acme] 279 Barnes, R., Hoffman-Andrews, J., and J. Kasten, "Automatic 280 Certificate Management Environment (ACME)", draft-ietf- 281 acme-acme-07 (work in progress), June 2017. 283 [I-D.ietf-acme-star] 284 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 285 Fossati, "Use of Short-Term, Automatically-Renewed (STAR) 286 Certificates to Delegate Authority over Web Sites", draft- 287 ietf-acme-star-00 (work in progress), June 2017. 289 [I-D.ietf-stir-certificates] 290 Peterson, J. and S. Turner, "Secure Telephone Identity 291 Credentials: Certificates", draft-ietf-stir- 292 certificates-14 (work in progress), May 2017. 294 [I-D.ietf-stir-passport] 295 Wendt, C. and J. Peterson, "Personal Assertion Token 296 (PASSporT)", draft-ietf-stir-passport-11 (work in 297 progress), February 2017. 299 [I-D.ietf-stir-rfc4474bis] 300 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 301 "Authenticated Identity Management in the Session 302 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 303 (work in progress), February 2017. 305 [I-D.peterson-acme-telephone] 306 Peterson, J. and R. Barnes, "ACME Identifiers and 307 Challenges for Telephone Numbers", draft-peterson-acme- 308 telephone-00 (work in progress), October 2016. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 316 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 317 . 319 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 320 DOI 10.17487/RFC2818, May 2000, 321 . 323 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 324 Request Syntax Specification Version 1.7", RFC 2986, 325 DOI 10.17487/RFC2986, November 2000, 326 . 328 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 329 A., Peterson, J., Sparks, R., Handley, M., and E. 330 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 331 DOI 10.17487/RFC3261, June 2002, 332 . 334 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 335 Standards (PKCS) #1: RSA Cryptography Specifications 336 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 337 2003, . 339 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 340 Resource Identifier (URI): Generic Syntax", STD 66, 341 RFC 3986, DOI 10.17487/RFC3986, January 2005, 342 . 344 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 345 Algorithms and Identifiers for RSA Cryptography for use in 346 the Internet X.509 Public Key Infrastructure Certificate 347 and Certificate Revocation List (CRL) Profile", RFC 4055, 348 DOI 10.17487/RFC4055, June 2005, 349 . 351 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 352 Certificate Status Protocol (OCSP) Profile for High-Volume 353 Environments", RFC 5019, DOI 10.17487/RFC5019, September 354 2007, . 356 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 357 Housley, R., and W. Polk, "Internet X.509 Public Key 358 Infrastructure Certificate and Certificate Revocation List 359 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 360 . 362 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 363 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 364 DOI 10.17487/RFC5912, June 2010, 365 . 367 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 368 DOI 10.17487/RFC5958, August 2010, 369 . 371 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 372 Infrastructure Certificate and Certificate Revocation List 373 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 374 2013, . 376 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 377 Galperin, S., and C. Adams, "X.509 Internet Public Key 378 Infrastructure Online Certificate Status Protocol - OCSP", 379 RFC 6960, DOI 10.17487/RFC6960, June 2013, 380 . 382 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 383 "Enrollment over Secure Transport", RFC 7030, 384 DOI 10.17487/RFC7030, October 2013, 385 . 387 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 388 for Generating Key Identifiers Values", RFC 7093, 389 DOI 10.17487/RFC7093, December 2013, 390 . 392 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 393 Protocol (HTTP/1.1): Message Syntax and Routing", 394 RFC 7230, DOI 10.17487/RFC7230, June 2014, 395 . 397 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 398 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 399 . 401 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 402 "Information technology - Open Systems Interconnection - 403 The Directory: Public-key and attribute certificate 404 frameworks", 2012. 406 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 407 "Information Technology - Abstract Syntax Notation One: 408 Specification of basic notation". 410 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 411 "Information Technology - Abstract Syntax Notation One: 412 Information Object Specification". 414 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 415 "Information Technology - Abstract Syntax Notation One: 416 Constraint Specification". 418 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 419 "Information Technology - Abstract Syntax Notation One: 420 Parameterization of ASN.1 Specifications". 422 9.2. Informative References 424 [I-D.ietf-modern-problem-framework] 425 Peterson, J. and T. McGarry, "Modern Problem Statement, 426 Use Cases, and Framework", draft-ietf-modern-problem- 427 framework-02 (work in progress), March 2017. 429 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 430 Extensions (MIME) Part Two: Media Types", RFC 2046, 431 DOI 10.17487/RFC2046, November 1996, 432 . 434 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 435 Wu, "Internet X.509 Public Key Infrastructure Certificate 436 Policy and Certification Practices Framework", RFC 3647, 437 DOI 10.17487/RFC3647, November 2003, 438 . 440 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 441 Polk, "Server-Based Certificate Validation Protocol 442 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 443 . 445 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 446 Multiple Certificate Status Request Extension", RFC 6961, 447 DOI 10.17487/RFC6961, June 2013, 448 . 450 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 451 Telephone Identity Problem Statement and Requirements", 452 RFC 7340, DOI 10.17487/RFC7340, September 2014, 453 . 455 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 456 RFC 7375, DOI 10.17487/RFC7375, October 2014, 457 . 459 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 460 "Information technology - Open Systems Interconnection - 461 The Directory: Selected Attribute Types", 2012. 463 Author's Address 465 Jon Peterson 466 Neustar, Inc. 468 Email: jon.peterson@neustar.biz