idnits 2.17.1 draft-ietf-stir-cert-delegation-00.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 (July 8, 2019) is 1747 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) == Unused Reference: 'RFC7044' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC7519' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'ATIS-0300251' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC5806' is defined on line 500, but no explicit reference was found in the text == 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-03 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-06 Summary: 0 errors (**), 0 flaws (~~), 9 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 July 8, 2019 5 Expires: January 9, 2020 7 STIR Certificate Delegation 8 draft-ietf-stir-cert-delegation-00.txt 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 January 9, 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 . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . 8 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 13.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The STIR problem statement [RFC7340] reviews the difficulties facing 79 the telephone network that are enabled by impersonation, including 80 various forms of robocalling, voicemail hacking, and swatting. One 81 of the most important components of a system to prevent impersonation 82 is the implementation of credentials which identify the parties who 83 control telephone numbers. The STIR certificates [RFC8226] 84 specification describes a credential system based on [X.509] version 85 3 certificates in accordance with [RFC5280] for that purpose. Those 86 credentials can then be used by STIR authentication services 87 [RFC8224] to sign PASSporT objects [RFC8225] carried in SIP [RFC3261] 88 requests. 90 [RFC8226] specifies an extension to X.509 that defines a Telephony 91 Number (TN) Authorization List that may be included by certification 92 authorities (CAs) in certificates. This extension provides 93 additional information that relying parties can use when validating 94 transactions with the certificate. When a SIP request, for example, 95 arrives at a terminating administrative domain, the calling number 96 attested by the SIP request can be compared to the TN Authorization 97 List of the certificate that signed the PASSporT to determine if the 98 caller is authorized to use that calling number. 100 Initial deployment of [RFC8226] has focused on the use of Service 101 Provider Codes (SPCs) to attest the scope of authority of a 102 certificate. Typically, these codes are internal telephone network 103 identifiers such as the Operating Company Numbers (OCNs) assigned to 104 carriers in the United States. However, these network identifiers 105 are effectively unavailable to non-carrier entities, and this has 106 raised questions about how such entities might best participate in 107 STIR, when needed. [RFC8226] gave an overview of a certificate 108 enrollment model based on "delegation," whereby the holder of 109 certificate might allocate a subset of that certificate's authority 110 to another party. This specification details how delegation of 111 authority works for STIR certificates. 113 2. Terminology 115 TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. Motivation 123 The most pressing need for delegation in STIR arises in a set of use 124 cases where callers want to use a particular calling number, but for 125 whatever reason, their outbound calls will not pass through the 126 authentication service of the service provider that controls that 127 numbering resource. 129 One example would be an enterprise that places outbound calls through 130 a set of service providers, for each call choosing a provider based 131 on a least-cost routing algorithm or similar local policy. The 132 enterprise was assigned a calling number by a particular service 133 provider, but some calls originating from that number will go out 134 through other service providers. 136 A user might also roam from their usual service provider to a 137 different network or administrative domain, for various reasons. 138 Most "legitimate spoofing" examples are of this form: where a user 139 wants to be able to use the main call-back number for their business 140 as a calling party number, even when the user is away from the 141 business. 143 These sorts of use cases could be addressed if the carrier who 144 controls the numbering resource were able to delegate a credential 145 that could be used to sign calls regardless of which network or 146 administrative domain handles the outbound routing for the call. In 147 the absence of something like a delegation mechanism, outbound 148 carriers may be forced to sign calls with credentials that do not 149 cover the originating number in question. Unfortunately, that 150 practice would be difficult to distinguish from malicious spoofing, 151 and if it becomes widespread, it could erode trust in STIR overall. 153 4. Delegation of STIR Certificates 155 STIR delegate certificates are certificates containing a TNAuthList 156 object that have been signed with the private key of a parent 157 certificate that itself contains a TNAuthList object. The parent 158 certificate needs to have its CA boolean set to "true", indicating 159 that that it can sign certificates. [TBD: Do we need to explore 160 alternatives (subcerts?)] Every STIR delegate certificate identifies 161 its parent certificate with a standard [RFC5280] Authority Key 162 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 5. Authentication Services Signing with Delegate Certificates 243 Authentication service behavior for delegate certificates is little 244 changed from baseline STIR behavior. The same checks are performed 245 by the authentication service, comparing the calling party number 246 attested in call signaling with the scope of the authority of the 247 signing certificate. Authentication services SHOULD NOT use a 248 delegate certificate without validating that its scope of authority 249 is encompassed by that of its parent certificate, and if that 250 certificate in turn has its own parent, the entire certificate path 251 should be validated. 253 This delegation architecture does not require that a non-carrier 254 entity act as its own authentication service. That function may be 255 performed by any authentication service that holds the private key 256 corresponding to the delegate certificate, including one run by an 257 outbound service provider, a third party in an enterprise's outbound 258 call path, or in the SIP User Agent itself. 260 Note that authentication services creating a PASSporT for a call 261 signed with a delegate certificate MUST provide an "x5u" link 262 corresponding to the entire certificate chain, rather than just the 263 delegate certificate used to sign the call, as described in 264 Section 7. 266 6. Verification Service Behavior for Delegate Certificate Signatures 268 The responsibility of a verification service validating PASSporTs 269 signed with delegate certificates, while largely following baseline 270 [RFC8224] and [RFC8225], requires some additional procedures. When 271 the verification service dereferences the "x5u" parameter, it will 272 acquire a certificate list rather than a single certificate. It MUST 273 then validate all of the credentials in the list, identifying the 274 parent certificate for each delegate through its AKID object. 276 While ordinarily, relying parties have significant latitude in path 277 construction when validating a certificate chain, STIR assumes a more 278 rigid hierarchical subordination model, rather than one where relying 279 parties may want to derive their own chains to particular trust 280 anchors. If the certificate chain acquired from the "x5u" element of 281 a PASSporT does not lead to an anchor that the verification service 282 trusts, it treats the validation no differently than it would when a 283 non-delegated certificate was issued by an untrusted root; in SIP, it 284 MAY return a 437 "Unsupported Credential" response if the call should 285 be failed for lack of a valid Identity header. 287 7. Acquiring Certificate Chains in STIR 289 PASSporT [RFC8225] uses the "x5u" element to convey the URL where 290 verification services can acquire the certificate used to sign a 291 PASSporT. This value is mirrored by the "info" parameter of the 292 Identity header when a PASSporT is conveyed via SIP. Commonly, this 293 is an HTTPS URI. 295 When a STIR delegate certificate is used to sign a PASSporT, the 296 "x5u" element in the PASSporT will contain a URI indicating where a 297 certificate list is available. [TBD: is it realistic to make this 298 "x5c"?] That list will be a concatenation of PEM encoded 299 certificates of the type "application/pem-certificate-chain" defined 300 in [RFC8555]. The list begins with the certificate used to sign the 301 PASSporT, followed by its parent, and then any subsequent 302 grandparents, great-grandparents, and so on. The ordering MUST 303 conform to the AKID/SKID order chain encoded in the certs themselves. 304 Note that ACME requires the first element in a pem-certificate-chain 305 to be an end-entity certificate; STIR relaxes this requirement, as CA 306 certificates are permitted to sign PASSporTs, so the first element in 307 a pem-certificate-chain used for STIR MAY be a CA certificate. 309 8. Certification Authorities and Service Providers 311 Once a telephone service provider has received a CA certificate 312 attesting their numbering resources, they may delegate from it as 313 they see fit. Note that the allocation to a service provider of a 314 certificate with the CA boolean set to "true" does not require that a 315 service provider act as a certification authority itself; it is a 316 function requiring specialized expertise and infrastructure. A 317 third-party certification authority, including the same one that 318 issued the service provider its parent certificate, could act as the 319 CA that issues delegate certificates for the service provider, if the 320 necessary business relationships permit it. A service provider might 321 in this case act as a Token Authority (see Section 8.1) granting its 322 customers permissions to receive certificates from the CA. 324 Note that if the same CA that issued the parent certificate is also 325 issuing a delegate certificate, it may be possible to shorten the 326 certificate chain, which reduces the work required of verification 327 services. 329 It is RECOMMENDED that any CA include in its practices and policies a 330 requirement to validate that the "encompassing" of a delegate 331 certificate by its parent. Future versions of this specification 332 will define a flag that a CA can add to a certificate indicating that 333 this function was performed. [TBD: do we really need that? Should 334 any CA ever not perform this function?] 336 8.1. ACME and Delegation 338 STIR deployments commonly use ACME [RFC8555] for certificate 339 acquisition, and it is anticipated that delegate certificates as well 340 will be acquired through an ACME interface. An entity can acquire a 341 certificate from a particular CA by requesting an Authority Token 342 [I-D.ietf-acme-authority-token] from the parent with the desired 343 TNAuthList [I-D.ietf-acme-authority-token-tnauthlist] object. Note 344 that if the client intends to do further subdelegation of its own, it 345 should request a token with the "ca" Authority Token flag set. 347 The entity then presents that Authority Token to a CA to acquire a 348 STIR delegate certificate. ACME returns an "application/pem- 349 certificate-chain" object with suitable for publishing as an HTTPS 350 resource for retrieval with the PASSporT "x5u" mechanism as discussed 351 in Section 7. If the CSR presented to the ACME server is for a 352 certificate with the CA boolean set to "true", then the ACME server 353 makes a policy decision to determine whether or not it is appropriate 354 to issue that certificate to the requesting entity. That policy 355 decision will be reflected by the "ca" flag in the Authority Token. 357 Service providers that want the capability to rapidly revoke 358 delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] 359 mechanism to automate the process of short-term certificate expiry. 360 [TBD: potential interaction with STIR short-term mechanisms, or the 361 ACME STAR delegation work?] 363 8.2. Handling Multiple Certificates 365 In some deployments, non-carrier entities may receive telephone 366 numbers from several different carriers. This could lead to 367 enterprises needing to maintain a sort of STIR keyring, with 368 different certificates delegated to them from different providers, 369 potentially issued by different CAs, which they choose between when 370 signing a call. This could be the case regardless of which syntax is 371 used in the TNAuthList to represent the scope of the delegation (see 372 Section 4.1). 374 For a small number of certificates, this is probably not a 375 significant burden. For cases where it becomes burdensome, a few 376 potential approaches exist. A delegate certificate could be cross- 377 certified with another delegate certificate via an Authority 378 Information Access field containing the URL of a Certificate 379 Authority Issuer, so that a signer would only need to sign with a 380 single certificate to inherit the privileges of the other 381 certificate(s) it has cross-certified with. In very complex 382 delegation cases, it might make more sense to establish a bridge CA 383 that cross-certifies with all of the certificates held by the 384 enterprise, rather than requiring a mesh of cross-certification 385 between a large number of certificates. Again, this bridge CA 386 function would likely be performed by some existing CA in the STIR 387 ecosystem. 389 9. IANA Considerations 391 This document contains no actions for the IANA. 393 10. Privacy Considerations 395 Any STIR certificate that identifies a narrow range of telephone 396 numbers potentially exposes information about the entities that are 397 placing calls. As this information is necessarily a superset of the 398 calling party number that is openly signaled during call setup, the 399 privacy risks associated with this mechanism are not substantially 400 greater than baseline STIR. See [RFC8224] for guidance on the use of 401 anonymization mechanisms in STIR. 403 11. Security Considerations 405 This document is entirely about security. For further information on 406 certificate security and practices, see [RFC5280], in particular its 407 Security Considerations. Also see the Security Considerations of 408 [RFC8226] for general guidance on the implications of the use of 409 certificates in STIR. 411 12. Acknowledgments 413 We would like to thank Richard Barnes, Chris Wendt, Dave Hancock, 414 Russ Housley, and Sean Turner for key input to the discussions 415 leading to this document. 417 13. References 419 13.1. Normative References 421 [I-D.ietf-acme-authority-token] 422 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 423 Challenges Using an Authority Token", draft-ietf-acme- 424 authority-token-03 (work in progress), March 2019. 426 [I-D.ietf-acme-authority-token-tnauthlist] 427 Wendt, C., Hancock, D., Barnes, M., and J. Peterson, 428 "TNAuthList profile of ACME Authority Token", draft-ietf- 429 acme-authority-token-tnauthlist-03 (work in progress), 430 March 2019. 432 [I-D.ietf-acme-star] 433 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 434 Fossati, "Support for Short-Term, Automatically-Renewed 435 (STAR) Certificates in Automated Certificate Management 436 Environment (ACME)", draft-ietf-acme-star-06 (work in 437 progress), July 2019. 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 445 A., Peterson, J., Sparks, R., Handley, M., and E. 446 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 447 DOI 10.17487/RFC3261, June 2002, 448 . 450 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 451 C. Holmberg, "An Extension to the Session Initiation 452 Protocol (SIP) for Request History Information", RFC 7044, 453 DOI 10.17487/RFC7044, February 2014, 454 . 456 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 457 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 458 . 460 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 461 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 462 May 2017, . 464 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 465 "Authenticated Identity Management in the Session 466 Initiation Protocol (SIP)", RFC 8224, 467 DOI 10.17487/RFC8224, February 2018, 468 . 470 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 471 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 472 . 474 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 475 Credentials: Certificates", RFC 8226, 476 DOI 10.17487/RFC8226, February 2018, 477 . 479 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 480 Kasten, "Automatic Certificate Management Environment 481 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 482 . 484 13.2. Informative References 486 [ATIS-0300251] 487 ATIS Recommendation 0300251, "Codes for Identification of 488 Service Providers for Information Exchange", 2007. 490 [DSS] National Institute of Standards and Technology, U.S. 491 Department of Commerce | NIST FIPS PUB 186-4, "Digital 492 Signature Standard, version 4", 2013. 494 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 495 Housley, R., and W. Polk, "Internet X.509 Public Key 496 Infrastructure Certificate and Certificate Revocation List 497 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 498 . 500 [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in 501 SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, 502 . 504 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 505 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 506 February 2012, . 508 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 509 Telephone Identity Problem Statement and Requirements", 510 RFC 7340, DOI 10.17487/RFC7340, September 2014, 511 . 513 [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, 514 "Information technology - Open Systems Interconnection - 515 The Directory: Public-key and attribute certificate 516 frameworks", 2012. 518 [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, 519 "Information technology - Open Systems Interconnection - 520 The Directory: Selected Attribute Types", 2012. 522 [X.680] ITU-T Recommendation X.680 (08/2015) | ISO/IEC 8824-1, 523 "Information Technology - Abstract Syntax Notation One: 524 Specification of basic notation". 526 [X.681] ITU-T Recommendation X.681 (08/2015) | ISO/IEC 8824-2, 527 "Information Technology - Abstract Syntax Notation One: 528 Information Object Specification". 530 [X.682] ITU-T Recommendation X.682 (08/2015) | ISO/IEC 8824-2, 531 "Information Technology - Abstract Syntax Notation One: 532 Constraint Specification". 534 [X.683] ITU-T Recommendation X.683 (08/2015) | ISO/IEC 8824-3, 535 "Information Technology - Abstract Syntax Notation One: 536 Parameterization of ASN.1 Specifications". 538 Author's Address 540 Jon Peterson 541 Neustar, Inc. 543 Email: jon.peterson@team.neustar