Internet Engineering Task Force (IETF) K. Moriarty, Ed.
Request for Comments: 7292 EMC
Category: Informational M. Nystrom
ISSN: 2070-1721 Microsoft Corporation
S. Parkinson
A. Rusch
M. Scott
RSA
July 2014
Internet Engineering Task Force (IETF) K. Moriarty, Ed.
Request for Comments: 7292 EMC
Category: Informational M. Nystrom
ISSN: 2070-1721 Microsoft Corporation
S. Parkinson
A. Rusch
M. Scott
RSA
July 2014
PKCS #12: Personal Information Exchange Syntax v1.1
PKCS#12：个人信息交换语法v1.1
Abstract
摘要
PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.
PKCS#12 v1.1描述了个人身份信息的传输语法，包括私钥、证书、杂项机密和扩展。支持此标准的机器、应用程序、浏览器、互联网信息亭等将允许用户导入、导出和使用一组个人身份信息。本标准支持在多种隐私和完整性模式下直接传输个人信息。
This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
本文档是RSA实验室公钥加密标准（PKCS）系列中PKCS#12 v1.1的再版。通过发布此RFC，变更控制权转移到IETF。
IESG Note
IESG注释
The IESG thanks RSA Laboratories for transferring change control to the IETF. Enhancements to this specification that preserve backward compatibility are expected in an upcoming IETF Standards Track document.
IESG感谢RSA实验室将变更控制转移到IETF。预计在即将发布的IETF标准跟踪文档中会对本规范进行增强，以保持向后兼容性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7292.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7292.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes from PKCS #12 Version 1 . . . . . . . . . . . . . 4
2. Definitions and Notation . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Exchange Modes . . . . . . . . . . . . . . . . . . . . . 7
3.2. Mode Choice Policies . . . . . . . . . . . . . . . . . . 8
3.3. Trusted Public Keys . . . . . . . . . . . . . . . . . . . 8
3.4. The AuthenticatedSafe . . . . . . . . . . . . . . . . . . 9
4. PFX PDU Syntax . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. The AuthenticatedSafe Type . . . . . . . . . . . . . . . 11
4.2. The SafeBag Type . . . . . . . . . . . . . . . . . . . . 12
4.2.1. The KeyBag Type . . . . . . . . . . . . . . . . . . . 13
4.2.2. The PKCS8ShroudedKeyBag Type . . . . . . . . . . . . 13
4.2.3. The CertBag Type . . . . . . . . . . . . . . . . . . 13
4.2.4. The CRLBag Type . . . . . . . . . . . . . . . . . . . 14
4.2.5. The SecretBag Type . . . . . . . . . . . . . . . . . 14
4.2.6. The SafeContents Type . . . . . . . . . . . . . . . . 14
5. Using PFX PDUs . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Creating PFX PDUs . . . . . . . . . . . . . . . . . . . . 15
5.2. Importing Keys, etc., from a PFX PDU . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Normative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Message Authentication Codes (MACs) . . . . . . . . 19
Appendix B. Deriving Keys and IVs from Passwords and Salt . . . 19
B.1. Password Formatting . . . . . . . . . . . . . . . . . . . 19
B.2. General Method . . . . . . . . . . . . . . . . . . . . . 20
B.3. More on the ID Byte . . . . . . . . . . . . . . . . . . . 22
B.4. Keys for Password Integrity Mode . . . . . . . . . . . . 22
Appendix C. Keys and IVs for Password Privacy Mode . . . . . . . 22
Appendix D. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 24
Appendix E. Intellectual Property Considerations . . . . . . . . 28
Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . 28
Appendix G. About PKCS . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes from PKCS #12 Version 1 . . . . . . . . . . . . . 4
2. Definitions and Notation . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Exchange Modes . . . . . . . . . . . . . . . . . . . . . 7
3.2. Mode Choice Policies . . . . . . . . . . . . . . . . . . 8
3.3. Trusted Public Keys . . . . . . . . . . . . . . . . . . . 8
3.4. The AuthenticatedSafe . . . . . . . . . . . . . . . . . . 9
4. PFX PDU Syntax . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. The AuthenticatedSafe Type . . . . . . . . . . . . . . . 11
4.2. The SafeBag Type . . . . . . . . . . . . . . . . . . . . 12
4.2.1. The KeyBag Type . . . . . . . . . . . . . . . . . . . 13
4.2.2. The PKCS8ShroudedKeyBag Type . . . . . . . . . . . . 13
4.2.3. The CertBag Type . . . . . . . . . . . . . . . . . . 13
4.2.4. The CRLBag Type . . . . . . . . . . . . . . . . . . . 14
4.2.5. The SecretBag Type . . . . . . . . . . . . . . . . . 14
4.2.6. The SafeContents Type . . . . . . . . . . . . . . . . 14
5. Using PFX PDUs . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Creating PFX PDUs . . . . . . . . . . . . . . . . . . . . 15
5.2. Importing Keys, etc., from a PFX PDU . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Normative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Message Authentication Codes (MACs) . . . . . . . . 19
Appendix B. Deriving Keys and IVs from Passwords and Salt . . . 19
B.1. Password Formatting . . . . . . . . . . . . . . . . . . . 19
B.2. General Method . . . . . . . . . . . . . . . . . . . . . 20
B.3. More on the ID Byte . . . . . . . . . . . . . . . . . . . 22
B.4. Keys for Password Integrity Mode . . . . . . . . . . . . 22
Appendix C. Keys and IVs for Password Privacy Mode . . . . . . . 22
Appendix D. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 24
Appendix E. Intellectual Property Considerations . . . . . . . . 28
Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . 28
Appendix G. About PKCS . . . . . . . . . . . . . . . . . . . . . 28
This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF. RSA and its parent company EMC reserve the right to continue publishing and distributing PKCS #12 v1.1 and its predecessors.
本文档是RSA实验室公钥加密标准（PKCS）系列中PKCS#12 v1.1的再版。通过发布此RFC，变更控制权转移到IETF。RSA及其母公司EMC保留继续发布和分发PKCS#12 v1.1及其前身的权利。
The body of this document, except for the Security Considerations section, is taken directly from the PKCS #12 v1.1 specification. The list of references and the in-line cites have been updated or added where appropriate to cite the most current documents in addition to those current at the original publication of PKCS #12 v1.1.
除安全注意事项部分外，本文件正文直接取自PKCS#12 v1.1规范。参考文献列表和在线cites已在适当情况下更新或添加，以引用PKCS#12 v1.1原始出版物上最新的文件。
This standard describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information.
本标准描述了个人身份信息的传输语法，包括私钥、证书、杂项机密和扩展。支持此标准的机器、应用程序、浏览器、互联网信息亭等将允许用户导入、导出和使用一组个人身份信息。
This standard supports direct transfer of personal information under several privacy and integrity modes. The most secure of the privacy and integrity modes require the source and destination platforms to have trusted public/private key pairs usable for digital signatures and encryption, respectively. The standard also supports lower-security, password-based privacy and integrity modes for those cases where trusted public/private key pairs are not available.
本标准支持在多种隐私和完整性模式下直接传输个人信息。最安全的隐私和完整性模式要求源平台和目标平台分别具有可用于数字签名和加密的可信公钥/私钥对。该标准还支持较低安全性、基于密码的隐私和完整性模式，适用于不可用可信公钥/私钥对的情况。
This standard should be amenable to both software and hardware implementations. Hardware implementations offer physical security in tamper-resistant tokens such as smart cards and Personal Computer Memory Card International Association (PCMCIA) devices.
本标准应适用于软件和硬件实现。硬件实现在防篡改令牌（如智能卡和个人计算机存储卡国际协会（PCMCIA）设备）中提供物理安全性。
This standard can be viewed as building on PKCS #8 [15] [24] by including essential but ancillary identity information along with private keys and by instituting higher security through public-key privacy and integrity modes.
本标准可被视为建立在PKCS#8[15][24]的基础上，包括基本但辅助的身份信息以及私钥，并通过公钥隐私和完整性模式实现更高的安全性。
This document transfers PKCS #12 [16] into the IETF and includes some minor changes from the authors for this submission.
本文件将PKCS#12[16]转移到IETF中，并包含作者对此提交的一些小改动。
o Addition of hash algorithms.
o 添加哈希算法。
o Incorporation of Technical Corrigendum #1, which makes some minor corrections to the ASN.1 syntax.
o 合并技术勘误表1，对ASN.1语法进行了一些小的修改。
o Removed (from the ASN.1 syntax) 1024 as an example of the iteration count.
o 删除（从ASN.1语法中）1024作为迭代计数的示例。
o Addition of a recommendation that the technique in Appendix B no longer be used for a specific mode (password privacy mode) and that techniques from PKCS#5 v2.1 be used instead.
o 增加一项建议，即附录B中的技术不再用于特定模式（密码隐私模式），而是使用PKCS#5 v2.1中的技术。
o Addition of comments and minor corrections to the ASN.1 module in Appendix C.
o 对附录C中的ASN.1模块添加了注释和轻微更正。
o Removal of the export regulations discussion in the former Appendix D.
o 删除前附录D中的出口法规讨论。
o Replacement of RSA with EMC in the "Intellectual Property Considerations".
o 在“知识产权注意事项”中用EMC替换RSA。
o Many changes and additions to the references.
o 对参考文献进行了许多更改和添加。
o A reference was added to NIST SP 800-132 for its recommendations on selection of the iteration count value for password integrity (part of dictionary-attack resistance).
o NIST SP 800-132中增加了一个参考，以了解其关于选择密码完整性迭代计数值的建议（字典攻击抵抗的一部分）。
o Comment included on acronym expansion of PFX: The acronym is sometimes expanded as Personal Information Exchange.
o 包括对PFX首字母缩略词扩展的评论：首字母缩略词有时扩展为个人信息交换。
o In Appendix B, the phrase "no longer recommended" was changed to "not recommended" in the following sentence to address a question and make it clear the method was not recommended: "Note that this method for password privacy mode is no longer recommended."
o 在附录B中，以下句子中的短语“不再推荐”改为“不推荐”，以解决一个问题，并明确说明不推荐该方法：“注意，不再推荐密码隐私模式的此方法。”
AlgorithmIdentifier: An ASN.1 type that identifies an algorithm (by an object identifier) and any associated parameters. This type is defined in [8].
AlgorithmIdentifier：ASN.1类型，用于识别算法（通过对象标识符）和任何相关参数。此类型在[8]中定义。
ASN.1: Abstract Syntax Notation One, as defined in [2], [3], [4], and [5].
ASN.1：抽象语法符号1，如[2]、[3]、[4]和[5]中所定义。
Attribute: An ASN.1 type that identifies an attribute type (by an object identifier) and an associated attribute value. The ASN.1 type Attribute is defined in [7].
属性：ASN.1类型，用于标识属性类型（通过对象标识符）和关联的属性值。ASN.1类型属性在[7]中定义。
Certificate: A digitally signed data unit binding a public key to identity information. A specific format for identity certificates is defined in [8]. Another format is described in [17].
证书：将公钥绑定到身份信息的数字签名数据单元。[8]中定义了身份证书的特定格式。[17]中描述了另一种格式。
Certificate Revocation List (CRL): A digitally signed list of certificates that should no longer be honored, having been revoked by the issuers or a higher authority. One format for CRLs is defined in [8].
证书吊销列表（CRL）：一个数字签名的证书列表，这些证书已被颁发者或更高权限吊销，不应再被遵守。[8]中定义了CRLs的一种格式。
ContentInfo: An ASN.1 type used to hold data that may have been cryptographically protected. This type is defined in [21] and [14].
ContentInfo：一种ASN.1类型，用于保存可能受到加密保护的数据。[21]和[14]中定义了该类型。
DER: Distinguished Encoding Rules, as defined in [6].
DER：区分编码规则，如[6]中所定义。
Destination platform: The ultimate, final target platform for the personal information originating from the source platform. Even though certain information may be transported from the destination platform to the source platform, the ultimate target for personal information is always called the destination platform.
目标平台：源平台个人信息的最终目标平台。即使某些信息可能从目标平台传输到源平台，个人信息的最终目标始终称为目标平台。
DigestInfo: An ASN.1 type used to hold a message digest. This type is defined in [21] and [14].
DigestInfo：用于保存消息摘要的ASN.1类型。[21]和[14]中定义了该类型。
Encryption Key Pair (DestEncK): A public/private key pair used for the public-key privacy mode of this standard. The public half is called PDestEncK (TPDestEncK when emphasizing that the public key is "trusted"), and the private half is called VDestEncK.
加密密钥对（DestEncK）：用于本标准公钥隐私模式的公钥/私钥对。公共部分称为PDestEncK（当强调公钥是“可信的”时称为TPDestEncK），私有部分称为VDestEncK。
Export time: The time that a user reads personal information from a source platform and transforms the information into an interoperable, secure Protocol Data Unit (PDU).
导出时间：用户从源平台读取个人信息并将信息转换为可互操作的安全协议数据单元（PDU）的时间。
Import time: The time that a user writes personal information from a Safe PDU to a destination platform.
导入时间：用户将个人信息从安全PDU写入目标平台的时间。
Message Authentication Code (MAC): A type of collision-resistant, "unpredictable" function of a message and a secret key. MACs are used for data authentication and are akin to secret-key digital signatures in many respects.
消息身份验证码（MAC）：消息和密钥的一种抗冲突、“不可预测”功能。MAC用于数据认证，在许多方面类似于密钥数字签名。
Object Identifier: A sequence of integers that uniquely identifies an associated data object in a global name space administrated by a hierarchy of naming authorities. This is a primitive data type in ASN.1.
对象标识符：一个整数序列，它唯一地标识由命名机构层次结构管理的全局名称空间中的关联数据对象。这是ASN.1中的基本数据类型。
PFX: The top-level exchange PDU defined in this standard. The acronym is sometimes expanded as Personal Information Exchange.
PFX：本标准中定义的顶级exchange PDU。缩写词有时扩展为个人信息交换。
Platform: A combination of machine, operating system, and applications software within which the user exercises personal identity. An application, in this context, is software that uses personal information. Two platforms differ if their machine types differ or if their applications software differs. There is at least one platform per user in multi-user systems.
平台：机器、操作系统和应用软件的组合，用户在其中行使个人身份。在此上下文中，应用程序是使用个人信息的软件。如果两个平台的机器类型不同或应用软件不同，则两个平台不同。在多用户系统中，每个用户至少有一个平台。
Protocol Data Unit (PDU): A sequence of bits in machine-independent format constituting a message in a protocol.
协议数据单元（PDU）：以独立于机器的格式构成协议中消息的位序列。
Shrouding: Encryption as applied to private keys, possibly in concert with a policy that prevents the plaintext of the key from ever being visible beyond a certain, well-defined interface.
覆盖：应用于私钥的加密，可能与防止密钥的明文在某个定义良好的接口之外可见的策略相一致。
Signature Key Pair (SrcSigK): A platform-specific signature key pair used for the public-key integrity mode of this standard. The public half is called PSrcSigK (TPSrcSigK when emphasizing that the public key is "trusted"), and the private half is called VSrcSigK.
签名密钥对（SrcSigK）：用于本标准公钥完整性模式的平台特定签名密钥对。公共部分称为PSrcSigK（当强调公钥是“可信的”时称为TPSrcSigK），私有部分称为VSrcSigK。
Source platform: The origin platform of the personal information ultimately intended for the destination platform. Even though certain information may be transported from the destination platform to the source platform, the platform that is the origin of personal information is always called the source platform.
源平台：个人信息的源平台，最终用于目标平台。即使某些信息可能会从目标平台传输到源平台，但作为个人信息来源的平台始终称为源平台。
There are four combinations of privacy modes and integrity modes. The privacy modes use encryption to protect personal information from exposure, and the integrity modes protect personal information from tampering. Without protection from tampering, an adversary could conceivably substitute invalid information for the user's personal information without the user being aware of the substitution.
隐私模式和完整性模式有四种组合。隐私模式使用加密保护个人信息不被泄露，完整性模式保护个人信息不被篡改。在没有防篡改保护的情况下，对手可以在用户不知道替换的情况下用无效信息替换用户的个人信息。
The following are the privacy modes:
以下是隐私模式：
o Public-key privacy mode: Personal information is enveloped on the source platform using a trusted encryption public key of a known destination platform (see Section 3.3). The envelope is opened with the corresponding private key.
o 公钥隐私模式：使用已知目标平台的可信加密公钥在源平台上封装个人信息（参见第3.3节）。信封用相应的私钥打开。
o Password privacy mode: Personal information is encrypted with a symmetric key derived from a user name and a privacy password, as in [22] and [13]. If password integrity mode is used as well, the privacy password and the integrity password may or may not be the same.
o 密码隐私模式：使用从用户名和隐私密码派生的对称密钥对个人信息进行加密，如[22]和[13]所示。如果同时使用密码完整性模式，则隐私密码和完整性密码可能相同，也可能不同。
The following are the integrity modes:
以下是完整性模式：
o Public-key integrity mode: Integrity is guaranteed through a digital signature on the contents of the PFX PDU, which is produced using the source platform's private signature key. The signature is verified on the destination platform by using the corresponding public key (see Section 3.4).
o 公钥完整性模式：通过对PFX PDU内容的数字签名来保证完整性，该签名使用源平台的私有签名密钥生成。通过使用相应的公钥在目标平台上验证签名（见第3.4节）。
o Password integrity mode: Integrity is guaranteed through a Message Authentication Code (MAC) derived from a secret integrity password. If password privacy mode is used as well, the privacy password and the integrity password may or may not be the same.
o 密码完整性模式：通过从机密完整性密码派生的消息身份验证码（MAC）来保证完整性。如果同时使用密码隐私模式，则隐私密码和完整性密码可能相同，也可能不同。
All combinations of the privacy and integrity modes are permitted in this standard. Of course, good security policy suggests that certain practices be avoided, e.g., it can be unwise to transport private keys without physical protection when using password privacy mode or when using public-key privacy mode with weak symmetric encryption.
本标准允许隐私和完整性模式的所有组合。当然，良好的安全策略建议避免某些做法，例如，在使用密码隐私模式或使用带有弱对称加密的公钥隐私模式时，在没有物理保护的情况下传输私钥可能是不明智的。
In general, the public-key modes for both privacy and integrity are preferable to the password modes (from a security viewpoint). However, it is not always possible to use the public-key modes. For example, it may not be known at export time what the destination platform is; if this is the case, then the use of the public-key privacy mode is precluded.
一般来说，隐私和完整性的公钥模式比密码模式更可取（从安全角度来看）。但是，并不总是可以使用公钥模式。例如，在导出时可能不知道目标平台是什么；如果是这种情况，则禁止使用公钥隐私模式。
Asymmetric key pairs may be used in this standard in two ways: public-key privacy mode and public-key integrity mode. For public-key privacy mode, an encryption key pair is required; for public-key integrity mode, a signature key pair is required.
非对称密钥对可在本标准中以两种方式使用：公钥隐私模式和公钥完整性模式。对于公钥隐私模式，需要加密密钥对；对于公钥完整性模式，需要签名密钥对。
It may be appropriate for the keys discussed in this section to be platform-specific keys dedicated solely for the purpose of transporting a user's personal information. Whether or not that is the case, though, the keys discussed here should not be confused with the user's personal keys that the user wishes to transport from one platform to another. (These latter keys are stored within the PDU.)
本节中讨论的密钥可能适合于平台专用密钥，专用于传输用户个人信息。不管是不是这样，这里讨论的密钥不应该与用户希望从一个平台传输到另一个平台的用户个人密钥混淆。（后面的这些键存储在PDU中。）
For public-key privacy mode, the private key from the encryption key pair is kept on the destination platform, where it is ultimately used to open a private envelope. The corresponding trusted public key is called TPDestEncK.
对于公钥隐私模式，来自加密密钥对的私钥保存在目标平台上，最终用于打开私钥信封。相应的受信任公钥称为TPDestEncK。
For public-key integrity mode, the private key from the signature pair is kept on the source platform, where it is used to sign personal information. The corresponding trusted public key is called TPSrcSigK.
对于公钥完整性模式，来自签名对的私钥保存在源平台上，用于对个人信息进行签名。相应的受信任公钥称为TPSrcSigK。
For both uses of public/private key pairs, the public key from the key pair must be transported to the other platform such that it is trusted to have originated at the correct platform. Judging whether or not a public key is trusted in this sense must ultimately be left to the user. There are a variety of methods for ensuring that a public key is trusted.
对于公钥/私钥对的两种用途，必须将密钥对中的公钥传输到另一个平台，以确保它在正确的平台上产生。从这个意义上判断公钥是否可信最终必须留给用户。有多种方法可以确保公钥是可信的。
The processes of imbuing keys with trust and of verifying trustworthiness of keys are not discussed further in this document. Whenever asymmetric keys are discussed in what follows, the public keys are assumed to be trusted.
在本文档中不进一步讨论向密钥注入信任和验证密钥可信度的过程。无论何时在下文中讨论非对称密钥，都假定公钥是可信的。
Each compliant platform shall be able to import and export AuthenticatedSafe PDUs wrapped in PFX PDUs.
每个合规平台应能够导入和导出包裹在PFX PDU中的经认证的安全PDU。
For integrity, the AuthenticatedSafe is either signed (if public-key integrity mode is used) or MACed (if password integrity mode is used) to produce a PFX PDU. If the AuthenticatedSafe is signed, then it is accompanied by a digital signature, which was produced on the source platform with a private signature key, VSrcSigK, corresponding to a trusted public signature key, TPSrcSigK. TPSrcSigK must accompany the PFX to the destination platform, where the user can verify the trust in the key and can verify the signature on the AuthenticatedSafe. If the AuthenticatedSafe is MACed, then it is accompanied by a MAC computed from a secret integrity password, salt bits, an iteration count, and the contents of the AuthenticatedSafe.
对于完整性，AuthenticatedSafe被签名（如果使用公钥完整性模式）或MACE（如果使用密码完整性模式）以生成PFX PDU。如果对AuthenticatedSafe进行了签名，那么它将伴随一个数字签名，该数字签名是在源平台上使用私有签名密钥VSrcSigK生成的，对应于可信的公共签名密钥TPSrcSigK。TPSrcSigK必须随PFX一起到达目标平台，在该平台上，用户可以验证密钥中的信任度，并可以验证AuthenticatedSafe上的签名。如果对AuthenticatedSafe进行了MACE，那么它将伴随一个MAC，该MAC是根据机密完整性密码、盐位、迭代计数和AuthenticatedSafe的内容计算得出的。
The AuthenticatedSafe itself consists of a sequence of ContentInfo values, some of which may consist of plaintext (data), and others that may either be enveloped (if public-key privacy mode is used) or encrypted (if password privacy mode is used). If the contents are enveloped, then they are encrypted with a symmetric cipher under a freshly generated key, which is in turn encrypted with RSA asymmetric encryption. The RSA public key used to encrypt the symmetric key is called TPDestEncK and corresponds to an RSA private key, VDestEncK, on the destination platform. TPDestEncK needs to be trusted by the
AuthenticatedSafe本身由一系列ContentInfo值组成，其中一些值可能由明文（数据）组成，另一些值可能被封装（如果使用公钥隐私模式）或加密（如果使用密码隐私模式）。如果内容是封装的，则使用新生成的密钥下的对称密码对其进行加密，然后使用RSA非对称加密对密钥进行加密。用于加密对称密钥的RSA公钥称为TPDestEncK，它对应于目标平台上的RSA私钥VDestEncK。TPDestEncK需要得到客户的信任
user when it is used at export time. If the contents are encrypted, then they are encrypted with a symmetric cipher under a key derived from a secret privacy password, salt bits, and an iteration counter.
导出时使用时的用户。如果内容是加密的，则使用对称密码对其进行加密，加密密钥来自秘密隐私密码、盐位和迭代计数器。
Each ContentInfo contains an arbitrary collection of private keys, PKCS #8-shrouded private keys, certificates, CRLs, or opaque data objects, at the user's discretion, stored in values of type SafeContents.
每个ContentInfo包含私钥、PKCS#8-屏蔽私钥、证书、CRL或不透明数据对象的任意集合，由用户自行决定，存储在SafeContents类型的值中。
The raison d'etre for the unencrypted option is that some governments restrict certain uses of cryptography. Having several parts in an AuthenticatedSafe keeps implementers' options open. For example, it may be the case that strong cryptography can be used to make PKCS #8-shrouded keys, but then these shrouded keys should not be further encrypted, because super-encryption can limit a product's exportability. The multi-part AuthenticatedSafe design permits this possibility.
未加密选项存在的理由是，一些政府限制加密的某些用途。在AuthenticatedSafe中包含多个部分可以使实现者的选项保持打开状态。例如，在这种情况下，可以使用强加密技术来生成PKCS#8-屏蔽密钥，但不应进一步加密这些屏蔽密钥，因为超级加密会限制产品的可导出性。多部件认证安全设计允许这种可能性。
Around the AuthenticatedSafe is the integrity-mode wrapper, which protects the entire contents of the AuthenticatedSafe (including unencrypted parts, if they are present). This is the reverse of the wrapping order in many protocols, in which privacy is the outermost protection. This latter, more-common wrapping order avoids signatures on encrypted data, which are undesirable under certain circumstances; however, these circumstances do not apply to this document, and it is therefore preferable to protect the integrity of as much information as possible.
AuthenticatedSafe的周围是完整性模式包装器，它保护AuthenticatedSafe的全部内容（包括未加密的部分，如果存在的话）。这与许多协议中的包装顺序相反，在这些协议中，隐私是最外层的保护。后一种更常见的包装顺序避免了加密数据上的签名，这在某些情况下是不可取的；但是，这些情况不适用于本文件，因此最好尽可能保护信息的完整性。
This format corresponds to the data model presented above, with wrappers for privacy and integrity. This section makes free reference to PKCS #7 [14] [21] and assumes the reader is familiar with terms defined in that document.
这种格式对应于上面介绍的数据模型，带有保护隐私和完整性的包装。本节免费参考PKCS#7[14][21]，并假设读者熟悉该文件中定义的术语。
All modes of direct exchange use the same PDU format. ASN.1 and BER-encoding ensure platform independence.
所有直接交换模式都使用相同的PDU格式。ASN.1和BER编码确保了平台独立性。
This standard has one ASN.1 export: PFX. This is the outer integrity wrapper. Instances of PFX contain:
本标准有一个ASN.1出口：PFX。这是外部完整性包装。PFX的实例包括：
1. A version indicator. The version shall be v3 for this version of this document.
1. 版本指示器。本文件的版本应为v3。
2. A PKCS #7 ContentInfo, whose contentType is signedData in public-key integrity mode and data in password integrity mode.
2. PKCS#7 ContentInfo，其contentType在公钥完整性模式下为signedData，在密码完整性模式下为data。
3. An optional instance of MacData, present only in password integrity. This object, if present, contains a PKCS #7 DigestInfo, which holds the MAC value, a macSalt, and an iterationCount. As described in Appendix B, the MAC key is derived from the password, the macSalt, and the iterationCount; as described in Section 5, the MAC is computed from the authSafe value and the MAC key via HMAC [11] [20]. The password and the MAC key are not actually present anywhere in the PFX. The salt and (to a certain extent) the iteration count thwarts dictionary attacks against the integrity password. See NIST Special Publication 800-132 [12] about how to choose a reasonable value for the iteration count.
3. MacData的可选实例，仅存在于密码完整性中。这个对象（如果存在）包含一个PKCS#7 DigestInfo，它保存MAC值、一个macSalt和一个iterationCount。如附录B所述，MAC密钥来自密码、macSalt和iterationCount；如第5节所述，MAC通过HMAC[11][20]从authSafe值和MAC密钥计算。密码和MAC密钥实际上并不存在于PFX中的任何位置。salt和（在一定程度上）迭代计数可以阻止针对完整性密码的字典攻击。关于如何选择迭代计数的合理值，请参见NIST专门出版物800-132[12]。
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
MacData ::= SEQUENCE {
mac DigestInfo,
macSalt OCTET STRING,
iterations INTEGER DEFAULT 1
-- Note: The default is for historical reasons and its
-- use is deprecated.
}
MacData ::= SEQUENCE {
mac DigestInfo,
macSalt OCTET STRING,
iterations INTEGER DEFAULT 1
-- Note: The default is for historical reasons and its
-- use is deprecated.
}
As mentioned, the contentType field of authSafe shall be of type data or signedData. The content field of the authSafe shall, either directly (data case) or indirectly (signedData case), contain a BER-encoded value of type AuthenticatedSafe.
如上所述，authSafe的contentType字段应为data或signedData类型。authSafe的内容字段应直接（数据案例）或间接（signedData案例）包含AuthenticatedSafe类型的BER编码值。
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted
An AuthenticatedSafe contains a sequence of ContentInfo values. The content field of these ContentInfo values contains either plaintext, encrypted, or enveloped data. In the case of encrypted or enveloped data, the plaintext of the data holds the BER-encoding of an instance of SafeContents. Section 5.1 of this document describes the construction of values of type AuthenticatedSafe in more detail.
AuthenticatedSafe包含一系列ContentInfo值。这些ContentInfo值的内容字段包含明文、加密或封装数据。在加密或封装数据的情况下，数据的明文保存SafeContents实例的BER编码。本文件第5.1节更详细地描述了AuthenticatedSafe类型值的构造。
The SafeContents type is made up of SafeBags. Each SafeBag holds one piece of information -- a key, a certificate, etc. -- which is identified by an object identifier.
SafeContents类型由安全袋组成。每个安全包都包含一条信息——一个密钥、一个证书等——由一个对象标识符标识。
SafeContents ::= SEQUENCE OF SafeBag
SafeContents ::= SEQUENCE OF SafeBag
SafeBag ::= SEQUENCE {
bagId BAG-TYPE.&id ({PKCS12BagSet})
bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
bagAttributes SET OF PKCS12Attribute OPTIONAL
}
SafeBag ::= SEQUENCE {
bagId BAG-TYPE.&id ({PKCS12BagSet})
bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
bagAttributes SET OF PKCS12Attribute OPTIONAL
}
PKCS12Attribute ::= SEQUENCE {
attrId ATTRIBUTE.&id ({PKCS12AttrSet}),
attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})
} -- This type is compatible with the X.500 type 'Attribute'
PKCS12Attribute ::= SEQUENCE {
attrId ATTRIBUTE.&id ({PKCS12AttrSet}),
attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})
} -- This type is compatible with the X.500 type 'Attribute'
PKCS12AttrSet ATTRIBUTE ::= {
friendlyName | -- from PKCS #9 [23]
localKeyId, -- from PKCS #9
... -- Other attributes are allowed
}
PKCS12AttrSet ATTRIBUTE ::= {
friendlyName | -- from PKCS #9 [23]
localKeyId, -- from PKCS #9
... -- Other attributes are allowed
}
The optional bagAttributes field allows users to assign nicknames and identifiers to keys, etc., and permits visual tools to display meaningful strings of some sort to the user.
可选的bagAttributes字段允许用户为键等分配昵称和标识符，并允许可视化工具向用户显示某种有意义的字符串。
Six types of SafeBags are defined in this version of this document:
本文件版本中定义了六种类型的安全袋：
bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}
bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}
BAG-TYPE ::= TYPE-IDENTIFIER
BAG-TYPE ::= TYPE-IDENTIFIER
keyBag BAG-TYPE ::=
{KeyBag IDENTIFIED BY {bagtypes 1}}
pkcs8ShroudedKeyBag BAG-TYPE ::=
{PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
certBag BAG-TYPE ::=
{CertBag IDENTIFIED BY {bagtypes 3}}
crlBag BAG-TYPE ::=
{CRLBag IDENTIFIED BY {bagtypes 4}}
secretBag BAG-TYPE ::=
{SecretBag IDENTIFIED BY {bagtypes 5}}
safeContentsBag BAG-TYPE ::=
{SafeContents IDENTIFIED BY {bagtypes 6}}
keyBag BAG-TYPE ::=
{KeyBag IDENTIFIED BY {bagtypes 1}}
pkcs8ShroudedKeyBag BAG-TYPE ::=
{PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
certBag BAG-TYPE ::=
{CertBag IDENTIFIED BY {bagtypes 3}}
crlBag BAG-TYPE ::=
{CRLBag IDENTIFIED BY {bagtypes 4}}
secretBag BAG-TYPE ::=
{SecretBag IDENTIFIED BY {bagtypes 5}}
safeContentsBag BAG-TYPE ::=
{SafeContents IDENTIFIED BY {bagtypes 6}}
PKCS12BagSet BAG-TYPE ::= {
keyBag |
pkcs8ShroudedKeyBag |
certBag |
crlBag |
secretBag |
safeContentsBag,
... -- For future extensions
}
PKCS12BagSet BAG-TYPE ::= {
keyBag |
pkcs8ShroudedKeyBag |
certBag |
crlBag |
secretBag |
safeContentsBag,
... -- For future extensions
}
As new bag types become recognized in future versions of this standard, the PKCS12BagSet may be extended.
随着新的行李类型在本标准的未来版本中得到认可，PKCS12BagSet可能会扩展。
A KeyBag is a PKCS #8 PrivateKeyInfo. Note that a KeyBag contains only one private key.
钥匙袋是PKCS#8 PrivateKeyInfo。请注意，KeyBag只包含一个私钥。
KeyBag ::= PrivateKeyInfo
KeyBag ::= PrivateKeyInfo
A PKCS8ShroudedKeyBag holds a private key, which has been shrouded in accordance with PKCS #8. Note that a PKCS8ShroudedKeyBag holds only one shrouded private key.
PKCS8CovertedKeyBag持有私钥，私钥已根据PKCS#8进行了保护。请注意，PKCS8CovertedKeyBag仅持有一个Coverted私钥。
PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo
PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo
A CertBag contains a certificate of a certain type. Object identifiers are used to distinguish between different certificate types.
CertBag包含某种类型的证书。对象标识符用于区分不同的证书类型。
CertBag ::= SEQUENCE {
certId BAG-TYPE.&id ({CertTypes}),
certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
}
CertBag ::= SEQUENCE {
certId BAG-TYPE.&id ({CertTypes}),
certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
}
x509Certificate BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {certTypes 1}}
-- DER-encoded X.509 certificate stored in OCTET STRING
sdsiCertificate BAG-TYPE ::=
{IA5String IDENTIFIED BY {certTypes 2}}
-- Base64-encoded SDSI certificate stored in IA5String
x509Certificate BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {certTypes 1}}
-- DER-encoded X.509 certificate stored in OCTET STRING
sdsiCertificate BAG-TYPE ::=
{IA5String IDENTIFIED BY {certTypes 2}}
-- Base64-encoded SDSI certificate stored in IA5String
CertTypes BAG-TYPE ::= {
x509Certificate |
CertTypes BAG-TYPE ::= {
x509Certificate |
sdsiCertificate, ... -- For future extensions }
SDSIC证书对于将来的扩展}
A CRLBag contains a Certificate Revocation List (CRL) of a certain type. Object identifiers are used to distinguish between different CRL types.
CRLBag包含特定类型的证书吊销列表（CRL）。对象标识符用于区分不同的CRL类型。
CRLBag ::= SEQUENCE {
crlId BAG-TYPE.&id ({CRLTypes}),
crlValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
}
CRLBag ::= SEQUENCE {
crlId BAG-TYPE.&id ({CRLTypes}),
crlValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
}
x509CRL BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {crlTypes 1}}
-- DER-encoded X.509 CRL stored in OCTET STRING
x509CRL BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {crlTypes 1}}
-- DER-encoded X.509 CRL stored in OCTET STRING
CRLTypes BAG-TYPE ::= {
x509CRL,
... -- For future extensions
}
CRLTypes BAG-TYPE ::= {
x509CRL,
... -- For future extensions
}
Each of the user's miscellaneous personal secrets is contained in an instance of SecretBag, which holds an object identifier-dependent value. Note that a SecretBag contains only one secret.
用户的每个杂项个人秘密都包含在SecretBag实例中，该实例包含一个依赖于对象标识符的值。请注意，SecretBag只包含一个秘密。
SecretBag ::= SEQUENCE {
secretTypeId BAG-TYPE.&id ({SecretTypes}),
secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
{@secretTypeId})
}
SecretBag ::= SEQUENCE {
secretTypeId BAG-TYPE.&id ({SecretTypes}),
secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
{@secretTypeId})
}
SecretTypes BAG-TYPE ::= {
... -- For future extensions
}
SecretTypes BAG-TYPE ::= {
... -- For future extensions
}
Implementers can add values to this set at their own discretion.
实现者可以自行决定向该集合添加值。
The sixth type of bag that can be held in a SafeBag is a SafeContents. This recursive structure allows for arbitrary nesting of multiple KeyBags, PKCS8ShroudedKeyBags, CertBags, CRLBags, and SecretBags within the top-level SafeContents.
第六种可以放在安全袋中的袋子是安全内容物。这种递归结构允许在顶级安全内容中任意嵌套多个密钥包、PKCS8CovertedKeyBags、CertBags、CRLBAG和SecretBags。
This section describes the creation and usage of PFX PDUs.
本节介绍PFX PDU的创建和使用。
The steps for creating PFX PDUs are as follows.
创建PFX PDU的步骤如下所示。
1. It is somewhat clear from the ASN.1 how to make a number of instances of SafeContents, each containing a number of (possibly nested) instances of SafeBag. Let us assume, therefore, a number of instances SC_1, SC_2,..., SC_n of SafeContents. Note that there can be a more or less arbitrary number of instances of SafeContents in a PFX PDU. As will be seen in step 2, each instance can be encrypted (or not) separately.
1. 从ASN.1中可以清楚地看出，如何创建多个SafeContents实例，每个实例都包含多个（可能是嵌套的）SafeBag实例。因此，让我们假设安全内容的多个实例SC_1、SC_2、…、SC_n。请注意，在PFX PDU中，SafeContents的实例数量可以或多或少任意。如步骤2所示，每个实例都可以单独加密（或不加密）。
2. For each SCI, depending on the chosen encryption option,
2. 对于每个SCI，根据选择的加密选项，
A. If SC_i is not to be encrypted, make a ContentInfo CI_i holding content type Data. The contents of the Data OCTET STRING shall be a BER-encoding of SC_i (including tag, length, and value octets).
A.如果不加密SC_i，则制作一个包含内容类型数据的ContentInfo CI_i。数据八位字节字符串的内容应为SC_i的BER编码（包括标签、长度和值八位字节）。
B. If SC_i is to be encrypted with a password, make a ContentInfo CI_i of type EncryptedData. The encryptedContentInfo field of CI_i has its contentType field set to data and its encryptedContent field set to the encryption of the BER-encoding of SC_i (note that the tag and length octets shall be present).
B.如果要使用密码对SC_i进行加密，则制作EncryptedData类型的ContentInfo CI_i。CI_i的encryptedContentInfo字段的contentType字段设置为data，encryptedContent字段设置为SC_i的BER编码的加密（注意，标签和长度八位字节应存在）。
C. If SC_i is to be encrypted with a public key, make a ContentInfo CI_i of type EnvelopedData in essentially the same fashion as the EncryptedData ContentInfo was made in B.
C.如果要使用公钥对SC_i进行加密，则制作EnvelopedData类型的ContentInfo CI_i，其方式与B中制作的EncryptedData ContentInfo基本相同。
3. Make an instance of AuthenticatedSafe by stringing together the CI_i's in a SEQUENCE.
3. 通过将CI_i按顺序串在一起，创建AuthenticatedSafe的实例。
4. Make a ContentInfo T holding content type Data. The contents of the Data OCTET STRING shall be a BER-encoding of the AuthenticatedSafe value (including tag, length, and value octets).
4. 制作包含内容类型数据的ContentInfo T。数据八位字节字符串的内容应为认证安全值（包括标签、长度和值八位字节）的BER编码。
5. For integrity protection,
5. 为了保护完整性，
A. If the PFX PDU is to be authenticated with a digital signature, make a ContentInfo C of type SignedData. The contentInfo field of the SignedData in C has T in it. C is the ContentInfo in the top-level PFX structure.
A.如果要使用数字签名对PFX PDU进行身份验证，请制作SignedData类型的ContentInfo C。C中签名数据的contentInfo字段中有T。C是顶级PFX结构中的ContentInfo。
B. If the PFX PDU is to be authenticated with HMAC, then an HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 is computed on the contents of the Data in T (i.e., excluding the OCTET STRING tag and length bytes). This is exactly what would be initially digested in step 5A if public-key authentication were being used.
B.如果要使用HMAC对PFX PDU进行身份验证，则根据T中的数据内容（即，不包括八位字节字符串标签和长度字节）计算具有SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224或SHA-512/256的HMAC。如果使用公钥身份验证，这正是步骤5A中最初消化的内容。
Importation from a PFX is accomplished essentially by reversing the procedure for creating a PFX. In general, when an application imports keys, etc., from a PFX, it should ignore any object identifiers that it is not familiar with. At times, it may be appropriate to alert the user to the presence of such object identifiers.
从PFX导入基本上是通过颠倒创建PFX的程序来完成的。通常，当应用程序从PFX导入密钥等时，它应该忽略它不熟悉的任何对象标识符。有时，可以适当地提醒用户存在这样的对象标识符。
Special care may be taken by the application when importing an item in the PFX would require overwriting an item that already exists locally. The behavior of the application when such an item is encountered may depend on what the item is (i.e., it may be that a PKCS #8-shrouded private key and a CRL should be treated differently here). Appropriate behavior may be to ask the user what action should be taken for this item.
当在PFX中导入项目需要覆盖本地已存在的项目时，应用程序可能会特别小心。遇到此类项时，应用程序的行为可能取决于该项是什么（即，这里可能对PKCS#8-覆盖私钥和CRL的处理方式有所不同）。适当的行为可能是询问用户应该对此项目采取什么措施。
When using passwords in privacy or integrity mode, it needs to be considered that password-based cryptography is generally limited in the security that it can provide, particularly for methods such as those defined in this document where off-line password search is possible. While the use of salt and iteration count can increase the complexity of attack, it is essential that passwords are selected well and that relevant guidelines (e.g., NIST SP 800-61-1) are taken into account. It is also important that passwords be protected well if stored.
在隐私或完整性模式下使用密码时，需要考虑的是，基于密码的加密通常在其可提供的安全性方面受到限制，特别是对于本文档中定义的方法，其中可以进行离线密码搜索。虽然使用salt和迭代计数会增加攻击的复杂性，但必须选择好密码，并考虑相关指南（如NIST SP 800-61-1）。同样重要的是，如果存储了密码，则应妥善保护密码。
When choosing a salt value in password privacy or integrity mode, the recommendations in Section 4 of PKCS #5 2.1 [13] [22] should be taken into account. Ideally, the salt is as long as the output of the hash function being used and consists of randomly generated data.
在密码隐私或完整性模式下选择salt值时，应考虑PKCS#5 2.1[13][22]第4节中的建议。理想情况下，salt与正在使用的哈希函数的输出一样长，并且由随机生成的数据组成。
[1] Dobbertin, H., "The status of MD5 after a recent attack.", CryptoBytes Vol. 2, #2, 1996.
[1] Dobbertin，H.，“最近一次攻击后MD5的状态”，《加密字节》第2卷，第2期，1996年。
[2] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Specification of basic notation", ISO/IEC 8824-1:2008, 2008.
[2] ISO/IEC，“信息技术——抽象语法符号一（ASN.1）——基本符号规范”，ISO/IEC 8824-1:2008，2008。
[3] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Information object specification", ISO/IEC 8824-2:2008, 2008.
[3] ISO/IEC，“信息技术——抽象语法符号1（ASN.1）——信息对象规范”，ISO/IEC 8824-2:2008，2008。
[4] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Constraint specification", ISO/IEC 88247-3:2008, 2008.
[4] ISO/IEC，“信息技术——抽象语法符号一（ASN.1）——约束规范”，ISO/IEC 88247-3:2008，2008。
[5] ISO/IEC, "Information technology -- Abstract Syntax Notation One (ASN.1) -- Parameterization of ASN.1 specifications", ISO/IEC 8824-4:2008, 2008.
[5] ISO/IEC，“信息技术——抽象语法符号1（ASN.1）——ASN.1规范的参数化”，ISO/IEC 8824-4:2008，2008。
[6] ISO/IEC, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules", ISO/IEC 8825-1:2008, 2008.
[6] ISO/IEC，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则规范”，ISO/IEC 8825-1:2008。
[7] ISO/IEC, "Information technology -- Open Systems Interconnection -- The Directory: Models", ISO/IEC 9594-2:1997, 1997.
[7] ISO/IEC，“信息技术——开放系统互连——目录：模型”，ISO/IEC 9594-2:1997，1997。
[8] ISO/IEC, "Information technology -- Open Systems Interconnection -- The Directory: Authentication Framework", ISO/IEC 9594-8:1997, 1997.
[8] ISO/IEC，“信息技术——开放系统互连——目录：认证框架”，ISO/IEC 9594-8:1997，1997。
[9] Microsoft, "PFX: Personal Exchange Syntax and Protocol Standard", ISO/IEC Version 0.020, January 1997.
[9] 微软，“PFX：个人交换语法和协议标准”，ISO/IEC版本0.020，1997年1月。
[10] National Institute of Standards and Technology (NIST), "Secure Hash Standard", FIPS Publication 180-4, March 2012.
[10] 国家标准与技术研究所（NIST），“安全哈希标准”，FIPS出版物180-42012年3月。
[11] National Institute of Standards and Technology (NIST), "The Keyed-Hash Message Authentication Code (HMAC)", FIPS Publication 198-1, July 2008.
[11] 国家标准与技术研究所（NIST），“密钥散列消息认证码（HMAC）”，FIPS出版物198-12008年7月。
[12] National Institute of Standards and Technology (NIST), "The Recommendation for Password-Based Key Derivation, Part 1: Storage Applications", NIST Special Publication 800-132, December 2010.
[12] 国家标准与技术研究所（NIST），“基于密码的密钥推导建议，第1部分：存储应用”，NIST特别出版物800-132，2010年12月。
[13] RSA Laboratories, "PKCS #5: Password-Based Encryption Standard", PKCS Version 2.1, October 2012.
[13] RSA Laboratories，“PKCS#5：基于密码的加密标准”，PKCS 2.1版，2012年10月。
[14] RSA Laboratories, "PKCS #7: Cryptographic Message Syntax Standard", PKCS Version 1.5, November 1993.
[14] RSA实验室，“PKCS#7：加密消息语法标准”，PKCS版本1.5，1993年11月。
[15] RSA Laboratories, "PKCS #8: Private-Key Information Syntax Standard", PKCS Version 1.2, November 1993.
[15] RSA实验室，“PKCS#8：私钥信息语法标准”，PKCS版本1.2，1993年11月。
[16] RSA Laboratories, "PKCS #12: Personal Information Exchange Syntax", PKCS Version 1.1, December 2012.
[16] RSA实验室，“PKCS#12：个人信息交换语法”，PKCS版本1.11912年12月。
[17] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed Security Infrastructure", 1996, <http://people.csail.mit.edu/rivest/sdsi10.html>.
[17] Rivest，R.和B.Lampson，“SDSI-一个简单的分布式安全基础设施”，1996年<http://people.csail.mit.edu/rivest/sdsi10.html>.
[18] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, March 2011.
[18] Turner，S.和L.Chen，“MD2历史地位”，RFC 61492011年3月。
[19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[19] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[20] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[20] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[21] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[21] Kaliski，B.，“PKCS#7：加密消息语法版本1.5”，RFC 2315，1998年3月。
[22] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[22] Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 28982000年9月。
[23] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[23] Nystrom，M.和B.Kaliski，“PKCS#9：选定对象类和属性类型版本2.0”，RFC 29852000年11月。
[24] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010.
[24] Turner，S.，“非对称密钥包”，RFC 5958，2010年8月。
[25] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[25] Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
Appendix A. Message Authentication Codes (MACs)
附录A.报文认证码（MAC）
A MAC is a special type of function of a message (data bits) and an integrity key. It can be computed or checked only by someone possessing both the message and the integrity key. Its security follows from the secrecy of the integrity key. In this standard, MACing is used in password integrity mode.
MAC是消息（数据位）和完整性密钥的一种特殊功能。它只能由同时拥有消息和完整性密钥的人计算或检查。它的安全性源于完整性密钥的保密性。在本标准中，MACing用于密码完整性模式。
This document uses a particular type of MAC called HMAC [11] [20], which can be constructed from any of a variety of hash functions. Note that the specifications in [20] and [11] differ somewhat from the specification in [9]. The hash function HMAC is based on is identified in the MacData, which holds the MAC; for this version of this standard, the hash function can be one of the following: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 [10]. As indicated in Appendix B.4, this structure implies that the same hash algorithm must be used to derive the MAC key itself in password integrity mode and that the MAC key has either 160, 224, 256, 384, or 512 bits.
本文档使用一种称为HMAC[11][20]的特定类型的MAC，它可以由各种散列函数中的任何一种构造而成。请注意，[20]和[11]中的规范与[9]中的规范有所不同。hash函数HMAC基于MacData中标识的数据，该数据保存MAC；对于本标准的此版本，哈希函数可以是以下函数之一：SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224或SHA-512/256[10]。如附录B.4所示，该结构意味着必须使用相同的哈希算法在密码完整性模式下导出MAC密钥本身，并且MAC密钥具有160、224、256、384或512位。
When password integrity mode is used to secure a PFX PDU, an HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 is computed on the BER-encoding of the contents of the content field of the authSafe field in the PFX PDU (see Section 5.1).
当密码完整性模式用于保护PFX PDU时，根据PFX PDU中authSafe字段的内容字段的BER编码计算具有SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224或SHA-512/256的HMAC（参见第5.1节）。
Note that this method for password privacy mode is not recommended and is deprecated for new usage. The procedures and algorithms defined in PKCS #5 v2.1 [13] [22] should be used instead. Specifically, PBES2 should be used as encryption scheme, with PBKDF2 as the key derivation function.
请注意，不建议将此方法用于密码隐私模式，并且不推荐用于新用途。应使用PKCS#5 v2.1[13][22]中定义的程序和算法。具体来说，应该使用PBES2作为加密方案，使用PBKDF2作为密钥派生函数。
The method presented here is still used to generate the key in password integrity mode.
这里介绍的方法仍然用于在密码完整性模式下生成密钥。
We present here a general method for using a hash function to produce various types of pseudorandom bits from a password and a string of salt bits. This method is used for password privacy mode and password integrity mode in the present standard.
我们在这里介绍了一种使用哈希函数从密码和盐位字符串生成各种类型的伪随机位的通用方法。此方法用于本标准中的密码隐私模式和密码完整性模式。
The underlying password-based encryption methods in PKCS #5 v2.1 view passwords (and salt) as being simple byte strings. The underlying password-based encryption methods and the underlying password-based authentication methods in this version of this document are similar.
PKCS#5 v2.1中基于密码的底层加密方法将密码（和salt）视为简单的字节字符串。本文档版本中的基本基于密码的加密方法和基本基于密码的身份验证方法类似。
What's left unspecified in the above paragraph is precisely where the byte string representing a password comes from. (This is not an issue with salt strings, since they are supplied as a password-based encryption (or authentication) parameter.) PKCS #5 v2.1 says: "[...] a password is considered to be an octet string of arbitrary length whose interpretation as a text string is unspecified. In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 are two possibilities."
在上面的段落中，没有明确说明的就是表示密码的字节字符串的来源。（这不是salt字符串的问题，因为它们是作为基于密码的加密（或身份验证）参数提供的。）PKCS#5 v2.1说：“[…]密码被视为任意长度的八位字节字符串，其解释为文本字符串未指定。但是，为了互操作性，建议应用程序遵循一些常见的文本编码规则。ASCII和UTF-8是两种可能。”
In this specification, however, all passwords are created from BMPStrings with a NULL terminator. This means that each character in the original BMPString is encoded in 2 bytes in big-endian format (most-significant byte first). There are no Unicode byte order marks. The 2 bytes produced from the last character in the BMPString are followed by 2 additional bytes with the value 0x00.
但是，在本规范中，所有密码都是从带有空终止符的BMPString创建的。这意味着原始BMPString中的每个字符都以大端字节格式编码为2个字节（首先是最高有效字节）。没有Unicode字节顺序标记。从BMPString中的最后一个字符生成的2个字节后面跟着另外2个值为0x00的字节。
To illustrate with a simple example, if a user enters the 6-character password "Beavis", the string that PKCS #12 implementations should treat as the password is the following string of 14 bytes:
用一个简单的例子说明，如果用户输入6个字符的密码“Beavis”，PKCS#12实现应视为密码的字符串是以下14字节的字符串：
0x00 0x42 0x00 0x65 0x00 0x61 0x00 0x76 0x00 0x69 0x00 0x73 0x00 0x00
0x00 0x42 0x00 0x00 0x65 0x00 0x61 0x00 0x76 0x00 0x69 0x00 0x73 0x00 0x00 0x00
Let H be a hash function built around a compression function f:
设H是围绕压缩函数f构建的哈希函数：
Z_2^u x Z_2^v -> Z_2^u
Z_2^u x Z_2^v -> Z_2^u
(that is, H has a chaining variable and output of length u bits, and the message input to the compression function of H is v bits). The values for u and v are as follows:
（即，H有一个链式变量，输出长度为u位，H的压缩功能的消息输入为v位）。u和v的值如下所示：
HASH FUNCTION VALUE u VALUE v MD2, MD5 128 512 SHA-1 160 512 SHA-224 224 512 SHA-256 256 512 SHA-384 384 1024 SHA-512 512 1024 SHA-512/224 224 1024 SHA-512/256 256 1024
散列函数值u值v MD2，MD5 128 512 SHA-1 160 512 SHA-224 224 512 SHA-256 256 512 SHA-384 384 1024 SHA-512 512 1024 SHA-512/224 224 1024 SHA-512/256 256 256 1024
Furthermore, let r be the iteration count.
此外，设r为迭代计数。
We assume here that u and v are both multiples of 8, as are the lengths of the password and salt strings (which we denote by p and s, respectively) and the number n of pseudorandom bits required. In addition, u and v are of course non-zero.
这里我们假设u和v都是8的倍数，密码和salt字符串的长度（我们分别用p和s表示）以及所需的伪随机比特数n也是8的倍数。此外，u和v当然是非零的。
For information on security considerations for MD5 [19], see [25] and [1], and on those for MD2, see [18].
有关MD5[19]的安全注意事项的信息，请参见[25]和[1]，有关MD2的安全注意事项的信息，请参见[18]。
The following procedure can be used to produce pseudorandom bits for a particular "purpose" that is identified by a byte called "ID". The meaning of this ID byte will be discussed later.
以下过程可用于产生用于特定“目的”的伪随机位，该目的由称为“ID”的字节标识。稍后将讨论此ID字节的含义。
1. Construct a string, D (the "diversifier"), by concatenating v/8 copies of ID.
1. 通过连接ID的v/8个副本来构造字符串D（“diversifier”）。
2. Concatenate copies of the salt together to create a string S of length v(ceiling(s/v)) bits (the final copy of the salt may be truncated to create S). Note that if the salt is the empty string, then so is S.
2. 将salt的副本连接在一起以创建长度为v（上限（S/v））位的字符串S（salt的最终副本可能会被截断以创建S）。注意，如果salt是空字符串，那么S也是空字符串。
3. Concatenate copies of the password together to create a string P of length v(ceiling(p/v)) bits (the final copy of the password may be truncated to create P). Note that if the password is the empty string, then so is P.
3. 将密码副本连接在一起，以创建长度为v（上限（P/v））位的字符串P（密码的最终副本可能会被截断以创建P）。注意，如果密码是空字符串，那么P也是空字符串。
4. Set I=S||P to be the concatenation of S and P.
4. 将I=S | | P设置为S和P的串联。
5. Set c=ceiling(n/u).
5. 设置c=天花板（n/u）。
6. For i=1, 2, ..., c, do the following:
6. 对于i=1，2，…，c，请执行以下操作：
A. Set A2=H^r(D||I). (i.e., the r-th hash of D||1,
H(H(H(... H(D||I))))
A. Set A2=H^r(D||I). (i.e., the r-th hash of D||1,
H(H(H(... H(D||I))))
B. Concatenate copies of Ai to create a string B of length v bits (the final copy of Ai may be truncated to create B).
B.连接Ai的副本以创建长度为v位的字符串B（Ai的最终副本可能被截断以创建B）。
C. Treating I as a concatenation I_0, I_1, ..., I_(k-1) of v-bit blocks, where k=ceiling(s/v)+ceiling(p/v), modify I by setting I_j=(I_j+B+1) mod 2^v for each j.
C.将I视为v位块的串联I_0，I_1，…，I_（k-1），其中k=上限（s/v）+上限（p/v），通过为每个j设置I_j=（I_j+B+1）mod 2^v来修改I。
7. Concatenate A_1, A_2, ..., A_c together to form a pseudorandom bit string, A.
7. 将A_1、A_2、…、A_c连接在一起以形成伪随机比特串A。
8. Use the first n bits of A as the output of this entire process.
8. 使用A的前n位作为整个过程的输出。
If the above process is being used to generate a DES key, the process should be used to create 64 random bits, and the key's parity bits should be set after the 64 bits have been produced. Similar concerns hold for 2-key and 3-key triple-DES keys, for CDMF keys, and for any similar keys with parity bits "built into them".
如果上述过程用于生成DES密钥，则该过程应用于创建64个随机位，并且应在生成64位后设置密钥的奇偶校验位。对于2键和3键三重DES键、CDMF键以及“内置”奇偶校验位的任何类似键，也存在类似的问题。
This standard specifies 3 different values for the ID byte mentioned above:
本标准规定了上述ID字节的3个不同值：
1. If ID=1, then the pseudorandom bits being produced are to be used as key material for performing encryption or decryption.
1. 如果ID＝1，则产生的伪随机比特将用作执行加密或解密的密钥材料。
2. If ID=2, then the pseudorandom bits being produced are to be used as an IV (Initial Value) for encryption or decryption.
2. 如果ID＝2，则产生的伪随机比特将用作用于加密或解密的IV（初始值）。
3. If ID=3, then the pseudorandom bits being produced are to be used as an integrity key for MACing.
3. 如果ID=3，则生成的伪随机位将用作MACing的完整性密钥。
When password integrity mode is used to protect a PFX PDU, a password and salt are used to derive a MAC key. As with password privacy mode, the password is a Unicode string, and the salt is a byte string. No particular lengths are prescribed in this standard for either the password or the salt, but the general advice about passwords and salt that is given in Appendix C applies here, as well.
当密码完整性模式用于保护PFX PDU时，密码和salt用于派生MAC密钥。与密码隐私模式一样，密码是Unicode字符串，salt是字节字符串。本标准中未规定密码或salt的具体长度，但附录C中给出的关于密码和salt的一般建议也适用于此处。
The hash function used to derive MAC keys is whatever hash function is going to be used for MACing. The MAC keys that are derived have the same length as the hash function's output. In this version of this standard, SHA-1, SHA-224, SHA-256, SHA384, SHA-512, SHA-512/224, or SHA/512/256 can be used to perform MACing, and so the MAC keys can be 160, 224, 256, 384, or 512 bits. See Appendix A for more information on MACing.
用于派生MAC密钥的哈希函数是用于MAC的任何哈希函数。派生的MAC密钥与哈希函数的输出具有相同的长度。在此版本的本标准中，可以使用SHA-1、SHA-224、SHA-256、SHA384、SHA-512、SHA-512/224或SHA/512/256执行MAC，因此MAC密钥可以是160、224、256、384或512位。有关MACing的更多信息，请参见附录A。
As stated at the start of Appendix B, use of this method for password privacy mode is not recommended; this specification of keys and IVs for password privacy mode is retained for backwards compatibility with PKCS #12 v1.0 only.
如附录B开头所述，不建议将此方法用于密码隐私模式；此密码隐私模式密钥和IVs规范仅为向后兼容PKCS#12 v1.0而保留。
When password privacy mode is used to encrypt a PFX PDU, a password (typically entered by the user), a salt and an iteration parameter are used to derive a key (and an IV, if necessary). The password is
当密码隐私模式用于加密PFX PDU时，密码（通常由用户输入）、salt和迭代参数用于导出密钥（以及IV，如有必要）。密码是
a Unicode string, and as such, each character in it is represented by 2 bytes. The salt is a byte string and so can be represented directly as a sequence of bytes.
Unicode字符串，因此，其中的每个字符由2个字节表示。salt是一个字节字符串，因此可以直接表示为一个字节序列。
This standard does not prescribe a length for the password. As usual, however, too short a password might compromise privacy. A particular application might well require a user-entered privacy password for creating a PFX PDU to have a password exceeding some specific length.
本标准未规定密码的长度。然而，像往常一样，密码太短可能会损害隐私。特定的应用程序可能需要用户输入隐私密码来创建PFX PDU，以使密码超过某个特定长度。
This standard does not prescribe a length for the salt either. Ideally, the salt is as long as the output of the hash function being used and consists of completely random bits.
本标准也没有规定盐的长度。理想情况下，salt与所使用的哈希函数的输出一样长，并且由完全随机的位组成。
The iteration count is recommended to be 1024 or more. (See [22] and [13] for more information.)
建议迭代计数为1024或更多。（有关更多信息，请参见[22]和[13]）
The PBES1 encryption scheme defined in PKCS #5 provides a number of algorithm identifiers for deriving keys and IVs; here, we specify a few more, all of which use the procedure detailed in Appendices B.2 and B.3 to construct keys (and IVs, where needed). As is implied by their names, all of the object identifiers below use the hash function SHA-1.
PKCS#5中定义的PBES1加密方案提供了许多用于派生密钥和IVs的算法标识符；在这里，我们还指定了一些，所有这些都使用附录B.2和B.3中详述的程序来构造键（和IVs，如需要）。正如它们的名称所暗示的那样，下面的所有对象标识符都使用哈希函数SHA-1。
pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1}
pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}
pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1}
pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}
Each of the six PBE object identifiers above has the following ASN.1 type for parameters:
上述六个PBE对象标识符中的每一个都有以下ASN.1类型的参数：
pkcs-12PbeParams ::= SEQUENCE {
salt OCTET STRING,
iterations INTEGER
}
pkcs-12PbeParams ::= SEQUENCE {
salt OCTET STRING,
iterations INTEGER
}
The pkcs-12PbeParams holds the salt that is used to generate the key (and IV, if necessary) and the number of iterations to carry out.
pkcs-12PbeParams保存用于生成密钥（和IV，如有必要）的salt以及要执行的迭代次数。
Note that the first two algorithm identifiers above (the algorithm identifiers for RC4) only derive keys; it is unnecessary to derive an IV for RC4.
注意，上面的前两个算法标识符（RC4的算法标识符）仅派生密钥；无需推导RC4的IV。
This section is here for two reasons: first, to enable backwards compatibility as described in the first paragraph of this section; second, because it is still used in password integrity mode. In order to not use it in password integrity mode, the ASN.1 definitions require updates. This document recommends that future definitions of the PFX structure replace the existing MacData object, optionally present in password integrity mode, with a new object definition that holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication scheme. This change would simplify the requirements for key derivation functions used across all parts of the PFX structure.
本节之所以在这里有两个原因：第一，如本节第一段所述，实现向后兼容性；第二，因为它仍然在密码完整性模式下使用。为了不在密码完整性模式下使用它，ASN.1定义需要更新。本文件建议，PFX结构的未来定义将现有的MacData对象（可选地以密码完整性模式存在）替换为新的对象定义，该对象定义包含基于PKCS#5[13][22]PBMAC1消息身份验证方案的MAC。这一变化将简化PFX结构所有部分中使用的关键派生函数的要求。
This appendix documents all ASN.1 types, values, and object sets defined in this specification. It does so by providing an ASN.1 module called PKCS-12.
本附录记录了本规范中定义的所有ASN.1类型、值和对象集。它通过提供一个名为PKCS-12的ASN.1模块来实现这一点。
PKCS-12 {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-12(12)
modules(0) pkcs-12(1)}
PKCS-12 {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-12(12)
modules(0) pkcs-12(1)}
-- PKCS #12 v1.1 ASN.1 Module
-- Revised October 27, 2012
-- PKCS #12 v1.1 ASN.1 Module
-- Revised October 27, 2012
-- This module has been checked for conformance with the ASN.1 standard
-- by the OSS ASN.1 Tools
-- This module has been checked for conformance with the ASN.1 standard
-- by the OSS ASN.1 Tools
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL
-- All types and values defined in this module are exported for use
-- in other ASN.1 modules.
-- EXPORTS ALL
-- All types and values defined in this module are exported for use
-- in other ASN.1 modules.
IMPORTS
进口
informationFramework
FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
usefulDefinitions(0) 3}
informationFramework
FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
usefulDefinitions(0) 3}
ATTRIBUTE FROM InformationFramework informationFramework
来自InformationFramework的属性InformationFramework
ContentInfo, DigestInfo
FROM PKCS-7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-7(7) modules(0) pkcs-7(1)}
ContentInfo, DigestInfo
FROM PKCS-7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-7(7) modules(0) pkcs-7(1)}
PrivateKeyInfo, EncryptedPrivateKeyInfo
FROM PKCS-8 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-8(8) modules(1) pkcs-8(1)}
PrivateKeyInfo, EncryptedPrivateKeyInfo
FROM PKCS-8 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-8(8) modules(1) pkcs-8(1)}
pkcs-9, friendlyName, localKeyId, certTypes, crlTypes
FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) modules(0) pkcs-9(1)};
pkcs-9, friendlyName, localKeyId, certTypes, crlTypes
FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) modules(0) pkcs-9(1)};
-- ============================
-- Object identifiers
-- ============================
-- ============================
-- Object identifiers
-- ============================
rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549)}
pkcs OBJECT IDENTIFIER ::= {rsadsi pkcs(1)}
pkcs-12 OBJECT IDENTIFIER ::= {pkcs 12}
pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1}
pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}
rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549)}
pkcs OBJECT IDENTIFIER ::= {rsadsi pkcs(1)}
pkcs-12 OBJECT IDENTIFIER ::= {pkcs 12}
pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1}
pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1}
pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2}
pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3}
pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4}
pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5}
pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}
bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}
bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1}
-- ============================
-- The PFX PDU
-- ============================
-- ============================
-- The PFX PDU
-- ============================
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
PFX ::= SEQUENCE {
version INTEGER {v3(3)}(v3,...),
authSafe ContentInfo,
macData MacData OPTIONAL
}
MacData ::= SEQUENCE {
mac DigestInfo,
macSalt OCTET STRING,
iterations INTEGER DEFAULT 1
-- Note: The default is for historical reasons and its use is
-- deprecated.
}
MacData ::= SEQUENCE {
mac DigestInfo,
macSalt OCTET STRING,
iterations INTEGER DEFAULT 1
-- Note: The default is for historical reasons and its use is
-- deprecated.
}
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted
SafeContents ::= SEQUENCE OF SafeBag
SafeContents ::= SEQUENCE OF SafeBag
SafeBag ::= SEQUENCE {
bagId BAG-TYPE.&id ({PKCS12BagSet}),
bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
bagAttributes SET OF PKCS12Attribute OPTIONAL
}
SafeBag ::= SEQUENCE {
bagId BAG-TYPE.&id ({PKCS12BagSet}),
bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}),
bagAttributes SET OF PKCS12Attribute OPTIONAL
}
-- ============================
-- Bag types
-- ============================
-- ============================
-- Bag types
-- ============================
keyBag BAG-TYPE ::=
{KeyBag IDENTIFIED BY {bagtypes 1}}
pkcs8ShroudedKeyBag BAG-TYPE ::=
{PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
certBag BAG-TYPE ::=
{CertBag IDENTIFIED BY {bagtypes 3}}
crlBag BAG-TYPE ::=
{CRLBag IDENTIFIED BY {bagtypes 4}}
secretBag BAG-TYPE ::=
{SecretBag IDENTIFIED BY {bagtypes 5}}
safeContentsBag BAG-TYPE ::=
{SafeContents IDENTIFIED BY {bagtypes 6}}
keyBag BAG-TYPE ::=
{KeyBag IDENTIFIED BY {bagtypes 1}}
pkcs8ShroudedKeyBag BAG-TYPE ::=
{PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}
certBag BAG-TYPE ::=
{CertBag IDENTIFIED BY {bagtypes 3}}
crlBag BAG-TYPE ::=
{CRLBag IDENTIFIED BY {bagtypes 4}}
secretBag BAG-TYPE ::=
{SecretBag IDENTIFIED BY {bagtypes 5}}
safeContentsBag BAG-TYPE ::=
{SafeContents IDENTIFIED BY {bagtypes 6}}
PKCS12BagSet BAG-TYPE ::= {
keyBag |
pkcs8ShroudedKeyBag |
certBag |
crlBag |
secretBag |
safeContentsBag,
... -- For future extensions
}
PKCS12BagSet BAG-TYPE ::= {
keyBag |
pkcs8ShroudedKeyBag |
certBag |
crlBag |
secretBag |
safeContentsBag,
... -- For future extensions
}
BAG-TYPE ::= TYPE-IDENTIFIER
BAG-TYPE ::= TYPE-IDENTIFIER
-- KeyBag
KeyBag ::= PrivateKeyInfo
-- KeyBag
KeyBag ::= PrivateKeyInfo
-- Shrouded KeyBag
PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo
-- Shrouded KeyBag
PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo
-- CertBag
CertBag ::= SEQUENCE {
certId BAG-TYPE.&id ({CertTypes}),
certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
}
-- CertBag
CertBag ::= SEQUENCE {
certId BAG-TYPE.&id ({CertTypes}),
certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
}
x509Certificate BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {certTypes 1}}
-- DER-encoded X.509 certificate stored in OCTET STRING
sdsiCertificate BAG-TYPE ::=
{IA5String IDENTIFIED BY {certTypes 2}}
-- Base64-encoded SDSI certificate stored in IA5String
x509Certificate BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {certTypes 1}}
-- DER-encoded X.509 certificate stored in OCTET STRING
sdsiCertificate BAG-TYPE ::=
{IA5String IDENTIFIED BY {certTypes 2}}
-- Base64-encoded SDSI certificate stored in IA5String
CertTypes BAG-TYPE ::= {
x509Certificate |
sdsiCertificate,
... -- For future extensions
}
CertTypes BAG-TYPE ::= {
x509Certificate |
sdsiCertificate,
... -- For future extensions
}
-- CRLBag
CRLBag ::= SEQUENCE {
crlId BAG-TYPE.&id ({CRLTypes}),
crltValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
}
-- CRLBag
CRLBag ::= SEQUENCE {
crlId BAG-TYPE.&id ({CRLTypes}),
crltValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId})
}
x509CRL BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {crlTypes 1}}
-- DER-encoded X.509 CRL stored in OCTET STRING
x509CRL BAG-TYPE ::=
{OCTET STRING IDENTIFIED BY {crlTypes 1}}
-- DER-encoded X.509 CRL stored in OCTET STRING
CRLTypes BAG-TYPE ::= {
x509CRL,
... -- For future extensions
}
CRLTypes BAG-TYPE ::= {
x509CRL,
... -- For future extensions
}
-- Secret Bag
SecretBag ::= SEQUENCE {
secretTypeId BAG-TYPE.&id ({SecretTypes}),
secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
{@secretTypeId})
}
-- Secret Bag
SecretBag ::= SEQUENCE {
secretTypeId BAG-TYPE.&id ({SecretTypes}),
secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes}
{@secretTypeId})
}
SecretTypes BAG-TYPE ::= {
... -- For future extensions
}
SecretTypes BAG-TYPE ::= {
... -- For future extensions
}
-- ============================
-- Attributes
-- ============================
-- ============================
-- Attributes
-- ============================
PKCS12Attribute ::= SEQUENCE {
attrId ATTRIBUTE.&id ({PKCS12AttrSet}),
attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})
} -- This type is compatible with the X.500 type 'Attribute'
PKCS12Attribute ::= SEQUENCE {
attrId ATTRIBUTE.&id ({PKCS12AttrSet}),
attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId})
} -- This type is compatible with the X.500 type 'Attribute'
PKCS12AttrSet ATTRIBUTE ::= {
friendlyName |
localKeyId,
... -- Other attributes are allowed
}
PKCS12AttrSet ATTRIBUTE ::= {
friendlyName |
localKeyId,
... -- Other attributes are allowed
}
END
终止
EMC Corporation makes no patent claims on the general constructions described in this document, although specific underlying techniques may be covered.
EMC公司对本文档中描述的一般构造不提出任何专利要求，尽管可能涉及特定的底层技术。
RC2 and RC4 are trademarks of EMC Corporation.
RC2和RC4是EMC公司的商标。
EMC Corporation makes no representations regarding intellectual property claims by other parties. Such determination is the responsibility of the user.
EMC Corporation不对其他方的知识产权索赔作出任何陈述。此类确定由用户负责。
Many thanks to Dan Simon of Microsoft Corporation and Jim Spring of Netscape Communications Corporation for their assistance in preparing early drafts of this document. Especial thanks to Brian Beckman of Microsoft Corporation for writing the specification that this document is based on.
非常感谢微软公司的丹·西蒙和网景通信公司的吉姆·斯普林，感谢他们在编写本文件早期草稿时给予的帮助。特别感谢微软公司的Brian Beckman编写本文档所基于的规范。
Appendix G. About PKCS
附录G.关于PKCS
The Public-Key Cryptography Standards are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide for the purpose of accelerating the deployment of public-key cryptography. First published in 1991 as a result of meetings with a small group of early adopters of public-key technology, the PKCS documents have become widely referenced and implemented. Contributions from the PKCS series have become part of many formal and de facto standards, including ANSI X9 documents, PKIX, SET, S/ MIME, and SSL.
公钥加密标准是RSA实验室与全球安全系统开发人员合作制定的规范，旨在加速公钥加密的部署。PKCS文件于1991年首次出版，是与一小群早期采用公钥技术的人举行会议的结果。PKCS文件已被广泛引用和实施。PKCS系列的贡献已成为许多正式和事实标准的一部分，包括ANSI X9文档、PKIX、SET、S/MIME和SSL。
Further development of PKCS occurs through the IETF. Suggestions for improvement are welcome.
通过IETF进一步开发PKCS。欢迎提出改进建议。
Authors' Addresses
作者地址
Kathleen M. Moriarty (editor) EMC Corporation 176 South Street Hopkinton, MA United States
Kathleen M.Moriarty（编辑）美国马萨诸塞州霍普金顿南街176号EMC公司
EMail: Kathleen.Moriarty@emc.com
EMail: Kathleen.Moriarty@emc.com
Magnus Nystrom Microsoft Corporation 1 Microsoft Way Redmond, WA 98052 United States
美国华盛顿州雷德蒙微软路1号Magnus Nystrom微软公司，邮编：98052
EMail: mnystrom@microsoft.com
EMail: mnystrom@microsoft.com
Sean Parkinson RSA Security Inc. 345 Queen Street Brisbane, QLD, 4000 Australia
肖恩·帕金森RSA安全公司，地址：澳大利亚昆士兰州布里斯班皇后街345号，邮编：4000
EMail: Sean.Parkinson@rsa.com
EMail: Sean.Parkinson@rsa.com
Andreas Rusch RSA Security Inc. 345 Queen Street Brisbane, QLD, 4000 Australia
澳大利亚昆士兰州布里斯班皇后街345号Andreas Rusch RSA Security Inc.邮编：4000
EMail: Andreas.Rusch@rsa.com
EMail: Andreas.Rusch@rsa.com
Michael Scott RSA Security Inc. 345 Queen Street Brisbane, QLD, 4000 Australia
澳大利亚昆士兰州布里斯班皇后街345号Michael Scott RSA Security Inc.邮编：4000
EMail: Michael2.Scott@rsa.com
EMail: Michael2.Scott@rsa.com