Internet Engineering Task Force (IETF) S. Josefsson
Request for Comments: 7468 SJD AB
Category: Standards Track S. Leonard
ISSN: 2070-1721 Penango, Inc.
April 2015
Internet Engineering Task Force (IETF) S. Josefsson
Request for Comments: 7468 SJD AB
Category: Standards Track S. Leonard
ISSN: 2070-1721 Penango, Inc.
April 2015
Textual Encodings of PKIX, PKCS, and CMS Structures
PKIX、PKCS和CMS结构的文本编码
Abstract
摘要
This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.
本文档描述并讨论公钥基础设施X.509（PKIX）、公钥加密标准（PKCS）和加密消息语法（CMS）的文本编码。文本编码是众所周知的，由多个应用程序和库实现，并被广泛部署。本文档阐明了现有实现的实际操作规则，并对其进行了定义，以便将来的实现能够进行互操作。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7468.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7468.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General Considerations . . . . . . . . . . . . . . . . . . . 3
3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Textual Encoding of Certificates . . . . . . . . . . . . . . 8
5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Explanatory Text . . . . . . . . . . . . . . . . . . . . 9
5.3. File Extension . . . . . . . . . . . . . . . . . . . . . 9
6. Textual Encoding of Certificate Revocation Lists . . . . . . 10
7. Textual Encoding of PKCS #10 Certification Request Syntax . . 11
8. Textual Encoding of PKCS #7 Cryptographic Message Syntax . . 11
9. Textual Encoding of Cryptographic Message Syntax . . . . . . 12
10. One Asymmetric Key and the Textual Encoding of PKCS #8
Private Key Info . . . . . . . . . . . . . . . . . . . . . . 12
11. Textual Encoding of PKCS #8 Encrypted Private Key Info . . . 13
12. Textual Encoding of Attribute Certificates . . . . . . . . . 13
13. Textual Encoding of Subject Public Key Info . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Non-conforming Examples . . . . . . . . . . . . . . 17
Appendix B. DER Expectations . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General Considerations . . . . . . . . . . . . . . . . . . . 3
3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Textual Encoding of Certificates . . . . . . . . . . . . . . 8
5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Explanatory Text . . . . . . . . . . . . . . . . . . . . 9
5.3. File Extension . . . . . . . . . . . . . . . . . . . . . 9
6. Textual Encoding of Certificate Revocation Lists . . . . . . 10
7. Textual Encoding of PKCS #10 Certification Request Syntax . . 11
8. Textual Encoding of PKCS #7 Cryptographic Message Syntax . . 11
9. Textual Encoding of Cryptographic Message Syntax . . . . . . 12
10. One Asymmetric Key and the Textual Encoding of PKCS #8
Private Key Info . . . . . . . . . . . . . . . . . . . . . . 12
11. Textual Encoding of PKCS #8 Encrypted Private Key Info . . . 13
12. Textual Encoding of Attribute Certificates . . . . . . . . . 13
13. Textual Encoding of Subject Public Key Info . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Non-conforming Examples . . . . . . . . . . . . . . 17
Appendix B. DER Expectations . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Several security-related standards used on the Internet define ASN.1 data formats that are normally encoded using the Basic Encoding Rules (BER) or Distinguished Encoding Rules (DER) [X.690], which are binary, octet-oriented encodings. This document is about the textual encodings of the following formats:
互联网上使用的几个安全相关标准定义了ASN.1数据格式，这些格式通常使用基本编码规则（BER）或可分辨编码规则（DER）[X.690]进行编码，这是二进制、八位字节编码。本文档涉及以下格式的文本编码：
1. Certificates, Certificate Revocation Lists (CRLs), and Subject Public Key Info structures in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [RFC5280].
1. Internet X.509公钥基础设施证书和证书吊销列表（CRL）配置文件[RFC5280]中的证书、证书吊销列表（CRL）和主体公钥信息结构。
2. PKCS #10: Certification Request Syntax [RFC2986].
2. PKCS#10：认证请求语法[RFC2986]。
3. PKCS #7: Cryptographic Message Syntax [RFC2315].
3. PKCS#7：加密消息语法[RFC2315]。
4. Cryptographic Message Syntax [RFC5652].
4. 加密消息语法[RFC5652]。
5. PKCS #8: Private-Key Information Syntax [RFC5208], renamed to One Asymmetric Key in Asymmetric Key Package [RFC5958], and Encrypted Private-Key Information Syntax in the same documents.
5. PKCS#8：私钥信息语法[RFC5208]，在非对称密钥包[RFC5958]中重命名为一个非对称密钥，并在相同文档中加密私钥信息语法。
6. Attribute Certificates in An Internet Attribute Certificate Profile for Authorization [RFC5755].
6. 用于授权的Internet属性证书配置文件中的属性证书[RFC5755]。
A disadvantage of a binary data format is that it cannot be interchanged in textual transports, such as email or text documents. One advantage with text-based encodings is that they are easy to modify using common text editors; for example, a user may concatenate several certificates to form a certificate chain with copy-and-paste operations.
二进制数据格式的一个缺点是不能在文本传输（如电子邮件或文本文档）中交换。基于文本的编码的一个优点是，它们很容易使用通用文本编辑器进行修改；例如，用户可以连接多个证书以形成具有复制和粘贴操作的证书链。
The tradition within the RFC series can be traced back to Privacy-Enhanced Mail (PEM) [RFC1421], based on a proposal by Marshall Rose in Message Encapsulation [RFC934]. Originally called "PEM encapsulation mechanism", "encapsulated PEM message", or (arguably) "PEM printable encoding", today the format is sometimes referred to as "PEM encoding". Variations include OpenPGP ASCII armor [RFC4880] and OpenSSH key file format [RFC4716].
RFC系列中的传统可以追溯到隐私增强邮件（PEM）[RFC1421]，这是基于Marshall Rose在消息封装[RFC934]中提出的建议。最初被称为“PEM封装机制”、“封装的PEM消息”或（可以说是）“PEM可打印编码”，今天这种格式有时被称为“PEM编码”。变化包括OpenPGP ASCII armor[RFC4880]和OpenSSH密钥文件格式[RFC4716]。
For reasons that basically boil down to non-coordination or inattention, many PKIX, PKCS, and CMS libraries implement a text-based encoding that is similar to -- but not identical with -- PEM encoding. This document specifies the _textual encoding_ format, articulates the de facto rules that most implementations operate by, and provides recommendations that will promote interoperability going forward. This document also provides common nomenclature for syntax elements, reflecting the evolution of this de facto standard format. Peter Gutmann's "X.509 Style Guide" [X.509SG] contains a section "base64 Encoding" that describes the formats and contains suggestions similar to what is in this document. All figures are real, functional examples, with key lengths and inner contents chosen to be as small as practicable.
出于基本上可以归结为不协调或疏忽的原因，许多PKIX、PKCS和CMS库实现了一种基于文本的编码，它类似于PEM编码，但与PEM编码不同。本文档指定了“文本编码”格式，阐明了大多数实现所遵循的事实规则，并提供了促进未来互操作性的建议。本文档还提供了语法元素的通用术语，反映了这种事实上的标准格式的演变。Peter Gutmann的“X.509样式指南”[X.509SG]包含“base64编码”一节，该节描述了格式，并包含与本文档类似的建议。所有图形都是真实的功能示例，键的长度和内部内容选择得尽可能小。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
Textual encoding begins with a line comprising "-----BEGIN ", a
label, and "-----", and ends with a line comprising "-----END ", a
label, and "-----". Between these lines, or "encapsulation
boundaries", are base64-encoded data according to Section 4 of
[RFC4648]. (PEM [RFC1421] referred to this data as the "encapsulated
Textual encoding begins with a line comprising "-----BEGIN ", a
label, and "-----", and ends with a line comprising "-----END ", a
label, and "-----". Between these lines, or "encapsulation
boundaries", are base64-encoded data according to Section 4 of
[RFC4648]. (PEM [RFC1421] referred to this data as the "encapsulated
text portion".) Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data. Furthermore, parsers SHOULD ignore whitespace and other non-base64 characters and MUST handle different newline conventions.
允许封装边界之前的文本部分“.”数据，解析器在处理此类数据时不得出现故障。此外，解析器应忽略空格和其他非base64字符，并且必须处理不同的换行规则。
The type of data encoded is labeled depending on the type label in
the "-----BEGIN " line (pre-encapsulation boundary). For example,
the line may be "-----BEGIN CERTIFICATE-----" to indicate that the
content is a PKIX certificate (see further below). Generators MUST
put the same label on the "-----END " line (post-encapsulation
boundary) as the corresponding "-----BEGIN " line. Labels are
formally case-sensitive, uppercase, and comprised of zero or more
characters; they do not contain consecutive spaces or hyphen-minuses,
nor do they contain spaces or hyphen-minuses at either end. Parsers
MAY disregard the label in the post-encapsulation boundary instead of
signaling an error if there is a label mismatch: some extant
implementations require the labels to match; others do not.
The type of data encoded is labeled depending on the type label in
the "-----BEGIN " line (pre-encapsulation boundary). For example,
the line may be "-----BEGIN CERTIFICATE-----" to indicate that the
content is a PKIX certificate (see further below). Generators MUST
put the same label on the "-----END " line (post-encapsulation
boundary) as the corresponding "-----BEGIN " line. Labels are
formally case-sensitive, uppercase, and comprised of zero or more
characters; they do not contain consecutive spaces or hyphen-minuses,
nor do they contain spaces or hyphen-minuses at either end. Parsers
MAY disregard the label in the post-encapsulation boundary instead of
signaling an error if there is a label mismatch: some extant
implementations require the labels to match; others do not.
There is exactly one space character (SP) separating the "BEGIN" or "END" from the label. There are exactly five hyphen-minus (also known as dash) characters ("-") on both ends of the encapsulation boundaries, no more, no less.
只有一个空格字符（SP）将“开始”或“结束”与标签分开。在封装边界的两端正好有五个连字符-减号（也称为破折号）字符（“-”），不多也不少。
The label type implies that the encoded data follows the specified syntax. Parsers MUST handle non-conforming data gracefully. However, not all parsers or generators prior to this document behave consistently. A conforming parser MAY interpret the contents as another label type but ought to be aware of the security implications discussed in the Security Considerations section. The labels described in this document identify container formats that are not specific to any particular cryptographic algorithm, a property consistent with algorithm agility. These formats use the ASN.1 AlgorithmIdentifier structure as described in Section 4.1.1.2 of [RFC5280].
标签类型意味着编码的数据遵循指定的语法。解析器必须优雅地处理不一致的数据。然而，并非在此文档之前的所有解析器或生成器的行为都是一致的。一致性解析器可以将内容解释为另一种标签类型，但应该注意安全注意事项部分中讨论的安全含义。本文档中描述的标签标识了不特定于任何特定加密算法的容器格式，该属性与算法敏捷性一致。这些格式使用[RFC5280]第4.1.1.2节所述的ASN.1算法标识符结构。
Unlike legacy PEM encoding [RFC1421], OpenPGP ASCII armor, and the OpenSSH key file format, textual encoding does *not* define or permit headers to be encoded alongside the data. Empty space can appear between the pre-encapsulation boundary and the base64, but generators SHOULD NOT emit such any such spacing. (The provision for this empty area is a throwback to PEM, which defined an "encapsulated header portion".)
与传统PEM编码[RFC1421]、OpenPGP ASCII armor和OpenSSH密钥文件格式不同，文本编码*不*定义或允许在数据旁边编码头。预封装边界和base64之间可能会出现空白，但生成器不应发出此类间距。（该空白区域的规定是对PEM的回溯，PEM定义了“封装的标题部分”。）
Implementers need to be aware that extant parsers diverge considerably on the handling of whitespace. In this document, "whitespace" means any character or series of characters that represent horizontal or vertical space in typography. In US-ASCII, whitespace means HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR
实现人员需要知道，现有解析器在处理空白方面存在很大分歧。在本文件中，“空白”是指在排版中表示水平或垂直空间的任何字符或一系列字符。在US-ASCII中，空白表示HT（0x09）、VT（0x0B）、FF（0x0C）、SP（0x20）、CR
(0x0D), and LF (0x0A); "blank" means HT and SP; lines are divided with CRLF, CR, or LF. The common ABNF production WSP is congruent with "blank"; a new production W is used for "whitespace". The ABNF in Section 3 is specific to US-ASCII. As these textual encodings can be used on many different systems as well as on long-term archival storage media such as paper or engravings, an implementer ought to use the spirit rather than the letter of the rules when generating or parsing these formats in environments that are not strictly limited to US-ASCII.
（0x0D）和LF（0x0A）；“空白”指HT和SP；行用CRLF、CR或LF划分。普通ABNF生产WSP与“空白”一致；新的产品W用于“空白”。第3节中的ABNF特定于US-ASCII。由于这些文本编码可用于许多不同的系统以及纸张或雕刻等长期存档存储介质，因此在不严格限于US-ASCII的环境中生成或解析这些格式时，实施者应该使用规则的精神而不是文字。
Most extant parsers ignore blanks at the ends of lines; blanks at the beginnings of lines or in the middle of the base64-encoded data are far less compatible. These observations are codified in Figure 1. The most lax parser implementations are not line-oriented at all and will accept any mixture of whitespace outside of the encapsulation boundaries (see Figure 2). Such lax parsing may run the risk of accepting text that was not intended to be accepted in the first place (e.g., because the text was a snippet or sample).
大多数现存的解析器忽略了行末尾的空格；在开始行或在BASE64编码数据的中间的空白是不太兼容的。这些观察结果如图1所示。最宽松的解析器实现根本不是面向行的，并且将接受封装边界之外的任何空白混合（参见图2）。这种松散的解析可能会有接受原本不打算接受的文本的风险（例如，因为文本是片段或样本）。
Generators MUST wrap the base64-encoded lines so that each line consists of exactly 64 characters except for the final line, which will encode the remainder of the data (within the 64-character line boundary), and they MUST NOT emit extraneous whitespace. Parsers MAY handle other line sizes. These requirements are consistent with PEM [RFC1421].
生成器必须包装base64编码的行，以便每行仅由64个字符组成，但最后一行除外，该行将对剩余的数据（在64个字符的行边界内）进行编码，并且它们不得发出无关的空白。解析器可以处理其他行大小。这些要求与PEM[RFC1421]一致。
Files MAY contain multiple textual encoding instances. This is used, for example, when a file contains several certificates. Whether the instances are ordered or unordered depends on the context.
文件可能包含多个文本编码实例。例如，当一个文件包含多个证书时，会使用此选项。实例是有序的还是无序的取决于上下文。
The ABNF [RFC5234] of the textual encoding is:
文本编码的ABNF[RFC5234]为：
textualmsg = preeb *WSP eol *eolWSP base64text posteb *WSP [eol]
textualmsg=preeb*WSP eol*eolWSP base64 text posteb*WSP[eol]
preeb = "-----BEGIN " label "-----" ; unlike [RFC1421] (A)BNF,
; eol is not required (but
posteb = "-----END " label "-----" ; see [RFC1421], Section 4.4)
preeb = "-----BEGIN " label "-----" ; unlike [RFC1421] (A)BNF,
; eol is not required (but
posteb = "-----END " label "-----" ; see [RFC1421], Section 4.4)
base64char = ALPHA / DIGIT / "+" / "/"
base64char = ALPHA / DIGIT / "+" / "/"
base64pad = "="
base64pad=“=”
base64line = 1*base64char *WSP eol
base64line = 1*base64char *WSP eol
base64finl = *base64char (base64pad *WSP eol base64pad /
*2base64pad) *WSP eol
; ...AB= <EOL> = <EOL> is not good, but is valid
base64finl = *base64char (base64pad *WSP eol base64pad /
*2base64pad) *WSP eol
; ...AB= <EOL> = <EOL> is not good, but is valid
base64text = *base64line base64finl
; we could also use <encbinbody> from RFC 1421, which requires
; 16 groups of 4 chars, which means exactly 64 chars per
; line, except the final line, but this is more accurate
base64text = *base64line base64finl
; we could also use <encbinbody> from RFC 1421, which requires
; 16 groups of 4 chars, which means exactly 64 chars per
; line, except the final line, but this is more accurate
labelchar = %x21-2C / %x2E-7E ; any printable character,
; except hyphen-minus
labelchar = %x21-2C / %x2E-7E ; any printable character,
; except hyphen-minus
label = [ labelchar *( ["-" / SP] labelchar ) ] ; empty ok
label = [ labelchar *( ["-" / SP] labelchar ) ] ; empty ok
eol = CRLF / CR / LF
eol = CRLF / CR / LF
eolWSP = WSP / CR / LF ; compare with LWSP
eolWSP = WSP / CR / LF ; compare with LWSP
Figure 1: ABNF (Standard)
图1:ABNF（标准）
laxtextualmsg = *W preeb
laxbase64text
posteb *W
laxtextualmsg = *W preeb
laxbase64text
posteb *W
W = WSP / CR / LF / %x0B / %x0C ; whitespace
W = WSP / CR / LF / %x0B / %x0C ; whitespace
laxbase64text = *(W / base64char) [base64pad *W [base64pad *W]]
laxbase64text = *(W / base64char) [base64pad *W [base64pad *W]]
Figure 2: ABNF (Lax)
图2:ABNF（Lax）
stricttextualmsg = preeb eol strictbase64text posteb eol
stricttextualmsg=preeb下线StrictBase64文本后线下线
strictbase64finl = *15(4base64char) (4base64char / 3base64char
base64pad / 2base64char 2base64pad) eol
strictbase64finl = *15(4base64char) (4base64char / 3base64char
base64pad / 2base64char 2base64pad) eol
base64fullline = 64base64char eol
base64fullline = 64base64char eol
strictbase64text = *base64fullline strictbase64finl
strictbase64text = *base64fullline strictbase64finl
Figure 3: ABNF (Strict)
图3:ABNF（严格）
New implementations SHOULD emit the strict format (Figure 3) specified above. The choice of parsing strategy depends on the context of use.
新的实现应该发出上面指定的严格格式（图3）。解析策略的选择取决于使用的上下文。
For convenience, these figures summarize the structures, encodings, and references in the following sections:
为方便起见，这些图总结了以下章节中的结构、编码和参考：
Sec. Label ASN.1 Type Reference Module
----+----------------------+-----------------------+---------+----------
5 CERTIFICATE Certificate [RFC5280] id-pkix1-e
6 X509 CRL CertificateList [RFC5280] id-pkix1-e
7 CERTIFICATE REQUEST CertificationRequest [RFC2986] id-pkcs10
8 PKCS7 ContentInfo [RFC2315] id-pkcs7*
9 CMS ContentInfo [RFC5652] id-cms2004
10 PRIVATE KEY PrivateKeyInfo ::= [RFC5208] id-pkcs8
OneAsymmetricKey [RFC5958] id-aKPV1
11 ENCRYPTED PRIVATE KEY EncryptedPrivateKeyInfo [RFC5958] id-aKPV1
12 ATTRIBUTE CERTIFICATE AttributeCertificate [RFC5755] id-acv2
13 PUBLIC KEY SubjectPublicKeyInfo [RFC5280] id-pkix1-e
Sec. Label ASN.1 Type Reference Module
----+----------------------+-----------------------+---------+----------
5 CERTIFICATE Certificate [RFC5280] id-pkix1-e
6 X509 CRL CertificateList [RFC5280] id-pkix1-e
7 CERTIFICATE REQUEST CertificationRequest [RFC2986] id-pkcs10
8 PKCS7 ContentInfo [RFC2315] id-pkcs7*
9 CMS ContentInfo [RFC5652] id-cms2004
10 PRIVATE KEY PrivateKeyInfo ::= [RFC5208] id-pkcs8
OneAsymmetricKey [RFC5958] id-aKPV1
11 ENCRYPTED PRIVATE KEY EncryptedPrivateKeyInfo [RFC5958] id-aKPV1
12 ATTRIBUTE CERTIFICATE AttributeCertificate [RFC5755] id-acv2
13 PUBLIC KEY SubjectPublicKeyInfo [RFC5280] id-pkix1-e
Figure 4: Convenience Guide
图4：便利指南
-----------------------------------------------------------------------
id-pkixmod OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0)}
id-pkix1-e OBJECT IDENTIFIER ::= {id-pkixmod pkix1-explicit(18)}
id-acv2 OBJECT IDENTIFIER ::= {id-pkixmod mod-attribute-cert-v2(61)}
id-pkcs OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1)}
id-pkcs10 OBJECT IDENTIFIER ::= {id-pkcs 10 modules(1) pkcs-10(1)}
id-pkcs7 OBJECT IDENTIFIER ::= {id-pkcs 7 modules(0) pkcs-7(1)}
id-pkcs8 OBJECT IDENTIFIER ::= {id-pkcs 8 modules(1) pkcs-8(1)}
id-sm-mod OBJECT IDENTIFIER ::= {id-pkcs 9 smime(16) modules(0)}
id-aKPV1 OBJECT IDENTIFIER ::= {id-sm-mod mod-asymmetricKeyPkgV1(50)}
id-cms2004 OBJECT IDENTIFIER ::= {id-sm-mod cms-2004(24)}
-----------------------------------------------------------------------
id-pkixmod OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0)}
id-pkix1-e OBJECT IDENTIFIER ::= {id-pkixmod pkix1-explicit(18)}
id-acv2 OBJECT IDENTIFIER ::= {id-pkixmod mod-attribute-cert-v2(61)}
id-pkcs OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1)}
id-pkcs10 OBJECT IDENTIFIER ::= {id-pkcs 10 modules(1) pkcs-10(1)}
id-pkcs7 OBJECT IDENTIFIER ::= {id-pkcs 7 modules(0) pkcs-7(1)}
id-pkcs8 OBJECT IDENTIFIER ::= {id-pkcs 8 modules(1) pkcs-8(1)}
id-sm-mod OBJECT IDENTIFIER ::= {id-pkcs 9 smime(16) modules(0)}
id-aKPV1 OBJECT IDENTIFIER ::= {id-sm-mod mod-asymmetricKeyPkgV1(50)}
id-cms2004 OBJECT IDENTIFIER ::= {id-sm-mod cms-2004(24)}
* This OID does not actually appear in PKCS #7 v1.5 [RFC2315]. It was defined in the ASN.1 module to PKCS #7 v1.6 [P7v1.6], and has been carried forward through PKCS #12 [RFC7292].
* 这个OID实际上没有出现在PKCS#7 v1.5[RFC2315]中。它在ASN.1模块中定义为PKCS#7 v1.6[P7v1.6]，并通过PKCS#12[RFC7292]进行了继承。
Figure 5: ASN.1 Module Object Identifier Value Assignments
图5:ASN.1模块对象标识符值分配
Public-key certificates are encoded using the "CERTIFICATE" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 Certificate structure as described in Section 4 of [RFC5280].
公钥证书使用“证书”标签进行编码。编码数据必须是[RFC5280]第4节所述的BER（DER优先；见附录B）编码ASN.1证书结构。
-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
-----END CERTIFICATE-----
Figure 6: Certificate Example
图6：证书示例
Historically, the label "X509 CERTIFICATE" and also less commonly "X.509 CERTIFICATE" have been used. Generators conforming to this document MUST generate "CERTIFICATE" labels and MUST NOT generate "X509 CERTIFICATE" or "X.509 CERTIFICATE" labels. Parsers SHOULD NOT treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to "CERTIFICATE", but a valid exception may be for backwards compatibility (potentially together with a warning).
历史上，使用过标签“X509证书”和不太常见的“X.509证书”。符合本文件要求的发电机必须生成“证书”标签，不得生成“X509证书”或“X.509证书”标签。解析器不应将“X509证书”或“X.509证书”视为等同于“证书”，但一个有效的例外可能是向后兼容（可能同时出现警告）。
Many tools are known to emit explanatory text before the BEGIN and after the END lines for PKIX certificates, more than any other type. If emitted, such text SHOULD be related to the certificate, such as providing a textual representation of key data elements in the certificate.
众所周知，许多工具在PKIX证书的开始行之前和结束行之后发出解释性文本，比任何其他类型的工具都多。如果发出，则此类文本应与证书相关，例如提供证书中关键数据元素的文本表示。
Subject: CN=Atlantis
Issuer: CN=Atlantis
Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC
-----BEGIN CERTIFICATE-----
MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz
MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs
YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh
Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID
AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB
gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE
LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow
CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0
ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg=
-----END CERTIFICATE-----
Subject: CN=Atlantis
Issuer: CN=Atlantis
Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC
-----BEGIN CERTIFICATE-----
MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz
MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs
YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh
Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID
AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB
gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE
LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow
CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0
ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg=
-----END CERTIFICATE-----
Figure 7: Certificate Example with Explanatory Text
图7：带有解释性文本的证书示例
Although textual encodings of PKIX structures can occur anywhere, many tools are known to offer an option to output this encoding when serializing PKIX structures. To promote interoperability and to separate DER encodings from textual encodings, the extension ".crt" SHOULD be used for the textual encoding of a certificate. Implementations should be aware that in spite of this recommendation, many tools still default to encode certificates in this textual encoding with the extension ".cer".
尽管PKIX结构的文本编码可以出现在任何地方，但已知许多工具在序列化PKIX结构时提供了输出这种编码的选项。为了促进互操作性并将DER编码与文本编码分开，扩展名“.crt”应用于证书的文本编码。实现应该知道，尽管有此建议，许多工具仍然默认使用扩展名为“.cer”的文本编码对证书进行编码。
This section does not disturb the official application/pkix-cert registration [RFC2585] in any way (which states that "each '.cer' file contains exactly one certificate, encoded in DER format"), but merely articulates a widespread, de facto alternative.
本节不会以任何方式干扰官方应用程序/pkix证书注册[RFC2585]（其中规定“每个.cer”文件仅包含一个以DER格式编码的证书），但仅阐述了一个广泛的、事实上的替代方案。
Certificate Revocation Lists (CRLs) are encoded using the "X509 CRL" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 CertificateList structure as described in Section 5 of [RFC5280].
证书吊销列表（CRL）使用“X509 CRL”标签进行编码。编码数据必须是[RFC5280]第5节所述的BER（DER优先；见附录B）编码ASN.1证书列表结构。
-----BEGIN X509 CRL-----
MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT
PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu
LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm
MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU
D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u
Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd
elUNpllhhTgXDTA2MTIyNzA4MDIzNFowCwYJKoZIhvcNAQEFA4GBAD0zX+J2hkcc
Nbrq1Dn5IKL8nXLgPGcHv1I/le1MNo9t1ohGQxB5HnFUkRPAY82fR6Epor4aHgVy
b+5y+neKN9Kn2mPF4iiun+a4o26CjJ0pArojCL1p8T0yyi9Xxvyc/ezaZ98HiIyP
c3DGMNR+oUmSjKZ0jIhAYmeLxaPHfQwR
-----END X509 CRL-----
-----BEGIN X509 CRL-----
MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT
PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu
LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm
MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU
D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u
Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd
elUNpllhhTgXDTA2MTIyNzA4MDIzNFowCwYJKoZIhvcNAQEFA4GBAD0zX+J2hkcc
Nbrq1Dn5IKL8nXLgPGcHv1I/le1MNo9t1ohGQxB5HnFUkRPAY82fR6Epor4aHgVy
b+5y+neKN9Kn2mPF4iiun+a4o26CjJ0pArojCL1p8T0yyi9Xxvyc/ezaZ98HiIyP
c3DGMNR+oUmSjKZ0jIhAYmeLxaPHfQwR
-----END X509 CRL-----
Figure 8: CRL Example
图8:CRL示例
Historically, the label "CRL" has rarely been used. Today, it is not common and many popular tools do not understand the label. Therefore, this document standardizes "X509 CRL" in order to promote interoperability and backwards-compatibility. Generators conforming to this document MUST generate "X509 CRL" labels and MUST NOT generate "CRL" labels. Parsers SHOULD NOT treat "CRL" as equivalent to "X509 CRL".
历史上，很少使用“CRL”标签。如今，它并不常见，许多流行的工具也不理解这个标签。因此，本文件对“X509 CRL”进行了标准化，以促进互操作性和向后兼容性。符合本文件要求的发电机必须生成“X509 CRL”标签，不得生成“CRL”标签。解析器不应将“CRL”视为等同于“X509 CRL”。
PKCS #10 Certification Requests are encoded using the "CERTIFICATE REQUEST" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 CertificationRequest structure as described in [RFC2986].
PKCS#10认证请求使用“证书请求”标签进行编码。编码数据必须是[RFC2986]中所述的BER（DER强烈推荐；见附录B）编码ASN.1 CertificationRequest结构。
-----BEGIN CERTIFICATE REQUEST-----
MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
dEQc8B8jAcnuOrfU
-----END CERTIFICATE REQUEST-----
-----BEGIN CERTIFICATE REQUEST-----
MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
dEQc8B8jAcnuOrfU
-----END CERTIFICATE REQUEST-----
Figure 9: PKCS #10 Example
图9:PKCS#10示例
The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators conforming to this document MUST generate "CERTIFICATE REQUEST" labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to "CERTIFICATE REQUEST".
“新证书申请”标签也被广泛使用。符合本文件要求的发电机必须生成“证书申请”标签。解析器可以将“新证书请求”视为等同于“证书请求”。
PKCS #7 Cryptographic Message Syntax structures are encoded using the "PKCS7" label. The encoded data MUST be a BER-encoded ASN.1 ContentInfo structure as described in [RFC2315].
PKCS#7加密消息语法结构使用“PKCS7”标签进行编码。编码数据必须是BER编码的ASN.1 ContentInfo结构，如[RFC2315]所述。
-----BEGIN PKCS7-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END PKCS7-----
-----BEGIN PKCS7-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END PKCS7-----
Figure 10: PKCS #7 Example
图10:PKCS#7示例
The label "CERTIFICATE CHAIN" has been in use to denote a degenerate PKCS #7 structure that contains only a list of certificates (see Section 9 of [RFC2315]). Several modern tools do not support this label. Generators MUST NOT generate the "CERTIFICATE CHAIN" label. Parsers SHOULD NOT treat "CERTIFICATE CHAIN" as equivalent to "PKCS7".
标签“证书链”用于表示仅包含证书列表的退化PKCS#7结构（参见[RFC2315]第9节）。一些现代工具不支持此标签。生成器不得生成“证书链”标签。解析器不应将“证书链”等同于“PKCS7”。
PKCS #7 is an old specification that has long been superseded by CMS [RFC5652]. Implementations SHOULD NOT generate PKCS #7 when CMS is an alternative.
PKCS#7是一个旧规范，长期以来被CMS[RFC5652]取代。当CMS是一种替代方案时，实施不应生成PKCS#7。
Cryptographic Message Syntax structures are encoded using the "CMS" label. The encoded data MUST be a BER-encoded ASN.1 ContentInfo structure as described in [RFC5652].
加密消息语法结构使用“CMS”标签进行编码。编码数据必须是BER编码的ASN.1 ContentInfo结构，如[RFC5652]所述。
-----BEGIN CMS-----
MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
-----END CMS-----
-----BEGIN CMS-----
MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
-----END CMS-----
Figure 11: CMS Example
图11:CMS示例
CMS is the IETF successor to PKCS #7. Section 1.1.1 of [RFC5652] describes the changes since PKCS #7 v1.5. Implementations SHOULD generate CMS when it is an alternative, promoting interoperability and forwards-compatibility.
CMS是PKCS#7的IETF继承者。[RFC5652]的第1.1.1节描述了自PKCS#7 v1.5以来的变化。作为替代方案时，实施应生成CMS，以促进互操作性和转发兼容性。
10. One Asymmetric Key and the Textual Encoding of PKCS #8 Private Key Info
10. 一个非对称密钥与PKCS#8私钥信息的文本编码
Unencrypted PKCS #8 Private Key Information Syntax structures (PrivateKeyInfo), renamed to Asymmetric Key Packages (OneAsymmetricKey), are encoded using the "PRIVATE KEY" label. The encoded data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 PrivateKeyInfo structure as described in PKCS #8 [RFC5208], or a OneAsymmetricKey structure as described in [RFC5958]. The two are semantically identical and can be distinguished by version number.
未加密的PKCS#8私钥信息语法结构（PrivateKeyInfo）重命名为非对称密钥包（OneAsymmetricKey），使用“私钥”标签进行编码。编码数据必须是PKCS#8[RFC5208]中所述的BER（DER优先；见附录B）编码ASN.1 PrivateKeyInfo结构，或[RFC5958]中所述的OneAsymmetricKey结构。两者在语义上相同，可以通过版本号来区分。
-----BEGIN PRIVATE KEY-----
MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf
jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK
H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ
-----END PRIVATE KEY-----
-----BEGIN PRIVATE KEY-----
MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf
jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK
H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ
-----END PRIVATE KEY-----
Figure 12: PKCS #8 PrivateKeyInfo (OneAsymmetricKey) Example
图12:PKCS#8 PrivateKeyInfo（OneAsymmetricKey）示例
Encrypted PKCS #8 Private Key Information Syntax structures (EncryptedPrivateKeyInfo), called the same in [RFC5958], are encoded using the "ENCRYPTED PRIVATE KEY" label. The encoded data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 EncryptedPrivateKeyInfo structure as described in PKCS #8 [RFC5208] and [RFC5958].
加密PKCS#8私钥信息语法结构（EncryptedPrivateKeyInfo），在[RFC5958]中称为相同的结构，使用“加密私钥”标签进行编码。编码数据必须为BER（首选DER；见附录B）编码的ASN.1加密私钥信息结构，如PKCS#8[RFC5208]和[RFC5958]所述。
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw
FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW
Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap
8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF
QC7k0NNzUHTV9yGDwfqMbw==
-----END ENCRYPTED PRIVATE KEY-----
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw
FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW
Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap
8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF
QC7k0NNzUHTV9yGDwfqMbw==
-----END ENCRYPTED PRIVATE KEY-----
Figure 13: PKCS #8 EncryptedPrivateKeyInfo Example
图13:PKCS#8 EncryptedPrivateKeyInfo示例
Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATE" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 AttributeCertificate structure as described in [RFC5755].
属性证书使用“属性证书”标签进行编码。编码数据必须是BER（DER强烈推荐；见附录B）编码的ASN.1 AttributeCertificate结构，如[RFC5755]所述。
-----BEGIN ATTRIBUTE CERTIFICATE-----
MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI
DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5
MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA
aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER
MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK
DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz
dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z
OTA3MDIwMTA1MDAwMFoYDzM5MTEwMTMxMDUwMDAwWjArMCkGA1UYSDEiMCCGHmh0
dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUFAAOBgQAV
M9axFPXXozEFcer06bj9MCBBCQLtAM7ZXcZjcxyva7xCBDmtZXPYUluHf5OcWPJz
5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw
Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ==
-----END ATTRIBUTE CERTIFICATE-----
-----BEGIN ATTRIBUTE CERTIFICATE-----
MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI
DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5
MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA
aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER
MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK
DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz
dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z
OTA3MDIwMTA1MDAwMFoYDzM5MTEwMTMxMDUwMDAwWjArMCkGA1UYSDEiMCCGHmh0
dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUFAAOBgQAV
M9axFPXXozEFcer06bj9MCBBCQLtAM7ZXcZjcxyva7xCBDmtZXPYUluHf5OcWPJz
5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw
Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ==
-----END ATTRIBUTE CERTIFICATE-----
Figure 14: Attribute Certificate Example
图14：属性证书示例
Public keys are encoded using the "PUBLIC KEY" label. The encoded data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 SubjectPublicKeyInfo structure as described in Section 4.1.2.7 of [RFC5280].
使用“公钥”标签对公钥进行编码。编码数据必须是[RFC5280]第4.1.2.7节所述的编码为ASN.1 SubjectPublicKeyInfo结构的BER（首选DER；见附录B）。
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe
kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U
Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe
kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U
Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp
-----END PUBLIC KEY-----
Figure 15: Subject Public Key Info Example
图15：主题公钥信息示例
Data in this format often originates from untrusted sources, thus parsers must be prepared to handle unexpected data without causing security vulnerabilities.
这种格式的数据通常来自不受信任的来源，因此解析器必须准备好处理意外数据，而不会造成安全漏洞。
Implementers building implementations that rely on canonical representation or the ability to fingerprint a particular data object need to understand that this document does not define canonical encodings. The first ambiguity is introduced by permitting the text-encoded representation instead of the binary BER or DER encodings, but further ambiguities arise when multiple labels are treated as similar. Variations of whitespace and non-base64 alphabetic characters can create further ambiguities. Data encoding ambiguities also create opportunities for side channels. If canonical encodings are desired, the encoded structure must be decoded and processed into a canonical form (namely, DER encoding).
构建依赖规范表示或对特定数据对象进行指纹识别的实现的实现者需要理解，本文档没有定义规范编码。第一个歧义是通过允许文本编码表示而不是二进制BER或DER编码引入的，但是当多个标签被视为相似时，会出现进一步的歧义。空格和非base64字母字符的变化可能会造成进一步的歧义。数据编码的模糊性也为旁道创造了机会。如果需要规范编码，则必须将编码结构解码并处理为规范形式（即DER编码）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998, <http://www.rfc-editor.org/info/rfc2315>.
[RFC2315]Kaliski，B.，“PKCS#7：加密消息语法版本1.5”，RFC 23151998年3月<http://www.rfc-editor.org/info/rfc2315>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000, <http://www.rfc-editor.org/info/rfc2986>.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10:认证请求语法规范版本1.7”，RFC 29862000年11月<http://www.rfc-editor.org/info/rfc2986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5280] 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, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月<http://www.rfc-editor.org/info/rfc5652>.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010, <http://www.rfc-editor.org/info/rfc5755>.
[RFC5755]Farrell，S.，Housley，R.和S.Turner，“授权的互联网属性证书配置文件”，RFC 57552010年1月<http://www.rfc-editor.org/info/rfc5755>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010, <http://www.rfc-editor.org/info/rfc5958>.
[RFC5958]Turner，S.，“非对称密钥包”，RFC 5958，2010年8月<http://www.rfc-editor.org/info/rfc5958>.
[X.690] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2008, November 2008.
[X.690]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC 8825-1:2008，2008年11月。
[RFC934] Rose, M. and E. Stefferud, "Proposed standard for message encapsulation", RFC 934, January 1985, <http://www.rfc-editor.org/info/rfc934>.
[RFC934]Rose，M.和E.Stefferud，“建议的消息封装标准”，RFC 934，1985年1月<http://www.rfc-editor.org/info/rfc934>.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993, <http://www.rfc-editor.org/info/rfc1421>.
[RFC1421]Linn，J.，“互联网电子邮件的隐私增强：第一部分：消息加密和认证程序”，RFC 14211993年2月<http://www.rfc-editor.org/info/rfc1421>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999, <http://www.rfc-editor.org/info/rfc2585>.
[RFC2585]Housley，R.和P.Hoffman，“互联网X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月<http://www.rfc-editor.org/info/rfc2585>.
[RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH) Public Key File Format", RFC 4716, November 2006, <http://www.rfc-editor.org/info/rfc4716>.
[RFC4716]Galbraith，J.和R.Thayer，“安全外壳（SSH）公钥文件格式”，RFC 47162006年11月<http://www.rfc-editor.org/info/rfc4716>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月<http://www.rfc-editor.org/info/rfc4880>.
[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2", RFC 5208, May 2008, <http://www.rfc-editor.org/info/rfc5208>.
[RFC5208]Kaliski，B.，“公钥密码标准（PKCS）#8：私钥信息语法规范版本1.2”，RFC 5208，2008年5月<http://www.rfc-editor.org/info/rfc5208>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, July 2014, <http://www.rfc-editor.org/info/rfc7292>.
[RFC7292]Moriarty，K.，Ed.，Nystrom，M.，Parkinson，S.，Rusch，A.，和M.Scott，“PKCS#12：个人信息交换语法v1.1”，RFC 72922014年7月<http://www.rfc-editor.org/info/rfc7292>.
[P7v1.6] Kaliski, B. and K. Kingdon, "Extensions and Revisions to PKCS #7 (Version 1.6 Bulletin)", May 1997, <http://www.emc.com/emc-plus/rsa-labs/ standards-initiatives/pkcs-7-cryptographic-message-syntax-standar.htm>.
[P7v1.6]Kaliski，B.和K.Kingdon，“PKCS#7（1.6版公告）的扩展和修订”，1997年5月<http://www.emc.com/emc-plus/rsa-labs/ 标准倡议/pkcs-7-cryptographic-message-syntax-standar.htm>。
[X.509SG] Gutmann, P., "X.509 Style Guide", October 2000, <http://www.cs.auckland.ac.nz/~pgut001/pubs/ x509guide.txt>.
[X.509SG]Gutmann，P.，“X.509风格指南”，2000年10月<http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt>。
This appendix contains examples for the non-recommended label variants described earlier in this document. As discussed earlier, supporting these is not required and is sometimes discouraged. Still, they can be useful for interoperability testing and for easy reference.
本附录包含本文件前面描述的非推荐标签变体示例。如前所述，支持这些是不必要的，有时是不鼓励的。尽管如此，它们对于互操作性测试和方便参考仍然很有用。
-----BEGIN X509 CERTIFICATE-----
MIIBHDCBxaADAgECAgIcxzAJBgcqhkjOPQQBMBAxDjAMBgNVBAMUBVBLSVghMB4X
DTE0MDkxNDA2MTU1MFoXDTI0MDkxNDA2MTU1MFowEDEOMAwGA1UEAxQFUEtJWCEw
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwoQSr863QrR0PoRIYQ96H7WykDePH
Wa0eVAE24bth43wCNc+U5aZ761dhGhSSJkVWRgVH5+prLIr+nzfIq+X4oxAwDjAM
BgNVHRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIfMdKS5F63lMnWVhi7uaKJzKCs
NnY/OKgBex6MIEAv2AIhAI2GdvfL+mGvhyPZE+JxRxWChmggb5/9eHdUcmW/jkOH
-----END X509 CERTIFICATE-----
-----BEGIN X509 CERTIFICATE-----
MIIBHDCBxaADAgECAgIcxzAJBgcqhkjOPQQBMBAxDjAMBgNVBAMUBVBLSVghMB4X
DTE0MDkxNDA2MTU1MFoXDTI0MDkxNDA2MTU1MFowEDEOMAwGA1UEAxQFUEtJWCEw
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwoQSr863QrR0PoRIYQ96H7WykDePH
Wa0eVAE24bth43wCNc+U5aZ761dhGhSSJkVWRgVH5+prLIr+nzfIq+X4oxAwDjAM
BgNVHRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIfMdKS5F63lMnWVhi7uaKJzKCs
NnY/OKgBex6MIEAv2AIhAI2GdvfL+mGvhyPZE+JxRxWChmggb5/9eHdUcmW/jkOH
-----END X509 CERTIFICATE-----
Figure 16: Non-standard 'X509' Certificate Example
图16：非标准“X509”证书示例
-----BEGIN X.509 CERTIFICATE-----
MIIBHDCBxaADAgECAgIcxzAJBgcqhkjOPQQBMBAxDjAMBgNVBAMUBVBLSVghMB4X
DTE0MDkxNDA2MTU1MFoXDTI0MDkxNDA2MTU1MFowEDEOMAwGA1UEAxQFUEtJWCEw
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwoQSr863QrR0PoRIYQ96H7WykDePH
Wa0eVAE24bth43wCNc+U5aZ761dhGhSSJkVWRgVH5+prLIr+nzfIq+X4oxAwDjAM
BgNVHRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIfMdKS5F63lMnWVhi7uaKJzKCs
NnY/OKgBex6MIEAv2AIhAI2GdvfL+mGvhyPZE+JxRxWChmggb5/9eHdUcmW/jkOH
-----END X.509 CERTIFICATE-----
-----BEGIN X.509 CERTIFICATE-----
MIIBHDCBxaADAgECAgIcxzAJBgcqhkjOPQQBMBAxDjAMBgNVBAMUBVBLSVghMB4X
DTE0MDkxNDA2MTU1MFoXDTI0MDkxNDA2MTU1MFowEDEOMAwGA1UEAxQFUEtJWCEw
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwoQSr863QrR0PoRIYQ96H7WykDePH
Wa0eVAE24bth43wCNc+U5aZ761dhGhSSJkVWRgVH5+prLIr+nzfIq+X4oxAwDjAM
BgNVHRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIfMdKS5F63lMnWVhi7uaKJzKCs
NnY/OKgBex6MIEAv2AIhAI2GdvfL+mGvhyPZE+JxRxWChmggb5/9eHdUcmW/jkOH
-----END X.509 CERTIFICATE-----
Figure 17: Non-standard 'X.509' Certificate Example
图17：非标准“X.509”证书示例
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
dEQc8B8jAcnuOrfU
-----END NEW CERTIFICATE REQUEST-----
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
dEQc8B8jAcnuOrfU
-----END NEW CERTIFICATE REQUEST-----
Figure 18: Non-standard 'NEW' PKCS #10 Example
图18：非标准“新”PKCS#10示例
-----BEGIN CERTIFICATE CHAIN-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END CERTIFICATE CHAIN-----
-----BEGIN CERTIFICATE CHAIN-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END CERTIFICATE CHAIN-----
Figure 19: Non-standard 'CERTIFICATE CHAIN' Example
图19：非标准“证书链”示例
This appendix is informative. Consult the respective standards for the normative rules.
本附录为资料性附录。有关规范性规则，请参考相应的标准。
DER is a restricted profile of BER [X.690]; thus, all DER encodings of data values are BER encodings, but just one of the BER encodings is the DER encoding for a data value. Canonical encoding matters when performing cryptographic operations; additionally, canonical encoding has certain efficiency advantages for parsers. There are three principal reasons to encode with DER:
DER是BER[X.690]的受限配置文件；因此，数据值的所有DER编码都是BER编码，但只有一个BER编码是数据值的DER编码。在执行加密操作时，规范编码很重要；此外，规范化编码对解析器具有一定的效率优势。使用DER编码有三个主要原因：
1. A digital signature is (supposed to be) computed over the DER encoding of the semantic content, so providing anything other than the DER encoding is senseless. (In practice, an implementer might choose to have an implementation parse and digest the data as is, but this practice amounts to guesswork.)
1. 数字签名（应该）是通过语义内容的DER编码来计算的，因此提供除DER编码之外的任何内容都是毫无意义的。（在实践中，实现者可能选择让实现按原样解析和消化数据，但这种做法相当于猜测。）
2. In practice, cryptographic hashes are computed over the DER encoding for identification.
2. 实际上，加密散列是在DER编码上计算的，用于识别。
3. In practice, the content is small. DER always encodes data values in definite-length form (where the length is stated at the beginning of the encoding); thus, a parser can anticipate memory or resource usage up front.
3. 实际上，内容很小。DER始终以确定长度的形式对数据值进行编码（其中长度在编码开始时说明）；因此，解析器可以预先预测内存或资源的使用情况。
Figure 20 matches the structures in this document with the particular reasons for DER encoding:
图20将本文档中的结构与DER编码的特定原因相匹配：
Sec. Label Reasons
----+----------------------+-------
5 CERTIFICATE 1 2 ~3
6 X509 CRL 1
7 CERTIFICATE REQUEST 1 ~3
8 PKCS7 *
9 CMS *
10 PRIVATE KEY 3
11 ENCRYPTED PRIVATE KEY 3
12 ATTRIBUTE CERTIFICATE 1 ~3
13 PUBLIC KEY 2 3
Sec. Label Reasons
----+----------------------+-------
5 CERTIFICATE 1 2 ~3
6 X509 CRL 1
7 CERTIFICATE REQUEST 1 ~3
8 PKCS7 *
9 CMS *
10 PRIVATE KEY 3
11 ENCRYPTED PRIVATE KEY 3
12 ATTRIBUTE CERTIFICATE 1 ~3
13 PUBLIC KEY 2 3
Figure 20: Guide for DER Encoding
图20：DER编码指南
* Cryptographic Message Syntax is designed for content of any length; indefinite-length encoding enables one-pass processing (streaming) when generating the encoding. Only certain parts -- namely, signed and authenticated attributes -- need to be DER encoded.
* 加密消息语法设计用于任何长度的内容；不定长编码在生成编码时启用单次处理（流式处理）。只有某些部分——即已签名和已验证的属性——需要进行DER编码。
~ Although not always "small", these encoded structures should not be particularly "large" (e.g., more than 16 kilobytes). The parser ought to be informed of large things up front in any event; this is yet another reason to DER encode these things in the first place.
~尽管并非总是“小”，但这些编码结构不应特别“大”（例如，超过16 KB）。在任何情况下，都应该提前通知解析器一些重要的事情；这是在第一时间对这些东西进行编码的另一个原因。
Figure 20: Guide for DER Encoding
图20：DER编码指南
Acknowledgements
致谢
Peter Gutmann suggested to document labels for Attribute Certificates and PKCS #7 messages, and to add examples for the non-standard variants. Dr. Stephen Henson suggested distinguishing when BER versus DER is appropriate or necessary.
Peter Gutmann建议记录属性证书和PKCS#7消息的标签，并为非标准变体添加示例。Stephen Henson博士建议区分BER和DER是合适的还是必要的。
Authors' Addresses
作者地址
Simon Josefsson SJD AB Johan Olof Wallins Vaeg 13 Solna 171 64 Sweden
Simon Josefsson SJD AB Johan Olof Wallins Vaeg 13 Solna 171 64瑞典
EMail: simon@josefsson.org
URI: http://josefsson.org/
EMail: simon@josefsson.org
URI: http://josefsson.org/
Sean Leonard Penango, Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles, CA 90036 United States
Sean Leonard Penango，Inc.美国加利福尼亚州洛杉矶威尔希尔大道21楼5900号，邮编90036
EMail: dev+ietf@seantek.com
URI: http://www.penango.com/
EMail: dev+ietf@seantek.com
URI: http://www.penango.com/