Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8358 Vigil Security
Updates: 5485 March 2018
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8358 Vigil Security
Updates: 5485 March 2018
Category: Informational
ISSN: 2070-1721
Update to Digital Signatures on Internet-Draft Documents
更新互联网文件草稿上的数字签名
Abstract
摘要
RFC 5485 specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
RFC 5485规定了互联网草案上数字签名的约定。加密消息语法（CMS）用于创建分离的签名，该签名存储在单独的配套文件中，因此添加数字签名不会影响现有的实用程序。
The RFC Editor recently published the first RFC that includes non-ASCII characters in a text file. The conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.
RFC编辑器最近发布了第一个在文本文件中包含非ASCII字符的RFC。遵循RFC 7997中规定的约定。我们假设非ASCII字符也将很快出现在互联网草稿中。本文档更新了在文本文件中包含非ASCII字符的Internet草稿上对数字签名的处理。
This document updates RFC 5485.
本文件更新了RFC 5485。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc8358.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8358.
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. 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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detached Signature Files . . . . . . . . . . . . . . . . . . 4
3. Additional Content Types . . . . . . . . . . . . . . . . . . 4
4. Need for Canonicalization . . . . . . . . . . . . . . . . . . 5
4.1. ASCII, UTF-8, and HTML File Canonicalization . . . . . . 6
4.2. XML File Canonicalization . . . . . . . . . . . . . . . . 6
4.3. No Canonicalization of Other File Formats . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Deployment and Operational Considerations . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detached Signature Files . . . . . . . . . . . . . . . . . . 4
3. Additional Content Types . . . . . . . . . . . . . . . . . . 4
4. Need for Canonicalization . . . . . . . . . . . . . . . . . . 5
4.1. ASCII, UTF-8, and HTML File Canonicalization . . . . . . 6
4.2. XML File Canonicalization . . . . . . . . . . . . . . . . 6
4.3. No Canonicalization of Other File Formats . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Deployment and Operational Considerations . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
RFC 5485 [IDSIG] specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) [CMS] is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
RFC 5485[IDSIG]指定了互联网草稿上数字签名的约定。加密消息语法（CMS）[CMS]用于创建分离的签名，该签名存储在单独的配套文件中，因此添加数字签名不会影响现有的实用程序。
The RFC Editor recently published the first RFC that includes non-ASCII characters in a text file. The conventions specified in RFC 7997 [RFCED] were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.
RFC编辑器最近发布了第一个在文本文件中包含非ASCII字符的RFC。遵循RFC 7997[RFCED]中规定的约定。我们假设非ASCII字符也将很快出现在互联网草稿中。本文档更新了在文本文件中包含非ASCII字符的Internet草稿上对数字签名的处理。
This document updates RFC 5485 [IDSIG], which contains the conventions that have been used by the IETF Secretariat to digitally sign Internet-Drafts for the past few years. The IETF Secretariat generates the digital signature shortly after the Internet-Draft is posted in the repository.
本文件更新了RFC 5485[IDSIG]，其中包含IETF秘书处过去几年用于数字签署互联网草案的公约。IETF秘书处在互联网草稿发布到存储库后不久生成数字签名。
The digital signature allows anyone to confirm that the contents of the Internet-Draft have not been altered since the time that the document was signed.
数字签名允许任何人确认，自文件签署之日起，互联网草稿的内容未被更改。
The digital signature is intended to provide a straightforward way for anyone to determine whether a particular file contains the Internet-Draft that was made available by the IETF Secretariat. The signing-time associated with the signature provides the wall clock time at which the signature was generated; it is not intended to provide a trusted timestamp.
数字签名旨在为任何人提供一种直接的方法，以确定特定文件是否包含IETF秘书处提供的互联网草案。与签名相关联的签名时间提供生成签名的挂钟时间；它不打算提供可信的时间戳。
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 BCP 14 [STDWORDS] [STDWORDS2] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（且仅在所有大写字母出现时）应按照BCP 14[STDWORD][STDWORDS2]中的说明进行解释，如下所示。
The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is a formal notation used for describing data protocols, regardless of the programming language used by the implementation. Encoding rules describe how the values defined in ASN.1 will be represented for transmission. The Basic Encoding Rules (BER) [X.690] are the most widely employed rule set, but they offer more than one way to
CMS使用抽象语法符号1（ASN.1）[X.680]。ASN.1是一种用于描述数据协议的正式符号，与实现所使用的编程语言无关。编码规则描述了ASN.1中定义的值在传输时的表示方式。基本编码规则（BER）[X.690]是应用最广泛的规则集，但它们提供了不止一种方法
represent data structures. For example, definite length encoding and indefinite length encoding are supported. This flexibility is not desirable when digital signatures are used. As a result, the Distinguished Encoding Rules (DER) [X.690] were invented. DER is a subset of BER that ensures a single way to represent a given value. For example, DER always employs definite length encoding.
表示数据结构。例如，支持定长编码和定长编码。当使用数字签名时，这种灵活性是不可取的。因此，发明了区分编码规则（DER）[X.690]。DER是BER的一个子集，确保以单一方式表示给定值。例如，DER总是采用定长编码。
All Internet-Draft file names begin with "draft-". The next portion of the file name depends on the source of the document. For example, documents from IETF working groups usually have "ietf-" followed by the working group abbreviation, and this is followed by a string that helps people figure out the subject of the document.
所有Internet草稿文件名都以“草稿-”开头。文件名的下一部分取决于文档的源。例如，来自IETF工作组的文档通常有“IETF-”，后跟工作组缩写，后面是帮助人们理解文档主题的字符串。
All Internet-Draft file names end with a hyphen followed by a two digit version number and a suffix. The suffix indicates the type of file. For example, a text file will have a suffix of ".txt". Today, plain text files are the most common, but the RFC Editor has announced plans to make use of other formats [RFCSERIES]. Each file format employs a different suffix.
所有Internet草稿文件名都以连字符结尾，后跟两位数的版本号和后缀。后缀表示文件的类型。例如，文本文件的后缀为“.txt”。如今，纯文本文件是最常见的，但RFC编辑器已经宣布计划使用其他格式[RFC系列]。每个文件格式使用不同的后缀。
Going forward, one cannot assume that a text file with a suffix of ".txt" will contain only ASCII characters.
接下来，我们不能假设后缀为“.txt”的文本文件只包含ASCII字符。
The companion signature file has exactly the same file name as the RFC or Internet-Draft, except that ".p7s" is added to the end. This file name suffix conforms to the conventions in RFC 5751 [MSG]. Here are a few example names:
附带的签名文件与RFC或Internet草稿的文件名完全相同，只是末尾添加了“.p7s”。此文件名后缀符合RFC 5751[MSG]中的约定。以下是几个示例名称：
Internet-Draft: draft-ietf-example-widgets-03.txt Signature File: draft-ietf-example-widgets-03.txt.p7s
互联网草稿：Draft-ietf-example-widgets-03.txt签名文件：Draft-ietf-example-widgets-03.txt.p7s
Internet-Draft: draft-ietf-example-widgets-03.pdf Signature File: draft-ietf-example-widgets-03.pdf.p7s
互联网草稿：Draft-ietf-example-widgets-03.pdf签名文件：Draft-ietf-example-widgets-03.pdf.p7s
Internet-Draft: draft-housley-internet-draft-sig-file-00.txt Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s
互联网草稿：Draft-housley-Internet-Draft-sig-file-00.txt签名文件：Draft-housley-Internet-Draft-sig-file-00.txt.p7s
The CMS is used to construct the detached signatures for Internet-Drafts. The CMS ContentInfo content type MUST always be present, and it MUST encapsulate the CMS SignedData content type. Since a detached signature is being created, the CMS SignedData content type MUST NOT encapsulate the Internet-Draft. The CMS detached signature is summarized in RFC 5485 [IDSIG].
CMS用于为Internet草稿构造分离的签名。CMS ContentInfo内容类型必须始终存在，并且必须封装CMS SignedData内容类型。由于正在创建分离的签名，CMS SignedData内容类型不能封装Internet草稿。CMS分离签名在RFC 5485[IDSIG]中进行了总结。
The SignedData.SignerInfo.EncapsulatedContentInfo.eContentType value MUST identify the format of the Internet-Draft that is being signed. Section 5 of RFC 5485 [IDSIG] lists the file formats and the associated content type. This document expands that list as follows:
SignedData.SignerInfo.En封装ContentInfo.eContentType值必须标识正在签名的Internet草稿的格式。RFC 5485[IDSIG]第5节列出了文件格式和相关内容类型。本文件将该列表扩展如下：
File Format Content Type
----------- ------------
ASCII text id-ct-asciiTextWithCRLF
UTF-8 text (includes non-ASCII) id-ct-utf8TextWithCRLF
HyperText Markup Language (HTML) id-ct-htmlWithCRLF
EPUB id-ct-epub
Extensible Markup Language (XML) id-ct-xml
Portable Document Format (PDF) id-ct-pdf
PostScript id-ct-postscript
File Format Content Type
----------- ------------
ASCII text id-ct-asciiTextWithCRLF
UTF-8 text (includes non-ASCII) id-ct-utf8TextWithCRLF
HyperText Markup Language (HTML) id-ct-htmlWithCRLF
EPUB id-ct-epub
Extensible Markup Language (XML) id-ct-xml
Portable Document Format (PDF) id-ct-pdf
PostScript id-ct-postscript
The object identifiers associated with the content types listed above table are:
与上表列出的内容类型关联的对象标识符为：
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }
id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 }
id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 }
id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct 37 }
id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct 37 }
id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct 38 }
id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct 38 }
id-ct-epub OBJECT IDENTIFIER ::= { id-ct 39 }
id-ct-epub OBJECT IDENTIFIER ::= { id-ct 39 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
In general, the content of an Internet-Draft is treated like a single octet string for the generation of the digital signature. Unfortunately, the text and HTML files require canonicalization to avoid signature validation problems. The primary concern is the manner in which different operating systems indicate the end of a line of text. Some systems use a single new-line character, other systems use the combination of the carriage-return character followed by a line-feed character, and other systems use fixed-length records padded with space characters. For the digital signature to validate properly, a single convention must be employed.
一般来说，互联网草稿的内容被视为生成数字签名的单个八位字符串。不幸的是，文本和HTML文件需要规范化以避免签名验证问题。主要关注的是不同操作系统指示一行文本结尾的方式。一些系统使用单个新行字符，其他系统使用回车字符和换行字符的组合，其他系统使用填充空格字符的固定长度记录。为了正确验证数字签名，必须使用单一约定。
The canonicalization procedure follows the conventions used for text files in the File Transfer Protocol (FTP) [FTP]. Such files must be supported by FTP implementations, so code reuse seems likely.
规范化过程遵循文件传输协议（FTP）[FTP]中用于文本文件的约定。此类文件必须由FTP实现支持，因此代码重用似乎是可能的。
The canonicalization procedure converts the data from its internal character representation to the standard 8-bit NVT-ASCII representation (see TELNET [TELNET]). In accordance with the NVT standard, the <CRLF> sequence MUST be used to denote the end of a line of text. Using the standard NVT-ASCII representation means that data MUST be interpreted as 8-bit bytes.
规范化过程将数据从其内部字符表示形式转换为标准的8位NVT-ASCII表示形式（请参见TELNET[TELNET]）。根据NVT标准，<CRLF>序列必须用于表示文本行的结尾。使用标准NVT-ASCII表示法意味着数据必须解释为8位字节。
Trailing space characters MUST NOT appear on a line of text. That is, the space character must not be followed by the <CRLF> sequence.
尾随空格字符不得出现在文本行上。也就是说，空格字符后面不能跟有<CRLF>序列。
Thus, a blank line is represented solely by the <CRLF> sequence.
因此，空行仅由<CRLF>序列表示。
The form-feed nonprintable character (0x0C) is expected in Internet-Drafts. Other non-printable characters, such as tab and backspace, are not expected, but they do occur. Non-printable or non-ASCII characters (ones outside the range 0x20 to 0x7E) MUST NOT be changed in any way not covered by the rules for end-of-line handling in the previous paragraph.
Internet草稿中应包含表单馈送不可打印字符（0x0C）。其他不可打印的字符（如制表符和退格）是不需要的，但它们确实会出现。不可打印或非ASCII字符（0x20到0x7E范围之外的字符）不得以上一段中行尾处理规则未涵盖的任何方式进行更改。
Trailing blank lines MUST NOT appear at the end of the file. That is, the file must not end with multiple consecutive <CRLF> sequences.
尾随空行不得出现在文件末尾。也就是说，文件不能以多个连续的<CRLF>序列结尾。
In some environments, a Byte Order Mark (BOM) (U+FEFF) is used at the beginning of a file to indicate that it contains non-ASCII characters. In UTF-8 or HTML files, a BOM at the beginning of the file is not considered to be part of the file content. One or more consecutive leading BOMs, if present, MUST NOT be processed by the digital signature algorithm.
在某些环境中，在文件的开头使用字节顺序标记（BOM）（U+FEFF），以指示文件包含非ASCII字符。在UTF-8或HTML文件中，文件开头的BOM表不被视为文件内容的一部分。数字签名算法不得处理一个或多个连续的前导BOM（如果存在）。
Any end-of-file marker used by an operating system is not considered to be part of the file content. When present, such end-of-file markers MUST NOT be processed by the digital signature algorithm.
操作系统使用的任何文件结束标记都不被视为文件内容的一部分。如果存在这样的文件结束标记，则不能由数字签名算法处理。
Note: This text file canonicalization procedure is consistent with the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI].
注：此文本文件规范化程序与RFC 5198[UFNI]附录B中提供的NVT-ASCII定义一致。
Utilities that produce XML files are expected to follow the guidance provided by the World Wide Web Consortium (W3C) in Section 2.11 of [R20081126]. If this guidance is followed, no canonicalization is needed.
生成XML文件的实用程序应遵循万维网联盟（W3C）在[R20081126]第2.11节中提供的指南。如果遵循此指南，则无需规范化。
A robust signature generation process MAY perform canonicalization to ensure that the W3C guidance has been followed. This guidance says that a <LF> character MUST be used to denote the end of a line of text within an XML file. Therefore, any two-character <CRLF> sequence and any <CR> that is not followed by <LF> are to be translated to a single <LF> character.
稳健的签名生成过程可以执行规范化，以确保遵循W3C指南。本指南指出，必须使用<LF>字符来表示XML文件中文本行的结尾。因此，任何两个字符<CRLF>序列和任何未后跟<LF>的<CR>都将被转换为单个<LF>字符。
No canonicalization is needed for file formats currently used or planned for Internet-Drafts other than ASCII, UTF-8, HTML, and XML files. Other file formats, including PDF [PDF], PostScript [PS], and EPUB [EPUB] are treated as a simple sequence of octets by the digital signature algorithm.
除ASCII、UTF-8、HTML和XML文件外，当前用于或计划用于Internet草稿的文件格式不需要规范化。其他文件格式，包括PDF[PDF]、PostScript[PS]和EPUB[EPUB]被数字签名算法视为一个简单的八位字节序列。
IANA has registered object identifiers for three content types in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry as follows:
IANA已在“S/MIME CMS内容类型的SMI安全性（1.2.840.113549.1.9.16.1）”注册表中注册了三种内容类型的对象标识符，如下所示：
Description OID Specification
-----------------------------------------------------------------
id-ct-utf8TextWithCRLF 1.2.840.113549.1.9.16.1.37 [RFC8358]
id-ct-htmlWithCRLF 1.2.840.113549.1.9.16.1.38 [RFC8358]
id-ct-epub 1.2.840.113549.1.9.16.1.39 [RFC8358]
Description OID Specification
-----------------------------------------------------------------
id-ct-utf8TextWithCRLF 1.2.840.113549.1.9.16.1.37 [RFC8358]
id-ct-htmlWithCRLF 1.2.840.113549.1.9.16.1.38 [RFC8358]
id-ct-epub 1.2.840.113549.1.9.16.1.39 [RFC8358]
The security considerations in RFC 5485 [IDSIG] are unchanged.
RFC 5485[IDSIG]中的安全注意事项保持不变。
The deployment considerations in RFC 5485 [IDSIG] are unchanged.
RFC 5485[IDSIG]中的部署注意事项保持不变。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[CMS]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<https://www.rfc-editor.org/info/rfc5652>.
[EPUB] International Digital Publishing Forum, "EPUB Content Documents 3.1", January 2017, <http://www.idpf.org/epub/31/spec/epub-contentdocs.html>.
[EPUB]国际数字出版论坛，“EPUB内容文档3.1”，2017年1月<http://www.idpf.org/epub/31/spec/epub-contentdocs.html>.
[IDSIG] Housley, R., "Digital Signatures on Internet-Draft Documents", RFC 5485, DOI 10.17487/RFC5485, March 2009, <https://www.rfc-editor.org/info/rfc5485>.
[IDSIG]Housley，R.，“互联网文件草稿上的数字签名”，RFC 5485，DOI 10.17487/RFC5485，2009年3月<https://www.rfc-editor.org/info/rfc5485>.
[PDF] International Organization for Standardization, "Document management -- Electronic document file format for long-term preservation -- Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", ISO 19005-3:2012, 2012.
[PDF]国际标准化组织，“文件管理——长期保存的电子文件格式——第3部分：支持嵌入文件的ISO 32000-1的使用（PDF/A-3）”，ISO 19005-3:2012，2012。
[PS] Adobe Systems Incorporated, "PostScript Language Reference Manual, third edition", Addison-Wesley Publishing Company, ISBN 0-201-37922-8, 1999.
[PS]Adobe Systems Incorporated，“PostScript语言参考手册，第三版”，Addison-Wesley出版社，ISBN 0-201-37922-81999。
[R20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[R20081126]Bray，T.，Paoli，J.，Sperberg McQueen，M.，Maler，E.，和F.Yergeau，“可扩展标记语言（XML）1.0（第五版）”，万维网联盟建议REC-XML-20081126，2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126>.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[STDWORDS2] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STDWORDS2]Leiba，B.“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation One: Specification of Basic Notation", Recommendation X.680, ISO/IEC 8824-1:2002, 2002.
[X.680]ITU-T，“信息技术——抽象语法符号一：基本符号规范”，建议X.680，ISO/IEC 8824-1:2002，2002年。
[X.690] ITU-T, "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 International Standard 8825-1:2008, November 2008.
[X.690]ITU-T，“信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC国际标准8825-1:2008，2008年11月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.
[FTP]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，DOI 10.17487/RFC0959，1985年10月<https://www.rfc-editor.org/info/rfc959>.
[MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[MSG]Ramsdell，B.和S.Turner，“安全/多用途互联网邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<https://www.rfc-editor.org/info/rfc5751>.
[RFCED] Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, <https://www.rfc-editor.org/info/rfc7997>.
[RFCED]Flanagan，H.，Ed.，“RFC中非ASCII字符的使用”，RFC 7997，DOI 10.17487/RFC7997，2016年12月<https://www.rfc-editor.org/info/rfc7997>.
[RFCSERIES] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <https://www.rfc-editor.org/info/rfc6949>.
[RFC系列]Flanagan，H.和N.Brownlee，“RFC系列格式要求和未来发展”，RFC 6949，DOI 10.17487/RFC6949，2013年5月<https://www.rfc-editor.org/info/rfc6949>.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.
[TELNET]Postel，J.和J.Reynolds，“TELNET协议规范”，STD 8，RFC 854，DOI 10.17487/RFC0854，1983年5月<https://www.rfc-editor.org/info/rfc854>.
[UFNI] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[UFNI]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 5198，DOI 10.17487/RFC5198，2008年3月<https://www.rfc-editor.org/info/rfc5198>.
Acknowledgements
致谢
The idea for the Internet-Draft signature file came from a discussion with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful suggestions came from Jim Schaad, Pasi Eronen, Chris Newman, and Glen Barney. Glen Barney also played a key role in implementing Internet-Draft signatures as specified in RFC 5485 [IDSIG].
互联网签名草案文件的想法来自于与Scott Bradner在美国伊利诺伊州芝加哥IETF 69上的讨论。许多有用的建议来自Jim Schaad、Pasi Eronen、Chris Newman和Glen Barney。Glen Barney还在实施RFC 5485[IDSIG]中规定的互联网草案签名方面发挥了关键作用。
Author's Address
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America
美国弗吉尼亚州赫恩登斯普林诺尔大道918号Russell Housley Vigil Security有限责任公司，邮编：20170
Email: housley@vigilsec.com
Email: housley@vigilsec.com