idnits 2.17.1 draft-ietf-regext-rdap-object-tag-05.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 (August 3, 2018) is 2090 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7481' is defined on line 577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7484 (Obsoleted by RFC 9224) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7482 (Obsoleted by RFC 9082) -- Obsolete informational reference (is this intentional?): RFC 7483 (Obsoleted by RFC 9083) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions S. Hollenbeck 3 Internet-Draft Verisign Labs 4 Updates: 7484 (if approved) A. Newton 5 Intended status: Best Current Practice ARIN 6 Expires: February 4, 2019 August 3, 2018 8 Registration Data Access Protocol (RDAP) Object Tagging 9 draft-ietf-regext-rdap-object-tag-05 11 Abstract 13 The Registration Data Access Protocol (RDAP) includes a method that 14 can be used to identify the authoritative server for processing 15 domain name, IP address, and autonomous system number queries. The 16 method does not describe how to identify the authoritative server for 17 processing other RDAP query types, such as entity queries. This 18 limitation exists because the identifiers associated with these query 19 types are typically unstructured. This document updates RFC 7484 by 20 describing an operational practice that can be used to add structure 21 to RDAP identifiers that makes it possible to identify the 22 authoritative server for additional RDAP queries. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 4, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Object Naming Practice . . . . . . . . . . . . . . . . . . . 3 60 3. Bootstrap Service Registry for Provider Object Tags . . . . . 8 61 3.1. Registration Procedure . . . . . . . . . . . . . . . . . 9 62 4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 10 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 5.1. Bootstrap Service Registry Structure . . . . . . . . . . 10 65 5.2. RDAP Extensions Registry . . . . . . . . . . . . . . . . 10 66 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 67 6.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 11 68 6.2. OpenRDAP . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 9.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 The Registration Data Access Protocol (RDAP) includes a method 80 ([RFC7484]) that can be used to identify the authoritative server for 81 processing domain name, IP address, and autonomous system number 82 (ASN) queries. This method works because each of these data elements 83 is structured in a way that facilitates automated parsing of the 84 element and association of the data element with a particular RDAP 85 service provider. For example, domain names include labels (such as 86 "com", "net", and "org") that are associated with specific service 87 providers. 89 As noted in Section 9 of RFC 7484 [RFC7484], the method does not 90 describe how to identify the authoritative server for processing 91 entity queries, name server queries, help queries, or queries using 92 certain search patterns. This limitation exists because the 93 identifiers bound to these queries are typically not structured in a 94 way that makes it easy to associate an identifier with a specific 95 service provider. This document describes an operational practice 96 that can be used to add structure to RDAP identifiers that makes it 97 possible to identify the authoritative server for additional RDAP 98 queries. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. Object Naming Practice 108 Tagging object identifiers with a service provider tag makes it 109 possible to identify the authoritative server for processing an RDAP 110 query using the method described in RFC 7484 [RFC7484]. A service 111 provider tag is constructed by prepending the Unicode HYPHEN-MINUS 112 character "-" (U+002D, described as an "unreserved" character in RFC 113 3986 [RFC3986]) to an IANA-registered value that represents the 114 service provider. For example, a tag for a service provider 115 identified by the string value "ARIN" is represented as "-ARIN". 117 In combination with the rdapConformance attribute described in 118 Section 4, service provider tags are concatenated to the end of RDAP 119 query object identifiers to unambiguously identify the authoritative 120 server for processing an RDAP query. Building on the example from 121 Section 3.1.5 of RFC 7482 [RFC7482], an RDAP entity handle can be 122 constructed that allows an RDAP client to bootstrap an entity query. 123 The following identifier is used to find information for the entity 124 associated with handle "XXXX" at service provider "ARIN": 126 XXXX-ARIN 128 Clients that wish to bootstrap an entity query can parse this 129 identifier into distinct handle and service provider identifier 130 elements. Handles can themselves contain HYPHEN-MINUS characters; 131 the service provider identifier is found following the last HYPHEN- 132 MINUS character in the tagged identifier. The service provider 133 identifier is used to retrieve a base RDAP URL from an IANA registry. 134 The base URL and entity handle are then used to form a complete RDAP 135 query path segment. For example, if the base RDAP URL 136 "https://example.com/rdap/" is associated with service provider 137 "YYYY" in an IANA registry, an RDAP client will parse a tagged entity 138 identifier "XXXX-YYYY" into distinct handle ("XXXX") and service 139 provider ("YYYY") identifiers. The service provider identifier 140 "YYYY" is used to query an IANA registry to retrieve the base RDAP 141 URL "https://example.com/rdap/". The RDAP query URL is formed using 142 the base RDAP URL and entity path segment described in Section 3.1.5 143 of RFC 7482 [RFC7482], using "XXXX-YYY" as the value of the handle 144 identifier. The complete RDAP query URL becomes 145 "https://example.com/rdap/entity/XXXX-YYYY". 147 Implementation of this practice requires tagging of unstructured 148 potential query identifiers in RDAP responses. Consider these elided 149 examples ("..." is used to note elided response objects) from 150 Section 5.3 of RFC 7483 [RFC7483] in which the handle identifiers 151 have been tagged with service provider tags "RIR", "DNR", and "ABC" 152 respectively: 154 { 155 "objectClassName" : "domain", 156 "handle" : "XXXX-RIR", 157 "ldhName" : "0.2.192.in-addr.arpa", 158 "nameservers" : 159 [ 160 ... 161 ], 162 "secureDNS": 163 { 164 ... 165 }, 166 "remarks" : 167 [ 168 ... 169 ], 170 "links" : 171 [ 172 ... 173 ], 174 "events" : 175 [ 176 ... 177 ], 178 "entities" : 179 [ 180 { 181 "objectClassName" : "entity", 182 "handle" : "XXXX-RIR", 183 "vcardArray": 184 [ 185 ... 186 ], 187 "roles" : [ "registrant" ], 188 "remarks" : 189 [ 190 ... 191 ], 192 "links" : 193 [ 194 ... 195 ], 196 "events" : 197 [ 198 ... 199 ] 200 } 201 ], 202 "network" : 203 { 204 "objectClassName" : "ip network", 205 "handle" : "XXXX-RIR", 206 "startAddress" : "192.0.2.0", 207 "endAddress" : "192.0.2.255", 208 "ipVersion" : "v4", 209 "name": "NET-RTR-1", 210 "type" : "DIRECT ALLOCATION", 211 "country" : "AU", 212 "parentHandle" : "YYYY-RIR", 213 "status" : [ "active" ] 214 } 215 } 217 Figure 1 219 { 220 "objectClassName" : "domain", 221 "handle" : "XXXX-YYY-DNR", 222 "ldhName" : "xn--fo-5ja.example", 223 "unicodeName" : "foo.example", 224 "variants" : 225 [ 226 ... 227 ], 228 "status" : [ "locked", "transfer prohibited" ], 229 "publicIds": 230 [ 231 ... 232 ], 233 "nameservers" : 234 [ 235 { 236 "objectClassName" : "nameserver", 237 "handle" : "XXXX-DNR", 238 "ldhName" : "ns1.example.com", 239 "status" : [ "active" ], 240 "ipAddresses" : 241 { 242 ... 243 }, 244 "remarks" : 245 [ 246 ... 247 ], 248 "links" : 249 [ 250 ... 251 ], 252 "events" : 253 [ 254 ... 255 ] 256 }, 257 { 258 "objectClassName" : "nameserver", 259 "handle" : "XXXX-DNR", 260 "ldhName" : "ns2.example.com", 261 "status" : [ "active" ], 262 "ipAddresses" : 263 { 264 ... 265 }, 266 "remarks" : 267 [ 268 ... 269 ], 270 "links" : 271 [ 272 ... 273 ], 274 "events" : 275 [ 276 ... 277 ] 278 } 279 ], 280 "secureDNS": 281 { 282 ... 283 }, 284 "remarks" : 285 [ 286 ... 287 ], 288 "links" : 289 [ 290 ... 291 ], 292 "port43" : "whois.example.net", 293 "events" : 294 [ 295 ... 296 ], 297 "entities" : 298 [ 299 { 300 "objectClassName" : "entity", 301 "handle" : "XXXX-ABC", 302 "vcardArray": 303 [ 304 ... 305 ], 306 "status" : [ "validated", "locked" ], 307 "roles" : [ "registrant" ], 308 "remarks" : 309 [ 310 ... 311 ], 312 "links" : 313 [ 314 ... 315 ], 316 "events" : 317 [ 318 ... 319 ] 320 } 321 ] 322 } 324 Figure 2 326 As described in Section 5 of RFC 7483 [RFC7483], RDAP responses can 327 contain "self" links. Service provider tags and self references 328 SHOULD be consistent. If they are inconsistent, the service provider 329 tag is processed with higher priority when using these values to 330 identify a service provider. 332 There is a risk of unpredictable processing behavior if the HYPHEN- 333 MINUS character is used for naturally occurring, non-separator 334 purposes in an entity handle. This could lead to a client mistakenly 335 assuming that a HYPHEN-MINUS character represents a separator and the 336 text that follows HYPHEN-MINUS is a service provider identifier. A 337 client that queries the IANA registry for what they assume is a valid 338 service provider will likely receive an unexpected, invalid result. 339 As a consequence, use of the HYPHEN-MINUS character as a service 340 provider tag separator MUST be noted by adding an rdapConformance 341 value to query responses as described in Section 4. 343 The HYPHEN-MINUS character was chosen as a separator for two reasons: 344 1) it is a familiar separator character in operational use, and 2) it 345 avoids collision with URI-reserved characters. The list of 346 unreserved characters specified in Section 2.3 of RFC 3986 [RFC3986] 347 provided multiple options for consideration: 349 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 351 ALPHA and DIGIT characters were excluded because they are commonly 352 used in entity handles for non-separator purposes. HYPHEN-MINUS is 353 commonly used as a separator and recognition of this practice will 354 reduce implementation requirements and operational risk. The 355 remaining characters were excluded because they are not broadly used 356 as separators in entity handles. 358 3. Bootstrap Service Registry for Provider Object Tags 360 The bootstrap service registry for the RDAP service provider space is 361 represented using the structure specified in Section 3 of RFC 7484 362 [RFC7484]. The JSON output of this registry contains contact 363 information for the registered service provider identifiers, 364 alphanumeric identifiers that identify RDAP service providers, and 365 base RDAP service URLs as shown in this example. 367 { 368 "version": "1.0", 369 "publication": "YYYY-MM-DDTHH:MM:SSZ", 370 "description": "RDAP bootstrap file for service provider object tags", 371 "services": [ 372 [ 373 ["contact@example.com"], 374 ["YYYY"], 375 [ 376 "https://example.com/rdap/" 377 ] 378 ], 379 [ 380 ["contact@example.org"], 381 ["ZZ54"], 382 [ 383 "http://rdap.example.org/" 384 ] 385 ], 386 [ 387 ["contact@example.net"], 388 ["1754"], 389 [ 390 "https://example.net/rdap/", 391 "http://example.net/rdap/" 392 ] 393 ] 394 ] 395 } 397 Figure 3 399 Alphanumeric service provider identifiers conform to the suffix 400 portion ("\w{1,8}") of the "roidType" syntax specified in Section 4.2 401 of RFC 5730 [RFC5730]. 403 3.1. Registration Procedure 405 The service provider registry is populated using the "First Come 406 First Served" policy defined in RFC 8126 [RFC8126]. Provider 407 identifier values can be derived and assigned by IANA on request. 408 Registration requests include an email address to be associated with 409 the registered service provider identifier, the requested service 410 provider identifier (or an indication that IANA should assign an 411 identifier), and one or more base RDAP URLs to be associated with the 412 service provider identifier. 414 4. RDAP Conformance 416 RDAP responses that contain values described in this document MUST 417 indicate conformance with this specification by including an 418 rdapConformance ([RFC7483]) value of "rdap_objectTag_level_0". The 419 information needed to register this value in the RDAP Extensions 420 Registry is described in Section 5.2. 422 Example rdapConformance structure with extension specified: 424 "rdapConformance" : 425 [ 426 "rdap_level_0", 427 "rdap_objectTag_level_0" 428 ] 430 Figure 4 432 5. IANA Considerations 434 IANA is requested to create the RDAP "Bootstrap Service Registry for 435 Provider Object Tags" listed below and make it available as JSON 436 objects. The contents of this registry is described in Section 3, 437 with the formal syntax specified in Section 10 of RFC 7484 [RFC7484]. 439 5.1. Bootstrap Service Registry Structure 441 Entries in this registry contain the following information: 443 o An email address that identifies a contact associated with the 444 registered RDAP service provider value. 445 o An alphanumeric value that identifies the RDAP service provider 446 being registered. 447 o One or more URLs that provide the RDAP service regarding this 448 registration. The URLS are expected to supply the same data, but 449 they can differ in scheme or other components as required by the 450 service operator. 452 5.2. RDAP Extensions Registry 454 IANA is requested to register the following value in the RDAP 455 Extensions Registry: 457 Extension identifier: rdap_objectTag 458 Registry operator: Any 459 Published specification: This document. 460 Contact: IESG 461 Intended usage: This extension describes a best practice for 462 structuring entity identifiers to enable query bootstrapping. 464 6. Implementation Status 466 NOTE: Please remove this section and the reference to RFC 7942 prior 467 to publication as an RFC. 469 This section records the status of known implementations of the 470 protocol defined by this specification at the time of posting of this 471 Internet-Draft, and is based on a proposal described in RFC 7942 472 [RFC7942]. The description of implementations in this section is 473 intended to assist the IETF in its decision processes in progressing 474 drafts to RFCs. Please note that the listing of any individual 475 implementation here does not imply endorsement by the IETF. 476 Furthermore, no effort has been spent to verify the information 477 presented here that was supplied by IETF contributors. This is not 478 intended as, and must not be construed to be, a catalog of available 479 implementations or their features. Readers are advised to note that 480 other implementations may exist. 482 According to RFC 7942, "this will allow reviewers and working groups 483 to assign due consideration to documents that have the benefit of 484 running code, which may serve as evidence of valuable experimentation 485 and feedback that have made the implemented protocols more mature. 486 It is up to the individual working groups to use this information as 487 they see fit". 489 6.1. Verisign Labs 491 Responsible Organization: Verisign Labs 492 Location: https://rdap.verisignlabs.com/ 493 Description: This implementation includes support for domain 494 registry RDAP queries using live data from the .cc and .tv country 495 code top-level domains. Client authentication is required to 496 receive entity information in query responses. 497 Level of Maturity: This is a "proof of concept" research 498 implementation. 499 Coverage: This implementation includes all of the features 500 described in this specification. 501 Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 503 6.2. OpenRDAP 505 Responsible Organization: OpenRDAP 506 Location: https://www.openrdap.org 507 Description: RDAP client implementing bootstrapping for entity 508 handles with a service provider tag. A test Bootstrap Services 509 Registry file is currently used in lieu of an official one. 510 Level of Maturity: Alpha 511 Coverage: Implements draft 04+, supports the HYPHEN-MINUS 512 separator character only. 513 Contact Information: Tom Harwood, tfh@skip.org 515 7. Security Considerations 517 This practice uses IANA as a well-known, central trusted authority to 518 allow users to get RDAP data from an authoritative source, reducing 519 the risk of sending queries to non-authoritative sources and 520 divulging query information to unintended parties. Using TLS 521 [RFC5246] to protect the connection to IANA allows the server to 522 authenticate itself as being operated by IANA and provides integrity 523 protection for the resulting referral information, as well as 524 providing privacy protection via data confidentiality. The 525 subsequent RDAP connection is performed as usual, and retains the 526 same security properties of the RDAP protocols themselves. 528 8. Acknowledgements 530 The author would like to acknowledge the following individuals for 531 their contributions to the development of this document: Tom 532 Harrison, Patrick Mevzek, and Marcos Sanz. In addition, the authors 533 would like to recognize the Regional Internet Registry (RIR) 534 operators (AFRINIC, APNIC, ARIN, LACNIC, and RIPE) that have been 535 implementing and using the practice of tagging handle identifiers for 536 several years. Their experience provided significant inspiration for 537 the development of this document. 539 9. References 541 9.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 549 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 550 . 552 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 553 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 554 2015, . 556 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 557 Writing an IANA Considerations Section in RFCs", BCP 26, 558 RFC 8126, DOI 10.17487/RFC8126, June 2017, 559 . 561 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 562 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 563 May 2017, . 565 9.2. Informative References 567 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 568 Resource Identifier (URI): Generic Syntax", STD 66, 569 RFC 3986, DOI 10.17487/RFC3986, January 2005, 570 . 572 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 573 (TLS) Protocol Version 1.2", RFC 5246, 574 DOI 10.17487/RFC5246, August 2008, 575 . 577 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 578 Registration Data Access Protocol (RDAP)", RFC 7481, 579 DOI 10.17487/RFC7481, March 2015, 580 . 582 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 583 Protocol (RDAP) Query Format", RFC 7482, 584 DOI 10.17487/RFC7482, March 2015, 585 . 587 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 588 Registration Data Access Protocol (RDAP)", RFC 7483, 589 DOI 10.17487/RFC7483, March 2015, 590 . 592 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 593 Code: The Implementation Status Section", BCP 205, 594 RFC 7942, DOI 10.17487/RFC7942, July 2016, 595 . 597 Appendix A. Change Log 599 00: Initial version. 600 01: Changed separator character from HYPHEN MINUS to COMMERCIAL AT. 601 Added a recommendation to maintain consistency between service 602 provider tags and "self" links (suggestion received from Tom 603 Harrison). Fixed a spelling error, and corrected the network 604 example in Section 2 (editorial erratum reported for RFC 7483 by 605 Marcos Sanz). Added acknowledgements. 606 02: Changed separator character from COMMERCIAL AT to TILDE. 607 Clarity updates and fixed an example handle. Added text to 608 describe the risk of separator characters appearing naturally in 609 entity handles and being misinterpreted as separator characters. 610 03: Added Implementation Status section (Section 6). 611 04: Keepalive refresh. 612 05: Added OpenRDAP implementation information to Section 6. 613 00: Initial working group version. 614 01: Added text to describe why the TILDE character was chosen as the 615 separator character. 616 02: Nit fixes. Added rdapConformance text, switched back to HYPHEN 617 MINUS, and added IANA registration instructions per working group 618 last call discussion. Updated suffix syntax reference from the 619 IANA EPP ROID registry to RFC 5730 (which is what the IANA 620 registry references). 621 03: Shepherd writeup review updates to explain examples in 622 Section 2. 623 04: AD review update to clarify query path construction. 624 05: IESG review update: object naming practice, revised an example 625 to include multiple separator HYPHEN-MINUS characters, revised 626 security considerations, revised IANA considerations, revised IANA 627 registry description and registration procedure to add email 628 address contact information. 630 Authors' Addresses 632 Scott Hollenbeck 633 Verisign Labs 634 12061 Bluemont Way 635 Reston, VA 20190 636 USA 638 Email: shollenbeck@verisign.com 639 URI: http://www.verisignlabs.com/ 641 Andrew Lee Newton 642 American Registry for Internet Numbers 643 PO Box 232290 644 Centreville, VA 20120 645 US 647 Email: andy@arin.net 648 URI: http://www.arin.net