doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc3650.txt b/doc/rfc/rfc3650.txt
new file mode 100644
index 0000000..1fbcb59
--- /dev/null
+++ b/doc/rfc/rfc3650.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                             S. Sun
+Request for Comments: 3650                                     L. Lannom
+Category: Informational                                        B. Boesch
+                                                                    CNRI
+                                                           November 2003
+
+
+                        Handle System Overview
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+IESG Note
+
+   Several groups within the IETF and IRTF have discussed the Handle
+   System and its relationship to existing systems of identifiers.  The
+   IESG wishes to point out that these discussions have not resulted in
+   IETF consensus on the described Handle System, nor on how it might
+   fit into the IETF architecture for identifiers.  Though there has
+   been discussion of handles as a form of URI, specifically as a URN,
+   these documents describe an alternate view of how namespaces and
+   identifiers might work on the Internet and include characterizations
+   of existing systems which may not match the IETF consensus view.
+
+Abstract
+
+   This document provides an overview of the Handle System in terms of
+   its namespace and service architecture, as well as its relationship
+   to other Internet services such as DNS, LDAP/X.500, and URNs.  The
+   Handle System is a general-purpose global name service that allows
+   secured name resolution and administration over networks such as the
+   Internet.  The Handle System manages handles, which are unique names
+   for digital objects and other Internet resources.
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Informational                      [Page 1]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Motivations. . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Handle Namespace . . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Handle System Architecture . . . . . . . . . . . . . . . . . .  8
+   5.  Handle System Security . . . . . . . . . . . . . . . . . . . . 11
+   6.  The Handle System and other Internet Services. . . . . . . . . 12
+       6.1.  Domain Name Service (DNS). . . . . . . . . . . . . . . . 13
+       6.2.  Directory Services (X.500/LDAP). . . . . . . . . . . . . 13
+       6.3.  Uniform Resource Identifier (URI)/Uniform Resource Name
+             (URN). . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 15
+       7.1.  General Security Practice. . . . . . . . . . . . . . . . 15
+       7.2.  Privacy Protection . . . . . . . . . . . . . . . . . . . 16
+       7.3.  Caching and Proxy Servers. . . . . . . . . . . . . . . . 16
+       7.4.  Mirroring. . . . . . . . . . . . . . . . . . . . . . . . 17
+       7.5.  Denial of Service (DoS). . . . . . . . . . . . . . . . . 17
+   8.  History of the Handle System . . . . . . . . . . . . . . . . . 18
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
+   10. References and Bibliography. . . . . . . . . . . . . . . . . . 19
+   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
+   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21
+
+1.  Introduction
+
+   This document provides an overview of the Handle System, a
+   distributed information system designed to provide an efficient,
+   extensible, and secured global name service for use on networks such
+   as the Internet.  The Handle System includes an open protocol, a
+   namespace, and a reference implementation of the protocol.  The
+   protocol enables a distributed computer system to store names, or
+   handles, of digital resources and resolve those handles into the
+   information necessary to locate, access, and otherwise make use of
+   the resources.  These associated values can be changed as needed to
+   reflect the current state of the identified resource without changing
+   the handle.  This allows the name of the item to persist over changes
+   of location and other current state information.  Each handle may
+   have its own administrator(s) and administration can be done in a
+   distributed environment.  The Handle System supports secured handle
+   resolution.  Security services such as data confidentiality, data
+   integrity, and non-repudiation are provided upon client request.
+
+   The Handle System provides a confederated name service that allows
+   any existing local namespace to join the global handle namespace by
+   obtaining a unique Handle System naming authority.  Local names and
+   their value-binding(s) remains intact after joining the Handle
+   System.  Any handle request to the local namespace may be processed
+
+
+
+Sun, et al.                  Informational                      [Page 2]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   by a service interface speaking the Handle System protocol.  Combined
+   with the unique naming authority, any local name is guaranteed unique
+   under the global handle namespace.
+
+   There are several services used today to provide name service for
+   Internet resources.  Among these, the Domain Name System (DNS) [2,3]
+   is the most widely used.  DNS is designed "to provide a mechanism for
+   naming resources in such a way that the names are mappable into IP
+   addresses and are usable in different hosts, networks, protocol
+   families, internets, and administrative organizations" [3].  The
+   growth of the Internet has raised demands for various extensions to
+   DNS.  There are also attempts to use DNS as a general-purpose
+   resource naming system.  However, the importance of DNS in basic
+   network routing has led to great caution in implementing any DNS
+   extension or overloading the DNS for general-purpose resource naming.
+   An additional factor which argues against using DNS as a general-
+   purpose naming service is the DNS administrative model.  DNS names
+   are typically managed by the network administrator(s) at the DNS zone
+   level.  There is no provision for per-name administrative structure
+   and no facilities for anyone other than the network administrator to
+   create or manage DNS names.  This is appropriate for domain name
+   administration, but less so for general-purpose resource naming.
+
+   The Handle System has been designed from the start to serve as a
+   general-purpose naming service.  It is designed to accommodate very
+   large numbers of entities and to allow distributed administration
+   over the public Internet.  The Handle System data model allows access
+   control to be defined at the level of each of the data values
+   associated with a given handle.  Each handle can further define its
+   own set of administrators that are independent from the network or
+   host administrator.
+
+   Traditional URLs (Uniform Resource Locators) [4] allow certain
+   Internet resources to be named as a combination of a DNS name and
+   local name.  The local name may be a local file path, or a reference
+   to some local service (e.g., a cgi-bin script).  This combination of
+   a DNS name and a local name provides a flexible administrative model
+   for naming and managing individual Internet resources.  However, the
+   URL practice also has some key limitations.  Most URL schemes (e.g.,
+   http) are defined for resolution only.  Any URL administration has to
+   be done either at the local host, or via some other network service
+   such as NFS.  Using a URL as a name typically ties the Internet
+   resource to its current network location.  For example, a URL will be
+   tied to its local file path when the file path is part of the URL.
+   When the resource moves from one location to another for whatever
+   reason, the URL breaks.  It is especially difficult to work around
+
+
+
+
+
+Sun, et al.                  Informational                      [Page 3]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   this problem when the reason for the location change is change in
+   ownership of an asset, as ownership is generally reflected in the
+   domain name.
+
+   The Handle System is designed to overcome these limitations and to
+   add significant functionality.  Specifically, the Handle System is
+   designed with the following objectives:
+
+      -  Uniqueness: Every handle is globally unique within the Handle
+         System.
+
+      -  Persistence: Handles may be used as persistent identifiers for
+         Internet resources.  A handle does not have to be derived from
+         the entity that it names.  While an existing name, or even a
+         mnemonic, may be included in a handle for convenience, the only
+         operational connection between a handle and the entity it names
+         is maintained within the Handle System.  This of course does
+         not guarantee persistence, which is a function of
+         administrative care.  But it does allow the same name to
+         persist over changes of location, ownership, and other state
+         conditions.  For example, when a named resource moves from one
+         location to another, the handle may be kept valid by updating
+         its value in the Handle System to reflect the new location.
+
+      -  Multiple Instances: A single handle can refer to multiple
+         instances of a resource, at different and possibly changing
+         locations in a network.  Applications can take advantage of
+         this to increase performance and reliability.  For example, a
+         network service may define multiple entry points for its
+         service with a single handle so as to distribute the service
+         load.
+
+      -  Multiple Attributes: A single handle can refer to multiple
+         attributes of a resource, including associated services,
+         available through any method at different and possibly changing
+         network locations.  Handles can thus be used as persistent
+         entry points into an evolving world of services associated with
+         identified resources.
+
+      -  Extensible Namespace: Existing local namespaces may join the
+         handle namespace by acquiring a unique handle naming authority.
+         This allows local namespaces to be introduced into a global
+         context while avoiding conflict with existing namespaces.  Use
+         of naming authorities also allows delegation of service, both
+         resolution and administration, to a local handle service.
+
+
+
+
+
+
+Sun, et al.                  Informational                      [Page 4]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+      -  International Support: The handle namespace is based on Unicode
+         3.0 [17], which includes most of the characters currently used
+         around the world.  This allows handles to be used in any native
+         environment.  The handle protocol mandates UTF-8 [5] as the
+         encoding used for handles.
+
+      -  Distributed Service Model: The Handle System defines a
+         hierarchical service model such that any local handle namespace
+         may be serviced by a corresponding local handle service, by the
+         global service, or by both.  The global service, known as the
+         Global Handle Registry, can be used to dispatch any handle
+         service request to the responsible local handle service.  The
+         distributed service model allows replication of any given
+         service into multiple service sites, and each service site may
+         further distribute its service into a cluster of individual
+         servers.  (Note that local here refers only to namespace and
+         administrative concerns.  A local handle service could in fact
+         have many service sites distributed across the Internet.)
+
+      -  Secured Name Service: The Handle System allows secured name
+         resolution and administration over the public Internet.  The
+         Handle System protocol defines standard mechanisms for both
+         client and server authentication, as well as service
+         authorization.  It also provides security options to assure
+         data integrity and confidentiality.
+
+      -  Distributed Administration Service: Each handle may define its
+         own administrator(s) or administrator group(s).  Ownership of
+         each handle is defined in terms of its administrator or
+         administrator groups.  This, combined with the Handle System
+         authentication protocol, allows any handle to be managed
+         securely over the public network by its administrator at any
+         network location.
+
+      -  Efficient Resolution Service: The handle protocol is designed
+         to allow highly efficient name resolution performance.  To
+         avoid resolution being affected by computationally costly
+         administration service, separate service interfaces (i.e.,
+         server processes and their associated communication ports) for
+         handle name resolution and administration may be defined by any
+         handle service.
+
+   This document provides an overview of the handle namespace and
+   service architecture.  It also compares the Handle System with other
+   existing Internet services, protocols, and specifications (e.g., DNS
+   [2, 3], URLs [4], X.500/LDAP [6,7,8], and URN [9,10]).  Details of
+   the handle system data and service model, as well as its
+   communication protocol, are specified in separate documents.  They
+
+
+
+Sun, et al.                  Informational                      [Page 5]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   can be found under the Handle System website at
+   http://www.handle.net.
+
+2.  Motivations
+
+   Since there are a number of name related projects in the Internet
+   community, it is worth defining exactly where we believe the Handle
+   System fits.  Unfortunately, that is particularly hard because the
+   other primary naming schemes either take an abstract services
+   approach (e.g., URI/URN), or an approach to name resolution absent of
+   a self-contained framework for reliable yet distributed
+   administration of the underlying databases (e.g., DNS).  This makes
+   categorizing the Handle System difficult.
+
+   The Handle System crosses boundaries.  Looked at as a name resolution
+   system, it might be compared to DNS.  If used to implement a URI/URN
+   namespace, it could be used with any URI/URN scheme.  If used for
+   distributed information updates and administration, it could be
+   considered a simplified-version of a distributed database system.
+
+   It is probably best to view the Handle System as a name-attribute
+   binding service with a specific protocol for securely creating,
+   updating, maintaining, and accessing a distributed database.  It is
+   designed to be an enabling service for secured information and
+   resource sharing over networks such as the public Internet.
+   Applications of the Handle System could include meta-data services
+   for digital publications, identity management services for virtual
+   identities, or any other applications that require resolution and/or
+   administration of globally unique identifiers.
+
+   In the spirit of exploration, the Handle System has been designed to
+   have high performance for name resolution and to push the boundaries
+   of distributed access control and administration.  Unlike most
+   conventional systems (even distributed systems) that are designed to
+   have a relatively small number of broadly empowered administrators,
+   the Handle System allows extremely fine granularity of administrative
+   control.  It has a unique self-contained administrative framework
+   that de-couples the ownership of each handle from the system
+   administrators and allows access control to be defined for each
+   handle value.
+
+   It should be noted, that as with all real systems, the Handle System
+   is a compromise between a number of technical and practical concerns.
+   There are also different opinions within the IETF on where the Handle
+   System fits in relation to other existing Internet name services.  It
+   is with the goal of exposing a broader community to the concepts,
+   approach, specific decisions, tradeoffs and results that we are
+   writing this RFC.
+
+
+
+Sun, et al.                  Informational                      [Page 6]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+3.  Handle Namespace
+
+   Every handle consists of two parts: its naming authority, otherwise
+   known as its prefix, and a unique local name under the naming
+   authority, otherwise known as its suffix:
+
+      <Handle> ::= <Handle Naming Authority> "/" <Handle Local Name>
+
+   The naming authority and local name are separated by the ASCII
+   character "/".  The collection of local names under a naming
+   authority defines the local handle namespace for that naming
+   authority.  Any local name must be unique under its local namespace.
+   The uniqueness of a naming authority and a local name under that
+   authority ensures that any handle is globally unique within the
+   context of the Handle System.
+
+   For example, "10.1045/january99-bearman" is a handle for an article
+   published in D-Lib magazine [12].  Its naming authority is "10.1045"
+   and its local name is "january99-bearman".  The handle namespace can
+   be considered a superset of many local namespaces, with each local
+   namespace having a unique naming authority under the Handle System.
+   The naming authority identifies the administrative unit of creation,
+   although not necessarily continuing administration, of the associated
+   handles.  Each naming authority is guaranteed to be globally unique
+   within the Handle System.  Any existing local namespace can join the
+   global handle namespace by obtaining a unique naming authority so
+   that any local name under the namespace can be globally referenced as
+   a combination of the naming authority and the local name as shown
+   above.
+
+   Naming authorities under the Handle System are defined in a
+   hierarchical fashion resembling a tree structure.  Each node and leaf
+   of the tree is given a label that corresponds to a naming authority
+   segment.  The parent node notifies the parent naming authority of its
+   child nodes.  Unlike DNS, handle naming authorities are constructed
+   left to right, concatenating the labels from the root of the tree to
+   the node that represents the naming authority.  Each label is
+   separated by the octet used for ASCII character "." (0x2E).  For
+   example, a naming authority for the National Digital Library Program
+   ("ndlp") at the Library of Congress ("loc") is defined as "loc.ndlp".
+
+   Each naming authority may have many child naming authorities
+   registered underneath.  Any child naming authority can only be
+   registered by its parent after its parent naming authority has been
+   registered.  However, there is no intrinsic administrative
+   relationship between the namespaces represented by the parent and
+   child naming authorities.  The parent namespace and its child
+
+
+
+
+Sun, et al.                  Informational                      [Page 7]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   namespaces may be served by different handle services, and they may
+   or may not share any administration privileges.
+
+   Handles may consist of any printable characters from the Universal
+   Character Set (UCS-2) of ISO/IEC 10646, which is the exact character
+   set defined by Unicode v3.0 [17].  The UCS-2 character set
+   encompasses most characters used in every major language written
+   today.  To allow compatibility with most of the existing systems and
+   to prevent ambiguity among different encodings, the Handle System
+   protocol mandates UTF-8 to be the only encoding used for handles.
+   The UTF-8 encoding preserves any ASCII encoded names so as to allow
+   maximum compatibility with existing systems without causing naming
+   conflict.  Some encoding issues over the global namespace and the
+   choice of UTF-8 encoding are discussed in [13].
+
+   By default, handles are case sensitive.  However, any individual
+   handle service may define its namespace such that ASCII characters
+   within any handle under that namespace are case insensitive.
+
+4.  Handle System Architecture
+
+   The Handle System defines a hierarchical service model.  The top
+   level consists of a single handle service, known as the Global Handle
+   Registry (GHR).  The lower level consists of all other handle
+   services, generically known as Local Handle Services (LHS).
+
+   The Global Handle Registry can be used to manage any handle
+   namespace.  It is unique among handle services only in that it
+   provides the service used to manage naming authorities, all of which
+   are managed as handles.  The naming authority handle provides
+   information that clients can use to access and utilize the local
+   handle service for handles under the naming authority.
+
+   Local Handle Services are intended to be hosted by organizations with
+   administrative responsibility for handles under certain naming
+   authorities.  A Local Handle Service may be responsible for any
+   number of local handle namespaces, each identified by a unique naming
+   authority.  The Local Handle Service and its responsible set of local
+   handle namespaces must be registered with the Global Handle Registry.
+
+   One important aspect of the Handle System is its distributed
+   architecture.  The Handle System as a whole consists of a number of
+   individual handle services.  Each of these services may consist of
+   one or more service sites.  Each service site is a complete
+   replication of every other site in the service in terms of handle
+   resolution.  Each service site may consist of one or more handle
+   servers.  All handles, and hence all handle requests, directed at a
+   given service site will be evenly distributed across these handle
+
+
+
+Sun, et al.                  Informational                      [Page 8]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   servers.  The Handle System as a whole may consist of any number of
+   handle services.  There are no design limits on the number of handle
+   services or on the number of sites which make up each service, nor
+   are there any limits on the number of servers that make up each site.
+   Replication among any service site does not require that each site
+   contain the same number of servers.  In other words, while each site
+   will have the same replicated set of handles, each site may allocate
+   that set of handles across a different number of servers.  This
+   distributed approach is intended to aid scalability, accommodate any
+   large-scale of operation, and mitigate problems of single point
+   failure.
+
+   Figure 3.1 illustrates a potential handle service that consists of
+   two service sites: one located on the U.S. east coast and the other
+   on the U.S. west coast.  The east coast service site consists of four
+   server computers.  The west coast service site, with more powerful
+   computers deployed, decides two servers will suffice.  The number of
+   service sites for any handle service, as well as the number of
+   servers that are used by any service site, may be added or removed
+   dynamically depending on the service requirement.
+
+       -------------------------              ------------------
+      |  ---------   ---------  |            |  -----    -----  |
+      | |         | |         | |            | |  S  |  |  S  | |
+      | | server1 | | server2 | |            | |  E  |  |  E  | |
+      | |         | |         | |            | |  R  |  |  R  | |
+      |  ---------   ---------  |            | |  V  |  |  V  | |
+      |  ---------   ---------  |            | |  E  |  |  E  | |
+      | |         | |         | |            | |  R  |  |  R  | |
+      | | Server3 | | Server4 | |            | |     |  |     | |
+      | |         | |         | |            | |  1  |  |  2  | |
+      |  ---------   ---------  |            |  -----    -----  |
+       -------------------------               ------------------
+
+         Handle Service Site 1                Handle Service Site 2
+            (US East Coast)                     (US West Coast)
+
+       Figure 3.1: Handle service configured with two service sites
+
+   Each handle service manages a distinct sub-namespace under the Handle
+   System.  Namespaces under different handle services may not overlap.
+   The sub-namespace typically consists of handles under a number of
+   naming authorities.  The handle service is called the "home" service
+   of these naming authorities and is the only one that provides
+   resolution and administration service for handles under these naming
+   authorities.  Before resolving a handle, a client has to determine
+   the "home" service of the handle in question.  The "home" service of
+   each handle is the "home" service of its naming authority and is
+
+
+
+Sun, et al.                  Informational                      [Page 9]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   registered at the Global Handle Registry.  Clients can find the
+   "home" service for each handle by querying the naming authority
+   handle at the Global Handle Registry.
+
+   The Global Handle Registry maintains naming authority handles.  Each
+   naming authority handle maintains the service information that
+   describes the "home" service of the naming authority.  The service
+   information lists the service sites of the given handle service, as
+   well as the interface to each handle server within each site.  To
+   find the "home" service for any handle, a client can query the Global
+   Handle Registry for the service information associated with the
+   corresponding naming authority handle.  The service information
+   provides the necessary information for clients to communicate with
+   the "home" service.
+
+   Figure 3.2 shows an example of a typical handle resolution process.
+   In this case, the "home" service is a Local Handle Service.  The
+   client is trying to resolve the handle "10.1045/july95-arms" and has
+   to find its "home" service from the Global Handle Registry.  The
+   "home" service can be found by sending a query to the Global Handle
+   Registry for the naming authority handle for "10.1045".  The Global
+   Handle Registry returns the service information of the Local Handle
+   Service that is responsible for handles under the naming authority
+   "10.1045".  The service information allows the client to communicate
+   with the Local Handle Service to resolve the handle "10.1045/july95-
+   arms".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Informational                     [Page 10]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+       ------------------------
+      |                        |    4. Result of client request
+      | Client with global     |  <-------------------------------.
+      |  service information   |                                  |
+      |                        |  ----------------------------.   |
+       ------------------------     3. Request to responsible |   |
+                 |   ^                 Local Handle Service   |   |
+     1. Client   |   |                                        |   |
+     query for   |   |                                        |   |
+     naming      |   | 2. Service information                 |   |
+     authority   |   |    for "10.1045"                       V   |
+     "10.1045"   |   |                          ----------------------
+                 |   |                         |                      |
+                 V   |                         | Local Handle Service |
+            ---------------                    | responsible for the  |
+           |               |                   | naming authority     |
+           | Global Handle |                   | "10.1045"            |
+           |   Registry    |                   |                      |
+           |               |                    ----------------------
+            ---------------
+
+               Figure 3.2: Handle resolution starting with global
+
+   To improve resolution performance, any client may choose to cache the
+   service information returned from the Global Handle Registry and use
+   it for subsequent queries.  A separate handle caching server, either
+   stand-alone or as a piece of a general caching mechanism, may also be
+   used to provide shared caching within a local community.  Given a
+   cached resolution result, subsequent queries of the same handle may
+   be answered locally without contacting any handle service.  Given
+   cached service information, clients can send their requests directly
+   to the correct Local Handle Service without contacting the Global
+   Handle Registry.
+
+5.  Handle System Security
+
+   The Handle System provides handle resolution and administration
+   service over networks such as the public Internet.  Each handle can
+   be assigned a set of values.  Clients use the handle resolution
+   service to resolve any handle into its set of values.  Each value has
+   a data type and a unique value index.  Clients can query for specific
+   handle values based on data type or value index.
+
+   The handle administration service answers requests from clients to
+   manage handles.  These include adding handles, deleting handles or
+   updating their values.  It also manages naming authorities via naming
+   authority handles.  Each handle can have its own administrator(s),
+   and each administrator can be granted a certain set of permissions.
+
+
+
+Sun, et al.                  Informational                     [Page 11]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   The handle system authentication protocol authenticates the handle
+   administrator before fulfilling any administrative request.
+
+   The Handle System provides security services such as client and
+   server authentication, data confidentiality and integrity, and non-
+   repudiation.  By default, handle resolution does not require any
+   client authentication.  However, resolution requests for confidential
+   data assigned to any handle (by its administrator), as well as any
+   administration requests (e.g., adding or deleting handle values)
+   require authentication of the client for proper authorization.  The
+   server will decide, during the authorization process, whether or not
+   the client has permission to access those confidential handle values,
+   or has permission to add or update handles and handle values.  When
+   authentication is required, the handle server will issue a challenge
+   to the requesting client before carrying out the client's request.
+   To satisfy the authentication requirement, the client must send back
+   the correct response identifying itself as a qualified administrator.
+   The handle server will respond to the initial request only after
+   successful authentication of the client.  Handle clients may choose
+   to use either secret key or public key cryptography for
+   authentication.  Handle System authentication can also be carried out
+   via third party authentication services.  To ensure data integrity,
+   clients may request digitally signed responses from any handle
+   server.  They may also set up secured communication sessions with
+   handle servers so that any exchanged information can be encrypted
+   (for data confidentiality) using a session key.  Handle servers can
+   also provide confidentiality by encrypting the handle data before
+   sending it to the client.
+
+   The Handle System provides service options for secured information
+   exchange between the client and server.  This does not, of course,
+   guarantee the truthfulness of handle values.  Incorrect values
+   assigned to any handle by its administrator may very well mislead
+   clients.  On the other hand, a handle value may contain references to
+   other handle values to provide additional credentials.  For example,
+   a handle value R (e.g., a claim) may contain a reference to some
+   other handle value that contains the digital signature (from a
+   creditable source) upon the value R.  Clients who trust the signature
+   could then trust the handle value R.
+
+6.  The Handle System and other Internet Services
+
+   There are a number of existing and proposed Internet identifier
+   services or specifications that, by design or intent, cover some of
+   the functionalities proposed for the Handle System.  This section
+   briefly reviews them in relationship to the Handle System.
+
+
+
+
+
+Sun, et al.                  Informational                     [Page 12]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+6.1.  Domain Name Service (DNS)
+
+   The Domain Name Service, or DNS, was originally designed and is
+   heavily used for mapping domain names into IP Addresses for network
+   routing purposes.  RFC 1034 [2] and RFC 1035 [3] provide detailed
+   descriptions of its design and implementation.  The growth of the
+   Internet has increased demands for various extensions to DNS, even
+   its possible use as a general purpose resource naming system.
+   However, any such use has the potential to slow down the network
+   address translation and/or affect its effectiveness in network
+   routing.  DNS implementations typically do not scale well when a
+   large amount of data is associated with any particular DNS name.  It
+   is therefore generally considered inappropriate to use DNS as a
+   general-purpose naming service.
+
+   An additional factor that argues against using DNS as a general-
+   purpose naming service is the DNS administrative model.  DNS names
+   are typically managed by the network administrator(s) at the DNS zone
+   level.  There is no provision for a per-name administrative
+   structure.  No facilities are provided for anyone other than network
+   administrators to create or manage DNS names.  This is appropriate
+   for domain name administration but less so for general-purpose name
+   administration.
+
+   The Handle System differs from DNS in its distributed administration
+   and service model, as well as its security features.  The handle
+   system protocol includes security options to assure confidentiality
+   and integrity during data transmission.  Each handle can have its own
+   administrator, independent from the server administrator.  The handle
+   system protocol allows any handle administrator to manage his or her
+   handles securely over the public network.  Additionally, the Handle
+   System service model allows any of its service sites to dynamically
+   configure its service distribution among a cluster of servers to
+   accommodate increased service requests.  This also allows less
+   powerful computers to be used together to support any arbitrarily
+   large number of handles.
+
+6.2.  Directory Services (X.500/LDAP)
+
+   X.500 [6] is the OSI Directory Standard defined by the ISO and the
+   ITU.  It is designed "to provide a white pages service that would
+   return either the telephone numbers or X.400 O/R addresses of
+   people", and is "concerned mainly with providing the name server
+   service for Open Systems Interconnection (OSI) applications" [7].
+   X.500 defines a hierarchical data and information model with a set of
+   protocols to allow global name lookup and search.  The protocol,
+   however, has proved difficult to implement and there has been
+   difficulty in getting "client access integrated into existing
+
+
+
+Sun, et al.                  Informational                     [Page 13]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   products" [14].  LDAP (Lightweight Directory Access Protocol) [8] has
+   overcome many of these difficulties by making the protocol simpler
+   and easier to implement.  Some concern remains, however, that as LDAP
+   is emerging from a local directory access protocol (LDAP v2) into a
+   distributed service protocol (LDAP v3), it faces many issues not
+   addressed in its original design, resulting in new complications.
+
+   The fundamental difference between a name resolution service such as
+   the Handle System, and a directory service such as LDAP, is search
+   capability.  The added functionality of being able to search a
+   directory service necessarily carries with it added complexity, thus
+   affects its efficiency.  A pure name service, such as the Handle
+   System, can be designed solely around efficient resolution of known
+   items without addressing functions and data structures required for
+   discovery of unknown items based on incomplete criteria.
+
+   Directory services, such as LDAP or WHOIS++ [15,16], may be used in
+   tandem with the Handle System to provide reverse lookup service.
+   Existing corporate directory services, for example, could provide
+   interfaces to both services.  The Handle System interface would
+   provide a highly efficient name resolution service.  The directory
+   service interface would provide extended search capability.  Handles
+   could also be used in LDAP service referral.  For example, an LDAP
+   service may be referenced as a handle.  Doing so will make the
+   reference persistent overtime, independent of location change.
+
+6.3.  Uniform Resource Identifier (URI)/Uniform Resource Name(URN)
+
+   Uniform Resource Identifier (URI) [23] defines a uniform, yet
+   extensible naming mechanism for identifying Internet resources in web
+   applications.  Uniform Resource Name (URN) [11], a subset of URI,
+   defines a namespace registration mechanism for persistent namespaces
+   under URI.  URI/URN represents most of the Internet name services
+   used in web applications.  This section discusses the relationship of
+   the Handle System to URI/URN and how applications may utilize the
+   Handle System within the URI/URN context.
+
+   The Handle System provides a general-purpose name service for the
+   Internet.  Like DNS or X.500 directory service, the Handle System
+   defines its namespace outside of any URI/URN namespace.  Handles can
+   be transcribed and resolved directly, without any URI/URN scheme as a
+   prefix.  For example, a library application may resolve the handle
+   "10.1045/july95-arms" directly into its set of handle values.  No
+   URI/URN scheme will be needed in this case.
+
+   The Handle System may be used for applications that require a
+   persistent name service.  The Handle System provides the necessary
+   mechanisms to allow persistent names to be registered as handles.
+
+
+
+Sun, et al.                  Informational                     [Page 14]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   Specific naming authorities may be defined to host those handles
+   designed to be persistent.  However, the persistence of handles
+   depends more on administrative policies than the technology itself.
+   Such policies are beyond the Handle System service, as described in
+   this set of documents.
+
+   On the other hand, the Handle System can also be used for
+   applications where persistent names are not required.  Such handles
+   may have a short life-time and they may also be used to identify
+   different objects at different times.
+
+   Different web applications may be developed using the Handle System
+   as the underlying name service.  Each of these applications may
+   define its own URI/URN namespace for its application needs.  For
+   example, application FOO may have a URI namespace "foo:" registered
+   to identify any FOO services on the web.  In the mean time,
+   application BAR may have a URN namespace "URN:BAR" registered to
+   identify any BAR object that needs a persistent name.  Both FOO and
+   BAR applications may use handles (under their respective naming
+   authority) in naming and resolving to services and/or objects.  This
+   is similar in DNS, where there are different URI schemes (e.g.,
+   "telnet", "ftp", "mailto", etc.) defined for different applications,
+   all using the DNS service.
+
+   The IETF and IRTF have discussed the Handle System in the realm of
+   URI-related work.  There are different opinions on whether the Handle
+   System will fit into a specific URI or URN namespace.  There are also
+   concerns on where the Handle System fits in relation to other
+   existing name services on the Internet.  Such discussions are out of
+   the scope of this document.
+
+7.  Security Considerations
+
+   This section is meant to inform people of security limitations of the
+   Handle System, as well as precautions that should be taken by
+   application developers, service providers, and Handle System clients.
+   Specific security considerations regarding the Handle System protocol
+   [21], as well as its data and service model [22], are addressed in
+   separate documents.
+
+7.1.  General Security Practice
+
+   The security of the Handle System depends on both client and server
+   host security at every step in the transaction.  It assumes the
+   client host has not been tampered with and that client software will
+   reliably convey the received data to the client.  The client of any
+   handle service must also assume that any handle servers involved have
+   not been compromised.  To trust the Global Handle Registry is to
+
+
+
+Sun, et al.                  Informational                     [Page 15]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   believe that the Global Handle Registry will correctly direct the
+   client request to the responsible Local Handle Service.  To trust a
+   Local Handle Service is to believe that the Local Handle Service will
+   correctly return the data that was assigned to the handle by its
+   administrator.  A Local Handle Service typically supports a set of
+   naming authorities.  Thus, trusting a Local Handle Service would
+   imply trusting those naming authorities.
+
+   The integrity of the Handle System depends heavily on the integrity
+   of the global service information.  Invalid global service
+   information may mislead clients into inappropriate Local Handle
+   Services.  It may also allow attackers to forge server signatures.
+   The Global Handle Registry must take extreme caution in protecting
+   the global service information and the public key pair used to sign
+   the global service information.  Client applications should only
+   accept the global service information from the Global Handle
+   Registry.  They should check its integrity upon each update.
+
+   For efficiency reasons, handle servers will not generate or return a
+   digital signature for every service response, unless specifically
+   requested by clients.  To assure data integrity, clients must
+   explicitly ask the server to return the digital signature.  To
+   protect sensitive data from exposure, clients may establish a
+   communication session with the server and ask the server to encrypt
+   any data using the session key.
+
+7.2.  Privacy Protection
+
+   By default, most handle data stored in the Handle System is publicly
+   accessible, unless otherwise specified by the handle administrator.
+   Handle administrators must pay attention when adding handle values
+   that contain private information.  They may choose to mark these
+   handle values readable only by the handle administrator(s), or to
+   store these as encrypted handle values, so that these values can only
+   be read within a controlled audience.
+
+   Log files generated by the handle server are another vulnerable point
+   where client privacy may be under attack.  Operators of handle
+   servers must protect such information carefully.
+
+7.3.  Caching and Proxy Servers
+
+   Besides performance gains and other value-added services, both proxy
+   and caching servers present themselves as men-in-the-middle, and as
+   such are vulnerable to man-in-the-middle attacks.  It is important to
+   know that proxy and caching servers are not part of any handle
+   service.  They are clients of the Handle System.  Service responses
+   from proxy and caching servers cannot be authenticated via the Handle
+
+
+
+Sun, et al.                  Informational                     [Page 16]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   System protocol.  The trust between the client and its immediate
+   proxy/caching server has to be setup independently, regardless of the
+   number of proxy/caching servers that are in the middle of the
+   communication path.
+
+   By using proxy and caching servers, clients assume that the servers
+   will submit their requests and relay any responses from the Handle
+   System without mishandling any of the contents.  They also assume
+   that the servers will protect any sensitive information on their
+   behalf.
+
+   Proxy and caching server operators should protect the systems on
+   which such servers are running as they would protect any system that
+   contains or transports sensitive information.  In particular, log
+   information gathered at proxies often contain highly sensitive
+   personal information, and/or information about organizations.  Such
+   information should be carefully guarded, and appropriate guidelines
+   for their use developed and followed.
+
+   Caching servers provide additional potential vulnerabilities because
+   the contents of the cache represent an attractive target for
+   malicious exploitation.  Potential attacks on the cache can reveal
+   private data for a handle user, or information still kept after a
+   user believes that they have been removed from the network.
+   Therefore, cache contents should be protected as sensitive
+   information.
+
+7.4.  Mirroring
+
+   Handle System clients should be aware of possible delays in content
+   replication among mirroring sites.  They should consider sending
+   their request to the primary service site for any time-sensitive
+   data.  Selection of mirroring sites by service administrators must be
+   done carefully.  Each mirroring site must follow the same security
+   procedures in order to ensure data integrity.  Software tools may be
+   applied to ensure data consistency among mirroring sites.
+
+7.5.  Denial of Service (DoS)
+
+   As with any public service, the Handle System is subject to denial of
+   service attacks.  No general solutions are available to protect
+   against such attacks in today's technology.  Server implementations
+   may be developed to be aware of such attacks and notify
+   administrators when they happen.  Stateless cookies [19, 20] are one
+   means of mitigating some of the effects of DoS attacks on hosts that
+   perform authentication, integrity, and encryption services.  Server
+
+
+
+
+
+Sun, et al.                  Informational                     [Page 17]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   implementations, moreover, need to be upgradeable to take advantage
+   of new security technologies, including anti-DoS technologies as
+   these become available.
+
+8.  History of the Handle System
+
+   The Handle System was originally conceived and developed at CNRI as
+   part of an overall digital object architecture.  The first public
+   implementation was created at CNRI in the fall of 1994 in an effort
+   led by David Ely.  The overall digital object architecture, including
+   the Handle System, was later described in a paper by Robert Kahn and
+   Robert Wilensky [1] in 1995.  Development continued at CNRI as part
+   of the Computer Science Technical Reports (CSTR) project, funded by
+   the Defense Advanced Projects Agency (DARPA) under Grant Number MDA-
+   972-92-J-1029 and MDA-972-99-1-0018.  One aspect of this early
+   digital library project, which was also a major factor in the
+   evolution of the Networked Computer Science Technical Reference
+   Library (NCSTRL) [18] and related activities, was to develop a
+   framework for the underlying infrastructure of digital libraries.
+
+   Early adopters of the Handle System included the Library of Congress,
+   the Defense Technical Information Center (DTIC), and the
+   International DOI Foundation (IDF).  Feedback from these
+   organizations as well as NCSTRL, other digital library projects, and
+   related IETF efforts as mentioned above, have all contributed to the
+   evolution of the Handle System.  The current status and available
+   software, for both client and server, can be found at
+   http://www.handle.net.
+
+9.  Acknowledgements
+
+   This work is derived from the earlier versions of the Handle System
+   implementation.  Design ideas are based on those discussed within the
+   Handle System development team, including David Ely, Charles Orth,
+   Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie Nguyen,
+   Jason Petrone, and Helen She.  Their contributions to this work are
+   gratefully acknowledged.
+
+   The authors also thank Russ Housley (housley@vigilsec.com), Ted
+   Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com)
+   for their extensive review and comments, as well as recommendations
+   received from other members of the IETF/IRTF community.
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Informational                     [Page 18]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+10.  References and Bibliography
+
+   [1]  Kahn, R. and R. Wilensky, "A Framework for Distributed Digital
+        Object Services", D-Lib Magazine, 1995.
+
+   [2]  Mockapetris, P., "Domain Names - Concepts and  Facilities", STD
+        13, RFC 1034, November 1987.
+
+   [3]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", STD 13, RFC 1035, November 1987.
+
+   [4]  Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+        Locators (URL)", RFC 1738, December 1994.
+
+   [5]  Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+        10646", RFC 2044, October 1996.
+
+   [6]  ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models,
+        and Services", 1993.
+
+   [7]  D. W. Chadwick, "Understanding X.500 - The Directory", Chapman &
+        Hall ISBN: 0-412-43020-7.
+
+   [8]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+        Protocol (v3)", RFC 2251, December 1997.
+
+   [9]  Sollins, K. and L. Masinter, "Functional Requirements for
+        Uniform Resource Names", RFC 1737, December 1994.
+
+   [10] Sollins, K. "Architectural Principles of Uniform Resource Name
+        Resolution", RFC 2276, January 1998.
+
+   [11] IETF Uniform Resource Names (URN) Working Group, April 1998.
+
+   [12] D-Lib Magazine, http://www.dlib.org
+
+   [13] Sam X. Sun, "Internationalization of the Handle System - A
+        Persistent Global Name Service", Proceeding of 12th
+        International Unicode Conference, April 1998.
+
+   [14] D. Goodman, C. Robbins, "Understanding LDAP & X.500", August
+        1997.
+
+   [15] Deutsch P., Schoultz R., Faltstrom P. and C. Weider,
+        "Architecture of the WHOIS++ service", RFC 1835, August 1995.
+
+   [16] Weider, C., Fullton, J. and S. Spero, "Architecture of the
+        Whois++ Index Service", RFC 1913, February 1996.
+
+
+
+Sun, et al.                  Informational                     [Page 19]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+   [17] The Unicode Consortium, "The Unicode Standard, Version v3.0",
+        Addison-Wesley Pub Co; ISBN: 0201616335.
+
+   [18] The Networked Computer Science Technical Reports Library
+        (NCSTRL), http://www.ncstrl.org/
+
+   [19] Karn, P. and W. Simpson, "Photuris: Session-Key Management
+        Protocol", RFC 2522, March 1999.
+
+   [20] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
+        RFC 2409, November 1998.
+
+   [21] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and
+        Service Definition", RFC 3651, November 2003.
+
+   [22] Sun, S., Reilly, S., Lannom, L. and J. Petrone, "Handle System
+        Protocol (ver 2.1) Specification", RFC 3652, November 2003.
+
+   [23] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+11.  Authors' Addresses
+
+   Sam X. Sun
+   Corporation for National Research Initiatives (CNRI)
+   1895 Preston White Dr., Suite 100
+   Reston, VA 20191
+
+   Phone: 703-262-5316
+   EMail: ssun@cnri.reston.va.us
+
+
+   Larry Lannom
+   Corporation for National Research Initiatives (CNRI)
+   1895 Preston White Dr., Suite 100
+   Reston, VA 20191
+
+   Phone: 703-620-8990
+   EMail: llannom@cnri.reston.va.us
+
+
+   Brian Boesch
+   Corporation for National Research Initiatives (CNRI)
+   1895 Preston White Dr., Suite 100
+   Reston, VA 20191
+
+   Phone: 703-262-5316
+   EMail: bboesch@cnri.reston.va.us
+
+
+
+Sun, et al.                  Informational                     [Page 20]
+
+RFC 3650                 Handle System Overview            November 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al.                  Informational                     [Page 21]
+