Network Working Group R. Housley
Request for Comments: 5485 Vigil Security
Category: Informational March 2009
Network Working Group R. Housley
Request for Comments: 5485 Vigil Security
Category: Informational March 2009
Digital Signatures on Internet-Draft Documents
网上文件草稿上的数字签名
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document 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.
本文件规定了互联网草案上数字签名的约定。加密消息语法（CMS）用于创建分离的签名，该签名存储在单独的配套文件中，因此添加数字签名不会影响现有的实用程序。
This document specifies the conventions for storing a digital signature on Internet-Drafts. The Cryptographic Message Syntax (CMS) [CMS] is used to create a detached signature. The signature is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
本文件规定了在互联网草稿上存储数字签名的约定。加密消息语法（CMS）[CMS]用于创建分离的签名。签名存储在单独的附带文件中，因此添加数字签名不会影响现有的实用程序。
Shortly after the IETF Secretariat posts the Internet-Draft in the repository, the digital signature is generated and posted as a companion file in the same repository. 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 posted in the repository.
IETF秘书处在存储库中发布互联网草案后不久，数字签名将生成并作为一个附带文件发布在同一存储库中。数字签名允许任何人确认，自文档在存储库中发布以来，互联网草稿的内容未被更改。
The signature of the IETF Secretariat is intended to provide a straightforward way for anyone to determine whether a particular file contains the document that was made available by the IETF Secretariat. The signing-time included by the IETF Secretariat provides the wall-clock time; it is not intended to provide a trusted timestamp.
IETF秘书处的签名旨在为任何人提供一种直接的方式，以确定特定文件是否包含IETF秘书处提供的文件。IETF秘书处包含的签署时间提供了挂钟时间；它不打算提供可信的时间戳。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [STDWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
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 represent data structures. For example, both 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.
CMS使用抽象语法符号1（ASN.1）[X.680]。ASN.1是一种用于描述数据协议的正式符号，与实现所使用的编程语言无关。编码规则描述了ASN.1中定义的值在传输时的表示方式。基本编码规则（BER）[X.690]是应用最广泛的规则集，但它们提供了多种表示数据结构的方法。例如，支持定长编码和定长编码。当使用数字签名时，这种灵活性是不可取的。因此，发明了区分编码规则（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. A plain text file with a suffix of ".txt" is required. Other formats may also be provided, and they employ the appropriate suffix for the file format.
所有Internet草稿文件名都以连字符结尾，后跟两位数的版本号和后缀。后缀表示文件的类型。需要后缀为“.txt”的纯文本文件。还可以提供其他格式，并且它们为文件格式使用适当的后缀。
The companion signature file has exactly the same file name as the Internet-Draft, except that ".p7s" is added to the end. This file name suffix conforms to the conventions in [MSG]. Here are a few example names:
附带的签名文件与Internet草稿的文件名完全相同，只是末尾添加了“.p7s”。此文件名后缀符合[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.ps Signature File: draft-ietf-example-widgets-03.ps.p7s
互联网草稿：Draft-ietf-example-widgets-03.ps签名文件：Draft-ietf-example-widgets-03.ps.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 IETF Secretariat will post the signature file in the repository shortly after the Internet-Draft is posted.
互联网草稿发布后不久，IETF秘书处将在存储库中发布签名文件。
In general, the content of the Internet-Draft is treated like a single octet string for the generation of the digital signature. Unfortunately, the plain text file requires 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.
一般来说，互联网草稿的内容被视为生成数字签名的单个八位字符串。不幸的是，纯文本文件需要规范化以避免签名验证问题。主要关注的是不同操作系统指示一行文本结尾的方式。一些系统使用单个新行字符，其他系统使用回车字符和换行字符的组合，其他系统使用填充空格字符的固定长度记录。为了正确验证数字签名，必须使用单一约定。
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. Thus, a blank line is represented solely by the <CRLF> sequence.
尾随空格字符不得出现在文本行上。也就是说，空格字符后面不能跟有<CRLF>序列。因此，空行仅由<CRLF>序列表示。
The form-feed nonprintable character (0x0C) is expected in Internet-Drafts. Other nonprintable characters, such as tab and backspace, are not expected, but they do occur. For robustness, any nonprintable 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>序列结尾。
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 ASCII NVT definition offered in Appendix B of RFC 5198 [UFNI].
注：此文本文件规范化过程与RFC 5198[UFNI]附录B中提供的ASCII NVT定义一致。
In accordance with the guidance of the World Wide Web Consortium (W3C) in Section 2.11 of [R20060816], a <LF> character MUST be used to denote the end of a line of text within an XML file. Any two-character <CRLF> sequence and any <CR> that is not followed by <LF> are to be translated to a single <LF> character.
根据[R20060816]第2.11节中万维网联盟（W3C）的指导，必须使用<LF>字符表示XML文件中文本行的结尾。任何两个字符<CRLF>序列和任何未后跟<LF>的<CR>将被转换为单个<LF>字符。
No canonicalization is needed for file formats currently used for Internet-Drafts other than plain text files and XML files. Other file formats are treated as a simple sequence of octets by the digital signature algorithm.
除纯文本文件和XML文件外，当前用于Internet草稿的文件格式不需要规范化。数字签名算法将其他文件格式视为简单的八位字节序列。
CMS is used to construct the detached signature of the Internet-Draft. 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 by:
CMS用于构造Internet草稿的分离签名。CMS ContentInfo内容类型必须始终存在，并且必须封装CMS SignedData内容类型。由于正在创建分离的签名，CMS SignedData内容类型不能封装Internet草稿。CMS分离签名总结如下：
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Secretariat certificate(s)
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one signer
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Secretariat certificate(s)
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one signer
}
SignerInfo {
version CMSVersion, -- Always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Always present
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
SignerInfo {
version CMSVersion, -- Always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Always present
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
EncapsulatedContentInfo {
eContentType id-ct-asciiTextWithCRLF,
-- (1.2.840.113549.1.9.16.1.27)
eContent OCTET STRING -- Always absent
}
EncapsulatedContentInfo {
eContentType id-ct-asciiTextWithCRLF,
-- (1.2.840.113549.1.9.16.1.27)
eContent OCTET STRING -- Always absent
}
The CMS requires the outer-most encapsulation to be ContentInfo [CMS]. The fields of ContentInfo are used as follows:
CMS要求最外层的封装为ContentInfo[CMS]。ContentInfo的字段使用如下：
contentType indicates the type of the associated content. For the detached Internet-Draft signature file, the encapsulated type is always SignedData, so the id-signedData (1.2.840.113549.1.7.2) object identifier MUST be present in this field.
contentType指示关联内容的类型。对于分离的Internet草稿签名文件，封装类型始终为SignedData，因此此字段中必须存在id SignedData（1.2.840.113549.1.7.2）对象标识符。
content holds the content. For the detached Internet-Draft signature file, the content is always a SignedData content.
内容保存内容。对于分离的Internet草稿签名文件，内容始终是SignedData内容。
The SignedData content type [CMS] contains the signature of the Internet-Draft and information to aid in the validation of that signature. The fields of SignedData are used as follows:
SignedData内容类型[CMS]包含互联网草稿的签名以及帮助验证该签名的信息。SignedData的字段使用如下：
version is the syntax version number. For this specification, the version number MUST be set to 3.
version是语法版本号。对于本规范，版本号必须设置为3。
digestAlgorithms is a collection of one-way hash function identifiers. It MUST contain the identifier used by the IETF Secretariat to generate the digital signature. See the discussion of digestAlgorithm in Section 3.2.1.
digestAlgorithms是单向哈希函数标识符的集合。它必须包含IETF秘书处用于生成数字签名的标识符。见第3.2.1节中对算法的讨论。
encapContentInfo is the signed content, including a content type identifier. Since a detached signature is being created, it does not encapsulate the Internet-Draft. The use of the EncapsulatedContentInfo type is discussed further in Section 3.2.2.
encapContentInfo是已签名的内容，包括内容类型标识符。由于正在创建分离的签名，因此它不会封装Internet草稿。第3.2.2节将进一步讨论封装ContentInfo类型的使用。
certificates is an optional collection of certificates. It SHOULD include the X.509 certificate needed to validate the digital signature value. Certification Authority (CA) certificates and end entity certificates MUST conform to the certificate profile specified in [PKIX1].
证书是证书的可选集合。它应该包括验证数字签名值所需的X.509证书。证书颁发机构（CA）证书和最终实体证书必须符合[PKIX1]中指定的证书配置文件。
crls is an optional collection of certificate revocation lists (CRLs). It SHOULD NOT include any CRLs; however, any CRLs that are present MUST conform to the CRL profile specified in [PKIX1].
crls是证书吊销列表（CRL）的可选集合。不应包括任何CRL；但是，存在的任何CRL必须符合[PKIX1]中指定的CRL配置文件。
signerInfos is a collection of per-signer information. For this specification, each item in the collection must represent the IETF Secretariat. More than one SignerInfo MAY appear to facilitate transitions between keys or algorithms. The use of the SignerInfo type is discussed further in Section 3.2.1.
signerInfos是每个签名者信息的集合。对于本规范，集合中的每个项目必须代表IETF秘书处。可能会出现多个SignerInfo来促进键或算法之间的转换。第3.2.1节将进一步讨论SignerInfo类型的使用。
The IETF Secretariat is represented in the SignerInfo type. The fields of SignerInfo are used as follows:
IETF秘书处以SignerInfo类型表示。SignerInfo的字段使用如下：
version is the syntax version number. In this specification, the version MUST be set to 3.
version是语法版本号。在本规范中，版本必须设置为3。
sid identifies the IETF Secretariat's public key. In this specification, the subjectKeyIdentifier alternative is always used, which identifies the public key directly. This identifier MUST match the value included in the subjectKeyIdentifier certificate extension in the IETF Secretariat's X.509 certificate.
sid标识IETF秘书处的公钥。在本规范中，始终使用subjectKeyIdentifier替代项，它直接标识公钥。此标识符必须与IETF秘书处X.509证书中subjectKeyIdentifier证书扩展中包含的值匹配。
digestAlgorithm identifies the one-way hash function, and any associated parameters, used by the IETF Secretariat to generate the digital signature.
digestAlgorithm识别IETF秘书处用于生成数字签名的单向散列函数和任何相关参数。
signedAttrs is an optional set of attributes that are signed along with the content. The signedAttrs are optional in the CMS, but signedAttrs is required by this specification. The SET OF Attribute must be encoded with the distinguished encoding rules (DER) [X.690]. Section 3.2.3 of this document lists the signed attributes that MUST be included in the collection. Other signed attributes MAY also be included.
signedAttrs是随内容一起签名的一组可选属性。SignedAttr在CMS中是可选的，但本规范要求SignedAttr。属性集必须使用可分辨编码规则（DER）[X.690]进行编码。本文件第3.2.3节列出了必须包含在集合中的已签名属性。还可以包括其他签名属性。
signatureAlgorithm identifies the digital signature algorithm, and any associated parameters, used by the IETF Secretariat to generate the digital signature.
signatureAlgorithm识别IETF秘书处用于生成数字签名的数字签名算法和任何相关参数。
signature is the digital signature value generated by the IETF Secretariat.
签名是IETF秘书处生成的数字签名值。
unsignedAttrs is an optional set of attributes that are not signed. Unsigned attributes are usually omitted; however, the unsigned attributes MAY hold a trusted timestamp generated in accordance with [TSP]. Appendix A of [TSP] provides more information about this unsigned attribute.
unsignedAttrs是一组可选的未签名属性。无符号属性通常被省略；然而，未签名属性可能持有根据[TSP]生成的可信时间戳。[TSP]的附录A提供了有关此未签名属性的更多信息。
The EncapsulatedContentInfo structure contains a content type identifier. Since a detached signature is being created, it does not encapsulate the Internet-Draft. The fields of EncapsulatedContentInfo are used as follows:
封装的ContentInfo结构包含内容类型标识符。由于正在创建分离的签名，因此它不会封装Internet草稿。封装的ContentInfo字段的使用方式如下：
eContentType is an object identifier that uniquely specifies the content type. The content type associated with the plain text file MUST be id-ct-asciiTextWithCRLF. Other file formats may also be posted, and the appropriate content type for each format is discussed in Section 4. Additional file formats can be added if the Internet community chooses.
eContentType是唯一指定内容类型的对象标识符。与纯文本文件关联的内容类型必须为id ct asciiTextWithCRLF。也可以发布其他文件格式，第4节讨论了每种格式的适当内容类型。如果Internet社区选择，可以添加其他文件格式。
eContent is optional. When an encapsulated signature is generated, the content to be signed is carried in this field. Since a detached signature is being created, eContent MUST be absent.
eContent是可选的。生成封装的签名时，将在该字段中携带要签名的内容。由于正在创建分离的签名，因此必须缺少eContent。
The IETF Secretariat MUST digitally sign a collection of attributes along with the Internet-Draft. Each attribute in the collection MUST be DER-encoded. The syntax for attributes is defined in [X.501], and the X.500 Directory provides a rich attribute syntax. A very simple subset of this syntax is used extensively in [CMS], where ATTRIBUTE.&Type and ATTRIBUTE.&id are the only parts of the ATTRIBUTE class that are employed.
IETF秘书处必须对属性集合以及互联网草稿进行数字签名。集合中的每个属性都必须进行DER编码。属性的语法在[X.501]中定义，X.500目录提供了丰富的属性语法。此语法的一个非常简单的子集在[CMS]中广泛使用，其中ATTRIBUTE.&Type和ATTRIBUTE.&id是使用的属性类的唯一部分。
Each of the attributes used with this CMS profile has a single attribute value. Even though the syntax is defined as a SET OF AttributeValue, there MUST be exactly one instance of AttributeValue present.
此CMS配置文件使用的每个属性都有一个属性值。即使语法定义为一组AttributeValue，也必须只存在一个AttributeValue实例。
The SignedAttributes syntax within signerInfo is defined as a SET OF Attribute. The SignedAttributes MUST include only one instance of any particular attribute.
signerInfo中的SignedAttributes语法定义为一组属性。SignedAttribute只能包含任何特定属性的一个实例。
The IETF Secretariat MUST include the content-type, message-digest, and signing-time attributes. The IETF Secretariat MAY also include the binary-signing-time signed attribute as well as any other attribute that is deemed appropriate. The intent is to allow additional signed attributes to be included if a future need is identified. This does not cause an interoperability concern because unrecognized signed attributes are ignored at verification.
IETF秘书处必须包括内容类型、消息摘要和签名时间属性。IETF秘书处还可以包括二进制签名时间签名属性以及任何其他被认为合适的属性。这样做的目的是，如果确定了未来的需求，则允许包含附加的已签名属性。这不会引起互操作性问题，因为在验证时会忽略未识别的签名属性。
A content-type attribute is required to contain the same object identifier as the content type contained in the EncapsulatedContentInfo. The appropriate content type for each format is discussed in Section 4. The IETF Secretariat MUST include a content-type attribute containing the appropriate content type. Section 11.1 of [CMS] defines the content-type attribute.
内容类型属性必须包含与封装的ContentInfo中包含的内容类型相同的对象标识符。第4节讨论了每种格式的适当内容类型。IETF秘书处必须包含包含适当内容类型的内容类型属性。[CMS]第11.1节定义了内容类型属性。
The IETF Secretariat MUST include a message-digest attribute, having as its value the output of a one-way hash function computed on the Internet-Draft that is being signed. Section 11.2 of [CMS] defines the message-digest attribute.
IETF秘书处必须包含一个消息摘要属性，其值为在正在签名的Internet草稿上计算的单向散列函数的输出。[CMS]第11.2节定义了消息摘要属性。
The IETF Secretariat MUST include a signing-time attribute, specifying the time, based on the local system clock, at which the digital signature was applied to the Internet-Draft. Since the IETF Secretariat may choose to perform signatures in batches, the signing-time may be several hours or days after the time that the Internet-Draft was actually posted. Section 11.3 of [CMS] defines the content-type attribute.
IETF秘书处必须包含签名时间属性，根据本地系统时钟指定数字签名应用于互联网草稿的时间。由于IETF秘书处可以选择分批进行签名，签名时间可能是互联网草稿实际发布后的数小时或数天。[CMS]第11.3节定义了内容类型属性。
The IETF Secretariat MAY include a binary-signing-time attribute, specifying the time at which the digital signature was applied to the Internet-Draft. If present, the time that is represented MUST match the time represented in the signing-time attribute. The binary-signing-time attribute is defined in [BinTime].
IETF秘书处可包括二进制签名时间属性，指定数字签名应用于互联网草稿的时间。如果存在，则表示的时间必须与签名时间属性中表示的时间匹配。二进制签名时间属性在[BinTime]中定义。
Unsigned attributes are usually omitted. However, an unsigned attribute MAY hold a trusted timestamp generated in accordance with [TSP]. The idea is to timestamp the IETF Secretariat digital signature to prove that it was created before a given time. If the IETF Secretariat's certificate is revoked the timestamp allows a verifier to know whether the signature was created before or after the revocation date. Appendix A of [TSP] defines the signature time-stamp attribute that can be used to timestamp a digital signature.
无符号属性通常被省略。然而，未签名属性可能持有根据[TSP]生成的可信时间戳。这个想法是给IETF秘书处的数字签名加上时间戳，以证明它是在给定时间之前创建的。如果IETF秘书处的证书被撤销，则时间戳允许验证者知道签名是在撤销日期之前还是之后创建的。[TSP]的附录A定义了可用于为数字签名添加时间戳的签名时间戳属性。
This section lists the content types that are used in this specification. The eContentType field as described in Section 3.2.2 contains a content type identifier, and the same value appears in the content-type attribute as described in Section 3.2.3.1.
本节列出了本规范中使用的内容类型。第3.2.2节中所述的eContentType字段包含内容类型标识符，内容类型属性中显示的值与第3.2.3.1节中所述的值相同。
The following table lists the file formats and the associated content type.
下表列出了文件格式和关联的内容类型。
File Format Content Type
----------- ------------
Plain text id-ct-asciiTextWithCRLF
Extensible Markup Language (XML) id-ct-xml
Portable Document Format (PDF) id-ct-pdf
PostScript id-ct-postscript
File Format Content Type
----------- ------------
Plain text id-ct-asciiTextWithCRLF
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 in the 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-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 }
The IETF Secretariat MUST protect its private key. The use of a hardware security module (HSM) is strongly RECOMMENDED because compromise of the IETF Secretariat's private key permits masquerade.
IETF秘书处必须保护其私钥。强烈建议使用硬件安全模块（HSM），因为IETF秘书处私钥的泄露允许伪装。
The IETF Secretariat currently maintains servers at a primary location and a backup location. This configuration requires two HSMs, one at each location. However, the two HSMs do not need to use the same signing key. Each HSM can have a different signing key, as long as each one has their own certificate.
IETF秘书处目前在主位置和备份位置维护服务器。此配置需要两个HSM，每个位置一个。但是，两个HSM不需要使用相同的签名密钥。每个HSM可以有不同的签名密钥，只要每个HSM都有自己的证书。
The generation of a public/private key pair for signature operations relies on random number generation. The use of an inadequate pseudo-random number generator (PRNG) can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the key pair, searching the resulting small set of possibilities, than to brute-force search the whole private key space. The generation of quality random numbers is difficult, but [RANDOM] offers important guidance in this area.
签名操作的公钥/私钥对的生成依赖于随机数生成。使用不适当的伪随机数生成器（PRNG）可能导致很少或没有安全性。攻击者可能会发现，复制生成密钥对的PRNG环境，搜索产生的一小部分可能性，比暴力搜索整个私钥空间要容易得多。生成高质量随机数很困难，但[随机]在这方面提供了重要的指导。
The IETF Secretariat should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular digital signature algorithm or one-way hash function will be reduced. Therefore, it SHOULD be possible to migrate these algorithms. That is, the IETF Secretariat SHOULD be prepared for the supported algorithms to change over time.
IETF秘书处应意识到，随着时间的推移，加密算法变得越来越弱。随着新的密码分析技术的发展和计算性能的提高，破坏特定数字签名算法或单向散列函数的工作因素将减少。因此，应该可以迁移这些算法。也就是说，IETF秘书处应准备好支持的算法随时间变化。
The IETF Secretariat must take care to use the correct time in signing-time and binary-signing-time attributes. The inclusion of a date within the Internet-Draft by the authors that is shortly before the signing time attributes supplied by the IETF Secretariat provides confidence about the date that the Internet-Draft was posted to the repository. However, the IETF Secretariat may choose to perform signatures in batches, and the signing-time may be several hours or days after the time that the Internet-Draft was actually posted.
IETF秘书处必须注意在签名时间和二进制签名时间属性中使用正确的时间。在IETF秘书处提供的签署时间属性之前不久，作者在互联网草稿中加入了一个日期，这为互联网草稿发布到存储库的日期提供了信心。然而，IETF秘书处可以选择分批进行签名，签名时间可能是互联网草稿实际发布后的几个小时或几天。
As stated above, the IETF Secretariat may choose to sign Internet-Drafts in batches. This allows a single HSM to be used if multiple servers are located in one geographic location, and it allows the HSM to be off-line except when signatures are being generated. Further, this allows the IETF Secretariat to include manual steps, such as entering an HSM passphrase or inserting a smartcard, as part of the signing procedure to improve operations security.
如上所述，IETF秘书处可以选择批量签署互联网草案。如果多台服务器位于一个地理位置，则允许使用单个HSM，并且允许HSM离线，除非生成签名。此外，这允许IETF秘书处将手动步骤包括在内，例如输入HSM密码或插入智能卡，作为签名程序的一部分，以提高操作安全性。
The private key used to generate the IETF Secretariat signature ought to be stored in an HSM to provide protection from unauthorized disclosure. While the HSM will be operated by the IETF Secretariat, it ought to be owned by the IETF Trust. Accordingly, the Trustees of the IETF Trust will designate an appropriate certification authority
用于生成IETF秘书处签名的私钥应存储在HSM中，以防止未经授权的披露。虽然HSM将由IETF秘书处运营，但应归IETF信托所有。因此，IETF信托的受托人将指定适当的认证机构
to issue a certificate to the IETF Secretariat, and they will approve any procedures used by the IETF Secretariat for signing documents consistent with this specification.
向IETF秘书处颁发证书，他们将批准IETF秘书处用于签署符合本规范的文件的任何程序。
A detached signature is used for all file formats. Some file formats, such as PDF and XML, have file-format-specific ways of handling digital signatures. These file-format-specific approaches are not used for two reasons. First, a single way to sign Internet-Drafts will ease implementation by the IETF Secretariat. Second, if the author includes a signature using one of these file-format-specific approaches, the IETF Secretariat signature does not harm it in any way.
分离的签名用于所有文件格式。一些文件格式（如PDF和XML）具有处理数字签名的特定于文件格式的方法。由于两个原因，没有使用这些特定于文件格式的方法。首先，签署互联网草案的单一方式将简化IETF秘书处的实施。第二，如果作者使用这些特定于文件格式的方法之一包含签名，IETF秘书处签名不会以任何方式损害签名。
File names are the means linking the detached signature to the signed document. A CMS signed attribute could have been specified to include another form of linkage, and this could be added in the future. At this point in time, it is important to support signature validation of expired Internet-Drafts that are obtained from non-IETF repositories. Therefore, the appropriate value for such a signed attribute is unclear. This specification allows an Internet-Draft and companion signature file to be stored anywhere without hindering signature validation.
文件名是将分离的签名链接到已签名文档的方法。CMS签名属性可以被指定为包含另一种形式的链接，这可以在将来添加。此时，支持从非IETF存储库获取的过期Internet草稿的签名验证非常重要。因此，这种有符号属性的适当值不清楚。本规范允许在不妨碍签名验证的情况下，将Internet草稿和配套签名文件存储在任何位置。
The idea for the Internet-Draft signature file came from a discussion with Scott Bradner at IETF 69 in Chicago. Many helpful suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman.
互联网签名文件草案的想法来自于芝加哥IETF 69与Scott Bradner的讨论。Jim Schaad、Pasi Eronen和Chris Newman提出了许多有用的建议。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 38522004年7月。
[PKIX1] 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.
[PKIX1]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[X.680] ITU-T Recommendation X.680: ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation, 2002.
[X.680]ITU-T建议X.680:ISO/IEC 8824-1:2002，信息技术-抽象语法符号1（ASN.1）：基本符号规范，2002。
[X.690] ITU-T Recommendation X.690: ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 2002.
[X.690]ITU-T建议X.690:ISO/IEC 8825-1:2002，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范，2002。
[BinTime] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 4049, April 2005.
[BinTime]Housley，R.，“二进制时间：在ASN.1中表示日期和时间的另一种格式”，RFC 4049，2005年4月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，1985年10月。
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[MSG]Ramsdell，B.，编辑，“安全/多用途互联网邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[OpenSSL] "OpenSSL: The Open Source toolkit for SSL/TLS", http://www.openssl.org/.
[OpenSSL]“OpenSSL:SSL/TLS的开源工具包”，http://www.openssl.org/.
[R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, 16 August 2006, http://www.w3.org/TR/2006/REC-xml-20060816/.
[R20060816]Bray，T.，J.Paoli，C.M.Sperberg McQueen，E.Maler和F.Yergeau，“可扩展标记语言（XML）1.0（第四版）”，W3C建议，2006年8月16日，http://www.w3.org/TR/2006/REC-xml-20060816/.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TELNET]Postel，J.和J.Reynolds，“TELNET协议规范”，STD 8，RFC 854，1983年5月。
[TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[TSP]Adams，C.，Cain，P.，Pinkas，D.，和R.Zuccherato，“互联网X.509公钥基础设施时间戳协议（TSP）”，RFC 31612001年8月。
[UFNI] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[UFNI]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X.501]ITU-T建议X.501：信息技术-开放系统互连-目录：模型，1993年。
Appendix: A
附录：A
OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS. The following command line can be used to verify an Internet-Draft signature:
OpenSSL 0.9.9[OpenSSL]包括CMS的一个实现。以下命令行可用于验证Internet草稿签名：
openssl cms -verify -CAfile <cert-file> -content <internet-draft> /
-inform DER -in <p7s-file> -out /dev/null
openssl cms -verify -CAfile <cert-file> -content <internet-draft> /
-inform DER -in <p7s-file> -out /dev/null
The arguments need to be provided as follows:
需要提供如下参数：
<cert-file> the name of the file containing the trust anchor, which is typically the self-signed certificate of the certification authority that issued a certificate to the IETF Secretariat.
<cert file>包含信任锚的文件的名称，通常是向IETF秘书处颁发证书的证书颁发机构的自签名证书。
<internet-draft> the name of the file containing the Internet-Draft after canonicalization.
<internet草稿>规范化后包含internet草稿的文件的名称。
<p7s-file> the name of the file containing the detached signature that was generated in accordance with this specification.
<p7s file>包含根据本规范生成的分离签名的文件名。
Author's Address
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com