RFC 3650
Handle System Overview
RFC 3650: Handle System Overview ✨
okay bestie, let's start with the basics 🎀 This is RFC 3650, titled Handle System Overview. It's an Informational doc, so it's sharing info with the Internet community and isn't a standard 💅 It was written by S. Sun, L. Lannom, and B. Boesch, all from CNRI, and it's dated November 2003 🍓 The title block doesn't list any Obsoletes or Updates, so it isn't replacing or changing any other RFC 🦋
Status of this Memo
this doc is giving info to the Internet community, it's not a spec for any kind of Internet standard 🌸 And distribution is totally unlimited, so share away 💜
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
IESG Note
so a bunch of groups inside the IETF and IRTF have been talking about the Handle System and how it fits with other identifier systems 👀 The IESG wants to be super clear that these talks did NOT land on IETF consensus about the Handle System, or about how it could fit into the IETF's identifier architecture 🙈 People have chatted about handles as a kind of URI, specifically as a URN, but these docs describe a different take on how namespaces and identifiers could work on the Internet. They also describe existing systems in ways that might not line up with the IETF consensus view ✨
heads up: this note is important! it means the ideas in here are one perspective, not the official IETF agreement 🫶
Abstract
this doc gives you the overview of the Handle System, covering its namespace and its service architecture 🧚 It also explains how it connects to other Internet services like DNS, LDAP/X.500, and URNs 💖 The Handle System is a general-purpose global name service. It lets you do secured name resolution and administration over networks like the Internet 🔥 It manages handles, which are unique names for digital objects and other Internet resources 🌈
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 . . . . . . . . . . . . . . . . . . . 21Part 1 is done, bestie 🦋 Next up is Section 1, the Introduction, so stay tuned 💜🌈
1. Introduction ✨
okay bestie, so the Handle System is a distributed information system built to be an efficient, extensible, and secured global name service for networks like the Internet 🌐💖. it's got three pieces: an open protocol, a namespace, and a reference implementation of the protocol 💅. the protocol lets a distributed computer system store names (aka handles) for digital resources and resolve those handles into the info needed to locate, access, and otherwise make use of the resources 🧚. the associated values can be changed as needed to reflect the current state of the identified resource, all without changing the handle 🦋. that means the name of the item can persist over changes of location and other current state info, and honestly it's giving stability 🎀. each handle may have its own administrator(s), and administration can be done in a distributed environment 🫶. the Handle System supports secured handle resolution, and security services such as data confidentiality, data integrity, and non-repudiation are provided upon client request 🔥.
the Handle System is also a confederated name service, which is so iconic 👑. any existing local namespace can join the global handle namespace by obtaining a unique Handle System naming authority ✨. local names and their value-binding(s) remains intact after joining, so nothing gets wiped 🙈. any handle request to the local namespace may be processed by a service interface that speaks the Handle System protocol 🌸. combined with the unique naming authority, any local name is guaranteed unique under the global handle namespace. no cap, that's the main character energy of namespaces 💜.
there are a bunch of services used today for name service on Internet resources 🌈. the most widely used one is the Domain Name System (DNS) [2,3] 💅. 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, and there are also attempts to use DNS as a general-purpose resource naming system 👀. however, DNS is so important for basic network routing that people are understandably very cautious about implementing any DNS extension or overloading DNS for general-purpose resource naming 😭. another factor 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's 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 was designed from the start to serve as a general-purpose naming service, and it's built 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. main character handle energy 👑✨.
Traditional URLs (Uniform Resource Locators) [4] let certain Internet resources be named as a combination of a DNS name and a 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 DNS name plus local name combo gives a flexible administrative model for naming and managing individual Internet resources 🎀. but URLs have some key limitations, bestie 😩. most URL schemes (e.g., http) are defined for resolution only, so 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's especially difficult to work around this when the reason for the location change is a change in ownership of an asset, since ownership is generally reflected in the domain name 🥲.
the Handle System is designed to overcome these limitations and to add significant functionality, and it has 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. 🌈
- 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 section gave you the 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]) 🎀. the details of the handle system data and service model, as well as its communication protocol, are specified in separate documents, and you can find them under the Handle System website at http://www.handle.net 🦋💅.
2. Motivations 🔥
okay bestie, first things first: there are a bunch of naming projects floating around the Internet community, so it's crucial to pin down exactly where the Handle System fits 🧚. And honestly? That's the hard part. The other big naming schemes either take a super abstract services approach (think URI/URN 🫶), or they do name resolution without a self-contained framework for reliable yet distributed administration of the underlying databases (hi DNS 👀). So categorizing the Handle System is genuinely tricky, ngl 💀.
The Handle System crosses boundaries 🦋. If you look at it as a name resolution system, it's giving DNS vibes. If it's used to implement a URI/URN namespace, it could work with any URI/URN scheme. And if it's used for distributed information updates and administration, it could be seen as a simplified version of a distributed database system ✨.
The best way to see it, I think, is as a name-attribute binding service with a specific protocol for securely creating, updating, maintaining, and accessing a distributed database 💖. It's built to be an enabling service for secured information and resource sharing over networks like the public Internet 🌸. Apps could include meta-data services for digital publications, identity management for virtual identities, or literally any other app that needs resolution and/or administration of globally unique identifiers 🎀.
In the spirit of exploration (bestie this is so ambitious 😭), the Handle System was designed for high performance name resolution and to push the boundaries of distributed access control and administration 🚀. Most conventional systems, even distributed ones, have a relatively small number of broadly empowered administrators. The Handle System instead 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 access control can be defined for each handle value 💅.
Also, as with all real systems, the Handle System is a compromise between a bunch of technical and practical concerns 🙈. People in the IETF don't all agree on where it fits relative to other existing Internet name services, and that's valid. We're writing this RFC to expose a broader community to the concepts, approach, specific decisions, tradeoffs and results 🌈.
3. Handle Namespace 🦋
Every handle has two parts: its naming authority (aka its prefix) and a unique local name under that naming authority (aka its suffix) 💜:
<Handle> ::= <Handle Naming Authority> "/" <Handle Local Name>The naming authority and local name are split by the ASCII character "/". The local names under a naming authority make up the local handle namespace for that authority. Any local name must be unique within its local namespace. Uniqueness of a naming authority plus a local name under it means any handle is globally unique within 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 is basically a superset of many local namespaces, and each local namespace has its own unique naming authority in the Handle System 🌸. The naming authority tells you the administrative unit that created the handles, though not necessarily who keeps administering them 🤓. Each naming authority is guaranteed to be globally unique within the Handle System 🔒. Any existing local namespace can join the global handle namespace by getting a unique naming authority, so any local name under it can be referenced globally as the naming authority plus local name, like shown above 🫶.
Naming authorities are organised hierarchically, kinda like a tree 🌳. Every node and leaf gets a label that matches a naming authority segment. The parent node tells the parent naming authority about its child nodes. Unlike DNS, handle naming authorities are built left to right, concatenating the labels from the root of the tree down to the node representing the naming authority 🙃. Labels are separated by the octet for the ASCII character "." (0x2E). For example, the naming authority for the National Digital Library Program ("ndlp") at the Library of Congress ("loc") is "loc.ndlp" 📖.
Each naming authority can have many child naming authorities registered underneath it. A child can only be registered by its parent after the parent has been registered 🪜. But the parent and child namespaces don't have any intrinsic administrative relationship. They can be served by different handle services and may or may not share administration privileges 💅.
Handles may use any printable characters from the Universal Character Set (UCS-2) of ISO/IEC 10646, which is exactly the character set defined by Unicode v3.0 [17] 🌍. UCS-2 covers most characters used in every major language written today, which is so iconic 😭. To stay compatible with most existing systems and avoid ambiguity across encodings, the Handle System protocol mandates UTF-8 as the only encoding for handles 🔥. UTF-8 preserves any ASCII-encoded names, so you get max compatibility with existing systems without naming conflicts 💖. Some encoding issues over the global namespace and the choice of UTF-8 are discussed in [13] 🧚.
By default, handles are case sensitive 🙈. But any individual handle service may define its namespace so that ASCII characters within any handle under that namespace are case insensitive 🎀.
Heads up bestie: "case sensitive" is the default, but a handle service is allowed to opt its own namespace into case insensitivity. Always check which rule your service is using 💅
4. Handle System Architecture ✨
okay so the Handle System runs on a hierarchical service model, bestie 🧚 think org chart with a boss at the top. At the very top sits one single handle service, the Global Handle Registry (GHR). Everything below it is a Local Handle Service (LHS), and those make up the lower level 💅.
The GHR can manage any handle namespace. What makes it special is that it's the only handle service that provides the service used to manage naming authorities, and naming authorities are managed as handles too 🤯 iconic. The naming authority handle gives clients the info they need to access and use the local handle service for handles under that naming authority.
LHSes are meant to be hosted by organizations that actually have administrative responsibility for handles under certain naming authorities 🎀. One LHS can be responsible for any number of local handle namespaces, and each one is identified by its own unique naming authority. The LHS and its responsible set of local handle namespaces has to be registered with the GHR 📝.
Now the distributed part, which is honestly my favourite 🦋. The Handle System as a whole is made up of a bunch of individual handle services. Each of those services can have one or more service sites, and each site is a complete replica of every other site in the service when it comes to handle resolution 🌸. Each site can have one or more handle servers, and all the handles (so all the handle requests) aimed at a given site get evenly distributed across those servers. The whole Handle System can have any number of handle services, and there are no design limits on how many services there are, how many sites make up each service, or how many servers make up each site 🌈. Sites don't have to match on server count either. Every site has the same replicated set of handles, but each one can spread that set across a different number of servers. This distributed approach is all about scalability, handling any large-scale operation, and dodging single point of failure drama 💖.
Figure 3.1 shows a potential handle service with two service sites: one on the U.S. east coast and one on the U.S. west coast 🗽. The east coast site has four server computers. The west coast site has more powerful computers, so it decides two servers will be enough 💪. The number of service sites for a handle service, plus the number of servers each site uses, can be added or removed dynamically depending on what the service needs 🔥.
------------------------- ------------------
| --------- --------- | | ----- ----- |
| | | | | | | | 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 sitesEach handle service manages its own distinct sub-namespace under the Handle System, and namespaces under different handle services are not allowed to overlap 🙅♀️. That sub-namespace usually covers handles under a bunch of naming authorities. The handle service is called the "home" service for those naming authorities, and it's the only one that provides resolution and administration for handles under them 🏠. Before resolving a handle, a client has to figure out the "home" service of that handle first. The "home" service of each handle is the "home" service of its naming authority, and that's registered at the Global Handle Registry. Clients can find the "home" service for any handle by querying the naming authority handle at the GHR 🔍.
The GHR keeps the naming authority handles. Each naming authority handle holds the service information that describes the "home" service of that naming authority ✨. The service information lists the service sites of the handle service, plus the interface to each handle server within each site. So to find the "home" service for any handle, a client can ask the GHR for the service information tied to the matching naming authority handle. That info gives the client everything it needs to talk to the "home" service 🫶.
Figure 3.2 shows a typical handle resolution process where the "home" service is a Local Handle Service 🦋. The client wants to resolve the handle 10.1045/july95-arms, so it has to find that handle's "home" service from the GHR. It finds the "home" service by sending a query to the GHR for the naming authority handle for 10.1045. The GHR sends back the service information of the LHS responsible for handles under the naming authority 10.1045. With that info, the client can talk to the LHS and resolve 10.1045/july95-arms 💌.
------------------------
| | 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 globalTo speed up resolution, any client can choose to cache the service information it gets back from the GHR and reuse it for later queries 🚀. A separate handle caching server can also be used for shared caching within a local community, either as a standalone thing or as part of a general caching mechanism 🤝. Once a resolution result is cached, later queries for the same handle can be answered locally without contacting any handle service 🏃♀️. And with cached service information, clients can send their requests straight to the right LHS without going through the GHR at all 😤 efficient.
5. Handle System Security 🔐
okay the security section is where things get serious, so listen up 👀. The Handle System provides handle resolution and administration service over networks like the public Internet 🌐. Each handle can be assigned a set of values. Clients use the resolution service to turn any handle into its set of values. Each value has a data type and a unique value index, and clients can query for specific handle values by data type or by value index 🔍.
The administration service answers client requests to manage handles. That includes adding handles, deleting handles, and updating their values ✏️. It also manages naming authorities through naming authority handles. Each handle can have its own administrator(s), and each administrator can be granted a certain set of permissions 🗝️.
The handle system authentication protocol authenticates the handle administrator before it fulfills any administrative request 🛂. No skipping that step, periodt.
The Handle System offers security services like 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), plus any administration requests (like adding or deleting handle values), do require client authentication so the server can authorize them properly 🔒. During authorization, the server decides whether the client has permission to access those confidential handle values, or to add or update handles and handle values 🧐. When authentication is required, the handle server issues a challenge to the requesting client before it carries out the request. To pass that challenge, the client has to send back the correct response, identifying itself as a qualified administrator 🪪. The handle server only responds to the initial request after the client has been successfully authenticated 🙅♀️. Handle clients can use either secret key or public key cryptography for authentication. Handle System authentication can also be handled through third party authentication services 🤝.
To ensure data integrity, clients can ask for digitally signed responses from any handle server ✍️. They can also set up secured communication sessions with handle servers, so any exchanged information can be encrypted for data confidentiality using a session key 🔑. Handle servers can additionally provide confidentiality by encrypting the handle data before sending it to the client 🎁.
The Handle System gives you service options for secured information exchange between client and server, but that does not, of course, guarantee that handle values are truthful 🙃. Incorrect values assigned to a handle by its administrator may very well mislead clients 😬. On the flip side, a handle value can contain references to other handle values to provide extra credentials 📎. For example, a handle value R (say, a claim) could reference another handle value that holds the digital signature (from a creditable source) on the value R. Clients who trust that signature can then trust the handle value R 💯.
6. The Handle System and other Internet Services 🌍
okay last stop for this part 🧚 There are a bunch of existing and proposed Internet identifier services or specifications that, by design or intent, cover some of the functionality proposed for the Handle System 👀. This section gives a quick look at them in relation to the Handle System 💜.
6.1. Domain Name Service (DNS) 💅
Okay bestie, DNS (Domain Name Service) was originally built for mapping domain names into IP Addresses for network routing, and it is heavily used for that 🌐. RFC 1034 [2] and RFC 1035 [3] give the full tea on its design and implementation 📖. As the Internet grew, people wanted all kinds of extensions to DNS, even its possible use as a general purpose resource naming system 🤔. ngl, any use like that has the potential to slow down network address translation and/or mess with its effectiveness in network routing 😬. DNS implementations usually don't scale well when a huge amount of data is attached to one DNS name 💀. So it's generally considered inappropriate to use DNS as a general-purpose naming service 🙅♀️.
Another reason DNS isn't the move for general-purpose naming is its admin model 🗂️. DNS names are typically managed by network administrators at the DNS zone level. There's no provision for a per-name administrative structure, and no facilities are provided for anyone other than network administrators to create or manage DNS names. That's 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 their handles securely over the public network 🌍. Additionally, the Handle System service model lets any of its service sites dynamically configure its service distribution among a cluster of servers to handle increased service requests 📈. This also means less powerful computers can team up 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 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, though: 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 like the Handle System and a directory service like LDAP is search capability 🔍. The added functionality of being able to search necessarily carries added complexity, which affects efficiency. A pure name service, like the Handle System, can be designed solely around efficient resolution of known items, without addressing the functions and data structures needed 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 ⚡, and 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 over time, 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 📝.
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 meantime, 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 to 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 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 💅
Okay so proxy and caching servers are giving full middleman energy 😭, which means they're open to man-in-the-middle attacks. Performance perks and other value-added stuff aside, proxies and caches are not part of any handle service. They're just clients of the Handle System 🎀. Responses that come back through them can't be authenticated with the Handle System protocol itself ✨. So the trust between you and your immediate proxy or caching server has to be set up on its own, no matter how many proxies or caches are sitting in the communication path 🫶.
When clients use proxies and caches, they're assuming the servers will send their requests and pass along any responses from the Handle System without messing with the contents 👀. They're also assuming the servers will protect any sensitive info on their behalf 🔒.
Proxy and caching server operators should protect their systems the same way they'd protect any system that holds or moves sensitive information 🛡️. Log info collected at proxies can be super sensitive, like highly personal stuff and info about organizations 😳. That data should be carefully guarded, and there should be good guidelines for using it that everyone actually follows 📋.
Caches are an extra-juicy target, ngl 🍯. Since the cache holds stuff, attackers would love to get in and reveal private data about a handle user, or info that's still hanging around after a user thinks they've been removed from the network 💀. So cache contents should be treated as sensitive information, full stop 🔐.
7.4. Mirroring 🪞
Handle System clients should be aware that content can take a little time to replicate across mirroring sites ⏳. For anything time-sensitive, they should consider sending their request to the primary service site 🎯. Service administrators have to pick mirroring sites carefully, no shortcuts 🙅♀️. Each mirroring site must follow the same security procedures so the data stays intact 🔐. Software tools can be used to keep data consistent across the mirrors too ✨.
7.5. Denial of Service (DoS) 🚨
Real talk, the Handle System is a public service, so it's subject to denial of service attacks, same as any other public service 😩. There are no general solutions for stopping these attacks with today's technology 🥲. Server implementations can be built to recognize these attacks and notify administrators when they happen 📣. Stateless cookies [19, 20] are one way to soften some of the damage DoS attacks do to hosts that handle authentication, integrity, and encryption services 🍪. Also, server implementations need to be upgradeable so they can take advantage of new security technologies, including anti-DoS technologies as they become available 🔄.
8. History of the Handle System 📜
The Handle System was first conceived and developed at CNRI as part of a bigger digital object architecture 🌱. The first public implementation came out at CNRI in the fall of 1994, in an effort led by David Ely 🍂. The overall digital object architecture, Handle System included, was later described in a paper by Robert Kahn and Robert Wilensky [1] in 1995 📄. Development kept going at CNRI as part of the Computer Science Technical Reports (CSTR) project, which was funded by the Defense Advanced Projects Agency (DARPA) under Grant Number MDA-972-92-J-1029 and MDA-972-99-1-0018 💰. One part of this early digital library project, which was also a major factor in the evolution of the Networked Computer Science Technical Reports Library (NCSTRL) [18] and related activities, was building 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, plus NCSTRL, other digital library projects, and the related IETF efforts mentioned above, all helped shape the Handle System into what it is now 🙌. You can find the current status and the available client and server software at http://www.handle.net 🌐.
9. Acknowledgements 🫶
This work is derived from earlier versions of the Handle System implementation ✨. The design ideas come from 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 are gratefully acknowledged, bestie 🥹.
The authors also thank Russ Housley (housley@vigilsec.com), Ted Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) for their super thorough review and comments 🙇♀️. They also thank the members of the IETF/IRTF community who sent recommendations 💜.
10. References and Bibliography 📚
Here's the full reference list, every single entry 👀:
[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.
[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 🏢
Meet the squad behind the Handle System, all at CNRI in Reston, VA 💜:
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.us12. Full Copyright Statement ⚖️
Legal time, but it's still important 🙈. The copyright notice and permissions are kept complete and exactly as written below ✨.
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 💖.
📦 where this page comes from
- ietf: rfc3650 2003-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms