Thanks Bill, Apparently, it's related to <http://gnso.icann.org/issues/whois/whois-service-requirements-initial-report-26mar10-en.pdf> backgrounder to Whois Webinar http://gnso.icann.org/announcements/announcement-09apr10-en.htm Hope not a bit-by-bit chipping away of privacy in the name of 'Law Enforcement'? regards, Alex On Tue, Apr 13, 2010 at 6:49 PM, William Drake <[log in to unmask]> wrote: > The bits on Proxy Registrations or Privacy Services may be of interest... > Bill > > Begin forwarded message: > > From: "Bruce Tonkin" <[log in to unmask]> > Date: April 13, 2010 7:14:15 AM GMT+02:00 > To: "GNSO Council " <[log in to unmask]> > Subject: [council] Law Enforcement Recommend RAA Amendments and ICANN Due > Diligence > > > Not sure where the original law enforcement document was submitted. Below > is what I found at: > > https://st.icann.org/raa-related/index.cgi/LawEnforcementRAArecommendations%20(2).doc?action=attachments_download;page_name=05_january_2010;id=20091118185109-0-21002. > > > Law Enforcement Recommend RAA Amendments and ICANN Due Diligence > > > Introduction: Below are: 1) suggested amendments to the RAA and; 2) due > diligence recommendations for ICANN to adopt in accrediting registrars and > registries. Both are supported by the following international law > enforcement agencies: > > • Australian Federal Police; > • Department of Justice (US); > • Federal Bureau of Investigation (US); > • New Zealand Police; > • Royal Canadian Mounted Police; > • Serious Organised Crime Agency (UK) > > The amendments are considered to be required in order to aid the prevention > and disruption of efforts to exploit domain registration procedures by > Criminal Groups for criminal purposes. The proposed amendments take > account of existing EU, US, Canadian and Australian legislation and those > countries commitment to preserving individual’s rights to privacy. These > amendments would maintain these protections whilst facilitating effective > investigation of Internet related crime. > > > I. Proposed Amendments to the RAA (May 21, 2009 version) > ======================================================== > > 1) The RAA should not explicitly condone or encourage the use of Proxy > Registrations or Privacy Services, as it appears in paragraphs 3.4.1 and > 3.12.4. This goes directly against the Joint Project Agreement (JPA) ICANN > signed with the United States Department of Commerce on September 25, 2006 > which specifically states “ICANN shall continue to enforce existing (Whois) > policy”, i.e., totally open and public WHOIS, and the September 30, 2009, > Affirmation of Commitments, paragraph 9.3.1 which states “ICANN implement > measures to maintain timely, unrestricted and public access to accurate and > complete WHOIS information, including registrant, technical, billing, and > administrative contact information.” Lastly, proxy and privacy registrations > contravene the 2007 GAC Principles on WHOIS. > > If there are proxy and/or privacy domain name registrations, the following > is recommended concerning their use: > > > a. Registrars are to accept proxy/privacy registrations only from ICANN > accredited Proxy Registration Services;1 > > (1: ICANN to implement accreditation system for Proxy Services using the > same stringent checks and assurances as provided in these points, to ensure > that all proxy services used are traceable and can supply correct details of > registrant to relevant authorities.) > > b. Registrants using privacy/proxy registration services will have authentic > WHOIS information immediately published by the Registrar when registrant is > found to be violating terms of service, including but not limited to the use > of false data, fraudulent use, spamming and/or criminal activity. > > > 2) To RAA paragraph 5.3.2.1, language should be added to the effect “or > knowingly and/or through gross negligence permit criminal activity in the > registration of domain names or provision of domain name WHOIS information…” > > > 3) All Accredited Registrars must submit to ICANN accurate and verifiable > contact details of their main operational and physical office location, > including country, phone number (with international prefix), street address, > city, and region, to be publicly disclosed in ICANN web directory. Address > must also be posted clearly on the Registrar's main website. Post Office > boxes, incorporation addresses, mail-drop, and mail-forwarding locations > will not be acceptable. In addition, Registrar must submit URL and location > of Port 43 WHOIS server. > > > 4) Registrars must publicly display of the name of CEO, President, and/or > other responsible officer(s). > > > 5) Registrars with multiple accreditations must disclose and publicly > display on their website parent ownership or corporate relationship, i.e., > identify controlling interests. > > > 6) Registrar must notify ICANN immediately of the following and concurrently > update Registrar website: > > a. any and all changes to a Registrar’s location; > b. changes to presiding officer(s); > c. bankruptcy filing; > d. change of ownership; > e. criminal convictions ; > f. legal/civil actions > > > 7) Registrar should be legal entity within the country of operation, and > should provide ICANN with official certification of business registration or > license. > > > 8) Resellers must be held completely accountable to ALL provisions of the > RAA. Registrars must contractually obligate all its Resellers to comply and > enforce all RAA provisions. The Registrar will be held directly liable for > any breach of the RAA a Reseller commits in which the Registrar does not > remediate immediately. All Registrar resellers and third-party > beneficiaries should be listed and reported to ICANN who shall maintain > accurate and updated records. > > > 9) Registrars and all associated third-party beneficiaries to Registrars are > required to collect and securely maintain the following data (Ref: > Anti-Phishing Working Group (AGWG) “Anti-Phishing Best Practices > Recommendations for Registrars”, October 2008): > > (i) Source IP address > > (ii) HTTP Request Headers > > (a) From > (b) Accept > (c) Accept‐Encoding > (d) Accept‐Language > (e) User‐Agent > (f) Referrer > (g) Authorization > (h) Charge‐To > (i) If‐Modified‐Since > > (iii) Collect and store the following data from registrants: > > (a) First Name: > (b) Last Name: > (c) E‐mail Address: > (d) Alternate E‐mail address > (e) Company Name: > (f) Position: > (g) Address 1: > (h) Address 2: > (i) City: > (j) Country: > (k) State: > (l) Enter State: > (m) Zip: > (n) Phone Number: > (o) Additional Phone: > (p) Fax: > (q) Alternative Contact First Name: > (r) Alternative Contact Last Name: > (s) Alternative Contact E‐mail: > (t) Alternative Contact Phone: > > (iv) Collect data on all additional add‐on services purchased during the > registration process. > > (v) All financial transactions, including, but not limited to credit card, > payment information. > > > 10) Each registrar is required to validate the following data upon receipt > from a registrant Ref: Anti-Phishing Working Group (AGWG) “Anti-Phishing > Best Practices Recommendations for Registrars”, October 2008): > > (1) Technical Data > > (a) IP addresses used to register domain names. > > (b) E‐mail Address > > (i) Verify that registration e‐mail address(es) are valid. > > > (2) Billing Data > > (a) Validate billing data based on the payment card industry (PCI > standards), at a minimum, the latest version of the PCI Data Security > Standard (DSS). > > > (3) Contact Data > > (a) Validate data is being provided by a human by using some anti‐automatic > form submission technology (such as dynamic imaging) to ensure registrations > are done by humans. > > (b) Validate current address WHOIS data and correlate with in‐house > fraudulent data for domain contact information and registrant’s IP address. > > > (4) Phone Numbers > > (i) Confirm that point of contact phone numbers are valid using an automated > system. > > (ii) Cross validate the phone number area code with the provided address and > credit card billing address. > > > > 11) Registrar must provide abuse contact information, including the SSAC SAC > 038 recommendations below (ICANN SSAC SAC 038: Registrar Abuse Point of > Contact, 25 February 2009): > > • Registrars must prominently publish abuse contact information on their > website and WHOIS. > > 1. The registrar identified in the sponsoring registrar field of a Whois > entry should have an abuse contact listed prominently on its web page. To > assist the community in locating this page, registrars should use uniform > naming convention to facilitate (automated and rapid) discovery of this > page, i.e., http://www.<registar>.<TLD>/abuse.html. > > 2. Registrars should provide ICANN with their abuse contact information and > ICANN should publish this information at > http://www.internic.net/regist.html. > > > • The information a registrar publishes for the abuse point of contact > should be consistent with contact details currently proposed as an amendment > to Section 3.16 of the RAA. Each contact method (telephone, email, postal > address) should reach an individual at the Registrar who will be able to > promptly and competently attend to an abuse claim; for example, no contact > should intentionally reject postal or email submissions. > > • Registrars should provide complainants with a well-defined, auditable way > to track abuse complaints (e.g. a ticketing or similar tracking system). > > > 12) ICANN should require Registrars to have a Service Level Agreement for > their Port 43 servers. > > > II. Proposed ICANN Due Diligence on current and new gTLD Registrars and > Registries > ================================================================================== > > a. ICANN to conduct enhanced due diligence on all Registrars and Registries > (including but not limited to owners, officers, board of directors) ICANN > accredits, or has accredited, to include, but not limited to: > > • criminal checks; > • credit checks; > • financial history and solvency; > • corporate/company structure and ownership. > > For example: Dunn and Bradstreet, Lexis-Nexis, Clear, World-Check, etc. > > > b. Such due diligence shall be documented by ICANN, in detail, in a written > report that can be provided upon request to appropriate auditors. > > > c. ICANN should provide complainants with well-defined and auditable way to > track complaints against Registrars and Registries. > > > i. ICANN should publish annual detailed reports of reported complaints. > > d. ICANN should conduct WHOIS compliance audits, at least once a year, and > publish results on: > > i. Port 43 > > ii. WHOIS accuracy > > > > *********************************************************** > William J. Drake > Senior Associate > Centre for International Governance > Graduate Institute of International and > Development Studies > Geneva, Switzerland > [log in to unmask] > www.graduateinstitute.ch/cig/drake.html > *********************************************************** > > >