Network Working Group C. Malamud Internet-Draft Memory Palace Press Expires: June 1, 2005 December 1, 2004 The iam Service draft-malamud-iam-service-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes the iam service, an alternative to WHOIS. Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Malamud Expires June 1, 2005 [Page 1] Internet-Draft iam December 2004 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Service Definition . . . . . . . . . . . . . . . . . . . . . . 5 3. Service Parameters . . . . . . . . . . . . . . . . . . . . . . 6 4. Discussion (Non-Normative) . . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. ICANN Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 8.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 A. Reference Implementation (Non-Normative) . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 21 Malamud Expires June 1, 2005 [Page 2] Internet-Draft iam December 2004 1. Overview The WHOIS Protocol is used to provide "information about registered domain names" in "human-readable format."[RFC3912] Provision of WHOIS service by registries and registrars is required by ICANN under a mandatory operating agreement.[ICANN-Registrar] Although the WHOIS service provides a simple unformatted interface for the end user, a variety of efforts are used to control the population of that information in databases through a complex interaction between domain name registrants, registrars, and registries.[RFC3707] The purpose of mandating accurate WHOIS information in domain name registries is to provide a contact mechanism and accountability. As such ICANN in their WDRP regulations mandate registrars to remind registrants "that provision of false Whois information can be grounds for cancellation of their domain name registration."[WDRP] The monetary value of the compilation of registrants is a tempting target for direct marketing and ICANN has regulated such use in the WMRP.[WMRP] Accountability of registrants coupled with restrictions on bulk access are thus design goals which are attempted to be met by the WHOIS service. Unfortunately, a complex set of protocols is used to govern the interaction of registrants, registrars, registries, and regulators. This document proposes that this chain of protocols is a good example of "the rise of the middle" and proposes an alternative service based on end-to-end design principles.[RFC3724] Three sets of requirements are intermingled: 1. A method for registrants to provide registrars their contact information for use in registering a domain name and for operational purposes such as maintaining host records, updating billing information, or confirming transfers. The current EPP/CRISP efforts address this requirement. 2. Authorized use of the compilation of names in a registry appears to be in the purview of ICANN and TLD administrators. Unauthorized use of the compilation has proven to be a continuing problem with the current WHOIS-based architecture. 3. A method for members of the public to determine who owns a domain name and how to contact them. The centralized approach to meeting requirement 3, public access, has resulted in unauthorized use of the compilation in requirement 2. Indeed, one could argue that use of a compilation for further marketing of services is not a requirement at all and could be eliminated or moved into a more limited role. However, that issue is Malamud Expires June 1, 2005 [Page 3] Internet-Draft iam December 2004 beyond the scope of the present document. Malamud Expires June 1, 2005 [Page 4] Internet-Draft iam December 2004 2. Service Definition Per the requirements of [RFC3403] the iam service is defined as an NAPTR-based application. The service provides for a single NAPTR-based lookup on a domain name, returning a URI. The "first known domain-name" is thus derived as direct input from the user. The allowed values of the NAPTR fields are as follows: o The Order and Preference fields SHALL be used as specified in [RFC3403]. o The Flags field SHALL always contain the value "U", which signifies that the record is terminal and contains a URI. o The Service field SHALL always start with the string "iam+", followed by exactly one additional service parameter, currently limited to values "opaque" and "rfc2629" as specified in Section 3. o The Regular Expression field SHALL contain a regexp expression which will transform the lookup key into a valid URI as further specified in Section 3. o The Replacement field SHALL contain a valid domain name and is not used in this application. The character "." MAY be used as the string. The expected output of the single rule chosen is the terminal rewrite rule which is always a URL. Malamud Expires June 1, 2005 [Page 5] Internet-Draft iam December 2004 3. Service Parameters An iam application retrieves all NAPTR records conforming to the lookup key, and MUST discard all records where the initial service parameter is not "iam". The field MUST contain a second service parameter, which contains a valid "parameter type" contained in the iam Services Registry as defined in Section 7.1. Two "parameter type" values are defined in this document: o "opaque" o "rfc2629" 3.1 The iam+opaque Service Parameter If the service parameter field contains "iam+opaque", the regular expression will result in a valid URI, limited to the following URI schemes: o "http" as specified in [RFC2616]. o "https" as specified in [RFC2660]. o "ftp" as specified in [RFC0959]. The content of the document retrieved from the URI is not specified in this document. Designers of documents which are retrieved using the iam service are encouraged to vary the content and format of these documents. Documents should be easily viewable by human beings, but there is no requirement for structure that would assist automated applications in harvesting contact information. A simple example is as follows. If the registrant of the "example.com" domain wishes to provide contact information using the iam service, the first step is to construct a valid NAPTR record: example.com. ;; order pref flags service IN NAPTR 100 10 "U" "iam+opaque" "/^.*$/http:\/\/example.com\/contact.html/" . ;; regexp replacement The regular expression will always resolve to the URI "http://example.com/contact.html". The content of this document might be the following: Malamud Expires June 1, 2005 [Page 6] Internet-Draft iam December 2004 Welcome to my contact information

