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 of any resolution request. It is
possible for a client to ask for a subset of those values with
specific data type (e.g., all URLs assigned to the handle). The
client may also ask for a specific handle value based on a specific
value index.
Each handle value can be uniquely referenced by the combination of
the handle and its value index. Care must be taken when changing the
value index as it may break an existing reference to the handle
value. For example, suppose 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 will become obsolete. 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. Nor can it be assumed that the index will start with
0 or 1. 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 as "authorized-read". This limits read-access to
the handle administrator only. The "privatized" value can then be
used to keep any historical data (on behalf of the handle
administrator) without exposing it to public. Such approach may also
be used to keep any obsolete handle or naming authority from being
reused accidentally.
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
allows organizations to 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". The
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 to describe the service interface
of any Handle System service component. The following sections
provide detailed descriptions of these pre-defined data types under
the Handle System.
3.2.1. Handle Administrator: HS_ADMIN
Each handle has one or more administrators. Any administrative
operation (e.g., add, delete or modify handle values) can only be
performed by the handle administrator with adequate privilege.
Handle administrators are defined in terms of HS_ADMIN values. Every
handle must have at least one HS_ ADMIN value that defines its
administrator. Each HS_ADMIN value can be used to define a set of
handle administrators sharing the same administration privilege.
Handles with multiple administrators of different privileges may have
multiple HS_ADMIN values. HS_ADMIN values are used by the Handle
System to authenticate handle administrators before fulfilling any
handle administration request.
Naming authorities, as described above, are themselves registered as
handles under the reserved naming authority "0.NA". These handles
are referred to as naming authority handles. Administrators for any
naming authority are defined as the administrators of the
corresponding naming authority handle. For example, "0.NA/10" is the
naming authority handle for the naming authority "10". Hence any
administrator for the naming authority handle "0.NA/10" is also the
administrator for the naming authority "10". Naming authority
administrators are the only ones who can create handles or sub-
naming authorities under the naming authority. A sub-naming
authority may define its own set of administrators to create handles
or further levels of sub-naming authorities. For example, the naming
authority "10.1045" may have a totally different group of
administrators from its parent naming authority "10".
An HS_ADMIN value is a handle value whose <type> field is HS_ADMIN
and whose <data> field consists of the following entries:
<AdminRef>
A reference to a handle value. The reference consists of the
handle name (a UTF8-string) followed by a 4-byte unsigned integer
for the handle value index. The handle value identifies the set
of administrators for the handle.
<AdminPermission>
A 16-bit bit-mask that defines the administration privilege of the
set of handle administrators identified by the HS_ADMIN value.
The <AdminRef> entry refers to a handle value that can be used to
authenticate the handle administrator. Such handle value is called
the handle administrator reference. The handle administrator
reference may contain the secret key, public key, or X.509
certificate [10] provided by the handle administrator. For example,
the <AdminRef> entry may contain a handle administrator reference
whose <type> field is DSS_WITH_DES_CBC_SHA and whose <data> field
contains a DES secret key [11], for use in the Cipher Block Chaining
(CBC) mode of operation [12, 13]. The secret key can be used by the
handle server to authenticate the handle administrator. For stronger
cryptographic algorithm, the handle administrator reference may
contain a set of Triple-DES keys [23] and set its <type> to be DES-
EDE3-WITH-CBC.
A single handle may be assigned with both the HS_ADMIN value and the
handle administrator reference. In other words, the <AdminRef> entry
may refer to a handle value assigned to the same handle that has the
HS_ADMIN value. In this case, authentication of the handle
administrator does not rely on any other handles. Alternatively, the
handle administrator reference may be a handle value under a
different handle. Thus HS_ADMIN values from different handles may
share a common handle administrator reference. This feature allows
sharing of handle administrators among different handles. The handle
administrator reference contains the secret key, public key, or X.509
certificate provided by the administrator of these handles.
Handle administrator reference may be of type HS_VLIST and has its
<data> field contain a list of references to other handle values.
Each of these handle values defines a handle administrator reference.
The HS_VLIST value defines an administrator group. Each handle
administrator reference from the HS_VLIST is a member of the
administrator group. Each handle value reference is defined in terms
of a <handle>:<index> pair. An administrator group may also contain
other administrator groups as its members. This allows administrator
groups to be defined in a hierarchical fashion. Care must be taken,
however, to avoid cyclic definition of administrators or
administrator groups. Multiple levels of administrator groups should
be avoided due to their lack of efficiency, but will not be signaled
as an error. Client software should be prepared to detect any
potential cyclic definition of administrators or <AdminRef> entries
that point to non-existent handle values and treat them as an error.
A handle can have multiple HS_ADMIN values, each of which defines a
different handle administrator. Different administrators can play
different roles or be granted different permissions. For example,
the naming authority handle "0.NA/10" may have two administrators,
one of which may only have permission to create new handles under the
naming authority, while the other may have permission to create new
sub-naming authorities (e.g., "10.1045"). The set of possible
permissions for a handle administrator is defined as follows:
Add_Handle (0x0001)
This permission allows naming authority administrator to create new
handles under a given naming authority.
Delete_Handle (0x0002)
This permission allows naming authority administrator to delete
handles under a given naming authority.
Add_NA (0x0004)
This permission allows the naming authority administrator to create
new sub-naming authorities.
Delete_NA (0x0008)
This permission allows naming authority administrator to delete an
existing sub-naming authority.
Modify_Value (0x0010)
This permission allows handle administrator to modify any handle
values other than HS_ADMIN values. HS_ADMIN values are used to
define handle administrators and are managed by a different set of
permissions.
Delete_Value (0x0020)
This permission allows handle administrator to delete any handle
value other than the HS_ADMIN values.
Add_Value (0x0040)
This permission allows handle administrator to add handle values
other than the HS_ADMIN values.
Modify_Admin (0x0080)
This permission allows handle administrator to modify HS_ADMIN
values.
Remove_Admin (0x0100)
This permission allows handle administrator to remove HS_ADMIN
values.
Add_Admin (0x0200)
This permission allows handle administrator to add new HS_ADMIN
values.
Authorized_Read (0x0400)
This permission grants handle administrator read-access to handle
values with the ADMIN_READ permission. Administrators without this
permission will not have access to handle values that require
authentication for read access.
LIST_Handle (0x0800)
This permission allows naming authority administrator to list
handles under a given naming authority.
LIST_NA (0x1000)
This permission allows naming authority administrator to list
immediate sub-naming authorities under a given naming authority.
Administrator permissions are encoded in the <AdminPermission> entry
in the <data> field of any HS_ADMIN value. Each permission is
encoded as a bit flag. The permission is granted if the flag is set
to 1, otherwise it is set to 0.
Figure 3.2.1 shows an example of HS_ADMIN value that defines an
administrator for the naming authority handle "0.NA/10". In figure
3.2.1, a naming authority administrator is identified by an HS_ADMIN
value assigned to the naming authority handle "0.NA/10". The
administrator can be authenticated based on the handle value
"0.NA/10":3, which is the handle value assigned to the naming
authority handle "0.NA/10" and has its index set to 3. The handle
value "0.NA/10":3 may contain the secret or public key used by the
administrator. The administrator is granted permission to add,
delete, or modify sub-naming authorities under "10", and add or
delete handles directly under the naming authority. The
administrator may also add, delete, or modify any handle values
assigned to the naming authority handle except those HS_ADMIN values.
In other words, the administrator is not allowed to add, delete, or
modify any administrators 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 used by handle servers to authenticate the handle
administrator before fulfilling any administrative requests. The
server authenticates a client by checking whether the client has
possession of the secret key (or the private key) that matches the
one in any of the handle administrator references. The
authentication is carried out via the Handle System authentication
protocol as described later in this document.
HS_ADMIN values may require authentication for read access in order
to prevent public exposure of the data. Additionally, the handle
administrator reference that contains the administrator’s secret key
should have neither PUBLIC_READ nor ADMIN_READ permission to prevent
the key from leaving the server.
3.2.2. Service Site Information: HS_SITE
The Handle System consists of a single distributed global handle
service, also known as the Global Handle Registry (GHR), and
unlimited number of Local Handle Services (LHSs). Each handle
service, global or local, may be replicated into multiple service
sites. Each service site may consist of multiple server computers.
Service requests targeted at any handle service can be distributed
into different service sites, and into different server computers
within any service site. Such architecture assures that each handle
service could have the capacity to manage any large number of handles
and handle requests. It also provides ways for each handle service
to avoid any single point of failure.
Each handle service, global or local, may provide the same set of
functions for resolving and administering its collection of handles.
Handle services differ primarily in that each service is responsible
for a distinct set of handles. They are also likely to differ in the
selection, number, and configuration of their components such as the
servers used to provide handle resolution and administration.
Different handle services may be created and managed by different
organizations. Each of them may have their own goals and policies.
A service site typically consists of a cluster of server computers
residing within a local Internet domain. These computers work
together to distribute the data storage and processing load at the
site. It is possible, although not recommended, to compose a site
from servers at widely different locations. Further, it is even
possible to compose two different sites from the same set of servers.
Each service site is defined by an HS_SITE value. HS_SITE is a
pre-defined Handle System data type. An HS_SITE value defines a
service site by identifying the server computers (e.g., IP addresses)
that comprise the site along with their service configurations (e.g.,
port numbers). HS_SITE values are typically assigned to naming
authority handles. The set of HS_SITE values assigned to a naming
authority handle is called the service information for the naming
authority.
The service information is managed by the naming authority
administrator. It must reflect the configuration of the handle
service for the naming authority. Note that an additional layer of
indirection, called a service handle, can be used to allow multiple
naming authorities to reference a single set of HS_SITE values, as
described later in this document (see section 3.2.3). Clients of the
Handle System depend on the service information to locate the
responsible handle server before they can send their service
requests. The service information can also be used by clients to
authenticate any service response from the handle server.
An HS_SITE value is a handle value whose <type> field is HS_SITE and
whose <data> field consists of the following entries:
<Version>
A 2-byte value that identifies the version number of the HS_SITE.
The version number identifies the data format used by the HS_SITE
value. It is defined to allow backward compatibility over time.
This document defines the HS_SITE with version number 0.
<ProtocolVersion>
A 2-byte integer value that identifies the handle protocol version.
The higher byte of the value identifies the major version and the
lower byte the minor version. Details of the Handle System
protocol is specified in [8].
<SerialNumber>
A 2-byte integer value that increases by 1 (and may wrap around
through 0) each time the HS_SITE value gets changed. It is used in
the Handle System protocol to synchronize the HS_SITE values
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. It
indicates whether the handle service has multiple primary sites.
The second bit of the octet is the <PrimarySite> bit. It indicates
whether the HS_SITE value is a primary site. A primary site is the
one that supports administrative operations for its handles. A
<MultiPrimary> entry with zero value indicates that the handle
service has a single primary site and all handle administration has
to be done at that site. A non-zero <MultiPrimary> entry indicates
that the handle service has multiple primary sites. Each primary
site may be used to administrate handles managed under the handle
service. Handles managed by such service may identify its primary
sites using an HS_PRIMARY value, as described in section 3.2.5.
<HashOption>
An 8-bit octet that identifies the hash option used by the service
site to distribute handles among its servers. Valid options
include HASH_BY_NA (0x00), HASH_BY_LOCAL (0x01), or HASH_BY_HANDLE
(0x02). These options indicate whether the hash operation should
only be applied to the naming authority portion of the handle, or
only the local name portion of the handle, or the entire handle,
respectively. The standard MD5 hashing algorithm [14] is used by
each service site to distribute handles among its servers.
<HashFilter>
An UTF8-string entry reserved for future use.
<AttributeList>
A 4-byte integer followed by a list of UTF8-string pairs. The
integer indicates the number of UTF8-string pairs that follow.
Each UTF8-string pair is an <attribute>:<value> pair. They are
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 distinguish the service sites
from each other.
<NumOfServer>
A 4-byte integer that defines the number of servers in the service
site. The entry is followed by a list of <ServerRecord>s. Each
<ServerRecord> defines a handle server that is part of the service
site. Each <ServerRecord> consists of the following data fields:
<ServerRecord> ::= <ServerID>
<Address> <PublicKeyRecord> <ServiceInterface>
where each field is defined as follows:
<ServerID>
A 4-byte unsigned integer that uniquely identifies a server
process under the service site. <ServerID>s do not have to
begin with 1 and they don’t have be consecutive numbers. They
are used to distinguish servers under a service site from each
other. Note that there can be multiple servers residing on any
given computer, each with a different <ServerID>.
<Address>
The 16-byte IPv6 [15, 16] address of the handle server. Any
IPv4 address should be presented as :::::FFFF:xxxx:xxxx (where
xxxx:xxxx can be any 4-byte IPv4 address).
<PublicKeyRecord>
A 4-byte integer followed by a byte-array that contains the
server’s public key. The integer specifies the size of the
byte-array. The byte-array (for the publickey) consists of
three parts: a UTF8-string that describes the key type, a
two-byte option field reserved for future use, and a byte-array
that contains the public key itself. For example, the UTF8-
String "DSA_PUB_KEY" indicates that the <PublicKeyRecord>
contains a DSA public key. The storage format of the DSA key
in the byte-array could then be found from the handle
"0.type/DSA_PUB_KEY". 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 this case, "CERT.X509" will map to the handle
"0.TYPE/CERT.X509". The handle may contain information that
describes the syntax and semantics of the public key or its
certificate. Additional key type may also be registered (as
handles under "0.TYPE") to further distinguish different kinds
of X.509 certificates. 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 a X.509
certificate with a DSA public key in it."
<ServiceInterface> ::= <InterfaceCounter>