Network Working Group G. Appenzeller
Request for Comments: 5408 Stanford University
Category: Informational L. Martin
Voltage Security
M. Schertler
Axway
January 2009
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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.
本文档描述了实现基于身份的加密所需的安全体系结构，这是一种使用用户身份作为公钥的公钥加密技术。它还定义了可用于实现该技术的数据结构。
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
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].
本文档描述了实现基于身份的加密所需的安全体系结构，这是一种使用用户身份作为公钥的公钥加密技术。它还定义了实现该技术所需的数据结构。此实现中使用的对象是使用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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键]中所述进行解释。
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.
基于身份的加密（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]。[IBECMS]中定义了如何将IBE与CMS结合使用来加密电子邮件。
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用户必须执行以下步骤：
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操作需要接收方系统的公共参数。一旦用户获得这些公共参数，他就可以执行IBE加密操作。这些公共参数可在由用户组织操作的PPS、由发送方组织操作的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加密消息所需的只是收件人的身份，其形式由公共参数定义。如果此标识与邮件要发送到的标识相同，则用户发送加密邮件所需的信息不比发送未加密邮件所需的信息多。这是基于IBE的安全消息传递系统的主要优点之一。身份的示例包括个人、组或角色标识符。
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节描述了PPS的URI[URI]或IRI[IRI]，IBE公共参数的格式，以及如何从PPS获取这些参数。用户从中获取IBE公共参数的URI或IRI必须以某种方式进行身份验证。PPS服务器必须支持TLS 1.2[TLS]以满足此要求，并应支持其后续服务器。该步骤如下图1所示。
IBE Public Parameter Request
----------------------------->
Sender PPS
<-----------------------------
IBE Public Parameters
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）并使用它对其邮件进行加密，然后使用接收方的IBE公钥对CEK进行加密，如[CMS]中所述。此操作如下图2所示。文档[IBCS]描述了实现两种形式的IBE所需的算法，[IBECMS]描述了如何使用加密消息语法（CMS）封装加密消息以及收件人解密电子邮件所需的IBE信息。
CEK ----> Sender ----> IBE-encrypted CEK
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加密的消息，此类消息的接收者将对其进行解析，以找到所需的URI或IRI，从而获取执行IBE计算所需的IBE公共参数，以及获取用于加密消息的标识组件。接下来，接收者执行以下步骤：
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加密邮件。public参数还提供PKG的URI或IRI，IBE加密消息的接收者可以从中获取IBE私钥。
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）进行身份验证后获得的，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服务器必须支持TLS 1.2[TLS]或其后续版本，使用双方支持的最新版本传输IBE公共参数。此外，用户必须验证服务器证书中的使用者名称是否与PPS的URI/IRI匹配。第2.2.1节中的注释也适用于该操作。
IBE Public Parameter Request
----------------------------->
Recipient PPS
<-----------------------------
IBE Public Parameters
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服务器必须支持TLS 1.2[TLS]或其后续版本，使用双方支持的最新版本传输IBE私钥。此操作如下图4所示。
IBE Private Key Request
---------------------------->
Recipient PKG
<----------------------------
IBE Private Key
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-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
}
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].
district是一个IA5String，表示URI[URI]或IRI[IRI]，其中IBE加密邮件的收件人可以检索加密或解密为此标识加密的邮件所需的IBE公共参数。应用程序必须支持第4节中所述的方法，并且可以支持其他方法。必须按照[PKIX]第7.4节规定的程序处理IRIs。
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.
[IBECMS]中给出了一个有用的IBEIdentityInfo类型示例。此示例是为在加密电子邮件中使用IBE而定制的。由于包含标识的信息非常依赖于应用程序，因此本文档不定义所有应用程序都必须支持的标识类型。
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
本节指定IBE系统的组件如何检索公共参数。发送或接收客户端必须允许手动配置这些参数，例如，通过编辑配置文件。然而，为了简化配置，客户机还应该实现本文中描述的公共参数URI/IRI请求方法来获取公共参数
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.
基于配置的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请求方法，并描述了参数块本身的结构。OID URIPSOID表示使用本节中定义的流程获取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)
}
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]，并且可以为此额外支持IRI[IRI]。要检索IBE公共参数，客户端应使用[HTTP]中定义的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请求在其主体中返回DER编码的[DER]IBESysParams结构的base64[B64]编码，该结构将在下一节中描述。此结构必须编码为应用程序/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
}
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字段是一个IA5String，它必须是URI[URI]或IRI[IRI]的编码。必须按照[PKIX]第7.4节规定的程序处理IRIs。
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字段是一个整数，表示一组唯一的IBE公共参数，这些参数在districtName定义的URI或IRI中可用。如果为districtName发布了新参数，districtSerial必须增加到比以前使用的districtSerial大的数字。
The validity field defines the lifetime of a specific instance of the IBESysParams and is defined to be the following:
validity字段定义IBESysParams特定实例的生存期，定义如下：
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
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的值必须以格林威治标准时间（Zulu）表示，必须包括秒（即时间始终为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公共参数的日期是否介于IBE公共参数的notBefore时间和notAfter时间之间，并且如果IBE公共参数未在notBefore时间和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.
每当某个地区的ibePublicParameters、ibeIdentityType或ibeParamExtensions的值更改时，必须重新生成并重新发布IBE公共参数。客户端应以应用程序可配置的间隔重新提取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.
例如，可以创建在IBE中使用的具有时间组件的标识，如[IBECMS]中所述。如果使用这样的标识，标识的时间部分必须介于IBE公共参数的notBefore时间和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
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
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算法。[IBCS]中定义了两种IBE算法（Boneh Franklin和Boneh Boyen算法）的OID及其publicParameterData结构。
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。它不能包含两个或多个具有相同算法的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]中给出了一个例子，它定义了一种适用于加密电子邮件的身份格式。
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
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}
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，在该URI中，加密消息可以被webmail系统的用户解密和查看。另一个例子是提供商业品牌信息，以便银行可以为不同业务线的客户提供不同的用户界面。
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表示客户端必须使用本文档第5节中定义的协议从PKG获取IBE私钥，并且必须使用IBEParamExtension中的IBEParamExtension值定义的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八进制字符串是一个IA5String，其中包含可以获取IBE私钥的PKG的URI[URI]或IRI[IRI]。必须按照[PKIX]第7.4节规定的程序处理IRIs。
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
The following summarizes the properties of the application/ibe-pp-data MIME type.
下面总结了application/ibe pp数据MIME类型的属性。
MIME media type name: application
MIME媒体类型名称：应用程序
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.
更多信息的人员和电子邮件地址：Luther Martin，martin@voltage.com.
Intended usage: COMMON
预期用途：普通
Author/Change controller: Luther Martin, martin@voltage.com.
作者/变更控制人：路德·马丁，martin@voltage.com.
When requesting a private key, a client has to transmit three parameters:
请求私钥时，客户端必须传输三个参数：
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.
客户端请求密钥的标识不一定与身份验证凭据验证的标识相同。例如，当单个用户可以访问多个别名时，可能会发生这种情况。例如，电子邮件用户可以访问对应于两个不同电子邮件地址的密钥，例如。，bob@example.com还有鲍勃。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)
}
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)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
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连接的服务器证书验证失败，则必须中止密钥请求。这样做对于保护身份验证凭据和私钥在从密钥服务器传输到客户端时免受中间人攻击至关重要。
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方法的主体中包含以下XML结构，必须将其编码为应用程序/ibe密钥请求+XML MIME类型：
<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: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.
<ibe:request>应该在键请求的<ibe:header>部分包含一个<ibe:client>元素，该元素包含标识客户端类型和客户端版本的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].
密钥请求必须包含一个<ibe:oid>元素，该元素包含DER编码的[DER]对象标识符的base64[B64]编码，该标识符标识请求密钥的算法。[IBCS]中列出了Boneh-Boyen（BB1）和Boneh-Franklin（BF）算法的OID。
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>元素，该元素包含请求私钥的标识。此标识是DER编码的[DER]ASN.1结构的base64[B64]编码。此结构以适合应用程序的方式定义用户身份。[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.
客户端可以在密钥请求的<ibe:body>部分包含可选的附加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媒体类型名称：应用程序
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.
更多信息的人员和电子邮件地址：Luther Martin，martin@voltage.com.
Intended usage: 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.
对于不是由传输协议完成的身份验证方法，客户端可以在密钥请求的<ibe:authData>元素中的XML元素中包含附加身份验证信息。如果客户端不知道如何向服务器进行身份验证，则客户端可能会发送一个没有身份验证信息的密钥请求。如果密钥服务器要求客户端进行外部身份验证，它可以使用IBE201响应代码（定义如下）进行回复，以将客户端重定向到正确的身份验证机制。从该外部机制接收到身份验证凭据后，客户机可以使用该凭据形成包含附加身份验证数据的密钥请求。
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响应进行回复，则回复正文必须包含以下XML结构，该结构必须编码为application/ibe PKG reply+XML MIME类型：
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="responseCode"/>
<ibe:body>
bodyTags
</ibe:body>
</ibe:response>
<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:
responseCode属性包含描述密钥服务器响应类型的ASCII字符串。当前定义的响应代码列表及其相关含义如下：
IBE100 KEY_FOLLOWS IBE101 RESERVED IBE201 FOLLOW_ENROLL_URI IBE300 SYSTEM_ERROR IBE301 INVALID_REQUEST IBE303 CLIENT_OBSOLETE IBE304 AUTHORIZATION DENIED
IBE100密钥\遵循IBE101保留IBE201遵循\注册\ URI IBE300系统\错误IBE301无效\请求IBE303客户端\过时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>必须包含包含有效私钥的<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>
<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
}
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
}
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结构中的客户端。从PKG接收IBEPrivateKeyReply的客户端，如果PKG包含无法处理的pkgOptions结构中的信息，则该客户端不得将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.
保留响应代码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: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>
<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.
客户端现在可以使用第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>
<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响应代码表示服务器接收到无效的密钥请求。可能有助于诊断错误的信息可能包含在此类响应的主体中。下面显示了此类响应的示例。收到IBE301响应代码后，客户端必须中止密钥请求，并放弃响应正文中包含的任何数据。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE301"/>
<ibe:body>
Some additional stuff
</ibe:body>
</ibe:response>
<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响应代码表示服务器无法正确处理该请求，因为服务器不再支持该请求的版本。可能有助于诊断错误的信息可能包含在此类响应的主体中。
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>
<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响应代码表示服务器已收到有效的密钥请求，但提供的身份验证凭据无效。可能有助于诊断错误的信息可能包含在此类响应的主体中。下面显示了此类响应的示例。收到IBE304响应代码后，客户机必须中止密钥请求并放弃响应正文中包含的任何数据。
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE304"/>
<ibe:body>
Helpful error message
</ibe:body>
</ibe:response>
<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
安全注意事项：此媒体类型传输的数据是IBE私钥，因此其机密性和完整性非常重要。为了确保这一点，来自包含IBE私钥的服务器的响应必须通过安全的
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.
协议，如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.
作者/变更控制人：路德·马丁，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-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
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) },
districtName IA5String,
districtSerial INTEGER,
validity ValidityPeriod,
ibePublicParameters IBEPublicParameters,
ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL
}
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
}
ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING
}
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING
}
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)
}
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)
}
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING,
pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption
}
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
}
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)
}
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
}
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系统完全依赖TLS安全机制来认证PKG或PPS服务器，并确保通信的机密性和完整性。如果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在标准注册树中注册了三种媒体类型。这些是应用程序/ibe pp数据、应用程序/ibe密钥请求+xml和应用程序/ibe pkg应答+xml。本文件第4.3节定义了媒体类型应用程序/ibe pp数据。本文件第5.4节定义了媒体类型应用程序/ibe密钥请求+xml。本文件第5.7节定义了媒体类型应用程序/ibe pkg reply+xml。
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号100室94304
Phone: +1 650 543 1280
Email: martin@voltage.com
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>
<?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.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年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，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年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.和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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[HTTPTLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTPTLS]Rescorla，E.，“HTTP Over TLS”，RFC 28182000年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.
[关键词]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 52802008年5月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年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，“传输层安全（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]Berners Lee，T.，Fielding，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（第四版），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身份的加密算法和加密消息语法（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特别出版物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号斯坦福，加利福尼亚州94305
Phone: +1 650 732 2273
EMail: appenz@cs.stanford.edu
Phone: +1 650 732 2273
EMail: appenz@cs.stanford.edu
Luther Martin Voltage Security 1070 Arastradero Rd, Suite 100 Palo Alto, CA 94304 USA
路德·马丁电压安全美国加利福尼亚州帕洛阿尔托市阿拉斯塔德罗路1070号100室94304
Phone: +1 650 543 1280
EMail: martin@voltage.com
Phone: +1 650 543 1280
EMail: martin@voltage.com
Mark Schertler Axway 1600 Seaport Blvd, Suite 400 Redwood City, CA 94063 USA
美国加利福尼亚州红木市海港大道1600号Mark Schertler Axway 400室，邮编94063
Phone: +1 650 216 2039
EMail: mschertler@us.axway.com
Phone: +1 650 216 2039
EMail: mschertler@us.axway.com