idnits 2.17.1 draft-blanchet-regext-entityid2rdapserver-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 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) -- Looks like a reference, but probably isn't: '1' on line 461 -- Looks like a reference, but probably isn't: '2' on line 464 -- Looks like a reference, but probably isn't: '3' on line 467 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- 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) -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Standards Track March 11, 2019 5 Expires: September 12, 2019 7 Finding Additional Registration Data (RDAP) Service 8 draft-blanchet-regext-entityid2rdapserver-00 10 Abstract 12 This document specifies a method to find which Registration Data 13 Access Protocol (RDAP) server is authoritative to answer additional 14 information for a query already answered by another server. It is 15 based on an entity id to RDAP server location mapping registry 16 managed by IANA. One use case of this specification is the domain 17 registry RDAP server providing a referral URL to the registrar RDAP 18 server, based on the registrar entity id, for information that the 19 registrar is authoritative for such as the contact or reseller 20 information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 3. High-Level Functional Description . . . . . . . . . . . . . . 3 59 4. Registry of Entity to RDAP server location . . . . . . . . . 3 60 5. Identifying the Entity . . . . . . . . . . . . . . . . . . . 4 61 6. Structure of the Entity to RDAP Server Location Registry . . 4 62 7. Formal Definition . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Imported JSON Terms . . . . . . . . . . . . . . . . . . . 6 64 7.2. Registry Syntax . . . . . . . . . . . . . . . . . . . . . 6 65 8. Recursive Referrals . . . . . . . . . . . . . . . . . . . . . 7 66 9. Merging the Data Received from Multiple RDAP Servers . . . . 7 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 12. Discussion of this draft . . . . . . . . . . . . . . . . . . 8 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 13.2. Informative References . . . . . . . . . . . . . . . . . 10 73 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Finding the authoritative Registration Data Access Protocol (RDAP) 80 server is specified in [RFC7484]. In some use cases, the 81 authoritative server answering an RDAP query may not have all the 82 information, but instead another server has the missing information. 83 However, the first server may not know the location (URL) of that 84 other server, but just an organization identifier, therefore it can 85 not send a link or redirect, as described in [RFC7483]. 86 Operationally, the location of the other server will need to be known 87 to many servers, where storing the mapping centrally enables the 88 scalable management of the locations.. 90 The typical use case is for domain registries where the RDAP server 91 of the domain registry is not authoritative for or does not have some 92 information for the query, but the registrar, a separate entity from 93 the domain registry, is authoritative and does have that additional 94 information. The information may include contact, reseller, 95 expiration date information. The registry RDAP server needs to 96 provide a referral location (URL) to the client, or provide the 97 organization identifier for the client to map to a location (URL), to 98 enable the client to retrieve the information from the registrar RDAP 99 server. 101 This specification is generic to include other possible current or 102 future cases, so it does not focus on the specific thin domain 103 registry-registrar case while it uses that use case for examples. 105 2. Conventions Used in This Document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. High-Level Functional Description 113 The functional description of this proposal is as follows: 115 1. an RDAP client finds the authoritative RDAP server using 116 [RFC7484], 118 2. the client sends its query to the authoritative RDAP server, 120 3. the authoritative RDAP server returns an answer as described in 121 [RFC7483] with a reference to the identifier of an entity who has 122 more data for this query, 124 4. The client finds the RDAP server of the entity by either: 126 A. Using a referral URL returned by the server based on the 127 server using this specification, 129 B. Using this specification to find the RDAP server of the 130 entity, based on the entity identifier, 132 5. the client sends the same query to the RDAP server of that 133 entity, 135 6. the server returns an answer as described in [RFC7483], 137 7. the client shows all the information received from both servers. 139 4. Registry of Entity to RDAP server location 141 While it is expected that the RDAP servers will be managed by 142 organizations, this specification uses the term "entity" to support 143 any generic case. This specification defines a registry managed by 144 IANA which maps an entity Id to its RDAP server location (URL). The 145 RDAP server location information description is similar to [RFC7484] 146 so that RDAP client can parse similarly for both registries. 148 5. Identifying the Entity 150 The organization identifier used in the RDAP answer is the key to the 151 entry of the RDAP server registry specified in this document. This 152 key should be unique in the registry. For the specific case of gTLD 153 domain registries, ICANN through IANA has created a registry of gTLD 154 accredited registrars [1]. In that registry, a registrar is 155 identified by a number. For ccTLD domain registries, some registrars 156 may not be in this registry, as they do not need to be accredited by 157 ICANN. In a generic way not related to domain registries, there 158 should be a registry of entities providing a unique number for these 159 entities. IANA already have a registry of organizations identifiers, 160 as numbers, the Private Enterprise Numbers [2] registry, with a 161 policy of first come first serve without any limitation, with easy 162 registration procedure [3], used in multiple contexts for IETF 163 protocols. This document suggests to use this registry for the 164 assignment of unique numbers to entities. Therefore, this document 165 specifies two namespaces for the entity identification: one for 166 accredited gTLD registrars and one from the IANA private enterprise 167 numbers registry. In the case of domain registries where a registrar 168 is not in the first list, that registrar can easily get a unique 169 organization number from the IANA organizations registry in a timely 170 manner. This specification defines a registry which maps an entity 171 id to its RDAP server location (URL). Therefore, the entity id with 172 its namespace creates a unique key to the registry. 174 6. Structure of the Entity to RDAP Server Location Registry 176 The Entity to RDAP Server Location registry, as specified in 177 Section 11 below, have been made available as JSON [RFC7159] objects, 178 which can be retrieved via HTTP from locations specified by IANA. 179 The JSON object for each registry contains a series of members 180 containing metadata about the registry such as a version identifier, 181 a timestamp of the publication date of the registry, and a 182 description. Additionally, a "services" member contains the registry 183 items themselves, as JSON objects. Each object has a key which 184 uniquely defines the entity and the value is an array of its RDAP 185 server URLs. 187 An example structure of the JSON output of the registry is 188 illustrated: 190 { 191 "version": "1.0", 192 "publication": "YYYY-MM-DDTHH:MM:SSZ", 193 "description": "Some text", 194 "services": { 195 "entry1-accregids": 196 [ 197 "https://registrar2.example.com/myrdap/", 198 "http://registrar2.example.com/myrdap/" 199 ], 200 "entry2-pen": 201 [ 202 "https://registrar4.example.com/rdap/" 203 ], 204 "entry3-accregids": 205 [ 206 "https://myregistrar.example.com/rdap/" 207 ] 208 } 209 } 211 The formal syntax is described in Section 7. 213 The "version" corresponds to the format version of the registry. 214 This specification defines version "1.0". 216 The syntax of the "publication" value conforms to the Internet date/ 217 time format [RFC3339]. The value is the latest update date of the 218 registry by IANA. 220 The optional "description" string can contain a comment regarding the 221 content of the registry. 223 Per [RFC7258], in each array of base RDAP URLs, the secure versions 224 of the transport protocol SHOULD be preferred and tried first. For 225 example, if the base RDAP URLs array contains both HTTPS and HTTP 226 URLs, the client SHOULD try the HTTPS version first. 228 Base RDAP URLs MUST have a trailing "/" character because they are 229 concatenated to the various segments defined in [RFC7482]. 231 JSON names MUST follow the format recommendations of [RFC7480]. Any 232 unrecognized JSON object properties or values MUST be ignored by 233 implementations. 235 The syntax of the keys is as follows: 237 o entity: a unsigned integer encoded in ASCII 238 o separator: the 0x2d ASCII hyphen 240 o namespace: either "accregids" for an entity id from the IANA 241 accredited registrar Ids registry or "pen" for an entity id from 242 the IANA Private Enterprise Numbers registry 244 7. Formal Definition 246 This section is the formal definition of the registries. The 247 structure of JSON objects and arrays using a set of primitive 248 elements is defined in [RFC7159]. Those elements are used to 249 describe the JSON structure of the registries. 251 7.1. Imported JSON Terms 253 o OBJECT: a JSON object, defined in Section 4 of [RFC7159] 255 o MEMBER: a member of a JSON object, defined in Section 4 of 256 [RFC7159] 258 o MEMBER-NAME: the name of a MEMBER, defined as a "string" in 259 Section 4 of [RFC7159] 261 o MEMBER-VALUE: the value of a MEMBER, defined as a "value" in 262 Section 4 of [RFC7159] 264 o ARRAY: an array, defined in Section 5 of [RFC7159] 266 o ARRAY-VALUE: an element of an ARRAY, defined in Section 5 of 267 [RFC7159] 269 o STRING: a "string", as defined in Section 7 of [RFC7159] 271 7.2. Registry Syntax 273 Using the above terms for the JSON structures, the syntax of a 274 registry is defined as follows: TBD 276 o rdap-entity2server-registry: an OBJECT containing a MEMBER version 277 and a MEMBER publication, an optional MEMBER description, and a 278 MEMBER services-list 280 o version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a 281 STRING 283 o publication: a MEMBER with MEMBER-NAME "publication" and MEMBER- 284 VALUE a STRING 286 o description: a MEMBER with MEMBER-NAME "description" and MEMBER- 287 VALUE a STRING 289 o services-list: a MEMBER with MEMBER-NAME "services" and 291 o TDB 293 o service-uri-list: an ARRAY, where each ARRAY-VALUE is a service- 294 uri 296 o service-uri: a STRING 298 8. Recursive Referrals 300 This specification does not restrict the use of recursive links. For 301 example, the answer from the additional RDAP server may itself 302 contain reference to other servers, hence the possibility of 303 recursion. However, without limits, this may end up with infinite 304 recursion. Based on its use case, the RDAP client should set a limit 305 on the number of referrals it will follow. In the specific case of 306 thin domain registries with registrars RDAP servers, there should be 307 a limit of 2 levels: the domain registry RDAP server and the 308 registrar RDAP server. 310 9. Merging the Data Received from Multiple RDAP Servers 312 The answer from the additional RDAP server may contain data that 313 overlaps with the answer from the initial authoritative RDAP server. 314 This document does not specify which data should be chosen in case of 315 overlaps or conflicts, since it depends on the use case. In the 316 specific case of thin domain registries with registrars RDAP servers, 317 the data received by all RDAP servers should be additive and shown 318 appropriately to the user. For example, if the domain registry RDAP 319 server answer contains an expiration date for the domain queried, and 320 if the registrar RDAP server answer also contains an expiration date, 321 then the two expiration dates are shown to the user of the RDAP 322 client. 324 10. Security Considerations 326 By providing a method to find an entity RDAP servers, this document 327 helps to ensure that the end users will get the RDAP data from an 328 authoritative source, instead of from rogue sources. The method has 329 the same security properties as the RDAP protocols themselves. The 330 transport used to access the registries can be more secure by using 331 TLS [RFC5246], which IANA supports. 333 Additional considerations on using RDAP are described in [RFC7481]. 335 11. IANA Considerations 337 IANA has created the RDAP Entity to RDAP Server Location Registry, 338 listed below, and made them available as JSON objects. The contents 339 of these registries are described in Section 6 with the formal syntax 340 specified in Section 7. 342 Because this registry will be accessed by software, the download 343 demand may be unusually high compared to normal IANA registries. The 344 technical infrastructure by which registries are published will need 345 to be reviewed and might need to be augmented. 347 Software accessing these registries will depend on the HTTP Expires 348 header field to limit their query rate. It is, therefore, important 349 for that header field to be properly set to provide timely 350 information as the registries change, while maintaining a reasonable 351 load on the IANA servers. 353 The HTTP Content-Type returned to clients accessing these JSON- 354 formatted registries MUST be "application/json", as defined in 355 [RFC7159]. 357 The registry entries may not be sorted. 359 12. Discussion of this draft 361 this is a todo list for the author on topics to be done/resolved, or 362 comments received. This section will disappear when draft is 363 finished. 365 o should this document merge with RFC7484 and become "RFC7484-bis" 367 o identify the exact field the first server refers to the entity 369 o Additional namespaces may be added with updates of this 370 specification. we don't want to setup a registry of namespace, do 371 we? 373 o The process for adding or updating entries in these registries 374 should be defined here 376 alternate structure proposed by James Gould: 378 { 379 "description": "RDAP bootstrap file for registry to registrar referrals", 380 "publication": "2019-02-14T02:00:02Z", 381 "repositories": [ 382 { 383 "id": "ICANN", 384 "description": "ICANN registrar repository for ICANN accredited registrars", 385 "registrars": [ 386 { 387 "id": "292", 388 "description": "MarkMonitor", 389 "url": "https://rdap.markmonitor.com/rdap/" 390 } 391 ] 392 }, 393 { 394 "id": "US", 395 "description": "US registry repository for US registrars", 396 "registrars": [ 397 { 398 "id": "9999", 399 "description": "Example non-ICANN accredited registrar for .US ccTLD", 400 "url": "https://rdap.registrar.example/rdap/" 401 } 402 ] 403 } 404 ] 405 } 407 13. References 409 13.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 417 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 418 . 420 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 421 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 422 2014, . 424 13.2. Informative References 426 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 427 (TLS) Protocol Version 1.2", RFC 5246, 428 DOI 10.17487/RFC5246, August 2008, 429 . 431 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 432 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 433 2014, . 435 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 436 Registration Data Access Protocol (RDAP)", RFC 7480, 437 DOI 10.17487/RFC7480, March 2015, 438 . 440 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 441 Registration Data Access Protocol (RDAP)", RFC 7481, 442 DOI 10.17487/RFC7481, March 2015, 443 . 445 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 446 Protocol (RDAP) Query Format", RFC 7482, 447 DOI 10.17487/RFC7482, March 2015, 448 . 450 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 451 Registration Data Access Protocol (RDAP)", RFC 7483, 452 DOI 10.17487/RFC7483, March 2015, 453 . 455 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 456 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 457 2015, . 459 13.3. URIs 461 [1] https://www.iana.org/assignments/registrar-ids/registrar- 462 ids.xhtml 464 [2] https://www.iana.org/assignments/enterprise-numbers/enterprise- 465 numbers 467 [3] https://pen.iana.org/pen/PenApplication.page 469 Acknowledgements 471 The following people have provided comments and reviews improving the 472 document significantly (in no particular order): Audric Schiltknecht, 473 Julien Bernard, James Gould. 475 Author's Address 477 Marc Blanchet 478 Viagenie 479 246 Aberdeen 480 Quebec, QC G1R 2E1 481 Canada 483 EMail: Marc.Blanchet@viagenie.ca 484 URI: http://viagenie.ca