Hi. My name is John Doe and I live here at example.com. If you need to reach me, my username is jdoe and my isp is example.net. My favorite color is blue and you can find more information about me here

3.2 The iam+rfc2629 Service Parameter If the service parameter field contains "iam+rfc2629", the regular expression will result in a valid URI, which will return a document that conforms to the "" as specified in [RFC2629]. As with the "iam+opaque", the set of NAPTR records MUST contain at least one of the "http", "https", or "ftp" URI schemes, but MAY include records of equal "order" with other URI schemes. (Simply put, if you offer an "rsync" resource record, you must also have a resource record with a "basic" URI scheme.) An example of a NAPTR resource record of this type is: example.com. ;; order pref flags service IN NAPTR 100 10 "U" "iam+rfc2629" "/^.*$/https:\/\/example.com\/contact.xml/" . ;; regexp replacement The regular expression will always resolve to the URI "http://example.com/contact.xml". The content of this document might be the following: Malamud Expires June 1, 2005 [Page 7] Internet-Draft iam December 2004 My Contact Information unaffiliated person
jdoe@example.net
Hi - Welcome to my contact information! [RFC2629] requires an anchor attribute on the "" element, but this attribute is not used by the iam service. The "" element SHOULD contain the date this document was last updated. The "", "", and "" elements MAY be used at the discretion of the document designer. 3.3 Multiple NAPTR Responses If a lookup results in multiple NAPTR resource records, an application SHOULD use the following rules in sequence to choose one record: 1. The application MUST discard all resource records where the first characters of the service parameter are not "iam". 2. The application MAY discard all resource records based on the second service parameter. For example, if some resource records are returned with a service parameter field of "iam+rfc2629" and others have "iam+opaque", the application MAY choose which set to process. 3. The application MUST discard all resource records with an Order field higher than the minimum value of the remaining set of resource records. 4. The application SHOULD choose a resource record with a lower Preference value but MAY choose a record with a higher preference value. Malamud Expires June 1, 2005 [Page 8] Internet-Draft iam December 2004 3.4 Use of DNSSEC An application SHOULD verify all DNSSEC signatures as the records are retrieved and SHOULD discard all resource records that fail the verification procedures as outlined in the DNSSEC documents. Malamud Expires June 1, 2005 [Page 9] Internet-Draft iam December 2004 4. Discussion (Non-Normative) Upon being presented with an early draft of this document, Paul Vixie commented that "naptr is pretty hard compared to srv, don't you think?" Upon further prodding he proposed the following solution using the SRV[RFC2782] resource record: $ORIGIN example.com. _whois._tcp SRV 0 1 23 myisp.example.net. SRV 0 3 23 myownbox.example.com. This solution preserves the existing investment in the WHOIS protocol, while still allowing a domain name registrant to specify the location of the relevant WHOIS servers and thus spares the end-user a three-step lookup consisting of: 1. Find the registry for the TLD in question. 2. Query the registry. 3. Query the registrar. The SRV-based approach thus has many of the same attributes as the "iam+rfc2629" of allowing the domain registrant to present structured text with contact information. On the other hand, one of the attractive attributes of the "iam+opaque" service parameter is the very fact that structured text is not necessarily present and thus discourages automated harvesting of contact information. The iam service also eliminates the need for a WHOIS server, a service that may not be present in many common web-hosting environments, which typically offer a LAMP service (Linux, Apache, MySQL, PhP). One argument for the current system of WHOIS information furnished through the registrant/registrar/registry chain is that this somehow provides more accountability and more accurate information. However, repeated investigations have shown that the present system does not do anything to promote such accuracy.[ICANN-Integrity] Creation and registration of a domain name has become confused under the current system with a perceived need for registries and registrants to publish contact information for end users. Allowing domain registrants to provide their own public contact information is a more flexible approach, and can draw on DNSSEC, server certificates, and other existing authentication mechanisms instead of making the domain registration process bear that additional publication burden. Malamud Expires June 1, 2005 [Page 10] Internet-Draft iam December 2004 5. Acknowledgments The author would like to thank the following individuals for comments and suggestions received: Eric Rescorla and Paul Vixie. As always, all errors & omissions remain the responsibility of the author. Malamud Expires June 1, 2005 [Page 11] Internet-Draft iam December 2004 6. Security Considerations This application is only as secure as the DNS on which it is based. The use of DNSSEC as defined in [I-D.ietf-dnsext-dnssec-intro] and related specifications is thus highly recommended in conjunction with this application. In particular, use of the "https" URL scheme without the use of DNSSEC makes the unwarranted illusion of authenticity and the possibility of active attacks a serious concern. Malamud Expires June 1, 2005 [Page 12] Internet-Draft iam December 2004 7. ICANN Considerations 7.1 iam Services Registry As described in Section 3, a new registry is created which lists valid entries for the second service parameters entry in the NAPTR resource record. The registry type, is "Specification Required", meaning that the field "must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible."[RFC2434] The registry contains three fields: o "service parameter" contains an alphanumeric string. o "description" contains a short verbal description. o "reference" contains a reference to an RFC or other archival document meeting the "Specification Required" standard. The initial values of the registry are: Service Parameter Description Reference ================= ================================ ========= opaque The resulting URI has no [RFCXXXX] predefined structure. rfc2629 The resulting URI conforms to [RFCXXXX] the as defined in RFC2629. 7.2 URL Scheme Registration Template Per the requirements of [RFC2717], the "iam" URL scheme is registered under the IETF tree, and should be added to the Official IANA Registry of URI Schemes[IANA-URI] as follows: Scheme Name Description Reference ----------- ----------------------------------------- --------- iam iam service [RFCXXXX] The syntax of the scheme, defined as a subset of the generic components of [RFC2396], modified to conform to [RFC2234] is as follows: Malamud Expires June 1, 2005 [Page 13] Internet-Draft iam December 2004 iam = "iam:" netpath netpath = "//" authority authority = host host = hostname hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = alpha / alpha *( alphanum / "-" ) alphanum alpha = lowalpha / upalpha ; note: domain names are not case sensitive lowalpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" upalpha = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" digit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" alphanum = alpha / digit Additional Considerations Per the Requirements of the Registration Template: o Character encoding considerations are based on the underlying DNS. In particular, non-USASCII names are based on the IDN standards as detailed in [RFC3490], [RFC3491], and [RFC3492]. o The intended usage of this application is to furnish contact information for a domain name. o Applications and/or protocols which will use this URL scheme name are client applications which provide an alternative to WHOIS-based domain name lookup. o Any interoperability considerations are based on the underlying DNS. o Security considerations are discussed in Section 6 of this document. o Contact information is included in this document. o Change control of this scheme will be with the IETF. Malamud Expires June 1, 2005 [Page 14] Internet-Draft iam December 2004 8. References 8.1 Normative References [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660, August 1999. [RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, Malamud Expires June 1, 2005 [Page 15] Internet-Draft iam December 2004 "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C. and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. [RFC3707] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004. [RFC3724] Kempf, J., Austein, R. and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004. [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004. 8.2 Informative References [I-D.ietf-dnsext-dnssec-intro] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-13 (work in progress), October 2004. [IANA-URI] IANA, "Official IANA Registry of URI Schemes", October 2004, . [ICANN-Integrity] Subcommittee on Courts, the Internet, and Intellectual Property, "Accuracy and Integrity of the Whois Database", Committee on the Judiciary, U.S. House of Representatives, Serial No. 70, May 2002, . [ICANN-Registrar] ICANN, "Registrar Accreditation Agreement", Ammended: 25 November 2002, Ammended: 23 January 2003, Ammended: 3 Malamud Expires June 1, 2005 [Page 16] Internet-Draft iam December 2004 April 2003, May 2001, . [WDRP] ICANN, "Whois Data Reminder Policy (WDRP)", June 2003, . [WMRP] ICANN, "Whois Marketing Restriction Policy Policy (WMRP)", August 2004, . Author's Address Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US EMail: carl@media.org Malamud Expires June 1, 2005 [Page 17] Internet-Draft iam December 2004 Appendix A. Reference Implementation (Non-Normative) A set of NAPTR records have been installed in the "simians.net" subdomain and can be retrieved using "dig" or other DNS utilities: [carl@example.com] csh% dig simians.net naptr ;; QUESTION SECTION: ;simians.net. IN NAPTR ;; ANSWER SECTION: simians.net. 86400 IN NAPTR 1 1 "U" "iam+opaque" "!^.*$!http://simians.net/contact.html!" . simians.net. 86400 IN NAPTR 1 1 "U" "iam+invalid" "!^.*$!http://simians.net/contact.html!" . simians.net. 86400 IN NAPTR 1 1 "U" "sip+invalid" "!^.*$!http://simians.net/contact.html!" . simians.net. 86400 IN NAPTR 1 2 "U" "iam+opaque" "!^.*$!http://simians.net/contact.html!" . simians.net. 86400 IN NAPTR 2 1 "U" "iam+opaque" "!^.*$!http://simians.net/contact.html!" . A simple utility written in PERL accepts a lookup key and returns a URL using the specifications in this document: #!/usr/bin/perl use strict; # http://www.net-dns.org/ use Net::DNS; my $target = $ARGV[0]; &usage() if ( $target eq "" ) || ( $target !~ /^[a-zA-Z][a-zA-Z.-]*/ ) || ( $target =~ /help/i ); my $res = Net::DNS::Resolver->new; my $query = $res->query( "$target", "NAPTR" ); if ( !$query ) { warn "Query failed: ", $res->errorstring, "\n"; exit; } my @rr = $query->answer; Malamud Expires June 1, 2005 [Page 18] Internet-Draft iam December 2004 my $order = 9999999; my $pref = 9999999; my $usethis; foreach my $record (@rr) { next unless $record->type eq "NAPTR"; # insert DNSSEC verification here next unless $record->service =~ /iam\+(opaque|rfc2629)/; next unless $record->flags =~ /u/i; if ( $record->order < $order ) { $usethis = $record; } if ( $record->preference < $pref ) { $usethis = $record; } next; } if ($usethis) { # apply the regexp my $regex = $usethis->regexp; my $delim = substr( $regex, 0, 1 ); my ( $left, $right ); $left = $regex; $right = $regex; $left =~ s/^$delim(.*)$delim(.*)$delim$/$1/e; $right =~ s/^$delim(.*)$delim(.*)$delim$/$2/e; $target =~ s/$left/$right/e; print $target ; } else { warn "Query failed. No applicable results found.\n"; } exit(0); sub usage { print STDERR "Usage: $0 domain_name\n"; exit; } Running the code as input to the lynx browser, yields the following results: Malamud Expires June 1, 2005 [Page 19] Internet-Draft iam December 2004 [desktop:~carl/Documents/DNS] carl# lynx -source `./iam.pl simians.net` Meet the Monkeys
bouncy monkey logo
Click Here to Hear My Info
[desktop:~carl/Documents/DNS] carl# Malamud Expires June 1, 2005 [Page 20] Internet-Draft iam December 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Malamud Expires June 1, 2005 [Page 21]