idnits 2.17.1 draft-ietf-regext-rdap-reverse-search-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 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 (October 26, 2020) is 1278 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) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7482 (Obsoleted by RFC 9082) ** Obsolete normative reference: RFC 7483 (Obsoleted by RFC 9083) ** Downref: Normative reference to an Informational RFC: RFC 8605 Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions M. Loffredo 3 Internet-Draft M. Martinelli 4 Intended status: Standards Track IIT-CNR/Registro.it 5 Expires: April 29, 2021 October 26, 2020 7 Registration Data Access Protocol (RDAP) Reverse search capabilities 8 draft-ietf-regext-rdap-reverse-search-05 10 Abstract 12 The Registration Data Access Protocol (RDAP) does not include query 13 capabilities to find the list of domains related to a set of entities 14 matching a given search pattern. In the RDAP context, an entity can 15 be associated to any defined object class. Therefore, a reverse 16 search can be applied to other use cases than the classic domain- 17 entity scenario. This document describes RDAP query extensions that 18 allow servers to provide a reverse search feature based on the 19 relationship between any searchable object and the related entities. 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 April 29, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4 58 3. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Implementation Considerations . . . . . . . . . . . . . . . . 5 60 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 61 5.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 10.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Reverse Whois is a service provided by many web applications that 75 allow users to find domain names owned by an individual or a company 76 starting from the owner's details, such as name and email. Even if 77 it has been considered useful for some legal purposes (e.g. 78 uncovering trademark infringements, detecting cybercrime cases), its 79 availability as a standardized Whois capability has been objected for 80 two main reasons, which now don't seem to conflict with an RDAP 81 implementation. 83 The first objection has been caused by the potential risks of privacy 84 violation. However, TLDs community is considering a new generation 85 of Registration Directory Services [ICANN-RDS1] [ICANN-RDS2] 86 [ICANN-RA], which provide access to sensitive data under some 87 permissible purposes and according to adequate policies to enforce 88 the requestor accreditation, authentication, authorization, and terms 89 and conditions of data use. It is well known that such security 90 policies are not implemented in Whois [RFC3912], while they are in 91 RDAP [RFC7481]. Therefore, RDAP permits a reverse search 92 implementation complying with privacy protection principles. 94 Another objection to the implementation of a reverse search 95 capability has been connected with its impact on server processing. 96 Since RDAP supports search queries, the impact of both standard and 97 reverse searches is equivalent and can be mitigated by servers 98 adopting ad hoc strategies. Furthermore, the reverse search is 99 almost always performed by specifying an entity role (e.g. 100 registrant, technical contact) and this can contribute to restricting 101 the result set. 103 Reverse searches, such as finding the list of domain names associated 104 with contacts or nameservers may be useful to registrars as well. 105 Usually, registries adopt out-of-band solutions to provide results to 106 registrars asking for reverse searches on their domains. Possible 107 reasons for such requests are: 109 o the loss of synchronization between the registrar database and the 110 registry database; 112 o the need for such data to perform massive EPP [RFC5730] updates 113 (e.g. changing the contacts of a set of domains, etc.). 115 Currently, RDAP does not provide any way for a client to search for 116 the collection of domains associated with an entity [RFC7482]. A 117 query (lookup or search) on domains can return the array of entities 118 related to a domain with different roles (registrant, registrar, 119 administrative, technical, reseller, etc.), but the reverse operation 120 is not allowed. Only reverse searches to find the collection of 121 domains related to a nameserver (ldhName or ip) can be requested. 122 Since an entity can be in relationship with any RDAP object 123 [RFC7483], the availability of a reverse search can be common to all 124 resource type path segments defined for search. 126 The protocol described in this specification aims to extend the RDAP 127 query capabilities to enable the reverse search based on the 128 relationship between any object and the associated entities. The 129 extension is implemented by adding new path segments (i.e. search 130 paths) and using a RESTful web service [REST]. The service is 131 implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] 132 and the conventions described in [RFC7480]. 134 1.1. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2. RDAP Path Segment Specification 144 The new search paths are OPTIONAL extensions of those defined in 145 [RFC7482]. A generic reverse search path is described by the syntax: 147 {resource-type}/reverse/{role}?{property}= 149 The path segments are defined as in the following: 151 o resource-type: it MUST be one of resource type path segments 152 defined in Section 3.2 of [RFC7482]: "domains", "nameservers" or 153 "entities"; 155 o role: it MUST be one of the roles described in Section 10.2.4 of 156 [RFC7483]. For role independent reverse searches, the value 157 "entity" MUST be used; 159 o property: it identifies the entity property to be used in matching 160 the search pattern. A pre-defined list of properties includes: 161 fn, handle, email, city, country, cc. The mapping between such 162 properties and the RDAP properties is shown in Table 1. Some of 163 the properties are related to jCard elements [RFC7095] but, being 164 jCard the JSON format for vCard [RFC6350], the corresponding 165 definitions are included in vCard specification. Servers MAY 166 implement additional properties to those defined in this document. 168 Partial string matching is allowed as defined in section 4.1 of 169 [RFC7482]. 171 +-------------------+--------------------+--------+--------+--------+ 172 | Reverse search | RDAP property | RFC | RFC | RFC | 173 | property | | 7483 | 6350 | 8605 | 174 +-------------------+--------------------+--------+--------+--------+ 175 | handle | handle | 5.1. | | | 176 | fn | jCard fn | | 6.2.1 | | 177 | email | jCard email | | 6.4.2 | | 178 | city | locality in jCard | | 6.3.1 | | 179 | | adr | | | | 180 | country | country name in | | 6.3.1 | | 181 | | jCard adr | | | | 182 | cc | country code in | | | 3.1 | 183 | | jCard adr | | | | 184 +-------------------+--------------------+--------+--------+--------+ 186 Table 1: Mapping between the reverse search properties and the RDAP 187 properties 189 https://example.com/rdap/domains/reverse/technical?handle=CID-40* 191 https://example.com/rdap/domains/reverse/registrant?fn=Bobby* 193 https://example.com/rdap/domains/reverse/registrant?cc=US 195 https://example.com/rdap/entites/reverse/registrar?handle=RegistrarX 197 Figure 1: Examples of reverse search queries 199 The "country" property can be used as an alternative to "cc" when 200 RDAP servers don't include the jCard "cc" parameter [RFC8605] in 201 their response. 203 3. RDAP Conformance 205 Servers complying with this specification MUST include the value 206 "reverse_search" in the rdapConformance property of the help response 207 [RFC7483]. The information needed to register this value in the 208 "RDAP Extensions" registry is described in Section 6. 210 4. Implementation Considerations 212 The implementation of the proposed extension is technically feasible. 213 Both handle and fn are used as standard path segments to search for 214 entities [RFC7482]. With regards to the other reverse search 215 properties, namely email, city and country code, the impact of their 216 usage on server processing is evaluated to be the same as other 217 existing query capabilities (e.g. wildcard prefixed search pattern) 218 so the risks to degrade the performance or to generate huge result 219 sets can be mitigated by adopting the same policies (e.g. restricting 220 the search functionality, limiting the rate of search requests 221 according to the user profile, truncating and paging the results, 222 returning partial responses). 224 5. Implementation Status 226 NOTE: Please remove this section and the reference to RFC 7942 prior 227 to publication as an RFC. 229 This section records the status of known implementations of the 230 protocol defined by this specification at the time of posting of this 231 Internet-Draft, and is based on a proposal described in [RFC7942]. 232 The description of implementations in this section is intended to 233 assist the IETF in its decision processes in progressing drafts to 234 RFCs. Please note that the listing of any individual implementation 235 here does not imply endorsement by the IETF. Furthermore, no effort 236 has been spent to verify the information presented here that was 237 supplied by IETF contributors. This is not intended as, and must not 238 be construed to be, a catalog of available implementations or their 239 features. Readers are advised to note that other implementations may 240 exist. 242 According to RFC 7942, "this will allow reviewers and working groups 243 to assign due consideration to documents that have the benefit of 244 running code, which may serve as evidence of valuable experimentation 245 and feedback that have made the implemented protocols more mature. 246 It is up to the individual working groups to use this information as 247 they see fit". 249 5.1. IIT-CNR/Registro.it 251 Responsible Organization: Institute of Informatics and Telematics 252 of National Research Council (IIT-CNR)/Registro.it 253 Location: https://rdap.pubtest.nic.it/ 254 Description: This implementation includes support for RDAP queries 255 using data from the public test environment of .it ccTLD. 256 Level of Maturity: This is a "proof of concept" research 257 implementation. 258 Coverage: This implementation includes all of the features 259 described in this specification. 260 Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 262 6. IANA Considerations 264 IANA is requested to register the following value in the RDAP 265 Extensions Registry: 267 Extension identifier: reverse_search 268 Registry operator: Any 269 Published specification: This document. 270 Contact: IETF 271 Intended usage: This extension describes reverse search query 272 patterns for RDAP. 274 7. Privacy Considerations 276 The use of the capability described in this document MUST be 277 compliant with the rules about privacy protection each RDAP provider 278 is subject to. Sensitive registration data MUST be protected and 279 accessible for permissible purposes only. Therefore, RDAP servers 280 MUST provide reverse search only to those requestors who are 281 authorized according to a lawful basis. Some potential users of this 282 capability include registrars searching for their own domains and 283 operators in the exercise of an official authority or performing a 284 specific task in the public interest that is set out in a law. 286 Another scenario consists of permitting reverse searches, which take 287 into account only those entities that have previously given the 288 explicit consent for publishing and processing their personal data. 290 8. Security Considerations 292 Security services required to provide controlled access to the 293 operations specified in this document are described in [RFC7481]. 295 The specification of the entity role within the reverse search path 296 allows the RDAP servers to implement different authorization policies 297 on a per-role basis. 299 9. Acknowledgements 301 The authors would like to acknowledge Tom Harrison, Scott Hollenbeck, 302 Francisco Arias, Gustavo Lozano and Eduardo Alvarez for their 303 contribution to this document. 305 10. References 307 10.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 315 DOI 10.17487/RFC3912, September 2004, 316 . 318 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 319 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 320 . 322 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 323 DOI 10.17487/RFC6350, August 2011, 324 . 326 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 327 DOI 10.17487/RFC7095, January 2014, 328 . 330 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 331 Protocol (HTTP/1.1): Message Syntax and Routing", 332 RFC 7230, DOI 10.17487/RFC7230, June 2014, 333 . 335 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 336 Registration Data Access Protocol (RDAP)", RFC 7480, 337 DOI 10.17487/RFC7480, March 2015, 338 . 340 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 341 Registration Data Access Protocol (RDAP)", RFC 7481, 342 DOI 10.17487/RFC7481, March 2015, 343 . 345 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 346 Protocol (RDAP) Query Format", RFC 7482, 347 DOI 10.17487/RFC7482, March 2015, 348 . 350 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 351 Registration Data Access Protocol (RDAP)", RFC 7483, 352 DOI 10.17487/RFC7483, March 2015, 353 . 355 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 356 Code: The Implementation Status Section", BCP 205, 357 RFC 7942, DOI 10.17487/RFC7942, July 2016, 358 . 360 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 361 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 362 May 2017, . 364 [RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: 365 ICANN Extensions for the Registration Data Access Protocol 366 (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, 367 . 369 10.2. Informative References 371 [ICANN-RA] 372 Internet Corporation For Assigned Names and Numbers, 373 "Registry Agreement", July 2017, 374 . 377 [ICANN-RDS1] 378 Internet Corporation For Assigned Names and Numbers, 379 "Final Report from the Expert Working Group on gTLD 380 Directory Services: A Next-Generation Registration 381 Directory Service (RDS)", June 2014, 382 . 385 [ICANN-RDS2] 386 Internet Corporation For Assigned Names and Numbers, 387 "Final Issue Report on a Next-Generation gTLD RDS to 388 Replace WHOIS", October 2015, 389 . 392 [REST] Fielding, R., "Architectural Styles and the Design of 393 Network-based Software Architectures", 2000, 394 . 397 Appendix A. Change Log 399 00: Initial working group version ported from draft-loffredo-regext- 400 rdap-reverse-search-04 401 01: Updated "Privacy Considerations" section. 402 02: Revised the text. 403 03: Refactored the query model. 404 04: Keepalive refresh. 405 05: Reorganized "Abstract". Corrected "Conventions Used in This 406 Document" section. Added "RDAP Conformance" section. Changed 407 "IANA Considerations" section. Added references to RFC7095 and 408 RFC8174. Other minor edits. 410 Authors' Addresses 412 Mario Loffredo 413 IIT-CNR/Registro.it 414 Via Moruzzi,1 415 Pisa 56124 416 IT 418 Email: mario.loffredo@iit.cnr.it 419 URI: http://www.iit.cnr.it 420 Maurizio Martinelli 421 IIT-CNR/Registro.it 422 Via Moruzzi,1 423 Pisa 56124 424 IT 426 Email: maurizio.martinelli@iit.cnr.it 427 URI: http://www.iit.cnr.it