Independent Submission A. Santoni
Request for Comments: 5544 Actalis S.p.A.
Category: Informational February 2010
ISSN: 2070-1721
Independent Submission A. Santoni
Request for Comments: 5544 Actalis S.p.A.
Category: Informational February 2010
ISSN: 2070-1721
Syntax for Binding Documents with Time-Stamps
使用时间戳绑定文档的语法
Abstract
摘要
This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time-stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed.
本文件描述了一种信封，可用于将文件（不一定通过加密技术进行保护）与为该文件获得的一个或多个时间戳令牌绑定，其中“时间戳令牌”具有RFC 3161或其继承者中定义的含义。还允许使用其他类型的时间证据。
The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652.
建议的信封基于RFC 5652中定义的加密消息语法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc5544.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5544.
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The standards track specification RFC 4998, Evidence Record Syntax (ERS), specifies an alternative mechanism. Readers are encouraged to also review RFC 4998 when evaluating the suitability of this mechanism.
本RFC不适用于任何级别的互联网标准。标准跟踪规范RFC 4998，证据记录语法（ERS），规定了一种替代机制。在评估该机制的适用性时，鼓励读者也查看RFC 4998。
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定（http:truster.IETF.org/license info）的约束，这些法律规定在本文件出版之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Syntax for TimeStampedData ......................................3
3. Compliance Requirements .........................................6
4. Recommended Processing ..........................................6
4.1. Generating a New TimeStampedData Structure .................7
4.2. Verifying an Existing TimeStampedData Structure ............8
4.3. Extending the Validity of an Existing
TimeStampedData Structure ..................................9
5. Security Considerations .........................................9
6. Normative References ...........................................10
7. Informative References .........................................10
Appendix A. ASN.1 Module ..........................................11
Appendix B. Acknowledgments .......................................12
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Syntax for TimeStampedData ......................................3
3. Compliance Requirements .........................................6
4. Recommended Processing ..........................................6
4.1. Generating a New TimeStampedData Structure .................7
4.2. Verifying an Existing TimeStampedData Structure ............8
4.3. Extending the Validity of an Existing
TimeStampedData Structure ..................................9
5. Security Considerations .........................................9
6. Normative References ...........................................10
7. Informative References .........................................10
Appendix A. ASN.1 Module ..........................................11
Appendix B. Acknowledgments .......................................12
Time-stamping has become the standard technique for proving the existence of a document before a certain point in time. Several legislations around the world embrace the concept and provide for time-stamping services, mainly for the purpose of extending the validity of signed documents. However, while time-stamping enhances digital signatures, its value does not depend on them. It can clearly be useful to time-stamp a document even if it is not signed. And it can also be useful, or even mandatory in some cases, to time-stamp a signed document in its entirety, regardless of how many signatures it contains.
时间戳已成为证明文件在某一时间点之前存在的标准技术。世界各地的一些立法采纳了这一概念，并规定了时间戳服务，主要目的是延长已签署文件的有效期。然而，虽然时间戳增强了数字签名，但其价值并不取决于它们。很明显，即使文档未签名，也可以在文档上加盖时间戳。而且，在某些情况下，对已签名的文档进行完整的时间戳也是有用的，甚至是强制性的，无论它包含多少签名。
When a time-stamp is related to a digital signature, there already exists a way to keep the two pieces together: RFC 3161 [TSP] describes how one or more TimeStampTokens can be included in a SignerInfo structure as unsigned attributes. On the other hand, there is no standard way to keep together a time-stamped document, whether signed or not, and the related time-stamps.
当时间戳与数字签名相关时，已经有一种方法可以将这两部分保持在一起：RFC 3161[TSP]描述了如何将一个或多个时间戳作为未签名属性包含在SignerInfo结构中。另一方面，没有标准的方法将带有时间戳的文件（无论是否签名）和相关的时间戳保存在一起。
In such cases, two approaches are typically being adopted:
在这种情况下，通常采用两种方法：
o time-stamps are kept as separate files (keeping track of what time-stamps belong to what documents is up to the user);
o 时间戳作为单独的文件保存（由用户跟踪哪些时间戳属于哪些文档）；
o an ad hoc solution is adopted for specific applications, e.g., a ZIP archive or a proprietary "envelope" of some kind.
o 对于特定的应用，采用了特别的解决方案，例如ZIP存档或某种专有“信封”。
Both solutions impede interoperability, which is the objective of this memo.
这两种解决方案都会妨碍互操作性，这是本备忘录的目标。
This document describes a simple syntax for binding one document (actually, any kind of file) to the corresponding temporal evidence; the latter is typically represented by one or more RFC 3161 TimeStampTokens. Additional types of temporal evidence, e.g., an RFC 4998 EvidenceRecord [ERS], are also supported via an "open" syntax. However, for the sake of interoperability, the emphasis in this document is on TimeStampTokens.
本文档描述了将一个文档（实际上是任何类型的文件）绑定到相应的时间证据的简单语法；后者通常由一个或多个RFC 3161时间标记表示。还通过“开放”语法支持其他类型的时间证据，例如RFC 4998证据记录[ERS]。然而，为了实现互操作性，本文档的重点是时间标记。
The proposed syntax is broadly based on the Cryptographic Message Syntax (CMS) defined in RFC 5652 [CMS].
建议的语法大体上基于RFC 5652[CMS]中定义的加密消息语法（CMS）。
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 [KWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[KWORDS]中所述进行解释。
The terms "document" and "file" are used interchangeably. The terms "TimeStampToken" and "time-stamp token" are used interchangeably, both referring to the data structure defined in RFC 3161.
术语“文档”和“文件”可以互换使用。术语“时间戳令牌”和“时间戳令牌”互换使用，两者均指RFC 3161中定义的数据结构。
The proposed data structure is called TimeStampedData, and it is based on the ContentInfo envelope defined in [CMS]:
建议的数据结构称为TimeStampedData，它基于[CMS]中定义的ContentInfo信封：
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
While CMS defines six content types (data, signed-data, enveloped-data, digested-data, encrypted-data, and authenticated-data), this memo defines an additional content type, timestamped-data, identified by the following Object Identifier (OID):
CMS定义了六种内容类型（数据、签名数据、信封数据、摘要数据、加密数据和认证数据），而本备忘录定义了一种额外的内容类型，即时间戳数据，由以下对象标识符（OID）标识：
id-ct-timestampedData OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) id-smime(16) id-ct(1) 31 }
id-ct-timestampedData OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) id-smime(16) id-ct(1) 31 }
This particular OID signals that the content field of the ContentInfo has the following syntax:
此特定OID表示ContentInfo的内容字段具有以下语法：
TimeStampedData ::= SEQUENCE {
version INTEGER { v1(1) },
dataUri IA5String OPTIONAL,
metaData MetaData OPTIONAL,
content OCTET STRING OPTIONAL,
temporalEvidence Evidence
}
TimeStampedData ::= SEQUENCE {
version INTEGER { v1(1) },
dataUri IA5String OPTIONAL,
metaData MetaData OPTIONAL,
content OCTET STRING OPTIONAL,
temporalEvidence Evidence
}
MetaData ::= SEQUENCE {
hashProtected BOOLEAN,
fileName UTF8String OPTIONAL,
mediaType IA5String OPTIONAL,
otherMetaData Attributes OPTIONAL
}
MetaData ::= SEQUENCE {
hashProtected BOOLEAN,
fileName UTF8String OPTIONAL,
mediaType IA5String OPTIONAL,
otherMetaData Attributes OPTIONAL
}
Attributes ::=
SET SIZE(1..MAX) OF Attribute -- according to RFC 5652
Attributes ::=
SET SIZE(1..MAX) OF Attribute -- according to RFC 5652
Evidence ::= CHOICE {
tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161
ersEvidence [1] EvidenceRecord, -- see RFC 4998
otherEvidence [2] OtherEvidence
}
Evidence ::= CHOICE {
tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161
ersEvidence [1] EvidenceRecord, -- see RFC 4998
otherEvidence [2] OtherEvidence
}
OtherEvidence ::= SEQUENCE {
oeType OBJECT IDENTIFIER,
oeValue ANY DEFINED BY oeType }
OtherEvidence ::= SEQUENCE {
oeType OBJECT IDENTIFIER,
oeValue ANY DEFINED BY oeType }
TimeStampTokenEvidence ::=
SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL
TimeStampTokenEvidence ::=
SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL
TimeStampAndCRL ::= SEQUENCE {
timeStamp TimeStampToken, -- according to RFC 3161
crl CertificateList OPTIONAL -- according to RFC 5280
}
TimeStampAndCRL ::= SEQUENCE {
timeStamp TimeStampToken, -- according to RFC 3161
crl CertificateList OPTIONAL -- according to RFC 5280
}
The version field contains the version number of the TimeStampedData syntax. It SHALL be 1 for this version of the document.
version字段包含TimeStampedData语法的版本号。此版本的文件应为1。
The dataUri field contains a URI reference conforming to [URI]. When the content field is absent, dataUri MUST be present and contain a URI allowing retrieval of the document that was time-stamped (unless the document is later moved). When the content field is present, this field MAY also be present.
dataUri字段包含符合[URI]的URI引用。当内容字段不存在时，dataUri必须存在并包含允许检索带时间戳的文档的URI（除非稍后移动文档）。当内容字段存在时，此字段也可能存在。
The metaData field contains metadata related to the document that was time-stamped, if applicable. In particular:
元数据字段包含与带时间戳的文档相关的元数据（如果适用）。特别地：
The hashProtected field indicates whether the metadata have been included in the computation of the digest within the first TimeStampToken (see further on). This makes it possible to detect a subsequent alteration of the metadata.
hashProtected字段指示元数据是否已包含在第一个timestaken内的摘要计算中（请参阅下文）。这使得检测元数据的后续更改成为可能。
The fileName field contains the original filename of the document that was time-stamped.
文件名字段包含带时间戳的文档的原始文件名。
The mediaType field contains a media type/subtype and possible parameters for the time-stamped document, according to [MIME]. This information may help decide how to "open" or deal with the time-stamped document.
根据[MIME]，mediaType字段包含时间戳文档的媒体类型/子类型和可能的参数。此信息可能有助于决定如何“打开”或处理带时间戳的文档。
The otherMetaData field contains further attributes of the time-stamped document (e.g., a description, claimed author, etc.), where each attribute is specified by an object identifier and a corresponding set of values, as described in [CMS]. When this field is present, it MUST contain at least one Attribute.
otherMetaData字段包含时间戳文档的其他属性（例如，描述、声称的作者等），其中每个属性由对象标识符和对应的一组值指定，如[CMS]中所述。存在此字段时，它必须至少包含一个属性。
Within the metaData field (if present), at least one of the fileName, mediaType, and otherMetaData sub-fields MUST be present.
在元数据字段（如果存在）中，必须至少存在文件名、mediaType和其他元数据子字段中的一个。
The Attribute values within the otherMetaData field MUST be DER encoded, even if the rest of the structure is BER encoded.
otherMetaData字段中的属性值必须进行DER编码，即使结构的其余部分是BER编码的。
The content field, when present, carries the entire contents, in its original format and encoding, of the document that was time-stamped. This can actually be any kind of data, e.g., a text document, an executable, a movie, a message, etc. The omission of the content field makes it possible to bind the temporal evidence to external data. In such a case, the temporal evidence is computed as though the content field were present.
内容字段（如果存在）以原始格式和编码携带带时间戳的文档的全部内容。这实际上可以是任何类型的数据，例如文本文档、可执行文件、电影、消息等。省略内容字段使得可以将时间证据绑定到外部数据。在这种情况下，时间证据的计算就好像内容字段存在一样。
The temporalEvidence field carries the evidence that the time-stamped document did exist before a certain point in time. Several types of evidence are allowed, but compliant applications are only required to support the RFC 3161 type -- namely, the tstEvidence choice.
temporalEvidence字段携带时间戳文档在某个时间点之前确实存在的证据。允许使用几种类型的证据，但兼容的应用程序只需要支持RFC 3161类型，即tstEvidence选项。
The TimeStampTokenEvidence sequence MUST contain at least one element of type TimeStampAndCRL.
TimeStampTokenEvidence序列必须至少包含一个TimeStampAndCRL类型的元素。
The elements of the TimeStampTokenEvidence sequence MUST conform to the following rule:
时间戳标记证据序列的元素必须符合以下规则：
o if the metaData field is absent or the value of its hashProtected field is FALSE, then the TimeStampToken within the first element SHALL be computed over the value octets of the content field (if this field is absent, use the octets retrieved via the dataUri field);
o 如果元数据字段不存在或其hashProtected字段的值为FALSE，则第一个元素中的TimeStampToken应在内容字段的值八位字节上计算（如果该字段不存在，则使用通过dataUri字段检索的八位字节）；
o otherwise (the metaData field is present and the value of its hashProtected field is TRUE), the TimeStampToken within the first element SHALL be computed over the concatenation of the following fields:
o 否则（元数据字段存在且其hashProtected字段的值为TRUE），应通过以下字段的串联计算第一个元素中的TimeStampToken：
- the DER encoding of the metaData field;
- 元数据字段的DER编码；
- the value octets of the content field (if this field is absent, use the octets retrieved via the dataUri field);
- 内容字段的值八位字节（如果该字段不存在，则使用通过dataUri字段检索的八位字节）；
o the TimeStampToken within the second element SHALL be computed over the first element;
o 应在第一个元素上计算第二个元素内的时间标记；
o the TimeStampToken within each subsequent element SHALL be computed over its preceding element in the sequence.
o 每个后续元素中的TimeStampToken应在序列中的前一个元素上计算。
Within the TimeStampAndCRL construct, the optional crl field carries a suitable CRL (Certificate Revocation List) demonstrating that the certificate of the TSA (Time-Stamping Authority) that issued the TimeStampToken was not revoked at the time when the subsequent element in the TimeStampTokenEvidence sequence was added. See the Security Considerations section for further discussion on this topic.
在TIMESTANDCRL构造中，可选的crl字段携带合适的crl（证书吊销列表），证明在添加TIMESTANDETKENCE序列中的后续元素时，颁发TIMESTANDKEN的TSA（时间戳颁发机构）的证书未被吊销。有关此主题的进一步讨论，请参阅“安全注意事项”部分。
Compliant applications MUST support at least the RFC 3161-based type of evidence (i.e., the tstEvidence CHOICE).
符合要求的应用程序必须至少支持基于RFC 3161的证据类型（即tstEvidence选项）。
This section is focused on the RFC 3161-based type of evidence. Processing of the structure for other types of evidence would be done in a similar manner.
本节重点介绍基于RFC 3161的证据类型。其他类型证据的结构处理将以类似方式进行。
In this case, applications are supposed to behave as follows:
在这种情况下，应用程序的行为应如下所示：
o populate the version field with the integer value v1(1);
o 用整数值v1（1）填充版本字段；
o if a self-contained envelope is to be generated, always populate the content field with the content of the file in its original format and encoding; depending on the application, the dataUri field may also be added;
o 如果要生成自包含信封，请始终使用原始格式和编码的文件内容填充内容字段；根据应用，还可以添加dataUri字段；
o otherwise (a detached envelope is to be generated), always populate the dataUri field with the URI of the time-stamped document (e.g., http://foo.example.com/Contract12345.pdf); using an absolute URI or a relative reference depends on the application;
o 否则（将生成分离的信封），始终使用时间戳文档的URI填充dataUri字段（例如。，http://foo.example.com/Contract12345.pdf); 使用绝对URI或相对引用取决于应用程序；
o if the metaData field is being added, decide on the value of its hashProtected field; set its value to TRUE if the application needs the remaining fields of the metaData construct to be hash-protected as described in Section 2; otherwise, set it to FALSE;
o 如果要添加元数据字段，则决定其hashProtected字段的值；如果应用程序需要按照第2节所述对元数据构造的其余字段进行哈希保护，则将其值设置为TRUE；否则，将其设置为FALSE；
o if the metaData field is being added, optionally populate the fileName field (e.g., "Contract12345.pdf"), the mediaType field with a suitable media type/subtype and possible parameters according to [MIME], and the otherMetaData field, depending on the application;
o 如果要添加元数据字段，根据应用程序，可以选择填充文件名字段（例如，“Contract12345.pdf”）、使用合适的媒体类型/子类型和可能的参数（根据[MIME]）填充mediaType字段以及其他元数据字段；
o select a suitable one-way hash function and compute a hash value using that function over the content, or the concatenation of the metadata and the content, as described in Section 2; this hash value will then be used for requesting the first TimeStampToken;
o 选择合适的单向散列函数，并使用该函数计算内容上的散列值，或元数据和内容的串联，如第2节所述；该散列值随后将用于请求第一时间戳令牌；
o obtain the first temporal evidence from a TSA and add it to the temporalEvidence field;
o 从TSA获取第一时间证据，并将其添加到时间证据字段；
o insert the TimeStampedData into a ContentInfo structure, with the id-ct-timestampedData OID in the contentType field;
o 将TimeStampedData插入ContentInfo结构，contentType字段中id为ct TimeStampedData OID；
o BER-encode the ContentInfo structure (except for the fields that are required to be DER encoded) and save it with a reasonable file name (e.g., derived from the name of the time-stamped file).
o BER编码ContentInfo结构（需要进行DER编码的字段除外），并使用合理的文件名保存（例如，从时间戳文件的名称派生）。
In this case, applications are supposed to behave as follows:
在这种情况下，应用程序的行为应如下所示：
o check that the contentType field of the ContentInfo structure has the expected value (id-ct-timestampedData) in its contentType field; then, extract the inner TimeStampedData structure and continue processing;
o 检查ContentInfo结构的contentType字段在其contentType字段中是否具有预期值（id ct timestampedData）；然后，提取内部timestameseddata结构并继续处理；
o check the version field (it should be v1);
o 检查版本字段（应为v1）；
o check that the temporalEvidence field is not empty;
o 检查临时证据字段是否为空；
o check whether the content is present; if it is not, use the dataUri field to retrieve the file;
o 检查内容是否存在；如果不是，则使用dataUri字段检索文件；
o open the first element of the TimeStampTokenEvidence sequence, open the time-stamp token within it and use the hash function that was used to obtain it to re-compute the hash of the fields indicated in Section 2; if the re-computed hash value matches the one within the time-stamp token, continue processing; otherwise, the TimeStampedData structure has been modified;
o 打开TimeStampTokenEvidence序列的第一个元素，打开其中的时间戳令牌，并使用用于获取该令牌的哈希函数来重新计算第2节中指示的字段的哈希；如果重新计算的哈希值与时间戳令牌内的哈希值匹配，则继续处理；否则，修改了TimeStampedData结构；
o validate the temporalEvidence by checking that:
o 通过检查以下各项来验证临时证据：
- each TimeStampToken in the chain does contain the correct digest value (according to the rule described in Section 2) and it was signed by a trusted TSA,
- 链中的每个TimeStampToken都包含正确的摘要值（根据第2节中描述的规则），并且由受信任的TSA签名，
- the corresponding TSA signing certificate was not revoked at the time when the subsequent TimeStampToken was issued, based on the associated CRL;
- 相应的TSA签名证书在随后的TimeStampToken发出时未根据相关CRL撤销；
o depending on the application, use the temporal evidence for whatever purpose the application was designed for;
o 根据应用程序，将临时证据用于应用程序设计的任何目的；
o depending on the application, show the dataUri, the fileName, the mediaType, the otherMetaData, and the temporal evidence to the user;
o 根据应用程序，向用户显示dataUri、文件名、mediaType、otherMetaData和临时证据；
o depending on the application, save the content to a separate file;
o 根据应用程序，将内容保存到单独的文件中；
o depending on the application, store at a different place the content that has been retrieved using the dataUri field, then update the dataUri field accordingly;
o 根据应用程序的不同，将使用dataUri字段检索的内容存储在不同的位置，然后相应地更新dataUri字段；
o depending on the application, show the time-stamped file to the user, possibly by activating a suitable "viewer".
o 根据应用程序，可能通过激活合适的“查看器”向用户显示时间戳文件。
In this case, applications are supposed to behave as follows:
在这种情况下，应用程序的行为应如下所示：
o validate the TimeStampedData structure as described above;
o 如上所述验证TimeStampedData结构；
o select the time-stamp token from the last TimeStampAndCRL element in the chain and obtain the latest available CRL for the corresponding TSA certificate (if this CRL is not fresh enough, wait until the next one is available), then store it in the TimeStampAndCRL element;
o 从链中最后一个timestamp和CRL元素中选择时间戳令牌，并获取对应TSA证书的最新可用CRL（如果此CRL不够新鲜，等待下一个CRL可用），然后将其存储在timestamp和CRL元素中；
o instantiate a new TimeStampAndCRL element and obtain a new time-stamp token computed over the previous one, according to the rule described in Section 2; insert the new time-stamp token into the new TimeStampAndCRL element, then append the latter to the end of the chain.
o 根据第2节中描述的规则，实例化一个新的timestamp和crl元素，并获得在前一个元素上计算的新时间戳令牌；将新的时间戳标记插入新的timestamp和crl元素，然后将后者附加到链的末尾。
See the Security Considerations section for further discussion on extending the validity of an existing TimeStampedData structure.
有关扩展现有TimeStampedData结构有效性的进一步讨论，请参见安全注意事项部分。
When the metaData field is present and the hashProtected sub-field is set to TRUE, the metadata are also included in the computation of the digest within the first time-stamp token, so that any subsequent alteration of the metadata will be easily detected. However, the integrity of hash-protected metadata does not imply that the metadata were correct at the time when the TimeStampedData object was created. That can only be inferred by other means (e.g., from context). For instance, when TimeStampedData objects are created by an archival service provider, it may be reasonable to assume that the metadata are correct at creation time. Instead, when a TimeStampedData object is received from an unknown party, the recipient cannot safely assume that the metadata are correct, lacking further information.
当元数据字段存在并且hashProtected子字段设置为TRUE时，元数据也包括在第一时间戳令牌内的摘要计算中，因此元数据的任何后续更改都将很容易被检测到。但是，受哈希保护的元数据的完整性并不意味着元数据在创建TimeStampedData对象时是正确的。只能通过其他方式推断（例如，从上下文）。例如，当存档服务提供商创建TimeStampedData对象时，可以合理地假设元数据在创建时是正确的。相反，当从未知方接收TimeStampedData对象时，接收方无法安全地假定元数据是正确的，因为缺少进一步的信息。
In general, a time-stamp token should not be considered valid after the certificate of the issuing TSA is expired (also, this consideration depends on the legislation and the policy under which the TSA operates). However, a time-stamp token can itself be time-stamped to extend the validity of the TSA's signature. By repeatedly applying this technique, a whole chain of time-stamp tokens can be grown to extend the validity of the first one ad libitum. Thus, this approach can be adopted to extend the validity of a TimeStampedData structure beyond the expiry date of the first TimeStampToken within it, by adding further elements to the TimeStampTokenEvidence sequence
一般来说，在签发TSA的证书过期后，时间戳令牌不应被视为有效（同样，这种考虑取决于TSA运行所依据的立法和政策）。但是，时间戳令牌本身可以加上时间戳，以延长TSA签名的有效性。通过反复应用这项技术，一整串时间戳标记可以随意扩展第一个标记的有效性。因此，通过向TimeStampToken证据序列添加更多元素，可以采用该方法将TimeStampedData结构的有效性扩展到其内第一个TimeStampToken的到期日期之外
according to the rule described in Section 2. Of course, each additional TimeStampToken must be added in a timely manner (before the previous one is expired or has been revoked).
根据第2节中描述的规则。当然，必须及时添加每个额外的TimeStampToken（在前一个TimeStampToken过期或被撤销之前）。
The validity extension technique described above requires that the TSA signing certificates can still be verified long after they have expired, typically by checking a CRL. The CRL must be captured at the suitable time, because expired certificates are typically removed from the CRL regardless of their being revoked. The TimeStampAndCRL construct allows adding a CRL next to the related TimeStampToken, so that the TSA certificate will still be verifiable at any later time. The CRL must be captured at the time when another element is about to be added to the TimeStampTokenEvidence sequence, or even later -- to allow for a last-minute revocation request to be processed by the CA (see the discussion about "grace periods" in [CADES]).
上述有效性扩展技术要求TSA签名证书在过期很久之后仍然可以进行验证，通常是通过检查CRL。必须在适当的时间捕获CRL，因为过期证书通常会从CRL中删除，而不管它们是否被吊销。TimeStampAndCRL构造允许在相关TimeStampToken旁边添加一个CRL，以便TSA证书在以后任何时候都可以验证。CRL必须在另一个元素即将添加到TimeStampTokenEvidence序列时捕获，或者更晚，以允许CA处理最后一分钟的撤销请求（请参阅[CADES]中关于“宽限期”的讨论）。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 56522009年9月。
[ERS] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007.
[ERS]Gondrom，T.，Brandner，R.，和U.Pordesch，“证据记录语法（ERS）”，RFC 49982007年8月。
[KWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KWORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[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月。
[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月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[CADES] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced Electronic Signatures (CAdES)", RFC 5126, March 2008.
[CADES]Pinkas，D.，Pope，N.，和J.Ross，“CMS高级电子签名（CADES）”，RFC 51262008年3月。
The ASN.1 module contained in this appendix defines the structures that are needed to implement this specification. It is expected to be used in conjunction with the ASN.1 modules in [CMS], [TSP], [PKIX1], and [ERS].
本附录中包含的ASN.1模块定义了实施本规范所需的结构。它预计将与[CMS]、[TSP]、[PKIX1]和[ERS]中的ASN.1模块结合使用。
TimeStampedDataModule
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) 35 }
TimeStampedDataModule
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) 35 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
进口
-- Imports from RFC 5652 [CMS]
Attribute
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 5652 [CMS]
Attribute
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 3161 [TSP]
TimeStampToken
FROM PKIXTSP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tsp(13)}
-- Imports from RFC 3161 [TSP]
TimeStampToken
FROM PKIXTSP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tsp(13)}
-- Imports from RFC 5280 [PKIX1]
CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(18)}
-- Imports from RFC 5280 [PKIX1]
CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(18)}
-- Imports from RFC 4998 [ERS]
EvidenceRecord
FROM ERS
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) id-mod(0)
id-mod-ers88(2) id-mod-ers88-v1(1) };
-- Imports from RFC 4998 [ERS]
EvidenceRecord
FROM ERS
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) id-mod(0)
id-mod-ers88(2) id-mod-ers88-v1(1) };
-- TimeStampedData Content Type and Object Identifier
--TimeStampedData内容类型和对象标识符
id-ct-timestampedData OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 31 }
id-ct-timestampedData OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 31 }
TimeStampedData ::= SEQUENCE {
version INTEGER { v1(1) },
dataUri IA5String OPTIONAL,
metaData MetaData OPTIONAL,
content OCTET STRING OPTIONAL,
temporalEvidence Evidence
}
TimeStampedData ::= SEQUENCE {
version INTEGER { v1(1) },
dataUri IA5String OPTIONAL,
metaData MetaData OPTIONAL,
content OCTET STRING OPTIONAL,
temporalEvidence Evidence
}
MetaData ::= SEQUENCE {
hashProtected BOOLEAN,
fileName UTF8String OPTIONAL,
mediaType IA5String OPTIONAL,
otherMetaData Attributes OPTIONAL
}
MetaData ::= SEQUENCE {
hashProtected BOOLEAN,
fileName UTF8String OPTIONAL,
mediaType IA5String OPTIONAL,
otherMetaData Attributes OPTIONAL
}
Attributes ::=
SET SIZE(1..MAX) OF Attribute -- according to RFC 5652
Attributes ::=
SET SIZE(1..MAX) OF Attribute -- according to RFC 5652
Evidence ::= CHOICE {
tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161
ersEvidence [1] EvidenceRecord, -- see RFC 4998
otherEvidence [2] OtherEvidence
}
Evidence ::= CHOICE {
tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161
ersEvidence [1] EvidenceRecord, -- see RFC 4998
otherEvidence [2] OtherEvidence
}
OtherEvidence ::= SEQUENCE {
oeType OBJECT IDENTIFIER,
oeValue ANY DEFINED BY oeType }
OtherEvidence ::= SEQUENCE {
oeType OBJECT IDENTIFIER,
oeValue ANY DEFINED BY oeType }
TimeStampTokenEvidence ::=
SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL
TimeStampTokenEvidence ::=
SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL
TimeStampAndCRL ::= SEQUENCE {
timeStamp TimeStampToken, -- according to RFC 3161
crl CertificateList OPTIONAL -- according to RFC 5280
}
TimeStampAndCRL ::= SEQUENCE {
timeStamp TimeStampToken, -- according to RFC 3161
crl CertificateList OPTIONAL -- according to RFC 5280
}
END
终止
Thanks to Stephen Kent for encouraging the author in the early stages of this work.
感谢斯蒂芬·肯特在这项工作的早期鼓励作者。
Thanks to Russ Housley for reviewing this memo, suggesting useful amendments and assigning a value to the OIDs herein defined.
感谢Russ Housley审阅本备忘录，提出有用的修订建议，并为此处定义的OID赋值。
Thanks are also due to other people who reviewed this memo and helped improving it, but prefer not to be mentioned.
感谢审阅此备忘录并帮助改进它的其他人，但不想被提及。
Author's Address
作者地址
Adriano Santoni Actalis S.p.A. Via Taramelli 26 I-20124 Milano Italy
Adriano Santoni Actalis S.p.A.Via Taramelli 26 I-20124意大利米兰
EMail: adriano.santoni@actalis.it
EMail: adriano.santoni@actalis.it