Network Working Group G. Appenzeller
Request for Comments: 5408 Stanford University
Category: Informational L. Martin
Voltage Security
M. Schertler
Axway
January 2009
Identity-Based Encryption Architecture and Supporting Data Structures
アイデンティティベースの暗号化アーキテクチャとサポートするデータ構造
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology.
この文書では、IDベース暗号、公開鍵としてユーザーのIDを使用して、公開鍵暗号化技術を実装するために必要なセキュリティアーキテクチャについて説明します。また、技術を実装するために使用することができるデータ構造を定義します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Identity-Based Encryption .......................................3
2.1. Overview ...................................................3
2.2. Sending a Message That Is IBE-Encrypted ....................5
2.2.1. Sender Obtains Public Parameters ....................5
2.2.2. Construct and Send an IBE-Encrypted Message .........6
2.3. Receiving and Viewing an IBE-Encrypted Message .............6
2.3.1. Recipient Obtains Public Parameters .................7
2.3.2. Recipient Obtains IBE Private Key ...................8
2.3.3. Recipient Decrypts IBE-Encrypted Message ............8
3. Identity Format .................................................9
4. Public Parameter Lookup .........................................9
4.1. Request Method ............................................10
4.2. Parameter and Policy Format ...............................11
4.3. The application/ibe-pp-data MIME Type .....................14
5. Private Key Request Protocol ...................................15
5.1. Overview ..................................................15
5.2. Private Key Request .......................................15
5.3. Request Structure .........................................16
5.4. The application/ibe-key-request+xml MIME type .............17
5.5. Authentication ............................................18
5.6. Server Response Format ....................................18
5.6.1. The IBE100 responseCode ............................19
5.6.2. The IBE101 responseCode ............................20
5.6.3. The IBE201 responseCode ............................20
5.6.4. The IBE300 responseCode ............................21
5.6.5. The IBE301 responseCode ............................21
5.6.6. The IBE303 responseCode ............................21
5.6.7. The IBE304 responseCode ............................22
5.7. The application/ibe-pkg-reply+xml MIME type ...............22
6. ASN.1 Module ...................................................23
7. Security Considerations ........................................25
7.1. Attacks outside the Scope of This Document ................25
7.2. Attacks within the Scope of This Document .................26
7.2.1. Attacks on the Protocols Defined in This Document ..26
8. IANA Considerations ............................................27
8.1. Media Types ...............................................27
8.2. XML Namespace .............................................27
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................29
This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that are required to implement the technology. Objects used in this implementation are defined using ASN.1 [ASN1] and XML [XML].
この文書では、IDベース暗号、公開鍵としてユーザーのIDを使用して、公開鍵暗号化技術を実装するために必要なセキュリティアーキテクチャについて説明します。また、技術を実装するために必要とされるデータ構造を定義します。この実装で使用されるオブジェクトは、ASN.1 [ASN1]及びXML [XML]を使用して定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEY].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[KEY]で説明されるように解釈されます。
Identity-based encryption (IBE) is a public-key encryption technology that allows a public key to be calculated from an identity and a set of public mathematical parameters and that allows for the corresponding private key to be calculated from an identity, a set of public mathematical parameters, and a domain-wide secret value. An IBE public key can be calculated by anyone who has the necessary public parameters; a cryptographic secret is needed to calculate an IBE private key, and the calculation can only be performed by a trusted server that has this secret.
IDベース暗号（IBE）アイデンティティと公共の数学的なパラメータのセットから計算される公開鍵を可能にし、それがアイデンティティから計算することに対応する秘密鍵を可能にし、公開鍵暗号技術、のセットです公共の数学的パラメータ、およびドメイン全体の秘密値。 IBE公開鍵は、必要な公開パラメータを持っている人で計算することができます。暗号の秘密は、IBE秘密鍵、および計算を計算するために必要なだけ、この秘密を持っている信頼できるサーバによって実行することができます。
Calculation of both the public and private keys in an IBE system can occur as needed, resulting in just-in-time creation of both public and private keys. This contrasts with other public-key systems [P1363], in which keys are generated randomly and distributed prior to secure communication commencing, and in which private encryption keys need to be securely archived to allow for their recovery if they are lost or destroyed. The ability to calculate a recipient's public key, in particular, eliminates the need for the sender and receiver to interact with each other, either directly or through a proxy such as a directory server, before sending secure messages.
必要に応じてIBEシステムにおける公開鍵と秘密鍵の両方の計算は、公開鍵と秘密鍵の両方のジャストインタイムの作成、その結果、発生する可能性があります。これは、キーがランダムに生成し、通信開始を確保するために事前配布され、ここで秘密暗号鍵は、彼らが失われたり、破壊された場合、その復旧を可能にするために安全にアーカイブする必要されている他の公開鍵システム[P1363]、とは対照的です。受信者の公開鍵を計算する能力は、特に、安全なメッセージを送信する前に、そのようなディレクトリサーバとして、直接またはプロキシ経由で互いに相互作用するために送信者と受信者が不要になります。
A characteristic of IBE systems that differentiates them from other server-based cryptographic systems is that once a set of public parameters is fetched, encryption is possible with no further communication with a server during the validity period of the public parameters. Other server-based systems may require a connection to a server for each encryption operation.
他のサーバベースの暗号システムからそれらを区別するIBEシステムの特徴は、公開パラメータのセットがフェッチされると、暗号化は、公開パラメータの有効期間中にサーバとのない更なる通信で可能であることです。その他のサーバーベースのシステムでは、各暗号化操作のためのサーバーへの接続が必要な場合があります。
This document describes an IBE-based messaging system, how the components of such a system work together, and defines data structures that support the operation of such a system. The server components required for such a system are the following:
この文書は、そのようなシステムの構成要素がどのように連携するかIBEベースのメッセージングシステムを記述し、そのようなシステムの動作をサポートするデータ構造を定義します。このようなシステムに必要なサーバーコンポーネントは以下のとおりであります：
o A Public Parameter Server (PPS). IBE public parameters include publicly-sharable cryptographic material, known as IBE public parameters, and policy information for an associated PKG. A PPS provides a well-known location for secure distribution of IBE public parameters and policy information that describe the operation of a PKG. Section 5 of this document describes the protocol that a client uses to communicate with a PPS.
公開パラメータサーバー（PPS）、O。 IBE公開パラメータは、関連付けられたPKGのための公的に共有可能な暗号IBE公開パラメータとして知られている材料、およびポリシー情報を含みます。 PPSは、PKGの動作を説明IBE公開パラメータ及びポリシー情報の安全な配布のためのよく知られた場所を提供します。このドキュメントのセクション5は、クライアントがPPSとの通信に使用するプロトコルを記述します。
o A Private-key Generator (PKG). The PKG stores and uses cryptographic material, known as a master secret, which is used for generating a user's IBE private key. A PKG accepts an IBE user's private key request, and after successfully authenticating them in some way, returns their IBE private key. Section 5 of this document describes the protocol that a client uses to communicate with a PKG.
O秘密鍵ジェネレータ（PKG）。 PKG店とユーザーのIBE秘密鍵を生成するために使用されているマスターシークレットとして知られている暗号化材料を、使用しています。 PKGは、IBEのユーザの秘密鍵の要求を受け入れ、そして成功したいくつかの方法でそれらを認証した後、そのIBE秘密鍵を返します。このドキュメントのセクション5は、クライアントがPKGとの通信に使用するプロトコルを記述します。
A logical architecture of such an IBE system would be to have a PKG and PPS per name space, such as a DNS zone. The organization that controls the DNS zone would also control the PKG and PPS and thus the determination of which PKG or PPS to use when creating public and private keys for the organization's members. In this case, the PPS URI/IRI can be uniquely created from a user-friendly name for the form of identity that the PPS supports. This architecture would make it clear which set of public parameters to use and where to retrieve them for a given identity (for example, an RFC 2821 address [SMTP]).
このようIBEシステムの論理アーキテクチャは、DNSゾーンとして、名前空間ごとPKGとPPSを持っていることであろう。 DNSゾーンを制御組織はまた、PKGとPPSので、組織のメンバーのための公開鍵と秘密鍵を作成するときにPKGやPPSが使用するの決意を制御します。この場合、PPS URI / IRIは一意にPPSがサポートするアイデンティティのフォームにユーザーフレンドリー名から作成することができます。このアーキテクチャは、それが明確にされ、使用すると、どこ与えられたアイデンティティ（例えば、RFC 2821アドレス[SMTP]）のためにそれらを取得するために、公開パラメータのセットになるだろう。
IBE-encrypted messages can use standard message formats, such as the Cryptographic Message Syntax [CMS]. How to use IBE with the CMS to encrypt email messages is defined in [IBECMS].
IBEで暗号化されたメッセージは、暗号メッセージ構文[CMS]のような標準的なメッセージフォーマットを使用することができます。電子メールメッセージを暗号化するためにCMSとIBEを使用する方法[IBECMS]で定義されています。
Note that IBE algorithms are used only for encryption, so if digital signatures are required, they will need to be provided by an additional mechanism.
IBEアルゴリズムは、暗号化のみに使用されているので、デジタル署名が必要な場合、彼らは追加のメカニズムによって提供される必要があることに注意してください。
Section 3 of this document describes the identity format that all PPS and PKG servers MUST support.
本書の第3節では、すべてのPPSとPKGのサーバーがサポートしなければならないアイデンティティの形式について説明します。
In order to send an encrypted message, an IBE user must perform the following steps:
暗号化されたメッセージを送信するためには、IBEのユーザーは、次の手順を実行する必要があります。
The public parameters of the recipient's system are needed to perform IBE operations. Once a user obtains these public parameters, he can perform IBE encryption operations. These public parameters may be available at a PPS that is operated by the user's organization, one that is operated by the sender's organization, or by a different organization entirely.
受信者のシステムの公開パラメータは、IBE操作を実行するために必要とされています。ユーザーはこれらの公開パラメータを取得すると、彼はIBE暗号化操作を行うことができます。これらの公開パラメータは完全に送信者の組織によって、または別の組織によって運営されてユーザーの組織、1によって運営されてPPSで利用できます。
In addition to the IBE public parameters, all that is needed to construct an IBE-encrypted message is the recipient's identity, the form of which is defined by the public parameters. When this identity is the same as the identity that a message would be addressed to, then no more information is needed from a user to send them an encrypted message than is needed to send them an unencrypted message. This is one of the major benefits of an IBE-based secure messaging system. Examples of identities are individual, group, or role identifiers.
IBE公開パラメータに加えて、IBE暗号化メッセージを構築するために必要なことすべては、受信者の身元、公開パラメータによって定義された形です。このアイデンティティは、メッセージがに対処するだろうとアイデンティティと同じである場合には、その後、これ以上の情報はそれらに彼らに暗号化されていないメッセージを送信するために必要とされるよりも暗号化されたメッセージを送信するために、ユーザーから必要ありません。これはIBEベースのセキュアなメッセージングシステムの主要な利点の1つです。アイデンティティの例には、個人、グループ、またはロール識別子です。
The sender of a message obtains the IBE public parameters that he needs from a PPS that is hosted at a well-known URI or IRI. The IBE public parameters contain all of the information that the sender needs to create an IBE-encrypted message except for the identity of the recipient. Section 4 of this document describes the URI [URI] or IRI [IRI] of a PPS, the format of IBE public parameters, and how to obtain them from a PPS. The URI or IRI from which users obtain IBE public parameters MUST be authenticated in some way. PPS servers MUST support TLS 1.2 [TLS] to satisfy this requirement and SHOULD support its successors. This step is shown below in Figure 1.
メッセージの送信者は、彼は、よく知られたURIまたはIRIでホストされているPPSから必要なIBE公開パラメータを取得します。 IBE公開パラメータは、送信者が受信者の身元を除き、IBE暗号化メッセージを作成するために必要な情報がすべて含まれています。この文書のセクション4は、URI [URI]またはPPS、IBE公開パラメータの形式のIRI [IRI]を記述し、PPSからそれらを取得する方法。ユーザーは、IBE公開パラメータを取得し、そこからURIまたはIRIは、何らかの方法で認証しなければなりません。 PPSサーバは、この要件を満たすために[TLS] TLS 1.2をサポートしなければならないし、その後継者をサポートする必要があります。このステップは、図1において以下に示されています。
IBE Public Parameter Request
----------------------------->
Sender PPS
<-----------------------------
IBE Public Parameters
Figure 1: Requesting IBE Public Parameters
図1：IBE公開パラメータを要求
The sender of an IBE-encrypted message selects the PPS and corresponding PKG based on his local security policy. Different PPS servers may provide public parameters that specify different IBE algorithms or different key strengths, for example. Or, they may require the use of PKG servers that require different levels of authentication before granting IBE private keys.
IBE暗号化メッセージの送信者は、PPSと彼のローカルセキュリティポリシーに基づいて、対応するPKGを選択します。異なるPPSサーバは、例えば、異なるIBEアルゴリズムまたは異なる強みを指定する公開パラメータを提供することができます。それとも、彼らはIBEに秘密鍵を許可する前に認証の異なるレベルを必要とPKGサーバを使用する必要があります。
To IBE-encrypt a message, the sender chooses a content-encryption key (CEK) and uses it to encrypt his message and then encrypts the CEK with the recipient's IBE public key as described in [CMS]. This operation is shown below in Figure 2. The document [IBCS] describes the algorithms needed to implement two forms of IBE, and [IBECMS] describes how to use the Cryptographic Message Syntax (CMS) to encapsulate the encrypted message along with the IBE information that the recipient needs to decrypt an email message.
IBE暗号化したメッセージに、送信者は、コンテンツ暗号化キー（CEK）を選択し、彼のメッセージを暗号化するためにそれを使用して、[CMS]で説明したように、その後、受信者のIBE公開鍵を使用してCEKを暗号化します。この操作は、ドキュメントが[IBCS】IBE 2つの形態を実装するために必要なアルゴリズムを記述し、そして[IBECMS] IBE情報と共に暗号化されたメッセージをカプセル化するために暗号メッセージ構文（CMS）を使用する方法を説明し、図2で以下に示されています受信者が電子メールメッセージを復号化する必要があること。
CEK ----> Sender ----> IBE-encrypted CEK
^
|
|
Recipient's Identity and IBE Public Parameters
受信者のアイデンティティとIBE公開パラメータ
Figure 2: Using an IBE Public-key Algorithm to Encrypt
図2：暗号化するために、IBE公開鍵アルゴリズムを使用して
In order to read an IBE-encrypted message, a recipient of such a message parses it to find the URI or IRI he needs in order to obtain the IBE public parameters that are required to perform IBE calculations as well as to obtain a component of the identity that was used to encrypt the message. Next, the recipient carries out the following steps:
IBEで暗号化されたメッセージを読み取るために、そのようなメッセージの受信者は、彼がIBE計算を実行するだけでなく、成分を得るために必要とされるIBE公開パラメータを得るために必要であるURIまたはIRIを見つけるためにそれを解析しますメッセージを暗号化するために使用されたID。次に、受信者は、次の手順を実行します：
An IBE system's public parameters allow it to uniquely create public and private keys. The recipient of an IBE-encrypted message can decrypt an IBE-encrypted message if he has both the IBE public parameters and the necessary IBE private key. The public parameters also provide the URI or IRI of the PKG where the recipient of an IBE-encrypted message can obtain the IBE private keys.
IBEシステムの公開パラメータは、それが一意に公開鍵と秘密鍵を作成することができます。彼はIBE公開パラメータ及び必要なIBE秘密鍵の両方を持っている場合IBE暗号化メッセージの受信者は、IBE暗号化メッセージを復号化することができます。公開パラメータはまた、IBE暗号化メッセージの受信者はIBE秘密鍵を取得することができPKGのURIまたはIRIを提供しています。
To decrypt an IBE-encrypted message, in addition to the IBE public parameters, the recipient needs to obtain the private key that corresponds to the public key that the sender used. The IBE private key is obtained after successfully authenticating to a private key generator (PKG), a trusted third party that calculates private keys for users. The recipient then receives the IBE private key over a secure connection.
IBE暗号化メッセージを復号化するには、IBE公開パラメータに加えて、受信者は送信者が使用した公開鍵に対応する秘密鍵を取得する必要があります。 IBE秘密鍵が正常に秘密鍵生成器（PKG）、ユーザーのために秘密鍵を計算し、信頼できる第三者に認証した後に得られます。受信者は、安全な接続を介してIBE秘密鍵を受け取ります。
The IBE private key decrypts the CEK (see Section 2.3.3). The CEK is then used to decrypt the encrypted message.
IBE秘密鍵は、（2.3.3項を参照）CEKを復号化します。 CEKは、暗号化されたメッセージを解読するために使用されます。
It may be useful for a PKG to allow users other than the intended recipient to receive some IBE private keys. Giving a mail-filtering appliance permission to obtain IBE private keys on behalf of users, for example, can allow the appliance to decrypt and scan encrypted messages for viruses or other malicious features.
PKGが意図した受信者以外のユーザーは、いくつかのIBE秘密鍵を受信できるようにすることが有用である可能性があります。ユーザーの代わりにIBE秘密鍵を取得するために、メールフィルタリングアプライアンスの許可を与える、例えば、アプライアンスはウイルスやその他の悪質な機能のための暗号化されたメッセージを解読してスキャンできるようにすることができます。
Before he can perform any IBE calculations related to the message that he has received, the recipient of an IBE-encrypted message needs to obtain the IBE public parameters that were used in the encryption operation. This operation is shown below in Figure 3. Because the use of the correct public parameters is vital to the overall security of an IBE system, IBE public parameters MUST be transported to recipients over a secure protocol. PPS servers MUST support TLS 1.2 [TLS] or its successors, using the latest version supported by both parties, for transport of IBE public parameters. In addition, users MUST verify that the subject name in the server certificate matches the URI/IRI of the PPS. The comments in Section 2.2.1 also apply to this operation.
彼は、彼が受信したメッセージに関連するIBE計算を実行する前に、IBE暗号化メッセージの受信者は、暗号化操作に使用されたIBE公開パラメータを取得する必要があります。この動作は、正しい公開パラメータの使用は、IBEシステムの全体的なセキュリティに不可欠であるので、図3に以下に示され、IBE公開パラメータは、セキュアなプロトコルを介して受信者に輸送されなければなりません。 PPSサーバは、IBE公開パラメータの輸送のために、両当事者によってサポートされる最新バージョンを使用して、TLS 1.2 [TLS]またはその後継者をサポートしなければなりません。また、ユーザは、サーバ証明書のサブジェクト名は、PPSのURI / IRIと一致していることを確かめなければなりません。 2.2.1でのコメントも、この操作に適用されます。
IBE Public Parameter Request
----------------------------->
Recipient PPS
<-----------------------------
IBE Public Parameters
Figure 3: Requesting IBE Public Parameters
図3：IBE公開パラメータを要求
To obtain an IBE private key, the recipient of an IBE-encrypted message provides the IBE public key used to encrypt the message and their authentication credentials to a PKG and requests the private key that corresponds to the IBE public key. Section 5 of this document defines the protocol for communicating with a PKG as well as a minimum interoperable way to authenticate to a PKG that all IBE implementations MUST support. Because the security of IBE private keys is vital to the overall security of an IBE system, IBE private keys MUST be transported to recipients over a secure protocol. PKG servers MUST support TLS 1.2 [TLS] or its successors, using the latest version supported by both parties, for transport of IBE private keys. This operation is shown below in Figure 4.
IBE秘密鍵を取得するには、IBE暗号化メッセージの受信者は、メッセージとPKGへの認証資格情報を暗号化するために使用されるIBE公開鍵を提供し、IBE公開鍵に対応する秘密鍵を要求します。この文書のセクション5は、PKGならびに全てIBE実装がサポートしなければならないPKGに対して認証するための最小の相互運用可能な方法と通信するためのプロトコルを定義します。 IBE秘密鍵のセキュリティはIBEシステム全体のセキュリティに不可欠ですので、IBE秘密鍵は、セキュアなプロトコルを介して受信者に輸送されなければなりません。 PKGサーバは、IBE秘密鍵の輸送のために、両当事者によってサポートされる最新バージョンを使用して、TLS 1.2 [TLS]またはその後継者をサポートしなければなりません。この動作は、図4において以下に示されています。
IBE Private Key Request
---------------------------->
Recipient PKG
<----------------------------
IBE Private Key
Figure 4: Obtaining an IBE Private Key
図4：IBE秘密鍵を取得
After obtaining the necessary IBE private key, the recipient uses that IBE private key and the corresponding IBE public parameters to decrypt the CEK. This operation is shown below in Figure 5. He then uses the CEK to decrypt the encrypted message content. An example of how to do this with email messages is given in [IBECMS].
必要なIBE秘密鍵を取得した後、受信者はIBE秘密鍵と対応するIBE公開パラメータは、CEKを復号化することを使用しています。この動作は、図5に彼はその後、暗号化されたメッセージの内容を解読するためにCEKを使用して下に示されています。電子メールメッセージでこれを行う方法の例は、[IBECMS]で与えられています。
IBE-encrypted CEK ----> Recipient ----> CEK
^
|
|
IBE Private Key and IBE Public Parameters
IBE秘密鍵とIBE公開パラメータ
Figure 5: Using an IBE Public-Key Algorithm to Decrypt
図5：復号化するためのIBE公開鍵アルゴリズムを使用して
An IBEIdentityInfo type MUST be used to represent the identity of a recipient. This is defined to be the following:
IBEIdentityInfoタイプは、受信者のアイデンティティを表現するために使用しなければなりません。これは以下のように定義されています。
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}
An IBEIdentityInfo type is used to calculate public and private IBE keys. Because of this, such a structure is typically DER-encoded [DER].
IBEIdentityInfoタイプは、パブリックとプライベートIBE鍵を計算するために使用されます。このため、このような構造は、典型的には、DERエンコード[DER]です。
The fields of an IBEIdentityInfo structure have the following meanings.
IBEIdentityInfo構造体のフィールドは以下の意味があります。
The district is an IA5String that represents the URI [URI] or IRI [IRI] where the recipient of an IBE-encrypted message can retrieve the IBE public parameters needed to encrypt or decrypt a message encrypted for this identity. Applications MUST support the method described in Section 4 for doing this and MAY support other methods. IRIs MUST be handled according to the procedures specified in Section 7.4 of [PKIX].
地区はURI [URI]またはIBE暗号化メッセージの受信者が、このアイデンティティのために暗号化されたメッセージを暗号化または復号化するために必要なIBE公開パラメータを取得することができIRI [IRI]を表しIA5Stringです。アプリケーションは、これを行うために第4節で説明した方法をサポートしなければならないし、他の方法をサポートするかもしれません。アイリス[PKIX]のセクション7.4で指定された手順に従って処理されなければなりません。
The serial is an INTEGER that defines a unique set of IBE public parameters in the event that more than one set of parameters is used by a single district.
シリアルは、パラメータの複数のセットは単一地区によって使用された場合に、IBE公開パラメータの固有のセットを定義する整数です。
identityType is an OBJECT IDENTIFIER that defines the format that the identityData field is encoded with.
たIdentityTypeはidentityDataフィールドを用いて符号化されたフォーマットを定義するオブジェクト識別子です。
An example of a useful IBEIdentityInfo type is given in [IBECMS]. This example is tailored to the use of IBE in encrypting email. Because the information that comprises an identity is very dependent on the application, this document does not define an identityType that all applications MUST support.
有用IBEIdentityInfoタイプの例は、[IBECMS]で与えられます。この例では、電子メールを暗号化する中IBEの使用に合わせて調整されます。身元を備えた情報は、アプリケーションに非常に依存しているため、この文書では、すべてのアプリケーションがサポートしなければならないたIdentityTypeを定義していません。
This section specifies how a component of an IBE system can retrieve the public parameters. A sending or receiving client MUST allow configuration of these parameters manually, for example, through editing a configuration file. However, for simplified configuration, a client SHOULD also implement the public parameter URI/IRI request method described in this document to fetch the public parameters based on a configured URI/IRI. This is especially useful for federating between IBE systems. By specifying a single URI/IRI, a client can be configured to fetch all the relevant parameters for a remote PKG. These public parameters can then be used to encrypt messages to recipients who authenticate to and retrieve private keys from that PKG.
このセクションでは、IBEシステムの構成要素は、公開パラメータを取得する方法を指定します。送信または受信クライアントは、例えば、コンフィギュレーションファイルを編集を介して、手動でこれらのパラメータの設定を可能にしなければなりません。しかし、簡易な構成のため、クライアントも構成URI / IRIに基づいて公開パラメータを取得するために、この文書で説明公開パラメータURI / IRI要求メソッドを実装する必要があります。これは、IBEシステム間の連合のために特に便利です。シングルURI / IRIを指定すると、クライアントはリモートPKG関連するすべてのパラメータを取得するように構成することができます。これらの公開パラメータはその後に認証を受信者にメッセージを暗号化し、そのPKGから秘密鍵を取得するために使用することができます。
The following section outlines the URI/IRI request method to retrieve a parameter block and describes the structure of the parameter block itself. The technique for fetching IBE public parameters using the process defined in this section is indicated by the OID uriPPSOID, which is defined to be the following:
次のセクションでは、パラメータブロックを取得するためのURI / IRI要求方法を概説し、パラメータブロック自体の構造が記載されています。このセクションで定義されたプロセスを使用して、IBE公開パラメータを取得するための技術は、次のようであると定義されるOID uriPPSOID、で示されます。
uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
}
The configuration URI/IRI SHOULD be an HTTPS URI [HTTP] and MAY additionally support IRIs [IRI] for this purpose. To retrieve the IBE public parameters, the client SHOULD use the HTTP GET method as defined in [HTTP]. The request MUST happen over a secure protocol. The requesting client MUST support TLS 1.2 [TLS] or its successors and SHOULD use the latest version supported by both parties. When requesting the URI/IRI, the client MUST only accept the system parameter block if the server identity was verified successfully by TLS 1.2 [TLS] or its successors.
構成URI / IRIは、[HTTP] HTTPS URIであるべきであり、さらに、この目的のためのIRI [IRI]をサポートするかもしれません。 [HTTP]で定義されているようIBE公開パラメータを取得するには、クライアントは、HTTPのGETメソッドを使用する必要があります。リクエストは、セキュアなプロトコルを介して行われる必要があります。要求しているクライアントはTLS 1.2 [TLS]またはその後継者をサポートしなければならないし、両当事者によってサポートされる最新バージョンを使用する必要があります。 URI / IRIを要求すると、サーバーのアイデンティティがTLS 1.2 [TLS]またはその後継で検証に成功した場合、クライアントはシステム・パラメータブロックを受け入れなければなりません。
A successful GET request returns in its body the base64 [B64] encoding of the DER-encoded [DER] IBESysParams structure that is described in the next section. This structure MUST be encoded as an application/ibe-pp-data MIME type.
その本体に成功GETリクエストリターンBASE64 [B64]次のセクションで説明されているDER符号化された[DER] IBESysParams構造の符号化。この構造は、アプリケーション/ IBE-PP-データのMIMEタイプとして符号化されなければなりません。
The IBE public parameters are a structure of the form
IBE公開パラメータは、フォームの構造です
IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) },
districtName IA5String,
districtSerial INTEGER,
validity ValidityPeriod,
ibePublicParameters IBEPublicParameters,
ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL
}
The fields of an IBESysParams structure have the following meanings.
IBESysParams構造体のフィールドは以下の意味があります。
The version field specifies the version of the IBESysParams format. For the format described in this document, this MUST be set to 2.
バージョンフィールドはIBESysParamsフォーマットのバージョンを指定します。本書で説明されている形式の場合、これは2に設定されなければなりません。
The districtName field is an IA5String that MUST be an encoding of an URI [URI] or IRI [IRI]. IRIs MUST be handled according to the procedures specified in Section 7.4 of [PKIX].
districtNameフィールドは、URI [URI]またはIRI [IRI]の符号化でなければなりませんIA5Stringです。アイリス[PKIX]のセクション7.4で指定された手順に従って処理されなければなりません。
The districtSerial field is an integer that represents a unique set of IBE public parameters that are available at the URI or IRI defined by the districtName. If new parameters are published for a districtName, the districtSerial MUST be increased to a number greater than the previously-used districtSerial.
districtSerialフィールドはdistrictNameによって定義されたURIまたはIRIに入手可能であるIBE公開パラメータの固有のセットを表す整数です。新しいパラメータはdistrictNameのために公開されている場合は、districtSerialは、以前に使用districtSerialよりも大きな数に増加させなければなりません。
The validity field defines the lifetime of a specific instance of the IBESysParams and is defined to be the following:
有効フィールドはIBESysParamsの特定のインスタンスの有効期間を定義し、次のようであると定義されます。
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
The values of notBefore and notAfter MUST be expressed in Greenwich Mean Time (Zulu), MUST include seconds (i.e., times are always YYYYMMDDHHMMSSZ), even where the number of seconds is equal to zero, and MUST be expressed to the nearest second.
notBeforeのとnotAfterの値は、グリニッジ標準時（ズールー）で発現されなければならない秒数がゼロに等しく、最も近い秒に表現されなければならない場合でも、秒（すなわち、時間は常にYYYYMMDDHHMMSSZいる）を含める必要があります。
A client MUST verify that the date on which it uses the IBE public parameters falls between the notBefore time and the notAfter time of the IBE public parameters, and it MUST NOT use the parameters for IBE encryption operations if they do not.
クライアントは、それがIBE公開パラメータを使用した日は、notBeforeの時間とIBE公開パラメータのnotAfterの時間の間に入ると、そうでない場合には、IBE暗号化操作のためのパラメータを使用してはならないことを確かめなければなりません。
IBE public parameters MUST be regenerated and republished whenever the values of ibePublicParameters, ibeIdentityType, or ibeParamExtensions change for a district. A client SHOULD refetch the IBE public parameters at an application-configurable interval to ensure that it has the most current version of the IBE public parameters.
IBE公開パラメータは、再生とibePublicParameters、ibeIdentityType、またはibeParamExtensionsの値は、地区のために変更するたびに再発行されなければなりません。クライアントは、それがIBE公開パラメータの最新バージョンを持っていることを保証するために、アプリケーション側で設定間隔でIBE公開パラメータを再フェッチすべきです。
It is possible to create identities for use in IBE that have a time component, as described in [IBECMS], for example. If such an identity is used, the time component of the identity MUST fall between the notBefore time and the notAfter times of the IBE public parameters.
例えば、[IBECMS]に記載されているように、時間成分を有するIBEに使用するためのIDを作成することが可能です。そのようなアイデンティティが使用されている場合は、アイデンティティの時間コンポーネントは、notBeforeの時間とIBE公開パラメータのnotAfterの時間の間になければなりません。
IBEPublicParameters is a structure containing public parameters that correspond to IBE algorithms that the PKG supports. This structure is defined to be following:
IBEPublicParameters PKGがサポートするアルゴリズムをIBEに対応する公開パラメータを含む構造です。この構造は、次のことが定義されています。
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
The ibeAlgorithm OID specifies an IBE algorithm. The OIDs for two IBE algorithms (the Boneh-Franklin and Boneh-Boyen algorithms) and their publicParameterData structures are defined in [IBCS].
ibeAlgorithm OIDは、IBEアルゴリズムを指定します。 2つのIBEアルゴリズム（Boneh - フランクリンとBoneh-Boyenアルゴリズム）のOIDとそのpublicParameterData構造が[IBCS]で定義されています。
The publicParameterData is a DER-encoded [DER] structure that contains the actual cryptographic parameters. Its specific structure depends on the algorithm.
publicParameterData実際の暗号化パラメータを含んでいるDER符号化された[DER]構造です。その具体的な構造は、アルゴリズムに依存します。
The IBESysParams of a district MUST contain an OID that identifies at least one algorithm and MAY contain OIDs that identify more than one algorithm. It MUST NOT contain two or more IBEPublicParameter entries with the same algorithm. A client that wants to use IBESysParams can chose any of the algorithms specified in the publicParameterData structure. A client MUST implement at least the Boneh-Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen [IBCS] and other algorithms. If a client does not support any of the supported algorithms, it MUST generate an error message and fail.
地区のIBESysParamsは、少なくとも一つのアルゴリズムを識別し、複数のアルゴリズムを識別するOIDを含むかもしれOIDを含まなければなりません。これは、同じアルゴリズムを持つ2つの以上のIBEPublicParameterエントリを含めることはできません。 IBESysParamsを使用したいクライアントはpublicParameterData構造に指定されたアルゴリズムのいずれかを選ぶことができます。クライアントは[IBCS】少なくともBoneh - フランクリン・アルゴリズムを実装しなければならないとBoneh-Boyen [IBCS]と他のアルゴリズムを実装することができます。クライアントがサポートされているアルゴリズムのいずれかをサポートしていない場合は、エラーメッセージを生成し、失敗しなければなりません。
ibeIdentityType is an OID that defines the type of identities that are used with this district. The OIDs and the required and optional fields for each OID are application dependent. An example of this is given in [IBECMS], which defines an identity format suitable for use in encrypting email.
ibeIdentityTypeは、この地方で使用されているアイデンティティのタイプを定義するOIDです。 OIDは、各OIDのための必須およびオプションのフィールドは、アプリケーションに依存しています。この例は、電子メールの暗号化に使用するのに適した同一のフォーマットを定義[IBECMS]、で与えられます。
IBEParamExtensions is a set of extensions that can be used to define additional parameters that particular implementations may require. This structure is defined as follows:
IBEParamExtensionsは、特定の実装が必要な場合があり、追加のパラメータを定義するために使用することができる拡張機能のセットです。次のようにこの構造体が定義されています。
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}
The contents of the octet string ibeParamExtensionValue are defined by the specific ibeParamExtensionOID. The IBEParamExtensions of a district MAY have any number of extensions, including zero. One example of extensions that have been used in practice is to provide a URI where an encrypted message can be decrypted and viewed by users of webmail systems. Another example is to provide commercial branding information, so that a bank can provide a different user interface for customers of different lines of business.
オクテット文字列ibeParamExtensionValueの内容は、特定のibeParamExtensionOIDによって定義されています。地区のIBEParamExtensionsは、ゼロを含む拡張子の任意の数を有していてもよいです。実際に使用されている拡張子の一例は、暗号化されたメッセージを復号化し、ウェブメールシステムのユーザーが見ることができURIを提供することです。別の例としては、銀行が業務の異なるラインの顧客のためのさまざまなユーザーインターフェースを提供できるよう、商用ブランディング情報を提供することです。
If a client receives public parameters that contain an extension that it is unable to process, it MUST NOT use the values in the IBESysParams structure for any cryptographic operations. Clients MUST be able to process an IBESysParams structure that contains no IBEParamExtensions.
クライアントは、処理することができないという拡張子が含まれている公開パラメータを受信した場合、それは任意の暗号化操作のIBESysParams構造体の値を使用してはなりません。クライアントは何IBEParamExtensionsを含まないIBESysParams構造を処理できなければなりません。
The pkgURI OID that is defined below defines an IBEParamExtensions structure that contains the URI or IRI of a Private Key Generator. The presence of this OID in an IBEParamExtension indicates that clients MUST use the protocol defined in Section 5 of this document to obtain IBE private keys from the PKG and MUST do so using the URI/IRI that is defined by the ibeParamExtensionValue in the IBEParamExtension.
以下に定義されるpkgURIのOIDは、秘密鍵生成器のURIまたはIRIが含まれているIBEParamExtensions構造を定義します。 IBEParamExtensionでこのOIDの存在は、クライアントがPKGからIBE秘密鍵を取得するために、このドキュメントのセクション5で定義されたプロトコルを使用しなければならないとIBEParamExtensionでibeParamExtensionValueによって定義されるURI / IRIを使用して、そうしなければならないことを示しています。
If the PKG is publicly-accessible, this extension SHOULD be present to allow the automatic retrieval of private keys for recipients of encrypted messages. For this extension, the ibeParamExtensionValue OCTET STRING is an IA5String containing the URI [URI] or IRI [IRI] of the PKG where IBE private keys can be obtained. IRIs MUST be handled according to the procedures specified in Section 7.4 of [PKIX].
PKGは、公的にアクセス可能な場合には、この拡張機能は、暗号化されたメッセージの受信者の秘密鍵の自動検索を可能にするために存在すべきです。この拡張のために、ibeParamExtensionValue OCTET STRINGがIBE秘密鍵を得ることができるPKGのURI [URI]またはIRI [IRI]を含むIA5Stringです。アイリス[PKIX]のセクション7.4で指定された手順に従って処理されなければなりません。
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
The following summarizes the properties of the application/ibe-pp-data MIME type.
以下は、アプリケーション/ IBE-PP-データMIMEタイプの特性を要約します。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: ibe-pp-data
MIMEサブタイプ名：IBE-PP-データ
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: This media type MUST be encoded as 7-bit (US-ASCII text [ASCII]).
エンコードの考慮事項：このメディアタイプは7ビットとしてエンコードされなければならない（US-ASCIIテキスト[ASCII]）。
Security considerations: The data conveyed as this media type are the public parameters needed for the operation of a cryptographic system. To ensure that the parameters can be trusted, the request for these parameters must take place over a secure protocol, such as TLS 1.2 or its successors. To ensure the validity of the server, the client MUST verify the server certificate and MUST abort the parameter request if the verification of the server certificate of the TLS connection fails. This media type contains no active content and does not use compression.
セキュリティの考慮事項：このメディアタイプとして伝達されるデータは暗号システムの動作に必要な公開パラメータです。パラメータが信頼できることを保証するために、これらのパラメータのための要求は、TLS 1.2またはその後継として、セキュアなプロトコルを介して行われなければなりません。サーバーの有効性を確保するために、クライアントは、サーバー証明書を検証しなければならなくて、TLS接続のサーバ証明書の検証が失敗した場合、パラメータの要求を中止しなければなりません。このメディアタイプは、アクティブなコンテンツが含まれていないと圧縮を使用していません。
Interoperability considerations: There are no known interoperability considerations for this media type.
相互運用性の考慮：このメディアタイプには、既知の相互運用性の考慮事項はありません。
Applications that use this media type: Applications that implement IBE in compliance with this specification will use this media type. The most commonly used of these applications are encrypted email and file encryption.
この仕様に準拠したIBEを実装するアプリケーションは、このメディアタイプを使用します。このメディアタイプを使用するアプリケーション。最も一般的にこれらのアプリケーションの使用は、電子メールやファイルの暗号化を暗号化されています。
Additional information: none
追加情報：なし
Person and email address for further information: Luther Martin, martin@voltage.com.
詳しくは、人とEメールアドレス：ルーサーマーティン、martin@voltage.com。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Luther Martin, martin@voltage.com.
著者/変更コントローラ：ルーサーマーティン、martin@voltage.com。
When requesting a private key, a client has to transmit three parameters:
秘密鍵を要求する場合、クライアントは、3つのパラメータを送信する必要があります。
3. Authentication credentials for the individual requesting the key
キーを要求する個々3.認証資格
The identity for which a client requests a key may not necessarily be the same as the identity that the authentication credentials validate. This may happen, for example, when a single user has access to multiple aliases. For example, an email user may have access to the keys that correspond to two different email addresses, e.g., bob@example.com and bob.smith@example.com.
クライアントがキーを要求するためのIDは、必ずしも認証資格情報を検証するアイデンティティと同じではないかもしれません。 1人のユーザーが複数のエイリアスへのアクセス権を持っているとき、これは、例えば、発生する可能性があります。例えば、電子メールユーザは、二つの異なる電子メールアドレスに対応するキー、例えば、bob@example.comとbob.smith@example.comにアクセスすることができます。
This section defines the protocol to request private keys, a minimum user authentication method for interoperability, and how to pass authentication credentials to the server. It assumes that a client has already determined the URI/IRI of the PKG. This can be done from information included in the IBE message format and the public parameters of the IBE system.
このセクションでは、秘密鍵、相互運用性のための最小限のユーザ認証方式を要求する、そしてどのようにサーバーに認証資格情報を渡すためのプロトコルを定義します。これは、クライアントがすでにPKGのURI / IRIを決定したことを想定しています。これは、IBEメッセージフォーマット及びIBEシステムの公開パラメータに含まれる情報から行うことができます。
The technique for fetching an IBE private key using the process defined in this section is indicated by the OBJECT IDENTIFIER pkgURI, which is defined to be the following:
このセクションで定義されたプロセスを使用して、IBE秘密鍵を取得するための技術は、以下であると定義されるオブジェクト識別子pkgURI、で示されます。
ibcs OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
To request a private key, a client MUST perform a HTTP POST method as defined in [HTTP]. The request MUST take place over a secure protocol. The requesting client MUST support TLS 1.2 [TLS] or its
[HTTP]で定義されている秘密鍵を要求するには、クライアントは、HTTPのPOSTメソッドを実行しなければなりません。リクエストは、セキュアなプロトコルを介して行われなければなりません。要求しているクライアントはTLS 1.2 [TLS]またはそのをサポートしなければなりません
successors, using the latest version supported by both the client and the PKG. When requesting the URI/IRI, the client MUST verify the server certificate [HTTPTLS], and it MUST abort the key request if the server certificate verification of the TLS connection fails. Doing so is critical to protect the authentication credentials and the private key against man-in-the-middle attacks when it is transmitted from the key server to the client.
クライアントとPKGの両方でサポートされている最新バージョンを使用して後継者、。 URI / IRIを要求する場合、クライアントは[HTTPTLS]サーバー証明書を検証しなければならない、とTLS接続のサーバー証明書の検証が失敗した場合には、キー要求を中止しなければなりません。そうすることで認証資格情報と、それがクライアントに鍵サーバから送信されたman-in-the-middle攻撃に対して、秘密鍵を保護することが重要です。
The POST method contains in its body the following XML structure that MUST be encoded as an application/ibe-key-request+xml MIME type:
POSTメソッドは、その本体内のアプリケーション/ IBEキー要求+ xmlのMIMEタイプとして符号化されなければならない次のXML構造を含みます。
<ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:header> <ibe:client version="clientID"/> </ibe:header> <ibe:body> <ibe:keyRequest> <ibe:algorithm> algorithmOID </ibe:algorithm> <ibe:id> ibeIdentityInfo </ibe:id> </ibe:keyRequest> <ibe:authData> ibeAuthData </ibe:authData> </ibe:body> </ibe:request>
<IBE：要求のxmlns：IBE = "URN：IETF：paramsは：XML：NS：IBE"> <IBE：ヘッダ> <IBE：クライアントバージョン= "クライアントID" /> </ IBE：ヘッダ> <IBE：body> < IBE：keyRequest> <IBE：アルゴリズム> algorithmOID </ IBE：アルゴリズム> <IBE：ID> ibeIdentityInfo </ IBE：ID> </ IBE：keyRequest> <IBE：authData> ibeAuthData </ IBE：authData> </ IBE：ボディ> </ IBE：リクエスト>
A <ibe:request> SHOULD include an <ibe:client> element in the <ibe:header> part of a key request that contains an ASCII string that identifies the client type and client version.
<IBE：要求が>で<クライアントIBE>要素<IBE：ヘッダ>クライアントタイプとクライアントのバージョンを識別するASCII文字列を含むキー要求の一部が挙げられるべきです。
A key request MUST contain an <ibe:oid> element that contains the base64 [B64] encoding of a DER-encoded [DER] object identifier that identifies the algorithm for which a key is requested. OIDs for the Boneh-Boyen (BB1) and Boneh-Franklin (BF) algorithms are listed in [IBCS].
キーが要求されているアルゴリズムを識別するDERエンコード[DER]オブジェクト識別子のBASE64 [B64]符号化を含む要素：キー要求は、<OID IBE>を含まなければなりません。 Boneh-BoyenのOID（BB1）とBoneh - フランクリン（BF）アルゴリズムは[IBCS]に記載されています。
A key request MUST contain an <ibe:id> element that contains the identity that the private key is being requested for. This identity is the base64 [B64] encoding of a DER-encoded [DER] ASN.1 structure. This structure defines a user's identity in a way appropriate for the application. An example of such a structure that is appropriate for use in encrypting email is defined in [IBECMS].
秘密鍵がために要求されていることのアイデンティティを含む要素：キー要求は、<ID IBE>を含まなければなりません。このIDは、DERエンコード[DER] ASN.1構造のBASE64 [B64]符号化です。この構造体は、アプリケーションのための適切な方法でユーザーのIDを定義します。電子メールの暗号化に使用するのに適切であるような構造の例は、[IBECMS]で定義されています。
A key request MAY contain an <ibe:authData> element. This element contains authentication information that the PKG can use to determine whether or not a request for a particular IBE private key should be granted.
<：authData IBE>要素のキー要求が含まれているかもしれません。この要素は、PKGは、特定のIBE秘密鍵の要求を許可するかどうかを判断するために使用できることを、認証情報が含まれています。
A client MAY include optional additional XML elements in the <ibe:body> part of the key request. A PKG MUST be able to process key requests that contain no such optional elements.
キー要求の一部：クライアントは、<身体IBE>で、オプションの追加のXML要素を含んでもよいです。 PKGはそのようなオプションの要素が含まれていないキーのリクエストを処理できなければなりません。
The following summarizes the properties of the application/ibe-key-request+xml MIME type.
以下は、アプリケーション/ IBE-キー要求+ xmlのMIMEタイプの特性をまとめたものです。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: ibe-key-request+xml
MIMEサブタイプ名：IBE-キー要求+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: This media type MUST be encoded as US-ASCII [ASCII].
エンコードの考慮事項：このメディアタイプは、US-ASCII [ASCII]として符号化されなければなりません。
Security considerations: The data conveyed in this media type may contain authentication credentials. Because of this, its confidentiality and integrity is extremely important. To ensure this, the request for an IBE private key must take place over a secure protocol, such as TLS 1.2 or its successors. To ensure the validity of the server, the client MUST verify the server certificate and MUST abort the key request if the verification of the server certificate of the TLS connection fails. This media type contains no active content and does not use compression.
セキュリティの考慮事項：このメディアタイプに伝達されるデータは、認証証明書が含まれていてもよいです。このため、その機密性と整合性は非常に重要です。これを確実にするために、IBE秘密鍵の要求は、TLS 1.2またはその後継として、セキュアなプロトコルを介して行われなければなりません。サーバーの有効性を確保するために、クライアントは、サーバー証明書を検証しなければならなくて、TLS接続のサーバ証明書の検証が失敗した場合、キー要求を中止しなければなりません。このメディアタイプは、アクティブなコンテンツが含まれていないと圧縮を使用していません。
Interoperability considerations: There are no known interoperability considerations for this media type.
相互運用性の考慮：このメディアタイプには、既知の相互運用性の考慮事項はありません。
Applications that use this media type: Applications that implement IBE in compliance with this specification will use this media type. The most commonly used of these applications are encrypted email and file encryption.
この仕様に準拠したIBEを実装するアプリケーションは、このメディアタイプを使用します。このメディアタイプを使用するアプリケーション。最も一般的にこれらのアプリケーションの使用は、電子メールやファイルの暗号化を暗号化されています。
Additional information: none
追加情報：なし
Person and email address for further information: Luther Martin, martin@voltage.com.
詳しくは、人とEメールアドレス：ルーサーマーティン、martin@voltage.com。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Luther Martin, martin@voltage.com.
著者/変更コントローラ：ルーサーマーティン、martin@voltage.com。
When a client requests a key from a PKG, the PKG MUST authenticate the client before issuing the key. Authentication may either be done through the key request structure or as part of the secure transport protocol.
クライアントは、PKGからキーを要求すると、PKGは、キーを発行する前に、クライアントを認証する必要があります。認証がいずれかのキー要求の構造を介して、またはセキュアなトランスポートプロトコルの一部として行われてもよいです。
A client or server implementing the request protocol MUST support HTTP Basic Auth [AUTH] and SHOULD also support HTTP Digest Auth [AUTH]. Applications MAY also use other means of authentication that are appropriate for the application. An email application, for example, might rely on deployed email infrastructure for this.
要求プロトコルを実装し、クライアントまたはサーバは、HTTP基本認証[AUTH]をサポートしなければならないともHTTPダイジェスト認証[AUTH]をサポートすべきです。また、アプリケーションは、アプリケーションに適した認証の他の手段を使用することができます。電子メールアプリケーションは、例えば、このために展開された電子メールインフラストラクチャに依存しているかもしれません。
For authentication methods that are not done by the transport protocol, a client MAY include additional authentication information in XML elements in the <ibe:authData> element of a key request. If a client does not know how to authenticate to a server, the client MAY send a key request without authentication information. If the key server requires the client to authenticate externally, it MAY reply with an IBE201 responseCode (as defined below) to redirect the client to the correct authentication mechanism. After receiving an authentication credential from this external mechanism, a client can then use the credential to form a key request that contains the additional authentication data.
キー要求の要素：トランスポートプロトコルによって行われていない認証方法の場合、クライアントは<authData IBE>内のXML要素に追加の認証情報を含むことができます。クライアントがサーバーに認証する方法を知らない場合、クライアントは、認証情報なしでキー要求を送信することができます。鍵サーバが外部認証するようにクライアントを必要とする場合、それが正しい認証機構にクライアントをリダイレクトするために（以下に定義）IBE201にResponseCodeで応答することができます。この外部機構から認証証明書を受け取った後、クライアントは、追加の認証データを含むキー要求を形成するための資格情報を使用することができます。
The key server replies to the HTTP request with an HTTP response. If the response contains a client error or server error status code, the client MUST abort the key request and fail.
鍵サーバは、HTTP応答でHTTPリクエストに応答します。応答がクライアント・エラーまたはサーバーエラーステータスコードが含まれている場合、クライアントはキー要求を中止し、失敗しなければなりません。
If the PKG replies with an HTTP response that has a status code indicating success, the body of the reply MUST contain the following XML structure that MUST be encoded as an application/ibe-pkg-reply+xml MIME type:
PKGは、成功を示すステータスコードを有するHTTP応答で応答した場合、応答の本体は、アプリケーション/ IBE-PKG返信+ xmlのMIMEタイプとして符号化されなければならない次のXML構造を含まなければなりません。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="responseCode"/> <ibe:body> bodyTags </ibe:body> </ibe:response>
<IBE：応答のxmlns：IBE = "URN：IETF：paramsは：XML：NS：IBE"> <IBE：responseType値= "はResponseCode" /> <IBE：BODY> BodyTagの</ IBE：body> </ IBE：応答>
The responseCode attribute contains an ASCII string that describes the type of response from the key server. The list of currently-defined responseCodes and their associated meanings is:
ResponseCode属性は、キーサーバからの応答のタイプを記述するASCII文字列が含まれています。現在定義されてresponseCodesとそれに関連する意味のリストは、次のとおりです。
IBE100 KEY_FOLLOWS IBE101 RESERVED IBE201 FOLLOW_ENROLL_URI IBE300 SYSTEM_ERROR IBE301 INVALID_REQUEST IBE303 CLIENT_OBSOLETE IBE304 AUTHORIZATION DENIED
RESERVED IBE201 FOLLOW_ENROLL_URI IBE300 SYSTEM_ERROR IBE301 INVALID_REQUEST IBE303 CLIENT_OBSOLETE IBE304 AUTHORIZATIONが拒否されましIBE100 KEY_FOLLOWS IBE101
If the key request was successful, the key server responds with a responseCode of IBE100, and the <ibe:body> MUST contain a <ibe:privateKey> element that contains a valid private key. An example of this is shown below.
キー要求が成功した場合、鍵サーバはIBE100のはResponseCodeで応答し、そして有効な秘密鍵が含まれています：<のPrivateKey IBE>要素<IBE体>は含まれていなければなりません。この一例を以下に示します。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="IBE100"/> <ibe:body> <ibe:privateKey> privateKey </ibe:privateKey> </ibe:body> </ibe:response>
<IBE：応答のxmlns：IBE = "URN：IETF：paramsは：XML：NS：IBE"> <IBE：responseType値= "IBE100" /> <IBE：BODY> <IBE：のPrivateKey>のPrivateKey </ IBE：のPrivateKey> </ IBE：ボディ> </ IBE：レスポンス>
The privateKey is the base64 [B64] encoding of the DER encoding [DER] of the following structure:
PrivateKeyは、以下の構造のDERエンコーディング[DER]のBASE64 [B64]のエンコードです。
IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING,
pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption
}
PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER,
optionValue OCTET STRING
}
The pkgIdentity is an IBEIdentityInfo structure that MUST be identical to the IBEIdentityInfo structure that was sent in the key request.
pkgIdentityは、鍵要求で送信されたIBEIdentityInfo構造と同一である必要がありIBEIdentityInfo構造です。
The pkgAlgorithm is an OID that identifies the algorithm of the returned private key. The OIDs for the BB1 and BF algorithms are defined in [IBCS].
pkgAlgorithmが返され、秘密鍵のアルゴリズムを特定するOIDです。 BB1およびBFアルゴリズムのOIDは[IBCS]で定義されています。
The pkgKeyData is a structure that contains the actual private key. Private-key formats for the BB1 and BF algorithms are defined in [IBCS].
pkgKeyDataは、実際の秘密鍵を格納する構造体です。 BB1およびBFアルゴリズムの秘密鍵のフォーマットは、[IBCS]で定義されています。
A server MAY pass back additional information to a client in the pkgOptions structure. A client that receives a IBEPrivateKeyReply from a PKG that contains information in a pkgOptions structure that it is unable process MUST NOT use the IBE private key in the IBEPrivateKeyReply structure for any cryptographic operations. A client MUST be able to process an IBEPrivateKeyReply that contains no PKGOptions structure.
サーバーはpkgOptions構造内のクライアントに追加情報をバック渡すことができます。それができないプロセスは、任意の暗号化操作のためのIBEPrivateKeyReply構造のIBE秘密鍵を使用してはならないですpkgOptions構造の情報が含まれていますPKGからIBEPrivateKeyReplyを受けるクライアント。クライアントにはPKGOptions構造を含まないIBEPrivateKeyReplyを処理できなければなりません。
The responseCode IBE101 is reserved to ensure interoperability with earlier versions of the protocol described in this document. An example of such a response is shown below. A response with the IBE101 responseCode SHOULD contain no body. If information is contained in the body of such a response, the client receiving the response MUST discard any data that is contained in the body.
ResponseCode IBE101は、本書で説明されたプロトコルの以前のバージョンとの相互運用性を確保するために予約されています。そのような応答の例を以下に示します。 IBE101にResponseCodeとの応答には、本体を含んではなりません。情報は、このような応答の本体に含まれている場合、応答を受信したクライアントは、本体に含まれる任意のデータを破棄しなければなりません。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="IBE101"/> <ibe:body> This message must be discarded by the recipient </ibe:body </ibe:response>
<IBE：応答のxmlns：IBE = "URN：IETF：paramsは：XML：NS：IBE"> <IBE：responseType値= "IBE101" /> <IBE：BODY>このメッセージは、受信者によって廃棄されなければならない</ IBE：ボディ</ IBE：レスポンス>
A PKG MAY support authenticating users to external authentication mechanisms. If this is the case, the server replies to the client with responseCode IBE201 and the body of the response MUST contain a <ibe:location> element that specifies the URI of the authentication mechanism. An example of such a response is shown below.
PKGは、外部の認証メカニズムにユーザーの認証をサポートするかもしれません。この場合、サーバはにResponseCode IBE201でクライアントに応答し、応答の本体は含まれていなければならない：認証メカニズムのURIを指定する<IBE場所>要素を。そのような応答の例を以下に示します。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="IBE201"/> <ibe:body> <ibe:location URI="http://www.example.com/enroll.asp"/> </ibe:body> </ibe:response>
<IBE：応答のxmlns：IBEを= "URN：IETF：paramsは：XML：NS：IBE"> <IBE：responseType値= "IBE201" /> <IBE：BODY> <IBE：ロケーションURI = "HTTP：// WWW .example.comと/ enroll.asp "/> </ IBE：ボディ> </ IBE：レスポンス>
The client can now contact the URI returned in such a response using the same mechanisms as defined in Section 5.2 to obtain an authentication credential. Once the client has obtained the credential from the authentication mechanism at this URI, it sends a new key request to the PKG with the correct authentication credentials contained in the request, placing the authentication credential in the <ibe:authData> element of a key request as described in Section 5.5.
今URIを連絡することができ、クライアントは、認証証明書を取得するために、セクション5.2で定義されたのと同じメカニズムを使用して、このような応答で返されます。キー要求の要素：クライアントは、このURIで認証機構から資格を取得していたら、それは<authData IBE>で認証資格を置く、リクエストに含まれる正しい認証資格情報を使用してPKGに新しいキー要求を送信します5.5節で説明したように。
The IBE300 responseCode indicates that an internal server error has occurred. Information that may help diagnose the error MAY be included in the body of such a response. An example of such a response is shown below. Upon receiving a IBE300 responseCode, the client MUST abort the key request and discard any data that was included in the body of the response.
IBE300にResponseCodeは、内部サーバーエラーが発生したことを示します。エラーの診断に役立つ可能性のある情報は、そのような応答の本文に含まれるかもしれません。そのような応答の例を以下に示します。 IBE300はResponseCodeを受信すると、クライアントがキー要求を中止し、応答の本文に含まれていたすべてのデータを捨てなければなりません。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="IBE300"/> <ibe:body> Widget phlebotomy failure </ibe:body> </ibe:response>
<IBE：応答のxmlns：IBE = "URN：IETF：paramsは：XML：NS：IBE"> <IBE：responseType値= "IBE300" /> <IBE：BODY>ウィジェット瀉血障害</ IBE：body> </ IBE ：応答>
The IBE303 responseCode indicates that an invalid key request has been received by the server. Information that may help diagnose the error MAY be included in the body of such a response. An example of such a response is shown below. Upon receiving an IBE301 responseCode, the client MUST abort the key request and discard any data that was included in the body of the response.
IBE303にResponseCodeは無効なキー要求がサーバによって受信されたことを示しています。エラーの診断に役立つ可能性のある情報は、そのような応答の本文に含まれるかもしれません。そのような応答の例を以下に示します。 IBE301はResponseCodeを受信すると、クライアントがキー要求を中止し、応答の本文に含まれていたすべてのデータを捨てなければなりません。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="IBE301"/> <ibe:body> Some additional stuff </ibe:body> </ibe:response>
<IBE：レスポンスのxmlns：IBE = "壷：IETF：のparams：XML：NS：IBE"> <IBE：responseType値= "IBE301" /> <IBE：body>のいくつかの追加のもの</ IBE：ボディ> </ IBE ：応答>
The IBE303 responseCode indicates that the server is unable to correctly process the request because the version of the request is no longer supported by the server. Information that may help diagnose the error MAY be included in the body of such a response.
IBE303にResponseCodeは、要求のバージョンは、もはやサーバーでサポートされているため、サーバーは要求を正しく処理できないことを示します。エラーの診断に役立つ可能性のある情報は、そのような応答の本文に含まれるかもしれません。
An example of such a response is shown below. Upon receiving an IBE303 responseCode, the client MUST abort the key request and discard any data that was included in the body of the response.
そのような応答の例を以下に示します。 IBE303はResponseCodeを受信すると、クライアントがキー要求を中止し、応答の本文に含まれていたすべてのデータを捨てなければなりません。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="IBE303"/> <ibe:body> Version 3.3 or later needed </ibe:body> </ibe:response>
<IBE：応答のxmlns：IBE = "URN：IETF：paramsは：XML：NS：IBE"> <IBE：responseType値= "IBE303" /> <IBE：body>バージョン3.3以降必要</ IBE：body> < / IBE：レスポンス>
The IBE304 responseCode indicates that a valid key request has been received by the server, but the authentication credentials provided were invalid. Information that may help diagnose the error MAY be included in the body of such a response. An example of such a response is shown below. Upon receiving an IBE304 responseCode, the client MUST abort the key request and discard any data that was included in the body of the response.
IBE304にResponseCodeは、有効なキーの要求がサーバによって受信されたことを示しますが、提供された認証資格情報が無効でした。エラーの診断に役立つ可能性のある情報は、そのような応答の本文に含まれるかもしれません。そのような応答の例を以下に示します。 IBE304はResponseCodeを受信すると、クライアントがキー要求を中止し、応答の本文に含まれていたすべてのデータを捨てなければなりません。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="IBE304"/> <ibe:body> Helpful error message </ibe:body> </ibe:response>
<IBE：応答のxmlns：IBE = "URN：IETF：paramsは：XML：NS：IBE"> <IBE：responseType値= "IBE304" /> <IBE：BODY>参考エラーメッセージ</ IBE：body> </ IBE ：応答>
The following summarizes the properties of the application/ibe-pkg-reply+xml MIME type.
以下は、アプリケーション/ IBE-PKG返信+ xmlのMIMEタイプの特性を要約します。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: ibe-pkg-reply+xml
MIMEサブタイプ名：IBE-PKG-返信+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: none
オプションのパラメータ：なし
Encoding considerations: This media type MUST be encoded as US-ASCII [ASCII].
エンコードの考慮事項：このメディアタイプは、US-ASCII [ASCII]として符号化されなければなりません。
Security considerations: The data conveyed as this media type is an IBE private key, so its confidentiality and integrity are extremely important. To ensure this, the response from the server that contains an IBE private key must take place over a secure protocol, such as TLS 1.2 or its successors. To ensure the validity of the server, the client MUST verify the server certificate and MUST abort the key request if the verification of the server certificate of the TLS connection fails. This media type contains no active content and does not use compression.
セキュリティの考慮事項：その機密性と整合性が極めて重要であるので、このメディアタイプとして伝達されるデータは、IBE秘密鍵です。これを確実にするために、IBE秘密鍵が含まれているサーバからの応答は、TLS 1.2またはその後継者などの安全なプロトコル上で行われなければなりません。サーバーの有効性を確保するために、クライアントは、サーバー証明書を検証しなければならなくて、TLS接続のサーバ証明書の検証が失敗した場合、キー要求を中止しなければなりません。このメディアタイプは、アクティブなコンテンツが含まれていないと圧縮を使用していません。
Interoperability considerations: There are no known interoperability considerations for this media type.
相互運用性の考慮：このメディアタイプには、既知の相互運用性の考慮事項はありません。
Applications that use this media type: Applications that implement IBE in compliance with this specification will use this media type. The most commonly used of these applications are encrypted email and file encryption.
この仕様に準拠したIBEを実装するアプリケーションは、このメディアタイプを使用します。このメディアタイプを使用するアプリケーション。最も一般的にこれらのアプリケーションの使用は、電子メールやファイルの暗号化を暗号化されています。
Additional information: none
追加情報：なし
Person and email address for further information: Luther Martin, martin@voltage.com.
詳しくは、人とEメールアドレス：ルーサーマーティン、martin@voltage.com。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Luther Martin, martin@voltage.com.
著者/変更コントローラ：ルーサーマーティン、martin@voltage.com。
The following ASN.1 module summarizes the ASN.1 definitions discussed in this document.
以下のASN.1モジュールは、このドキュメントで説明ASN.1定義をまとめたもの。
IBEARCH-module { joint-iso-itu-t(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) ibearch(5) module(5) version(1) }
IBEARCHモジュール{関節イソITU-T（2）国（16）米国（840）組織（1）identicrypt（114334）IBCS（1）ibearch（5）モジュール（5）バージョン（1）}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) },
districtName IA5String,
districtSerial INTEGER,
validity ValidityPeriod,
ibePublicParameters IBEPublicParameters,
ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL
}
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}
ibcs OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING,
pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption
}
PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER,
optionValue OCTET STRING
}
uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
}
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}
END
終わり
Attacks on the cryptographic algorithms that are used to implement IBE are outside the scope of this document. Such attacks are detailed in [IBCS], which defines parameters that give 80-bit, 112-bit, and 128-bit encryption strength. We assume that capable administrators of an IBE system will select parameters that provide a sufficient resistance to cryptanalytic attacks by adversaries.
IBEを実装するために使用される暗号アルゴリズムへの攻撃は、この文書の範囲外です。そのような攻撃は、80ビット、112ビット、128ビットの暗号化強度を与えるパラメータを定義[IBCS]に詳述されています。私たちは、IBEシステムの可能管理者が敵によって暗号解読攻撃に対する十分な耐性を提供するパラメータを選択することを前提としています。
Attacks that give an adversary the ability to access or change the information on a PPS or PKG, especially the cryptographic material (referred to in this document as the master secret), will defeat the security of an IBE system. In particular, if the cryptographic material is compromised, the adversary will have the ability to recreate any user's private key and therefore decrypt all messages protected with the corresponding public key. To address this concern, it is highly RECOMMENDED that best practices for physical and operational security for PPS and PKG servers be followed and that these servers be configured (sometimes known as hardened) in accordance with best current practices [NIST]. An IBE system SHOULD be operated in an environment where illicit access is infeasible for attackers to obtain.
敵にPPSまたはPKGの情報にアクセスしたり、変更する機能、（マスターシークレットとして、この文書で言及）、特に暗号材料を与える攻撃は、IBEシステムのセキュリティを破るだろう。暗号材料が侵害された場合、特に、敵はすべてのユーザの秘密鍵を再作成するため、対応する公開鍵で保護されたすべてのメッセージを復号化する機能を備えています。この問題に対処するために、非常にPPSとPKGサーバー用の物理的および運用上のセキュリティのベストプラクティスに従うことを推奨されており、これらのサーバが構成されていることが現在のベストプラクティス[NIST]に従って（時には硬化として知られています）。 IBEシステムは、攻撃者が取得するために不正アクセスが実行不可能である環境で動作させる必要があります。
Attacks that require administrative access or IBE-user-equivalent access to machines used by either the client or the server components defined in this document are also outside the scope of this document.
この文書で定義されたクライアントまたはサーバコンポーネントのいずれかが使用するマシンへの管理者アクセスまたはIBE-ユーザー同等のアクセスを必要とする攻撃は、この文書の範囲外でもあります。
We also assume that all administrators of a system implementing the protocols that are defined in this document are trustworthy and will not abuse their authority to bypass the security provided by an IBE system. Similarly, we assume that users of an IBE system will behave responsibly, not sharing their authentication credentials with others. Thus, attacks that require such assumptions are outside the scope of this document.
また、この文書で定義されたプロトコルを実装するシステムのすべての管理者が信頼できるとIBEシステムによって提供されるセキュリティをバイパスする権限を乱用しないことを前提としています。同様に、我々は、IBEシステムのユーザーは他の人と自分の認証資格情報を共有しない、責任を振る舞うすることを前提としています。したがって、そのような仮定を必要とする攻撃は、この文書の範囲外です。
Attacks within the scope of this document are those that allow an adversary to:
この文書の範囲内の攻撃は敵にできるようにするものです。
o passively monitor information transmitted between users of an IBE system and the PPS and PKG
O受動IBEシステムのユーザとPPSとPKGとの間で伝送される情報を監視します
o masquerade as a PPS or PKG
O PPSまたはPKGになりすまします
o perform a denial-of-service (DoS) attack on a PPS or PKG
O PPSまたはPKGに対するサービス拒否（DoS）攻撃を実行します
o easily guess an IBE users authentication credential
O簡単IBEユーザー認証資格を推測
All communications between users of an IBE system and the PPS or PKG are protected using TLS 1.2 [TLS]. The IBE system defined in this document provides no additional security protections for the communications between IBE users and the PPS or PKG. Therefore, the described IBE system is completely dependent on the TLS security mechanisms for authentication of the PKG or PPS server and for confidentiality and integrity of the communications. Should there be a compromise of the TLS security mechanisms, the integrity of all communications between an IBE user and the PPS or PKG will be suspect.
IBEシステムのユーザとPPSまたはPKGとの間のすべての通信はTLS 1.2 [TLS]を使用して保護されています。この文書で定義されたIBEシステムは、IBEユーザとPPSまたはPKGとの間の通信のための追加のセキュリティ保護を提供しません。したがって、説明したIBEシステムは、PKGまたはPPSサーバの認証のための通信の機密性と完全性のためのTLSセキュリティメカニズムに完全に依存しています。 TLSのセキュリティメカニズムの妥協があるはず、IBEユーザーとPPSまたはPKG間のすべての通信の整合性が疑わしいとなります。
The protocols defined in this document do not explicitly defend against an attacker masquerading as a legitimate IBE PPS or PKG. The protocols rely on the server authentication mechanism of TLS [TLS]. In addition to the TLS server authentication mechanism, IBE client software can provide protection against this possibility by providing user interface capabilities that allow users to visually determine that a connection to PPS and PKG servers is legitimate. This additional capability can help ensure that users cannot easily be tricked into providing valid authorization credentials to an attacker.
この文書で定義されたプロトコルは、明示的に正当なIBE PPSまたはPKGになりすまし攻撃を防御しません。プロトコルは、TLS [TLS]のサーバー認証メカニズムに依存しています。 TLSサーバ認証メカニズムに加えて、IBEクライアントソフトウェアは、ユーザーが視覚的にPPSとPKGのサーバーへの接続が正当なものであることを判断できるようにするユーザーインターフェイス機能を提供することによって、この可能性に対する保護を提供することができます。この追加機能は、ユーザーが簡単に攻撃者に有効な認証資格情報を提供するようにだまされないことを保証することができます。
The protocols defined in this document are also vulnerable to attacks against an IBE PPS or PKG. Denial-of-service attacks against either component can result in users' being unable to encrypt or decrypt using IBE, and users of an IBE system SHOULD take the appropriate countermeasures [DOS, BGPDOS] that their use of IBE requires.
この文書で定義されたプロトコルはまた、IBE PPSまたはPKGの攻撃に対して脆弱です。いずれかの成分に対するサービス拒否攻撃は、ユーザーの暗号化またはIBEを使用して復号化できなくなる可能性、およびIBEシステムのユーザーが適切な対策を取るべきである[DOSは、BGPDOS] IBEのそれらの使用が必要であること。
The IBE user authentication method selected by an IBE PKG SHOULD be of sufficient strength to prevent attackers from easily guessing the IBE user's authentication credentials through trial and error.
IBE PKGによって選択されたIBEユーザ認証方法は、簡単に試行錯誤IBEユーザーの認証資格情報を推測から攻撃を防ぐのに十分な強度のものでなければなりません。
With this specification, IANA has registered three media types in the standard registration tree. These are application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml. The media type application/ibe-pp-data is defined in Section 4.3 of this document. The media type application/ibe-key-request+xml is defined in Section 5.4 of this document. The media type application/ibe-pkg-reply+xml is defined in Section 5.7 of this document.
この仕様では、IANAは、標準の登録ツリーに3つのメディアタイプを登録しています。これらは、アプリケーション/ IBE-PP-データ、アプリケーション/ IBE-キー要求+ XML、およびアプリケーション/ IBE-PKG-返信+ xmlのです。メディアタイプapplication / IBE-PP-データは、このドキュメントのセクション4.3で定義されています。メディアタイプapplication / IBE-キーの要求+ xmlのは、このドキュメントのセクション5.4で定義されています。メディアタイプアプリケーション/ IBE-PKG-返信+ XMLはこのドキュメントのセクション5.7で定義されています。
The IANA is requested to register the following namespace identifier:
IANAは、次の名前空間識別子を登録するように要求されます。
urn:ietf:params:xml:ns:ibe
URN：IETF：のparams：XML：NS：IBE
Registrant Contact:
登録者連絡先：
Luther Martin Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto, CA 94304
ルーサーマーティン電圧セキュリティ1070 Arastradero Rdのスイート100パロアルト、CA 94304
Phone: +1 650 543 1280 Email: martin@voltage.com
電話：+1 650 543 1280 Eメール：martin@voltage.com
XML:
XML：
<?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Identity-Based Encryption</title> </head> <body> <h1>Namespace for Identity-Based Encryption</h1> <h2>urn:ietf:params:xml:ns:ibe</h2> <p> <a href="http://www.rfc-editor.org/rfc/rfc5408.txt">RFC5408</a>. </p> </body> </html>
！<？xmlのバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C / DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/xhtml-basic10。 DTD "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <メタHTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = ISO-8859-1 1" /> <タイトル> IDベース暗号化</ TITLE> </ HEAD> <BODY> <H1> IDベース暗号化のための名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：IBE < / H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc5408.txt"> RFC5408 </a>に。 </ P> </ body> </ html>この
[ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7-bit Coded Character Set for Information Exchange.
[ASCII] ISO / IEC 646：1991 - 情報技術 - ISO 7ビット符号化文字は、情報交換のために設定してください。
[ASN1] ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One, 1997.
[ASN1] ITU-T勧告X.680：情報技術 - 抽象構文記法1、1997。
[AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[AUTH]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[B64] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[B64]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[DER] ITU-T Recommendation X.690: OSI Networking and System Aspects: Abstract Syntax Notation One (ASN.1), July 2002.
[DER] ITU-T勧告X.690：OSIネットワークとシステム的側面：抽象構文記法1（ASN.1）、2002年7月。
[DOS] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[DOS]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[HTTPTLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTPTLS]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", RFC 5091, December 2007.
[IBCS] Boyen、X.とL.マーチン、 "IDベース暗号化規格（IBCS）＃1：BFの超特異曲線実装とBB1暗号"、RFC 5091、2007年12月。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEY]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIX]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth Edition), September 2006.
[XML] W3C、拡張マークアップ言語（XML）1.0（第4版）、2006年9月。
[BGPDOS] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
、RFC 3882、2004年9月、 "サービス拒否攻撃をブロックするようにBGPを設定する" [BGPDOS]トルコ人、D.、。
[IBECMS] Martin, L. and M. Schertler, "Using the Boneh-Franklin Identity-Based Encryption Algorithm with the Cryptographic Message Syntax (CMS)", RFC 5409, January 2009.
[IBECMS]マーティン、L.およびM. Schertler、RFC 5409 "暗号メッセージ構文（CMS）とBoneh-フランクリンIDベース暗号化アルゴリズムを使用する" を、2009年1月。
[NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration Checklist Program for IT Products - Guidance for Checklist Users and Developers", NIST Special Publication SP 800-70, May 2005.
[NIST] M. Souppaya、J.ワックとK.ケント、「IT製品のためのセキュリティ設定チェックリストプログラム - チェックリストのユーザーと開発者のための指針」、NIST特別出版SP 800-70、2005年5月。
[P1363] IEEE P1363, "Standard Specifications for Public-Key Cryptography", 2001.
[P1363] IEEE P1363、 "公開鍵暗号のための標準仕様"、2001年。
Authors' Addresses
著者のアドレス
Guido Appenzeller Stanford University Gates Building 3A Stanford, CA 94305
グイドアッペンツェルスタンフォード大学ゲイツビル3Aスタンフォード、CA 94305
Phone: +1 650 732 2273 EMail: appenz@cs.stanford.edu
電話：+1 650 732 2273 Eメール：appenz@cs.stanford.edu
Luther Martin Voltage Security 1070 Arastradero Rd, Suite 100 Palo Alto, CA 94304 USA
マーティン・ルーサー・電圧セキュリティ1070 Arastradero Rdを、スイート100パロアルト、CA 94304 USA
Phone: +1 650 543 1280 EMail: martin@voltage.com
電話：+1 650 543 1280 Eメール：martin@voltage.com
Mark Schertler Axway 1600 Seaport Blvd, Suite 400 Redwood City, CA 94063 USA
マークSchertler Axway 1600シーポートブルバード、スイート400レッドウッドシティー、CA 94063 USA
Phone: +1 650 216 2039 EMail: mschertler@us.axway.com
電話：+1 650 216 2039 Eメール：mschertler@us.axway.com