Independent Submission S. Leonard
Request for Comments: 8351 Penango, Inc.
Category: Informational June 2018
ISSN: 2070-1721
Independent Submission S. Leonard
Request for Comments: 8351 Penango, Inc.
Category: Informational June 2018
ISSN: 2070-1721
The PKCS #8 EncryptedPrivateKeyInfo Media Type
PKCS#8 EncryptedPrivateKeyInfo媒体类型
Abstract
摘要
This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value.
本文档为PKCS#8的EncryptedPrivateKeyInfo类型注册application/pkcs8加密媒体类型。此媒体类型的实例携带单个加密私钥，BER编码为单个EncryptedPrivateKeyInfo值。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8351.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8351.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Registration Application . . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Registration Application . . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
The private key is encrypted with an encryption algorithm, which could be a password-based encryption scheme as that term is used in PKCS #5: Password-Based Cryptography Specification Version 2.1 as published in [RFC2898] and updated by [RFC8018]. This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8 (as originally described in [RFC5208], which was obsoleted by [RFC5958]). An instance of this media type carries a single encrypted private key [RFC5958] BER-encoded as a single EncryptedPrivateKeyInfo value.
私钥使用加密算法加密，加密算法可以是基于密码的加密方案，因为该术语在[RFC2898]中发布并由[RFC8018]更新的PKCS#5：基于密码的加密规范版本2.1中使用。本文档为PKCS#8的EncryptedPrivateKeyInfo类型注册了application/pkcs8加密媒体类型（如[RFC5208]中最初所述，该类型已被[RFC5958]淘汰）。此媒体类型的实例携带单个加密私钥[RFC5958]BER，编码为单个EncryptedPrivateKeyInfo值。
Type name: application
类型名称：应用程序
Subtype name: pkcs8-encrypted
子类型名称：pkcs8加密
Required parameters: None.
所需参数：无。
Optional parameters:
可选参数：
password-mapping: The private key is encrypted with an encryption algorithm, which could be a password-based encryption scheme as that term is used in PKCS #5 ([RFC2898] and [RFC8018]). Such algorithms take a password as input. A "password" is a secret text value (see Section 3 of [RFC2898] and [RFC8018]), but for algorithmic purposes the term "password" refers to an octet string (see Section 2 of [RFC2898] and [RFC8018]). Therefore, there must be some mapping between the text value (which might be user input) and the octet string. Section 3 of [RFC2898] (which was replaced by [RFC8018]) recommends "that applications follow some common text encoding rules"; it then offers, but does not recommend, ASCII and UTF-8.
密码映射：使用加密算法对私钥进行加密，该算法可以是基于密码的加密方案，因为PKCS#5（[RFC2898]和[RFC8018]）中使用了该术语。这种算法以密码作为输入。“密码”是一个秘密文本值（见[RFC2898]和[RFC8018]第3节），但出于算法目的，“密码”一词指八位字节字符串（见[RFC2898]和[RFC8018]第2节）。因此，文本值（可能是用户输入）和八位字节字符串之间必须存在某种映射。[RFC2898]的第3节（被[RFC8018]取代）建议“应用程序遵循一些通用的文本编码规则”；然后它提供但不推荐ASCII和UTF-8。
While many modern applications support Unicode and Unicode-based encodings such as UTF-8 and UTF-16, interchange is still needed with private key artifacts that are encrypted with passwords in other encodings. Therefore, this parameter specifies the charset (see Section 1.3 of [RFC2978]) that a recipient should attempt first, in "reverse", when mapping from a sequence of characters to an octet string. This parameter is not cryptographically protected, so recipients cannot rely on it as the exclusive mapping possibility.
虽然许多现代应用程序支持Unicode和基于Unicode的编码，如UTF-8和UTF-16，但仍然需要与私钥工件进行交换，这些工件在其他编码中使用密码进行加密。因此，当从字符序列映射到八位字节字符串时，此参数指定收件人应首先尝试的字符集（见[RFC2978]第1.3节），以“反向”的形式。此参数不受加密保护，因此收件人不能依赖它作为独占映射。
This parameter has similar semantics to the charset parameter from text/plain, except that it only applies to the user's input (text value) of a password. There is no default value.
此参数的语义与text/plain中的charset参数类似，只是它仅适用于用户输入的密码（文本值）。没有默认值。
The following special values, which all begin with "*" to distinguish them from registered charsets, are defined:
定义了以下特殊值，这些值均以“*”开头，以区别于已注册的字符集：
*pkcs12 UTF-16LE with U+0000 NULL terminator: PKCS #12 style, see [RFC7292].
*带U+0000零终止符的pkcs12 UTF-16LE:PKCS#12样式，请参见[RFC7292]。
*precis Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) password profile, i.e., OpaqueString from Section 4 of [RFC7613], which was obsoleted by [RFC8265]: always UTF-8 in Normalization Form C (NFC).
*国际化字符串（precis）密码配置文件的precis准备、实施和比较，即[RFC7613]第4节中的不透明字符串，已被[RFC8265]淘汰：始终采用规范化形式C（NFC）的UTF-8。
*precis-XXX Any profile from the IANA "PRECIS Profiles" registry where "XXX" is replaced by the profile name as shown in the registry.
*precis XXX IANA“precis Profiles”注册表中的任何配置文件，其中“XXX”由注册表中显示的配置文件名称替换。
*hex hexadecimal input: the input is mapped to 0-9, A-F, and then converted directly to octets. If there are an odd number of hex digits, either the final digit 0 is appended or an error condition is raised. Compare with Annex M.4 of [IEEE.802.11-2012].
*十六进制输入：输入映射到0-9，A-F，然后直接转换为八位字节。如果十六进制数字为奇数，则会追加最后一个数字0或引发错误条件。与[IEEE.802.11-2012]的附录M.4进行比较。
*dtmf The characters "0"-"9", "A"-"D", "*", and "#", which map to their corresponding ASCII codes. "A"-"D" map to the uppercase range 0x41 - 0x44. (This is to support restricted-input devices, i.e., telephones and telephone-like equipment.) User input outside of these values is either ignored or an error condition is raised.
*dtmf字符“0”-“9”、“A”-“D”、“*”和“#”映射到相应的ASCII码。“A”-“D”映射到大写范围0x41-0x44。（这是为了支持受限输入设备，即电话和类似电话的设备。）忽略这些值之外的用户输入，或引发错误条件。
Otherwise, the value of this parameter is a charset, from the IANA "Character Sets" registry [CHARREG].
否则，此参数的值是IANA“字符集”注册表[CHARREG]中的字符集。
This parameter is case insensitive.
此参数不区分大小写。
Encoding considerations: Binary.
编码注意事项：二进制。
Security considerations:
安全考虑：
Carries a cryptographic private key. See Section 6 of [RFC5958].
携带加密私钥。参见[RFC5958]第6节。
EncryptedPrivateKeyInfo PKCS #8 data contains exactly one private key. Poor password choices, weak algorithms, or improper parameter selections (e.g., insufficient salting rounds) will make the confidential payloads much easier to compromise.
EncryptedPrivateKeyInfo PKCS#8数据仅包含一个私钥。糟糕的密码选择、薄弱的算法或不正确的参数选择（例如，盐渍轮不足）将使机密有效载荷更容易泄露。
Interoperability considerations:
互操作性注意事项：
PKCS #8 is a widely recognized format for private key information on all modern cryptographic stacks. The contents are exactly one private key (with optional key attributes), so there is no possibility for hidden "Easter eggs" in the payload such as unexpected certificates or miscellaneous secrets.
PKCS#8是一种广泛认可的格式，用于所有现代密码栈上的私钥信息。内容正好是一个私钥（具有可选的密钥属性），因此不可能在有效负载中隐藏“复活节彩蛋”，例如意外的证书或其他机密。
The encrypted variation in this registration, EncryptedPrivateKeyInfo (Section 3, "Encrypted Private Key Info", of [RFC5958], and Section 6 of PKCS #8 as originally described in [RFC5208], which was obsoleted by [RFC5958]), is less widely used for exchange than PKCS #12, but it is much simpler to implement. Actually, PKCS #12 incorporates the PKCS #8 types, so a PKCS #12 processor ought to be able to process PKCS #8 data by embedding the PKCS #8 data in PKCS #12 "scaffolding".
此注册中的加密变体EncryptedPrivateKeyInfo（RFC5958的第3节“加密私钥信息”）和PKCS#8的第6节（如[RFC5208]中最初所述）在交换中的应用不如PKCS#12广泛，但实现起来要简单得多。实际上，PKCS#12包含PKCS#8类型，因此PKCS#12处理器应该能够通过将PKCS#8数据嵌入PKCS#12“支架”来处理PKCS#8数据。
The password-mapping parameter aids in interoperability when the creator (who encrypted the keying material) and the user (who is attempting to decrypt the keying material) are not operating in the same character-encoding environment. An anticipated scenario is that the creator may have created the keying material with a password in a Shift-JIS environment a long time ago, while the user is in a UTF-8 environment. There are potentially many Unicode sequences that code for the same abstract character, such as precomposed and decomposed forms; yet, such an abstract character (however coded in Unicode) will tend to map to one coding in the legacy charset, if it can be represented at all. Therefore, the password-mapping parameter will almost never be ambiguous when mapping to legacy encodings. When mapping from one Unicode form to another (such as an internal Unicode representation to *pkcs12), code sequences are either preserved or
当创建者（加密密钥材料的人）和用户（试图解密密钥材料的人）不在同一字符编码环境中操作时，密码映射参数有助于实现互操作性。一个预期的场景是，当用户处于UTF-8环境中时，创建者可能早就在Shift JIS环境中使用密码创建了密钥材料。可能有许多Unicode序列为相同的抽象字符编码，例如预合成和分解形式；然而，这样一个抽象字符（不管是用Unicode编码的）如果可以表示的话，将倾向于映射到遗留字符集中的一种编码。因此，在映射到传统编码时，密码映射参数几乎永远不会含糊不清。当从一个Unicode表单映射到另一个表单时（例如到*pkcs12的内部Unicode表示），代码序列要么保留要么删除
folded deterministically to common Unicode code points or sequences, producing the same holistic result as mapping to legacy encodings.
以确定方式折叠到通用Unicode代码点或序列，产生与映射到遗留编码相同的整体结果。
It is possible that an abstract character might map to multiple legacy encodings under the same charset. However, the possibility is sufficiently remote as to be ignored in this media type registration. One possible workaround is to set the user's (decrypting party's) local operating environment to the password-mapping legacy encoding parameter for the purpose of generating the password octet string from user input. Another possibility is to generate all possible legacy encoding combinations from the abstract text (i.e., Unicode text), attempting decryption with them. Customized behavior can be defined by updating this media type registration with a new password-mapping special value, prefixed with *.
一个抽象字符可能映射到同一字符集下的多个传统编码。然而，这种可能性非常遥远，在这种媒体类型注册中可以忽略。一种可能的解决方法是将用户（解密方）的本地操作环境设置为密码映射遗留编码参数，以便从用户输入生成密码八位组字符串。另一种可能性是从抽象文本（即Unicode文本）生成所有可能的遗留编码组合，并尝试使用它们进行解密。自定义行为可以通过使用新的密码映射特殊值（前缀为*）更新此媒体类型注册来定义。
Published specification:
已发布的规范：
RSA Laboratories PKCS #8 v1.2 RSA Encryption Standard, November 1993 (republished as [RFC5208], May 2008, and updated as [RFC5958], August 2010); RFC 5958, August 2010
RSA Laboratories PKCS#8 v1.2 RSA加密标准，1993年11月（2008年5月作为[RFC5208]重新发布，2010年8月更新为[RFC5958]）；RFC 59582010年8月
Applications that use this media type:
使用此媒体类型的应用程序：
Machines, applications, browsers, Internet kiosks, and so on, that support this standard allow a user to import, export, and exercise a single private key.
支持此标准的计算机、应用程序、浏览器、Internet信息亭等允许用户导入、导出和使用单个私钥。
Fragment identifier considerations: None.
片段标识符注意事项：无。
Additional information:
其他信息：
Deprecated alias names for this type: N/A Magic number(s): None. File extension(s): .p8e Macintosh file type code(s): None. A uniform type identifier (UTI) of "com.rsa.pkcs-8-encrypted" is recommended.
此类型的已弃用别名：N/A幻数：无。文件扩展名：.p8e Macintosh文件类型代码：无。建议使用“com.rsa.pkcs-8-encrypted”的统一类型标识符（UTI）。
Object Identifiers: 1.2.840.113549.1.12.10.1.2 (when in PKCS #12)
对象标识符：1.2.840.113549.1.12.10.1.2（在PKCS#12中时）
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Sean Leonard <dev+ietf@seantek.com>
Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: None.
使用限制：无。
Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Provisional registration? No
临时登记？不
IANA has registered the media type application/pkcs8-encrypted in the Standards tree using the information provided in Section 2 of this document.
IANA已使用本文件第2节提供的信息在标准树中注册了加密的媒体类型应用程序/pkcs8。
See the registration template.
请参阅注册模板。
[CHARREG] IANA, "Character Sets", December 2013, <http://www.iana.org/assignments/character-sets>.
[CHARREG]IANA，“字符集”，2013年12月<http://www.iana.org/assignments/character-sets>.
[IEEE.802.11-2012] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, <http://ieeexplore.ieee.org/document/6178212/>.
[IEEE.802.11-2012]IEEE，“IEEE信息技术标准——系统局域网和城域网之间的电信和信息交换——具体要求第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE 802.11-2012，DOI 10.1109/ieeestd.2012.6178212， <http://ieeexplore.ieee.org/document/6178212/>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, <https://www.rfc-editor.org/info/rfc2898>.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 2898，DOI 10.17487/RFC2898，2000年9月<https://www.rfc-editor.org/info/rfc2898>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，DOI 10.17487/RFC2978，2000年10月<https://www.rfc-editor.org/info/rfc2978>.
[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2", RFC 5208, DOI 10.17487/RFC5208, May 2008, <https://www.rfc-editor.org/info/rfc5208>.
[RFC5208]Kaliski，B，“公钥密码标准（PKCS）#8：私钥信息语法规范版本1.2”，RFC 5208，DOI 10.17487/RFC5208，2008年5月<https://www.rfc-editor.org/info/rfc5208>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，DOI 10.17487/RFC5958，2010年8月<https://www.rfc-editor.org/info/rfc5958>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, <https://www.rfc-editor.org/info/rfc7292>.
[RFC7292]Moriarty，K.，Ed.，Nystrom，M.，Parkinson，S.，Rusch，A.，和M.Scott，“PKCS#12：个人信息交换语法v1.1”，RFC 7292，DOI 10.17487/RFC7292，2014年7月<https://www.rfc-editor.org/info/rfc7292>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <https://www.rfc-editor.org/info/rfc7613>.
[RFC7613]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 7613，DOI 10.17487/RFC7613，2015年8月<https://www.rfc-editor.org/info/rfc7613>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, <https://www.rfc-editor.org/info/rfc8018>.
[RFC8018]Moriarty，K.，Ed.，Kaliski，B.，和A.Rusch，“PKCS#5：基于密码的加密规范版本2.1”，RFC 8018，DOI 10.17487/RFC8018，2017年1月<https://www.rfc-editor.org/info/rfc8018>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>.
[RFC8265]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 8265，DOI 10.17487/RFC8265，2017年10月<https://www.rfc-editor.org/info/rfc8265>.
Author's Address
作者地址
Sean Leonard Penango, Inc. 5900 Wilshire Blvd Ste 2600 Los Angeles, CA 90036 United States of America
Sean Leonard Penango，Inc.美国加利福尼亚州洛杉矶威尔希尔大道5900号，邮编：2600，邮编：90036
Email: dev+ietf@seantek.com
URI: http://www.penango.com/
Email: dev+ietf@seantek.com
URI: http://www.penango.com/