Network Working Group L. Martin
Request for Comments: 5409 Voltage Security
Category: Informational M. Schertler
Axway
January 2009
Network Working Group L. Martin
Request for Comments: 5409 Voltage Security
Category: Informational M. Schertler
Axway
January 2009
Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)
使用基于Boneh Franklin和Boneh Boyen身份的加密算法和加密消息语法（CMS）
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 conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined.
本文档描述了在加密消息语法（CMS）中使用Boneh Franklin（BF）和Boneh Boyen（BB1）基于身份的加密算法来加密内容加密密钥的约定。还定义了对象标识符和收件人身份编码约定。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. IBE Overview ...............................................3
2. Using Identity-Based Encryption .................................3
3. Key Encryption Algorithm Identifiers ............................6
4. Processing by the Sender ........................................7
5. Processing by the Receiver ......................................7
6. ASN.1 Module ....................................................8
7. Security Considerations .........................................9
7.1. Attacks outside the Scope of This Document .................9
7.2. Attacks within the Scope of This Document .................10
7.3. Attacks to Which the Protocols Defined in This Document
Are Susceptible............................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................12
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. IBE Overview ...............................................3
2. Using Identity-Based Encryption .................................3
3. Key Encryption Algorithm Identifiers ............................6
4. Processing by the Sender ........................................7
5. Processing by the Receiver ......................................7
6. ASN.1 Module ....................................................8
7. Security Considerations .........................................9
7.1. Attacks outside the Scope of This Document .................9
7.2. Attacks within the Scope of This Document .................10
7.3. Attacks to Which the Protocols Defined in This Document
Are Susceptible............................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................12
This document defines the way to use the Boneh-Franklin [IBCS] and Boneh-Boyen [IBCS] identity-based encryption (IBE) public-key algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a public-key technology for encrypting content-encryption keys (CEKs) that can be implemented within the framework of the CMS: the recipient's identity is incorporated into the EnvelopedData CMS content type using the OtherRecipientInfo CHOICE in the RecipientInfo field as defined in Section 6.2.5 of [CMS]. This document does not describe the implementation of the BF and BB1 algorithms, which are described in detail in [IBCS].
本文档定义了在加密消息语法（CMS）[CMS]中使用Boneh Franklin[IBCS]和Boneh Boyen[IBCS]基于身份的加密（IBE）公钥算法的方法。IBE是一种用于加密内容加密密钥（CEK）的公钥技术，可在CMS框架内实现：收件人的身份通过[CMS]第6.2.5节中定义的RecipientInfo字段中的OtherRecipientInfo选项并入EnvelopedData CMS内容类型。本文件不描述BF和BB1算法的实现，这些算法在[IBCS]中有详细描述。
IBE algorithms are a type of public-key cryptographic algorithm in which the public key is calculated directly from a user's identity instead of being generated randomly. This requires a different set of steps for encryption and decryption than would be used with other public-key algorithms, and these steps are defined in Sections 4 and 5 of this document, respectively.
IBE算法是一种公钥密码算法，其中公钥直接从用户身份计算，而不是随机生成。这需要一组不同于其他公钥算法的加密和解密步骤，这些步骤分别在本文件第4节和第5节中定义。
This document also defines the object identifiers and syntax of the object that is used to define the identity of a message recipient.
本文档还定义了用于定义邮件收件人身份的对象标识符和对象语法。
CMS values and identity objects are defined using ASN.1 [ASN1].
CMS值和标识对象使用ASN.1[ASN1]定义。
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 RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
In addition to the client components that are described in this document, the following additional components are required for a complete IBE messaging system.
除了本文档中描述的客户端组件外，完整的IBE消息传递系统还需要以下附加组件。
o A Private-Key Generator (PKG). The PKG contains the cryptographic material, known as a master secret, for generating an individual'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.
o 私钥生成器（PKG）。PKG包含加密材料，称为主密钥，用于生成个人的IBE私钥。PKG接受IBE用户的私钥请求，并在以某种方式成功对其进行身份验证后，返回其IBE私钥。
o A Public Parameter Server (PPS). IBE system parameters include publicly sharable cryptographic material, known as IBE public parameters, and policy information for the PKG. A PPS provides a well-known location for distribution of IBE public parameters and policy information for the IBE PKG.
o 公共参数服务器（PPS）。IBE系统参数包括公开共享的加密材料（称为IBE公共参数）和PKG的策略信息。PPS为IBE PKG的IBE公共参数和策略信息的分发提供了一个众所周知的位置。
The interactions of senders and receivers of IBE-encrypted messages are described in [IBE]. All communications between users of an IBE system and the PPS or PKG MUST be protected using TLS [TLS] as described in [IBE]. This provides confidentiality and integrity of all information that is delivered to users as well as authentication of the PPS and PKG.
[IBE]中描述了IBE加密消息的发送方和接收方之间的交互。IBE系统用户与PPS或PKG之间的所有通信必须使用[IBE]中所述的TLS[TLS]进行保护。这提供了交付给用户的所有信息的机密性和完整性，以及PPS和PKG的身份验证。
To use IBE, the ori field in RecipientInfo MUST be used. The fields are set as follows: oriType is set to ibeORIType; oriValue is set to ibeORIValue.
要使用IBE，必须使用RecipientInfo中的ori字段。字段设置如下：oriType设置为ibeORIType；oriValue设置为ibeORIValue。
These fields have the following meanings:
这些字段具有以下含义：
ibeORIType defines the object identifier (OID) that indicates that the subsequent ibeORIValue is the information necessary to decrypt the message using IBE. This field MUST be set to the following:
ibeORIType定义了对象标识符（OID），它指示后续的ibeORIValue是使用IBE解密消息所必需的信息。此字段必须设置为以下值：
ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) version(1)
}
ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) version(1)
}
ibeORIValue defines the identity that was used in the IBE algorithm to encrypt the CEK. This is an IBERecipientInfo type, which is defined as follows:
ibeORIValue定义IBE算法中用于加密CEK的标识。这是一种IBERecipientInfo类型，定义如下：
IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey
}
IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey
}
The fields of IBERecipientInfo MUST be set as follows.
必须按如下方式设置IBERecipientInfo的字段。
The cmsVersion MUST be set to 3.
cmsVersion必须设置为3。
The keyFetchMethod is the OID that defines the method of retrieving the private key that the recipient MUST use. This SHOULD be set to uriPPSOID [IBE], which is defined to be the following:
keyFetchMethod是定义检索收件人必须使用的私钥的方法的OID。这应设置为UripSoid[IBE]，定义如下：
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 recipientIdentity is the data that the sender used to calculate the IBE public key that the sender used to encrypt the content-encryption key. This recipientIdentity is used to calculate IBE public and private keys as described in [IBCS]. This MUST be a DER-encoded [DER] IBEIdentityInfo type [IBE], which is defined as follows:
recipientIdentity是发送方用来计算IBE公钥的数据，发送方用来加密内容加密密钥。此recipientIdentity用于计算IBE公钥和私钥，如[IBCS]中所述。这必须是DER编码的[DER]IBEIdentityInfo类型[IBE]，定义如下：
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}
The identityType defines the format that is used to encode the information that defines the identity of the recipient. This MUST be set to cmsIdentityOID to indicate that identityData contains an EmailIdentityData type. The value of cmsIdentityOID is the following:
identityType定义用于编码定义收件人身份的信息的格式。必须将其设置为cmsIdentityOID，以指示identityData包含EmailIdentityData类型。cmsIdentityOID的值如下所示：
cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1)
}
cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1)
}
The identityData MUST be an EmailIdentityData type, which is defined as follows:
identityData必须是EmailIdentityData类型，其定义如下：
EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String,
time GeneralizedTime
}
EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String,
time GeneralizedTime
}
The rfc822Name field is the email address of the recipient in the format defined in Section 4.2.1.6 of [PKIX] for the rfc822Name subjectAltName variant. Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5 of [PKIX].
rfc822Name字段是收件人的电子邮件地址，采用[PKIX]第4.2.1.6节中为rfc822Name subjectAltName变量定义的格式。[PKIX]第7.5节规定了对包含国际化域名的互联网邮件地址进行编码的规则。
The value of the time field is the UTC time after which the sender wants to let the recipient decrypt the message, so it may be called the "not-before" time. This is usually set to the time when the message is encrypted, but MAY be set to a future time. The value of "time" 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.
时间字段的值是UTC时间，在UTC时间之后，发件人希望让收件人解密邮件，因此可以将其称为“非之前”时间。这通常设置为消息加密的时间，但也可以设置为将来的时间。“时间”的值必须以格林威治标准时间（Zulu）表示，必须包括秒（即时间始终为YYYYMMDDHHMMSSZ），即使秒数等于零，也必须以最接近的秒表示。
The sender of an IBE-encrypted message may want to express this time rounded to a time interval to create a key lifetime. A key lifetime reduces the number of IBE private keys that a recipient needs to retrieve, but still forces the IBE user to periodically re-authenticate. Based on the time interval chosen a recipient would only have to retrieve a new IBE key once during the interval. To do this, follow the steps below. Let "time-interval" be the number of seconds in this larger time interval.
IBE加密消息的发送方可能希望将此时间四舍五入到一个时间间隔，以创建密钥生存期。密钥生存期减少了收件人需要检索的IBE私钥的数量，但仍然强制IBE用户定期重新验证。根据选定的时间间隔，收件人只需在该时间间隔内检索一次新的IBE密钥。要执行此操作，请执行以下步骤。让“时间间隔”为较大时间间隔内的秒数。
1. Find the GeneralizedTime for the not-before value. 2. Convert this GeneralizedTime into the number of seconds since January 1, 1970. Call this "total-time". 3. Calculate reduced-time = (floor (total-time / time-interval)) * time-interval. 4. Convert reduced-time to a GeneralizedTime to get the not-before "time" value.
1. 查找not before值的GeneratedTime。2.将此GeneratedTime转换为自1970年1月1日起的秒数。称之为“总时间”。3.计算减少的时间=（下限（总时间/时间间隔））*时间间隔。4.将减少的时间转换为泛化时间，以获取“时间”之前的值。
An example of this algorithm for computing a one-week time interval is as follows.
计算一周时间间隔的算法示例如下。
1. Suppose that the GeneralizedTime is 20020401000000Z. 2. Then the total-time is 1017612000. 3. A time-interval of 1 week is 604800 seconds. So the reduced-time = (floor (1017612000 / 604800)) * 604800 = 1017273600. 4. This gives the GeneralizedTime form of the reduced-time of 20020328000000Z.
1. 假设GeneratedTime为20020401000000Z。2.那么总时间是1017612000。3.一周的时间间隔为604800秒。因此减少的时间=（地板（1017612000/604800））*604800=1017273600。4.这给出了20020328000000Z缩短时间的广义时间形式。
When issuing IBE private keys, a PKG SHOULD NOT issue them too far into the future. This restriction is to prevent an adversary who obtains an IBE user's authentication credentials from requesting private keys far into the future and therefore negating the periodic IBE user re-authentication that key lifetime provides. For example, if a one-week period is chosen for the key lifetime, then IBE private keys should not be issued more than one week in advance. Otherwise, once an adversary gains access to the PKG via the stolen IBE user credentials, they can request all future keys and negate the IBE user authentication restraints in place.
在发布IBE私钥时，PKG不应在将来发布太多。此限制是为了防止获得IBE用户身份验证凭据的对手在将来请求私钥，从而否定密钥生命周期提供的定期IBE用户重新身份验证。例如，如果为密钥生存期选择了一周的时间段，则IBE私钥不应提前超过一周发出。否则，一旦对手通过被盗的IBE用户凭据获得PKG访问权，他们可以请求所有未来的密钥并取消IBE用户身份验证限制。
The serverInfo is an optional sequence of OID-value pairs that are defined to be the following:
serverInfo是OID值对的可选序列，定义如下：
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
These can be used to convey any other information that might be used by a PKG. Examples of such information could include the user interface that the recipient will experience. Differences in the user interface could include localization information or commercial branding information. A client MUST ignore any part of serverInfo that it is unable to process.
这些可用于传递PKG可能使用的任何其他信息。此类信息的示例可能包括接收者将体验到的用户界面。用户界面的差异可能包括本地化信息或商业品牌信息。客户端必须忽略其无法处理的serverInfo的任何部分。
The encryptedKey is the result of encrypting the CEK with an IBE algorithm using recipientIdentity as the IBE public key.
encryptedKey是通过使用recipientIdentity作为IBE公钥的IBE算法对CEK进行加密的结果。
The BF and BB1 algorithms as defined in [IBCS] have the following object identifiers. These object identifiers are also defined in the ASN.1 module in [IBCS].
[IBCS]中定义的BF和BB1算法具有以下对象标识符。这些对象标识符也在[IBCS]的ASN.1模块中定义。
bf OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1)
}
bf OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1)
}
This is the object identifier that MUST be inserted in the keyEncryptionAlgorithm field in the CMS when the BF algorithm is used to encrypt the CEK.
这是当BF算法用于加密CEK时，必须插入CMS中keyEncryptionAlgorithm字段中的对象标识符。
bb1 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2)
}
bb1 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2)
}
This is the object identifier that MUST be inserted in the keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is used to encrypt the CEK.
这是当BB1算法用于加密CEK时，必须插入CMS中keyEncryptionAlgorithm字段中的对象标识符。
The sender of a message that uses IBE to encrypt content-encryption keys performs the following steps:
使用IBE加密内容加密密钥的邮件的发件人执行以下步骤：
1. Selects a set of IBE public parameters to use in the subsequent steps in accordance with his local security policy. He then determines the URI where the public parameters can be obtained using the process described in [IBE]. This information MUST be encoded in the IBEIdentityInfo as described in Section 2.
1. 根据本地安全策略，选择一组IBE公共参数以在后续步骤中使用。然后，他确定可以使用[IBE]中描述的过程获取公共参数的URI。此信息必须按照第2节所述在IBEIdentityInfo中进行编码。
2. Sets the fields of an OtherRecipientInfo object to their appropriate values as described in Section 2.
2. 如第2节所述，将OtherRecipientInfo对象的字段设置为相应的值。
3. Calculates an IBE public key as defined in [IBCS] using this IBEIdentityInfo as the identity information.
3. 使用此IBEIdentityInfo作为标识信息，计算[IBCS]中定义的IBE公钥。
4. This IBE public key is then used to encrypt the content-encryption key (CEK), using the algorithms that are defined in [IBCS].
4. 然后使用[IBCS]中定义的算法，使用该IBE公钥对内容加密密钥（CEK）进行加密。
5. Sets encryptedKey to the IBE-encrypted CEK.
5. 将encryptedKey设置为IBE加密的CEK。
6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the appropriate OID for the IBE algorithm that was used (see Section 3).
6. 在CMS中，必须将keyEncryptionAlgorithm设置为所用IBE算法的适当OID（参见第3节）。
Upon receiving a message that has a CEK encrypted with IBE, the recipient performs the following steps to decrypt the CEK:
收到使用IBE加密CEK的邮件后，收件人将执行以下步骤对CEK进行解密：
1. Determines that the CEK is IBE-encrypted by noting that the oriType of the OtherRecipientInfo type is set to ibeORIType.
1. 通过注意OtherRecipientInfo类型的oriType设置为ibeORIType，确定CEK是IBE加密的。
2. Determines that the recipientIdentity was used as the identity in IBE encryption of the CEK.
2. 确定recipientIdentity用作CEK的IBE加密中的标识。
3. Determines the location of the IBE public parameters and the IBE Private Key Generator as described in [IBE].
3. 确定IBE公共参数和IBE私钥生成器的位置，如[IBE]中所述。
4. Obtains the IBE public parameters from the location determined in Step 3 using the process defined in [IBE].
4. 使用[IBE]中定义的过程，从步骤3中确定的位置获取IBE公共参数。
5. Obtains the IBE private key needed to decrypt the encrypted CEK using the process defined in [IBE].
5. 使用[IBE]中定义的过程获取解密加密CEK所需的IBE私钥。
6. Decrypts the CEK using the IBE private key obtained in Step 4 using the algorithms described in [IBCS].
6. 使用步骤4中使用[IBCS]中描述的算法获得的IBE私钥解密CEK。
The following ASN.1 module summarizes the ASN.1 definitions defined by this document.
以下ASN.1模块总结了本文档定义的ASN.1定义。
IBECMS-module {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) module(5) version(1)
}
IBECMS-module {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) module(5) version(1)
}
DEFINITIONS IMPLICIT TAGS ::= BEGIN
DEFINITIONS IMPLICIT TAGS ::= BEGIN
IMPORTS IBEIdentityInfo, uriPPSOID FROM
从导入IBEIdentityInfo、UripSoid
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)
};
IBEOtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue IBERecipientInfo
}
IBEOtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue IBERecipientInfo
}
ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) version(1)
}
ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) version(1)
}
IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey
}
IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey
}
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
EncryptedKey ::= OCTET STRING
EncryptedKey ::= OCTET STRING
EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String,
time GeneralizedTime
}
EmailIdentityData ::= SEQUENCE {
rfc822Name IA5String,
time GeneralizedTime
}
cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1)
}
cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) email(1) version(1)
}
END
终止
This document is based on [CMS], [IBCS], and [IBE], and the relevant security considerations of those documents apply.
本文件基于[CMS]、[IBCS]和[IBE]，这些文件的相关安全注意事项适用。
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,
对用于实现IBE的加密算法的攻击超出了本文档的范围。此类攻击在[IBCS]中有详细说明，其中定义了提供80位，
112-bit, 128-bit, and 256-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.
112位、128位和256位加密强度。我们假设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 to the PKG or the ability to modify the information distributed by the PPS is infeasible for attackers to obtain.
使对手能够访问或更改PPS或PKG上的信息，特别是加密材料（在本文档中称为主机密）的攻击将破坏IBE系统的安全性。特别是，如果加密材料被泄露，对手将能够重新创建任何用户的私钥，从而解密所有受相应公钥保护的消息。为了解决这一问题，强烈建议遵循PPS和PKG服务器物理和操作安全的最佳实践，并根据当前最佳实践[NIST]对这些服务器进行配置（有时称为加固）。IBE系统应在攻击者无法非法访问PKG或修改PPS分发的信息的环境中运行。
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. This is of particular importance with an IBE system, for an administrator of a PKG could potentially abuse his authority and configure the PKG to grant him any IBE private key that the PKG is capable of calculating. To minimize the possibility of administrators doing this, a system implementing IBE SHOULD implement n-out-of-m control for critical administrative functions and SHOULD maintain auditable logs of all security-critical events that occur in an operating IBE system.
我们还假设，实现本文档中定义的协议的系统的所有管理员都是可信的，不会滥用其权限绕过IBE系统提供的安全性。这对于IBE系统尤其重要，因为PKG的管理员可能会滥用其权限，并配置PKG以授予其PKG能够计算的任何IBE私钥。为了最大限度地减少管理员这样做的可能性，实现IBE的系统应该对关键管理功能实施n-of-m控制，并且应该维护操作IBE系统中发生的所有安全关键事件的可审核日志。
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系统的用户行为负责，不会与其他人共享他们的身份验证凭据。因此，需要此类假设的攻击不在本文档的范围内。
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 user's authentication credential
o 轻松猜测IBE用户的身份验证凭据
7.3. Attacks to Which the Protocols Defined in This Document Are Susceptible
7.3. 本文档中定义的协议易受攻击
All communications between users of an IBE system and the PPS or PKG are protected using TLS [TLS]. The IBE system defined in this document provides no additional security 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[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 allows 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 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 used 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用户的身份验证凭据。
[ASN1] ITU-T Recommendation X.680: Information Technology - "Abstract Syntax Notation One (ASN.1): Specification of Basic Notation", July 2002.
[ASN1]ITU-T建议X.680：信息技术-“抽象语法符号1（ASN.1）：基本符号规范”，2002年7月。
[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月。
[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月。
[IBE] Appenzeller, G., Martin, L., and M. Schertler, "Identity-Based Encryption Architecture and Supporting Data Structures", RFC 5408, January 2009.
[IBE]Appenzeller，G.，Martin，L.和M.Schertler，“基于身份的加密体系结构和支持数据结构”，RFC 5408，2009年1月。
[KEYWORDS] 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月。
[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月。
[BGPDOS] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
[BGPDOS]Turk，D.，“配置BGP以阻止拒绝服务攻击”，RFC 3882，2004年9月。
[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月。
Authors' Addresses
作者地址
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