idnits 2.17.1 draft-hollenbeck-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 316: '... SHOULD be consistent. If they are ...' RFC 2119 keyword, line 327: '... TILDE character MUST NOT be used in a...' -- The draft header indicates that this document updates RFC7484, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2017) is 2377 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) -- Looks like a reference, but probably isn't: '1' on line 517 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 6 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: April 27, 2018 October 24, 2017 8 Registration Data Access Protocol (RDAP) Object Tagging 9 draft-hollenbeck-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 describes an 20 operational practice that can be used to add structure to RDAP 21 identifiers that makes it possible to identify the authoritative 22 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 April 27, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 RDAP Service Providers . . . . 7 61 3.1. Registration Procedure . . . . . . . . . . . . . . . . . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. Bootstrap Service Registry for RDAP Service Providers . . 9 64 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. OpenRDAP . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The Registration Data Access Protocol (RDAP) includes a method 79 ([RFC7484]) that can be used to identify the authoritative server for 80 processing domain name, IP address, and autonomous system number 81 (ASN) queries. This method works because each of these data elements 82 is structured in a way that facilitates automated parsing of the 83 element and association of the data element with a particular RDAP 84 service provider. For example, domain names include labels (such as 85 "com", "net", and "org") that are associated with specific service 86 providers. 88 As noted in Section 9 of RFC 7484 [RFC7484], the method does not 89 describe how to identify the authoritative server for processing 90 entity queries, name server queries, help queries, or queries using 91 certain search patterns. This limitation exists because the 92 identifiers bound to these queries are typically not structured in a 93 way that makes it easy to associate an identifier with a specific 94 service provider. This document describes an operational practice 95 that can be used to add structure to RDAP identifiers that makes it 96 possible to identify the authoritative server for additional RDAP 97 queries. 99 2. Object Naming Practice 101 Tagging object identifiers with a service provider tag makes it 102 possible to identify the authoritative server for processing an RDAP 103 query using the method described in RFC 7484 [RFC7484]. A service 104 provider tag is constructed by prepending the Unicode TILDE character 105 "~" (U+007E, described as an "unreserved" character in RFC 3986 106 [RFC3986]) to an IANA-registered value that represents the service 107 provider. For example, a tag for a service provider identified by 108 the string value "ARIN" is represented as "~ARIN". 110 Service provider tags are concatenated to the end of RDAP query 111 object identifiers to unambiguously identify the authoritative server 112 for processing an RDAP query. Building on the example from 113 Section 3.1.5 of RFC 7482 [RFC7482], an RDAP entity handle can be 114 constructed that allows an RDAP client to bootstrap an entity query. 115 The following identifier is used to find information for the entity 116 associated with handle "XXXX" at service provider "ARIN": 118 XXXX~ARIN 120 Clients that wish to bootstrap an entity query can parse this 121 identifier into distinct handle and service provider identifier 122 elements. Handles can themselves contain TILDE characters; the 123 service provider identifier is found following the last TILDE 124 character in the tagged identifier. The service provider identifier 125 is used to retrieve a base RDAP URL from an IANA registry. The base 126 URL and entity handle are then used to form a complete RDAP query 127 path segment. For example, if the base RDAP URL 128 "https://example.com/rdap/" is associated with service provider 129 "YYYY" in an IANA registry, an RDAP client will parse a tagged entity 130 identifier "XXXX~YYYY" into distinct handle ("XXXX") and service 131 provider ("YYYY") identifiers. The service provider identifier 132 "YYYY" is used to query an IANA registry to retrieve the base RDAP 133 URL "https://example.com/rdap/". The base RDAP URL is concatenated 134 to the entity handle to create a complete RDAP query path segment of 135 "https://example.com/rdap/entity/XXXX~YYYY". 137 Implementation of this practice requires tagging of unstructured 138 potential query identifiers in RDAP responses. Consider these elided 139 examples from Section 5.3 of RFC 7483 [RFC7483] in which the handle 140 identifiers have been tagged with a service provider tag: 142 { 143 "objectClassName" : "domain", 144 "handle" : "XXXX~RIR", 145 "ldhName" : "0.2.192.in-addr.arpa", 146 "nameservers" : 147 [ 148 ... 149 ], 150 "secureDNS": 151 { 152 ... 153 }, 154 "remarks" : 155 [ 156 ... 157 ], 158 "links" : 159 [ 160 ... 161 ], 162 "events" : 163 [ 164 ... 165 ], 166 "entities" : 167 [ 168 { 169 "objectClassName" : "entity", 170 "handle" : "XXXX~RIR", 171 "vcardArray": 172 [ 173 ... 174 ], 175 "roles" : [ "registrant" ], 176 "remarks" : 177 [ 178 ... 179 ], 180 "links" : 181 [ 182 ... 183 ], 184 "events" : 185 [ 186 ... 187 ] 188 } 189 ], 190 "network" : 191 { 192 "objectClassName" : "ip network", 193 "handle" : "XXXX~RIR", 194 "startAddress" : "192.0.2.0", 195 "endAddress" : "192.0.2.255", 196 "ipVersion" : "v4", 197 "name": "NET-RTR-1", 198 "type" : "DIRECT ALLOCATION", 199 "country" : "AU", 200 "parentHandle" : "YYYY~RIR", 201 "status" : [ "active" ] 202 } 203 } 205 Figure 1 207 { 208 "objectClassName" : "domain", 209 "handle" : "XXXX~DNR", 210 "ldhName" : "xn--fo-5ja.example", 211 "unicodeName" : "foo.example", 212 "variants" : 213 [ 214 ... 215 ], 216 "status" : [ "locked", "transfer prohibited" ], 217 "publicIds": 218 [ 219 ... 220 ], 221 "nameservers" : 222 [ 223 { 224 "objectClassName" : "nameserver", 225 "handle" : "XXXX~DNR", 226 "ldhName" : "ns1.example.com", 227 "status" : [ "active" ], 228 "ipAddresses" : 229 { 230 ... 231 }, 232 "remarks" : 233 [ 234 ... 235 ], 236 "links" : 237 [ 238 ... 239 ], 240 "events" : 241 [ 242 ... 243 ] 244 }, 245 { 246 "objectClassName" : "nameserver", 247 "handle" : "XXXX~DNR", 248 "ldhName" : "ns2.example.com", 249 "status" : [ "active" ], 250 "ipAddresses" : 251 { 252 ... 253 }, 254 "remarks" : 255 [ 256 ... 257 ], 258 "links" : 259 [ 260 ... 261 ], 262 "events" : 263 [ 264 ... 265 ] 266 } 267 ], 268 "secureDNS": 269 { 270 ... 271 }, 272 "remarks" : 273 [ 274 ... 275 ], 276 "links" : 277 [ 278 ... 279 ], 280 "port43" : "whois.example.net", 281 "events" : 282 [ 283 ... 284 ], 285 "entities" : 286 [ 287 { 288 "objectClassName" : "entity", 289 "handle" : "XXXX~ABC", 290 "vcardArray": 291 [ 292 ... 293 ], 294 "status" : [ "validated", "locked" ], 295 "roles" : [ "registrant" ], 296 "remarks" : 297 [ 298 ... 299 ], 300 "links" : 301 [ 302 ... 303 ], 304 "events" : 305 [ 306 ... 307 ] 308 } 309 ] 310 } 312 Figure 2 314 As described in Section 5 of RFC 7483 [RFC7483], RDAP responses can 315 contain "self" links. Service provider tags and self references 316 SHOULD be consistent. If they are inconsistent, the service provider 317 tag is processed with higher priority when using these values to 318 identify a service provider. 320 There is a risk of unpredictable processing behavior if the TILDE 321 character is used for naturally occurring, non-separator purposes in 322 an entity handle. This could lead to a client mistakenly assuming 323 that a TILDE character represents a separator and the text that 324 follows TILDE is a service provider identifier. A client that 325 queries the IANA registry for what they assume is a valid service 326 provider will likely receive an unexpected invalid result. As a 327 consequence, the TILDE character MUST NOT be used in an entity handle 328 for any purpose other than to separate an object identifier from a 329 service provider tag. 331 3. Bootstrap Service Registry for RDAP Service Providers 333 The bootstrap service registry for the RDAP service provider space is 334 represented using the structure specified in Section 3 of RFC 7484 335 [RFC7484]. The JSON output of this registry contains alphanumeric 336 identifiers that identify RDAP service providers, grouped by base 337 RDAP URLs, as shown in this example. 339 { 340 "version": "1.0", 341 "publication": "YYYY-MM-DDTHH:MM:SSZ", 342 "description": "RDAP service provider bootstrap values", 343 "services": [ 344 [ 345 ["YYYY"], 346 [ 347 "https://example.com/rdap/" 348 ] 349 ], 350 [ 351 ["ZZ54"], 352 [ 353 "http://rdap.example.org/" 354 ] 355 ], 356 [ 357 ["1754"], 358 [ 359 "https://example.net/rdap/", 360 "http://example.net/rdap/" 361 ] 362 ] 363 ] 364 } 366 Figure 3 368 Alphanumeric service provider identifiers conform to the syntax 369 specified in the IANA registry of Extensible Provisioning Protocol 370 (EPP) Repository Identifiers [1]. 372 3.1. Registration Procedure 374 The service provider registry is populated using the "First Come 375 First Served" policy defined in RFC 5226 [RFC5226]. Provider 376 identifier values can be derived and assigned by IANA on request. 377 Registration requests include the requested service provider 378 identifier (or an indication that IANA should assign an identifier) 379 and one or more base RDAP URLs to be associated with the service 380 provider identifier. 382 4. IANA Considerations 384 IANA is requested to create the RDAP Bootstrap Services Registry 385 listed below and make it available as JSON objects. The contents of 386 this registry is described in Section 3, with the formal syntax 387 specified in Section 10 of RFC 7484 [RFC7484]. 389 4.1. Bootstrap Service Registry for RDAP Service Providers 391 Entries in this registry contain at least the following: 393 o An alphanumeric value that identifies the RDAP service provider 394 being registered. 395 o One or more URLs that provide the RDAP service regarding this 396 registration. 398 5. Implementation Status 400 NOTE: Please remove this section and the reference to RFC 7942 prior 401 to publication as an RFC. 403 This section records the status of known implementations of the 404 protocol defined by this specification at the time of posting of this 405 Internet-Draft, and is based on a proposal described in RFC 7942 406 [RFC7942]. The description of implementations in this section is 407 intended to assist the IETF in its decision processes in progressing 408 drafts to RFCs. Please note that the listing of any individual 409 implementation here does not imply endorsement by the IETF. 410 Furthermore, no effort has been spent to verify the information 411 presented here that was supplied by IETF contributors. This is not 412 intended as, and must not be construed to be, a catalog of available 413 implementations or their features. Readers are advised to note that 414 other implementations may exist. 416 According to RFC 7942, "this will allow reviewers and working groups 417 to assign due consideration to documents that have the benefit of 418 running code, which may serve as evidence of valuable experimentation 419 and feedback that have made the implemented protocols more mature. 420 It is up to the individual working groups to use this information as 421 they see fit". 423 5.1. Verisign Labs 425 Responsible Organization: Verisign Labs 426 Location: https://rdap.verisignlabs.com/ 427 Description: This implementation includes support for domain 428 registry RDAP queries using live data from the .cc and .tv country 429 code top-level domains. Client authentication is required to 430 receive entity information in query responses. 431 Level of Maturity: This is a "proof of concept" research 432 implementation. 433 Coverage: This implementation includes all of the features 434 described in this specification. 435 Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 437 5.2. OpenRDAP 439 Responsible Organization: OpenRDAP 440 Location: https://www.openrdap.org 441 Description: RDAP client implementing bootstrapping for entity 442 handles with a service provider tag. A test Bootstrap Services 443 Registry file is currently used in lieu of an official one. 444 Level of Maturity: Alpha 445 Coverage: Implements draft 04+, supports the TILDE separator 446 character only. 447 Contact Information: Tom Harwood, tfh@skip.org 449 6. Security Considerations 451 This practice helps to ensure that end users will get RDAP data from 452 an authoritative source using a bootstrap method to find 453 authoritative RDAP servers, reducing the risk of sending queries to 454 non-authoritative sources. The method has the same security 455 properties as the RDAP protocols themselves. The transport used to 456 access the IANA registries can be more secure by using TLS [RFC5246], 457 which IANA supports. Additional considerations associated with RDAP 458 are described in RFC 7481 [RFC7481]. 460 7. Acknowledgements 462 The author would like to acknowledge the following individuals for 463 their contributions to the development of this document: Tom 464 Harrison, and Marcos Sanz. In addition, the authors would like to 465 recognize the Regional Internet Registry (RIR) operators (AFRINIC, 466 APNIC, ARIN, LACNIC, and RIPE) that have been implementing and using 467 the practice of tagging handle identifiers for several years. Their 468 experience provided significant inspiration for the development of 469 this document. 471 8. References 472 8.1. Normative References 474 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 475 IANA Considerations Section in RFCs", RFC 5226, 476 DOI 10.17487/RFC5226, May 2008, 477 . 479 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 480 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 481 2015, . 483 8.2. Informative References 485 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 486 Resource Identifier (URI): Generic Syntax", STD 66, 487 RFC 3986, DOI 10.17487/RFC3986, January 2005, 488 . 490 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 491 (TLS) Protocol Version 1.2", RFC 5246, 492 DOI 10.17487/RFC5246, August 2008, 493 . 495 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 496 Registration Data Access Protocol (RDAP)", RFC 7481, 497 DOI 10.17487/RFC7481, March 2015, 498 . 500 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 501 Protocol (RDAP) Query Format", RFC 7482, 502 DOI 10.17487/RFC7482, March 2015, 503 . 505 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 506 Registration Data Access Protocol (RDAP)", RFC 7483, 507 DOI 10.17487/RFC7483, March 2015, 508 . 510 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 511 Code: The Implementation Status Section", BCP 205, 512 RFC 7942, DOI 10.17487/RFC7942, July 2016, 513 . 515 8.3. URIs 517 [1] http://www.iana.org/assignments/epp-repository-ids/epp- 518 repository-ids.xhtml#epp-repository-ids-1 520 Appendix A. Change Log 522 00: Initial version. 523 01: Changed separator character from HYPHEN MINUS to COMMERCIAL AT. 524 Added a recommendation to maintain consistency between service 525 provider tags and "self" links (suggestion received from Tom 526 Harrison). Fixed a spelling error, and corrected the network 527 example in Section 2 (editorial erratum reported for RFC 7483 by 528 Marcos Sanz). Added acknowledgements. 529 02: Changed separator character from COMMERCIAL AT to TILDE. 530 Clarity updates and fixed an example handle. Added text to 531 describe the risk of separator characters appearing naturally in 532 entity handles and being misinterpreted as separator characters. 533 03: Added Implementation Status section (Section 5). 534 04: Keepalive refresh. 535 05: Added OpenRDAP implementation information to Section 5. 537 Authors' Addresses 539 Scott Hollenbeck 540 Verisign Labs 541 12061 Bluemont Way 542 Reston, VA 20190 543 USA 545 Email: shollenbeck@verisign.com 546 URI: http://www.verisignlabs.com/ 548 Andrew Lee Newton 549 American Registry for Internet Numbers 550 PO Box 232290 551 Centreville, VA 20120 552 US 554 Email: andy@arin.net 555 URI: http://www.arin.net