RFC 3651
Handle System Namespace and Service Definition
RFC 3651: Handle System Namespace and Service Definition 🎀
bestie, this RFC is the spec for the Handle System 🌸, which is a global name service for the Internet. Here's the title block, the vibe check on who wrote it, and what it's about:
- RFC number: 3651 ✨
- Authors: S. Sun, S. Reilly, and L. Lannom, all from CNRI 💖
- Category: Informational 📚
- Date: November 2003 🦋
- Obsoletes / Updates: the title block doesn't list any RFCs as obsoleted or updated 🧚
Status of this Memo 💅
okay so this memo gives information to the Internet community 🫶 It is not an Internet standard of any kind, so it's giving "FYI" energy, not "you MUST do this" energy. Distribution of this memo is unlimited, so share the tea 🍓
Copyright Notice 🌈
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
IESG Note 🙈
ngl, this part is a little bit of a plot twist 😭 Several groups inside the IETF and IRTF talked about the Handle System and how it relates to existing identifier systems. The IESG wants to point out that these talks did not reach IETF consensus on the Handle System described here, or on how it would fit into the IETF's architecture for identifiers.
Handles have been discussed as a form of URI, specifically as a URN. These documents describe an alternate take on how namespaces and identifiers could work on the Internet, and they include descriptions of existing systems that may not match the IETF consensus view. So read it with a grain of salt 🧂
Abstract 🔥
The Handle System is a general-purpose global name service that lets you do secured name resolution and administration over the public Internet 👑 This document goes deep on the Handle System namespace and its data, service, and operation models.
The namespace defines the handle syntax and its semantic structure. The data model covers the data structures the Handle System protocol uses, along with any pre-defined data types for the handle service. The service model defines the various Handle System components and how they work together over the network. Last but not least, the operation model describes service operation in terms of messages sent between client and server, plus the client authentication process based on the Handle System authentication protocol 💅
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Handle System Namespace. . . . . . . . . . . . . . . . . . . . 3
3. Handle System Data Model . . . . . . . . . . . . . . . . . . . 4
3.1. Handle Value Set . . . . . . . . . . . . . . . . . . . . 4
3.2. Pre-defined Handle Data Types. . . . . . . . . . . . . . 9
3.2.1. Handle Administrator: HS_ADMIN . . . . . . . . . 10
3.2.2. Service Site Information: HS_SITE. . . . . . . . 14
3.2.3. Naming Authority Delegation Service:
HS_NA_DELEGATE . . . . . . . . . . . . . . . . . 19
3.2.4. Service Handle: HS_SERV. . . . . . . . . . . . . 20
3.2.5. Alias Handle: HS_ALIAS . . . . . . . . . . . . . 21
3.2.6. Primary Site: HS_PRIMARY . . . . . . . . . . . . 21
3.2.7. Handle Value List: HS_VLIST. . . . . . . . . . . 22
4. Handle System Service Model. . . . . . . . . . . . . . . . . . 22
4.1. Handle System Service Components . . . . . . . . . . . . 23
4.1.1. Global Handle Registry (GHR) . . . . . . . . . . 23
4.1.2. Local Handle Service (LHS) . . . . . . . . . . . 26
4.2. Handle System Middle-Ware Components . . . . . . . . . . 27
4.2.1. Handle System Caching Service. . . . . . . . . . 27
4.2.2. Handle System Proxy Server . . . . . . . . . . . 28
4.3. Handle System Client Components. . . . . . . . . . . . . 28
5. Handle System Operation Model. . . . . . . . . . . . . . . . . 29
5.1. Handle System Service Request and Response . . . . . . . 30
5.2. Handle System Authentication Protocol. . . . . . . . . . 32
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
8. References and Bibliography. . . . . . . . . . . . . . . . . . 38
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 411. Introduction ✨
The Handle System manages handles, which are globally unique names for Internet resources 🦋 Robert Kahn and Robert Wilensky first came up with it in a paper back in 1995 [22].
It's a general-purpose global name service that lets handles be resolved and administered securely over the public Internet 💖 The service splits into two categories. First there's handle resolution, which is how clients turn handles into their values. Then there's handle administration, which handles client requests to manage handles, like adding and deleting them or updating handle values 🔥
The document "Handle System Overview" [1] gives the big-picture architecture and explains how the Handle System connects to other Internet services like DNS [2,3] and LDAP[4]. This document is the deep dive into the namespace, the data and service models, and the operation model. It assumes you already know the basics from the overview, so go read that first if you're new bestie 🧚
Here's the lineup. The namespace defines the handle syntax and its semantic structure. The data model defines the data structures used by the protocol and the pre-defined data types for the service. The service model defines the components and how they cooperate over the network. The operation model covers messages between client and server and the client authentication process based on the authentication protocol 💜
2. Handle System Namespace 🌸
Handles are character strings that can use a wide range of characters 🌈 Every handle has two parts: a naming authority, followed by a unique local name under that naming authority. The two are separated by the ASCII character "/" (octet 0x2F) 💅 Here's the handle syntax in ABNF [5]:
<Handle> = <NamingAuthority> "/" <LocalName>
<NamingAuthority> = *(<NamingAuthority> ".") <NAsegment>
<NAsegment> = 1*(%x00-2D / %x30-3F / %x41-FF )
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters except
; octets '0x2E' and '0x2F' (which
; correspond to the ASCII characters '.',
; and '/').
<LocalName> = *(%x00-FF)
; any octets that map to UTF-8 encoded
; Unicode 2.0 characters
Table 2.1: Handle syntaxAs Table 2.1 shows, both <NamingAuthority> and <LocalName> are UTF-8 [6] encoded character strings 🫶 The Handle System protocol mandates UTF-8 encoding for handles sent over the wire. The <LocalName> can contain any characters from the Unicode 2.0 standard [7]. The <NamingAuthority> can also use any Unicode 2.0 characters, except the ASCII "/" (0x2F), since that one's reserved to separate the <NamingAuthority> from the <LocalName> ✨ A <NamingAuthority> can have multiple non-empty <NAsegment>s, each separated by the ASCII "." (octet 0x2E).
Naming authorities are hierarchical, kind of like a family tree 🌳 Every node and leaf in the tree gets a label that matches a naming authority segment (<NAsegment>). The parent node stands for the parent naming authority. You build a naming authority by reading labels left to right, joining them from the root of the tree down to the node in question, with "." (octet 0x2E) between each label. For example, the Digital Object Identifier (DOI) project's naming authority is "10", a root-level one since it has no parent. It can have lots of child naming authorities, though, like "10.1045", which is a child of "10" for the D-Lib Magazine 🍓
By default, handles are case sensitive. But a handle service, global or local, can choose to make its namespace treat ASCII characters as case insensitive. For instance, the global handle service, formally known as the Global Handle Registry (GHR), treats ASCII characters as case insensitive. Since the GHR manages all handles for naming authorities, ASCII characters in naming authorities end up case insensitive too 🙈
3. Handle System Data Model 💖
The Handle System gives you a name-to-value binding service over the public Internet 🔥 Each handle can have a set of values assigned to it. The Handle System keeps track of each handle's value set and returns it whenever someone makes a handle resolution request 💅 The data model defines the conceptual data structure for those values. The data model the protocol uses might not be the exact physical model used for storage in any particular implementation. It's really the model the Handle System protocol follows, as specified in the "Handle System Protocol Specification" [8] 🧚
3.1. Handle Value Set 🦋
Each handle can have a set of values assigned to it. These handle values all share a common data structure 🌈 For example, each handle value has a unique index number that tells it apart from the other values in the set. It also has a specific data type, which defines the syntax and semantics of its data field. On top of that, each handle value holds some administrative info, like its TTL and permissions ✨
Figure 3.1 shows the handle "10.1045/may99-payette" with a set of three handle values 👑 The one with index number 1 is shown in detail. (Heads up, the length encoding for each field isn't shown in Figure 3.1. Also, the empty <reference> field is a 4-byte integer whose value is zero 🙈)
Handle "10.1045/may99-payette"
|
|
V
-------------------------------------------------------------
| <index>: 3 |
------------------------------------------------------------- |
| <index>: 2 | |
------------------------------------------------------------- | |
| | | |
| <index>: 1 | | |
| <type>: URL | | |
| <data>: http://www.dlib.org/dlib... | | |
| <TTL>: {Relative: 24 hours} | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <timestamp>: 927314334000 | | |
| <reference>: {empty} | |-
| |-
-------------------------------------------------------------Part 1 of 10 is a wrap, bestie! 🌈💖 More parts are coming, so stay tuned ✨
In Figure 3.1, the handle value has its index set to 1. 💖 Its data type is URL, and the URL data in the <data> field is "http://www.dlib.org/dlib...". The TTL (time to live) entry says the value record should be cached for no more than 24 hours before the source gets consulted again ⏰. The <permission> field lets anyone read it but only the administrator can update it 🔐. The <reference> field is empty, though it may contain a list of references to other handle values as credentials for this handle value ✨.
So a handle value is basically a record made up of a bunch of data fields 🧚. Here's what each one does:
<index> An unsigned 32-bit integer that uniquely identifies a handle value from other handle values.
<type> A UTF8-string that identifies the data type for the value record. Note that throughout this document, a UTF8-string is defined as a data structure that consists of a 4-byte unsigned integer followed by an UTF-8 encoded character string. The integer specifies the number of octets in the character string.
The <type> field identifies the data type that defines the syntax and semantics of data in the next <data> field. The data type may be registered with the Handle System to avoid potential conflicts. The Handle System has a reserved naming authority "0.TYPE" for registered data types. For example, "URL" (as shown in Figure 3.1) is a registered data type. It is registered as the handle "0.TYPE/URL". The handle may have a value that explains the syntax and semantics of the data type.
Data types under the Handle System may be hierarchical. Each level of the hierarchy may be named in terms of a UTF8-String with no '.' (0x2E) characters. The '.' character is used to mark the boundary between hierarchy levels. For example, the Handle System data type "a.b" may be considered as a sub-type "b" under the type "a". Similarly, handle values of <type> "a.b.x", "a.b.y" and "a.b.z" may be considered as handle values under the common type hierarchy "a.b".
For any handle values, the UTF8-string in the <type> field may not end with the '.' character. In other words, no Handle System data type should end with the '.' character. However, the '.' character may appear in the end of the <type> parameter in a handle query. This is used to query for all handle values under a common type hierarchy. For example, one may query for all handle values under the type hierarchy "a.b" (e.g., handle values of <type> "a.b.x", "a.b.y" and "a.b.z") by setting the <type> parameter to "a.b.". Note here that the <type> parameter ends with the '.' character. Details of the handle query operation can be found in the Handle System protocol specification [8].
<data> A sequence of octets (preceded by its length in a 4-byte unsigned integer) that describes the resource identified by the handle. The syntax and semantics of these octets are identified by the <type> field.
<permission> An eight-bit bit-mask for access control of the handle value. Access control is defined in terms of read, write, and execute permissions, applicable to either general public or handle administrator(s). Each handle value can have its permission field specified as any combination of the following bits:
PUBLIC_WRITE (0x01) permission that allows anyone to modify or delete the handle value.
PUBLIC_READ (0x02) permission that allows anyone to read the handle value.
ADMIN_WRITE (0x04) permission that allows any handle administrator to update or delete the handle value.
ADMIN_READ (0x08)_ permission that allows the handle value to be read by any handle administrator with AUTHORITIVE_READ privilege.
PUBLIC_EXECUTE (0x10) permission that allows anyone to execute the program identified by the handle value on the handle host as anonymous user. Because of the security risks this may have brought up, implementations may choose not to support such permission, or provide options so that it can be disabled at deployment.
ADMIN_EXECUTE (0x20) permission that allows handle administrator(s) to run the program identified by the handle value on the handle server. The handle server must authenticate the handle administrator before executing the program. The handle administrator must have an established account on the handle server. The execution of the handle value should assume the same privilege as the one given to the account for the handle administrator. Because of the security risks this may have brought up, implementations may choose not to support such permission, or provide options so that it can be disabled at deployment.
Note that a handle value with no PUBLIC_READ nor ADMIN_READ permission can not leave the handle server. It may be used, for example, to store secret keys for authentication purposes. A handle value with neither PUBLIC_WRITE nor ADMIN_WRITE permission makes the handle value immutable and cannot be deleted by any handle administrator (via the Handle System protocol).
The administrator for a given handle must specify the permission for each handle value. Implementations may choose PUBLIC_READ and ADMIN_WRITE as the default permission for each handle value. Handle servers must check permissions before fulfilling any client request.
<TTL> An octet followed by a 4-byte integer that specifies the Time-To- Live of the value record. It is used to describe how long the value record can be cached before the source of the information should again be consulted. A zero value for a TTL indicates that the value record should only be used for the transaction in progress and should not be cached. Any non-zero TTL is defined in terms of a TTL type (specified in the first octet), followed by the TTL value (the 32-bit unsigned integer that follows the TTL type). The TTL type indicates whether the TTL value is absolute or relative. The absolute TTL value defines the time to live in terms of seconds since 00:00:00 UTC, January 1st 1970. A relative TTL specifies the time to live in terms of the number of seconds elapsed since the value was obtained by the client from any handle server.
<timestamp> An 8-byte (long) integer that records the last time the value was updated at the server. The field contains elapsed time since 00:00:00 UTC, January 1970 in milliseconds. The choice of milliseconds is to avoid potential collision when updating the value.
<reference> A 4-byte integer followed by a list of references to other handle values. The integer specifies the number of references in the list. Each reference in the list refers to another handle value in terms of a UTF8-string and a 4-byte integer (where the UTF8- string is the handle name and the integer is the value index). References are generally used to add credentials to the current handle value. For example, a handle value may make itself more trust-worthy by referring to a digital signature issued by a commonly trusted entity.
By default, the Handle System returns all the handle values with public-read permission in response to any resolution request 📬. A client can ask for a subset of those values with a specific data type (for example, all URLs assigned to the handle), or ask for one specific handle value by its value index 🎯.
Each handle value can be uniquely referenced by the combination of the handle and its value index 🔗. Be careful when changing the value index, because it may break an existing reference to the handle value 😬. For example, say the handle X/Y has a value whose index is 1. That value may be referred to as X/Y:1. If the handle administrator changes the value index from 1 to 2, the reference to X/Y:1 becomes obsolete, and any reference to the handle value will have to change to X/Y:2 💀.
Value records assigned to any handle may or may not have continuous index numbers 🔢. It can't be assumed that the index starts with 0 or 1 either. A handle administrator may assign a handle value with any index, as long as each index is unique within the value set 🧩.
A handle value may be "privatized" or "disabled" by setting its <permission> field to "authorized-read" 🙈. This limits read access to the handle administrator only. The "privatized" value can then be used to keep historical data (on behalf of the handle administrator) without exposing it to the public 🗄️. This approach may also be used to keep any obsolete handle or naming authority from being reused by accident 🫶.
3.2. Pre-defined Handle Data Types 🎀
Every handle value must have a data type specified in its <type> field 📝. The Handle System provides a type registration service that lets organizations register new data types for their applications 🏷️. Data types can be registered as handles under the naming authority "0.TYPE". For example, the URL data type is registered under the Handle System as the handle 0.TYPE/URL. That handle may have a handle value that refers to RFC1738 [9], an IETF standard document that defines the syntax and semantics of URL 📚.
The Handle System pre-defines a set of data types to carry out the handle service 🌈. For example, HS_ADMIN is a pre-defined data type used to describe handle administrators or administrator groups 👑. HS_SITE is a pre-defined data type that describes the service interface of any Handle System service component ✨. The following sections give detailed descriptions of these pre-defined data types under the Handle System 💅.
3.2.1. Handle Administrator: HS_ADMIN ✨
okay so every handle needs at least one admin 👑 and only an admin with the right privilege can do admin stuff, like adding, deleting, or modifying handle values 🔐. Handle admins are defined by HS_ADMIN values. Each HS_ADMIN value can define a group of admins who share the same privilege, and a handle with admins of different privilege levels can have multiple HS_ADMIN values 🎀. The Handle System uses these values to authenticate admins before it does any admin request. no cap, this is the bouncer 💅
Naming authorities (we just covered them) are registered as handles under the reserved naming authority "0.NA" 🌸. These are called naming authority handles. Whoever administers a naming authority is whoever administers its naming authority handle. So "0.NA/10" is the naming authority handle for the naming authority "10", and any admin for "0.NA/10" is also an admin for "10" 🫶. Only naming authority admins can create handles or sub-naming authorities under it. A sub-naming authority can have its own admins, who can create handles or even more levels of sub-naming authorities. For example, "10.1045" can have a totally separate crew of admins from its parent "10" 🦋
An HS_ADMIN value is a handle value whose <type> field is HS_ADMIN and whose <data> field has these entries:
<AdminRef>: a reference to another handle value. It's made up of the handle name (a UTF8-string) followed by a 4-byte unsigned integer, which is the handle value index. That referenced value tells you which set of admins the handle has 🧚<AdminPermission>: a 16-bit bit-mask that sets the admin privileges for the set of admins that the HS_ADMIN value identifies 💜
The <AdminRef> entry points to a handle value that can be used to authenticate the admin. That value is called the handle administrator reference. It can hold a secret key, a public key, or an X.509 certificate [10] that the admin gave. For example, the <AdminRef> can point to a reference whose <type> is DSS_WITH_DES_CBC_SHA and whose <data> holds a DES secret key [11], used in Cipher Block Chaining (CBC) mode [12, 13]. The handle server can use that secret key to authenticate the admin. If you want stronger crypto, the reference can hold a set of Triple-DES keys [23] and set its <type> to DES-EDE3-WITH-CBC 🔥
A single handle can have both an HS_ADMIN value and its handle administrator reference. So the <AdminRef> can point to a value on that same handle, and then authentication doesn't depend on any other handle at all ✨. Or the reference can be a handle value under a totally different handle. That means HS_ADMIN values from different handles can share one administrator reference, which is a neat way to share admins across handles 🦋. In both cases, the reference holds the secret key, public key, or X.509 certificate that the admin of those handles provided.
A handle administrator reference can also be of type HS_VLIST, and its <data> field is a list of references to other handle values. Each of those values is an administrator reference, and together the HS_VLIST value defines an administrator group 👑. Every reference in the list is a member of that group. Each reference is written as a <handle>:<index> pair. A group can also include other groups as members, so groups can be nested in layers 🌈. Be careful though, because you have to avoid cyclic definitions of admins or admin groups 💀. Multiple levels of admin groups should be avoided because they're inefficient, but the spec won't flag them as an error. Client software should be ready to catch any possible cyclic definitions, and also any <AdminRef> entries that point to handle values that don't exist, and treat those as errors 🙈
A handle can have several HS_ADMIN values, and each one defines a different admin. Different admins can have different roles or different permissions 💅. For example, the naming authority handle "0.NA/10" might have two admins. One can only create new handles under the naming authority, and the other can create new sub-naming authorities like "10.1045" 🎀. These are the permissions an admin can have:
Add_Handle (0x0001): lets a naming authority admin create new handles under a given naming authority.Delete_Handle (0x0002): lets a naming authority admin delete handles under a given naming authority.Add_NA (0x0004): lets the naming authority admin create new sub-naming authorities.Delete_NA (0x0008): lets a naming authority admin delete an existing sub-naming authority.Modify_Value (0x0010): lets a handle admin modify any handle values except HS_ADMIN values. HS_ADMIN values are managed by a different set of permissions 🔒.Delete_Value (0x0020): lets a handle admin delete any handle value except the HS_ADMIN values.Add_Value (0x0040): lets a handle admin add handle values except the HS_ADMIN values.Modify_Admin (0x0080): lets a handle admin modify HS_ADMIN values.Remove_Admin (0x0100): lets a handle admin remove HS_ADMIN values.Add_Admin (0x0200): lets a handle admin add new HS_ADMIN values.Authorized_Read (0x0400): gives a handle admin read access to handle values that have the ADMIN_READ permission. Admins without this permission can't get into handle values that need authentication to read 👀.LIST_Handle (0x0800): lets a naming authority admin list handles under a given naming authority.LIST_NA (0x1000): lets a naming authority admin list the immediate sub-naming authorities under a given naming authority.
Admin permissions live in the <AdminPermission> entry inside the <data> field of any HS_ADMIN value. Each permission is its own bit flag. If the flag is set to 1, the permission is granted. If it's 0, it isn't 🧮
Figure 3.2.1 is an example of an HS_ADMIN value that defines an admin for the naming authority handle "0.NA/10". The admin is identified by an HS_ADMIN value on "0.NA/10". They can be authenticated using the handle value "0.NA/10":3, which is the value on "0.NA/10" with index 3 🌸. That value can hold the secret or public key the admin uses. This admin can add, delete, or modify sub-naming authorities under "10", and can add or delete handles directly under the naming authority. They can also add, delete, or modify any handle values on the naming authority handle, except HS_ADMIN values. So in short, this admin is not allowed to add, delete, or modify any admins for the naming authority 🙅♀️
-------------------------------------------------------------
------------------------------------------------------------- |
------------------------------------------------------------- | |
| | | |
| <index>: 2 | | |
| <type>: HS_ADMIN | | |
| <data>: | | |
| <AdminRef>: "0.NA/10": 3 | | |
| <AdminPerm>: Add_NA, Delete_NA, | | |
| Add Handle, Delete_Handle, | | |
| Add_Value, Delete_Value, Modify_Value, | | |
| Authorized_Read, List_Handle, List_NA | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-------------------------------------------------------------
Figure 3.2.1: Administrator for the naming authority
handle "0.NA/10"HS_ADMIN values are how handle servers check the admin before they do any admin request 🔍. The server authenticates a client by checking whether the client has the secret key (or private key) that matches one of the handle administrator references. The actual authentication happens through the Handle System authentication protocol, which we'll get to later in this document ✨
HS_ADMIN values can require authentication for read access, so the data doesn't get exposed to the public 🙈. Also, a handle administrator reference that holds the admin's secret key should have neither PUBLIC_READ nor ADMIN_READ permission, so the key never leaves the server 🔐
3.2.2. Service Site Information: HS_SITE 🏠
okay so the Handle System is one big distributed global handle service, called the Global Handle Registry (GHR), plus an unlimited number of Local Handle Services (LHSs) 🌍. Every handle service, global or local, can be replicated across multiple service sites, and each service site can run on multiple server computers 🖥️. Service requests aimed at any handle service can be spread across different service sites and across different servers inside each site. This setup means every handle service can handle a massive number of handles and requests, and it avoids any single point of failure 💖 it's giving resilience, honestly 👑
So, every handle service, global or local, can offer the same bundle of resolving and admin tools for its own collection of handles ✨ The big difference is that each service is in charge of a distinct set of handles. They'll also probably vary in how many servers they use, which servers they pick, and how they're set up 🖥️ Different orgs can run different services, and each one can have its own goals and policies 💅
A service site is usually a cluster of server computers sitting inside one local Internet domain 🏠 They team up to share out the storage and processing work. Building a site from servers at super far-apart locations is possible, but it's NOT RECOMMENDED 🙈 And here's the wild part: you can even build two different sites from the exact same set of servers 🤯
Each service site is defined by an HS_SITE value, which is a pre-defined Handle System data type 🎀 An HS_SITE value describes the site by listing the server computers (like their IP addresses) and how each one is configured (like their port numbers) 🧚 HS_SITE values usually get attached to naming authority handles 🦋 The whole set of HS_SITE values on a naming authority handle is called the service information for that naming authority 📝
The naming authority administrator manages the service information, and it MUST reflect how the handle service is configured for that naming authority 👑 Heads up: a service handle is an extra layer of indirection that lets multiple naming authorities point at one shared set of HS_SITE values. We'll get to that later (see section 3.2.3) 🫶 Clients rely on the service information to find the right handle server before they can send any service requests. Clients can also use it to authenticate any service response from that server 🔐
Okay, now the fields 🌈 An HS_SITE value is a handle value whose <type> field is HS_SITE, and whose <data> field has these entries:
<Version>💖 A 2-byte value for the version number of theHS_SITE. The version number tells you which data format theHS_SITEvalue uses, and it exists so things stay backward compatible over time. This document defines theHS_SITEwith version number 0.<ProtocolVersion>✨ A 2-byte integer for the handle protocol version. The higher byte is the major version and the lower byte is the minor version. The details of the Handle System protocol are specified in [8].<SerialNumber>🔢 A 2-byte integer that goes up by 1 (and can wrap around through 0) every time theHS_SITEvalue changes. The Handle System protocol uses it to keepHS_SITEvalues in sync between client and server.<PrimaryMask>🎯 An 8-bit mask that identifies the primary site(s) of the handle service. The first bit of the octet is the<MultiPrimary>bit, which says whether the handle service has multiple primary sites. The second bit is the<PrimarySite>bit, which says whether thisHS_SITEvalue is a primary site. A primary site is the one that supports administrative operations for its handles. If<MultiPrimary>is zero, the handle service has a single primary site, and all handle administration has to be done at that site. If<MultiPrimary>is non-zero, the handle service has multiple primary sites. Each primary site MAY be used to administer handles managed under the service. Handles managed by such a service MAY identify its primary sites using anHS_PRIMARYvalue, as described in section 3.2.5.<HashOption>🧩 An 8-bit octet that picks the hash option the service site uses to spread handles across its servers. The valid options areHASH_BY_NA(0x00),HASH_BY_LOCAL(0x01), orHASH_BY_HANDLE(0x02). These say whether the hash operation SHOULD only be applied to the naming authority portion of the handle, only to the local name portion, or to the entire handle, respectively. The standard MD5 hashing algorithm [14] is what each service site uses to distribute handles among its servers.<HashFilter>🚧 An UTF8-string entry that's reserved for future use.<AttributeList>📚 A 4-byte integer followed by a list of UTF8-string pairs. The integer tells you how many UTF8-string pairs come after it. Each pair is an<attribute>:<value>pair, used to add literal explanations of the service site. For example, if the<attribute>is "Organization", the<value>SHOULD contain a description of the organization hosting the service site. Other<attribute>s may be defined to help tell service sites apart 🏷️<NumOfServer>🖥️ A 4-byte integer that defines how many servers are in the service site. It's followed by a list of<ServerRecord>s, and each<ServerRecord>defines one handle server that's part of the site. Each<ServerRecord>has these data fields:
<ServerRecord> ::= <ServerID>
<Address> <PublicKeyRecord> <ServiceInterface>Here's what each field means 👇
<ServerID>🆔 A 4-byte unsigned integer that uniquely identifies a server process under the service site.<ServerID>s don't have to start at 1, and they don't have to be consecutive numbers either. They're just used to tell the servers in a site apart. There can be multiple servers on any given computer, each with its own<ServerID>.<Address>🌐 The 16-byte IPv6 [15, 16] address of the handle server. Any IPv4 address SHOULD be presented as:::::FFFF:xxxx:xxxx, wherexxxx:xxxxcan be any 4-byte IPv4 address.<PublicKeyRecord>🔑 A 4-byte integer followed by a byte-array that holds the server's public key. The integer gives the size of the byte-array. The byte-array (for the public key) has three parts: a UTF8-string that describes the key type, a two-byte option field reserved for future use, and a byte-array with the public key itself. For example, the UTF8-String "DSA_PUB_KEY" means the<PublicKeyRecord>holds a DSA public key. The storage format of the DSA key in the byte-array can then be found from the handle0.type/DSA_PUB_KEY. The public key in the<PublicKeyRecord>can be used to authenticate any service response from the handle server.
The <PublicKeyRecord> MAY also contain an X.509 certificate. This happens if the key type field contains the UTF8-String "CERT.X509". In that case, "CERT.X509" maps to the handle 0.TYPE/CERT.X509. That handle MAY contain information describing the syntax and semantics of the public key or its certificate. Additional key types MAY also be registered (as handles under 0.TYPE) to tell different kinds of X.509 certificates apart. For example, "CERT.X509.DSA" MAY be used to denote X.509 certificates that contain DSA public keys. If the key type field of a <PublicKeyRecord> declares "CERT.X509.DSA", the <PublicKeyRecord> MUST contain an X.509 certificate with a DSA public key in it. 🎓
<ServiceInterface>🔌 The grammar is:
<ServiceInterface> ::= <InterfaceCounter>
* [ <ServiceType>
<TransmissionProtocol>
<PortNumber> ]That's a 4-byte integer followed by an array of triplets, each made of <ServiceType, TransmissionProtocol, PortNumber>. The 4-byte integer says how many triplets there are. Each triplet lists one service interface the handle server provides. For each triplet, the <ServiceType> is an octet (used as a bit mask) that says whether the interface is for handle resolution (0x01), handle administration (0x02), or both. The <TransmissionProtocol> is also an octet bit mask that picks the transmission protocol. The possible protocols are TCP (0x01), UDP (0x02), and HTTP (0x04). The <PortNumber> is a 4-byte unsigned integer for the port the interface uses. The default port number is 2641 🎉
Now let's look at an example 📸 Figure 3.2.2 shows a handle service site in terms of an HS_SITE value. That value is assigned to the naming authority handle 0.NA/10. The <PrimaryMask> shows it's the only primary site of the handle service. The site has three handle servers, as the <NumOfServer> says. Those servers handle resolution and administration for every handle under naming authority "10". The first server record (ServerID 0) has two service interfaces, one for resolution and one for administration, and each interface gets its own port 💜
Last bit, and it's the part that makes the magic happen ✨ Each server in a service site is responsible for a subset of the handles the service manages, and clients can find the right one with a common hash operation 🪄 The hash operation first converts all ASCII characters in the handle to upper-case. Then it applies MD5 hashing to the portion of the converted handle string picked by the <HashOption> entry. The result is a 16-byte integer. The absolute value of that integer is divided by the number of servers (given in the <NumOfServer> entry). The remainder is the sequence number, starting at zero, of the <ServerRecord> in the HS_SITE value. From that <ServerRecord>, the client can find the IP address of the handle server to send its handle requests to 🫶🌸
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <index>: 2 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 0 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: FALSE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_HANDLE | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 0 {followed by no attributes} | | |
| NumOfServer: 3 | | |
| {followed by a list of <ServerRecord>} | | |
| | | |
| ----------------------------------------- | | |
| ------------------------------------------ | | | |
| ------------------------------------------ || | | |
| | ServerID: 1 ||| | | |
| | Address: :FFFF:132.151.1.155 ||| | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2R... ||| | | |
| | ServiceInterface ||| | | |
| | ServiceType: Resolution_Only ||| | | |
| | TransmissionProtocol: TCP & UDP ||| | | |
| | PortNumber: 2641 ||| | | |
| | ||| | | |
| | ServiceType: Admin only ||| | | |
| | TransmissionProtocol: TCP || | | |
| | PortNumber: 2642 | | | |
| ------------------------------------------ | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-----------------------------------------------------------Fig. 3.2.2: The primary service site for the naming authority "10"
3.2.3. Naming Authority Delegation Service: HS_NA_DELEGATE 🌸
okay so HS_NA_DELEGATE is a pre-defined Handle System data type, and it's giving the exact same format as the HS_SITE value 💅 Just like HS_SITE values, HS_NA_DELEGATE values are used to describe service sites of a LHS ✨
HS_NA_DELEGATE values may be assigned to naming authority handles to designate naming authority administration to a LHS 🦋 A naming authority handle with a set of HS_NA_DELEGATE values means that all child naming authorities of that naming authority are managed by the LHS described by those HS_NA_DELEGATE values. It's lowkey so clean 🫶
For example, say the naming authority "foo.bar" decides to have its child naming authorities delegated to a LHS 🧚 To make that happen, you can assign the naming authority handle 0.NA/foo.bar a set of HS_NA_DELEGATE values that describes the LHS. Those values tell you that the service information for any child naming authority of "foo.bar", such as "foo.bar.baz", can be found by querying the naming authority handle 0.NA/foo.bar.baz from the LHS 😭✨
3.2.4. Service Handle: HS_SERV 🎀
Any handle service, global or local, can be defined in terms of a set of HS_SITE values 💖 These HS_SITE values may be assigned directly to the relevant naming authority handle, or you can add an extra level of indirection by using service handles. Think of a service handle as a name for a handle service 🌈 It can be used to maintain the HS_SITE values for the handle service, and it gets referenced from a naming authority handle via an HS_SERV value. An HS_SERV value is a handle value whose <type> field is HS_SERV and whose <data> field contains the reference to the service handle. HS_SERV values are typically assigned to naming authority handles to refer clients to the responsible handle service, so it's basically a referral system 💅
Using service handles lets service information be shared among multiple naming authorities. It also means changes to service configuration (like adding a new site) can be made in one place instead of in every naming authority handle involved, which is so efficient 🍓 The mechanism may also be used to support service referral from one handle service to another for whatever reason.
A naming authority handle may have no more than one HS_SERV value assigned to it, otherwise it is an error ❌ If a naming authority handle has both a list of HS_SITE values and an HS_SERV value, the HS_SITE values should be used as the service information for the naming authority 👑
Service handles can be registered under the reserved naming authority "0.SERV", and handles under "0.SERV" are managed by the GHR 🦋 For example, the service handle 0.SERV/123 may be created to maintain the service information for the handle service that manages handles under the naming authority "123" and any of its sub-naming authorities. Similarly, a service handle 0.SERV/a.b.c may be created to host the service information for the handle service that manages handles under the naming authority "a.b.c" ✨
The use of service handles raises several special considerations, bestie 🙈 Multiple levels of service handle redirection should be avoided due to their lack of efficiency, but they are not signaled as an error. Looped references of service handles, or HS_SERV values that point to non-existent service handles, should be caught and the error conditions passed back to the user. Not me being dramatic, but this part matters 💀
3.2.5. Alias Handle: HS_ALIAS 🦋
In practice, it is very possible that a digital object has multiple names that identify the object, and the Handle System supports that via the pre-defined data type HS_ALIAS 🌸 An HS_ALIAS value is a handle value whose <type> field is HS_ALIAS and whose <data> field contains a reference to another handle. A handle with an HS_ALIAS value is an alias handle to the handle referenced in that HS_ALIAS value. An alias handle should not have any additional handle values other than HS_ALIAS or HS_ADMIN (for administration) values, because this is necessary to prevent any inconsistency between a handle and its aliases 🔥
During handle resolution, a client may get back an HS_ALIAS value. That means the handle in question is an alias handle, so the client may then retry the query against the handle specified in the HS_ALIAS value until it gets final results ✨
Alias handles come with their own special considerations too 🙈 For example, multiple levels of aliases should be avoided for the sake of efficiency, but they are not signaled as an error. Alias loops, and aliases that point to non-existent handles, should be caught and the error conditions passed back to the user.
One potential use of an alias handle is supporting the transfer of ownership of any named resource, and this is honestly iconic 👑 When a resource identified by a handle transfers from one organization to another, a new handle for the resource may be created. To avoid inconsistency and any broken references, the handle used before the ownership transfer may be changed into an alias handle, pointing its HS_ALIAS value to the newly created handle 🫶
3.2.6. Primary Site: HS_PRIMARY 💜
HS_PRIMARY is a pre-defined data type used to designate the primary service sites for any given handle 🧚 A handle service with multiple primary service sites is called a multi-primary service. Otherwise it is called a single-primary service. Each handle managed by a multi-primary handle service may specify its primary service sites in terms of an HS_PRIMARY value. An HS_PRIMARY value is a handle value whose <type> field is HS_PRIMARY and whose <data> field contains a list of references to HS_SITE values, and each of those HS_SITE values defines a primary service site for the handle 🌈
There can be at most one HS_PRIMARY value assigned to each handle, otherwise it is an error. A handle with no HS_PRIMARY value but managed by a multi-primary handle service is not an error. In this case, every primary service site of the handle service will also be the primary site for the handle 🍓 Handles managed by a single-primary handle service do not need any HS_PRIMARY values, and any such values should be ignored 💅
3.2.7. Handle Value List: HS_VLIST 🎀
HS_VLIST is a pre-defined data type that lets a handle value be used as a reference to a list of other handle values 💖 An HS_VLIST value is a handle value whose <type> is HS_VLIST and whose <data> consists of a 4-byte unsigned integer followed by a list of references to other handle values. The integer specifies the number of references in the list. The references may refer to handle values under the same handle or to handle values from any other handles. Each reference is encoded as an UTF8-string followed by a 4-byte unsigned integer that identifies the referenced handle and its value index 🧠
HS_VLIST values may be used to define administrator groups for handles 👑 In that case, each reference in the HS_VLIST defines a member of the administrator group, and the HS_VLIST value identifies the group as a whole. Client software must be careful, however, to avoid cyclic definition of value references 😭 Bestie, this is a real trap, so watch out 💀
4. Handle System Service Model 🌈
The Handle System is a distributed global name service ✨ It consists of a single distributed Global Handle Registry (GHR) and an unlimited number of Local Handle Services (LHS) 🦋 These service components provide the name service (both resolution and administration) on behalf of Handle System client components. Handle System client components may also choose to use Handle System middle-ware components (for example, the Handle System caching service) for efficiency 💜 This section describes these components and how they relate to each other, so let's get into it 🫶
4.1. Handle System Service Components
Okay so the Handle System has a hierarchical service model 🦋 At the very top sits ONE distributed global handle service, aka the Global Handle Registry (GHR) 👑 Underneath the GHR there can be any number of Local Handle Services (LHSs) ✨ Each LHS MUST be registered with the GHR so it can manage handles under its own distinct set of naming authorities. The GHR handles this through naming authority handles (the ones under "0.NA") 💅 A naming authority handle can also be used to find the service information (in terms of HS_SITE values) that describes the handle service in charge of handles under that naming authority 🎀 From that info, clients pick a service site and find the server that handles their requests 🧚
The whole thing is built to scale 💖 A handle service, global or local, MAY consist of multiple service sites that replicate each other, and each service site MAY also be a cluster of computers working together on its namespace. Having several service sites means there's no single point of failure, and it lets load get balanced between them 🫶 Running multiple servers at a site splits the service load across several server processes too, which means less powerful computers can still pull their weight in the name service 😭
4.1.1. Global Handle Registry (GHR)
The GHR is mainly used to manage naming authority handles and to provide service information for every naming authority under the Handle System 👑 It MAY also be used to manage and provide resolution and administration service for non-naming-authority handles. Unlike an LHS, which mostly manages handles under a few naming authorities, the GHR is mainly there to register naming authorities and provide service info for every LHS 💅 So basically, the GHR is the single root service that registers every LHS and shares their service info through naming authority handle(s) 🌈 Every naming authority under the Handle System MUST be registered under the GHR as a naming authority handle. That naming authority handle gives the service info for whichever handle service manages all the handles under that naming authority. The service info MAY be given as a set of HS_SITE values, or as an HS_SERV value that points to a service handle, as described earlier 🎀
The GHR MAY consist of multiple service sites, each described in its own HS_SITE value. These HS_SITE values are assigned to the designated naming authority handle "0.NA/0.NA", which is also called the root handle 🧚 The root handle is the naming authority handle that keeps the service info for the GHR. Only the administrators of the root handle can create top-level naming authorities 👑
To talk to the GHR, client software needs the GHR service info beforehand 🔥 That info MAY be distributed with the client software, or picked up from some other secure sources (e.g., postal mail, a secure web site, etc.) 💌 Client software MAY keep the service info to communicate with the GHR until it expires (according to its TTL) ⏰ The GHR MUST update its service info (assigned to the root handle) every time its configuration changes 🫶 Client software with out-dated service info will get notified of the update every time it talks to the GHR 😭 And the GHR MUST be maintained so that any client software with out-dated GHR service info can still query the root handle for the latest update. That's the kind of resilience I'm obsessed with 💜
Figure 4.1.1 shows the GHR service info as a set of HS_SITE values. The GHR MAY consist of a number of service sites, each described in an HS_SITE value. This figure shows a GHR service site located on the US East Coast, as indicated in the <AttributeList>.
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <index>: 3 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 1 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: TRUE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_HANDLE | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 1 | | |
| Description: Service site at US East Coast | | |
| NumOfServer: 3 | | |
| | | |
| ------------------------------------------ | | |
| ------------------------------------------ | | | |
| ------------------------------------------ || | | |
| | ServerID: 1 ||| | | |
| | Address: :FFFF:132.151.2.150 ||| | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2Rnw... ||| | | |
| | ServiceInterface ||| | | |
| | ServiceType: Resolution & Admin ||| | | |
| | TransmissionProtocol: TCP & UDP || | | |
| | PortNumber: 2641 | | | |
| ------------------------------------------ | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-----------------------------------------------------------Figure 4.1.1: GHR service information
The GHR and its service info are the entry point for any client software that wants to talk to the Handle System 🚪 For any given handle, client software can ask the GHR for its naming authority handle 🔍 That returns the service info of the LHS that manages every handle under the naming authority. The service info then points the client to the handle server inside that LHS that manages the handle 🎯
4.1.2. Local Handle Service (LHS)
A Local Handle Service (LHS) manages handles under given sets of naming authorities 🏡 Each naming authority defines a "local" namespace made up of all the handles under it. Quick clarification: an LHS is NOT a "local" service in terms of network topology 🙈 It's called "Local" because it usually manages a restricted (local) namespace, not because it's sitting nearby on the network.
A naming authority is "homed" at an LHS if the LHS manages all of that naming authority's handles 🏠 An LHS MAY be home to multiple naming authorities. On the other hand, a naming authority MAY only be "homed" at one LHS. A naming authority MAY also be homed at the GHR 🌸
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| <index>: 3 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 1 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: FALSE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_LOCALNAME | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 1 | | |
| Description: Local Service for "10" | | |
| NumOfServer: 2 | | |
| ----------------------------------------- | | |
| ----------------------------------------- | | | |
| | ServerID: 1 || | | |
| | Address: :FFFF:132.151.3.150 || | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2R... || | | |
| | ServiceInteface: || | | |
| | ServiceType: Resolution & Admin || | | |
| | TransmissionProtocol: TCP & UDP || | | |
| | PortNumber: 2641 |' | | |
| -----------------------------------------' | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | |-
| <reference>: {empty} |-
-----------------------------------------------------------Figure 4.1.2: LHS service information
Like the GHR, an LHS MAY also consist of many service sites, with each site described by an HS_SITE value 🧩 The set of HS_SITE values for any LHS MAY be assigned to a service handle or to the relevant naming authority handle(s). Figure 4.1.2 shows an example of HS_SITE values for an LHS. These HS_SITE values are assigned to the naming authority handle "0.NA/10", which suggests that the naming authority "10" is "homed" at the LHS described in those values 🎀 Clients can query the GHR to get the service info they need to talk to the LHS 🔎 Administrators of the naming authority handle are responsible for keeping that service info maintained and up to date 💅
Also, an LHS MAY refer its clients to another LHS in response to a service request 🌈 This lets the LHS spread its service out in a hierarchical fashion, which is honestly iconic 👑
4.2. Handle System Middle-Ware Components
Handle System middle-ware components currently include Handle System caching servers and Handle System proxy servers 🧁 These middle-ware pieces are clients to the service components, but they're servers to the client software 🔄 They're used to provide extra interfaces on top of the basic handle service. For example, a caching server MAY be used to share resolution results within a local community 🫶 And a proxy server can be used to get past an organizational firewall via HTTP tunneling 🚀
4.2.1. Handle System Caching Service ✨
okay so the Handle System caching service is basically how we cut down on network traffic between clients and servers 🦋 Caching handle data, including the service info of any LHS, means you can reuse stuff you already asked for instead of asking again. main character efficiency fr 💅
Every handle value has a <TTL> (Time to Live) field that tells a caching service how long the cached value can be treated as valid ⏰ A zero-value TTL means the value only works for the transaction currently in progress, so it should not be cached 🙈 A caching service can get its data straight from a handle service, or from another caching service that eventually gets its data from the handle service 🌸
A caching service can be defined in terms of an HS_SITE value and can be made up of multiple caching servers 🧚 For any given handle, clients can find the right caching server inside the caching service by using the same hashing algorithm used to locate the handle server within any handle service. so organized, no cap 🎀
Caching services are not part of any Handle System administration or authentication hierarchy 💀 The Handle System protocol does not authenticate any response from a caching service. Clients are responsible for setting up their own trust relationship with whichever caching service they pick. They'll also rely on that caching service to properly authenticate any response from any handle server. be careful bestie, this one is on you 🫶
4.2.2. Handle System Proxy Server
Handle System proxy servers let you resolve handles through other Internet protocols 🌈 For example, CNRI built and made available a Handle System HTTP Proxy Server that handles any handle resolution over HTTP ✨ The current DNS address for the proxy server is hdl.handle.net. The proxy server lets any handle be resolved through an HTTP URL, which can be built as http://hdl.handle.net/<handle>, where <handle> can be any handle from the Handle System 💖
Like, for example, the handle ncstrl.vatech_cs/tr-93-35 can be resolved with the HTTP URL http://hdl.handle.net/ncstrl.vatech_cs/tr-93-35 from any web browser 🦋 In this case the URL gets sent to the proxy server as an HTTP request. The proxy server queries the Handle System for the handle data and sends the results back as an HTTP response. it's giving working through the web 😭
Using HTTP URLs means handles can be resolved from standard web browsers without any extra client software, which is so iconic 👑 BUT, the reference to the handle also ties itself to the proxy server 😬 If the proxy server changes its DNS name or otherwise becomes invalid, the reference (i.e., the HTTP URL) to the handle will break. So the selection and use of a proxy server should be carefully evaluated 🍓
Proxy servers are not part of any Handle System administration or authentication hierarchy either 🙈 The Handle System protocol does not authenticate any response from a proxy server. Clients are responsible for setting up their trust relationship with whichever proxy server they select. They'll also rely on the proxy server to properly authenticate any response from any handle server. main character trust issues, periodt 💅
4.3. Handle System Client Components
Handle System client components are client software that talks to the Handle System service components 🎀 Client software may speak the Handle System protocol and send its request directly to a service component. The response from that service component might be the final answer, or it might be a referral to another service component. If it's a referral, the client software has to follow it to finish the transaction 🔥
Client software can also be configured to tunnel its request through a middle-ware component 🧚 That middle-ware component takes responsibility for getting the final result and sending it back to the client. Unlike service components, middle-ware components only return final results of the client's request. No service referral will ever come back from a middle-ware component 🫶
Lots of different Handle System client components can be built for different applications 🌸 The CNRI Handle System Resolver [17] is one such component ✨ The resolver extends web browsers (e.g., Netscape or Microsoft Internet Explorer) so that handles can be resolved directly through "hdl:" Uniform Resource Identifiers (URIs) 💜 The Grail web browser [18], a freely downloadable software developed in Python [19], also supports the "hdl:" URI scheme and resolves handles accordingly 🐍 For example, the handle 10.1045/july95-arms can be resolved by entering its handle URI, hdl:10.1045/july95-arms, into any of these resolver-enabled browsers 🌈 Details of the handle URI syntax will be specified in a separate document. stay tuned, bestie 👀
5. Handle System Operation Model 🦋
Handle System operations fall into two categories: resolution and administration 💖 Clients use the handle resolution service to query for any handle values ✨ Handle administration lets clients manage handles, including adding and deleting handles and updating their values 💅 It also deals with naming authority administration through naming authority handles. This section explains how the various Handle System components work together to get these service operations done 🧚
Both resolution and administration may require authentication of the client 🔐 The authentication can be done through the Handle System authentication protocol described later in this section. Whether authentication is required depends on the kind of operation involved, the permissions assigned to the relevant handle value, and the policies deployed by the relevant service components. it's all about context, iykyk 🙈
The Handle System protocol specifies the syntax and semantics of each message exchanged between Handle System clients and their server components 🌸 This section gives a high-level overview of the protocol used to accomplish any service operation. The exact programmatic detail of each message (i.e., its byte layout or syntax) is specified in a separate document [8]. ngl the details live elsewhere, so we'll keep it light here 🫶
5.1. Handle System Service Request and Response ✨
okay so the Handle System gives its service in response to client requests 💅 A client can send a request to any handle server to provoke a response 🦋 The response either gives an answer to the request, OR a status code with extra info that does one of three things: refers the request to another service component, asks the client for authentication, or signals some error status 😭
Every handle under the Handle System is managed by its home service 🏠 The naming authority handle tells you the service info (in terms of HS_SERV or HS_SITE values) for the handle service that manages all handles under that naming authority 🌸 Any handle request must be directed to the home service of the handle in question, no exceptions bestie 🙈 Clients can find the home service by querying the corresponding naming authority handle against the GHR 🔍 Or, this info might already be sitting in a local cache, or even be part of a local client configuration 🧚 Once clients have the service info, they can pick a service site and locate the responsible handle server within that site 🎀
Let's look at an example! To resolve the handle ncstrl.vatech_cs/te-93-35, client software needs to know the home service for the naming authority ncstrl.vatech_cs 💜 The home service can be obtained by querying the naming authority handle 0.NA/ncstrl.vatech_cs against the GHR 👑 The GHR will return the service info in terms of the HS_SITE values assigned to that naming authority handle ✨ From there, clients can pick a service site, find the responsible handle server within the site, and send the resolution request to the handle server 🫶
Clients may require digital signatures from a handle server so they can authenticate any response from the server 🔐 The signature can be generated using the server's private key 🗝️ Clients may verify the signature using the public key available from the service info (refer to the <PublicKeyRecord> entry discussed in 3.2.2) 🌈
A communication session can also be set up between any client and handle server 💖 Each session is identified by a unique session ID managed by the server 🪪 A session may be used to manage requests that need multiple interactions 🔥 It can also be used to share any TCP connection or authentication info among multiple service transactions 🦋 Each session may establish a session key and use it to authenticate any message exchanged within the session 🔑 It may also be used to encrypt any message between the client and the server for data confidentiality 🛡️
Now the diagram! 📊 It shows a handle resolution process in terms of the messages exchanged between client software and Handle System service components 🎀 Here the client is trying to resolve the handle ncstrl.vatech_cs/tr-93-35 🌸 It assumes the client has already obtained the service info of the LHS "homed" by the naming authority "ncstrl.vatech.cs" 🍓 The client still has to get that service info from the naming authority handle managed by the GHR 😭 Once it has it, the client can locate the responsible LHS and query for the handle value 💅
[HS Client] ----------------------------> [Global Handle Registry]
1. ask for the service
information from the
naming authority handle
"0.NA/ncstrl.vatech_cs"
[HS Client] <---------------------------- [Global Handle Registry]
2. service information for
the naming authority
"ncstrl.vatech_cs"
[HS Client] ----------------------------> [Local Handle Service]
3. query the handle
"ncstrl.vatech_cs/tr-93-35"
against the responsible
handle server
\... ...
(optional client authentication, depending on the service request)
\... ...
[HS Client] <---------------------------- [Local Handle Service]
4. query result from the handle
server + (optional) server
signature
Figure 5.1: Handle resolution exampleIn Figure 5.1, the client is set up to talk to the GHR for any handle service 🧠 So it first queries the GHR to find the home service for the handle's naming authority 🔎 The GHR returns the service info of the LHS that manages every handle under that naming authority 📬 From there, the client can find the responsible handle server and query it for the handle 🎯 The server may set up a session to authenticate the client if any of the handle values requires authentication 🔐 Otherwise, the server will simply return the handle value to the client 💌 The server may also send a digital signature as part of its response if the client asks for one ✍️
⚠️ Quick heads up: all of the above assumes the client software already has the GHR service info! That info was most likely obtained from the client software distribution 📦
The GHR will notify the client software if it learns that the service info the client is using is out of date 🔔 Client software may retrieve the latest service info from the root handle 0.NA/0.NA 🌳 The root handle also maintains the public key that may be used to authenticate the service info 🗝️
Also, a client may cache the service info of any naming authority, so later queries for handles under the same naming authority can reuse that info and skip the first two steps in Figure 5.1 ⚡ Client software may also be configured to query a caching or proxy server directly for any handle 🧚♀️ In that case, the caching or proxy server acts as the [HS Client] in Figure 5.1 before returning the query result to the client 🎁
Last but not least: client software under certain organizations may choose to bypass the GHR and talk directly to an LHS managed by that organization 🏢 Doing so may get a quicker response for handles managed under that LHS 🚀 For handles not managed by that LHS, the client software will be referred to the GHR 🌈
5.2. Handle System Authentication Protocol ✨
okay so the Handle System totally supports handle administration over the public Internet 🌐 and you can actually change handle stuff remotely. Access controls can be defined on each handle value 🔐. The Handle System authentication protocol is what any handle server uses to authenticate the handle administrator whenever there's an administration request 💅. Authentication is also needed when clients query for handle values that are read-only by the handle administrator 👀. Handle administration includes adding, deleting or modifying handle values, and adding or deleting handles 🧚. Naming authority administrations are carried out as handle administrations over the corresponding naming authority handles 🎀.
The Handle System authentication protocol does not perform any server authentication 🙈. However, a client may authenticate any server response by asking the server to sign its response with a digital signature ✍️.
By default, the Handle System authenticates clients via a challenge-response protocol 🦋. So after the server gets a client's request, it issues a challenge to the client if authentication is necessary. To be authenticated as the administrator, the client has to return a challenge-response, which is a message that demonstrates possession of the administrator's secret 🔑. The secret may be the private key or the secret key of the administrator. This challenge-response lets the server authenticate the client as the handle administrator. Once authentication succeeds, the server will fulfill the client's request if the administrator has sufficient permission ✨.
For example, say a client sends a request to the handle server to add a new handle value 🌸. The server will issue a challenge to the client in order to authenticate the client as one of the handle administrators. If the client has the private key of the administrator, she can use it to sign the server's challenge and return the signature as part of her challenge-response 🗝️. The server will validate the signature to authenticate the client. The client will be notified if the validation fails. Otherwise, the server will further check whether the administrator has permission to add the handle value. If so, the server adds the handle value and reports success to the client 🎉. If not, a permission-denied message gets returned 💀.
The following diagram shows a typical authentication process in terms of the messages exchanged between the client and the handle server 📊.
[Client] --------------------------------> [Handle Server]
1. client request
+ (optional) client credential
[Client] <-------------------------------- [Handle Server]
2. server's challenge to client
+ (i.e., nonce + MD5 of client request)
[Client] -------------------------------> [Handle Server]
3. reference to handle administrator
+ challenge-response from client
[Client] <------------------------------- [Handle Server]
4. server acknowledgement
Figure 5.2: Handle System authentication processIn Figure 5.2, the client sends an administration request to the handle server (along with an optional credential we'll talk about later) 📨. The server decides client authentication is required and issues a challenge. The client identifies itself as a handle administrator and returns the challenge-response. The server authenticates the client as the administrator based on that challenge-response. It also checks whether the administrator is authorized for the administration request. If so, the server fulfills the request and acknowledges the client 🥳.
Handle servers must authenticate the client before fulfilling any request that requires administrator privilege 🛡️. The exact authentication process varies depending on whether the administrator uses a public key or a secret key. It also depends on whether the handle used to store the administrator's key is managed by the same handle server or not 🤓.
When a public key is used, the challenge-response from the client contains its digital signature over the server's challenge. The server can authenticate the client by verifying that digital signature against the administrator's public key 🔏. If a secret key is used, the challenge-response from the client carries the Message Authenticate Code (MAC) generated using the secret key. The server may authenticate the client by generating the same MAC with the administrator's secret key and comparing it against the challenge-response 🧮.
The reference to handle administrator in Fig 5.2 is also called a key-reference 🔗. It refers to a handle value that contains the key used by the administrator. If the key-reference is managed by the same handle server (for example, a handle value assigned to the same handle), the server may use the key directly to do the authentication. If the key-reference is managed by some other handle server (whether or not it's within the same handle service), the server will have to send a verification-request to that other handle server, which we'll call the key-server, in order to authenticate the client 🤝. The verification-request to the key-server carries both the server's challenge and the client's challenge-response. The key-server returns a verification-response, signed using the key-server's private key ✍️. What's in the verification-response depends on the handle value referenced by the key-reference. If the key-reference refers to a public key used by the administrator, the verification-response contains the administrator's public key. Otherwise, the key-server verifies the challenge-response on behalf of the requesting server and returns the result in the verification-response 🧾. The diagram below shows the control flow of the authentication process where the key-reference refers to a handle value containing the administrator's public (or secret) key and the key-server is some other handle server 🗺️.
-------- -------------
| | 1. client request. | |
| | -------------------------------> | |
| | | |
| | 2. session ID | |
| | + server's challenge | |
| Handle | <------------------------------- | Handle |
| System | | server |
| client | 3. session ID | receiving |
| | + response to the challenge | client |
| | + administrator reference | request |
| | --------------------------------> | |
| | | |
| | 6. server acknowledgement | |
| | <------------------------------- | |
-------- -------------
| ^
4. Verification | | 5. verifi-
request | | cation
| | response
| | (signed)
V |
--------------------------
| The handle server (the |
| key-server) that manages |
| the key referenced by |
| the key-reference |
--------------------------
Figure 5.3: Authentication process requiring verification
from a second handle serverSecret key based authentication via a second handle server (aka the key server) is a super convenient way to share a common secret key (like a pass phrase) among handles managed by different handle servers 🧩. BUT it should not be used to manage highly sensitive handles or handle data 🚫. The authentication process itself is expensive and relies on a third party (the key-server) to work properly 😩. Also, the secret key itself is subject to dictionary attack, since the key-server cannot determine whether the verification-request comes from a legitimate handle server 😬. A handle service may set its local policy so that secret key based authentication can only be carried out if the handle server receiving the client request is also the key-server 🔒.
Local handle services may define additional local policies for authentication and/or authorization 📋. Handle System service components may also choose to use other Internet authentication mechanisms such as Kerberos [20] or some Transport Layer Security protocol [21] 🌈. Details of these will be addressed in a separate document 📚.
6. Security Considerations 🔒
Handle System security considerations are discussed in the "Handle System Overview" [1], and that discussion applies equally to this document 💜.
The Handle System delegates handle administration to each handle administrator, who may or may not be the server administrator 👑. Handle administrators are allowed to choose their own public/secret keys used for authentication. The security of Handle System authentication depends on proper key selection and on the handle administrator maintaining those keys 🫶. Handle administrators must choose and protect their authentication keys carefully in order to protect the handle data 😭. Handle server implementations may deploy policies that regulate the selection of public/secret keys used for authentication. For example, a handle server may require that any authentication key be no less than a certain number of bits 📏. It may also prohibit the use of secret keys because of the potential for dictionary attack 🙅♀️.
The Handle System data model supports execution permission (PUBLIC_EXECUTE, ADMIN_EXECUTE) for each handle value ⚡. While this allows better sharing of network resources, it also raises many security considerations 🚨. Execution privilege should be restricted within the permissions of a certain user account (corresponding to the handle administrator) on the server to prevent system-wide disruption 🧯. Switching between computing platforms for the server should also be done carefully to avoid any unexpected behavior 🫣. Implementations may choose not to support the execution permission, or may provide options so that it can be disabled 🙌.
To protect against any irresponsible use of system resources, handle servers may implement quota control 🚧. Quota control can be used to put limits on the number of handles under a naming authority, the number of handle values allowed for any given handle, the maximum size of any handle value, and the number of sub-naming authorities under a naming authority. Handle servers must report an error if the result of a handle administration violates any of these limits ❗
7. Acknowledgements ✨
okay so this section is where the authors give shoutouts, and honestly it's giving gratitude era 🫶 This work grew out of earlier versions of the Handle System implementation. The big-picture digital object architecture, Handle System included, was laid out in a paper by Robert Kahn and Robert Wilensky [22] back 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. The design ideas came out of conversations within the Handle System development team: David Ely, Charles Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie Nguyen, Jason Petrone, and Helen She. They're all iconic and their contributions 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 🌸 Recommendations from other members of the IETF/IRTF community got a big thank you too 🧚
8. References and Bibliography 📚
okay here's the reading list, and it's a lot 😭 Every single reference is kept exactly as written, so nothing's been dropped:
- [1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650, November 2003.
- [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] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
- [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [6] Yergeau, F., "UTF-8, A Transform Format for Unicode and ISO10646", RFC 2279, January 1998.
- [7] The Unicode Consortium, "The Unicode Standard, Version 2.0", Addison-Wesley Developers Press, 1996. ISBN 0-201-48345-9
- [8] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol (ver 2.1) Specification", RFC 3652, November 2003.
- [9] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
- [10] Housley, R., Polk, W. Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [11] Federal Information Processing Standards Publication (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 (supersedes FIPS PUB 46, 1977 January 15).
- [12] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
- [13] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
- [14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [15] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
- [16] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
- [17] CNRI Handle System Resolver, http://www.handle.net/resolver
- [18] Grail browser home page, http://grail.sourceforge.net/
- [19] Python language website, http://www.python.org/
- [20] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
- [21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
- [22] R. Kahn, R. Wilensky, "A Framework for Distributed Digital Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
- [23] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
9. Authors' Addresses 💌
these are the people who wrote the thing, so here are their contact details, exactly as published:
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
Sean Reilly
Corporation for National Research Initiatives (CNRI)
1895 Preston White Dr., Suite 100
Reston, VA 20191
Phone: 703-620-8990
EMail: sreilly@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.us10. Full Copyright Statement ⚖️
okay the legal part is a little less fun, but it matters, so I'm keeping it word for word 🙈 Here's the full copyright statement, exactly as written:
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: rfc3651 2003-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms