[要約] RFC 3652は、Handle System Protocol（バージョン2.1）の仕様を定めたものであり、要約すると以下のようになります。1. Handle System Protocolは、グローバルな識別子であるハンドルを管理するためのプロトコルである。 2. この仕様は、ハンドルの作成、解決、更新、削除などの操作を定義している。 3. 目的は、ハンドルシステムの効率的な運用と相互運用性の確保である。
Network Working Group S. Sun
Request for Comments: 3652 S. Reilly
Category: Informational L. Lannom
J. Petrone
CNRI
November 2003
Handle System Protocol (ver 2.1) Specification
システムプロトコル（Ver 2.1）仕様を処理します
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
IESG Note
IESGノート
Several groups within the IETF and IRTF have discussed the Handle System and its relationship to existing systems of identifiers. The IESG wishes to point out that these discussions have not resulted in IETF consensus on the described Handle System, nor on how it might fit into the IETF architecture for identifiers. Though there has been discussion of handles as a form of URI, specifically as a URN, these documents describe an alternate view of how namespaces and identifiers might work on the Internet and include characterizations of existing systems which may not match the IETF consensus view.
IETFおよびIRTF内のいくつかのグループは、ハンドルシステムと既存の識別子システムとの関係について説明しました。IESGは、これらの議論が説明されているハンドルシステムのIETFコンセンサスや、識別子のIETFアーキテクチャにどのように適合するかについてのIETFコンセンサスをもたらさなかったことを指摘したいと考えています。URIの形式としてのハンドル、特にURNとしての議論がありましたが、これらのドキュメントは、名前空間と識別子がインターネット上でどのように機能するかについての代替ビューを説明し、IETFコンセンサスビューと一致しない既存のシステムの特性評価を含む方法を説明しています。
Abstract
概要
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.
ハンドルシステムは、公開インターネット上のセキュリティで保護された名前解像度と管理を可能にする汎用グローバルネームサービスです。このドキュメントでは、クライアントソフトウェアに使用されるプロトコルについて、ハンドル解像度と管理の両方のハンドルシステムにアクセスします。プロトコルは、クライアントソフトウェアの手順を指定して、特定のハンドルの責任あるハンドルサーバーを見つけます。また、ハンドル操作のためにクライアントとサーバーの間で交換されるメッセージを定義します。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conventions. . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Data Transmission Order. . . . . . . . . . . . . 4
2.1.2. Transport Layer. . . . . . . . . . . . . . . . . 5
2.1.3. Character Case . . . . . . . . . . . . . . . . . 6
2.1.4. Standard String Type: UTF8-String. . . . . . . . 7
2.2. Common Elements. . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Message Envelope . . . . . . . . . . . . . . . . 8
2.2.2. Message Header . . . . . . . . . . . . . . . . . 11
2.2.3. Message Body . . . . . . . . . . . . . . . . . . 17
2.2.4. Message Credential . . . . . . . . . . . . . . . 18
2.3. Message Transmission . . . . . . . . . . . . . . . . . . 20
3. Handle Protocol Operations . . . . . . . . . . . . . . . . . . 21
3.1. Client Bootstrapping . . . . . . . . . . . . . . . . . . 21
3.1.1. Global Handle Registry and its Service
Information. . . . . . . . . . . . . . . . . . . 21
3.1.2. Locating the Handle System Service Component . . 22
3.1.3. Selecting the Responsible Server . . . . . . . . 23
3.2. Query Operation. . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Query Request. . . . . . . . . . . . . . . . . . 24
3.2.2. Successful Query Response. . . . . . . . . . . . 25
3.2.3. Unsuccessful Query Response. . . . . . . . . . . 26
3.3. Error Response from Server . . . . . . . . . . . . . . . 26
3.4. Service Referral . . . . . . . . . . . . . . . . . . . . 27
3.5. Client Authentication. . . . . . . . . . . . . . . . . . 28
3.5.1. Challenge from Server to Client. . . . . . . . . 29
3.5.2. Challenge-Response from Client to Server . . . . 30
3.5.3. Challenge-Response Verification-Request. . . . . 33
3.5.4. Challenge-Response Verification-Response . . . . 33
3.6. Handle Administration. . . . . . . . . . . . . . . . . . 34
3.6.1. Add Handle Value(s). . . . . . . . . . . . . . . 34
3.6.2. Remove Handle Value(s) . . . . . . . . . . . . . 35
3.6.3. Modify Handle Value(s) . . . . . . . . . . . . . 36
3.6.4. Create Handle. . . . . . . . . . . . . . . . . . 37
3.6.5. Delete Handle. . . . . . . . . . . . . . . . . . 39
3.7. Naming Authority (NA) Administration . . . . . . . . . . 40
3.7.1. List Handle(s) under a Naming Authority. . . . . 40
3.7.2. List Sub-Naming Authorities under a Naming
Authority. . . . . . . . . . . . . . . . . . . . 41
3.8. Session and Session Management . . . . . . . . . . . . . 42
3.8.1. Session Setup Request. . . . . . . . . . . . . . 43
3.8.2. Session Setup Response . . . . . . . . . . . . . 46
3.8.3. Session Key Exchange . . . . . . . . . . . . . . 47
3.8.4. Session Termination. . . . . . . . . . . . . . . 48
4. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 48
4.1. Server Implementation. . . . . . . . . . . . . . . . . . 48
4.2. Client Implementation. . . . . . . . . . . . . . . . . . 49
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. Informative References . . . . . . . . . . . . . . . . . . . . 50
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53
The Handle System provides a general-purpose, secured global name service for the Internet. It was originally conceived and described in a paper by Robert Kahn and Robert Wilensky [18] in 1995. The Handle System defines a client server protocol in which client software submits requests via a network to handle servers. Each request describes the operation to be performed on the server. The server will process the request and return a message indicating the result of the operation. This document specifies the protocol for client software to access a handle server for handle resolution and administration. It does not include the description of the protocol used to manage handle servers. A discussion of the management protocol is out of the scope of this document and will be made available in a separate document. The document assumes that readers are familiar with the basic concepts of the Handle System as introduced in the "Handle System Overview" [1], as well as the data model and service definition given in the "Handle System Namespace and Service Definition" [2].
ハンドルシステムは、インターネットに汎用的で安全なグローバル名サービスを提供します。もともとは、1995年にRobert KahnとRobert Wilensky [18]による論文で考案され、説明されていました。ハンドルシステムは、クライアントソフトウェアがネットワークを介してリクエストを送信してサーバーを処理するクライアントサーバープロトコルを定義しています。各リクエストは、サーバーで実行される操作について説明します。サーバーはリクエストを処理し、操作の結果を示すメッセージを返します。このドキュメントは、クライアントソフトウェアのプロトコルを指定して、ハンドル解像度と管理用のハンドルサーバーにアクセスします。ハンドルサーバーの管理に使用されるプロトコルの説明は含まれていません。管理プロトコルの議論はこのドキュメントの範囲外であり、別のドキュメントで利用可能になります。このドキュメントは、読者が「ハンドルシステムの概要」[1]で紹介されているハンドルシステムの基本概念に精通していること、および「ハンドルシステム名とサービス定義」[2に記載されているデータモデルとサービスの定義に精通していることを前提としています。]。
The Handle System consists of a set of service components as defined in [2]. From the client's point of view, the Handle System is a distributed database for handles. Different handles under the Handle System may be maintained by different handle servers at different network locations. The Handle protocol specifies the procedure for a client to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.
ハンドルシステムは、[2]で定義されている一連のサービスコンポーネントで構成されています。クライアントの観点から、ハンドルシステムはハンドル用の分散データベースです。ハンドルシステムの下の異なるハンドルは、さまざまなネットワークロケーションの異なるハンドルサーバーによって維持される場合があります。ハンドルプロトコルは、クライアントが特定のハンドルの責任あるハンドルサーバーを見つける手順を指定します。また、ハンドル操作のためにクライアントとサーバーの間で交換されるメッセージを定義します。
Some key aspects of the Handle protocol include:
ハンドルプロトコルのいくつかの重要な側面には次のものがあります。
o The Handle protocol supports both handle resolution and administration. The protocol follows the data and service model defined in [2].
o ハンドルプロトコルは、ハンドル解像度と管理の両方をサポートします。プロトコルは、[2]で定義されているデータとサービスモデルに従います。
o A client may authenticate any server response based on the server's digital signature.
o クライアントは、サーバーのデジタル署名に基づいてサーバーの応答を認証できます。
o A server may authenticate its client as handle administrator via the Handle authentication protocol. The Handle authentication protocol is a challenge-response protocol that supports both public-key and secret-key based authentication.
o サーバーは、ハンドル認証プロトコルを介して、クライアントをハンドル管理者として認証することができます。ハンドル認証プロトコルは、Public-KeyおよびSecret-Keyベースの両方の認証をサポートするチャレンジ応答プロトコルです。
o A session may be established between the client and server so that authentication information and network resources (e.g., TCP connection) may be shared among multiple operations. A session key can be established to achieve data integrity and confidentiality.
o 認証情報とネットワークリソース（TCP接続など）が複数の操作間で共有できるように、クライアントとサーバーの間にセッションが確立される場合があります。データの整合性と機密性を実現するために、セッションキーを確立できます。
o The protocol can be extended to support new operations. Controls can be used to extend the existing operations. The protocol is defined to allow future backward compatibility.
o プロトコルは、新しい操作をサポートするために拡張できます。コントロールを使用して、既存の操作を拡張できます。プロトコルは、将来の後方互換性を可能にするために定義されています。
o Distributed service architecture. Support service referral among different service components.
o 分散サービスアーキテクチャ。さまざまなサービスコンポーネント間のサービス紹介をサポートします。
o Handles and their data types are based on the ISO-10646 (Unicode 2.0) character set. UTF-8 [3] is the mandated encoding under the Handle protocol.
o ハンドルとそのデータ型は、ISO-10646（Unicode 2.0）文字セットに基づいています。UTF-8 [3]は、ハンドルプロトコルの下で義務付けられたエンコードです。
The Handle protocol (version 2.1) specified in this document has changed significantly from its earlier versions. These changes are necessary due to changes made in the Handle System data model and the service model. Servers that implement this protocol may continue to support earlier versions of the protocol by checking the protocol version specified in the Message Envelope (see section 2.2.1).
このドキュメントで指定されたハンドルプロトコル（バージョン2.1）は、以前のバージョンから大幅に変更されました。これらの変更は、ハンドルシステムデータモデルとサービスモデルに加えられた変更のために必要です。このプロトコルを実装するサーバーは、メッセージエンベロープで指定されたプロトコルバージョンをチェックすることにより、プロトコルの以前のバージョンを引き続きサポートし続ける場合があります（セクション2.2.1を参照）。
The following conventions are followed by the Handle protocol to ensure interoperability among different implementations.
次の規則の後に、さまざまな実装間の相互運用性を確保するために、ハンドルプロトコルが続きます。
The order of transmission of data packets follows the network byte order (also called the Big-Endian [11]). That is, when a data-gram consists of a group of octets, the order of transmission of those octets follows their natural order from left to right and from top to bottom, as they are read in English. For example, in the following diagram, the octets are transmitted in the order they are numbered.
データパケットの送信の順序は、ネットワークバイトの順序に続きます（Big-Endian [11]とも呼ばれます）。つまり、データグラムがオクテットのグループで構成されている場合、これらのオクテットの伝送の順序は、英語で読まれているように、左から右へ、そして上から下まで自然な秩序に従います。たとえば、次の図では、オクテットに番号が付けられている順序で送信されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.-------------------------------.
| 1 | 2 |
|-------------------------------|
| 3 | 4 |
|-------------------------------|
| 5 | 6 |
'-------------------------------'
If an octet represents a numeric quantity, the left most bit is the most significant bit. For example, the following diagram represents the value 170 (decimal).
オクテットが数値を表す場合、左が最も重要なビットです。たとえば、次の図は値170（小数）を表します。
0 1 2 3 4 5 6 7
.---------------.
|1 0 1 0 1 0 1 0|
'---------------'
Similarly, whenever a multi-octet field represents a numeric quantity, the left most bit is the most significant bit and the most significant octet of the whole field is transmitted first.
同様に、マルチオクテットフィールドが数値を表す場合はいつでも、左が最も重要なビットであり、フィールド全体の最も重要なオクテットが最初に送信されます。
The Handle protocol is designed so that messages may be transmitted either as separate data-grams over UDP or as a continuous byte stream via a TCP connection. The recommended port number for both UDP and TCP is 2641.
ハンドルプロトコルは、メッセージをUDP上の個別のデータグラムとして、またはTCP接続を介して連続バイトストリームとして送信できるように設計されています。UDPとTCPの両方で推奨されるポート番号は2641です。
UDP Usage
UDPの使用
Messages carried by UDP are restricted to 512 bytes (not including the IP or UDP header). Longer messages must be fragmented into UDP packets where each packet carries a proper sequence number in the Message Envelope (see Section 2.2.1).
UDPによって運ばれるメッセージは、512バイト（IPまたはUDPヘッダーを含まない）に制限されています。長いメッセージをUDPパケットに断片化する必要があります。そこでは、各パケットがメッセージエンベロープに適切なシーケンス番号が付いています（セクション2.2.1を参照）。
The optimum retransmission policy will vary depending on the network or server performance, but the following are recommended:
最適な再送信ポリシーは、ネットワークまたはサーバーのパフォーマンスによって異なりますが、以下をお勧めします。
o The client should try other servers or service interfaces before repeating a request to the same server address.
o クライアントは、同じサーバーアドレスにリクエストを繰り返す前に、他のサーバーまたはサービスインターフェイスを試す必要があります。
o The retransmission interval should be based on prior statistics if possible. Overly aggressive retransmission should be avoided to prevent network congestion. The recommended retransmission interval is 2-5 seconds.
o 再送信間隔は、可能であれば以前の統計に基づいている必要があります。ネットワークの混雑を防ぐために、過度に積極的な再送信を避ける必要があります。推奨される再送信間隔は2〜5秒です。
o When transmitting large amounts of data, TCP-friendly congestion control, such as an interface to the Congestion Manager [12], should be implemented whenever possible to avoid unfair consumption of the bandwidth against TCP-based applications. Details of the congestion control will be discussed in a separate document.
o 大量のデータを送信する場合、TCPベースのアプリケーションに対する帯域幅の不公平な消費を避けるために、可能な限り、混雑マネージャーへのインターフェース[12]などのTCPに優しい混雑制御を実装する必要があります。輻輳制御の詳細については、別のドキュメントで説明します。
TCP Usage
TCPの使用
Messages under the Handle protocol can be mapped directly into a TCP byte-stream. However, the size of each message is limited by the range of a 4-byte unsigned integer. Longer messages may be fragmented into multiple messages before the transmission and reassembled at the receiving end.
ハンドルプロトコルの下のメッセージは、TCPバイトストリームに直接マッピングできます。ただし、各メッセージのサイズは、4バイトの符号なし整数の範囲によって制限されます。長いメッセージは、送信前に複数のメッセージに断片化され、受信側で再組み立てされる場合があります。
Several connection management policies are recommended:
いくつかの接続管理ポリシーが推奨されます。
o The server should support multiple connections and should not block other activities waiting for TCP data.
o サーバーは複数の接続をサポートする必要があり、TCPデータを待っている他のアクティビティをブロックしないでください。
o By default, the server should close the connection after completing the request. However, if the request asks to keep the connection open, the server should assume that the client will initiate connection closing.
o デフォルトでは、リクエストを完了した後、サーバーは接続を閉じる必要があります。ただし、リクエストが接続を開いたままにするように要求する場合、サーバーはクライアントが接続クロージングを開始すると想定する必要があります。
Handles are character strings based on the ISO-10646 character set and must be encoded in UTF-8. By default, handle characters are treated as case-sensitive under the Handle protocol. A handle service, however, may be implemented in such a way that ASCII characters are processed case-insensitively. For example, the Global Handle Registry (GHR) provides a handle service where ASCII characters are processed in a case-insensitive manner. This suggests that ASCII characters in any naming authority are case-insensitive.
ハンドルは、ISO-10646文字セットに基づく文字文字列であり、UTF-8でエンコードする必要があります。デフォルトでは、ハンドル文字は、ハンドルプロトコルの下で症例に敏感なものとして扱われます。ただし、ハンドルサービスは、ASCII文字がケースインセンシタルに処理されるように実装できます。たとえば、グローバルハンドルレジストリ（GHR）は、ASCII文字がケースに依存しない方法で処理されるハンドルサービスを提供します。これは、命名当局のASCIIキャラクターがケース非感受性であることを示唆しています。
When handles are created under a case-insensitive handle server, their original case should be preserved. To avoid any confusion, the server should avoid creating any handle whose character string matches that of an existing handle, ignoring the case difference. For example, if the handle "X/Y" was already created, the server should refuse any request to create the handle "x/y" or any of its case variations.
ハンドルがケースに依存しないハンドルサーバーの下で作成される場合、元のケースを保存する必要があります。混乱を避けるために、サーバーは、ケースの違いを無視して、既存のハンドルの文字列と一致するハンドルを作成することを避ける必要があります。たとえば、ハンドル「x/y」が既に作成されている場合、サーバーはハンドル「x/y」またはそのケースのバリエーションを作成するリクエストを拒否する必要があります。
Handles are transmitted as UTF8-Strings under the Handle protocol. Throughout this document, UTF8-String stands for the data type that consists of a 4-byte unsigned integer followed by a character string in UTF-8 encoding. The leading integer specifies the number of octets of the character string.
ハンドルは、ハンドルプロトコルの下でUTF8ストリングとして送信されます。このドキュメント全体を通して、UTF8ストリングは、4バイトの符号なし整数で構成されるデータ型を表します。その後、UTF-8エンコーディングの文字文字列が続きます。主要な整数は、文字文字列のオクテットの数を指定します。
Each message exchanged under the system protocol consists of four sections (see Fig. 2.2). Some of these sections (e.g., the Message Body) may be empty depending on the protocol operation.
システムプロトコルで交換される各メッセージは、4つのセクションで構成されています（図2.2を参照）。これらのセクションの一部（メッセージ本文など）は、プロトコル操作に応じて空になる場合があります。
The Message Envelope must always be present. It has a fixed size of 20 octets. The Message Envelope does not carry any application layer information and is primarily used to help deliver the message. Content in the Message Envelope is not protected by the digital signature in the Message Credential.
メッセージエンベロープは常に存在する必要があります。20オクテットの固定サイズです。メッセージエンベロープにはアプリケーションレイヤー情報が含まれておらず、主にメッセージの配信に役立ちます。メッセージエンベロープのコンテンツは、メッセージ資格情報のデジタル署名によって保護されていません。
The Message Header must always be present as well. It has a fixed size of 24 octets and holds the common data fields of all messages exchanged between client and server. These include the operation code, the response code, and the control options for each protocol operation. Content in the Message Header is protected by the digital signature in the Message Credential.
メッセージヘッダーも常に存在する必要があります。24オクテットの固定サイズで、クライアントとサーバーの間で交換されるすべてのメッセージの共通データフィールドを保持します。これらには、操作コード、応答コード、および各プロトコル操作の制御オプションが含まれます。メッセージヘッダーのコンテンツは、メッセージ資格情報のデジタル署名によって保護されています。
The Message Body contains data specific to each protocol operation. Its format varies according to the operation code and the response code in the Message Header. The Message Body may be empty. Content in the Message Body is protected by the digital signature in the Message Credential.
メッセージ本文には、各プロトコル操作に固有のデータが含まれています。その形式は、操作コードとメッセージヘッダーの応答コードによって異なります。メッセージ本文が空になる可能性があります。メッセージ本文のコンテンツは、メッセージ資格情報のデジタル署名によって保護されています。
The Message Credential provides a mechanism for transport security for any message exchanged between the client and server. A non-empty Message Credential may contain the digital signature from the originator of the message or the one-way Message Authentication Code (MAC) based on a pre-established session key. The Message Credential may be used to authenticate the message between the client and server. It can also be used to check data integrity after its transmission.
メッセージ資格情報は、クライアントとサーバーの間で交換されるメッセージの輸送セキュリティのメカニズムを提供します。非空白のメッセージ資格情報には、事前に確立されたセッションキーに基づいて、メッセージの起源者または一元配置メッセージ認証コード（MAC）からのデジタル署名を含めることができます。メッセージ資格情報は、クライアントとサーバー間のメッセージを認証するために使用できます。また、送信後にデータの整合性を確認するためにも使用できます。
.----------------------.
| | ; Message wrapper for proper message
| Message Envelope | ; delivery. Not protected by the
| | ; digital signature in the Message
| | ; Credential.
|----------------------|
| | ; Common data fields for all handle
| Message Header | ; operations.
| |
|----------------------|
| | ; Specific data fields for each
| Message Body | ; request/response.
| |
|----------------------|
| | ; Contains digital signature or
| Message Credential | ; message authentication code (MAC)
| | ; upon Message Header and Message
'----------------------' ; Body.
Fig 2.2: Message format under the Handle protocol
図2.2：ハンドルプロトコルの下のメッセージ形式
Each message begins with a Message Envelope under the Handle protocol. If a message has to be truncated before its transmission, each truncated portion must also begin with a Message Envelope.
各メッセージは、ハンドルプロトコルの下のメッセージエンベロープから始まります。メッセージを送信前に切り捨てる必要がある場合、各切り捨てられた部分もメッセージエンベロープで開始する必要があります。
The Message Envelope allows the reassembly of the message at the receiving end. It has a fixed size of 20 octets and consists of seven fields:
メッセージエンベロープは、受信側でメッセージの再組み立てを可能にします。20オクテットの固定サイズで、7つのフィールドで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| MajorVersion | MinorVersion | MessageFlag |
|---------------------------------------------------------------|
| SessionId |
|---------------------------------------------------------------|
| RequestId |
|---------------------------------------------------------------|
| SequenceNumber |
|---------------------------------------------------------------|
| MessageLength |
'---------------------------------------------------------------'
The <MajorVersion> and <MinorVersion> are used to identify the version of the Handle protocol. Each of them is defined as a one-byte unsigned integer. This specification defines the protocol version whose <MajorVersion> is 2 and <MinorVersion> is 1.
<majorversion>および<minuterversion>は、ハンドルプロトコルのバージョンを識別するために使用されます。それらのそれぞれは、1バイトの符号なし整数として定義されています。この仕様では、<majorversion>が2、<miniorversion>が1であるプロトコルバージョンを定義します。
<MajorVersion> and <MinorVersion> are designed to allow future backward compatibility. A difference in <MajorVersion> indicates major variation in the protocol format and the party with the lower <MajorVersion> will have to upgrade its software to ensure precise communication. An increment in <MinorVersion> is made when additional capabilities are added to the protocol without any major change to the message format.
<majorversion>および<minuterversion>は、将来の後方互換性を可能にするように設計されています。<majorversion>の違いは、プロトコル形式の大きな変動を示しており、低い<majorversion>の当事者は、正確な通信を確保するためにソフトウェアをアップグレードする必要があります。メッセージ形式に大きな変更を加えることなく、追加の機能がプロトコルに追加されると、<minilversion>の増分が行われます。
The <MessageFlag> consists of two octets defined as follows:
<messageflag>は、次のように定義された2つのオクテットで構成されています。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|CP |EC |TC | Reserved |
'---------------------------------------------------------------'
Bit 0 is the CP (ComPressed) flag that indicates whether the message (excluding the Message Envelope) is compressed. If the CP bit is set (to 1), the message is compressed. Otherwise, the message is not compressed. The Handle protocol uses the same compression method as used by the FTP protocol[8].
ビット0は、メッセージ（メッセージエンベロープを除く）が圧縮されているかどうかを示すCP（圧縮）フラグです。CPビットが設定されている場合（1に）、メッセージは圧縮されます。それ以外の場合、メッセージは圧縮されていません。ハンドルプロトコルは、FTPプロトコル[8]で使用されるのと同じ圧縮方法を使用します。
Bit 1 is the EC (EnCrypted) flag that indicates whether the message (excluding the Message Envelope) is encrypted. The EC bit should only be set under an established session where a session key is in place. If the EC bit is set (to 1), the message is encrypted using the session key. Otherwise the message is not encrypted.
ビット1は、メッセージ（メッセージエンベロープを除く）が暗号化されているかどうかを示すEC（暗号化）フラグです。ECビットは、セッションキーが設置されている確立されたセッションでのみ設定する必要があります。ECビットが設定されている場合（1に）、メッセージはセッションキーを使用して暗号化されます。それ以外の場合、メッセージは暗号化されていません。
Bit 2 is the TC (TrunCated) flag that indicates whether this is a truncated message. Message truncation happens most often when transmitting a large message over the UDP protocol. Details of message truncation (or fragmentation) will be discussed in section 2.3.
ビット2は、これが切り捨てられたメッセージであるかどうかを示すTC（切り捨てられた）フラグです。メッセージの切り捨ては、UDPプロトコルを介して大きなメッセージを送信するときに最も頻繁に発生します。メッセージの切り捨て（または断片化）の詳細については、セクション2.3で説明します。
Bits 3 to 15 are currently reserved and must be set to zero.
現在、ビット3〜15は予約されており、ゼロに設定する必要があります。
The <SessionId> is a four-byte unsigned integer that identifies a communication session between the client and server.
<sessionId>は、クライアントとサーバーの間の通信セッションを識別する4バイトの符号なし整数です。
Session and its <SessionId> are assigned by a server, either upon an explicit request from a client or when multiple message exchanges are expected to fulfill the client's request. For example, the server will assign a unique <SessionId> in its response if it has to authenticate the client. A client may explicitly ask the server to set up a session as a virtually private communication channel like SSL [4]. Requests from clients without an established session must have their <SessionId> set to zero. The server must assign a unique non-zero <SessionId> for each new session. It is also responsible for terminating those sessions that are not in use after some period of time.
セッションとその<SessionId>は、クライアントからの明示的な要求に応じて、または複数のメッセージ交換がクライアントの要求を満たすことが期待される場合に、サーバーによって割り当てられます。たとえば、サーバーは、クライアントを認証する必要がある場合、応答に一意の<sessionId>を割り当てます。クライアントは、SSL [4]のような実質的にプライベートなコミュニケーションチャネルとしてセッションを設定するようサーバーに明示的に依頼することができます。確立されたセッションのないクライアントからのリクエストには、<sessionId>がゼロに設定されている必要があります。サーバーは、新しいセッションごとに一意のゼロ<sessionId>を割り当てる必要があります。また、数時間後に使用されていないセッションを終了する責任があります。
Both clients and servers must maintain the same <SessionId> for messages exchanged under an established session. A message whose <SessionId> is zero indicates that no session has been established.
クライアントとサーバーの両方が、確立されたセッションで交換されたメッセージについて、同じ<sessionId>を維持する必要があります。<sessionId>がゼロであるメッセージは、セッションが確立されていないことを示しています。
The session and its state information may be shared among multiple handle operations. They may also be shared over multiple TCP connections as well. Once a session is established, both client and server must maintain their state information according to the <SessionId>. The state information may include the stage of the conversation, the other party's authentication information, and the session key that was established for message encryption or authentication. Details of these are discussed in section 3.8.
セッションとその状態情報は、複数のハンドル操作で共有される場合があります。また、複数のTCP接続でも共有される場合があります。セッションが確立されると、クライアントとサーバーの両方が<sessionId>に従って状態情報を維持する必要があります。州の情報には、会話の段階、相手の認証情報、およびメッセージ暗号化または認証のために確立されたセッションキーが含まれる場合があります。これらの詳細については、セクション3.8で説明します。
Each request from a client is identified by a <RequestId>, a 4-byte unsigned integer set by the client. Each <RequestId> must be unique from all other outstanding requests from the same client. The <RequestId> allows the client to keep track of its requests, and any response from the server must include the correct <RequestId>.
クライアントからの各リクエストは、クライアントが設定した4バイトの署名されていない整数である<requestId>によって識別されます。それぞれの<QuestionID>は、同じクライアントからの他のすべての未解決のリクエストから一意でなければなりません。<questiond>により、クライアントはリクエストを追跡でき、サーバーからの応答には正しい<questiond>が含まれている必要があります。
Messages under the Handle protocol may be truncated during their transmission (e.g., under UDP). The <SequenceNumber> is a 4-byte unsigned integer used as a counter to keep track of each truncated portion of the original message. The message recipient can reassemble the original message based on the <SequenceNumber>. The <SequenceNumber> must start with 0 for each message. Each truncated message must set its TC flag in the Message Envelope. Messages that are not truncated must set their <SequenceNumber> to zero.
ハンドルプロトコルの下でのメッセージは、送信中に切り捨てられる場合があります（UDPの下など）。<sequencenumber>は、元のメッセージの各切り捨てられた部分を追跡するためにカウンターとして使用される4バイトの符号なし整数です。メッセージ受信者は、<sequencenumber>に基づいて元のメッセージを再組み立てることができます。<sequencenumber>は、各メッセージの0から始まる必要があります。各切り捨てられたメッセージは、TCフラグをメッセージエンベロープに設定する必要があります。切り捨てられていないメッセージは、<sequencenumber>をゼロに設定する必要があります。
A 4-byte unsigned integer that specifies the total number of octets of any message, excluding those in the Message Envelope. The length of any single message exchanged under the Handle protocol is limited by the range of a 4-byte unsigned integer. Longer data can be transmitted as multiple messages with a common <RequestId>.
メッセージエンベロープのものを除く、メッセージのオクテットの総数を指定する4バイトの符号なし整数。ハンドルプロトコルの下で交換される単一のメッセージの長さは、4バイトの符号なし整数の範囲によって制限されます。より長いデータは、共通<RequestID>を使用して複数のメッセージとして送信できます。
The Message Header contains the common data elements among any protocol operation. It has a fixed size of 24 octets and consists of eight fields.
メッセージヘッダーには、プロトコル操作の中に共通のデータ要素が含まれています。24オクテットの固定サイズで、8つのフィールドで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| OpCode |
|---------------------------------------------------------------|
| ResponseCode |
|---------------------------------------------------------------|
| OpFlag |
|---------------------------------------------------------------|
| SiteInfoSerialNumber | RecursionCount| |
|---------------------------------------------------------------|
| ExpirationTime |
|---------------------------------------------------------------|
| BodyLength |
'---------------------------------------------------------------'
Every message that is not truncated must have a Message Header. If a message has to be truncated for its transmission, the Message Header must appear in the first truncated portion of the message.
切り捨てられていないすべてのメッセージには、メッセージヘッダーが必要です。送信用にメッセージを切り捨てなければならない場合、メッセージヘッダーがメッセージの最初の切り捨てられた部分に表示されなければなりません。
This is different from the Message Envelope, which appears in each truncated portion of the message.
これは、メッセージエンベロープとは異なり、メッセージの各切り捨てられた部分に表示されます。
The <OpCode> stands for operation code, which is a four-byte unsigned integer that specifies the intended operation. The following table lists the <OpCode>s that MUST be supported by all implementations in order to conform to the base protocol specification. Each operation code is given a symbolic name that is used throughout this document for easy reference.
<opcode>は、操作コードの略です。これは、意図した操作を指定する4バイトの符号なし整数です。次の表には、ベースプロトコル仕様に準拠するために、すべての実装でサポートする必要がある<opcode> sを示します。各操作コードには、簡単に参照できるようにこのドキュメント全体で使用されるシンボリック名が与えられます。
Op_Code Symbolic Name Remark
--------- ------------- ------
0 OC_RESERVED Reserved
1 OC_RESOLUTION Handle query
2 OC_GET_SITEINFO Get HS_SITE values
100 OC_CREATE_HANDLE Create new handle
101 OC_DELETE_HANDLE Delete existing handle
102 OC_ADD_VALUE Add handle value(s)
103 OC_REMOVE_VALUE Remove handle value(s)
104 OC_MODIFY_VALUE Modify handle value(s)
105 OC_LIST_HANDLE List handles
106 OC_LIST_NA List sub-naming authorities
200 OC_CHALLENGE_RESPONSE Response to challenge 201 OC_VERIFY_RESPONSE Verify challenge response
200 oc_challenge_responseチャレンジ201への応答oc_verify_response検証課題応答
300 : { Reserved for handle server administration } 399
300：{ハンドルサーバー管理用に予約} 399
400 OC_SESSION_SETUP Session setup request 401 OC_SESSION_TERMINATE Session termination request 402 OC_SESSION_EXCHANGEKEY Session key exchange
400 oc_session_setupセッションセットアップリクエスト401 oc_session_terminateセッション終了リクエスト402 oc_session_exchangekeyセッションキーExchange
A detailed description of each of these <OpCode>s can be found in section 3 of this document. In general, clients use the <OpCode> to tell the server what kind of handle operation they want to accomplish. Response from the server must maintain the same <OpCode> as the original request and use the <ResponseCode> to indicate the result.
これらのそれぞれの<opcode> sの詳細な説明は、このドキュメントのセクション3に記載されています。一般に、クライアントは<opcode>を使用して、どのようなハンドル操作を達成したいかをサーバーに伝えます。サーバーからの応答は、元のリクエストと同じ<opcode>を維持し、<lestsecode>を使用して結果を示しなければなりません。
The <ResponseCode> is a 4-byte unsigned integer that is given by a server to indicate the result of any service request. The list of <ResponseCode>s used in the Handle protocol is defined in the following table. Each response code is given a symbolic name that is used throughout this document for easy reference.
<ResponseCode>は、サービス要求の結果を示すためにサーバーによって指定された4バイトの符号なし整数です。ハンドルプロトコルで使用されている<応答> sのリストを次の表に示します。各応答コードには、このドキュメント全体で使用されるシンボリック名が与えられ、簡単に参照されます。
Res. Code Symbolic Name Remark
--------- ------------- ------
0 RC_RESERVED Reserved for request
1 RC_SUCCESS Success response
2 RC_ERROR General error
3 RC_SERVER_BUSY Server too busy to respond
4 RC_PROTOCOL_ERROR Corrupted or
unrecognizable message
5 RC_OPERATION_DENIED Unsupported operation
6 RC_RECUR_LIMIT_EXCEEDED Too many recursions for
the request
100 RC_HANDLE_NOT_FOUND Handle not found 101 RC_HANDLE_ALREADY_EXIST Handle already exists 102 RC_INVALID_HANDLE Encoding (or syntax) error
100 RC_HANDLE_NOT_FOUNDハンドルが見つからない101 RC_HANDLE_ALREADY_EXISTハンドルはすでに存在します
200 RC_VALUE_NOT_FOUND Value not found 201 RC_VALUE_ALREADY_EXIST Value already exists 202 RC_VALUE_INVALID Invalid handle value
200 RC_VALUE_NOT_FOUND値は見つかりません201 RC_VALUE_ALREADY_EXIST値はすでに存在します
300 RC_EXPIRED_SITE_INFO SITE_INFO out of date 301 RC_SERVER_NOT_RESP Server not responsible 302 RC_SERVICE_REFERRAL Server referral 303 RC_NA_DELEGATE Naming authority delegation takes place.
300 RC_EXPIRED_SITE_INFO SITE_INFO日付から301 RC_SERVER_NOT_RESP SERVER責任302 RC_SERVICE_REFERARAL SERVER紹介303 RC_NA_DELEGATE Authority Delegationが行われます。
400 RC_NOT_AUTHORIZED Not authorized/permitted 401 RC_ACCESS_DENIED No access to data 402 RC_AUTHEN_NEEDED Authentication required 403 RC_AUTHEN_FAILED Failed to authenticate 404 RC_INVALID_CREDENTIAL Invalid credential 405 RC_AUTHEN_TIMEOUT Authentication timed out 406 RC_UNABLE_TO_AUTHEN Unable to authenticate
400 rc_not_authorized承認/許可されていない401 RC_ACCESS_DENIEDデータへのアクセスなし
500 RC_SESSION_TIMEOUT Session expired 501 RC_SESSION_FAILED Unable to establish session 502 RC_NO_SESSION_KEY No session yet available 503 RC_SESSION_NO_SUPPORT Session not supported 504 RC_SESSION_KEY_INVALID Invalid session key
500 RC_SESSION_TIMEOUTセッションの期限切れ501 RC_SESSION_FAILEDセッションを確立できなかった502 RC_NO_SESSION_KEYセッションなし
900 RC_TRYING Request under processing
901 RC_FORWARDED Request forwarded to
another server
902 RC_QUEUED Request queued for later
processing
Response codes under 10000 are reserved for system use. Any message with a response code under 10000 but not listed above should be treated as an unknown error. Response codes above 10000 are user defined and can be used for application specific purposes.
10000未満の応答コードは、システムの使用のために予約されています。10000未満の応答コードを含むが、上記のメッセージはないメッセージは、未知のエラーとして扱う必要があります。10000を超える応答コードはユーザー定義であり、アプリケーション固有の目的に使用できます。
Detailed descriptions of these <ResponseCode>s can be found in section 3 of this document. In general, any request from a client must have its <ResponseCode> set to 0. The response message from the server must have a non-zero <ResponseCode> to indicate the result. For example, a response message from a server with <ResponseCode> set to RC_SUCCESS indicates that the server has successfully fulfilled the client's request.
これらの<ResponseCode> sの詳細な説明は、このドキュメントのセクション3に記載されています。一般に、クライアントからのリクエストは、<応答>を0に設定する必要があります。サーバーからの応答メッセージには、結果を示すためにゼロ以外の<ressupecode>が必要です。たとえば、RC_SUCCESSに設定された<ResponseCode>を備えたサーバーからの応答メッセージは、サーバーがクライアントの要求を正常に満たしたことを示します。
The <OpFlag> is a 32-bit bit-mask that defines various control options for protocol operation. The following figure shows the location of each option flag in the <OpFlag> field.
<opflag>は、プロトコル操作のさまざまな制御オプションを定義する32ビットビットマスクです。次の図は、<opflag>フィールドの各オプションフラグの位置を示しています。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|AT |CT |ENC|REC|CA |CN |KC |PO |RD | Reserved |
|---------------------------------------------------------------|
| Reserved |
'---------------------------------------------------------------'
AT - AuThoritative bit. A request with the AT bit set (to 1) indicates that the request should be directed to the primary service site (instead of any mirroring sites). A response message with the AT bit set (to 1) indicates that the message is returned from a primary server (within the primary service site).
at-権威あるビット。AT BITセット（1に）のリクエストは、リクエストを（ミラーリングサイトの代わりに）プライマリサービスサイトに送信する必要があることを示します。AT BITセット（1に）を使用した応答メッセージは、メッセージがプライマリサーバー（プライマリサービスサイト内）から返されることを示します。
CT - CerTified bit. A request with the CT bit set (to 1) asks the server to sign its response with its digital signature. A response with the CT bit set (to 1) indicates that the message is signed. The server must sign its response if the request has its CT bit set (to 1). If the server fails to provide a valid signature in its response, the client should discard the response and treat the request as failed.
CT-認定ビット。CTビットセット（1）を使用したリクエストは、サーバーにデジタル署名で応答に署名するように求めます。CTビットセット（1に）を使用した応答は、メッセージが署名されていることを示します。リクエストにCTビットが設定されている場合、サーバーは応答に署名する必要があります（1に）。サーバーが応答に有効な署名を提供できない場合、クライアントは応答を破棄し、リクエストを失敗したと扱う必要があります。
ENC - ENCryption bit. A request with the ENC bit set (to 1) requires the server to encrypt its response using the pre-established session key.
enc -暗号化ビット。ENCビットセット（1に）を使用したリクエストでは、事前に確立されたセッションキーを使用して、サーバーが応答を暗号化する必要があります。
REC - RECursive bit. A request with the REC bit set (to 1) asks the server to forward the query on behalf of the client if the request has to be processed by another handle server. The server may honor the request by forwarding the request to the appropriate handle server and passing on any result back to the client. The server may also deny any such request by sending a response with <ResponseCode> set to RC_SERVER_NOT_RESP.
rec-再帰ビット。RECビットセット（1）を使用したリクエストは、リクエストを別のハンドルサーバーによって処理する必要がある場合、クライアントに代わってクエリを転送するようサーバーに要求します。サーバーは、リクエストを適切なハンドルサーバーに転送し、結果をクライアントに戻すことにより、リクエストを尊重する場合があります。サーバーは、rc_server_not_respに設定された<ressupecode>を使用して応答を送信することにより、そのような要求を拒否する場合もあります。
CA - Cache Authentication. A request with the CA bit set (to 1) asks the caching server (if any) to authenticate any server response (e.g., verifying the server's signature) on behalf of the client. A response with the CA bit set (to 1) indicates that the response has been authenticated by the caching server.
CA-認証をキャッシュします。CAビットセット（1に）を使用したリクエストは、クライアントに代わってサーバーの応答（たとえば、サーバーの署名の検証）を認証するようにキャッシュサーバー（もしあれば）を求めます。CAビットセット（1に）を使用した応答は、キャッシュサーバーによって応答が認証されていることを示します。
CN - ContiNuous bit. A message with the CN bit set (to 1) tells the message recipient that more messages that are part of the same request (or response) will follow. This happens if a request (or response) has data that is too large to fit into any single message and has to be fragmented into multiple messages.
CN-連続ビット。CNビットセット（1に）を使用したメッセージは、同じ要求（または応答）の一部であるより多くのメッセージが続くことを受信者に伝えます。これは、要求（または応答）に、単一のメッセージに収まるには大きすぎて複数のメッセージに断片化する必要があるデータがある場合に発生します。
KC - Keep Connection bit. A message with the KC bit set requires the message recipient to keep the TCP connection open (after the response is sent back). This allows the same TCP connection to be used for multiple handle operations.
KC-接続ビットを維持します。KCビットセットを使用したメッセージでは、メッセージ受信者がTCP接続を開いたままにしておく必要があります（応答が送信された後）。これにより、同じTCP接続を複数のハンドル操作に使用できます。
PO - Public Only bit. Used by query operations only. A query request with the PO bit set (to 1) indicates that the client is only asking for handle values that have the PUB_READ permission. A request with PO bit set to zero asks for all the handle values regardless of their read permission. If any of the handle values require ADMIN_READ permission, the server must authenticate the client as the handle administrator.
PO-パブリックのみのビット。クエリ操作のみで使用されます。POビットセット（1に）を使用したクエリリクエストは、クライアントがpub_read許可を持つハンドル値のみを要求していることを示します。POビットがゼロに設定されたリクエストは、読み取り許可に関係なく、すべてのハンドル値を要求します。ハンドル値のいずれかがadmin_read許可を必要とする場合、サーバーはクライアントをハンドル管理者として認証する必要があります。
RD - Request-Digest bit. A request with the RD bit set (to 1) asks the server to include in its response the message digest of the request. A response message with the RD bit set (to 1) indicates that the first field in the Message Body contains the message digest of the original request. The message digest can be used to check the integrity of the server response. Details of these are discussed later in this document.
RD-リクエストダイジェストビット。RDビットセット（1）を使用したリクエストは、サーバーに、リクエストのメッセージがダイジェストされるメッセージをその応答に含めるように依頼します。RDビットセット（1に）を使用した応答メッセージは、メッセージ本文の最初のフィールドに元のリクエストのメッセージダイジェストが含まれていることを示します。メッセージダイジェストを使用して、サーバーの応答の整合性を確認できます。これらの詳細については、このドキュメントの後半で説明します。
All other bits in the <OpFlag> field are reserved and must be set to zero.
<opflag>フィールドの他のすべてのビットは予約されており、ゼロに設定する必要があります。
In general, servers must honor the <OpFlag> specified in the request. If a requested option cannot be met, the server should return an error message with the proper <ResponseCode> as defined in the previous section.
一般に、サーバーはリクエストで指定された<Opflag>を尊重する必要があります。要求されたオプションを満たすことができない場合、サーバーは前のセクションで定義されている適切な<応答>を使用してエラーメッセージを返す必要があります。
The <SiteInfoSerialNumber> is a two-byte unsigned integer. The <SiteInfoSerialNumber> in a request refers to the <SerialNumber> of the HS_SITE value used by the client (to access the server). Servers can check the <SiteInfoSerialNumber> in the request to find out if the client has up-to-date service information.
<SiteInFoserialNumber>は、2バイトの符号なし整数です。リクエストの<SiteInFoserialNumber>は、クライアントが使用するHS_SITE値の<SerialNumber>（サーバーにアクセスするため）を指します。サーバーは、リクエストで<SiteInfoserialNumber>を確認して、クライアントが最新のサービス情報を持っているかどうかを確認できます。
When possible, the server should fulfill a client's request even if the service information used by the client is out-of-date. However, the response message should specify the latest version of service information in the <SiteInforSerialNumber> field. Clients with out-of-date service information can update the service information from the Global Handle Registry. If the server cannot fulfill a client's request due to expired service information, it should reject the request and return an error message with <ResponseCode> set to RC_EXPIRED_SITE_INFO.
可能であれば、クライアントが使用するサービス情報が時代遅れであっても、サーバーはクライアントの要求を満たす必要があります。ただし、応答メッセージは、<SiteInforSerialNumber>フィールドにサービス情報の最新バージョンを指定する必要があります。時代遅れのサービス情報を持つクライアントは、グローバルハンドルレジストリからサービス情報を更新できます。サーバーが期限切れのサービス情報のためにクライアントのリクエストを満たせない場合、RC_EXPIRED_SITE_INFOに設定された<ResponseCode>を使用してリクエストを拒否し、エラーメッセージを返す必要があります。
The <RecursionCount> is a one-byte unsigned integer that specifies the number of service recursions. Service recursion happens if the server has to forward the client's request to another server. Any request directly from the client must have its <RecursionCount> set to 0. If the server has to send a recursive request on behalf of the client, it must increment the <RecursionCount> by 1. Any response from the server must maintain the same <RecursionCount> as the one in the request. To prevent an infinite loop of service recursion, the server should be configurable to stop sending a recursive request when the <RecursionCount> reaches a certain value.
<RecursionCount>は、サービス再帰の数を指定する1バイトの署名のない整数です。サーバーがクライアントの要求を別のサーバーに転送する必要がある場合、サービスの再帰が発生します。クライアントからの直接リクエストには、<cursioncount>が0に設定されている必要があります。サーバーがクライアントに代わって再帰リクエストを送信する必要がある場合、1。<RecursionCount>リクエストのものとして。サービスの再帰の無限ループを防ぐために、<RecursionCount>が特定の値に達したときに再帰要求の送信を停止するようにサーバーを構成可能にする必要があります。
The <ExpirationTime> is a 4-byte unsigned integer that specifies the time when the message should be considered expired, relative to January 1st, 1970 GMT, in seconds. It is set to zero if no expiration is expected.
<ExpirationTime>は、1970年1月1日のGMTと比較して、メッセージが期限切れと見なされる時間を数秒単位で指定する4バイトの署名のない整数です。有効期限が予想されない場合、ゼロに設定されます。
The <BodyLength> is a 4-byte unsigned integer that specifies the number of octets in the Message Body. The <BodyLength> does not count the octets in the Message Header or those in the Message Credential.
<bodyLength>は、メッセージ本文のオクテットの数を指定する4バイトの符号なし整数です。<BodyLength>は、メッセージヘッダーまたはメッセージ資格情報のオクテットをカウントしません。
The Message Body always follows the Message Header. The number of octets in the Message Body can be determined from the <BodyLength> in the Message Header. The Message Body may be empty. The exact format of the Message Body depends on the <OpCode> and the <ResponseCode> in the Message Header. Details of the Message Body under each <OpCode> and <ResponseCode> are described in section 3 of this document.
メッセージ本文は常にメッセージヘッダーに従います。メッセージ本文のオクテットの数は、メッセージヘッダーの<BodyLength>から決定できます。メッセージ本文が空になる可能性があります。メッセージ本文の正確な形式は、メッセージヘッダーの<opcode>と<sfrestecode>に依存します。各<opcode>および<responsecode>の下のメッセージ本文の詳細については、このドキュメントのセクション3で説明します。
For any response message, if the Message Header has its RD bit (in <OpFlag>) set to 1, the Message Body must begin with the message digest of the original request. The message digest is defined as follows:
応答メッセージの場合、メッセージヘッダーにRDビット（<Opflag>）が1に設定されている場合、メッセージ本文は元のリクエストのメッセージダイジェストから開始する必要があります。メッセージダイジェストは次のように定義されています。
<RequestDigest> ::= <DigestAlgorithmIdentifier>
<MessageDigest>
where
ただし
<DigestAlgorithmIdentifier> An octet that identifies the algorithm used to generate the message digest. If the octet is set to 1, the digest is generated using the MD5 [9] algorithm. If the octet is set to 2, SHA-1 [10] algorithm is used.
<DigestalGorithMidentifier>メッセージダイジェストを生成するために使用されるアルゴリズムを識別するオクテット。オクテットが1に設定されている場合、MD5 [9]アルゴリズムを使用してダイジェストが生成されます。オクテットが2に設定されている場合、SHA-1 [10]アルゴリズムが使用されます。
<MessageDigest> The message digest itself. It is calculated upon the Message Header and the Message Body of the original request. The length of the field is fixed according to the digest algorithm. For MD5 algorithm, the length is 16 octets. For SHA-1, the length is 20 octets.
<MesagedGigest>メッセージ自体。メッセージヘッダーと元のリクエストのメッセージ本文で計算されます。フィールドの長さは、ダイジェストアルゴリズムに従って固定されています。MD5アルゴリズムの場合、長さは16オクテットです。SHA-1の場合、長さは20オクテットです。
The Message Body may be truncated into multiple portions during its transmission (e.g., over UDP). Recipients of such a message may reassemble the Message Body from each portion based on the <SequenceNumber> in the Message Envelope.
メッセージ本文は、その伝送中に複数の部分に切り捨てられる可能性があります（例：UDP）。このようなメッセージの受信者は、メッセージエンベロープの<SequenCenumber>に基づいて、各部分からメッセージ本文を再組み立てることができます。
The Message Credential is primarily used to carry any digital signatures signed by the message issuer. It may also carry the Message Authentication Code (MAC) if a session key has been established. The Message Credential is used to protect contents in the Message Header and the Message Body from being tampered with during transmission. The format of the Message Credential is designed to be semantically compatible with PKCS#7 [5]. Each Message Credential consists of the following fields:
メッセージ資格情報は、主にメッセージ発行者によって署名されたデジタル署名を携帯するために使用されます。また、セッションキーが確立されている場合、メッセージ認証コード（MAC）を搭載する場合があります。メッセージ資格情報は、メッセージヘッダー内の内容を保護し、メッセージ本文が送信中に改ざんされないように使用されます。メッセージ資格情報の形式は、PKCS＃7 [5]とセマンティックに互換性があるように設計されています。各メッセージ資格情報は、次のフィールドで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| CredentialLength |
|---------------------------------------------------------------|
| Version | Reserved | Options |
|---------------------------------------------------------------|
|
| Signer: <Handle, Index>
|
|---------------------------------------------------------------|
| Type (UTF8-String) |
|---------------------------------------------------------------|
|
| SignedInfo: <Length> : 4-byte unsigned integer
| DigestAlgorithm: <UTF8-String>
| SignedData: <Length, Signature>
|
'---------------------------------------------------------------'
where
ただし
<CredentialLength> A 4-byte unsigned integer that specifies the number of octets in the Message Credential. It must be set to zero if the message has no Message Credential.
<credentiallength>メッセージ資格情報のオクテットの数を指定する4バイトの符号なし整数。メッセージにメッセージ資格情報がない場合は、ゼロに設定する必要があります。
<Version> An octet that identifies the version number of the Message Credential. The version number specified in this document is zero.
<バージョン>メッセージ資格情報のバージョン番号を識別するオクテット。このドキュメントで指定されたバージョン番号はゼロです。
<Reserved> An octet that must be set to zero.
<Reserved>ゼロに設定する必要があるオクテット。
<Options> Two octets reserved for various cryptography options.
<オプション>さまざまな暗号化オプション用に予約された2つのオクテット。
<Signer> ::= <HANDLE>
<INDEX>
A reference to a handle value in terms of the <HANDLE> and the
<INDEX> of the handle value. The handle value may contain the
public key, or the X.509 certificate, that can be used to
validate the digital signature.
<Type> A UTF8-String that indicates the type of content in the <SignedInfo> field (described below). It may contain HS_DIGEST if <SignedInfo> contains the message digest, or HS_MAC if <SignedInfo> contains the Message Authentication Code (MAC). The <Type> field will specify the signature algorithm identifier if <SignedInfo> contains a digital signature. For example, with the <Type> field set to HS_SIGNED_PSS, the <SignedInfo> field will contain the digital signature generated using the RSA-PSS algorithm [16]. If the <Type> field is set to HS_SIGNED, the <SignedInfo> field will contain the digital signature generated from a DSA public key pair.
<Type> <SignedInfo>フィールドのコンテンツのタイプを示すUTF8-STRING（以下で説明）。<signedInfo>にメッセージダイジェストが含まれている場合、hs_digestを含む場合があります。<type>フィールドは、<signedInfo>にデジタル署名が含まれている場合、署名アルゴリズム識別子を指定します。たとえば、<Type>フィールドがHS_SIGNED_PSSに設定されている場合、<SignedInfo>フィールドには、RSA-PSSアルゴリズム[16]を使用して生成されたデジタル署名が含まれます。<Type>フィールドがHS_Signedに設定されている場合、<SigneDinfo>フィールドには、DSA公開キーペアから生成されたデジタル署名が含まれます。
<SignedInfo> ::= <Length>
<DigestAlgorithm>
<SignedData>
where
<Length> A 4-byte unsigned integer that specifies the number of octets in the <SignedInfo> field.
<length> <signedInfo>フィールドのオクテットの数を指定する4バイトの符号なし整数。
<DigestAlgorithm> A UTF8-String that refers to the digest algorithm used to generate the digital signature. For example, the value "SHA-1" indicates that the SHA-1 algorithm is used to generate the message digest for the signature.
<DigestalGorithm>デジタル署名を生成するために使用されるダイジェストアルゴリズムを指すUTF8-STRING。たとえば、値「SHA-1」は、SHA-1アルゴリズムが署名のメッセージダイジェストを生成するために使用されることを示します。
<SignedData> ::= <LENGTH>
<SIGNATURE>
where
<LENGTH> A 4-byte unsigned integer that specifies the number of octets in the <SIGNATURE>.
<length> <signature>のオクテットの数を指定する4バイトの符号なし整数。
<SIGNATURE> Contains the digital signature or the MAC over the Message Header and Message Body. The syntax and semantics of the signature depend on the <Type> field and the public key referenced in the <Signer> field. For example, if the <Type> field is "HS_SIGNED" and the public key referred to by the <Signer> field is a DSA [6] public key, the signature will be the ASN.1 octet string representation of the parameter R and S as described in [7]. If the <Signer> field refers to a handle value that contains a X.509 certificate, the signature should be encoded according to RFC 3279 and RFC 3280 [14, 15].
<Signature>メッセージヘッダーとメッセージ本文上にデジタル署名またはMacが含まれています。署名の構文とセマンティクスは、<Type>フィールドと<Signer>フィールドで参照されている公開キーに依存します。たとえば、<Type>フィールドが「HS_SIGN」であり、<Signer>フィールドで言及されている公開キーがDSA [6]の公開である場合、署名はパラメーターRのASN.1オクテット文字列表現となります。[7]に記載されているS。<signer>フィールドがx.509証明書を含むハンドル値を指す場合、署名はRFC 3279およびRFC 3280 [14、15]に従ってエンコードする必要があります。
The Message Credential may contain the message authentication code (MAC) generated using a pre-established session key. In this case, the <Signer> field must set its <HANDLE> to a zero-length UTF8-String and its <INDEX> to the <SessionId> specified in the Message Envelope. The <Signature> field must contain the MAC in its <SIGNATURE> field. The MAC is the result of the one-way hash over the concatenation of the session key, the <Message Header>, the <MessageBody>, and the session key again.
メッセージ資格情報には、事前に確立されたセッションキーを使用して生成されたメッセージ認証コード（MAC）が含まれる場合があります。この場合、<signer>フィールドは、<handle>をゼロの長さのutf8-stringに設定し、<インデックス>をメッセージエンベロープで指定した<sessiond>に設定する必要があります。<Signature>フィールドには、<Signature>フィールドにMacを含める必要があります。MACは、セッションキー、<メッセージヘッダー>、<メッセージボディ>、およびセッションキーの連結に対する一方向ハッシュの結果です。
The Message Credential in a response message may contain the digital signature signed by the server. The server's public key can be found in the service information used by the client to send the request to the server. In this case, the client should ignore any reference in the <Signer> field and use the public key in the service information to verify the signature.
応答メッセージのメッセージ資格情報には、サーバーが署名したデジタル署名が含まれる場合があります。サーバーの公開キーは、リクエストをサーバーに送信するためにクライアントが使用するサービス情報に記載されています。この場合、クライアントは<signer>フィールドの参照を無視し、サービス情報の公開キーを使用して署名を確認する必要があります。
The Message Credential can also be used for non-repudiation purposes. This happens if the Message Credential contains a server's digital signature. The signature may be used as evidence to demonstrate that the server has rendered its service in response to a client's request.
メッセージ資格情報は、非和解の目的でも使用できます。これは、メッセージ資格情報にサーバーのデジタル署名が含まれている場合に発生します。署名は、クライアントの要求に応じてサーバーがサービスを提供したことを示す証拠として使用できます。
The Message Credential provides a mechanism for safe transmission of any message between the client and server. Any message whose Message Header and Message Body complies with its Message Credential suggests that the message indeed comes from its originator and assures that the message has not been tampered with during its transmission.
メッセージ資格情報は、クライアントとサーバー間のメッセージを安全に送信するメカニズムを提供します。メッセージヘッダーとメッセージ本文がメッセージの資格情報に準拠しているメッセージは、メッセージが実際にその創始者から来ていることを示唆しており、メッセージが送信中に改ざんされていないことを保証します。
A large message may be truncated into multiple packets during its transmission. For example, to fit the size limit of a UDP packet, the message issuer must truncate any large message into multiple UDP packets before its transmission. The message recipient must reassemble the message from these truncated packets before further processing. Message truncation must be carried out over the entire message except the Message Envelope. A new Message Envelope has to be inserted in front of each truncated packet before its transmission. For example, a large message that consists of
送信中に大きなメッセージが複数のパケットに切り捨てられる場合があります。たとえば、UDPパケットのサイズ制限を適合させるには、メッセージ発行者は、送信前に大きなメッセージを複数のUDPパケットに切り捨てる必要があります。メッセージ受信者は、さらに処理する前に、これらの切り捨てられたパケットからのメッセージを再組み立てする必要があります。メッセージエンベロープを除き、メッセージの切り捨てはメッセージ全体にわたって実行する必要があります。新しいメッセージエンベロープは、送信前に各切り捨てられたパケットの前に挿入する必要があります。たとえば、それで構成される大きなメッセージ
.--------------------------------------------------------.
| Message Envelope | Message Header, Body, Credential |
'--------------------------------------------------------'
may be truncated into:
：に切り捨てられる場合があります。
.--------------------------------------------.
| Message Envelope 1 | Truncated_Packet 1 |
'--------------------------------------------'
.--------------------------------------------.
| Message Envelope 2 | Truncated_Packet 2 |
'--------------------------------------------'
......
.--------------------------------------------.
| Message Envelope N | Truncated Packet N |
'--------------------------------------------'
where the "Truncated_packet 1", "Truncated_packet 2", ..., and "Truncated_packet N" result from truncating the Message Header, the Message Body and the Message Credential. Each "Message Envelope i" (inserted before each truncation) must set its TC flag to 1 and maintain the proper sequence count (in the <SequenceNumber>). Each "Message Envelope i" must also set its <MessageLength> to reflect the size of the packet. The recipient of these truncated packets can reassemble the message by concatenating these packets based on their <SequenceNumber>.
ここで、「truncated_packet 1」、「truncated_packet 2」、...、および「truncated_packet n」は、メッセージヘッダー、メッセージ本文、およびメッセージの資格情報をトランケートすることに起因します。各「メッセージエンベロープI」（各切り捨ての前に挿入）は、TCフラグを1に設定し、適切なシーケンスカウントを維持する必要があります（<SequenCenumber>）。各「Message Envelope I」は、パケットのサイズを反映するように<messagelength>を設定する必要があります。これらの切り捨てられたパケットの受信者は、<sequencenumber>に基づいてこれらのパケットを連結することにより、メッセージを再組み立てることができます。
This section describes the details of each protocol operation in terms of messages exchanged between the client and server. It also defines the format of the Message Body according to each <OpCode> and <ResponseCode> in the Message Header.
このセクションでは、クライアントとサーバーの間で交換されるメッセージに関して、各プロトコル操作の詳細について説明します。また、メッセージヘッダーの各<opcode>および<responsecode>に従ってメッセージ本文の形式を定義します。
The service information for the Global Handle Registry (GHR) allows clients to contact the GHR to find out the responsible service components for their handles. The service information is a set of HS_SITE values assigned to the root handle "0.NA/0.NA" and is also called the root service information. The root service information may be distributed along with the client software, or be downloaded from the Handle System website at http://www.handle.net.
グローバルハンドルレジストリ（GHR）のサービス情報により、クライアントはGHRに連絡して、ハンドルの責任あるサービスコンポーネントを見つけることができます。サービス情報は、ルートハンドル「0.NA/0.NA」に割り当てられたHS_SITE値のセットであり、ルートサービス情報とも呼ばれます。ルートサービス情報は、クライアントソフトウェアとともに配布するか、http://www.handle.netのハンドルシステムWebサイトからダウンロードすることもできます。
Changes to the root service information are identified by the <SerialNumber> in the HS_SITE values. A server at GHR can find out if the root service information used by the client is outdated by checking the <SerialNumber> in the client's request. The client should update the root service information if the <ResponseCode> of the response message is RC_EXPIRED_SITE_INFO. Clients may obtain the most up-to-date root service information from the root handle. The GHR must sign the root service information using the public key specified in the outdated service information (identified in the client's request) so that the client can validate the signature.
ルートサービス情報の変更は、HS_SITE値の<SerialNumber>によって識別されます。GHRのサーバーは、クライアントのリクエストで<SerialNumber>をチェックすることにより、クライアントが使用するルートサービス情報が時代遅れかどうかを確認できます。応答メッセージの<ResponseCode>がRC_EXPIRED_SITE_INFOである場合、クライアントはルートサービス情報を更新する必要があります。クライアントは、ルートハンドルから最新のルートサービス情報を取得できます。GHRは、クライアントが署名を検証できるように、時代遅れのサービス情報で指定された公開キー（クライアントの要求で識別）を使用して、ルートサービス情報に署名する必要があります。
Each handle under the Handle System is managed by a unique handle service component (e.g., LHS). For any given handle, the responsible service component (and its service information) can be found from its naming authority handle. Before resolving any given handle, the client needs to find the responsible service component by querying the naming authority handle from the GHR.
ハンドルシステムの下の各ハンドルは、一意のハンドルサービスコンポーネント（LHSなど）によって管理されます。任意のハンドルについて、責任あるサービスコンポーネント（およびそのサービス情報）は、その命名機関のハンドルから見つけることができます。特定のハンドルを解決する前に、クライアントはGHRから命名機関のハンドルを照会することにより、責任サービスコンポーネントを見つける必要があります。
For example, to find the responsible LHS for the handle "1000/abc", client software can query the GHR for the HS_SITE (or HS_SERV) values assigned to the naming authority handle "0.NA/1000". The set of HS_SITE values provides the service information of the LHS that manages every handle under the naming authority "1000". If no HS_SITE values are found, the client can check if there is any HS_SERV value assigned to the naming authority handle. The HS_SERV value provides the service handle that maintains the service information for the LHS. Service handles are used to manage the service information shared by different naming authorities.
たとえば、ハンドル「1000/ABC」の責任あるLHSを見つけるために、クライアントソフトウェアは、命名機関のハンドル「0.NA/1000」に割り当てられたHS_SITE（またはHS_SERV）値のGHRを照会できます。HS_SITE値のセットは、命名権限「1000」の下ですべてのハンドルを管理するLHSのサービス情報を提供します。HS_SITE値が見つからない場合、クライアントは、命名権限ハンドルに割り当てられたHS_SERV値があるかどうかを確認できます。HS_SERV値は、LHSのサービス情報を維持するサービスハンドルを提供します。サービスハンドルは、さまざまな命名当局が共有するサービス情報を管理するために使用されます。
It is possible that the naming authority handle requested by the client does not reside at the GHR. This happens when naming authority delegation takes place. Naming authority delegation happens when a naming authority delegates an LHS to manage all its child naming authorities. In this case, the delegating naming authority must contain the service information, a set of HS_NA_DELEGATE values, of the LHS that manages its child naming authorities.
クライアントから要求された命名機関のハンドルがGHRに存在しない可能性があります。これは、権限の委任が行われたときに起こります。命名当局の委任は、命名当局がLHSを委任して、すべての子供の命名当局を管理するときに発生します。この場合、委任命名機関には、子どもの命名当局を管理するLHSのサービス情報、HS_NA_DELEGATE値のセットを含める必要があります。
All top-level naming authority handles must be registered and managed by the GHR. When a server at the GHR receives a request for a naming authority that has been delegated to an LHS, it must return a message with the <ResponseCode> set to RC_NA_DELEGATE, along with the HS_NA_DELAGATE values from the nearest ancestor naming authority. The client can query the LHS described by the HS_NA_DELAGATE values for the delegated naming authority handle. In practice, the ancestor naming authority should make itself available to any handle server within the GHR, by replicating itself at the time of delegation. This will prevent any cross-queries among handle servers (within a service site) when the naming authority in query and the ancestor naming authority do not hash into the same handle server.
すべてのトップレベルの命名機関ハンドルは、GHRによって登録および管理する必要があります。GHRのサーバーがLHSに委任された命名当局のリクエストを受信する場合、RC_NA_DELEGATEに設定された<ResponseCode>を使用してメッセージを返す必要があります。クライアントは、委任された命名権限ハンドルのHS_NA_DELAGATE値によって記述されたLHSを照会できます。実際には、先祖の命名機関は、委任時にそれ自体を複製することにより、GHR内の任意のハンドルサーバーが利用できるようにする必要があります。これにより、クエリの命名当局と祖先の命名機関が同じハンドルサーバーにハッシュしない場合、ハンドルサーバー間のクロスQuerie（サービスサイト内）が妨げられます。
Each handle service component is defined in terms of a set of HS_SITE values. Each of these HS_SITE values defines a service site within the service component. A service site may consist of a group of handle servers. For any given handle, the responsible handle server within the service component can be found following this procedure:
各ハンドルサービスコンポーネントは、HS_SITE値のセットに関して定義されます。これらの各HS_SITE値は、サービスコンポーネント内のサービスサイトを定義します。サービスサイトは、ハンドルサーバーのグループで構成されている場合があります。特定のハンドルについて、この手順に従って、サービスコンポーネント内の責任あるハンドルサーバーを見つけることができます。
1. Select a preferred service site.
1. 優先サービスサイトを選択します。
Each service site is defined in terms of an HS_SITE value. The HS_SITE value may contain a <Description> or other attributes (under the <AttributeList>) to help the selection. Clients must select the primary service site for any administrative operations.
各サービスサイトは、HS_SITE値の観点から定義されています。HS_SITE値には、選択を支援するために<説明>またはその他の属性（<Attributelist>の下）が含まれている場合があります。クライアントは、管理業務に対してプライマリサービスサイトを選択する必要があります。
2. Locate the responsible server within the service site.
2. サービスサイト内の責任サーバーを見つけます。
This can be done as follows: Convert every ASCII character in the handle to its upper case. Calculate the MD5 hash of the converted handle string according to the <HashOption> given in the HS_SITE value. Take the last 4 bytes of the hash result as a signed integer. Modulo the absolute value of the integer by the <NumOfServer> given in the HS_SITE value. The result is the sequence number of the <ServerRecord> listed in the HS_SITE value. For example, if the result of the modulation is 2, the third <ServerRecord> listed in the <HS_SITE> should be selected. The <ServerRecord> defines the responsible handle server for the given handle.
これは次のように行うことができます。ハンドルのすべてのASCII文字をその大文字に変換します。HS_SITE値で指定された<Hashoption>に従って、変換されたハンドル文字列のMD5ハッシュを計算します。ハッシュ結果の最後の4バイトを署名された整数として取ります。hs_site値で与えられた<numofserver>による整数の絶対値。結果は、hs_site値にリストされている<serverRecord>のシーケンス番号です。たとえば、変調の結果が2の場合、<HS_SITE>にリストされている3番目の<ServerRecord>を選択する必要があります。<serverRecord>は、指定されたハンドルの責任あるハンドルサーバーを定義します。
A query operation consists of a client sending a query request to the responsible handle server and the server returning the query result to the client. Query requests are used to retrieve handle values assigned to any given handle.
クエリ操作は、クライアントが責任あるハンドルサーバーにクエリ要求を送信し、クエリの結果をクライアントに返すサーバーに構成されます。クエリ要求は、特定のハンドルに割り当てられたハンドル値を取得するために使用されます。
The Message Header of any query request must set its <OpCode> to OC_RESOLUTION (defined in section 2.2.2.1) and <ResponseCode> to 0.
クエリ要求のメッセージヘッダーは、<opcode>をoc_resolution（セクション2.2.2.1で定義）および<responsecode>に0に設定する必要があります。
The Message Body for any query request is defined as follows:
クエリリクエストのメッセージ本文は、次のように定義されます。
<Message Body of Query Request> ::= <Handle>
<IndexList>
<TypeList>
where
ただし
<Handle> A UTF8-String (as defined in section 2.1.4) that specifies the handle to be resolved.
<handle>解決するハンドルを指定するUTF8-STRING（セクション2.1.4で定義されています）。
<IndexList> A 4-byte unsigned integer followed by an array of 4-byte unsigned integers. The first integer indicates the number of integers in the integer array. Each number in the integer array is a handle value index and refers to a handle value to be retrieved. The client sets the first integer to zero (followed by an empty array) to ask for all the handle values regardless of their index.
<IndexList> 4バイトの符号なし整数に続いて、4バイトの符号なし整数の配列が続きます。最初の整数は、整数アレイ内の整数の数を示します。整数配列内の各番号は、ハンドル値インデックスであり、取得するハンドル値を指します。クライアントは、最初の整数をゼロに設定し（空の配列が続く）、インデックスに関係なくすべてのハンドル値を要求します。
<TypeList> A 4-byte unsigned integer followed by a list of UTF8- Strings. The first integer indicates the number of UTF8-Strings in the list that follows. Each UTF8-String in the list specifies a data type. This tells the server to return all handle values whose data type is listed in the list. If a UTF8-String ends with the '.' (0x2E) character, the server must return all handle values whose data type is under the type hierarchy specified in the UTF8-String. The <TypeList> may contain no UTF8-String if the first integer is 0. In this case, the server must return all handle values regardless of their data type.
<TypeList> 4バイトの符号なし整数に続いてUTF8文字列のリストが続きます。最初の整数は、次のリスト内のUTF8ストリングの数を示します。リスト内の各UTF8ストリングは、データ型を指定します。これにより、データ型がリストにリストされているすべてのハンドル値を返すようにサーバーに指示されます。UTF8ストリングが「。」で終了する場合（0x2E）文字、サーバーは、データ型がUTF8ストリングで指定されたタイプの階層の下にあるすべてのハンドル値を返す必要があります。最初の整数が0の場合、<TypeList>にはUTF8-STRINGが含まれない場合があります。この場合、サーバーはデータ型に関係なくすべてのハンドル値を返す必要があります。
If a query request does not specify any index or data type and the PO flag (in the Message Header) is set, the server will return all the handle values that have the PUBLIC_READ permission. Clients can also send queries without the PO flag set. In this case, the server will return all the handle values with PUBLIC_READ permission and all the handle values with ADMIN_READ permission. If the query requests a specific handle value via the value index and the value does not have PUBLIC_READ permission, the server should accept the request (and authenticate the client) even if the request has its PO flag set.
クエリ要求がインデックスまたはデータ型を指定せず、POフラグ（メッセージヘッダー内）が設定されている場合、サーバーはpublic_read許可を持つすべてのハンドル値を返します。クライアントは、POフラグセットなしでクエリを送信することもできます。この場合、サーバーはすべてのハンドル値をpublic_read許可と、admin_read許可ですべてのハンドル値を返します。クエリが値インデックスを介して特定のハンドル値を要求し、値にpublic_readの許可がない場合、リクエストにPOフラグが設定されていても、サーバーはリクエスト（およびクライアントの認証）を受け入れる必要があります。
If a query consists of a non-empty <IndexList> but an empty <TypeList>, the server should only return those handle values whose indexes are listed in the <IndexList>. Likewise, if a query consists of a non-empty <TypeList> but an empty <IndexList>, the server should only return those handle values whose data types are listed in the <TypeList>.
クエリが空でない<indexlist>で構成されているが、空の<タイプリスト>で構成されている場合、サーバーはインデックスが<indexlist>にリストされているハンドル値のみを返す必要があります。同様に、クエリが空でない<タイプリスト>で構成されているが、空の<インデックスリスト>で構成されている場合、サーバーはデータ型が<typelist>にリストされているハンドル値のみを返す必要があります。
When both <IndexList> and <TypeList> fields are non-empty, the server should return all handle values whose indexes are listed in the <IndexList> AND all handle values whose data types are listed in the <TypeList>.
<indexlist>と<typeList>フィールドの両方が空でない場合、サーバーはインデックスが<indexList>にリストされているすべてのハンドル値と、データ型が<typelist>にリストされているすべてのハンドル値を返す必要があります。
The Message Header of any query response must set its <OpCode> to OC_RESOLUTION. A successful query response must set its <ResponseCode> to RC_SUCCESS.
クエリ応答のメッセージヘッダーは、<opcode>をoc_resolutionに設定する必要があります。クエリ応答を成功させるには、<ResponseCode>をRC_SUCCESSに設定する必要があります。
The message body of the successful query response is defined as follows:
クエリ応答の成功のメッセージ本文は、次のように定義されます。
<Message Body of Successful Query Response> ::= [<RequestDigest>]
<Handle>
<ValueList>
where
ただし
<RequestDigest> Optional field as defined in section 2.2.3.
<RequestDigest>セクション2.2.3で定義されているオプションフィールド。
<Handle> A UTF8-String that specifies the handle queried by the client.
<handle>クライアントが照会したハンドルを指定するUTF8-STRING。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer specifies the number of handle values in the list. The encoding of each handle value follows the specification given in [2] (see section 3.1). The integer is set to zero if there is no handle value that satisfies the query.
<Valuelist> 4バイトの符号なし整数に続いて、ハンドル値のリストが続きます。整数は、リスト内のハンドル値の数を指定します。各ハンドル値のエンコードは、[2]に与えられた仕様に従います（セクション3.1を参照）。クエリを満たすハンドル値がない場合、整数はゼロに設定されます。
If a server cannot fulfill a client's request, it must return an error message. The general format for any error message from the server is specified in section 3.3 of this document.
サーバーがクライアントの要求を満たせない場合、エラーメッセージを返す必要があります。サーバーからのエラーメッセージの一般的な形式は、このドキュメントのセクション3.3で指定されています。
For example, a server must return an error message if the queried handle does not exist in its database. The error message will have an empty message body and have its <ResponseCode> set to RC_HANDLE_NOT_FOUND.
たとえば、クエリのハンドルがデータベースに存在しない場合、サーバーはエラーメッセージを返す必要があります。エラーメッセージには空のメッセージ本文があり、<ResponseCode>がrc_handle_not_foundに設定されています。
Note that a server should NOT return an RC_HANDLE_NOT_FOUND message if the server is not responsible for the handle being queried. It is possible that the queried handle exists but is managed by another handle server (under some other handle service). When this happens, the server should either send a service referral (see section 3.4) or simply return an error message with <ResponseCode> set to RC_SERVER_NOT_RESP.
サーバーがハンドルがクエリになっていることについて責任を負わない場合、サーバーはrc_handle_not_foundメッセージを返すべきではないことに注意してください。クエリされたハンドルが存在する可能性がありますが、別のハンドルサーバーによって管理されています（他のハンドルサービスの下）。これが発生した場合、サーバーはサービス紹介を送信するか（セクション3.4を参照）、または<ResponseCode>をRC_SERVER_NOT_RESPに設定してエラーメッセージを返すだけです。
The server may return an error message with <ResponseCode> set to RC_SERVER_BUSY if the server is too busy to process the request. Like RC_HANDLE_NOT_FOUND, an RC_SERVER_BUSY message also has an empty message body.
サーバーがリクエストを処理できない場合は、サーバーがRC_SERVER_BUSYに設定された<ResponseCode>を使用してエラーメッセージを返す場合があります。rc_handle_not_foundのように、rc_server_busyメッセージには空のメッセージ本文もあります。
Servers should return an RC_ACCESS_DENIED message if the request asks for a specific handle value (via the handle value index) that has neither PUBLIC_READ nor ADMIN_READ permission.
サーバーは、public_readまたはadmin_readの許可を持たない特定のハンドル値（ハンドル値インデックスを介して）を要求する場合、RC_ACCESS_DENIEDメッセージを返す必要があります。
A handle Server may ask its client to authenticate itself as the handle administrator during the resolution. This happens if any handle value in query has ADMIN_READ permission, but no PUBLIC_READ permission. Details of client authentication are described later in this document.
ハンドルサーバーは、解像度中にクライアントに自分自身をハンドル管理者として認証するように依頼する場合があります。これは、Queryのハンドル値がadmin_read許可を持っているが、public_read許可はない場合に発生します。クライアント認証の詳細については、このドキュメントの後半で説明します。
A handle server will return an error message if it encounters an error when processing a request. Any error response from the server must maintain the same <OpCode> (in the message header) as the one in the original request. Each error condition is identified by a unique <ResponseCode> as defined in section 2.2.2.2 of this document.
ハンドルサーバーは、リクエストの処理時にエラーが発生すると、エラーメッセージが返されます。サーバーからのエラー応答は、元のリクエストのものと同じ<opcode>（メッセージヘッダー）を維持する必要があります。各エラー条件は、このドキュメントのセクション2.2.2.2で定義されている一意の<応答>によって識別されます。
The Message Body of an error message may be empty. Otherwise it consists of the following data fields (unless otherwise specified):
エラーメッセージのメッセージ本文が空になる可能性があります。それ以外の場合は、次のデータフィールドで構成されています（特に指定されていない限り）：
<Message Body of Error Response from Server> ::= [<RequestDigest>]
<ErrorMessage>
[ <IndexList> ]
where
ただし
<RequestDigest> Optional field as defined in section 2.2.3.
<RequestDigest>セクション2.2.3で定義されているオプションフィールド。
<ErrorMessage> A UTF8-String that explains the error.
<ErrorMessage>エラーを説明するUTF8-STRING。
<IndexList> An optional field. When not empty, it consists of a 4-byte unsigned integer followed by a list of handle value indexes. The first integer indicates the number of indexes in the list. Each index in the list is a 4-byte unsigned integer that refers to a handle value that contributed to the error. An example would be a server that is asked to add three handle values, with indexes 1, 2, and 3, and handle values with indexes of 1 and 2 already in existence. In this case, the server could return an error message with <REsponseCode> set to RC_VALUE_ALREADY_EXIST and add index 1 and 2 to the <IndexList>. Note that the server is not obligated to return the complete list of handle value indexes that may have caused the error.
<IndexList>オプションのフィールド。空でない場合、それは4バイトの符号なし整数で構成され、その後にハンドル値インデックスのリストが続きます。最初の整数は、リスト内のインデックスの数を示します。リスト内の各インデックスは、エラーに寄与するハンドル値を指す4バイトの符号なし整数です。例としては、インデックス1、2、および3の3つのハンドル値を追加するように求められ、1と2のインデックスが既に存在しているハンドル値を追加するように求められるサーバーです。この場合、サーバーは<rspessecode>をrc_value_already_existに設定してエラーメッセージを返すことができ、インデックス1と2を<indexlist>に追加します。サーバーは、エラーを引き起こした可能性のあるハンドル値インデックスの完全なリストを返す義務がないことに注意してください。
A handle server may receive requests for handles that are managed by some other handle server or service. When this happens, the server has the option to either return a referral message that directs the client to the proper handle service, or simply return an error message with <ResponseCode> set to RC_SERVER_NOT_RESP. Service referral also happens when ownership of handles moves from one handle service to another. It may also be used by any local handle service to delegate its service into multiple service layers.
ハンドルサーバーは、他のハンドルサーバーまたはサービスによって管理されるハンドルのリクエストを受信する場合があります。これが発生した場合、サーバーには、クライアントを適切なハンドルサービスに向ける紹介メッセージを返すか、<ResponseCode>をRC_SERVER_NOT_RESPに設定してエラーメッセージを返すオプションがあります。サービス紹介は、ハンドルの所有権があるハンドルサービスから別のハンドルサービスに移動する場合にも発生します。また、ローカルハンドルサービスで使用して、サービスを複数のサービスレイヤーに委任することもできます。
The Message Header of a service referral must maintain the same <OpCode> as the one in the original request and set its <ResponseCode> to RC_SERVICE_REFERRAL.
サービス紹介のメッセージヘッダーは、元のリクエストの<opcode>と同じ<opcode>を維持し、<servescode>をrc_service_referralに設定する必要があります。
The Message Body of any service referral is defined as follows:
任意のサービス紹介のメッセージ本文は、次のように定義されています。
<Message Body of Service Referral> ::= [ <RequestDigest> ]
<ReferralHandle>
[ <ValueList> ]
where
ただし
<RequestDigest> Optional field as defined in section 2.2.3.
<RequestDigest>セクション2.2.3で定義されているオプションフィールド。
<ReferralHandle> A UTF8-String that identifies the handle (e.g., a service handle) that maintains the referral information (i.e., the service information of the handle service in which this refers). If the <ReferralHandle> is set to "0.NA/0.NA", it is referring the client to the GHR.
<referralhandle>紹介情報（つまり、これが参照するハンドルサービスのサービス情報）を維持するハンドル（たとえば、サービスハンドル）を識別するUTF8-STRING。<referralhandle>が「0.na/0.na」に設定されている場合、クライアントをGHRに参照しています。
<ValueList> An optional field that must be empty if the <ReferralHandle> is provided. When not empty, it consists of a 4-byte unsigned integer, followed by a list of HS_SITE values. The integer specifies the number of HS_SITE values in the list.
<valuelist> <preirlalhandle>が提供されている場合は空でなければならないオプションのフィールド。空でない場合は、4バイトの符号なし整数で構成され、その後にHS_SITE値のリストが続きます。整数は、リスト内のHS_SITE値の数を指定します。
Unlike regular query responses that may consist of handle values of any data type, a service referral can only have zero or more HS_SITE values in its <ValueList>. The <ReferralHandle> may contain an empty UTF8-String if the HS_SITE values in the <ValueList> are not maintained by any handle.
データ型のハンドル値で構成される通常のクエリ応答とは異なり、サービス紹介は<valuelist>にゼロ以上のHS_SITE値しか持たません。<valuelist>のHS_SITE値がハンドルによって維持されていない場合、<referralHandle>には空のUTF8-STRINGが含まれている場合があります。
Care must be taken by clients to avoid any loops caused by service referrals. It is also the client's responsibility to authenticate the service information obtained from the service referral. A client should always use its own copy of the GHR service information if the <ReferralHandle> is set to "0.NA/0.NA".
サービスの紹介によって引き起こされるループを避けるために、クライアントが注意する必要があります。また、サービス紹介から取得したサービス情報を認証することはクライアントの責任です。クライアントは、<preirlalhandle>が「0.na/0.na」に設定されている場合、常にGHRサービス情報の独自のコピーを使用する必要があります。
Clients are asked to authenticate themselves as handle administrators when querying for any handle value with ADMIN_READ but no PUBLIC_READ permission. Client authentication is also required for any handle administration requests that require administrator privileges. This includes adding, removing, or modifying handles or handle values.
クライアントは、admin_readでハンドル値をクエリするときに、ハンドル管理者として認証するように求められますが、public_readの許可はありません。また、管理者の特権を必要とするハンドル管理リクエストには、クライアント認証が必要です。これには、ハンドルの追加、削除、または変更の値の追加、削除、または変更が含まれます。
Client authentication consists of multiple messages exchanged between the client and server. Such messages include the challenge from the server to the client to authenticate the client, the challenge-response from the client in response to the server's challenge, and the verification request and response message if secret key authentication takes place. Messages exchanged during the authentication are correlated via a unique <SessionId> assigned by the server. For each authentication session, the server needs to maintain the state information that includes the server's challenge, the challenge-response from the client, as well as the original client request.
クライアント認証は、クライアントとサーバーの間で交換される複数のメッセージで構成されています。このようなメッセージには、クライアントを認証するためのサーバーからクライアントへの課題、サーバーの課題に応じてクライアントからのチャレンジ応答、およびSecret Key認証が行われる場合の確認要求と応答メッセージが含まれます。認証中に交換されるメッセージは、サーバーによって割り当てられた一意の<sessionId>を介して相関します。認証セッションごとに、サーバーは、サーバーの課題、クライアントからの課題反応、および元のクライアントリクエストを含む状態情報を維持する必要があります。
The authentication starts with a response message from the server that contains a challenge to the client. The client must respond to the challenge with a challenge-response message. The server validates the challenge-response, either by verifying the digital signature inside the challenge-response, or by sending a verification request to another handle server (herein referred to as the verification server), that maintains the secret key for the administrator. The purpose of the challenge and the challenge-response is to prove to the server that the client possesses the private key (or the secret key) of the handle administrator. If the authentication fails, an error response will be sent back with the <ResponseCode> set to RC_AUTHEN_FAILED.
認証は、クライアントへの課題を含むサーバーからの応答メッセージから始まります。クライアントは、チャレンジ応答メッセージでチャレンジに応答する必要があります。サーバーは、チャレンジ応答内のデジタル署名を確認するか、管理者のシークレットキーを維持する別のハンドルサーバー（ここでは検証サーバーと呼ばれる）に検証要求を送信することにより、チャレンジ応答を検証します。チャレンジとチャレンジ応答の目的は、クライアントがハンドル管理者の秘密鍵（または秘密の鍵）を所有していることをサーバーに証明することです。認証が失敗した場合、rc_authen_failedに設定された<lestsecode>でエラー応答が返送されます。
Upon successful client authentication, the server must also make sure that the administrator is authorized for the request. If the administrator has sufficient privileges, the server will process the request and send back the result. If the administrator does not have sufficient privileges, the server will return an error message with <ResponseCode> set to RC_NOT_AUTHORIZED.
クライアント認証が成功すると、サーバーは管理者がリクエストを許可されていることを確認する必要があります。管理者が十分な特権を持っている場合、サーバーはリクエストを処理し、結果を返送します。管理者が十分な特権を持っていない場合、サーバーは<ResponseCode>をRC_NOT_Authorizedに設定してエラーメッセージを返します。
The following sections provide details of each message exchanged during the authentication process.
次のセクションでは、認証プロセス中に交換された各メッセージの詳細を提供します。
The Message Header of the CHALLENGE must keep the same <OpCode> as the original request and set the <ResponseCode> to RC_AUTH_NEEDED. The server must assign a non-zero unique <SessionId> in the Message Envelope to keep track of the authentication. It must also set the RD flag of the <OpFlag> (see section 2.2.2.3) in the Message Header, regardless of whether the original request had the RD bit set or not.
チャレンジのメッセージヘッダーは、元のリクエストと同じ<opcode>を維持し、<responsecode>をrc_auth_neededに設定する必要があります。サーバーは、認証を追跡するために、メッセージエンベロープにゼロ以外の一意の<sessionId>を割り当てる必要があります。また、元のリクエストにRDビットが設定されているかどうかに関係なく、メッセージヘッダーに<opflag>（セクション2.2.2.3を参照）のrdフラグを設定する必要があります。
The Message Body of the server's CHALLENGE is defined as follows:
サーバーの課題のメッセージ本文は、次のように定義されています。
<Message Body of Server's Challenge> ::= <RequestDigest>
<Nonce>
where
<RequestDigest> Message Digest of the request message, as defined in section 2.2.3.
<RequestDigest>セクション2.2.3で定義されているように、リクエストメッセージのメッセージダイジェスト。
<Nonce> A 4-byte unsigned integer followed by a random string generated by the server via a secure random number generator. The integer specifies the number of octets in the random string. The size of the random string should be no less than 20 octets.
<nonce> 4バイトの符号なし整数に続いて、安全な乱数ジェネレーターを介してサーバーによって生成されたランダムな文字列が続きます。整数は、ランダム文字列にオクテットの数を指定します。ランダムな文字列のサイズは、20オクテット以上でなければなりません。
Note that the server will not sign the challenge if the client did not request the server to do so. If the client worries about whether it is speaking to the right server, it may ask the server to sign the <Challenge>. If the client requested the server to sign the <Challenge> but failed to validate the server's signature, the client should discard the server's response and reissue the request to the server.
クライアントがサーバーにそうするように要求しなかった場合、サーバーはチャレンジに署名しないことに注意してください。クライアントが適切なサーバーに話しかけているかどうかを心配している場合、サーバーに<Challenge>に署名するように依頼する場合があります。クライアントがサーバーに<Challenge>に署名するように要求したが、サーバーの署名の検証に失敗した場合、クライアントはサーバーの応答を破棄し、リクエストをサーバーに再発行する必要があります。
The Message Header of the CHALLENGE_RESPONSE must set its <OpCode> to OC_CHALLENGE_RESPONSE and its <ResponseCode> to 0. It must also keep the same <SessionId> (in the Message Envelope) as specified in the challenge from the server.
Challenge_responseのメッセージヘッダーは、<opcode>をOC_CHALLENGE_RESPONSE>に設定し、<ResponseCode>に0に設定する必要があります。また、サーバーからのチャレンジで指定されたものと同じ<sessionId>（メッセージエンベロープ）を維持する必要があります。
The Message Body of the CHALLENGE_RESPONSE request is defines as follows:
チャレンジ応答要求のメッセージ本文は、次のように定義されています。
<Message Body of CHALLENGE_RESPONSE> ::= <AuthenticationType>
<KeyHandle>
<KeyIndex>
<ChallengeResponse>
where
ただし
<AuthenticationType> A UTF8-String that identifies the type of authentication key used by the client. For example, the field is set to "HS_SECKEY" if the client chooses to use a secret key for its authentication. The field is set to "HS_PUBKEY" if a public key is used instead.
<AuthenticationType>クライアントが使用する認証キーのタイプを識別するUTF8-STRING。たとえば、クライアントが認証にシークレットキーを使用することを選択した場合、フィールドは「hs_seckey」に設定されます。フィールドは、代わりに公開キーが使用されている場合、「hs_pubkey」に設定されています。
<KeyHandle> A UTF8-String that identifies the handle that holds the public or secret key of the handle administrator.
<KeyHandle>ハンドル管理者の公開または秘密の鍵を保持するハンドルを識別するUTF8-STRING。
<KeyIndex> A 4-byte unsigned integer that specifies the index of the handle value (of the <KeyHandle>) that holds the public or secret key of the administrator.
<keyIndex>管理者の公開または秘密の鍵を保持するハンドル値（<keyhandle>）のインデックスを指定する4バイトの符号なし整数。
<ChallengeResponse> Contains either the Message Authentication Code (MAC) or the digital signature over the challenge from the server. If the <AuthenticationType> is "HS_SECKEY", the <ChallengeResponse> consists of an octet followed by the MAC. The octet identifies the algorithm used to generate the MAC. For example, if the first octet is set to 0x01, the MAC is generated by
<Challengeresponse>には、メッセージ認証コード（MAC）またはサーバーからの課題に対するデジタル署名のいずれかが含まれています。<AuthenticationType>が「HS_Seckey」の場合、<Challengeresponse>はOctetに続いてMacが続きます。Octetは、MACを生成するために使用されるアルゴリズムを識別します。たとえば、最初のオクテットが0x01に設定されている場合、Macはによって生成されます
MD5_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
where the <SecretKey> is the administrator's secret key
referenced by the <KeyHandle> and <KeyIndex>. The
<ServerChallenge> is the Message Body portion of the
server's challenge. If the first octet in the
<ChallengeResponse> is set to 0x02, the MAC is generated
using
SHA-1_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
A more secure approach is to use HMAC [17] for the <ChallengeResponse>. The HMAC can be generated using the <SecretKey> and <ServerChallenge>. A <ChallengeResponse> with its first octet set to 0x11 indicates that the HMAC is generated using the MD5 algorithm. Likewise, a <ChallengeResponse> with its first octet set to 0x12 indicates that the HMAC is generated using the SHA-1 algorithm.
より安全なアプローチは、<Challengeresponse>にHMAC [17]を使用することです。HMACは、<secretKey>および<serverChallenge>を使用して生成できます。A <Challengeresponse>最初のOctetセットが0x11に設定されていることは、HMACがMD5アルゴリズムを使用して生成されることを示します。同様に、最初のOctetセットを0x12に設定したa <Challengeresponse>は、HMACがSHA-1アルゴリズムを使用して生成されることを示します。
If the <AuthenticationType> is "HS_PUBKEY", the <ChallengeResponse> contains the digital signature over the Message Body portion of the server's challenge. The signature is generated in two steps: First, a one-way hash value is computed over the blob that is to be signed. Second, the hash value is signed using the private key. The signature consists of a UTF8-String that specifies the digest algorithm used for the signature, followed by the signature over the server's challenge. The <KeyHandle> and
<AuthenticationType>が「hs_pubkey」の場合、<Challengeresponse>には、サーバーの課題のメッセージ本文部分にデジタル署名が含まれています。署名は2つのステップで生成されます。最初に、一方向ハッシュ値が署名されるブロブの上に計算されます。第二に、ハッシュ値は秘密鍵を使用して署名されます。署名は、署名に使用されるダイジェストアルゴリズムを指定するUTF8ストリングで構成され、その後にサーバーの課題を介した署名が続きます。<keyhandle>と
<KeyIndex> refers to the administrator's public key that can be used to verify the signature.
<keyIndex>は、署名の検証に使用できる管理者の公開キーを指します。
Handle administrators are defined in terms of HS_ADMIN values assigned to the handle. Each HS_ADMIN value defines the set of privileges granted to the administrator. It also provides the reference to the authentication key that can be used to authenticate the administrator. The reference can be made directly if the <AdminRef> field of the HS_ADMIN value refers to the handle value that holds the authentication key. Indirect reference to the authentication key can also be made via administrator groups. In this case, the <AdminRef> field may refer to a handle value of type HS_VLIST. An HS_VLIST value defines an administrator group via a list of handle value references, each of which refers to the authentication key of a handle administrator.
ハンドル管理者は、ハンドルに割り当てられたHS_ADMIN値に関して定義されます。各HS_ADMIN値は、管理者に付与された特権のセットを定義します。また、管理者の認証に使用できる認証キーへの参照を提供します。HS_ADMIN値の<AdminRef>フィールドが認証キーを保持するハンドル値を指す場合、参照を直接行うことができます。認証キーへの間接的な参照は、管理者グループを介して行うこともできます。この場合、<adminref>フィールドは、タイプhs_vlistのハンドル値を参照できます。HS_VLIST値は、ハンドル値の参照のリストを介して管理者グループを定義します。それぞれが、ハンドル管理者の認証キーを指します。
For handles with multiple HS_ADMIN values, the server will have to check each of those with sufficient privileges to see if its <AdminRef> field matches the <KeyHandle> and <KeyIndex>. If no match is found, but there are administrator groups defined, the server must check if the <KeyHandle> and <KeyIndex> belong to any of the administrator groups that have sufficient privileges. An administrator group may contain another administrator group as a member. Servers must be careful to avoid infinite loops when navigating these groups.
複数のHS_ADMIN値を持つハンドルの場合、サーバーは、<adminref>フィールドが<keyhandle>および<keyIndex>と一致するかどうかを確認するために、十分な特権を持つ各ハンドルを確認する必要があります。一致が見つからないが、管理者グループが定義されている場合、サーバーは<keyhandle>および<keyIndex>が十分な特権を持つ管理者グループに属しているかどうかを確認する必要があります。管理者グループには、メンバーとして別の管理者グループが含まれる場合があります。サーバーは、これらのグループをナビゲートするときに無限のループを避けるように注意する必要があります。
If the <KeyHandle> and <KeyIndex> are not referenced by any of the HS_ADMIN values, or the administrator group that has sufficient privileges, the server will return an error message with <ResponseCode> set to RC_NOT_AUTHORIZED. Otherwise, the server will continue to authenticate the client as follows:
<keyHandle>および<keyIndex>がHS_ADMIN値のいずれか、または十分な特権を持つ管理者グループによって参照されない場合、サーバーは<RestupeCode>をRC_NOT_Authorizedに設定してエラーメッセージを返します。それ以外の場合、サーバーは次のようにクライアントを認証し続けます。
If the <AuthenticationType> is "HS_PUBKEY", the server will retrieve the administrator's public key based on the <KeyHandle> and <KeyIndex>. The public key can be used to verify the <ChallengeResponse> against the server's <Challenge>. If the <ChallengeResponse> matches the <Challenge>, the server will continue to process the original request and return the result. Otherwise, the server will return an error message with <ResponseCode> set to RC_AUTHENTICATION_FAILED.
<AuthenticationType>が「hs_pubkey」の場合、サーバーは<keyhandle>および<keyindex>に基づいて管理者の公開キーを取得します。公開キーを使用して、サーバーの<Challenge>に対して<Challengeresponse>を確認できます。<Challengeresponse>が<Challenge>と一致する場合、サーバーは元のリクエストを処理し続け、結果を返します。それ以外の場合、サーバーは<rspessecode>をrc_authentication_failedに設定してエラーメッセージを返します。
If the <AuthenticationType> is "HS_SECKEY", the server will have to send a verification request to the verification server; that is, the handle server that manages the handle referenced by the <KeyHandle>. The verification request and its response are defined in the following sections. The verification server will verify the <ChallengeResponse> against the <Challenge> on behalf of the handle server.
<AuthenticationType>が「HS_Seckey」の場合、サーバーは検証リクエストを検証サーバーに送信する必要があります。つまり、<keyhandle>で参照されるハンドルを管理するハンドルサーバーです。検証要求とその応答は、次のセクションで定義されています。検証サーバーは、ハンドルサーバーに代わって<Challengeresponse>に対して<Challengeresponse>を確認します。
The message header of the VERIFICATION_REQUEST must set its <OpCode> to OC_VERIFY_CHALLENGE and the <ResponseCode> to 0.
vilification_requestのメッセージヘッダーは、<opcode>をoc_verify_challengeに、<sfrestecode>に0に設定する必要があります。
The message body of the Verification-Request is defined as follows:
検証要求のメッセージ本文は、次のように定義されています。
<Message Body of VERIFICATION_REQUEST> ::= <KeyHandle>
<KeyIndex>
<Challenge>
<ChallengeResponse>
where
ただし
<KeyHandle> A UTF8-String that refers to the handle that holds the secret key of the administrator.
<KeyHandle>管理者の秘密の鍵を保持するハンドルを指すUTF8-STRING。
<KeyIndex> A 4-byte unsigned integer that is the index of the handle value that holds the secret key of the administrator.
<keyIndex>管理者の秘密の鍵を保持するハンドル値のインデックスである4バイトの符号なし整数。
<Challenge> The message body of the server's challenge, as described in section 3.5.1.
<Challenge>セクション3.5.1で説明されているように、サーバーの課題のメッセージ本文。
<ChallengeResponse> The <ChallengeResponse> from the client in response to the server's <Challenge>, as defined in section 3.5.2.
<Challengeresponse>セクション3.5.2で定義されているように、サーバーの<Challenge>に応じてクライアントから<Challengeresponse>から。
Any Challenge-Response Verification-Request must set its CT bit in the message header. This is to ensure that the verification server will sign the Verification-Response as specified in the next section.
チャレンジ応答の確認要件は、メッセージヘッダーにCTビットを設定する必要があります。これは、検証サーバーが次のセクションで指定されているように検証応答に署名するようにするためです。
The Verification-Response tells the requesting handle server whether the <ChallengeResponse> matches the <Challenge> in the Verification-Request.
検証応答は、<Challengeresponse>が検証の再クエストの<Challenge>と一致するかどうかを要求するハンドルサーバーに伝えます。
The Message Header of the Verification-Response must set its <ResponseCode> to RC_SUCCESS whether or not the <ChallengeResponse> matches the <Challenge>. The RD flag in the <OpFlag> field should also be set (to 1) since the <RequestDigist> will be mandatory in the Message Body.
検証応答のメッセージヘッダーは、<Challengeresponse>が<Challenge>に一致するかどうかにかかわらず、<ResponseCode>をRC_SUCCESSに設定する必要があります。<requestDigist>がメッセージ本文で必須であるため、<Opflag>フィールドのRDフラグも設定する必要があります（1に）設定する必要があります。
The Message Body of the Verification-Response is defined as follows:
検証応答のメッセージ本文は、次のように定義されています。
<Challenge-Response Verification-Response>
::= <RequestDigest>
<VerificationResult>
where
<RequestDigest> Contains the message digest of the Verification-Request.
<RequestDigest>には、検証再実行のメッセージダイジェストが含まれています。
<VerificationResult> An octet that is set to 1 if the <ChallengeResponse> matches the <Challenge>. Otherwise it must be set to 0.
<検証> <Challengeresponse>が<Challenge>に一致する場合、1に設定されたオクテット。それ以外の場合は、0に設定する必要があります。
The verification server may return an error with <ResponseCode> set to RC_AUTHEN_FAILED if it cannot perform the verification (e.g., the <KeyHandle> does not exist, or the <KeyHandle> and <KeyIndex> refer to an invalid handle value). When this happens, the server that performs the client authentication should relay the same error message back to the client.
検証サーバーは、検証を実行できない場合（<keyhandle>が存在しないか、<keyhandle>および<keyIndex>が無効なハンドル値を参照する場合、<responsecode>をrc_authen_failedに設定してエラーを返す場合があります。これが発生した場合、クライアント認証を実行するサーバーは、同じエラーメッセージをクライアントに戻す必要があります。
The Handle System protocol supports a set of handle administration functions that include adding, deleting, and modifying handles or handle values. Before fulfilling any administration request, the server must authenticate the client as the handle administrator that is authorized for the administrative operation. Handle administration can only be carried out by the primary handle server.
ハンドルシステムプロトコルは、ハンドル管理機能の追加、削除、および変更を含むハンドル管理機能のセットをサポートします。管理リクエストを満たす前に、サーバーはクライアントを管理操作を許可されているハンドル管理者として認証する必要があります。ハンドル管理は、プライマリハンドルサーバーによってのみ実行できます。
Clients add values to existing handles by sending ADD_VALUE requests to the responsible handle server. The Message Header of the ADD_VALUE request must set its <OpCode> to OC_ADD_VALUE.
クライアントは、責任あるハンドルサーバーにadd_valueリクエストを送信することにより、既存のハンドルに値を追加します。add_valueリクエストのメッセージヘッダーは、<opcode>をoc_add_valueに設定する必要があります。
The Message Body of the ADD_VALUE request is encoded as follows:
add_valueリクエストのメッセージ本文は、次のようにエンコードされます。
<Message Body of ADD_VALUE Request> ::= <Handle>
<ValueList>
where
ただし
<Handle> A UTF8-String that specifies the handle.
<handle>ハンドルを指定するUTF8-STRING。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer indicates the number of handle values in the list.
<Valuelist> 4バイトの符号なし整数に続いて、ハンドル値のリストが続きます。整数は、リスト内のハンドル値の数を示します。
The server that receives the ADD_VALUE request must first authenticate the client as the administrator with the ADD_VALUE privilege. Upon successful authentication, the server will proceed to add each value in the <ValueList> to the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
ADD_VALUEリクエストを受信するサーバーは、最初にADD_VALUE特権を使用して管理者としてクライアントを認証する必要があります。認証が成功すると、サーバーは<valuelist>の各値を<ハンドル>に追加します。成功した場合、サーバーはRC_SUCCESSメッセージをクライアントに返します。
Each ADD_VALUE request must be carried out as a transaction. If adding any value in the <ValueList> raises an error, the entire operation must be rolled back. For any failed ADD_VALUE request, none of the values in the <ValueList> should be added to the <Handle>. The server must also send a response to the client that explains the error. For example, if a value in the <ValueList> has the same index as one of the existing handle values, the server will return an error message that has the <ResponseCode> set to RC_VALUE_ALREADY_EXISTS.
各add_value要求は、トランザクションとして実行する必要があります。<valuelist>に値を追加するとエラーが発生する場合、操作全体をロールバックする必要があります。失敗したadd_valueリクエストについては、<valuelist>の値を<handle>に追加する必要はありません。また、サーバーは、エラーを説明するクライアントに応答を送信する必要があります。たとえば、<valuelist>の値が既存のハンドル値の1つと同じインデックスを持っている場合、サーバーは<responsecode>がrc_value_already_existsに設定されているエラーメッセージを返します。
ADD_VALUE requests can also be used to add handle administrators. This happens if the <ValueList> in the ADD_VALUE request contains any HS_ADMIN values. The server must authenticate the client as an administrator with the ADD_ADMIN privilege before fulfilling such requests.
add_valueリクエストは、ハンドル管理者を追加するためにも使用できます。これは、add_valueリクエストの<valuelist>にhs_admin値が含まれている場合に発生します。サーバーは、そのようなリクエストを満たす前に、ADD_ADMIN特権の管理者としてクライアントを認証する必要があります。
An ADD_VALUE request will result in an error if the requested handle does not exist. When this happens, the server will return an error message with <ResponseCode> set to RC_HANDLE_NOT_EXIST.
add_valueリクエストは、要求されたハンドルが存在しない場合、エラーになります。これが発生した場合、サーバーは<ResponseCode>をRC_HANDLE_NOT_EXISTに設定してエラーメッセージを返します。
Clients remove existing handle values by sending REMOVE_VALUE requests to the responsible handle server. The Message Header of the REMOVE_VALUE request must set its <OpCode> to OC_REMOVE_VALUE.
クライアントは、Remove_Valueリクエストを責任あるハンドルサーバーに送信することにより、既存のハンドル値を削除します。remove_valueリクエストのメッセージヘッダーは、<opcode>をoc_remove_valueに設定する必要があります。
The Message Body of any REMOVE_VALUE request is encoded as follows:
remove_valueリクエストのメッセージ本文は、次のようにエンコードされます。
<Message Body of REMOVE_VALUE Request> ::= <Handle>
<IndexList>
where
ただし
<Handle> A UTF8-String that specifies the handle whose value(s) needs to be removed.
<handle>値を削除する必要があるハンドルを指定するUTF8-STRING。
<IndexList> A 4-byte unsigned integer followed by a list of handle value indexes. Each index refers to a handle value to be removed from the <Handle>. The integer specifies the number of indexes in the list. Each index is also encoded as a 4-byte unsigned integer.
<IndexList> 4バイトの符号なし整数に続いて、ハンドル値インデックスのリストが続きます。各インデックスとは、<ハンドル>から削除されるハンドル値を指します。整数は、リスト内のインデックスの数を指定します。各インデックスは、4バイトの符号なし整数としてエンコードされています。
The server that receives the REMOVE_VALUE request must first authenticate the client as the administrator with the REMOVE VALUE privilege. Upon successful authentication, the server will proceed to remove the handle values specified in the <IndexList> from the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
Remove_Valueリクエストを受信するサーバーは、最初に削除値の特権を持つ管理者としてクライアントを認証する必要があります。認証が成功すると、サーバーは<handle>から<indexlist>で指定されたハンドル値を削除します。成功した場合、サーバーはRC_SUCCESSメッセージをクライアントに返します。
Each REMOVE_VALUE request must be carried out as a transaction. If removing any value specified in the <IndexList> raises an error, the entire operation must be rolled back. For any failed REMOVE_VALUE request, none of values referenced in the <IndexList> should be removed from the <Handle>. The server must also send a response to the client that explains the error. For example, attempts to remove any handle value with neither PUB_WRITE nor ADMIN_WRITE permission will result in an RC_ACCESS_DENIED error. Note that a REMOVE_VALUE request asking to remove a non-existing handle value will not be treated as an error.
各remove_valueリクエストは、トランザクションとして実行する必要があります。<indexlist>で指定された値を削除すると、エラーが発生する場合、操作全体をロールバックする必要があります。失敗したremove_valueリクエストの場合、<indexlist>で参照されている値は<handle>から削除する必要はありません。また、サーバーは、エラーを説明するクライアントに応答を送信する必要があります。たとえば、pub_writeもadmin_writeの許可もなく、ハンドル値を削除しようとすると、RC_ACCESS_DENIEDエラーが発生します。存在しないハンドル値を削除するように要求するremove_value要求は、エラーとして扱われないことに注意してください。
REMOVE_VALUE requests can also be used to remove handle administrators. This happens if any of the indexes in the <IndexList> refer to an HS_ADMIN value. Servers must authenticate the client as an administrator with the REMOVE_ADMIN privilege before fulfilling such requests.
remove_valueリクエストは、ハンドル管理者を削除するためにも使用できます。これは、<indexlist>のインデックスのいずれかがHS_ADMIN値を参照した場合に発生します。サーバーは、そのようなリクエストを満たす前に、remove_admin特権を持つ管理者としてクライアントを認証する必要があります。
Clients can make modifications to an existing handle value by sending MODIFY_VALUE requests to the responsible handle server. The Message Header of the MODIFY_VALUE request must set its <OpCode> to OC_MODIFY_VALUE.
クライアントは、Modify_Valueリクエストを責任あるハンドルサーバーに送信することにより、既存のハンドル値に変更を加えることができます。modify_valueリクエストのメッセージヘッダーは、<opcode>をoc_modify_valueに設定する必要があります。
The Message Body of any MODIFY_VALUE request is defined as follows:
modify_valueリクエストのメッセージ本文は、次のように定義されています。
<Message Body of MODIFY_VALUE Response> ::= <Handle>
<ValueList>
where
ただし
<Handle> A UTF8-String that specifies the handle whose value(s) needs to be modified.
<handle>値を変更する必要があるハンドルを指定するUTF8-STRING。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer specifies the number of handle values in the list. Each value in the <ValueList> specifies a handle value that will replace the existing handle value with the same index.
<Valuelist> 4バイトの符号なし整数に続いて、ハンドル値のリストが続きます。整数は、リスト内のハンドル値の数を指定します。<valuelist>の各値は、既存のハンドル値を同じインデックスに置き換えるハンドル値を指定します。
The server that receives the MODIFY_VALUE request must first authenticate the client as an administrator with the MODIFY_VALUE privilege. Upon successful authentication, the server will proceed to replace those handle values listed in the <ValueList>, provided each handle value has PUB_WRITE or ADMIN_WRITE permission. If successful, the server must notify the client with an RC_SUCCESS message.
Modify_Valueリクエストを受信するサーバーは、最初にMODIFY_VALUE PRIVILEGEを使用して管理者としてクライアントを認証する必要があります。認証が成功すると、サーバーは、各ハンドル値にpub_writeまたはadmin_writeの許可がある場合、<valuelist>にリストされているハンドル値を置き換えます。成功した場合、サーバーはRC_SUCCESSメッセージでクライアントに通知する必要があります。
Each MODIFY_VALUE request must be carried out as a transaction. If replacing any value listed in the <ValueList> raises an error, the entire operation must be rolled back. For any failed MODIFY_VALUE request, none of values in the <ValueList> should be replaced. The server must also return a response to the client that explains the error. For example, if a MODIFY_VALUE requests to remove a handle value that has neither PUB_WRITE nor ADMIN_WRITE permission, the server must return an error message with the <ResponseCode> set to RC_ACCESS_DENIED. Any MODIFY_VALUE request to replace non- existing handle values is also treated as an error. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_NOT_FOUND.
各modify_valueリクエストは、トランザクションとして実行する必要があります。<valuelist>にリストされている値を置き換えると、エラーが発生する場合、操作全体をロールバックする必要があります。失敗したmodify_valueリクエストの場合、<valuelist>の値を置き換える必要はありません。サーバーは、エラーを説明するクライアントへの応答も返す必要があります。たとえば、Modify_Valueがpub_writeもadmin_writeの許可もないハンドル値を削除するように要求する場合、サーバーは<responsecode>をrc_access_deniedに設定してエラーメッセージを返す必要があります。既存の非ハンドル値を置き換えるためのModify_Value要求もエラーとして扱われます。この場合、サーバーは<rspessecode>をrc_value_not_foundに設定してエラーメッセージを返します。
MODIFY_VALUE requests can also be used to update handle administrators. This happens if both the values in the <ValueList> and the value to be replaced are HS_ADMIN values. Servers must authenticate the client as an administrator with the MODIFY_ADMIN privilege before fulfilling such a request. It is an error to replace a non-HS_ADMIN value with an HS_ADMIN value. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_INVALID.
Modify_valueリクエストを使用して、ハンドル管理者を更新することもできます。これは、<valuelist>の値と置き換える値の両方がHS_ADMIN値である場合に発生します。サーバーは、そのようなリクエストを満たす前に、Modify_Admin特権を持つ管理者としてクライアントを認証する必要があります。非HS_ADMIN値をHS_ADMIN値に置き換えることはエラーです。この場合、サーバーは<rspessecode>をrc_value_invalidに設定してエラーメッセージを返します。
Clients can create new handles by sending CREATE_HANDLE requests to the responsible handle server. The Message Header of any CREATE_HANDLE request must set its <OpCode> to OC_CREATE_HANDLE.
クライアントは、create_handleリクエストを責任あるハンドルサーバーに送信することにより、新しいハンドルを作成できます。Create_Handle要求のメッセージヘッダーは、<opcode>をoc_create_handleに設定する必要があります。
The Message Body of any CREATE_HANDLE request is defined as follows:
create_handleリクエストのメッセージ本文は、次のように定義されています。
<Message Body of CREATE_HANDLE Response> ::= <Handle>
<ValueList>
where
ただし
<Handle> A UTF8-String that specifies the handle.
<handle>ハンドルを指定するUTF8-STRING。
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer indicates the number of handle values in the list. The <ValueList> should at least include one HS_ADMIN value that defines the handle administrator.
<Valuelist> 4バイトの符号なし整数に続いて、ハンドル値のリストが続きます。整数は、リスト内のハンドル値の数を示します。<valuelist>には、少なくともハンドル管理者を定義するHS_ADMIN値を1つ含める必要があります。
Only naming authority administrators with the CREATE_HANDLE privilege are allowed to create new handles under the naming authority. The server that receives a CREATE_HANDLE request must authenticate the client as the administrator of the corresponding naming authority handle and make certain that the administrator is authorized to create handles under the naming authority. This is different from the ADD_VALUE request where the server authenticates the client as an administrator of the handle. Upon successful authentication, the server will proceed to create the new handle and add each value in the <ValueList> to the new <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
create_handle特権を持つ権限の管理者のみが、命名当局の下で新しいハンドルを作成することが許可されています。create_handle要求を受信するサーバーは、クライアントを対応する命名機関の管理者として認証し、管理者が命名権限の下でハンドルを作成することを許可されていることを確認する必要があります。これは、サーバーがハンドルの管理者としてクライアントを認証するADD_Valueリクエストとは異なります。認証が成功すると、サーバーは新しいハンドルを作成し、<valuelist>の各値をnew <handle>に追加します。成功した場合、サーバーはRC_SUCCESSメッセージをクライアントに返します。
Each CREATE_HANDLE request must be carried out as a transaction. If any part of the CREATE_HANDLE process fails, the entire operation can be rolled back. For example, if the server fails to add values in the <ValueList> to the new handle, it must return an error message without creating the new handle. Any CREATE_HANDLE request that asks to create a handle that already exists will be treated as an error. In this case, the server will return an error message with the <ResponseCode> set to RC_HANDLE_ALREADY_EXIST.
各create_handle要求は、トランザクションとして実行する必要があります。create_handleプロセスの一部が失敗した場合、操作全体をロールバックできます。たとえば、サーバーが<valuelist>の値を新しいハンドルに追加できない場合、新しいハンドルを作成せずにエラーメッセージを返す必要があります。既に存在するハンドルを作成するように依頼するcreate_handle要求は、エラーとして扱われます。この場合、サーバーはRC_HANDLE_ALREADY_EXISTに設定された<ResponseCode>を使用してエラーメッセージを返します。
CREATE_HANDLE requests can also be used to create naming authorities. Naming authorities are created as naming authority handles at the GHR. Before creating a new naming authority handle, the server must authenticate the client as the administrator of the parent naming authority. Only administrators with the CREATE_NA privilege are allowed to create any sub-naming authority. Root level naming authorities may be created by the administrator of the root handle "0.NA/0.NA".
create_handleリクエストは、命名当局を作成するためにも使用できます。命名当局は、GHRで命名当局ハンドルとして作成されます。新しい命名機関のハンドルを作成する前に、サーバーは親ネーミング機関の管理者としてクライアントを認証する必要があります。Create_na特権を持つ管理者のみが、任意のサブネーミング機関を作成することが許可されています。ルートレベルの命名当局は、ルートハンドル「0.NA/0.NA」の管理者によって作成される場合があります。
Clients delete existing handles by sending DELETE_HANDLE requests to the responsible handle server. The Message Header of the DELETE_HANDLE request must set its <OpCode> to OC_DELETE_HANDLE.
クライアントは、delete_handle要求を責任あるハンドルサーバーに送信して、既存のハンドルを削除します。delete_handle要求のメッセージヘッダーは、<opcode>をoc_delete_handleに設定する必要があります。
The Message Body of any DELETE_HANDLE request is defined as follows:
delete_handle要求のメッセージ本文は、次のように定義されます。
<Message Body of DELETE_HANDLE Request> ::= <Handle>
where
ただし
<Handle> A UTF8-String that specifies the handle.
<handle>ハンドルを指定するUTF8-STRING。
The server that receives the DELETE_HANDLE request must first authenticate the client as the administrator with the DELETE_HANDLE privilege. Upon successful authentication, the server will proceed to delete the handle along with any handle values assigned to the handle. If successful, the server will return an RC_SUCCESS message to the client.
delete_handle要求を受信するサーバーは、最初にdelete_handle Privilegeを使用して管理者としてクライアントを認証する必要があります。認証が成功すると、サーバーはハンドルに割り当てられたハンドル値とともにハンドルを削除します。成功した場合、サーバーはRC_SUCCESSメッセージをクライアントに返します。
Each DELETE_HANDLE request must be carried out as a transaction. If any part of the DELETE_HANDLE process fails, the entire operation must be rolled back. For example, if the server fails to remove any handle values assigned to the handle (before deleting the handle), it must return an error message without deleting the handle. This may happen if the handle contains a value that has neither PUB_WRITE nor ADMIN_WRITE permission. In this case, the server will return an error message with the <ResponseCode> set to RC_PERMISSION_DENIED. A DELETE_HANDLE request that asks to delete a non-existing handle will also be treated as an error. The server will return an error message with the <ResponseCode> set to RC_HANDLE_NOT_EXIST.
各delete_handle要求は、トランザクションとして実行する必要があります。delete_handleプロセスの一部が失敗した場合、操作全体をロールバックする必要があります。たとえば、サーバーがハンドルに割り当てられたハンドル値を削除しない場合（ハンドルを削除する前に）、ハンドルを削除せずにエラーメッセージを返す必要があります。これは、ハンドルにpub_writeもadmin_writeの許可もない値が含まれている場合に発生する可能性があります。この場合、サーバーはRC_Permission_Deniedに設定された<ResponseCode>を使用してエラーメッセージを返します。存在しないハンドルを削除するように要求するdelete_handle要求もエラーとして扱われます。サーバーは、RC_HANDLE_NOT_EXISTに設定された<ResponseCode>を使用してエラーメッセージを返します。
DELETE_HANDLE requests can also be used to delete naming authorities. This is achieved by deleting the corresponding naming authority handle on the GHR. Before deleting a naming authority handle, the server must authenticate the client as the administrator of the naming authority handle. Only administrators with the DELETE_NA privilege are allowed to delete the naming authority. Root level naming authorities may be deleted by the administrator of the root handle "0.NA/0.NA".
delete_handleリクエストは、命名当局を削除するためにも使用できます。これは、GHRの対応する命名機関のハンドルを削除することによって達成されます。命名機関のハンドルを削除する前に、サーバーはクライアントを命名機関ハンドルの管理者として認証する必要があります。delete_na特権を持つ管理者のみが、命名権限を削除することができます。ルートレベルの命名当局は、ルートハンドル「0.NA/0.NA」の管理者によって削除される場合があります。
The Handle System manages naming authorities via naming authority handles. Naming authority handles are managed by the GHR. Clients can change the service information of any naming authority by changing the HS_SITE values assigned to the corresponding naming authority handle. Creating or deleting naming authorities is done by creating or deleting the corresponding naming authority handles. Root level naming authorities may be created or deleted by the administrator of the root handle "0.NA/0.NA". Non-root-level naming authorities may be created by the administrator of its parent naming authority.
ハンドルシステムは、命名当局ハンドルを介して命名当局を管理します。命名権限ハンドルはGHRによって管理されます。クライアントは、対応する命名機関のハンドルに割り当てられたHS_SITE値を変更することにより、命名機関のサービス情報を変更できます。命名当局の作成または削除は、対応する命名機関のハンドルを作成または削除することにより行われます。ルートレベルの命名当局は、ルートハンドル「0.NA/0.NA」の管理者によって作成または削除される場合があります。非ルートレベルの命名当局は、親ネーミング機関の管理者によって作成される場合があります。
For example, the administrator of the naming authority handle "0.NA/10" may create the naming authority "10.1000" by sending a CREATE_HANDLE request to the GHR to create the naming authority handle "0.NA/10.1000". Before fulfilling the request, the server at the GHR must authenticate the client as the administrator of the parent naming authority, that is, the administrator of the naming authority handle "0.NA/10". The server must also make sure that the administrator has the NA_CREATE privilege.
たとえば、命名機関のハンドル「0.NA/10」の管理者は、create_handle要求をGHRに送信して命名権限ハンドル「0.NA/10.1000」を作成することにより、命名権限「10.1000」を作成できます。リクエストを満たす前に、GHRのサーバーは、クライアントを親ネーミング機関の管理者として認証する必要があります。つまり、命名当局の管理者は「0.NA/10」を処理します。また、サーバーは、管理者がNA_Create特権を持っていることを確認する必要があります。
The Handle protocol also allows clients to list handles or sub-naming authorities under a naming authority. Details of these operations are described in the following sections.
また、ハンドルプロトコルにより、クライアントは命名当局の下でハンドルまたはサブネーミング当局をリストすることもできます。これらの操作の詳細については、次のセクションで説明します。
Clients send LIST_HANDLE requests to handle servers to get a list of handles under a naming authority. The Message Header of the LIST_HANDLE request must set its <OpCode> to OC_LIST_HANDLE.
クライアントは、命名権限の下でハンドルのリストを取得するためにサーバーを処理するためにList_handleリクエストを送信します。list_handle要求のメッセージヘッダーは、<opcode>をoc_list_handleに設定する必要があります。
The Message Body of any LIST_HANDLE request is defined as follows:
List_Handleリクエストのメッセージ本文は、次のように定義されています。
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
where
ただし
<NA_Handle> A UTF8-String that specifies the naming authority handle.
<na_handle>命名権限ハンドルを指定するUTF8-STRING。
To obtain a complete list of the handles, the request must be sent to every handle server listed in one of the service sites of the responsible handle service. Each server within the service site will return its own list of handles under the naming authority. The Message Body of a successful LIST_HANDLE response (from each handle server) is defined as follows:
ハンドルの完全なリストを取得するには、責任あるハンドルサービスのサービスサイトのいずれかにリストされているすべてのハンドルサーバーにリクエストを送信する必要があります。サービスサイト内の各サーバーは、命名当局の下で独自のハンドルリストを返します。成功したlist_handle応答のメッセージ本文（各ハンドルサーバーから）は、次のように定義されています。
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
<Num_Handles> Number of handles (managed by the handle server) under the naming authority.
<num_handles>命名権限の下でのハンドル数（ハンドルサーバーによって管理）。
<HandleList> A list of UTF8-Strings, each of which identify a handle under the naming authority.
<handlelist> utf8-stringsのリスト。それぞれが命名当局の下でハンドルを識別します。
The LIST_HANDLE request may potentially slow down the overall system performance. A handle service (or its service site) has the option of whether or not to support such request. The server will return an RC_OPERATION_DENIED message if LIST_HANDLE is not supported. The server that receives a LIST_HANDLE request should authenticate the client as a naming authority administrator with the LIST_HANDLE privilege before fulfilling the request.
List_Handle要求は、システム全体のパフォーマンスを遅くする可能性があります。ハンドルサービス（またはそのサービスサイト）には、そのようなリクエストをサポートするかどうかのオプションがあります。list_handleがサポートされていない場合、サーバーはrc_operation_deniedメッセージを返します。List_Handle要求を受信するサーバーは、リクエストを満たす前に、List_handle Privilegeを使用して命名当局の管理者としてクライアントを認証する必要があります。
Clients send LIST_NA requests to handle servers to get a list of sub-naming authorities under a naming authority. The Message Header of the LIST_NA request must set its <OpCode> to OC_LIST_NA.
クライアントはList_naリクエストを送信してサーバーを処理して、命名当局の下でサブネーミング当局のリストを取得します。list_na要求のメッセージヘッダーは、<opcode>をoc_list_naに設定する必要があります。
The Message Body of any LIST_NA request is defined as follows:
List_na要求のメッセージ本文は、次のように定義されます。
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
where
ただし
<NA_Handle> A UTF8-String that specifies the naming authority handle.
<na_handle>命名権限ハンドルを指定するUTF8-STRING。
To obtain a complete list of the sub-naming authorities, the request must be sent to every handle server listed in any one of the service sites of the GHR. Each server within the service site will return its own list of sub-naming authority handles under the given naming authority. The Message Body of a successful LIST_NA response (from each handle server) is defined as follows:
サブネーミング当局の完全なリストを取得するには、GHRのいずれかのサービスサイトのいずれかにリストされているすべてのハンドルサーバーにリクエストを送信する必要があります。サービスサイト内の各サーバーは、特定の命名当局の下で、サブネーミング機関ハンドルの独自のリストを返します。成功したlist_na応答のメッセージ本文（各ハンドルサーバーから）は、次のように定義されています。
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
<Num_Handles> Number of handles (managed by the handle server) under the naming authority.
<num_handles>命名権限の下でのハンドル数（ハンドルサーバーによって管理）。
<HandleList> A list of UTF8-Strings, each of which identifies a sub-naming authority user-specified naming authority.
<handlelist> utf8-stringsのリスト。それぞれがサブネーミング機関のユーザー指定命名機関を識別します。
LIST_NA requests must be sent to servers under the GHR that manages all the naming authority handles. The LIST_NA request may potentially slow down the overall system performance, especially the GHS. A server (or service sites) under the GHR has the option of whether or not to support such requests. The server will return an RC_OPERATION_DENIED message if LIST_NA is not supported. The server that receives a LIST_HANDLE request should authenticate the client as a naming authority administrator with the LIST_NA privilege before fulfilling the request.
List_naリクエストは、すべての命名当局ハンドルを管理するGHRの下のサーバーに送信する必要があります。List_na要求は、システム全体のパフォーマンス、特にGHSを遅くする可能性があります。GHRの下にあるサーバー（またはサービスサイト）には、そのようなリクエストをサポートするかどうかのオプションがあります。list_naがサポートされていない場合、サーバーはrc_operation_deniedメッセージを返します。List_Handle要求を受信するサーバーは、リクエストを満たす前に、List_na Privilegeを使用して命名当局の管理者としてクライアントを認証する必要があります。
Sessions are used to allow sharing of authentication information or network resources among multiple protocol operations. For example, a naming authority administrator may authenticate itself once through the session setup, and then register multiple handles under the session.
セッションは、複数のプロトコル操作間で認証情報またはネットワークリソースの共有を許可するために使用されます。たとえば、命名当局の管理者は、セッションのセットアップを1回認証し、セッションの下で複数のハンドルを登録することができます。
A client may ask the server to establish a session key and use it for subsequent requests. A session key is a secret key that is shared by the client and server. It can be used to authenticate or encrypt any message exchanged under the session. A session is encrypted if every message exchanged within the session is encrypted using the session key.
クライアントは、サーバーにセッションキーを確立し、後続のリクエストに使用するように依頼する場合があります。セッションキーは、クライアントとサーバーが共有する秘密キーです。セッションで交換されたメッセージを認証または暗号化するために使用できます。セッション内で交換されるすべてのメッセージがセッションキーを使用して暗号化された場合、セッションが暗号化されます。
Sessions may be established as the result of an explicit OC_SESSION_SETUP request from a client. A server may also automatically setup a session when multiple message exchanges are expected to fulfill a request. For example, the server will automatically establish a session if it receives a CREATE_HANDLE request that requires client authentication.
セッションは、クライアントからの明示的なOC_Session_Setupリクエストの結果として確立される場合があります。また、複数のメッセージ交換がリクエストを満たすことが期待される場合、サーバーはセッションを自動的にセットアップすることもできます。たとえば、サーバーは、クライアント認証を必要とするcreate_handleリクエストを受信した場合、セッションを自動的に確立します。
Every session is identified by a non-zero Session ID that appears in the Message Header. Servers are responsible for generating a unique Session ID for each outstanding session. Each session may have a set of state information associated with it. The state information may include the session key and the information obtained from client authentication, as well as any communication options. Servers and clients are responsible for keeping the state information in sync until the session is terminated.
すべてのセッションは、メッセージヘッダーに表示されるゼロ以外のセッションIDによって識別されます。サーバーは、傑出したセッションごとに一意のセッションIDを生成する責任があります。各セッションには、それに関連する一連の州情報がある場合があります。州の情報には、セッションキーとクライアント認証から得られた情報、および通信オプションが含まれる場合があります。サーバーとクライアントは、セッションが終了するまで、状態情報を同期させる責任があります。
A session may be terminated with an OC_SESSION_TERMINATE request from the client. Servers may also terminate a session that has been idle for a significant amount of time.
セッションは、クライアントからのoc_session_terminateリクエストで終了する場合があります。サーバーは、かなりの時間をアイドル状態にしたセッションを終了する場合があります。
Clients establish a session with a handle server with a SESSION_SETUP request. A SESSION_SETUP request can also be used to update any state information associated to an existing session. The Message Header of the SESSION_SETUP request must have its <OpCode> set to OC_SESSION_SETUP and <ResponseCode> to 0.
クライアントは、Session_Setupリクエストを使用して、ハンドルサーバーを使用してセッションを確立します。Session_Setupリクエストを使用して、既存のセッションに関連付けられた状態情報を更新することもできます。session_setupリクエストのメッセージヘッダーには、<opcode>がoc_session_setupに設定され、<lesspecode>に設定されている必要があります。
The Message Body of any SESSION_SETUP request is defined as follows:
任意のsession_setupリクエストのメッセージ本文は、次のように定義されます。
<SESSION_SETUP Request Message Body> ::= <SessionAttributes>
where
ただし
<SessionAttributes> A 4-byte unsigned integer followed by a list of session attributes. The integer indicates the number of session attributes in the list. Possible session attributes include the <HS_SESSION_IDENTITY>, the <HS_SESSION_TIMEOUT>, and the <HS_SESSION_KEY_EXCHANGE>. Each of these attributes is defined as follows:
<SessionAttributes> 4バイトの符号なし整数に続いて、セッション属性のリストが続きます。整数は、リスト内のセッション属性の数を示します。可能なセッション属性には、<hs_session_identity>、<hs_session_timeout>、<hs_session_key_exchange>、<hs_session_timeout>、および<hs_key_exchange>が含まれます。これらの属性のそれぞれは、次のように定義されます。
<HS_SESSION_IDENTITY> ::= <Key>
<Handle>
<ValueIndex>
where
<Key> A UTF-8 string constant "HS_SESSION_IDENTITY".
<キー> UTF-8文字列定数「hs_session_identity」。
<Handle> <ValueIndex> A UTF-8 string followed by a 4-byte unsigned integer that specifies the handle and the handle value used for client authentication. It must refer to a handle value that contains the public key of the client. The public key is used by the server to authenticate the client.
<handle> <valyIndex> UTF-8文字列に続いて、クライアント認証に使用されるハンドルとハンドル値を指定する4バイトの符号なし整数が続きます。クライアントの公開鍵を含むハンドル値を参照する必要があります。公開キーは、クライアントを認証するためにサーバーによって使用されます。
<HS_SESSION_KEY_EXCHANGE> ::= <Key>
<KeyExchangeData>
where
<Key> A UTF-8 string constant "HS_SESSION_KEY_EXCHANGE".
<キー> UTF-8文字列定数 "HS_SESSION_KEY_EXCHANGE"。
<KeyExchangeData> One of the these tuples: <ClientCipher <ClientCipher KeyExchange>, <HdlCipher KeyExchange>, or <ServerCipher KeyExchange>. Each of these tuples is defined as follows:
<KeyExchangeData>これらのタプルの1つ：<ClientCipher <ClientCipher keyExchange>、<HDLCipher keyExchange>、または<serverCipher keyExchange>。これらのタプルのそれぞれは、次のように定義されています。
<ClientCipher KeyExchange> ::= <Key>
<PubKey>
where
<Key> A UTF-8 string constant "CLIENT_CIPHER".
<キー> UTF-8文字列定数「client_cipher」。
<PubKey> A public key provided by the client and used by the server to encrypt the session key.
<pubkey>クライアントが提供し、セッションキーを暗号化するためにサーバーが使用する公開キー。
<HdlCipher KeyExchange> ::= <Key>
<ExchangeKeyHdl>
<ExchangeKeyIndex>
where
<Key> A UTF-8 string constant "HDL_CIPHER".
<キー> UTF-8文字列定数「HDL_CIPHER」。
<ExchangeKeyHdl> <ExchangeKeyIndex> A UTF-8 string followed by a 4-byte unsigned integer. The <ExchangeKeyHdl> and <ExchangeKeyIndex> refers to a handle value used for session key exchange. The handle value must contain the public key of the client. The public key will be used by the server to encrypt the session key before sending it to the client.
<ExchangeKeyhdl> <ExchangeKeyIndex> UTF-8文字列に続いて、4バイトの符号なし整数が続きます。<exchangekeyhdl>および<echangekeyindex>は、セッションキーエクスチェンジに使用されるハンドル値を指します。ハンドル値には、クライアントの公開キーが含まれている必要があります。公開キーは、クライアントに送信する前に、セッションキーを暗号化するためにサーバーによって使用されます。
<ServerCipher KeyExchange> ::= <Key>
where
ただし
<Key> A UTF-8 string constant "SERVER_CIPHER". This tells the server that the client will be responsible for generating the session key. The server will have to provide its public key in the response message and set the <ResponseCode> to RC_SESSION_EXCHANGEKEY. The client can use the server's public key to encrypt the session key and send it to the server via a subsequent SESSION_EXCHANGEKEY request.
<キー> UTF-8文字列定数 "server_cipher"。これにより、クライアントがセッションキーを生成する責任があることをサーバーに伝えます。サーバーは、応答メッセージに公開キーを提供し、<ressupecode>をrc_session_exchangekeyに設定する必要があります。クライアントは、サーバーの公開キーを使用して、セッションキーを暗号化し、後続のsession_exchangekeyリクエストを介してサーバーに送信できます。
<DiffieHellman KeyExchange> ::= <Key>
<DHParams>
where
<Key> A UTF-8 string constant "DIFFIE_HELLMAN"
<キー> UTF-8文字列定数「diffie_hellman」
<DHParams> The values used as input in the Diffie-Hellman algorithm. It consists of three big integers of variable length. Each big integer is encoded in terms of a 4-byte unsigned integer followed by an octet string. The octet string contains the big integer itself. The 4-byte unsigned integer specifies the number of octets of the octet string.
<dhparams> diffie-hellmanアルゴリズムの入力として使用される値。可変長の3つの大きな整数で構成されています。各大きな整数は、4バイトの符号なし整数の観点からエンコードされ、その後にオクテット弦が続きます。Octet文字列には、大きな整数自体が含まれています。4バイトの符号なし整数は、オクテット弦のオクテットの数を指定します。
<HS_SESSION_TIMEOUT> ::= <Key>
<TimeOut>
where
<Key> A UTF-8 string constant "HS_SESSION_TIMEOUT".
<キー> UTF-8文字列定数「HS_SESSION_TIMEOUT」。
<TimeOut> A 4-byte unsigned integer that specifies the desired duration of the session in seconds.
<timeout>セッションの目的の期間を秒単位で指定する4バイトの符号なし整数。
Note that it should be treated as an error if the same session attribute is listed multiple times in the <SessionAttribute> field. When this happens, the server should return an error message with <ResponseCode> set to RC_PROTOCOL_ERROR.
同じセッション属性が<sessionAttribute>フィールドに複数回リストされている場合、エラーとして扱う必要があることに注意してください。これが発生した場合、サーバーは<rspessecode>をrc_protocol_errorに設定してエラーメッセージを返す必要があります。
A SESSION_SETUP_REQUEST can be used to change session attributes of any established session. This happens if the <SessionId> is non-zero and matches one of the established sessions. Care must be taken by the server to prevent any unauthorized request from changing the session attributes. For example, an encrypted session may only be changed into an unencrypted session by a SESSION_SETUP_REQUEST with an appropriate MAC in its Message Credential.
session_setup_requestを使用して、確立されたセッションのセッション属性を変更できます。これは、<sessionId>がゼロ以外であり、確立されたセッションの1つと一致する場合に発生します。不正な要求がセッション属性を変更しないように、サーバーが注意する必要があります。たとえば、暗号化されたセッションは、メッセージ資格情報に適切なMACを使用したSESSION_SETUP_REQUESTによってのみ、暗号化されていないセッションに変更される場合があります。
The Message Header of the SESSION_SETUP response must set its <OpCode> to OC_SESSION_SETUP. The <ResponseCode> of the SESSION_SETUP response varies according to the SESSION_SETUP request. It must be set to RC_SUCCESS if the SESSION_SETUP request is successful and the server does not expect a session key to be returned by the client.
session_setup応答のメッセージヘッダーは、<opcode>をoc_session_setupに設定する必要があります。Session_Setup Responseの<ResponseCode>は、Session_Setupリクエストによって異なります。Session_Setupリクエストが成功し、サーバーがクライアントがセッションキーを返すことをサーバーが期待していない場合、RC_SUCCESSに設定する必要があります。
The Message Body of the SESSION_SETUP response is empty unless the request is asking for <HS_SESSION_KEY_EXCHANGE>. In this case, the Message Body of the SESSION_SETUP response may contain the encrypted session key from the server, or the server's public key, to be used for session key exchange. The exact format depends on the content of the <HS_SESSION_KEY_EXCHANGE> in the SESSION_SETUP request. If <ClientCipher KeyExchange> or <HdlCipher KeyExchange> is given in the SESSION_SETUP request, the Message Body of the SESSION_SETUP response will contain the encrypted session key from the server and is defined as follows:
リクエストが<hs_session_key_exchange>を要求している場合を除き、session_setup応答のメッセージ本文は空です。この場合、Session_Setup応答のメッセージ本文には、セッションキーの交換に使用されるサーバーまたはサーバーの公開キーからの暗号化されたセッションキーが含まれている場合があります。正確な形式は、session_setupリクエストの<hs_session_key_exchange>のコンテンツに依存します。<clientcipher keyExchange>または<hdlcipher keyExchange>がSession_setupリクエストに与えられている場合、Session_setup応答のメッセージ本文には、サーバーから暗号化されたセッションキーが含まれ、次のように定義されます。
<Message Body of SESSION_SETUP Response>
::= <RequestDigest>
<EncryptedSessionKey>
[ <EncryptionAlgorithm> ]
where
<RequestDigest> Message digest of the SESSION_SETUP request is as specified in section 2.2.3.
<RequestDigest> SESSION_SETUPリクエストのメッセージダイジェストは、セクション2.2.3で指定されています。
<EncryptedSessionKey> Session key is encrypted using the public key provided in the SESSION_SETUP request. The session key is a randomly generated octet string from the server. The server will only return the <EncryptedSessionKey> if the <KeyExchangeData> in the SESSION_SETUP request provides the public key from the client.
<暗号化されたセッションキー>セッションキーは、session_setupリクエストで提供される公開キーを使用して暗号化されます。セッションキーは、サーバーからランダムに生成されたオクテット文字列です。サーバーは、session_setupリクエストの<keyexchangedata>がクライアントから公開キーを提供する場合にのみ<encryptedsessionkey>を返します。
<EncryptionAlgorithm> (optional) UTF-8 string that identifies the encryption algorithm used by the session key.
<encryptionalgorithm>（オプション）セッションキーで使用される暗号化アルゴリズムを識別するUTF-8文字列。
If <ServerCipher KeyExchange> is given in the SESSION_SETUP request, the server must provide its public key in the SESSION_SETUP response. The public key can be used by the client in a subsequent SESSION_EXCHANGEKEY request (defined below) for session key exchange. In this case, the Message Header of the SESSION_SETUP response must set its <ResponseCode> to RC_SESSION_EXCHANGEKEY. The Message Body of the SESSION_SETUP response must include the server's public key and is defined as follows:
<serverCipher keyExchange>がsession_setupリクエストで指定されている場合、サーバーはsession_setup応答で公開キーを提供する必要があります。公開キーは、セッションキーエクスチェンジのために、以降のSession_ExchangeKeyリクエスト（以下に定義）でクライアントが使用できます。この場合、session_setup応答のメッセージヘッダーは、<lesspecode>をrc_session_exchangekeyに設定する必要があります。SESSION_SETUP応答のメッセージ本文には、サーバーの公開キーを含める必要があり、次のように定義されています。
<Message Body of SESSION_SETUP response>
::= <RequestDigest>
<Public Key for Session Key Exchange>
where
ただし
<RequestDigest> Message digest of the SESSION_SETUP request as specified in section 2.2.3.
<RequestDigest>セクション2.2.3で指定されているSESSION_SETUPリクエストのメッセージダイジェスト。
<Public Key for Session Key Exchange> Public key from the server to be used for session key exchange. It is encoded in the same format as the <PublicKey> record in the HS_SITE value (see section 3.2.2 in [2]).
<セッションキーエクスチェンジの公開キー>セッションキーエクスチェンジに使用されるサーバーからの公開キー。HS_SITE値の<publicKey>レコードと同じ形式でエンコードされています（[2]のセクション3.2.2を参照）。
If the <ResponseCode> of a SESSION_SETUP response is RC_SESSION_EXCHANGEKEY, the client is responsible for generating the session key and sending it to the server. In this case, the client can generate a session key, encrypt it with the public key provided by the server in the SESSION_SETUP response, and send the encrypted session key to the server in a SESSION_EXCHANGEKEY request.
Session_Setup Responseの<ResponseCode>がRC_SESSION_EXCHANGEKEYの場合、クライアントはセッションキーを生成してサーバーに送信する責任があります。この場合、クライアントはセッションキーを生成し、Session_Setup応答でサーバーが提供する公開キーで暗号化し、Session_Exchangekeyリクエストで暗号化されたセッションキーをサーバーに送信できます。
The Message Header of the SESSION_EXCHANGEKEY request must set its <OpCode> to OC_SESSION_EXCHANGEKEY and its <ResponseCode> to 0. The Message Body of the SESSION_EXCHANGEKEY request is defined as follows:
session_exchangekeyリクエストのメッセージヘッダーは、<opcode>をoc_session_exchangekeyに<opcode>に設定し、<responsecode>に0に設定する必要があります。
<Message Body of OC_SESSION_EXCHANGEKEY>
::= <Encrypted Session Key>
[ <EncryptionAlgorithm> ]
where
ただし
<EncryptedSessionKey> Session key encrypted using the public key provided in the SESSION_SETUP response. The session key is a randomly generated octet string by the client.
<暗号化されたセッションキー>セッションキーは、Session_Setup Responseで提供される公開キーを使用して暗号化されました。セッションキーは、クライアントによってランダムに生成されたオクテット文字列です。
<EncryptionAlgorithm> (optional) UTF-8 string that identifies the encryption algorithm used by the session key.
<encryptionalgorithm>（オプション）セッションキーで使用される暗号化アルゴリズムを識別するUTF-8文字列。
During the session key exchange, the server receiving the exchange key or session key has the responsibility of ensuring that the key meets the security requirements defined in its local policy. If the server considers the key being volunable, it must return an error message to the client with <ResponseCode> set to RC_SESSION_KEY_INVALID.
セッションキーエクスチェンジ中、Exchangeキーまたはセッションキーを受信するサーバーには、キーがローカルポリシーで定義されているセキュリティ要件を満たすことを保証する責任があります。サーバーがキーをボルーナブルと見なしている場合、RC_SESSION_KEY_INVALIDに設定されている<ResponseCode>を使用して、クライアントにエラーメッセージを返す必要があります。
Clients can terminate a session with a SESSION_TERMINATE request. The Message Header of a SESSION_TERMINATE request must have its <OpCode> set to OC_SESSION_TERMINATE and its <ResponseCode> to 0. The message body of any SESSION_TERMINATE request must be empty.
クライアントは、session_terminateリクエストでセッションを終了できます。session_terminateリクエストのメッセージヘッダーには、<opcode>がoc_session_terminateに設定され、<session_terminateリクエストのメッセージ本文が空でなければなりません。
The server must send a SESSION_TERMINATE response to the client after the session is terminated. The server should only terminate the session after it has finished processing all the requests (under the session) that were submitted before the Session Termination request.
サーバーは、セッションが終了した後、Cession_terminate応答をクライアントに送信する必要があります。サーバーは、セッション終了リクエストの前に送信されたすべてのリクエスト（セッションの下）の処理が完了した後にのみ終了する必要があります。
The message header of the SESSION_TERMINATE response must set its <OpCode> to OC_SESSION_TERMINATE. A successful SESSION_TERMINATE response must have its <ResponseCode> set to RC_SUCCESS, and an empty message body.
session_terminate応答のメッセージヘッダーは、<opcode>をoc_session_terminateに設定する必要があります。SESSION_ TERNINESの成功には、<ResponseCode>がRC_SUCCESSに設定され、空のメッセージ本文が必要です。
The optimal structure for any handle server will depend on the host operating system. This section only addresses those implementation considerations that are common to most handle servers.
ハンドルサーバーの最適構造は、ホストオペレーティングシステムに依存します。このセクションでは、ほとんどのハンドルサーバーに共通する実装に関する考慮事項のみを説明します。
A good server implementation should allow easy configuration or fine-tuning. A suggested list of configurable items includes the server's network interface(s) (e.g., IP address, port number, etc.), the number of concurrent processes/threads allowed, time-out intervals for any TCP connection and/or authentication process, re-try policy under UDP connection, policies on whether to support recursive service, case-sensitivity for ASCII characters, and different levels of transaction logging, etc.
優れたサーバーの実装は、簡単な構成または微調整を可能にする必要があります。設定可能なアイテムの提案されたリストには、サーバーのネットワークインターフェイス（例：IPアドレス、ポート番号など）、許可されている同時プロセス/スレッドの数、TCP接続および/または認証プロセスのタイムアウト間隔、UDP接続の下でのポリシーを再試行し、再帰サービスをサポートするかどうか、ASCII文字のケース感受性、およびさまざまなレベルのトランザクションロギングなど。
All handle server implementations must support all the handle data types as defined in the "Handle System Namespace and Service Definition" [2]. They should also be able to store handle values of any application defined data type.
すべてのハンドルサーバーの実装は、「ハンドルシステムの名前空間とサービス定義」で定義されているように、すべてのハンドルデータ型をサポートする必要があります[2]。また、アプリケーション定義されたデータ型のハンドル値を保存できるはずです。
A handle server must support multiple concurrent activities, whether they are implemented as separate processes or threads in the host's operating system, or multiplexed inside a single name server program. A handle server should not block the service of UDP requests while it waits for TCP data or other query activities. Similarly, a handle server should not attempt to provide recursive service without processing such requests in parallel, though it may choose to serialize requests from a single client, or to regard identical requests from the same client as duplicates.
ハンドルサーバーは、ホストのオペレーティングシステム内の個別のプロセスまたはスレッドとして実装されている場合でも、単一の名前サーバープログラム内で多重化されている場合でも、複数の同時アクティビティをサポートする必要があります。ハンドルサーバーは、TCPデータまたは他のクエリアクティビティを待っている間、UDPリクエストのサービスをブロックしてはなりません。同様に、ハンドルサーバーは、そのような要求を並行して処理せずに再帰サービスを提供しようとしないでください。ただし、単一のクライアントからのリクエストをシリアル化することも、同じクライアントからの同一のリクエストを複製と見なすこともできます。
Clients should be prepared to receive handle values of any data type. Clients may choose to implement a callback interface to allow new modules or plug-ins to be added to support any application-defined data types.
クライアントは、データ型のハンドル値を受信する準備をする必要があります。クライアントは、アプリケーション定義のデータ型をサポートするために、新しいモジュールまたはプラグインを追加できるようにコールバックインターフェイスを実装することを選択できます。
Clients that follow service referrals or handle aliases must avoid falling into an infinite loop. They should not repeatedly contact the same server for the same request with the same target entry. A client may choose to use a counter that is incremented each time it follows a service referral or handle alias. There should be a configurable upper limit to the counter to control the levels of service referrals or handle aliases followed by the client.
サービスの紹介やエイリアスを処理するクライアントは、無限のループに陥らないようにしなければなりません。同じターゲットエントリを使用して同じ要求について、同じサーバーに繰り返し連絡するべきではありません。クライアントは、サービスの紹介に従うたびに増分されるカウンターを使用するか、エイリアスを処理することを選択できます。サービスの紹介のレベルを制御したり、エイリアスを処理した後にクライアントがそれに続くために、カウンターに設定可能な上限があるはずです。
Clients that provide some caching can expect much better performance than those that do not. Client implementations should always consider caching the service information associated with a naming authority. This will reduce the number of roundtrips for subsequent handle requests under the same naming authority.
キャッシュを提供するクライアントは、そうでないパフォーマンスよりもはるかに優れたパフォーマンスを期待できます。クライアントの実装は、命名当局に関連するサービス情報のキャッシュを常に検討する必要があります。これにより、同じ命名当局に基づく後続のハンドル要求の往復の数が減ります。
The overall Handle System security considerations are discussed in "Handle System Overview" [1]; that discussion applies equally to this document. Security considerations regarding the Handle System data model and service model are discussed in "Handle System Namespace and Service Definition" [2].
ハンドルシステム全体のセキュリティに関する考慮事項については、「ハンドルシステムの概要」[1]で説明します。その議論は、このドキュメントにも同様に適用されます。ハンドルシステムデータモデルとサービスモデルに関するセキュリティ上の考慮事項については、「ハンドルシステム名とサービスの定義」[2]で説明しています。
For efficiency, the Handle protocol includes a simple challenge-response authentication protocol for basic client authentication. Handle servers are free to provide additional authentication mechanisms (e.g., SASL) as needed. Details of this will be discussed in a separate document.
効率のために、ハンドルプロトコルには、基本的なクライアント認証のためのシンプルなチャレンジ応答認証プロトコルが含まれています。ハンドルサーバーは、必要に応じて追加の認証メカニズム（SASLなど）を無料で提供できます。この詳細については、別のドキュメントで説明します。
Data integrity under the Handle protocol is achieved via the server's digital signature. Care must be taken to protect the server's private key from any impersonation attack. Any change to the server's public key pair must be registered (in terms of service information) with the GHR.
ハンドルプロトコルの下でのデータの整合性は、サーバーのデジタル署名を介して達成されます。サーバーの秘密鍵をなりすまし攻撃から保護するように注意する必要があります。サーバーの公開キーペアへの変更は、GHRに（サービス情報の観点から）登録する必要があります。
This work is derived from the earlier versions of the Handle System implementation. The overall digital object architecture, including the Handle System, was described in a paper by Robert Kahn and Robert Wilensky [22] in 1995. Development continued at CNRI as part of the Computer Science Technical Reports (CSTR) project, funded by the Defense Advanced Projects Agency (DARPA) under Grant Number MDA-972- 92-J-1029 and MDA-972-99-1-0018. Design ideas are based on those discussed within the Handle System development team, including David Ely, Charles Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie Nguyen, Jason Petrone, and Helen She. Their contributions to this work are gratefully acknowledged.
この作業は、ハンドルシステムの実装の以前のバージョンから派生しています。ハンドルシステムを含む全体的なデジタルオブジェクトアーキテクチャは、1995年にRobert KahnとRobert Wilensky [22]による論文で説明されました。助成金番号MDA-972- 92-J-1029およびMDA-972-99-1-0018に基づくプロジェクト局（DARPA）。デザインのアイデアは、デビッドイーリー、チャールズオース、アリソンユー、ショーンライリー、ジェーンオイラー、キャサリンレイ、ステファニーヌグエン、ジェイソンペトローン、ヘレンSHなど、ハンドルシステム開発チーム内で議論されているものに基づいています。この作業への彼らの貢献は感謝されています。
The authors also thank Russ Housley (housley@vigilsec.com), Ted Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) for their extensive review and comments, as well as recommendations received from other members of the IETF/IRTF community.
著者はまた、Russ Housley（housley@vigilsec.com）、Ted Hardie（hardie@qualcomm.com）、およびMark Baugher（mbaugher@cisco.com）、および大規模なレビューとコメント、および他のメンバーから受け取った推奨事項に感謝します。IETF/IRTFコミュニティ。
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650, November 2003.
[1] Sun、S。and L. Lannom、「ハンドルシステムの概要」、RFC 3650、2003年11月。
[2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and Service Definition", RFC 3651, November 2003.
[2] Sun、S.、Reilly、S。、およびL. Lannom、「Handle System Namespace and Service Definition」、RFC 3651、2003年11月。
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[3] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[4] A. Freier, P. Karlton, P. Kocher "The SSL Protocol Version 3.0"
[4] A. Freier、P。Karlton、P。Kocher「SSLプロトコルバージョン3.0」
[5] RSA Laboratories, "Public-Key Cryptography Standard PKCS#7" http://www.rsasecurity.com/rsalabs/pkcs/
[5] RSA Laboratories、「Public-Key Cryptography Standard PKCS＃7」http://www.rsasecurity.com/rsalabs/pkcs/
[6] U.S. Federal Information Processing Standard: Digital Signature Standard.
[6] 米国連邦情報処理標準：デジタル署名標準。
[7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[7] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3370、2002年8月。
[8] Braden, R., "FTP Data Compression", RFC 468, March 1973.
[8] Braden、R。、「FTPデータ圧縮」、RFC 468、1973年3月。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[10] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[10] Nist、Fips Pub 180-1：Secure Hash Standard、1995年4月。
[11] D. Cohen, "On Holy Wars and a Plea for Peace", Internet Experiment, Note IEN 137, 1 April 1980.
[11] D. Cohen、「聖戦と平和の嘆願について」、インターネット実験、1980年4月1日、IEN 137に注意してください。
[12] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[12] Balakrishnan、H。およびS. Seshan、「ザ・ミッシングマネージャー」、RFC 3124、2001年6月。
[13] R. Kahn, R. Wilensky, "A Framework for Distributed Digital Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[13] R. Kahn、R。Wilensky、「分散デジタルオブジェクトサービスのフレームワーク、1995年5月、http：//www.cnri.reston.va.us/k-w.html
[14] Polk, W., Housley, R. and L. Bassham, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[14] Polk、W.、Housley、R。、およびL. Bassham、「インターネットのアルゴリズムと識別子X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3279、2002年4月。
[15] 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.
[15] Housley、R.、Polk、W.、Ford、W。and D. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[16] M. Bellare and P. Rogaway. The Exact Security of Digital Signatures - How to Sign with RSA and Rabin. In Advances in Cryptology-Eurocrypt '96, pp.399-416, Springer-Verlag, 1996.
[16] M. BellareとP. Rogaway。デジタル署名の正確なセキュリティ - RSAとRabinで署名する方法。Cryptology-Eurocrypt '96、pp.399-416、Springer-Verlag、1996年の進歩
[17] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[17] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[18] R. Kahn, R. Wilensky, "A Framework for Distributed Digital Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[18] R. Kahn、R。Wilensky、「分散デジタルオブジェクトサービスのフレームワーク、1995年5月、http：//www.cnri.reston.va.us/k-w.html
Sam X. Sun Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
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
電話：703-262-5316メール：ssun@cnri.reston.va.us
Sean Reilly Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
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
電話：703-620-8990メール：sreilly@cnri.reston.va.us
Larry Lannom Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
Larry Lannom Corporation for National Research Initiatives（CNRI）1895 Preston White Dr.、Suite 100 Reston、VA 20191
Phone: 703-262-5307 EMail: llannom@cnri.reston.va.us
電話：703-262-5307メール：llannom@cnri.reston.va.us
Jason Petrone Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
ジェイソン・ペトローヌ・コーポレーション・フォー・ナショナル・リサーチ・イニシアチブ（CNRI）1895 Preston White Dr.、Suite 100 Reston、VA 20191
Phone: 703-262-5340 EMail: jpetrone@cnri.reston.va.us
電話：703-262-5340メール：jpetrone@cnri.reston.va.us
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。