idnits 2.17.1 draft-peterson-stir-certificates-shortlived-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2018) is 2244 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: 'I-D.wendt-acme-authority-token-tnauthlist' is mentioned on line 229, but not defined == Missing Reference: 'I-D.peterson-acme-authority-token' is mentioned on line 230, but not defined == Missing Reference: 'More TBD' is mentioned on line 256, but not defined == Unused Reference: 'ATIS-0300251' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC2392' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC4055' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC5019' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC5912' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC5958' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC6818' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'RFC7093' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC3647' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC5055' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC6961' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC7375' is defined on line 454, 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-09 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-03 ** 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-03 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 29 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 March 5, 2018 5 Expires: September 6, 2018 7 Short-Lived Certificates for Secure Telephone Identity 8 draft-peterson-stir-certificates-shortlived-02.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 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 September 6, 2018. 37 Copyright Notice 39 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . 6 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 [RFC8226] 75 specification describes a credential system based on [X.509] version 76 3 certificates in accordance with [RFC5280] for that purpose. Those 77 credentials can then be used by STIR authentication services 78 [RFC8224] to sign PASSporT objects [RFC8225] carried in a SIP 79 [RFC3261] request. 81 The STIR certificates document specifies an extension to X.509 that 82 defines a Telephony Number (TN) Authorization List that may be 83 included by certificate authorities in certificates. This extension 84 provides additional information that relying parties can use when 85 validating transactions with the certificate. When a SIP request, 86 for example, arrives at a terminating administrative domain, the 87 calling number attested by the SIP request can be compared to the TN 88 Authorization List of the certificate that signed the request to 89 determine if the caller is authorized to use that calling number in 90 SIP. 92 No specific recommendation is made in the STIR certificates document 93 for a means of determining the freshness of certificates with a TN 94 Authorization List. This document explores how short-lived 95 certificates could be used as a means of preserving that freshness. 96 Short-lived certificates also have a number of other desirable 97 properties that fulfill important operational requirements for 98 network operators. The use of the Automated Certificate Management 99 Environment (ACME) [I-D.ietf-acme-acme] to manage these short-lived 100 certificates is the focus of the architecture specified, in 101 particular adapting the Short-Term Automatically Renewed (STAR) 102 [I-D.ietf-acme-star] mechanism to STIR. The interaction of STIR with 103 ACME has already been explored in [I-D.wendt-acme-authority-token- 104 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 RFC 111 2119 [RFC2119]. 113 3. Short-lived certificates for STIR 115 While there is no easy definition of what constitutes a "short-lived" 116 certificate, the term typically refers to certificates that are valid 117 only for days or even hours, as opposed to the months or years common 118 in traditional public key infrastructures. When the private keying 119 material associated with that has an expiry of months or years is 120 compromised by an adversary, the issuing authority must revoke the 121 certificate, which requires relying parties to review certificate 122 revocation lists or to access real-time status information with 123 protocols such as OCSP. Sha certificateort-lived certificates offer 124 an alternative where, if compromised, certificates will shortly 125 expire anyway, and rather than revoking and reissuing the certificate 126 in response to a crisis, certificates routinely roll-over and cannot 127 be cached for a long term by relying parties, minimizing their value 128 to attackers. 130 One of the additional benefits of using short-lived certificates is 131 that they do not require relying parties to perform any certificate 132 freshness check. The trade-off is that the signer must acquire new 133 certificates frequently, so the cost of round-trip times to the 134 certificate authority is paid on the signer's side rather than the 135 verifier's side; however, in environments where many parties may rely 136 on a single certificate, or at least where a single certificate will 137 be used to sign many transactions during its short lifetime, the 138 overall architecture will incur fewer round-trip times to the 139 certificate authority and thus less processing delay. 141 In the STIR context, the TN Authorization List defined in [RFC8226] 142 adds a new wrinkle to the behavior of short-lived certificates. 143 Because a subject may have authority over multiple telephone numbers, 144 a certificate issued to that subject could attest the authority over 145 all, some, or just one of those telephone numbers. If an 146 authentication service wanted to acquire a new certificate on a per- 147 call basis, for example, they could acquire a certificate that can 148 only sign for the calling party number of the call in question. At 149 the other end of the spectrum, a large service provider could acquire 150 a certificate valid for millions of numbers, but expire the 151 certificate after a very short duration - on the order of hours - to 152 reduce the risk that the certificate would be compromised. 154 This inherent flexibility in the short-lived certificate architecture 155 would also permit authentication services to implement very narrow 156 policies for certificate usage. A large service provider who wanted 157 to avoid revealing which phone numbers they controlled, for example, 158 could provide no information in the certificate that signs a call 159 other than just the single telephone number that corresponds to the 160 calling party's number. How frequently the service provider feels 161 that they need to expire that certificate and acquire a new one is 162 entirely a matter of policy to them. This makes it much harder for 163 entities monitoring signatures over calls to guess who owns which 164 numbers, and provides a much more complicated threat surface for 165 attackers trying to compromise the service. 167 In order to reduce the burden on verification services, an 168 authentication service could also piggyback a short-lived certificate 169 onto the signed SIP request, so that no network lookup and consequent 170 round-trip delay would be required on the terminating side to acquire 171 the new certificate. [RFC8224] already provides a way of pointing to 172 a certificate in a MIME body associated with the SIP request. Future 173 work could specify other means of carrying certificates within SIP 174 requests via a header rather than a body, to optimize for 175 intermediaries adding and extracting these certificates. 177 4. Certificate Acquisition with ACME 179 One of the primary challenges facing short-lived certificates is 180 building an operational system that allows signers to acquire new 181 certificates and put them to immediate use. ACME 182 [I-D.ietf-acme-acme] is designed for exactly this purpose. After a 183 client registers with an ACME server, and the authority of the client 184 for the names in question is established (through means such as [I- 185 D.wendt-acme-authority-token-tnauthlist]), the client can at any time 186 apply for a certificate to be issued by sending an appropriate JSON 187 request to the server. That request will contain a CSR [RFC2986] 188 indicating the intended scope of authority as well the validity 189 interval of the certificate in question. Ultimately, this will 190 enable the client to download the certificate from a certificate URL 191 designated by the server. 193 ACME is based on the concept that clients establish accounts at an 194 ACME server, and that through challenges, the server learns which 195 identifiers it will issue for certificates requested for an account. 196 Any given certificate issued for an account can be for just one of 197 those identifiers, or potentially for more: this is determined by the 198 CSR that an ACME client creates for a particular order. Thus, a 199 service provider with authority for millions of identifiers - that 200 is, millions of telephone numbers - could create a CSR for an ACME 201 order that requests a certificate only associated with one of those 202 telephone numbers if it so desired. The same would be true of 203 certificates based on Service Provider Codes (SPCs) as described in 204 [RFC8226]: a service provider might have just one SPC or perhaps 205 many. ACME thus puts needed flexibility into the hands of the 206 clients requesting certificates to determine how much of their 207 authority they want to invest in any given certificate. 209 ACME also provides a mechanism that allows the assignee of a number 210 to delegate temporary authority for it to a user. ACME Short-Term 211 Automatically-Renewed (STAR [I-D.ietf-acme-star]) certificates 212 provide a property of automatic renewal for ACME orders, one that 213 assumes that certificates issuance is based on a hierarchical 214 delegation. A short-term certificate attesting authority for a 215 particular identifier might be issued for an interval of 72 hours, 216 for example, by the owner of the identifier to a delegate. In the 217 STAR model, the interface used by the owner of the identifier and the 218 delegate is out of the scope of ACME, as it would be for an 219 adaptation of STAR to telephone numbers (likely it would be an 220 interface similar to MODERN [I-D.ietf-modern-problem-framework]). 221 STAR permits the delegate to acquire new certificates directly from 222 the ACME server at each renewal interval. Because the owner of the 223 identifier in STAR actually fulfills the ACME challenge and retrieves 224 the Order ID for the certificate, the owner may at any time send a 225 certificate termination request to the ACME server, which will 226 prevent the certificate from being renewed by the delegate at the 227 next renewal interval. 229 [I-D.wendt-acme-authority-token-tnauthlist] uses the ATC framework of 230 [I-D.peterson-acme-authority-token] to generate tokens that are 231 provided to the CA in response to ACME challenges. For a usage with 232 short-term certificates, it may make sense for the ATC tokens to have 233 a relatively long expiry, so that the ACME client does not have to 234 constantly return to the Token Authority for new tokens. 236 [TBD: More on when the ACME stuff gets into better shape, and on 237 adapting STAR] 239 5. IANA Considerations 241 This document contains no actions for the IANA. 243 6. Privacy Considerations 245 Short-lived certificates provide attractive privacy properties when 246 compared to real-time status query protocols like OCSP, which require 247 relying parties to perform a network dip that can reveal a great deal 248 about the source and destination of communications. For STIR, these 249 problems are compounded by the presence of the TN Authorization List 250 extension to certificates. Short-lived certificates can minimize the 251 data that needs to appear in the TN Authorization List, and 252 consequently reduce the amount of information about the caller leaked 253 by certificate usage to an amount equal to what is leaked by the call 254 signaling itself. 256 [More TBD] 258 7. Security Considerations 260 This document is entirely about security. For further information on 261 certificate security and practices, see [RFC5280], in particular its 262 Security Considerations. 264 8. Acknowledgments 266 Stephen Farrell provided key input to the discussions leading to this 267 document. 269 9. References 271 9.1. Normative References 273 [ATIS-0300251] 274 ATIS Recommendation 0300251, "Codes for Identification of 275 Service Providers for Information Exchange", 2007. 277 [DSS] National Institute of Standards and Technology, U.S. 278 Department of Commerce | NIST FIPS PUB 186-4, "Digital 279 Signature Standard, version 4", 2013. 281 [I-D.ietf-acme-acme] 282 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 283 Kasten, "Automatic Certificate Management Environment 284 (ACME)", draft-ietf-acme-acme-09 (work in progress), 285 December 2017. 287 [I-D.ietf-acme-star] 288 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 289 Fossati, "Support for Short-Term, Automatically-Renewed 290 (STAR) Certificates in Automated Certificate Management 291 Environment (ACME)", draft-ietf-acme-star-03 (work in 292 progress), March 2018. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, 296 DOI 10.17487/RFC2119, March 1997, 297 . 299 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 300 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 301 . 303 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 304 DOI 10.17487/RFC2818, May 2000, 305 . 307 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 308 Request Syntax Specification Version 1.7", RFC 2986, 309 DOI 10.17487/RFC2986, November 2000, 310 . 312 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 313 A., Peterson, J., Sparks, R., Handley, M., and E. 314 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 315 DOI 10.17487/RFC3261, June 2002, 316 . 318 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 319 Standards (PKCS) #1: RSA Cryptography Specifications 320 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 321 2003, . 323 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 324 Resource Identifier (URI): Generic Syntax", STD 66, 325 RFC 3986, DOI 10.17487/RFC3986, January 2005, 326 . 328 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 329 Algorithms and Identifiers for RSA Cryptography for use in 330 the Internet X.509 Public Key Infrastructure Certificate 331 and Certificate Revocation List (CRL) Profile", RFC 4055, 332 DOI 10.17487/RFC4055, June 2005, 333 . 335 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 336 Certificate Status Protocol (OCSP) Profile for High-Volume 337 Environments", RFC 5019, DOI 10.17487/RFC5019, September 338 2007, . 340 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 341 Housley, R., and W. Polk, "Internet X.509 Public Key 342 Infrastructure Certificate and Certificate Revocation List 343 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 344 . 346 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 347 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 348 DOI 10.17487/RFC5912, June 2010, 349 . 351 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 352 DOI 10.17487/RFC5958, August 2010, 353 . 355 [RFC6818] Yee, P., "Updates to the Internet X.509 Public Key 356 Infrastructure Certificate and Certificate Revocation List 357 (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 358 2013, . 360 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 361 Galperin, S., and C. Adams, "X.509 Internet Public Key 362 Infrastructure Online Certificate Status Protocol - OCSP", 363 RFC 6960, DOI 10.17487/RFC6960, June 2013, 364 . 366 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 367 "Enrollment over Secure Transport", RFC 7030, 368 DOI 10.17487/RFC7030, October 2013, 369 . 371 [RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods 372 for Generating Key Identifiers Values", RFC 7093, 373 DOI 10.17487/RFC7093, December 2013, 374 . 376 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 377 Protocol (HTTP/1.1): Message Syntax and Routing", 378 RFC 7230, DOI 10.17487/RFC7230, June 2014, 379 . 381 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 382 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 383 . 385 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 386 "Authenticated Identity Management in the Session 387 Initiation Protocol (SIP)", RFC 8224, 388 DOI 10.17487/RFC8224, February 2018, 389 . 391 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 392 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 393 . 395 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 396 Credentials: Certificates", RFC 8226, 397 DOI 10.17487/RFC8226, February 2018, 398 . 400 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 401 "Information technology - Open Systems Interconnection - 402 The Directory: Public-key and attribute certificate 403 frameworks", 2012. 405 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 406 "Information Technology - Abstract Syntax Notation One: 407 Specification of basic notation". 409 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 410 "Information Technology - Abstract Syntax Notation One: 411 Information Object Specification". 413 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 414 "Information Technology - Abstract Syntax Notation One: 415 Constraint Specification". 417 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 418 "Information Technology - Abstract Syntax Notation One: 419 Parameterization of ASN.1 Specifications". 421 9.2. Informative References 423 [I-D.ietf-modern-problem-framework] 424 Peterson, J. and T. McGarry, "Modern Problem Statement, 425 Use Cases, and Framework", draft-ietf-modern-problem- 426 framework-03 (work in progress), July 2017. 428 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 429 Extensions (MIME) Part Two: Media Types", RFC 2046, 430 DOI 10.17487/RFC2046, November 1996, 431 . 433 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 434 Wu, "Internet X.509 Public Key Infrastructure Certificate 435 Policy and Certification Practices Framework", RFC 3647, 436 DOI 10.17487/RFC3647, November 2003, 437 . 439 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 440 Polk, "Server-Based Certificate Validation Protocol 441 (SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007, 442 . 444 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 445 Multiple Certificate Status Request Extension", RFC 6961, 446 DOI 10.17487/RFC6961, June 2013, 447 . 449 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 450 Telephone Identity Problem Statement and Requirements", 451 RFC 7340, DOI 10.17487/RFC7340, September 2014, 452 . 454 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 455 RFC 7375, DOI 10.17487/RFC7375, October 2014, 456 . 458 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 459 "Information technology - Open Systems Interconnection - 460 The Directory: Selected Attribute Types", 2012. 462 Author's Address 464 Jon Peterson 465 Neustar, Inc. 467 Email: jon.peterson@team.neustar