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
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.
著作権（C）インターネット協会（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コンセンサスが得られていないことを指摘したいです。特にURNとして、URIの形式として、ハンドルの議論がなされているが、これらの文書は、名前空間と識別子は、インターネット上で動作し、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年にロバート・Wilensky [18]の論文に記載されました。各要求は、サーバー上で実行される操作について説明しています。サーバは、要求を処理し、操作の結果を示すメッセージを返します。この文書では、ハンドルの解像度と管理のためのハンドルサーバにアクセスするためのクライアント・ソフトウェアのためのプロトコルを指定します。これは、ハンドルサーバを管理するために使用されるプロトコルの記述が含まれていません。管理プロトコルの説明は、この文書の範囲外であり、別の文書で利用可能となります。文書は2 [「ハンドルSystem名前空間とサービス定義」に与えられた[1]と同様に、データモデルやサービスの定義「ハンドルシステムの概要」で導入され、読者はハンドルシステムの基本的な概念に精通していることを前提としてい]。
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サーバーは、ハンドル認証プロトコルを介してハンドル管理者として、クライアントを認証することができます。ハンドル認証プロトコルは、公開鍵と秘密鍵による認証の両方をサポートしてチャレンジ応答プロトコルです。
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.
その認証情報とネットワーク資源（例えば、TCP接続）は、複数の操作の間で共有することができるので、Oセッションは、クライアントとサーバの間で確立されてもよいです。セッションキーは、データの整合性と機密性を達成するために確立することができます。
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（ユニコード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.
データパケットの送信の順序が（ビッグエンディアン[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（10進数）を表します。
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によって運ばれるメッセージは、（IPまたはUDPヘッダを含まない）512バイトに制限されています。長いメッセージは、各パケットは、メッセージエンベロープ（セクション2.2.1を参照）で適切なシーケンス番号を搬送するUDPパケットに断片化されなければなりません。
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.
[12]そのような輻輳マネージャへのインターフェースとしてデータ、TCP向け輻輳制御、大量に送信する場合、TCPベースのアプリケーションに対する帯域幅の不当な消費を避けるために、可能な限り、O、実装されるべきです。輻輳制御の詳細については、別の文書で説明します。
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-文字列は、UTF8エンコーディングの文字列に続く4バイトの符号なし整数で構成されたデータ型を表します。大手整数、文字列のオクテット数を指定します。
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>と<MinorVersionの>ハンドルプロトコルのバージョンを識別するために使用されます。それらのそれぞれは、1バイトの符号なし整数として定義されています。この仕様は、その<のMajorVersion> 2であり、<MinorVersionの> 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>と<MinorVersionの>将来の下位互換性を許可するように設計されています。 <のMajorVersion>の違いは、プロトコル形式の主要な変動を示し、下の<のMajorVersion>を持つ当事者が、正確な通信を確保するためのソフトウェアをアップグレードする必要があります。増加<MinorVersionの>追加機能は、メッセージ形式への大きな変更なしにプロトコルに追加されたときに行われます。
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.
<セッションID>クライアントとサーバとの間の通信セッションを識別する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.
セッションとその<セッション>クライアントまたは複数のメッセージ交換がクライアントの要求を満たすことが期待されているときからの明示的な要求に応じていずれか、サーバーによって割り当てられます。それはクライアントを認証する必要がある場合たとえば、サーバーはその応答で<セッション>ユニークに割り当てます。クライアントは、明示的にSSL [4]のような事実上のプライベート通信チャネルとしてセッションを設定するには、サーバーを求めることができます。確立されたセッションのないクライアントからの要求はゼロに彼らの<セッション>セットを持っている必要があります。サーバーは、新しいセッションごとのユニークな非ゼロ<セッション>を割り当てる必要があります。また、ある程度の期間の後に使用されていないこれらのセッションを終了するための責任があります。
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.
クライアントとサーバの両方が確立されたセッションの下で交換されるメッセージのために<セッション>同じを維持する必要があります。その<セッション>ゼロのメッセージには、セッションが確立されていないことを示しています。
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コネクション上で共有することができます。セッションが確立されると、クライアントとサーバの両方が<セッション>に応じてそれらの状態情報を維持する必要があります。状態情報は、会話の舞台、相手の認証情報、およびメッセージの暗号化や認証のために設立されたセッションキーを含むことができます。これらの詳細については、セクション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>によって識別されます。各<RequestId>同じクライアントから他のすべての未解決の要求から一意である必要があります。 <RequestId>は、クライアントがその要求を追跡することを可能にし、サーバーからの応答は、<RequestId>正しいを含める必要があります。
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.
<オペコード>は、意図する動作を指定する4バイトの符号なし整数であるオペレーション・コード、を表します。次の表は基本プロトコル仕様に準拠するために、すべての実装によってサポートされなければならない<オペコード> 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
100 OC_CREATE_HANDLEハンドル値（S）を取り外し、ハンドル102 OC_ADD_VALUEハンドル値（複数可）を追加し、既存の削除103 OC_REMOVE_VALUEを新しいハンドル101 OC_DELETE_HANDLE作成104 OC_MODIFY_VALUE変更ハンドル値（複数可）105 OC_LIST_HANDLEリスト106 OC_LIST_NAリストサブ命名権限を処理
200 OC_CHALLENGE_RESPONSE Response to challenge 201 OC_VERIFY_RESPONSE Verify challenge response
201 OC_VERIFY_RESPONSEに挑戦する200 OC_CHALLENGE_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セッション鍵交換
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.
これら<オペコード> Sのそれぞれの詳細な説明は、このドキュメントのセクション3に見出すことができます。一般的には、クライアントは、彼らが達成したいハンドル操作の種類をサーバーに伝えるために、<オペコード>を使用します。サーバからの応答は、元の要求として<オペコード>同じを維持し、その結果を示すために、<はResponseCode>を使用する必要があります。
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バイトの符号なし整数です。 <はResponseCode>ハンドルプロトコルで使用される秒のリストを以下の表に定義されています。各応答コードは簡単に参照のために本明細書を通じて使用されるシンボル名を与えられています。
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
0 RC_RESERVED予約の要求1つのRC_SUCCESS成功応答2 RC_ERROR一般的なエラー3 RC_SERVER_BUSYサーバの要求のために4 RC_PROTOCOL_ERROR破損しているか認識できないメッセージ5 RC_OPERATION_DENIEDサポートされていない操作6 RC_RECUR_LIMIT_EXCEEDEDあまりにも多くの再帰を対応するには余りにも忙しいです
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ハンドルが既に102 RC_INVALID_HANDLE符号化（または構文）が存在するが見つかりませんハンドルエラー
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値が既に202 RC_VALUE_INVALID無効なハンドル値が存在するが見つかりません
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.
日付301 RC_SERVER_NOT_RESPサーバーのうち300 RC_EXPIRED_SITE_INFO SITE_INFOない権限の委任を命名責任302 RC_SERVICE_REFERRAL Serverの紹介303 RC_NA_DELEGATEが行われます。
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許可されていない/信用証明書405 RC_AUTHEN_TIMEOUT認証が認証することができません406 RC_UNABLE_TO_AUTHENをタイムアウトRC_AUTHEN_FAILED 404 RC_INVALID_CREDENTIAL無効の認証に失敗しました401 402 RC_AUTHEN_NEEDED認証403を必要なデータにアクセスできない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 504 RC_SESSION_KEY_INVALID無効なセッション鍵をサポートしていないセッション502 RC_NO_SESSION_KEY 503 RC_SESSION_NO_SUPPORTセッションをまだ利用できませんセッションを確立することができないRC_SESSION_FAILED期限切れ
900 RC_TRYING Request under processing 901 RC_FORWARDED Request forwarded to another server 902 RC_QUEUED Request queued for later processing
902 RC_QUEUED要求は後の処理のためにキューに入れられた別のサーバーに転送処理901 RC_FORWARDEDリクエスト下900 RC_TRYINGリクエスト
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>の詳細な説明は、このドキュメントのセクション3に記載されています。一般に、クライアントからの要求は、その<はResponseCode> 0に設定しておく必要があり、サーバからの応答メッセージは、非ゼロ<にResponseCode>結果を示すために有していなければなりません。例えば、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との要求が（1に）設定ビットは、要求が（代わりに、任意のミラーリングサイトの）プライマリサービスサイトに向けられるべきであることを示します。 ATと応答メッセージが（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 - 認定ビット。 （1）CTビットが設定された要求は、そのデジタル署名とその応答に署名するためにサーバに要求します。 （1）CTビットが設定された応答は、メッセージが署名されていることを示しています。要求は、（1）そのCTのビットがセットされている場合、サーバは、その応答に署名しなければなりません。サーバが応答して、有効な署名を提供するために失敗した場合、クライアントは応答を破棄しなければならないし、失敗したとして、要求を扱います。
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 - 暗号化ビット。 （1）ENCビットが設定された要求は、事前に確立されたセッションキーを使用してその応答を暗号化するためのサーバを必要とします。
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 - 再帰的なビット。 （1）RECビットがセットされた要求は、要求が別のハンドルサーバによって処理しなければならない場合、クライアントに代わってクエリを転送するようにサーバーを要求します。サーバーは、適切なハンドルサーバに要求を転送し、クライアントにどんな結果に渡すことによって、要求を尊重します。サーバはまたRC_SERVER_NOT_RESPに<はResponseCode>設定された応答を送信することによってそのような要求を拒否することができます。
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 - キャッシュ認証。 （1）CAビットが設定された要求は、キャッシュサーバ（もしあれば）任意のサーバの応答を認証するために要求（例えば、サーバの署名を検証する）クライアントの代わりに。 （1）CAビットが設定された応答は、応答がキャッシュサーバによって認証されたことを示しています。
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 - 連続ビット。 （1）CNビットが設定されたメッセージは、同じ要求（または応答）の一部である複数のメッセージが続くことをメッセージ受信者に伝えます。要求（または応答）は、任意の単一のメッセージに収まるには大きすぎると複数のメッセージに分割されなければならないデータがある場合に発生します。
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 - 公共ビットのみ。問合せ操作のみで使用されます。 （1）POビットが設定されたクエリ要求は、クライアントが唯一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 - 要求 - ダイジェストビット。 （1）RDビットが設定された要求は、応答要求のメッセージダイジェストに含まれるようにサーバに要求します。 （1）RDビットが設定された応答メッセージは、メッセージ本文の最初のフィールドは、元の要求のメッセージダイジェストを含むことを示します。メッセージダイジェストは、サーバの応答の整合性をチェックするために使用することができます。これらの詳細は、このドキュメントの後半で説明されています。
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>要求で指定さを尊重しなければなりません。要求されたオプションを満たすことができない場合は、前のセクションで定義されているように、サーバは<にResponseCode>適切にエラーメッセージを返す必要があります。
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>要求には、<のSerialNumber>（サーバにアクセスするために）クライアントが使用HS_SITE値のことをいいます。サーバーは、クライアントが最新のサービス情報を持っているかどうかを確認するためのリクエストに<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バイトの符号なし整数です。サーバが別のサーバーにクライアントの要求を転送する必要がある場合、サービス再帰が発生します。クライアントから直接、すべての要求は、その<RecursionCount>サーバがクライアントの代わりに再帰的な要求を送信する必要がある場合、それは<RecursionCount> 1で、サーバからの応答が同じに維持しなければなりませんインクリメントしなければならない0に設定しておく必要があります<RecursionCount>要求内の1つのように。サービス再帰の無限ループを防ぐために、サーバは、<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>は、メッセージは秒単位で、1月1日、1970 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>から決定することができます。メッセージ本文は空でもよいです。メッセージ本文の正確なフォーマットは、メッセージヘッダに<オペコード>と<にResponseCode>に依存します。下のメッセージ本文の詳細各<オペコード>と<は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.
<するMessageDigest>メッセージ自体を消化します。これは、メッセージヘッダと元の要求のメッセージ本文の時に計算されます。フィールドの長さは、ダイジェストアルゴリズムに応じて固定されています。 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）を運ぶことができます。メッセージ資格は、伝送中に改ざんされることからメッセージヘッダとメッセージ本文内のコンテンツを保護するために使用されます。メッセージ資格情報のフォーマットは、[5] PKCS＃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
.---------------------------------------------------------------.
| 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.
<予約>ゼロに設定する必要がありますオクテット。
<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.
<タイプ> <たSignedInfo>フィールド内のコンテンツの種類を示すUTF8-stringは、（後述します）。 <たSignedInfo>は、メッセージ認証コード（MAC）が含まれている場合、<たSignedInfo>は、メッセージダイジェスト、又はHS_MACが含まれている場合には、HS_DIGESTを含んでいてもよいです。 <たSignedInfo>は、デジタル署名が含まれている場合、<タイプ>フィールドは、署名アルゴリズム識別子を指定します。例えば、HS_SIGNED_PSSに設定<タイプ>フィールドに、<たSignedInfo>フィールドは、RSA-PSSアルゴリズム[16]を使用して生成されたデジタル署名を含むことになります。 <タイプ>フィールドは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.
<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>.
<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が含まれています。署名の構文とセマンティクスは、<種類>フィールドと<署名者>フィールドで参照する公開鍵によって異なります。例えば、<タイプ>フィールドが「HS_SIGNED」であれば、<署名者>フィールドによって参照される公開鍵がDSA [6]の公開鍵であり、署名は、パラメータRのASN.1オクテットストリング表現となり、 S [7]に記載の方法。 <署名者>フィールドは、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）を含んでいてもよい予め確立されたセッション鍵を用いて生成。この場合、<署名者>フィールドは<セッションID>メッセージエンベロープで指定されたゼロ長UTF8ストリングとその<INDEX>にその<HANDLE>を設定する必要があります。 <署名>フィールドは、その<SIGNATURE>フィールドにMACが含まれている必要があります。 MACは、再度セッションキー、<メッセージヘッダー>、<するmessagebody>、およびセッションキーの連結オーバー一方向ハッシュの結果です。
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.
応答メッセージ内のメッセージ・クレデンシャルは、サーバによって署名されたデジタル署名を含んでいてもよいです。サーバーの公開鍵をサーバにリクエストを送信するためにクライアントによって使用されるサービス情報に記載されています。この場合、クライアントは<署名者>フィールド内の任意の参照を無視して、署名を検証するために、サービス情報の公開鍵を使用する必要があります。
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」が1へのTCフラグを設定し（<SequenceNumberは>で）適切な順序カウントを維持しなければなりません。それぞれの「メッセージエンベロープ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.
このセクションでは、クライアントとサーバ間で交換されるメッセージの観点から各プロトコルの動作の詳細について説明します。また、各<オペコード>と<は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のハンドルシステムのウェブサイトからダウンロードすること。
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>によって識別されます。クライアントが使用するルートサービス情報は、クライアントの要求に<のSerialNumber>をチェックして古い場合GHRのサーバが見つけることができます。 <は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を見つけるために、クライアントソフトウェアはHS_SITEためGHR（またはHS_SERV）命名機関ハンドル「0.NA/1000」に割り当てられた値を照会することができます。 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
すべてのトップレベルの命名機関ハンドルが登録され、GHRで管理する必要があります。 GHRのサーバがLHSに委任された命名機関の要求を受信すると、それは<にResponseCode>とともに、RC_NA_DELEGATEに設定してメッセージを返す必要があります
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.
権威を命名最も近い祖先からHS_NA_DELAGATE値。クライアントは、委任命名機関ハンドルのHS_NA_DELAGATE値によって記述さLHSを照会することができます。実際には、祖先の命名権限が委譲の時に自分自身を複製することによって、GHR内の任意のハンドルサーバに自身が利用できるようにする必要があります。これは、クエリ内の命名機関と祖先命名権威が同じハンドルサーバにハッシュしていないとき（サービスサイト内）ハンドルサーバ間で任意のクロスクエリを防ぐことができます。
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文字は、その大文字に変換します。 <HashOption> HS_SITE値で指定に従って変換ハンドル列のMD5ハッシュを計算します。符号付き整数としてハッシュ結果の最後の4つのバイトを取ります。モジュロによる整数の絶対値<NumOfServer> HS_SITE値で与えられます。結果は<ServerRecord> HS_SITE値に記載されているのシーケンス番号です。例えば、変調の結果が2である場合、第三の<ServerRecord> <HS_SITE>選択されなければならないに記載されています。 <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.
任意のクエリ要求のメッセージヘッダーは、その<オペコード> 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.
解決すべきハンドルを指定UTF8ストリング（セクション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.
<タイプリスト> UTF8-文字列のリストに続く4バイトの符号なし整数。最初の整数は、以下のリストにUTF8-文字列の数を示しています。リスト内の各UTF8-文字列データ型を指定します。これは、そのデータ型のリストに記載されているすべてのハンドル値を返すようにサーバーに指示します。 UTF8-文字列で終わる場合「」 （0x2E）文字は、サーバーは、そのデータタイプUTF8-文字列で指定されたタイプの階層の下にあるすべてのハンドル値を返す必要があります。最初の整数は、この場合0である場合、<タイプリスト>ないUTF8ストリングを含まないことがあり、サーバに関係なく、そのデータ・タイプのすべてのハンドル値を返さなければなりません。
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フラグを設定せずにクエリを送信することができます。この場合、サーバはADMIN_READの許可を得てPUBLIC_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>に記載されていたもののハンドル値を返す必要があります。クエリが<IndexList>非空の<タイプリスト>が、空で構成されている場合は同様に、サーバは、データ型が<タイプリスト>に記載されていたもののハンドル値を返す必要があります。
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>と<タイプリスト>フィールドが空でない場合は、サーバーは、そのインデックスに記載されているすべてのハンドル値を返す必要があります。<IndexList>、そのデータタイプ<タイプリスト>に記載されているすべてのハンドル値。
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.
任意のクエリ応答のメッセージヘッダはOC_RESOLUTIONにその<オペコード>を設定する必要があります。成功のクエリ応答はRC_SUCCESSにその<はResponseCode>を設定する必要があります。
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.
<ハンドル>クライアントによって照会ハンドルを指定UTF8-文字列。
<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バイトの符号なし整数。整数は、リスト内のハンドル値の数を指定します。各ハンドル値の符号化は（セクション3.1を参照）[2]で与えられた仕様に従います。クエリを満たすないハンドル値が存在しない場合、整数はゼロに設定されています。
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.
サーバは、サーバが要求を処理するにはあまりにもビジー状態の場合、<はResponseCode> RC_SERVER_BUSYに設定するとエラーメッセージを返すことがあります。 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.
ハンドルServerは、解像度時のハンドルの管理者として自分自身を認証するために、そのクライアントを求めることができます。クエリ内の任意のハンドル値が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.
リクエストを処理するとき、それはエラーが発生した場合のハンドルサーバはエラーメッセージを返します。サーバからエラー応答が、元の要求内の1つとして<オペコード>（メッセージヘッダーにおいて）同じ維持しなければなりません。この文書のセクション2.2.2.2で定義されるように各エラー状態は、<はResponseCode>一意で識別されます。
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-文字列。
<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バイトの符号なし整数です。例では、3つのハンドルのインデックス1、2と値、および3を追加し、すでに存在して1と2のインデックスと値を処理するように要求されているサーバになります。この場合、サーバは、<はResponseCode> RC_VALUE_ALREADY_EXISTに設定してエラーメッセージを返す可能性があり、<IndexList>にインデックス1及び2を加えます。サーバがエラーの原因となった可能性がハンドル値インデックスの完全なリストを返すために義務はないことに注意してください。
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.
サービスの紹介のメッセージヘッダは、元の要求に一つとして<オペコード>同じを維持し、RC_SERVICE_REFERRALにその<はResponseCode>を設定する必要があります。
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の> <ReferralHandle>提供されている場合、空である必要があります任意のフィールドを。空ではないが、それは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ストリングを含んでいてもよいです。
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".
ケアサービスの紹介によって引き起こされる任意のループを避けるために、クライアントが取られなければなりません。また、サービスの紹介から取得したサービス情報を認証するために、クライアントの責任です。 <ReferralHandle>が「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.
クライアント認証は、クライアントとサーバ間で交換される複数のメッセージで構成されています。このようなメッセージは、秘密鍵認証が行われた場合、クライアント、サーバーのチャレンジに応答して、クライアントからのチャレンジレスポンス、および検証要求と応答メッセージを認証するために、サーバからクライアントへの挑戦が含まれます。認証時に交換されるメッセージは、サーバによって割り当てられた<セッション>ユニーク経由して相関しています。各認証セッションでは、サーバーは、サーバーのクライアントからのチャレンジ、チャレンジレスポンスだけでなく、元のクライアント要求を含む状態情報を維持する必要があります。
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.
認証は、クライアントにチャレンジを含むサーバーからの応答メッセージで始まります。クライアントは、チャレンジ・レスポンス・メッセージでのチャレンジに応答しなければなりません。サーバは、チャレンジ・レスポンスの内部にデジタル署名を検証することにより、または管理者の秘密鍵を保持する別のハンドルサーバ（本明細書検証サーバと呼ぶ）に確認要求を送信することによってのいずれかで、チャレンジ・レスポンスを検証します。チャレンジとチャレンジ・レスポンスの目的は、クライアントがハンドル管理者の秘密鍵（または秘密鍵）を所有するサーバーに証明することです。認証に失敗した場合、エラー応答は、<はResponseCode> RC_AUTHEN_FAILEDに設定して戻って送信されます。
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.
成功したクライアント認証の際に、サーバーは、管理者が要求のために承認されていることを確認する必要があります。管理者が十分な権限を持っている場合、サーバーは要求を処理し、結果を送り返します。管理者が十分な権限を持っていない場合、サーバーはRC_NOT_AUTHORIZEDに<にResponseCode>が設定されたエラーメッセージを返します。
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.
CHALLENGEのメッセージヘッダは、元の要求として<オペコード>同じを維持し、RC_AUTH_NEEDEDに<はResponseCode>を設定する必要があります。サーバが認証を追跡するために、メッセージエンベロープで<セッション>非ゼロユニークに割り当てる必要があります。またかかわらず、元の要求は、RDが設定ビットまたはしなかったかどうか、メッセージヘッダに（セクション2.2.2.3を参照）<OpFlag>のRDフラグを設定する必要があります。
The Message Body of the server's CHALLENGE is defined as follows:
次のようにサーバのCHALLENGEのメッセージ本文に定義されます。
<Message Body of Server's Challenge> ::= <RequestDigest>
<Nonce>
where
<RequestDigest>
Message Digest of the request message, as defined in section
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.
<ノンス>安全な乱数発生器を介して、サーバによって生成されたランダムな文字列に続く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.
クライアントがそうするようにサーバに要求しなかった場合、サーバーがチャレンジに署名していないことに注意してください。クライアントはそれが正しいサーバーに話しているかどうかが心配なら、それは<チャレンジ>署名するサーバーを求めることができます。クライアントは、<チャレンジ>署名するサーバーを要求しますが、サーバーの署名を検証するために失敗した場合、クライアントは、サーバの応答を破棄して、サーバーに要求を再発行する必要があります。
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のメッセージヘッダは、サーバからの挑戦に指定されているそれはまた（メッセージエンベロープに）<セッション>同じに保つ必要があります0にその<オペコード> OC_CHALLENGE_RESPONSEとその<はResponseCode>に設定する必要があります。
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-文字列。クライアントが認証用の秘密鍵を使用することを選択した場合たとえば、フィールドは「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-文字列。
<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.
管理者の公開鍵または秘密鍵を保持している（<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
<チャレンジ - レスポンス>メッセージ認証コード（MAC）またはサーバからのチャレンジを介してデジタル署名のいずれかが含まれています。 <AuthenticationType>が「HS_SECKEY」である場合は、<チャレンジ - レスポンス>は、MACに続くオクテットで構成されています。オクテットは、MACを生成するために使用されるアルゴリズムを特定します。最初のオクテットは0×01に設定されている場合、例えば、MACは、によって生成されます
MD5_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
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
ここで、<のSecretKey> <KeyHandle>と<キーインデックス>が参照し、管理者の秘密鍵です。 <ServerChallenge>は、サーバーの挑戦のメッセージ本文部分です。 <チャレンジ - レスポンス>の最初のオクテットは0×02に設定されている場合、MACを使用して生成されます
SHA-1_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
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.
より安全なアプローチは、<チャレンジ - レスポンス>のためのHMAC [17]を使用することです。 HMACは、<のSecretKey>と<ServerChallenge>を使用して生成することができます。 <チャレンジ - レスポンス> 0x11をに設定され、その最初のオクテットとは、HMACは、MD5アルゴリズムを使用して生成されることを示しています。同様に、<チャレンジ - レスポンス> 0x12をに設定され、その最初のオクテットとの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」である場合は、<チャレンジ - レスポンス>は、サーバーの挑戦のメッセージ本文部分の上にデジタル署名が含まれています。まず、一方向ハッシュ値が署名されるブロブにわたって計算される：署名は、2つのステップで生成されます。第二に、ハッシュ値が秘密鍵を使用して署名されています。署名は、サーバーの挑戦を超える署名が続く署名に使用されたダイジェストアルゴリズムを、指定UTF8-文字列で構成されています。 <KeyHandle>と
<KeyIndex> refers to the administrator's public key that can be used to verify the signature.
<キーインデックス>署名を検証するために使用することができ、管理者の公開鍵を指します。
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>と<キーインデックス>と一致するかどうかを確認するために十分な権限を持つもののそれぞれをチェックする必要があります。一致が見つからなかったが、定義された管理者グループがある場合は、サーバがチェックする必要がある場合は、<KeyHandle>と<キーインデックス>は、十分な権限を持っている管理者グループのいずれかに属しています。管理者グループは、メンバーとして別の管理者グループが含まれていてもよいです。サーバーは、これらのグループをナビゲートするときに無限ループを避けるために注意しなければなりません。
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>と<キーインデックス>はHS_ADMIN値のいずれか、または十分な権限を持つ管理者グループによって参照されていない場合は、サーバーはRC_NOT_AUTHORIZEDに<にResponseCode>セットでエラー・メッセージが返されます。そうしないと、サーバは次のようにクライアントを認証していきます。
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>と<キーインデックス>に基づいて、管理者の公開鍵を取得します。公開鍵は、サーバーの<チャレンジ>に対して<チャレンジ - レスポンス>を検証するために使用することができます。 <チャレンジ - レスポンス>が<チャレンジ>一致した場合、サーバーは、元の要求を処理し、結果を返すように続けます。そうしないと、サーバはRC_AUTHENTICATION_FAILEDに<にResponseCode>が設定されたエラーメッセージを返します。
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>で参照されるハンドルを管理ハンドルサーバです。検証要求とその応答は以下のセクションで定義されています。検証サーバは、ハンドルサーバに代わって<チャレンジ>に対して<チャレンジ - レスポンス>を確認します。
The message header of the VERIFICATION_REQUEST must set its <OpCode> to OC_VERIFY_CHALLENGE and the <ResponseCode> to 0.
VERIFICATION_REQUESTのメッセージヘッダは、<オペコード> 0にOC_VERIFY_CHALLENGEと<はResponseCode>に設定しなければなりません。
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-文字列。
<KeyIndex> A 4-byte unsigned integer that is the index of the handle value that holds the secret key of the administrator.
<キーインデックス>管理者の秘密鍵を保持しているハンドル値の指標である4バイトの符号なし整数。
<Challenge> The message body of the server's challenge, as described in section 3.5.1.
<チャレンジ>セクション3.5.1で説明したように、サーバーの挑戦のメッセージ本文、。
<ChallengeResponse> The <ChallengeResponse> from the client in response to the server's <Challenge>, as defined in section 3.5.2.
<チャレンジ - レスポンス> <チャレンジ - レスポンス>サーバーの<チャレンジ>に応じて、クライアントから、セクション3.5.2で定義されています。
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.
検証・レスポンスは、検証リクエストで、<チャレンジ - レスポンスが> <チャレンジ>一致するかどうかを要求してハンドルサーバに指示します。
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.
検証レスポンスのメッセージのヘッダーは、<チャレンジ - レスポンス>が<チャレンジ>一致するかどうかRC_SUCCESSするために、その<はResponseCode>を設定する必要があります。 <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.
<VerificationResult> An octet that is set to 1 if the <ChallengeResponse> matches the <Challenge>. Otherwise it must be set to 0.
<チャレンジ - レスポンス>が<チャレンジ>一致した場合に1に設定されている<VerificationResult>オクテット。それ以外の場合は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.
検証サーバは、検証を行うことができない場合は、<はResponseCode>（例えば、<KeyHandle>が存在しない、または<KeyHandle>と<キーインデックス>は、無効なハンドル値を参照）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要求のメッセージヘッダは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.
ハンドルを指定UTF8-文字列を<ハンドル>。
<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の> <ハンドル>に追加されるべきではありません。また、サーバは、エラーを説明し、クライアントへの応答を送信する必要があります。 <ValueListの>の値が既存のハンドルのいずれかの値と同じインデックスを有する場合、例えば、サーバはRC_VALUE_ALREADY_EXISTSに<はResponseCode>セットを持つエラーメッセージを返します。
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要求はエラーになります。この場合、サーバはRC_HANDLE_NOT_EXISTに<にResponseCode>が設定されたエラーメッセージを返します。
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要求のメッセージヘッダは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.
値（S）を除去する必要があるハンドルを指定UTF8ストリングを<ハンドル>。
<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要求を受信したサーバーは、最初のREMOVEのVALUE権限を持つ管理者としてクライアントを認証する必要があります。認証に成功すると、サーバーは、<ハンドル>から<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> <ハンドル>から除去されるべきで参照される値のいずれも失敗したため。また、サーバは、エラーを説明し、クライアントへの応答を送信する必要があります。例えば、RC_ACCESS_DENIEDエラーになりますPUB_WRITEもADMIN_WRITE権限もないとのいずれかのハンドル値を削除しようとします。非既存のハンドル値を削除するよう求める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要求のメッセージヘッダは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.
値（S）を変更する必要があるハンドルを指定UTF8ストリングを<ハンドル>。
<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権限を持つ管理者としてクライアントを認証する必要があります。認証に成功すると、サーバーは、<のValueList>に記載されたハンドル値を置き換えるために進み、各ハンドル値がPUB_WRITEまたはADMIN_WRITE権限を持っていました。成功した場合、サーバは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要求は、エラーとして扱われます。この場合、サーバはRC_VALUE_NOT_FOUNDに<にResponseCode>が設定されたエラーメッセージを返します。
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値を交換するとエラーになります。この場合、サーバはRC_VALUE_INVALIDに<にResponseCode>が設定されたエラーメッセージを返します。
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要求のメッセージヘッダは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.
ハンドルを指定UTF8-文字列を<ハンドル>。
<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値を含むべきです。
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の>の各値を追加して進みます。成功した場合、サーバはクライアントに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要求のメッセージヘッダは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.
ハンドルを指定UTF8-文字列を<ハンドル>。
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権限を持つ管理者としてクライアントを認証する必要があります。認証に成功すると、サーバーは、ハンドルに割り当てられた任意のハンドル値と一緒にハンドルを削除するために進めてまいります。成功した場合、サーバはクライアントに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権限を持つ管理者のみ命名権限を削除することが許可されています。当局命名Rootレベルは、ルートハンドル「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」の管理者が命名機関ハンドル「0.NA/10.1000」を作成するGHRにCREATE_HANDLEリクエストを送信することにより、「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要求のメッセージヘッダは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-文字列。
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.
<HandleList> A list of UTF8-Strings, each of which identify a handle under the naming authority.
<HANDLELIST>命名権限の下でハンドルを識別し、それぞれがUTF8-文字列のリスト。
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権限を持つ命名機関の管理者として、クライアントを認証する必要があります。
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要求のメッセージヘッダは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-文字列。
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.
<HandleList> A list of UTF8-Strings, each of which identifies a sub-naming authority user-specified naming authority.
<HANDLELIST>サブ命名権限ユーザ指定の命名権限を識別する各々がUTF8-文字列のリスト。
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権限を持つ命名機関の管理者として、クライアントを認証する必要があります。
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.
セッションは、複数のプロトコルの動作のうちの認証情報またはネットワークリソースの共有を可能にするために使用されます。例えば、命名機関の管理者は、セッションセットアップを一度自分自身を認証して、その後、セッションで複数のハンドルを登録します。
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要求のメッセージヘッダは、その<オペコード>が0にOC_SESSION_SETUPと<にResponseCode>に設定されている必要があります。
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_IDENTITY> ::= <Key>
<Handle>
<ValueIndex>
where
<Key>
A UTF-8 string constant "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.
<ハンドル> <ValueIndex>ハンドルとクライアントの認証に使用するハンドル値を指定する4バイトの符号なし整数に続いてUTF-8文字列。これは、クライアントの公開鍵を含むハンドル値を参照する必要があります。公開鍵は、クライアントを認証するためにサーバーによって使用されます。
<HS_SESSION_KEY_EXCHANGE> ::= <Key>
<KeyExchangeData>
where
<Key>
A UTF-8 string constant "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>これらのタプルの一つ：<ClientCipher <ClientCipher KeyExchange>、<HdlCipher KeyExchange>、または<ServerCipher KeyExchange>。次のようにこれらのタプルのそれぞれに定義されます。
<ClientCipher KeyExchange> ::= <Key>
<PubKey>
where
<Key>
A UTF-8 string constant "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".
<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.
4バイトの符号なし整数に続く<ExchangeKeyHdl> <ExchangeKeyIndex> UTF-8文字列。 <ExchangeKeyHdl>と<ExchangeKeyIndex>セッション鍵の交換のために使用されるハンドル値を指します。ハンドル値は、クライアントの公開鍵を含まなければなりません。公開鍵はクライアントに送信する前に、セッション鍵を暗号化するために、サーバによって使用されます。
<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"。これは、クライアントがセッション鍵を生成するための責任を負うことになりますサーバーに指示します。サーバは、応答メッセージ内の公開鍵を提供し、RC_SESSION_EXCHANGEKEYに<はResponseCode>を設定する必要があります。クライアントは、セッションキーを暗号化し、それに続くSESSION_EXCHANGEKEY要求を介してサーバに送信し、サーバの公開鍵を使用することができます。
<DiffieHellman KeyExchange> ::= <Key>
<DHParams>
where
<Key>
A UTF-8 string constant "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アルゴリズムに入力として使用される値。これは、可変長の三の大の整数で構成されています。各大きな整数はオクテットストリングに続く4バイトの符号なし整数の点で符号化されます。オクテット文字列は大整数自体が含まれています。 4バイトの符号なし整数は、オクテット文字列のオクテット数を指定します。
<HS_SESSION_TIMEOUT> ::= <Key>
<TimeOut>
where
<Key>
A UTF-8 string constant "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>フィールドに複数回表示されている場合、それはエラーとして扱われるべきであることに注意してください。この場合、サーバはRC_PROTOCOL_ERRORに<にResponseCode>が設定されたエラーメッセージを返す必要があります。
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は、任意の確立されたセッションのセッション属性を変更するために使用することができます。 <セッション>が非ゼロであると確立されたセッションのいずれかに一致する場合に発生します。ケアは、セッション属性を変更することから不正な要求を防ぐために、サーバによって行われなければなりません。例えば、暗号化されたセッションは、そのメッセージ資格に適切な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応答のメッセージヘッダはOC_SESSION_SETUPにその<オペコード>を設定する必要があります。 <はResponseCode> SESSION_SETUPの応答は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.
<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.
<EncryptedSessionKey>セッションキーがSESSION_SETUP要求で提供された公開鍵を使って暗号化されています。セッションキーは、サーバーからランダムに生成されたオクテット文字列です。サーバーは、クライアントから公開鍵を提供SESSION_SETUP要求に<EncryptedSessionKey>の場合<KeyExchangeData>を返します。
<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応答のメッセージヘッダはRC_SESSION_EXCHANGEKEYにその<はResponseCode>を設定する必要があります。 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.
セクション2.2.3で指定されるようにSESSION_SETUP要求の<RequestDigest>メッセージダイジェスト。
<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.
<はResponseCode>のSESSION_SETUP応答が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要求のメッセージヘッダーは次のようにSESSION_EXCHANGEKEY要求のメッセージ本体が定義されて0に、その<オペコード> OC_SESSION_EXCHANGEKEYその<はResponseCode>に設定する必要があります。
<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.
<EncryptedSessionKey>セッションキーはSESSION_SETUP応答で提供された公開鍵を使って暗号化。セッションキーは、クライアントによってランダムに生成されたオクテット文字列です。
<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.
セッション鍵の交換時には、交換鍵やセッションキーを受信するサーバは、鍵がローカルポリシーで定義されたセキュリティ要件を満たしていることを保証する責任を負っています。サーバは、キービーイングのvolunableを考慮した場合、それは<にResponseCode> RC_SESSION_KEY_INVALIDに設定してクライアントにエラーメッセージを返す必要があります。
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要求のメッセージヘッダーは、その<オペコード>はOC_SESSION_TERMINATEに設定し、その<はResponseCode> 0に任意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.
セッションが終了した後、サーバーはクライアントにSESSION_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応答のメッセージヘッダは、<オペコード> OC_SESSION_TERMINATEに設定しなければなりません。成功SESSION_TERMINATE応答は、そのRC_SUCCESSに<にResponseCode>セット、および空のメッセージボディを持っている必要があります。
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.
優れたサーバの実装は簡単な設定や微調整を可能にしなければなりません。設定可能な項目の提案リストは、サーバのネットワーク・インタフェース（S）（例えば、IPアドレス、ポート番号など）が含まれ、許可されている同時プロセス/スレッド、任意のTCP接続および/または認証プロセスのタイムアウト間隔の数、再帰的なサービス、ASCII文字の大文字と小文字の区別、およびトランザクションログの異なるレベルをサポートするかどうかのUDP接続、ポリシー、などの下で再試行してくださいポリシー
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]「System名前空間とサービス定義ハンドル」で定義されているすべてのハンドルサーバの実装は、すべてのハンドルのデータ・タイプをサポートしている必要があります。彼らはまた、任意のアプリケーション定義のデータ型のハンドル値を格納することができるはずです。
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]。その議論は、この文書にも同様に適用されます。ハンドルシステムのデータモデルとサービスモデルに関するセキュリティ上の考慮事項は、「System名前空間とサービス定義を処理する」で説明されている[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.
この作品は、ハンドルシステムの実装の以前のバージョンから導出されます。ハンドルシステムを含む総合的なデジタル・オブジェクト・アーキテクチャは、ロバート・カーン、ロバート・Wilenskyの論文に記載された[22] 1995年に開発が国防高等によって資金を供給、コンピュータサイエンステクニカルレポート（CSTR）プロジェクトの一環として、CNRIで継続認可番号MDA-972- 92-J-1029およびMDA-972-99-1-0018下に計画庁（DARPA）。デザインのアイデアは、デビッド・イーリー、チャールズ・オース、アリソンゆう、ショーン・ライリー、ジェーン・オイラー、キャサリン・レイ、ステファニー・グエン、ジェイソンPetrone、とヘレン彼女を含めハンドルシステム開発チーム内で検討したものに基づいています。この作品への貢献は深く感謝しています。
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.
著者はまた、彼らの豊富なレビューとコメントをラスHousley（housley@vigilsec.com）、テッドハーディー（hardie@qualcomm.com）、およびマーク・Baugher（mbaugher@cisco.comを）感謝、などの他のメンバーから受信した勧告IETF / IRTFのコミュニティ。
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650, November 2003.
[1]日、S.と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]日、S.、ライリー、S.とL. Lannomを、 "System名前空間とサービス定義のハンドル"、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.ストリンガー、P. Karlton、P.コッヘル "SSLプロトコルバージョン3.0"
[5] RSA Laboratories, "Public-Key Cryptography Standard PKCS#7" http://www.rsasecurity.com/rsalabs/pkcs/
[5] RSA Laboratories社、 "公開鍵暗号標準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]ブレーデン、R.、 "FTPデータ圧縮"、RFC 468、1973年3月。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[9]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[10] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[10] NIST、FIPS PUB 180-1の：1995セキュアハッシュ標準、4月。
[11] D. Cohen, "On Holy Wars and a Plea for Peace", Internet Experiment, Note IEN 137, 1 April 1980.
、インターネット実験、「聖なる戦争と平和のための嘆願について」[11] D.コーエンは、IEN 137、1980年4月1日に注意してください。
[12] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[12]バラクリシュナン、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.カーン、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]ポーク、W.、Housley氏、R.とL. Bassham、RFC 3279、2002年4月 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"。
[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.、ポーク、W.、フォード、W.およびD.ソロ、 "インターネット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.ベラー及びP. Rogaway。デジタル署名の正確なセキュリティ - どのようにRSAとラビンでサインインしてください。暗号学-EUROCRYPT '96、pp.399-416、シュプリンガー・フェアラーク、1996年の進歩で。
[17] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[17] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "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.カーン、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
国立研究イニシアチブのためのサムX.日株式会社（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-262-5316 EMail: ssun@cnri.reston.va.us
電話：703-262-5316 Eメール：ssun@cnri.reston.va.us
Sean Reilly Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国立研究イニシアチブのためのショーン・ライリー・コーポレーション（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-620-8990 EMail: sreilly@cnri.reston.va.us
電話：703-620-8990 Eメール：sreilly@cnri.reston.va.us
Larry Lannom Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国立研究イニシアチブのためのラリーLannomコーポレーション（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-262-5307 EMail: llannom@cnri.reston.va.us
電話：703-262-5307 Eメール：llannom@cnri.reston.va.us
Jason Petrone Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国立研究イニシアチブのためのジェイソンPetroneコーポレーション（CNRI）1895プレストン・ホワイト博士は、スイート100レストン、バージニア州20191
Phone: 703-262-5340 EMail: jpetrone@cnri.reston.va.us
電話：703-262-5340 Eメール：jpetrone@cnri.reston.va.us
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。