[要約] RFC 5408は、Identity-Based Encryption (IBE) のアーキテクチャとそれをサポートするデータ構造に関する文書です。IBEは、公開鍵暗号方式の一種で、ユーザーの身元情報（例えば、メールアドレス）を直接公開鍵として使用することができる技術です。このRFCの目的は、IBEシステムの実装と運用に必要な基本的な概念、プロトコル、データ構造を定義することにあります。IBEは、証明書の管理が難しい環境や、迅速なキー配布が求められるシナリオで特に有用です。関連するRFCにはRFC 5091があり、これはIBEの暗号アルゴリズムに関する詳細を提供しています。
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
IDベースの暗号化アーキテクチャとサポートデータ構造
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
o パブリックパラメーターサーバー（PPS）。IBEパブリックパラメーターには、IBEパラメーターとして知られる公的に共有可能な暗号化資料、および関連するPKGのポリシー情報が含まれます。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サーバーがサポートする必要があるID形式について説明します。
In order to send an encrypted message, an IBE user must perform the following steps:
暗号化されたメッセージを送信するには、IBEユーザーは次の手順を実行する必要があります。
1. Obtain the recipient's public parameters
1. 受信者の公開パラメーターを取得します
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操作を実行するには、受信者のシステムの公開パラメーターが必要です。ユーザーがこれらの公開パラメーターを取得すると、暗号化操作を実行できます。これらのパブリックパラメーターは、ユーザーの組織が運営するPPS、送信者の組織によって運営されているPPS、または完全に異なる組織によって利用可能である場合があります。
2. Construct and send an IBE-encrypted message
2. IBE暗号化されたメッセージを作成して送信します
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暗号化されたメッセージを作成するために必要なのは受信者のIDであり、その形式はパブリックパラメーターによって定義されます。このアイデンティティがメッセージに宛てられるIDと同じである場合、ユーザーからは、暗号化されていないメッセージを送信するために必要な場合よりも暗号化されたメッセージを送信するためにユーザーから情報を必要としません。これは、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パブリックパラメーターには、受信者のIDを除いて、送信者がIBE暗号化されたメッセージを作成するために必要なすべての情報が含まれています。このドキュメントのセクション4では、PPSのURI [URI]またはIRI [IRI]、IBE Publicパラメーターの形式、およびPPSからそれらを取得する方法について説明します。ユーザーがIBEパリメーターを取得するURIまたはIRIは、何らかの方法で認証されなければなりません。PPSサーバーは、この要件を満たすためにTLS 1.2 [TLS]をサポートし、後継者をサポートする必要があります。この手順を図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-RECRYPTメッセージを暗号化するために、送信者はコンテンツ圧力キー（CEK）を選択し、それを使用してメッセージを暗号化し、[CMS]に記載されているように受信者のIBE公開鍵でCEKを暗号化します。この操作を図2に示します。ドキュメント[IBCS]は、2つのフォームのIBEを実装するために必要なアルゴリズムを説明し、[IBECMS]は暗号化メッセージの構文（CMS）を使用して、IBE情報とともに暗号化されたメッセージをカプセル化する方法を説明します。受信者が電子メールメッセージを解読する必要があること。
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を見つけるためにそれを解析し、メッセージを暗号化するために使用されたアイデンティティ。次に、受信者は次の手順を実行します。
1. Obtain the IBE public parameters
1. IBEパブリックパラメーターを取得します
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も提供します。
2. Obtain the IBE private key from the PKG
2. PKGからIBE秘密キーを取得します
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秘密キーを受け取ります。
3. Decrypt the IBE-encrypted Message
3. IBE暗号化されたメッセージを復号化します
The IBE private key decrypts the CEK (see Section 2.3.3). The CEK is then used to decrypt the encrypted message.
IBE秘密キーはCEKを復号化します（セクション2.3.3を参照）。次に、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パラメーターを取得する必要があります。この操作を図3に示します。正しいパブリックパラメーターの使用は、IBEシステムの全体的なセキュリティに不可欠であるため、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].
この地区は、IBE暗号化されたメッセージの受信者が、このアイデンティティのために暗号化されたメッセージを暗号化または復号化するために必要なIBEパブリックパラメーターを取得できるURI [URI]またはIRI [IRI]を表すIA5Stringです。アプリケーションは、これを行うためにセクション4で説明した方法をサポートし、他の方法をサポートする必要があります。IRISは、[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.
IdentyTypeは、IDDATAフィールドがエンコードされている形式を定義するオブジェクト識別子です。
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の使用に合わせて調整されています。アイデンティティを含む情報はアプリケーションに非常に依存しているため、このドキュメントは、すべてのアプリケーションがサポートする必要があるIDTYPEを定義していません。
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システムのコンポーネントがパブリックパラメーターを取得する方法を指定します。送信または受信クライアントは、これらのパラメーターの構成を手動で許可する必要があります。たとえば、構成ファイルの編集を介して。ただし、簡素化された構成の場合、クライアントは、このドキュメントで説明されているPublicパラメーター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 URIPSOIDで示されます。これは、次のとおりです。
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はHTTPS URI [HTTP]である必要があり、この目的のためにIRIS [IRI]をさらにサポートする場合があります。IBEパリメーターを取得するには、[HTTP]で定義されているように、クライアントはHTTP GETメソッドを使用する必要があります。リクエストは、安全なプロトコルに対して行われなければなりません。要求クライアントは、TLS 1.2 [TLS]またはその後継者をサポートし、両当事者がサポートする最新バージョンを使用する必要があります。URI/IRIを要求する場合、クライアントは、TLS 1.2 [TLS]またはその後継者によってサーバーのIDが正常に検証された場合にのみ、システムパラメーターブロックを受け入れる必要があります。
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 Requestの成功は、次のセクションで説明するDer-Encoded [der] Ibesysparams構造のベース64 [B64]をエンコードするBase64 [B64]を返します。この構造は、アプリケーション/IBE-PP-DATA 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]のエンコーディングでなければならないIA5ストリングです。IRISは、[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.
地区フィールドは、地区名で定義されたURIまたはIRIで利用可能なIBEパラメーターのユニークなセットを表す整数です。地区名に新しいパラメーターが公開されている場合、地区の地区は、以前に使用されていた地区よりも大きい数に増やさなければなりません。
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.
前にnotafterの値は、グリニッジ平均時間（zulu）で表現する必要があり、秒数がゼロに等しい場合でも、秒（つまり、時間は常にyyyymmdhhmmssz）を含める必要があり、最も近い秒に表現する必要があります。
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のパラメーターを使用する日付が、IBEパラメーターの時間とnothter時間の間にあることを確認する必要があり、IBE暗号化操作のパラメーターを使用しない場合は、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の時間コンポーネントは、IBE公開パラメーターの時間とほぼ時間の間に落ちなければなりません。
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-FranklinおよびBoneh-Boyenアルゴリズム）とそのpublicParameterData構造のOIDは、[IBCS]で定義されています。
The publicParameterData is a DER-encoded [DER] structure that contains the actual cryptographic parameters. Its specific structure depends on the algorithm.
PublicParameterDataは、実際の暗号化パラメーターを含むder-Encoded [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には、少なくとも1つのアルゴリズムを識別するOIDが含まれている必要があり、複数のアルゴリズムを識別するOIDが含まれている場合があります。同じアルゴリズムを持つ2つ以上のibepublicparameterエントリを含めてはなりません。Ibesysparamsを使用したいクライアントは、publicParameterData構造で指定されたアルゴリズムを選択できます。クライアントは、少なくともBoneh-Franklinアルゴリズム[IBCS]を実装し、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]に記載されています。これは、電子メールの暗号化での使用に適したID形式を定義しています。
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.
Octet string ibeparamextensionValueの内容は、特定のibeparamextensioniodによって定義されます。地区のibeparamextensionsには、ゼロを含む任意の数の拡張機能がある場合があります。実際に使用されている拡張機能の1つの例は、暗号化されたメッセージをWebメールシステムのユーザーが復号化および表示できる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構造を定義します。ibeparame xtensionにおけるこのOIDの存在は、クライアントがこのドキュメントのセクション5で定義されているプロトコルを使用してPKGからIBEプライベートキーを取得する必要があることを示しており、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のオクテット文字列は、IBEプライベートキーを取得できるPKGのURI [URI]またはIRI [IRI]を含むIA5STRINGです。IRISは、[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-DATA MIMEタイプのプロパティをまとめたものです。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: ibe-pp-data
MIMEサブタイプ名：ibe-pp-data
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.
詳細については、個人およびメールアドレス：Luther Martin、martin@voltage.com。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Luther Martin, martin@voltage.com.
著者/変更コントローラー：Luther Martin、martin@voltage.com。
When requesting a private key, a client has to transmit three parameters:
秘密鍵を要求するとき、クライアントは3つのパラメーターを送信する必要があります。
1. The IBE algorithm for which the key is being requested
1. キーが要求されているIBEアルゴリズム
2. The identity for which it is requesting a key
2. キーを要求しているアイデンティティ
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.
クライアントがキーを要求するアイデンティティは、認証資格情報が検証するアイデンティティと必ずしも同じではない場合があります。これは、たとえば、単一のユーザーが複数のエイリアスにアクセスできる場合に発生する可能性があります。たとえば、電子メールユーザーは、2つの異なるメールアドレス（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 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.
秘密鍵を要求するには、クライアントは[http]で定義されているようにHTTP POSTメソッドを実行する必要があります。リクエストは、安全なプロトコルを介して行う必要があります。リクエストクライアントは、クライアントとPKGの両方でサポートされている最新バージョンを使用して、TLS 1.2 [TLS]またはその後継者をサポートする必要があります。URI/IRIを要求する場合、クライアントはサーバー証明書[HTTPTLS]を確認する必要があり、TLS接続のサーバー証明書の確認が失敗した場合、キー要求を中止する必要があります。そうすることは、キーサーバーからクライアントに送信されたときに、認証資格情報と中間攻撃に対する秘密鍵を保護するために重要です。
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-KEY-REQUEST 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>
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.
a <ibe：request>は、クライアントタイプとクライアントバージョンを識別するASCII文字列を含むキーリクエストの一部に<ibe：client>要素を含める必要があります。
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-Encoded [der]オブジェクト識別子のbase64 [b64]エンコードを含む<ibe：oid>要素を含める必要があります。Boneh-Boyen（BB1）およびBoneh-Franklin（BF）アルゴリズムのOIDSは[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].
キー要求には、秘密鍵が要求されているアイデンティティを含む<ibe：id>要素を含める必要があります。このアイデンティティは、base64 [b64] derエンコードされた[der] asn.1構造のエンコードです。この構造は、アプリケーションに適した方法でユーザーの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.
重要な要求には、<ibe：authdata>要素が含まれる場合があります。この要素には、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.
クライアントには、キーリクエストの一部にオプションの追加のXML要素を含めることができます。PKGは、そのようなオプションの要素を含まない重要な要求を処理できる必要があります。
The following summarizes the properties of the application/ibe-key-request+xml MIME type.
以下は、アプリケーション/ibe-key-request xml mimeタイプのプロパティをまとめたものです。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: ibe-key-request+xml
MIMEサブタイプ名：ibe-key-request 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.
詳細については、個人およびメールアドレス：Luther Martin、martin@voltage.com。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Luther Martin, martin@voltage.com.
著者/変更コントローラー：Luther Martin、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 Basic Auth [auth]をサポートする必要があり、HTTP Digest Auth [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.
トランスポートプロトコルによって行われない認証方法の場合、クライアントは、キーリクエストの<ibe：authdata>要素の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-Reply XML MIMEタイプとしてエンコードする必要がある次のXML構造を含める必要があります。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:responseType value="responseCode"/> <ibe:body> bodyTags </ibe:body> </ibe:response> 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:
<ibe：response xmlns：ibe = "urn：ietf：params：xml：ns：ibe"> <ibe：responsetype value = "responsecode"/> <ibe：body> bodytags </ibe：body> </ibe：応答> ResponseCode属性には、キーサーバーからの応答のタイプを説明するASCII文字列が含まれています。現在定義されている応答とそれに関連する意味のリストは次のとおりです。
IBE100 KEY_FOLLOWS IBE101 RESERVED IBE201 FOLLOW_ENROLL_URI IBE300 SYSTEM_ERROR IBE301 INVALID_REQUEST IBE303 CLIENT_OBSOLETE IBE304 AUTHORIZATION DENIED
ibe100 key_follows ibe101予約済みibe201 follow_enroll_uri ibe300 system_error ibe301 invalid_request ibe303 client_obsolete ibe304承認拒否
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の応答コードで応答し、<ibe：body>には有効なプライベートキーを含むa <ibe：privatekey>要素を含める必要があります。この例を以下に示します。
<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>
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構造のクライアントに追加情報を渡すことができます。PKGOPTIONS構造に情報を含むPKGからIbePrivateKeyreplyを受信するクライアントは、プロセスが不可能であると、暗号化操作のIBEPRIVATEKEYREPLY構造のIBE秘密キーを使用してはなりません。クライアントは、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>
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は、認証ユーザーを外部認証メカニズムにサポートする場合があります。この場合、サーバーは応答コードIBE201を使用してクライアントに返信し、応答の本文には、認証メカニズムのURIを指定する<ibe：location>要素を含める必要があります。このような応答の例を以下に示します。
<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> 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.
<ibe：response xmlns：ibe = "urn：ietf：params：xml：ns：ibe"> <ibe：responsetype value = "ibe201"/> <ibe：body> <ibe：location uri = "http：// wwww.example.com/enroll.asp "/> </ibe：body> </ibe：response>クライアントは、セクション5.2で定義された同じメカニズムを使用して、そのような応答で返されるURIに連絡して、認証資格情報を取得できるようになりました。クライアントがこのURIの認証メカニズムから資格情報を取得すると、リクエストに含まれる正しい認証資格情報を使用してPKGに新しいキーリクエストを送信し、認証資格情報を<ibe：authdata>要素に配置しますセクション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応答コードは、内部サーバーエラーが発生したことを示します。エラーの診断に役立つ可能性のある情報は、そのような応答の本体に含まれる場合があります。このような応答の例を以下に示します。IBE300応答コードを受信すると、クライアントはキーリクエストを中止し、応答の本文に含まれているデータを破棄する必要があります。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE300"/>
<ibe:body>
Widget phlebotomy failure
</ibe:body>
</ibe:response>
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応答コードを受信すると、クライアントはキーリクエストを中止し、応答の本文に含まれているデータを破棄する必要があります。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE301"/>
<ibe:body>
Some additional stuff
</ibe:body>
</ibe:response>
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応答コードを受信すると、クライアントはキーリクエストを中止し、応答の本文に含まれているデータを破棄する必要があります。
<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>
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>
The following summarizes the properties of the application/ibe-pkg-reply+xml MIME type.
以下は、アプリケーション/IBE-PKG-Reply XML MIMEタイプのプロパティをまとめたものです。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: ibe-pkg-reply+xml
MIMEサブタイプ名：IBE-PKG-REPLY 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.
詳細については、個人およびメールアドレス：Luther Martin、martin@voltage.com。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Luther Martin, martin@voltage.com.
著者/変更コントローラー：Luther Martin、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)
}
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の実装に使用される暗号化アルゴリズムへの攻撃は、このドキュメントの範囲外です。このような攻撃は[IBCS]で詳しく説明されており、80ビット、112ビット、および128ビットの暗号化強度を与えるパラメーターを定義します。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システムのユーザーは、IBEの使用が必要とする適切な対策[DOS、BGPDOS]を取得する必要があります。
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-data、application/ibe-key-request xml、およびapplication/ibe-pkg-reply xmlです。メディアタイプアプリケーション/IBE-PP-DATAは、このドキュメントのセクション4.3で定義されています。メディアタイプアプリケーション/IBE-KEY-REQUEST XMLは、このドキュメントのセクション5.4で定義されています。メディアタイプアプリケーション/IBE-PKG-Reply XMLは、このドキュメントのセクション5.7で定義されています。
The IANA is requested to register the following namespace identifier:
IANAは、次の名前空間識別子を登録するように要求されます。
urn:ietf:params:xml:ns:ibe
Registrant Contact:
登録者の連絡先：
Luther Martin Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto, CA 94304
Luther Martin Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto、CA 94304
Phone: +1 650 543 1280
Email: 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>
[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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、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] Ferguson、P。and D. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP/1.1」、RFC 2616、1999年6月。
[HTTPTLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[httptls] Rescorla、E。、「TLS上のHTTP」、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. Martin、「アイデンティティベースの暗号化標準（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、「国際化された資源識別子（IRIS）」、RFC 3987、2005年1月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Key] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、「Internet X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、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.
[BGPDOS] Turk、D。、「サービス拒否攻撃をブロックするためにBGPの構成」、RFC 3882、2004年9月。
[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] Martin、L。およびM. Schertler、「Boneh-Franklin Identityベースの暗号化アルゴリズムを暗号化メッセージ構文（CMS）（CMS）（CMS）を使用して」、RFC 5409、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。Wack、K。Kent、「IT製品のセキュリティ構成チェックリストプログラム - チェックリストユーザーと開発者向けガイダンス」、NIST Special Publication 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
Guido Appenzeller Stanford University Gates Building 3A Stanford、CA 94305
Phone: +1 650 732 2273
EMail: appenz@cs.stanford.edu
Luther Martin Voltage Security 1070 Arastradero Rd, Suite 100 Palo Alto, CA 94304 USA
Luther Martin Voltage Security 1070 Arastradero Rd、Suite 100 Palo Alto、CA 94304 USA
Phone: +1 650 543 1280
EMail: martin@voltage.com
Mark Schertler Axway 1600 Seaport Blvd, Suite 400 Redwood City, CA 94063 USA
Mark Schertler Axway 1600 Seaport Blvd、Suite 400 Redwood City、CA 94063 USA
Phone: +1 650 216 2039
EMail: mschertler@us.axway.com