idnits 2.17.1 draft-ietf-regext-rdap-reverse-search-03.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 (November 3, 2019) is 1630 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: 'RFC6350' is defined on line 311, but no explicit reference was found in the text ** 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 (~~), 2 warnings (==), 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: May 6, 2020 November 3, 2019 7 Registration Data Access Protocol (RDAP) Reverse search capabilities 8 draft-ietf-regext-rdap-reverse-search-03 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. Even if such capabilities, commonly 15 referred as reverse search, respond to some needs not yet readily 16 fulfilled by the current Whois protocol, they have raised concerns 17 from two perspectives: server processing impact and data privacy. 18 Anyway, the impact of the reverse queries on RDAP servers processing 19 is the same as the standard searches and it can be reduced by 20 implementing policies to deal with large result sets, while data 21 privacy risks can be prevented by RDAP access control functionality. 22 In the RDAP context, an entity can be associated to any defined 23 object class. Therefore, a reverse search can be applied to other 24 use cases than the classic domain-entity scenario. This document 25 describes an RDAP search query extension that allows clients to 26 request a reverse search based on the relationship between an object 27 and the associated entities. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 6, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 65 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4 66 3. Implementation Considerations . . . . . . . . . . . . . . . . 5 67 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 68 4.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 6 69 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 9.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Reverse Whois is a service provided by many web applications that 82 allow users to find domain names owned by an individual or a company 83 starting from the owner's details, such as name and email. Even if 84 it has been considered useful for some legal purposes (e.g. 85 uncovering trademark infringements, detecting cybercrime cases), its 86 availability as a standardized Whois capability has been objected for 87 two main reasons, which now don't seem to conflict with an RDAP 88 implementation. 90 The first objection has been caused by the potential risks of privacy 91 violation. However, TLDs community is considering a new generation 92 of Registration Directory Services 93 ([ICANN-RDS1],[ICANN-RDS2],[ICANN-RA]), which provide access to 94 sensitive data under some permissible purposes and according to 95 adequate policies to enforce the requestor accreditation, 96 authentication, authorization, and terms and conditions of data use. 97 It is well known that such security policies are not implemented in 98 Whois ([RFC3912]), while they are in RDAP ([RFC7481]). Therefore, 99 RDAP permits a reverse search implementation complying with privacy 100 protection principles. 102 Another objection to the implementation of a reverse search 103 capability has been connected with its impact on server processing. 104 Since RDAP supports search queries, the impact of both standard and 105 reverse searches is equivalent and can be mitigated by servers 106 adopting ad hoc strategies. Furthermore, the reverse search is 107 almost always performed by specifying an entity role (e.g. 108 registrant, technical contact) and this can contribute to restricting 109 the result set. 111 Reverse searches, such as finding the list of domain names associated 112 with contacts or nameservers may be useful to registrars as well. 113 Usually, registries adopt out-of-band solutions to provide results to 114 registrars asking for reverse searches on their domains. Possible 115 reasons for such requests are: 117 o the loss of synchronization between the registrar database and the 118 registry database; 120 o the need for such data to perform massive EPP ([RFC5730]) updates 121 (e.g. changing the contacts of a set of domains, etc.). 123 Currently, RDAP does not provide any way for a client to search for 124 the collection of domains associated with an entity ([RFC7482]). A 125 query (lookup or search) on domains can return the array of entities 126 related to a domain with different roles (registrant, registrar, 127 administrative, technical, reseller, etc.), but the reverse operation 128 is not allowed. Only reverse searches to find the collection of 129 domains related to a nameserver (ldhName or ip) can be requested. 130 Since an entity can be in relationship with any RDAP object 131 ([RFC7483]), the availability of a reverse search can be common to 132 all resource type path segments defined for search. 134 The protocol described in this specification aims to extend the RDAP 135 query capabilities to enable the reverse search based on the 136 relationship between any object and the associated entities. The 137 extension is implemented by adding new path segments (i.e. search 138 paths) and using a RESTful web service ([REST]). The service is 139 implemented using the Hypertext Transfer Protocol (HTTP) ([RFC7230]) 140 and the conventions described in RFC 7480 ([RFC7480]). 142 1.1. Conventions Used in This Document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2. RDAP Path Segment Specification 150 The new search paths are OPTIONAL extensions of those defined in RFC 151 7482 ([RFC7482]). A generic reverse search path is described by the 152 syntax: 154 {resource-type}/reverse/{role}?{property}= 156 The path segments are defined as in the following: 158 o resource-type: it MUST be one of resource type path segments 159 defined in Section 3.2 of RFC 7482 ([RFC7482]): "domains", 160 "nameservers" or "entities"; 162 o role: it MUST be one of the roles described in Section 10.2.4 of 163 RFC 7483 ([RFC7483]). For role independent reverse searches, the 164 value "entity" MUST be used; 166 o property: it identifies the entity property to be used in matching 167 the search pattern. A pre-defined list of properties includes: 168 fn, handle, email, city, country, cc. The mapping between such 169 properties and the RDAP fields is shown in Table 1. Servers MAY 170 implement additional properties to those defined in this document. 172 Partial string matching is allowed as defined in section 4.1 of RFC 173 7482 ([RFC7482]). 175 +-------------------+--------------------+--------+--------+--------+ 176 | Reverse search | RDAP property | RFC | RFC | RFC | 177 | property | | 7483 | 6350 | 8605 | 178 +-------------------+--------------------+--------+--------+--------+ 179 | handle | handle | 5.1. | | | 180 | fn | vcard fn | | 6.2.1 | | 181 | email | vcard email | | 6.4.2 | | 182 | city | locality in vcard | | 6.3.1 | | 183 | | adr | | | | 184 | country | country name in | | 6.3.1 | | 185 | | vcard adr | | | | 186 | cc | country code in | | | 3.1 | 187 | | vcard adr | | | | 188 +-------------------+--------------------+--------+--------+--------+ 190 Table 1: Mapping between the reverse search properties and the RDAP 191 fields 193 https://example.com/rdap/domains/reverse/technical?handle=CID-40* 195 https://example.com/rdap/domains/reverse/registrant?fn=Bobby* 197 https://example.com/rdap/domains/reverse/registrant?cc=US 199 https://example.com/rdap/entites/reverse/registrar?handle=RegistrarX 201 Figure 1: Examples of reverse search queries 203 The "country" property can be used as an alternative to "cc" when 204 RDAP servers don't include the vCard "cc" parameter ([RFC8605]) in 205 their response. 207 3. Implementation Considerations 209 The implementation of the proposed extension is technically feasible. 210 Both handle and fn are used as standard path segments to search for 211 entities ([RFC7482]). With regards to the other reverse search 212 properties, namely email, city and country code, the impact of their 213 usage on server processing is evaluated to be the same as other 214 existing query capabilities (e.g. wildcard prefixed search pattern) 215 so the risks to degrade the performance or to generate huge result 216 sets can be mitigated by adopting the same policies (e.g. restricting 217 the search functionality, limiting the rate of search requests 218 according to the user profile, truncating and paging the results, 219 returning partial responses). 221 4. Implementation Status 223 NOTE: Please remove this section and the reference to RFC 7942 prior 224 to publication as an RFC. 226 This section records the status of known implementations of the 227 protocol defined by this specification at the time of posting of this 228 Internet-Draft, and is based on a proposal described in RFC 7942 229 ([RFC7942]). The description of implementations in this section is 230 intended to assist the IETF in its decision processes in progressing 231 drafts to RFCs. Please note that the listing of any individual 232 implementation here does not imply endorsement by the IETF. 233 Furthermore, no effort has been spent to verify the information 234 presented here that was supplied by IETF contributors. This is not 235 intended as, and must not be construed to be, a catalog of available 236 implementations or their features. Readers are advised to note that 237 other implementations may exist. 239 According to RFC 7942, "this will allow reviewers and working groups 240 to assign due consideration to documents that have the benefit of 241 running code, which may serve as evidence of valuable experimentation 242 and feedback that have made the implemented protocols more mature. 243 It is up to the individual working groups to use this information as 244 they see fit". 246 4.1. IIT-CNR/Registro.it 248 Responsible Organization: Institute of Informatics and Telematics 249 of National Research Council (IIT-CNR)/Registro.it 250 Location: https://rdap.pubtest.nic.it/ 251 Description: This implementation includes support for RDAP queries 252 using data from the public test environment of .it ccTLD. 253 Level of Maturity: This is a "proof of concept" research 254 implementation. 255 Coverage: This implementation includes all of the features 256 described in this specification. 257 Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 259 5. Privacy Considerations 261 The use of the capability described in this document MUST be 262 compliant with the rules about privacy protection each RDAP provider 263 is subject to. Sensitive registration data MUST be protected and 264 accessible for permissible purposes only. Therefore, RDAP servers 265 MUST provide reverse search only to those requestors who are 266 authorized according to a lawful basis. Some potential users of this 267 capability include registrars searching for their own domains and 268 operators in the exercise of an official authority or performing a 269 specific task in the public interest that is set out in a law. 270 Another scenario consists of permitting reverse searches, which take 271 into account only those entities that have previously given the 272 explicit consent for publishing and processing their personal data. 274 6. Security Considerations 276 Security services required to provide controlled access to the 277 operations specified in this document are described in RFC 7481 278 ([RFC7481]). 280 The specification of the entity role within the reverse search path 281 allows the RDAP servers to implement different authorization policies 282 on a per-role basis. 284 7. IANA Considerations 286 This document has no actions for IANA. 288 8. Acknowledgements 290 The authors would like to acknowledge Tom Harrison, Scott Hollenbeck, 291 Francisco Arias, Gustavo Lozano and Eduardo Alvarez for their 292 contribution to this document. 294 9. References 296 9.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 304 DOI 10.17487/RFC3912, September 2004, 305 . 307 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 308 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 309 . 311 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 312 DOI 10.17487/RFC6350, August 2011, 313 . 315 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 316 Protocol (HTTP/1.1): Message Syntax and Routing", 317 RFC 7230, DOI 10.17487/RFC7230, June 2014, 318 . 320 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 321 Registration Data Access Protocol (RDAP)", RFC 7480, 322 DOI 10.17487/RFC7480, March 2015, 323 . 325 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 326 Registration Data Access Protocol (RDAP)", RFC 7481, 327 DOI 10.17487/RFC7481, March 2015, 328 . 330 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 331 Protocol (RDAP) Query Format", RFC 7482, 332 DOI 10.17487/RFC7482, March 2015, 333 . 335 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 336 Registration Data Access Protocol (RDAP)", RFC 7483, 337 DOI 10.17487/RFC7483, March 2015, 338 . 340 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 341 Code: The Implementation Status Section", BCP 205, 342 RFC 7942, DOI 10.17487/RFC7942, July 2016, 343 . 345 [RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: 346 ICANN Extensions for the Registration Data Access Protocol 347 (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, 348 . 350 9.2. Informative References 352 [ICANN-RA] 353 Internet Corporation For Assigned Names and Numbers, 354 "Registry Agreement", July 2017, 355 . 358 [ICANN-RDS1] 359 Internet Corporation For Assigned Names and Numbers, 360 "Final Report from the Expert Working Group on gTLD 361 Directory Services: A Next-Generation Registration 362 Directory Service (RDS)", June 2014, 363 . 366 [ICANN-RDS2] 367 Internet Corporation For Assigned Names and Numbers, 368 "Final Issue Report on a Next-Generation gTLD RDS to 369 Replace WHOIS", October 2015, 370 . 373 [REST] Fielding, R., "Architectural Styles and the Design of 374 Network-based Software Architectures", 2000, 375 . 378 Appendix A. Change Log 380 00: Initial working group version ported from draft-loffredo-regext- 381 rdap-reverse-search-04 382 01: Updated "Privacy Considerations" section. 383 02: Revised the text. 384 03: Refactored the query model. 386 Authors' Addresses 388 Mario Loffredo 389 IIT-CNR/Registro.it 390 Via Moruzzi,1 391 Pisa 56124 392 IT 394 Email: mario.loffredo@iit.cnr.it 395 URI: http://www.iit.cnr.it 397 Maurizio Martinelli 398 IIT-CNR/Registro.it 399 Via Moruzzi,1 400 Pisa 56124 401 IT 403 Email: maurizio.martinelli@iit.cnr.it 404 URI: http://www.iit.cnr.it