Network Working Group                                           C. Adams
Request for Comments: 3161                                       Entrust
Category: Standards Track                                        P. Cain
                                                                     BBN
                                                               D. Pinkas
                                                                Integris
                                                           R. Zuccherato
                                                                 Entrust
                                                             August 2001
        
Network Working Group                                           C. Adams
Request for Comments: 3161                                       Entrust
Category: Standards Track                                        P. Cain
                                                                     BBN
                                                               D. Pinkas
                                                                Integris
                                                           R. Zuccherato
                                                                 Entrust
                                                             August 2001
        

Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)

Internet X.509公钥基础设施时间戳协议(TSP)

Status of this Memo

本备忘录的状况

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

Abstract

摘要

This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses.

本文档描述了发送给时间戳管理局(TSA)的请求和返回的响应的格式。它还为TSA操作建立了几个安全相关要求,涉及处理请求以生成响应。

1. Introduction
1. 介绍

A time-stamping service supports assertions of proof that a datum existed before a particular time. A TSA may be operated as a Trusted Third Party (TTP) service, though other operational models may be appropriate, e.g., an organization might require a TSA for internal time-stamping purposes.

时间戳服务支持数据在特定时间之前存在的证明断言。TSA可以作为受信任的第三方(TTP)服务运行,尽管其他运行模式可能是合适的,例如,组织可能需要TSA用于内部时间戳。

Non-repudiation services [ISONR] require the ability to establish the existence of data before specified times. This protocol may be used as a building block to support such services. An example of how to prove that a digital signature was generated during the validity period of a public key certificate is given in an annex.

不可否认服务[ISONR]要求能够在指定时间之前确定数据的存在。该协议可用作支持此类服务的构建块。附件中给出了如何证明数字签名是在公钥证书有效期内生成的示例。

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“建议”、“可”和“可选”(大写,如图所示)应按照[RFC2119]中所述进行解释。

In order to associate a datum with a particular point in time, a Time Stamp Authority (TSA) may need to be used. This Trusted Third Party provides a "proof-of-existence" for this particular datum at an instant in time.

为了将数据与特定时间点关联,可能需要使用时间戳授权(TSA)。该受信任的第三方在瞬间为该特定数据提供“存在证明”。

The TSA's role is to time-stamp a datum to establish evidence indicating that a datum existed before a particular time. This can then be used, for example, to verify that a digital signature was applied to a message before the corresponding certificate was revoked thus allowing a revoked public key certificate to be used for verifying signatures created prior to the time of revocation. This is an important public key infrastructure operation. The TSA can also be used to indicate the time of submission when a deadline is critical, or to indicate the time of transaction for entries in a log. An exhaustive list of possible uses of a TSA is beyond the scope of this document.

TSA的作用是在数据上加盖时间戳,以建立证据,表明数据在特定时间之前存在。例如,这可用于验证在撤销相应证书之前已将数字签名应用于消息,从而允许将已撤销的公钥证书用于验证在撤销之前创建的签名。这是一项重要的公钥基础设施操作。TSA还可用于指示截止日期至关重要时的提交时间,或指示日志中条目的交易时间。TSA可能用途的详尽列表超出了本文件的范围。

This standard does not establish overall security requirements for TSA operation, just like other PKIX standards do not establish such requirements for CA operation. Rather, it is anticipated that a TSA will make known to prospective clients the policies it implements to ensure accurate time-stamp generation, and clients will make use of the services of a TSA only if they are satisfied that these policies meet their needs.

本标准没有为TSA操作制定总体安全要求,就像其他PKIX标准没有为CA操作制定此类要求一样。相反,预计TSA将向潜在客户公布其实施的政策,以确保准确生成时间戳,并且客户只有在满足这些政策满足其需求时才会使用TSA的服务。

2. The TSA
2. 运输安全管理局

The TSA is a TTP that creates time-stamp tokens in order to indicate that a datum existed at a particular point in time.

TSA是一种TTP,它创建时间戳令牌,以指示数据存在于特定时间点。

For the remainder of this document a "valid request" shall mean one that can be decoded correctly, is of the form specified in Section 2.4, and is from a supported TSA subscriber.

对于本文件的其余部分,“有效请求”应指能够正确解码、采用第2.4节规定的格式且来自受支持的TSA订户的请求。

2.1. Requirements of the TSA
2.1. TSA的要求

The TSA is REQUIRED:

TSA要求:

1. to use a trustworthy source of time.

1. 使用可靠的时间来源。

2. to include a trustworthy time value for each time-stamp token.

2. 为每个时间戳令牌包含可信时间值。

3. to include a unique integer for each newly generated time-stamp token.

3. 为每个新生成的时间戳令牌包含唯一整数。

4. to produce a time-stamp token upon receiving a valid request from the requester, when it is possible.

4. 在可能的情况下,在收到请求者的有效请求时生成时间戳令牌。

5. to include within each time-stamp token an identifier to uniquely indicate the security policy under which the token was created.

5. 在每个时间戳令牌中包含一个标识符,以唯一地指示创建令牌所依据的安全策略。

6. to only time-stamp a hash representation of the datum, i.e., a data imprint associated with a one-way collision resistant hash-function uniquely identified by an OID.

6. 仅对数据的散列表示进行时间戳,即,与OID唯一标识的单向抗冲突散列函数相关联的数据印记。

7. to examine the OID of the one-way collision resistant hash-function and to verify that the hash value length is consistent with the hash algorithm.

7. 检查单向抗冲突哈希函数的OID,并验证哈希值长度是否与哈希算法一致。

8. not to examine the imprint being time-stamped in any way (other than to check its length, as specified in the previous bullet).

8. 不得以任何方式检查带有时间戳的印记(检查其长度除外,如前一项所述)。

9. not to include any identification of the requesting entity in the time-stamp tokens.

9. 不在时间戳令牌中包含请求实体的任何标识。

10. to sign each time-stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate.

10. 使用专门为此目的生成的密钥对每个时间戳令牌进行签名,并在相应证书上指示密钥的此属性。

11. to include additional information in the time-stamp token, if asked by the requester using the extensions field, only for the extensions that are supported by the TSA. If this is not possible, the TSA SHALL respond with an error message.

11. 如果请求者使用extensions字段提出请求,则在时间戳令牌中包含附加信息,仅适用于TSA支持的扩展。如果这是不可能的,TSA应以错误信息作出响应。

2.2. TSA Transactions
2.2. TSA交易

As the first message of this mechanism, the requesting entity requests a time-stamp token by sending a request (which is or includes a TimeStampReq, as defined below) to the Time Stamping Authority. As the second message, the Time Stamping Authority responds by sending a response (which is or includes a TimeStampResp, as defined below) to the requesting entity.

作为该机制的第一条消息,请求实体通过向时间戳授权机构发送请求(是或包括TimeStampReq,定义如下)来请求时间戳令牌。作为第二条消息,时间戳机构通过向请求实体发送响应(其为或包括时间戳,定义如下)来响应。

Upon receiving the response (which is or includes a TimeStampResp that normally contains a TimeStampToken (TST), as defined below), the requesting entity SHALL verify the status error returned in the response and if no error is present it SHALL verify the various fields contained in the TimeStampToken and the validity of the digital signature of the TimeStampToken. In particular, it SHALL verify that what was time-stamped corresponds to what was requested to be time-stamped. The requester SHALL verify that the TimeStampToken contains the correct certificate identifier of the

在接收到响应时(该响应是或包括通常包含时间戳令牌(TST)的时间戳,定义如下),请求实体应验证响应中返回的状态错误,如果不存在错误,则应验证时间戳令牌中包含的各个字段以及时间戳令牌的数字签名的有效性。特别是,应验证时间戳的内容是否与要求时间戳的内容一致。请求者应验证TimeStampToken是否包含正确的证书标识符

TSA, the correct data imprint and the correct hash algorithm OID. It SHALL then verify the timeliness of the response by verifying either the time included in the response against a local trusted time reference, if one is available, or the value of the nonce (large random number with a high probability that it is generated by the client only once) included in the response against the value included in the request. For more details about replay attack detection, see the security considerations section (item 6). If any of the verifications above fails, the TimeStampToken SHALL be rejected.

TSA、正确的数据印记和正确的哈希算法OID。然后,它应根据本地可信时间参考(如果有)验证响应中包含的时间,或者验证nonce的值(大随机数,很有可能由客户端仅生成一次),从而验证响应的及时性根据请求中包含的值包含在响应中。有关重播攻击检测的更多详细信息,请参阅安全注意事项部分(第6项)。如果上述任何验证失败,则时间戳令牌将被拒绝。

Then, since the TSA's certificate may have been revoked, the status of the certificate SHOULD be checked (e.g., by checking the appropriate CRL) to verify that the certificate is still valid.

然后,由于TSA的证书可能已被吊销,因此应检查证书的状态(例如,通过检查适当的CRL),以验证证书仍然有效。

Then, the client application SHOULD check the policy field to determine whether or not the policy under which the token was issued is acceptable for the application.

然后,客户端应用程序应该检查策略字段,以确定应用程序是否可以接受根据其发出令牌的策略。

2.3. Identification of the TSA
2.3. TSA的识别

The TSA MUST sign each time-stamp message with a key reserved specifically for that purpose. A TSA MAY have distinct private keys, e.g., to accommodate different policies, different algorithms, different private key sizes or to increase the performance. The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID having value:

TSA必须使用专门为此目的保留的密钥对每个时间戳消息进行签名。TSA可以具有不同的私钥,例如,以适应不同的策略、不同的算法、不同的私钥大小或提高性能。相应的证书必须仅包含[RFC2459]第4.2.1.13节中定义的扩展密钥使用字段扩展的一个实例,其中KeyPurposeID具有以下值:

id-kp-timeStamping. This extension MUST be critical.

id kp时间戳。这一扩展必须至关重要。

The following object identifier identifies the KeyPurposeID having value id-kp-timeStamping.

以下对象标识符标识具有值id kp时间戳的KeyPurposeID。

   id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
                   identified-organization(3) dod(6)
                   internet(1) security(5) mechanisms(5) pkix(7)
                   kp (3) timestamping (8)}
        
   id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1)
                   identified-organization(3) dod(6)
                   internet(1) security(5) mechanisms(5) pkix(7)
                   kp (3) timestamping (8)}
        
2.4. Request and Response Formats
2.4. 请求和响应格式
2.4.1. Request Format
2.4.1. 请求格式

A time-stamping request is as follows:

时间戳申请如下:

TimeStampReq ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   messageImprint               MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
        
TimeStampReq ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   messageImprint               MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
        

--time-stamped reqPolicy TSAPolicyId OPTIONAL, nonce INTEGER OPTIONAL, certReq BOOLEAN DEFAULT FALSE, extensions [0] IMPLICIT Extensions OPTIONAL }

--带时间戳的reqPolicy TSAPolicId可选,nonce整数可选,certReq布尔默认值为FALSE,扩展[0]隐式扩展可选}

The version field (currently v1) describes the version of the Time-Stamp request.

版本字段(当前为v1)描述时间戳请求的版本。

The messageImprint field SHOULD contain the hash of the datum to be time-stamped. The hash is represented as an OCTET STRING. Its length MUST match the length of the hash value for that algorithm (e.g., 20 bytes for SHA-1 or 16 bytes for MD5).

messageImprint字段应包含要加时间戳的数据的散列。哈希值表示为八位字节字符串。其长度必须与该算法的哈希值长度相匹配(例如,SHA-1为20字节,MD5为16字节)。

   MessageImprint ::= SEQUENCE  {
        hashAlgorithm                AlgorithmIdentifier,
        hashedMessage                OCTET STRING  }
        
   MessageImprint ::= SEQUENCE  {
        hashAlgorithm                AlgorithmIdentifier,
        hashedMessage                OCTET STRING  }
        

The hash algorithm indicated in the hashAlgorithm field SHOULD be a known hash algorithm (one-way and collision resistant). That means that it SHOULD be one-way and collision resistant. The Time Stamp Authority SHOULD check whether or not the given hash algorithm is known to be "sufficient" (based on the current state of knowledge in cryptanalysis and the current state of the art in computational resources, for example). If the TSA does not recognize the hash algorithm or knows that the hash algorithm is weak (a decision left to the discretion of each individual TSA), then the TSA SHOULD refuse to provide the time-stamp token by returning a pkiStatusInfo of 'bad_alg'.

hashAlgorithm字段中指示的哈希算法应该是已知的哈希算法(单向且抗冲突)。这意味着它应该是单向的,并且可以防止碰撞。时间戳管理机构应检查给定的哈希算法是否已知“足够”(例如,基于密码分析的当前知识状态和计算资源的当前技术状态)。如果TSA不识别哈希算法或知道哈希算法很弱(由每个TSA自行决定),则TSA应通过返回“bad_alg”的PKI状态信息来拒绝提供时间戳令牌。

The reqPolicy field, if included, indicates the TSA policy under which the TimeStampToken SHOULD be provided. TSAPolicyId is defined as follows:

reqPolicy字段(如果包括)指示应在其下提供时间戳令牌的TSA策略。TSAPolicyId的定义如下:

      TSAPolicyId ::= OBJECT IDENTIFIER
        
      TSAPolicyId ::= OBJECT IDENTIFIER
        

The nonce, if included, allows the client to verify the timeliness of the response when no local clock is available. The nonce is a large random number with a high probability that the client generates it only once (e.g., a 64 bit integer). In such a case the same nonce value MUST be included in the response, otherwise the response shall be rejected.

nonce(如果包括)允许客户端在没有本地时钟可用时验证响应的及时性。nonce是一个大的随机数,客户端很可能只生成一次(例如,64位整数)。在这种情况下,响应中必须包含相同的nonce值,否则响应将被拒绝。

If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID identifier inside a SigningCertificate attribute in the response MUST be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates.

如果certReq字段存在并设置为true,则TSA必须在该响应的SignedData结构的certificates字段中提供由响应中SigningCertificate属性内的ESSCertID标识符引用的TSA公钥证书。该字段还可能包含其他证书。

If the certReq field is missing or if the certReq field is present and set to false then the certificates field from the SignedData structure MUST not be present in the response.

如果certReq字段缺失或certReq字段存在并设置为false,则SignedData结构中的certificates字段不得出现在响应中。

The extensions field is a generic way to add additional information to the request in the future. Extensions is defined in [RFC 2459]. If an extension, whether it is marked critical or not critical, is used by a requester but is not recognized by a time-stamping server, the server SHALL not issue a token and SHALL return a failure (unacceptedExtension).

extensions字段是将来向请求添加附加信息的通用方法。扩展在[RFC 2459]中定义。如果请求者使用了扩展(无论是否标记为关键扩展),但时间戳服务器无法识别该扩展,则服务器不应发出令牌,并应返回故障(不可接受扩展)。

The time-stamp request does not identify the requester, as this information is not validated by the TSA (See Section 2.1). In situations where the TSA requires the identity of the requesting entity, alternate identification /authentication means have to be used (e.g., CMS encapsulation [CMS] or TLS authentication [RFC2246]).

时间戳请求未识别请求者,因为TSA未验证该信息(见第2.1节)。在TSA要求请求实体的身份的情况下,必须使用替代标识/认证手段(例如,CMS封装[CMS]或TLS认证[RFC2246])。

2.4.2. Response Format
2.4.2. 响应格式

A time-stamping response is as follows:

时间戳响应如下所示:

   TimeStampResp ::= SEQUENCE  {
      status                  PKIStatusInfo,
      timeStampToken          TimeStampToken     OPTIONAL  }
        
   TimeStampResp ::= SEQUENCE  {
      status                  PKIStatusInfo,
      timeStampToken          TimeStampToken     OPTIONAL  }
        

The status is based on the definition of status in section 3.2.3 of [RFC2510] as follows:

状态基于[RFC2510]第3.2.3节中的状态定义,如下所示:

   PKIStatusInfo ::= SEQUENCE {
      status        PKIStatus,
      statusString  PKIFreeText     OPTIONAL,
      failInfo      PKIFailureInfo  OPTIONAL  }
        
   PKIStatusInfo ::= SEQUENCE {
      status        PKIStatus,
      statusString  PKIFreeText     OPTIONAL,
      failInfo      PKIFailureInfo  OPTIONAL  }
        

When the status contains the value zero or one, a TimeStampToken MUST be present. When status contains a value other than zero or one, a TimeStampToken MUST NOT be present. One of the following values MUST be contained in status:

当状态包含值0或1时,必须存在TimeStampToken。当status包含除0或1以外的值时,TimeStampToken不得存在。状态中必须包含以下值之一:

   PKIStatus ::= INTEGER {
      granted                (0),
      -- when the PKIStatus contains the value zero a TimeStampToken, as
         requested, is present.
      grantedWithMods        (1),
       -- when the PKIStatus contains the value one a TimeStampToken,
         with modifications, is present.
      rejection              (2),
      waiting                (3),
      revocationWarning      (4),
        
   PKIStatus ::= INTEGER {
      granted                (0),
      -- when the PKIStatus contains the value zero a TimeStampToken, as
         requested, is present.
      grantedWithMods        (1),
       -- when the PKIStatus contains the value one a TimeStampToken,
         with modifications, is present.
      rejection              (2),
      waiting                (3),
      revocationWarning      (4),
        
       -- this message contains a warning that a revocation is
       -- imminent
      revocationNotification (5)
       -- notification that a revocation has occurred  }
        
       -- this message contains a warning that a revocation is
       -- imminent
      revocationNotification (5)
       -- notification that a revocation has occurred  }
        

Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present.

兼容服务器不应产生任何其他值。如果存在不可理解的值,则兼容客户端必须生成错误。

When the TimeStampToken is not present, the failInfo indicates the reason why the time-stamp request was rejected and may be one of the following values.

当时间戳令牌不存在时,failInfo指示时间戳请求被拒绝的原因,可能是以下值之一。

PKIFailureInfo ::= BIT STRING {
   badAlg               (0),
     -- unrecognized or unsupported Algorithm Identifier
   badRequest           (2),
     -- transaction not permitted or supported
   badDataFormat        (5),
     -- the data submitted has the wrong format
   timeNotAvailable    (14),
     -- the TSA's time source is not available
   unacceptedPolicy    (15),
     -- the requested TSA policy is not supported by the TSA
   unacceptedExtension (16),
     -- the requested extension is not supported by the TSA
    addInfoNotAvailable (17)
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }
        
PKIFailureInfo ::= BIT STRING {
   badAlg               (0),
     -- unrecognized or unsupported Algorithm Identifier
   badRequest           (2),
     -- transaction not permitted or supported
   badDataFormat        (5),
     -- the data submitted has the wrong format
   timeNotAvailable    (14),
     -- the TSA's time source is not available
   unacceptedPolicy    (15),
     -- the requested TSA policy is not supported by the TSA
   unacceptedExtension (16),
     -- the requested extension is not supported by the TSA
    addInfoNotAvailable (17)
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }
        

These are the only values of PKIFailureInfo that SHALL be supported.

这些是应支持的PKIFailureInfo的唯一值。

Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present.

兼容服务器不应产生任何其他值。如果存在不可理解的值,则兼容客户端必须生成错误。

The statusString field of PKIStatusInfo MAY be used to include reason text such as "messageImprint field is not correctly formatted".

PKIStatusInfo的statusString字段可用于包含原因文本,如“messageImprint字段格式不正确”。

A TimeStampToken is as follows. It is defined as a ContentInfo ([CMS]) and SHALL encapsulate a signed data content type.

时间戳标记如下所示。它被定义为ContentInfo([CMS]),并应封装签名数据内容类型。

   TimeStampToken ::= ContentInfo
     -- contentType is id-signedData ([CMS])
     -- content is SignedData ([CMS])
        
   TimeStampToken ::= ContentInfo
     -- contentType is id-signedData ([CMS])
     -- content is SignedData ([CMS])
        

The fields of type EncapsulatedContentInfo of the SignedData construct have the following meanings:

SignedData构造的封装ContentInfo类型的字段具有以下含义:

eContentType is an object identifier that uniquely specifies the content type. For a time-stamp token it is defined as:

eContentType是唯一指定内容类型的对象标识符。对于时间戳令牌,其定义为:

   id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
        
   id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
        

eContent is the content itself, carried as an octet string. The eContent SHALL be the DER-encoded value of TSTInfo.

eContent是内容本身,作为八位字节字符串携带。eContent应为TSTInfo的DER编码值。

The time-stamp token MUST NOT contain any signatures other than the signature of the TSA. The certificate identifier (ESSCertID) of the TSA certificate MUST be included as a signerInfo attribute inside a SigningCertificate attribute.

时间戳令牌不得包含TSA签名以外的任何签名。TSA证书的证书标识符(ESSCertID)必须作为SigningCertificate属性中的SignerinInfo属性包含。

TSTInfo ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   policy                       TSAPolicyId,
   messageImprint               MessageImprint,
     -- MUST have the same value as the similar field in
     -- TimeStampReq
   serialNumber                 INTEGER,
    -- Time-Stamping users MUST be ready to accommodate integers
    -- up to 160 bits.
   genTime                      GeneralizedTime,
   accuracy                     Accuracy                 OPTIONAL,
   ordering                     BOOLEAN             DEFAULT FALSE,
   nonce                        INTEGER                  OPTIONAL,
     -- MUST be present if the similar field was present
     -- in TimeStampReq.  In that case it MUST have the same value.
   tsa                          [0] GeneralName          OPTIONAL,
   extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
        
TSTInfo ::= SEQUENCE  {
   version                      INTEGER  { v1(1) },
   policy                       TSAPolicyId,
   messageImprint               MessageImprint,
     -- MUST have the same value as the similar field in
     -- TimeStampReq
   serialNumber                 INTEGER,
    -- Time-Stamping users MUST be ready to accommodate integers
    -- up to 160 bits.
   genTime                      GeneralizedTime,
   accuracy                     Accuracy                 OPTIONAL,
   ordering                     BOOLEAN             DEFAULT FALSE,
   nonce                        INTEGER                  OPTIONAL,
     -- MUST be present if the similar field was present
     -- in TimeStampReq.  In that case it MUST have the same value.
   tsa                          [0] GeneralName          OPTIONAL,
   extensions                   [1] IMPLICIT Extensions   OPTIONAL  }
        

The version field (currently v1) describes the version of the time-stamp token.

版本字段(当前为v1)描述时间戳令牌的版本。

Conforming time-stamping servers MUST be able to provide version 1 time-stamp tokens.

合格的时间戳服务器必须能够提供版本1时间戳令牌。

Among the optional fields, only the nonce field MUST be supported.

在可选字段中,只能支持nonce字段。

Conforming time-stamping requesters MUST be able to recognize version 1 time-stamp tokens with all the optional fields present, but are not mandated to understand the semantics of any extension, if present.

一致性时间戳请求者必须能够识别存在所有可选字段的版本1时间戳令牌,但不必理解任何扩展(如果存在)的语义。

The policy field MUST indicate the TSA's policy under which the response was produced. If a similar field was present in the TimeStampReq, then it MUST have the same value, otherwise an error (unacceptedPolicy) MUST be returned. This policy MAY include the following types of information (although this list is certainly not exhaustive):

策略字段必须指明TSA的策略,根据该策略生成响应。如果TimeStampReq中存在类似的字段,则它必须具有相同的值,否则必须返回错误(unacceptedPolicy)。该政策可能包括以下类型的信息(尽管该列表并非详尽无遗):

* The conditions under which the time-stamp token may be used.

* 可以使用时间戳令牌的条件。

* The availability of a time-stamp token log, to allow later verification that a time-stamp token is authentic.

* 时间戳令牌日志的可用性,以便稍后验证时间戳令牌是否真实。

The messageImprint MUST have the same value as the similar field in TimeStampReq, provided that the size of the hash value matches the expected size of the hash algorithm identified in hashAlgorithm.

messageImprint必须与TimeStampReq中的类似字段具有相同的值,前提是哈希值的大小与hashAlgorithm中标识的哈希算法的预期大小匹配。

The serialNumber field is an integer assigned by the TSA to each TimeStampToken. It MUST be unique for each TimeStampToken issued by a given TSA (i.e., the TSA name and serial number identify a unique TimeStampToken). It should be noticed that the property MUST be preserved even after a possible interruption (e.g., crash) of the service.

serialNumber字段是TSA分配给每个TimeStampToken的整数。对于给定TSA发布的每个TimeStampToken,它必须是唯一的(即,TSA名称和序列号标识唯一的TimeStampToken)。应该注意的是,即使在服务可能中断(例如崩溃)后,也必须保留该属性。

genTime is the time at which the time-stamp token has been created by the TSA. It is expressed as UTC time (Coordinated Universal Time) to reduce confusion with the local time zone use. UTC is a time scale, based on the second (SI), as defined and recommended by the CCIR, and maintained by the Bureau International des Poids et Mesures (BIPM). A synonym is "Zulu" time which is used by the civil aviation and represented by the letter "Z" (phonetically "Zulu").

genTime是TSA创建时间戳令牌的时间。它表示为UTC时间(协调世界时),以减少与本地时区使用的混淆。UTC是一种时间尺度,基于CCIR定义和建议的秒(SI),由国际计量局(BIPM)维护。一个同义词是“祖鲁”时间,民用航空使用,由字母“Z”(拼音为“祖鲁”)表示。

The ASN.1 GeneralizedTime syntax can include fraction-of-second details. Such syntax, without the restrictions from [RFC 2459] Section 4.1.2.5.2, where GeneralizedTime is limited to represent the time with a granularity of one second, may be used here.

ASN.1 GeneratedTime语法可以包含第二个细节的一小部分。在不受[RFC 2459]第4.1.2.5.2节限制的情况下,此处可以使用这种语法,其中GeneratedTime被限制为以1秒的粒度表示时间。

GeneralizedTime values MUST include seconds. However, when there is no need to have a precision better than the second, then GeneralizedTime with a precision limited to one second SHOULD be used (as in [RFC 2459]).

GeneralizedTime值必须包括秒。但是,如果不需要比第二个精度更好的精度,则应使用精度限制为1秒的GeneralizedTime(如[RFC 2459]中所述)。

The syntax is: YYYYMMDDhhmmss[.s...]Z Example: 19990609001326.34352Z

语法为:YYYYMMDDhhmmss[.s..]Z示例:19990609001326.34352Z

X.690 | ISO/IEC 8825-1 provides the following restrictions for a DER-encoding.

X.690 | ISO/IEC 8825-1为DER编码提供了以下限制。

The encoding MUST terminate with a "Z" (which means "Zulu" time). The decimal point element, if present, MUST be the point option ".". The fractional-seconds elements, if present, MUST omit all trailing 0's; if the elements correspond to 0, they MUST be wholly omitted, and the decimal point element also MUST be omitted.

编码必须以“Z”(表示“祖鲁”时间)结束。小数点元素(如果存在)必须是点选项“”。小数秒元素(如果存在)必须省略所有尾随的0;如果元素对应于0,则必须完全省略它们,并且还必须省略小数点元素。

Midnight (GMT) shall be represented in the form: "YYYYMMDD000000Z" where "YYYYMMDD" represents the day following the midnight in question.

午夜(GMT)应以“YYYYMMDD00000Z”的形式表示,其中“YYYYMMDD”表示所述午夜的第二天。

Here are a few examples of valid representations:

以下是一些有效表示的示例:

"19920521000000Z" "19920622123421Z" "19920722132100.3Z"

“19920521000MZ”“19920622123421Z”“1992072132100.3Z”

accuracy represents the time deviation around the UTC time contained in GeneralizedTime.

精度表示泛化时间中包含的UTC时间周围的时间偏差。

   Accuracy ::= SEQUENCE {
         seconds        INTEGER              OPTIONAL,
         millis     [0] INTEGER  (1..999)    OPTIONAL,
         micros     [1] INTEGER  (1..999)    OPTIONAL  }
        
   Accuracy ::= SEQUENCE {
         seconds        INTEGER              OPTIONAL,
         millis     [0] INTEGER  (1..999)    OPTIONAL,
         micros     [1] INTEGER  (1..999)    OPTIONAL  }
        

If either seconds, millis or micros is missing, then a value of zero MUST be taken for the missing field.

如果缺失秒、毫秒或微秒,则缺失字段的值必须为零。

By adding the accuracy value to the GeneralizedTime, an upper limit of the time at which the time-stamp token has been created by the TSA can be obtained. In the same way, by subtracting the accuracy to the GeneralizedTime, a lower limit of the time at which the time-stamp token has been created by the TSA can be obtained.

通过向GeneratedTime添加精度值,可以获得TSA创建时间戳令牌的时间上限。同样,通过将精度减去广义时间,可以获得TSA创建时间戳令牌的时间下限。

accuracy can be decomposed in seconds, milliseconds (between 1-999) and microseconds (1-999), all expressed as integer.

精度可以用秒、毫秒(1-999之间)和微秒(1-999)来分解,所有这些都表示为整数。

When the accuracy optional field is not present, then the accuracy may be available through other means, e.g., the TSAPolicyId.

当精度可选字段不存在时,可通过其他方式(例如,TSAPolicyId)获得精度。

If the ordering field is missing, or if the ordering field is present and set to false, then the genTime field only indicates the time at which the time-stamp token has been created by the TSA. In such a case, the ordering of time-stamp tokens issued by the same TSA or different TSAs is only possible when the difference between the genTime of the first time-stamp token and the genTime of the second time-stamp token is greater than the sum of the accuracies of the genTime for each time-stamp token.

如果缺少排序字段,或者如果排序字段存在并设置为false,则genTime字段仅指示TSA创建时间戳令牌的时间。在这种情况下,只有当第一个时间戳令牌的genTime和第二个时间戳令牌的genTime之间的差异大于每个时间戳令牌的genTime的精度之和时,才可能对由相同或不同的TSA发行的时间戳令牌进行排序。

If the ordering field is present and set to true, every time-stamp token from the same TSA can always be ordered based on the genTime field, regardless of the genTime accuracy.

如果排序字段存在并设置为true,则来自同一TSA的每个时间戳令牌始终可以基于genTime字段排序,而不管genTime的准确性如何。

The nonce field MUST be present if it was present in the TimeStampReq. In such a case it MUST equal the value provided in the TimeStampReq structure.

如果时间戳请求中存在nonce字段,则该字段必须存在。在这种情况下,它必须等于TimeStampReq结构中提供的值。

The purpose of the tsa field is to give a hint in identifying the name of the TSA. If present, it MUST correspond to one of the subject names included in the certificate that is to be used to verify the token. However, the actual identification of the entity that signed the response will always occur through the use of the certificate identifier (ESSCertID Attribute) inside a SigningCertificate attribute which is part of the signerInfo (See Section 5 of [ESS]).

tsa字段的目的是给出识别tsa名称的提示。如果存在,则必须与证书中包含的用于验证令牌的主体名称之一相对应。但是,签名响应的实体的实际标识将始终通过在作为SignerinInfo一部分的SigningCertificate属性中使用证书标识符(ESSCertID属性)来实现(参见[ESS]第5节)。

extensions is a generic way to add additional information in the future. Extensions is defined in [RFC 2459].

扩展是将来添加附加信息的通用方法。扩展在[RFC 2459]中定义。

Particular extension field types may be specified in standards or may be defined and registered by any organization or community.

特定的扩展字段类型可以在标准中指定,也可以由任何组织或社区定义和注册。

3. Transports
3. 运输

There is no mandatory transport mechanism for TSA messages in this document. The mechanisms described below are optional; additional optional mechanisms may be defined in the future.

本文档中没有TSA消息的强制传输机制。下面描述的机制是可选的;将来可能会定义其他可选机制。

3.1. Time-Stamp Protocol Using E-mail
3.1. 使用电子邮件的时间戳协议

This section specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 2 and Appendix D via Internet mail.

本节规定了通过互联网邮件为第2节和附录D所述协议交换传送ASN.1编码消息的方法。

Two MIME objects are specified as follows:

指定两个MIME对象,如下所示:

   Content-Type: application/timestamp-query
   Content-Transfer-Encoding: base64
   <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
        
   Content-Type: application/timestamp-query
   Content-Transfer-Encoding: base64
   <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
        
   Content-Type: application/timestamp-reply
   Content-Transfer-Encoding: base64
   <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
        
   Content-Type: application/timestamp-reply
   Content-Transfer-Encoding: base64
   <<the ASN.1 DER-encoded Time-Stamp message, base64-encoded>>
        

These MIME objects can be respectively sent and received using common MIME processing engines and provides a simple Internet mail transport for Time-Stamp messages.

这些MIME对象可以使用常见的MIME处理引擎分别发送和接收,并为时间戳消息提供简单的Internet邮件传输。

For the application/timestamp-query and application/timestamp-reply MIME types, implementations SHOULD include the optional "name" and "filename" parameters. Including a file name helps preserve type information when time-stamp queries and replies are saved as files. When these parameters are included, a file name with the appropriate extension SHOULD be selected:

对于应用程序/时间戳查询和应用程序/时间戳回复MIME类型,实现应该包括可选的“name”和“filename”参数。包含文件名有助于在时间戳查询和答复保存为文件时保留类型信息。包含这些参数时,应选择具有适当扩展名的文件名:

MIME Type File Extension application/timestamp-query .TSQ application/timestamp-reply .TSR

MIME类型文件扩展名application/timestamp query.TSQ application/timestamp reply.TSR

In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name.

此外,文件名应限制为八个字符,后跟三个字母的扩展名。八个字符的文件名基可以是任何不同的名称。

3.2. File Based Protocol
3.2. 基于文件的协议

A file containing a time-stamp message MUST contain only the DER encoding of one TSA message, i.e., there MUST be no extraneous header or trailer information in the file. Such files can be used to transport time stamp messages using for example, FTP.

包含时间戳消息的文件必须仅包含一条TSA消息的DER编码,即文件中不得有无关的头或尾信息。此类文件可用于传输时间戳消息,例如使用FTP。

A Time-Stamp Request SHOULD be contained in a file with file extension .tsq (like Time-Stamp Query). A Time-Stamp Response SHOULD be contained in a file with file extension .tsr (like Time-Stamp Reply).

时间戳请求应该包含在文件扩展名为.tsq的文件中(类似于时间戳查询)。时间戳响应应该包含在文件扩展名为.tsr的文件中(类似于时间戳回复)。

3.3. Socket Based Protocol
3.3. 基于套接字的协议

The following simple TCP-based protocol is to be used for transport of TSA messages. This protocol is suitable for cases where an entity initiates a transaction and can poll to pick up the results.

以下基于TCP的简单协议用于传输TSA消息。此协议适用于实体启动事务并可以轮询以获取结果的情况。

The protocol basically assumes a listener process on a TSA that can accept TSA messages on a well-defined port (IP port number 318).

该协议基本上假设TSA上有一个侦听器进程,可以在定义良好的端口(IP端口号318)上接受TSA消息。

Typically an initiator binds to this port and submits the initial TSA message. The responder replies with a TSA message and/or with a reference number to be used later when polling for the actual TSA message response.

通常,启动器绑定到此端口并提交初始TSA消息。响应者回复TSA消息和/或参考号,以便稍后在轮询实际TSA消息响应时使用。

If a number of TSA response messages are to be produced for a given request (say if a receipt must be sent before the actual token can be produced) then a new polling reference is also returned.

如果要为给定请求生成多个TSA响应消息(例如,如果必须在生成实际令牌之前发送回执),则还将返回一个新的轮询引用。

When the final TSA response message has been picked up by the initiator then no new polling reference is supplied.

当启动器拾取最终TSA响应消息时,不提供新的轮询引用。

The initiator of a transaction sends a "direct TCP-based TSA message" to the recipient. The recipient responds with a similar message.

事务的发起人向收件人发送“基于TCP的直接TSA消息”。接收者也会回复类似的消息。

A "direct TCP-based TSA message" consists of: length (32-bits), flag (8-bits), value (defined below)

“基于TCP的直接TSA消息”包括:长度(32位)、标志(8位)、值(定义如下)

The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order.

“长度”字段包含消息其余部分的八位字节数(即“值”加一的八位字节数)。此协议中的所有32位值都指定为网络字节顺序。

   Message name   flag     value
   tsaMsg         '00'H    DER-encoded TSA message
     -- TSA message
   pollRep        '01'H    polling reference (32 bits),
                           time-to-check-back (32 bits)
     -- poll response where no TSA message response ready; use polling
     -- reference value (and estimated time value) for later polling
   pollReq        '02'H    polling reference (32 bits)
     -- request for a TSA message response to initial message
   negPollRep     '03'H    '00'H
     -- no further polling responses (i.e., transaction complete)
   partialMsgRep  '04'H    next polling reference (32 bits),
                           time-to-check-back (32 bits),
                           DER-encoded TSA message
     -- partial response (receipt) to initial message plus new polling
     -- reference (and estimated time value) to use to get next part of
     -- response
   finalMsgRep    '05'H    DER-encoded TSA message
     -- final (and possibly sole) response to initial message
   errorMsgRep    '06'H    human readable error message
     -- produced when an error is detected (e.g., a polling reference
     -- is received which doesn't exist or is finished with)
        
   Message name   flag     value
   tsaMsg         '00'H    DER-encoded TSA message
     -- TSA message
   pollRep        '01'H    polling reference (32 bits),
                           time-to-check-back (32 bits)
     -- poll response where no TSA message response ready; use polling
     -- reference value (and estimated time value) for later polling
   pollReq        '02'H    polling reference (32 bits)
     -- request for a TSA message response to initial message
   negPollRep     '03'H    '00'H
     -- no further polling responses (i.e., transaction complete)
   partialMsgRep  '04'H    next polling reference (32 bits),
                           time-to-check-back (32 bits),
                           DER-encoded TSA message
     -- partial response (receipt) to initial message plus new polling
     -- reference (and estimated time value) to use to get next part of
     -- response
   finalMsgRep    '05'H    DER-encoded TSA message
     -- final (and possibly sole) response to initial message
   errorMsgRep    '06'H    human readable error message
     -- produced when an error is detected (e.g., a polling reference
     -- is received which doesn't exist or is finished with)
        

The sequence of messages that can occur is:

可能出现的消息顺序为:

a) entity sends tsaMsg and receives one of pollRep, negPollRep, partialMsgRep, or finalMsgRep in response.

a) 实体发送TSAMG并接收pollRep、negPollRep、partialMsgRep或finalMsgRep中的一个作为响应。

b) end entity sends pollReq message and receives one of negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep in response.

b) 终端实体发送pollReq消息,并在响应中接收negPollRep、partialMsgRep、finalMsgRep或errorMsgRep中的一个。

The "time-to-check-back" parameter is an unsigned 32-bit integer. It is the time in seconds indicating the minimum interval after which the client SHOULD check the status again.

“检查时间”参数是一个无符号32位整数。它是以秒为单位的时间,指示客户端再次检查状态的最小间隔。

It provides an estimate of the time that the end entity should send its next pollReq.

它提供了终端实体应该发送下一个pollReq的时间估计。

3.4. Time-Stamp Protocol via HTTP
3.4. 基于HTTP的时间戳协议

This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 2 and Appendix D via the HyperText Transfer Protocol.

本小节规定了通过超文本传输协议为第2节和附录D中描述的协议交换传输ASN.1编码消息的方法。

Two MIME objects are specified as follows.

下面指定了两个MIME对象。

Content-Type: application/timestamp-query

内容类型:应用程序/时间戳查询

      <<the ASN.1 DER-encoded Time-Stamp Request message>>
        
      <<the ASN.1 DER-encoded Time-Stamp Request message>>
        

Content-Type: application/timestamp-reply

内容类型:应用程序/时间戳回复

      <<the ASN.1 DER-encoded Time-Stamp Response message>>
        
      <<the ASN.1 DER-encoded Time-Stamp Response message>>
        

These MIME objects can be sent and received using common HTTP processing engines over WWW links and provides a simple browser-server transport for Time-Stamp messages.

这些MIME对象可以使用通用HTTP处理引擎通过WWW链接发送和接收,并为时间戳消息提供了一个简单的浏览器服务器传输。

Upon receiving a valid request, the server MUST respond with either a valid response with content type application/timestamp-response or with an HTTP error.

收到有效请求后,服务器必须使用内容类型为application/timestamp response的有效响应或HTTP错误进行响应。

4. Security Considerations
4. 安全考虑

This entire document concerns security considerations. When designing a TSA service, the following considerations have been identified that have an impact upon the validity or "trust" in the time-stamp token.

整个文件涉及安全考虑。在设计TSA服务时,已经确定了对时间戳令牌的有效性或“信任”有影响的以下考虑因素。

1. When a TSA shall not be used anymore, but the TSA private key has not been compromised, the authority's certificate SHALL be revoked. When the reasonCode extension relative to the revoked certificate from the TSA is present in the CRL entry extensions, it SHALL be set either to unspecified (0), affiliationChanged (3), superseded (4) or cessationOfOperation (5). In that case, at any future time, the tokens signed with the corresponding key will be considered as invalid, but tokens generated before the revocation time will remain valid. When the reasonCode extension relative to the revoked certificate from the TSA is not present in the CRL entry extensions, then all the tokens that have been signed with the corresponding key SHALL be considered as invalid. For that reason, it is recommended to use the reasonCode extension.

1. 当TSA不再使用,但TSA私钥未被泄露时,管理局的证书应被撤销。当CRL条目扩展中存在与TSA吊销证书相关的原因代码扩展时,应将其设置为未指定(0)、更改(3)、取代(4)或操作许可(5)。在这种情况下,在将来的任何时候,使用相应密钥签名的令牌将被视为无效,但在撤销时间之前生成的令牌将保持有效。当CRL条目扩展中不存在与TSA吊销证书相关的推理代码扩展时,则所有使用相应密钥签名的令牌应视为无效。因此,建议使用reasonCode扩展。

2. When the TSA private key has been compromised, then the corresponding certificate SHALL be revoked. In that case, the reasonCode extension relative to the revoked certificate from the TSA may or may not be present in the CRL entry extensions. When it is present then it SHALL be set to keyCompromise (1). Any token signed by the TSA using that private key cannot be trusted anymore. For this reason, it is imperative that the TSA's private key be guarded with proper security and controls in order to minimize the possibility of compromise. In case the private key does become compromised, an audit trail of all tokens generated by the TSA MAY provide a means to discriminate between genuine and false backdated tokens. Two time-stamp tokens from two different TSAs is another way to address this issue.

2. 当TSA私钥被泄露时,相应的证书应被撤销。在这种情况下,与来自TSA的吊销证书相关的推理代码扩展可能存在于CRL条目扩展中,也可能不存在于CRL条目扩展中。当存在时,应将其设置为KeyConvention(1)。TSA使用该私钥签名的任何令牌都不再可信。因此,TSA的私钥必须采用适当的安全性和控制措施加以保护,以最大限度地减少泄露的可能性。如果私钥确实被泄露,则TSA生成的所有令牌的审计跟踪可提供区分真实和错误回溯令牌的方法。来自两个不同TSA的两个时间戳令牌是解决此问题的另一种方法。

3. The TSA signing key MUST be of a sufficient length to allow for a sufficiently long lifetime. Even if this is done, the key will have a finite lifetime. Thus, any token signed by the TSA SHOULD be time-stamped again (if authentic copies of old CRLs are available) or notarized (if they aren't) at a later date to renew the trust that exists in the TSA's signature. time-stamp tokens could also be kept with an Evidence Recording Authority to maintain this trust.

3. TSA签名密钥必须具有足够的长度,以允许足够长的生命周期。即使这样做,密钥也将有一个有限的生命周期。因此,TSA签署的任何代币应再次加盖时间戳(如果旧CRL的真实副本可用)或在以后的日期公证(如果没有),以更新TSA签名中存在的信托。时间戳令牌也可以由证据记录机构保存,以维持这种信任。

4. A client application using only a nonce and no local clock SHOULD be concerned about the amount of time it is willing to wait for a response. A `man-in-the-middle' attack can introduce delays. Thus, any TimeStampResp that takes more than an acceptable period of time SHOULD be considered suspect. Since each transport method specified in this document has different delay characteristics, the period of time that is considered acceptable will depend upon the particular transport method used, as well as other environment factors.

4. 仅使用nonce而不使用本地时钟的客户端应用程序应该关心它愿意等待响应的时间量。“中间人”攻击会导致延迟。因此,任何超过可接受时间段的时间戳都应被视为可疑。由于本文件中规定的每种运输方法具有不同的延迟特性,因此认为可接受的时间段将取决于所使用的特定运输方法以及其他环境因素。

5. If different entities obtain time-stamp tokens on the same data object using the same hash algorithm, or a single entity obtains multiple time-stamp tokens on the same object, the generated time-stamp tokens will include identical message imprints; as a result, an observer with access to those time-stamp tokens could infer that the time-stamps may refer to the same underlying data.

5. 如果不同实体使用相同的哈希算法在同一数据对象上获得时间戳令牌,或者单个实体在同一对象上获得多个时间戳令牌,则生成的时间戳令牌将包括相同的消息印记;因此,能够访问这些时间戳令牌的观察者可以推断时间戳可能引用相同的底层数据。

6. Inadvertent or deliberate replays for requests incorporating the same hash algorithm and value may happen. Inadvertent replays occur when more than one copy of the same request message gets sent to the TSA because of problems in the intervening network elements. Deliberate replays occur when a middleman is replaying legitimate TS responses. In order to detect these situations, several techniques may be used. Using a nonce always allows to detect replays, and hence its use is RECOMMENDED. Another possibility is to use both a local clock and a moving time window during which the requester remembers all the hashes sent during that time window. When receiving a response, the requester ensures both that the time of the response is within the time window and that there is only one occurrence of the hash value in that time window. If the same hash value is present more than once within a time window, the requester may either use a nonce, or wait until the time window has moved to come back to the case where the same hash value appears only once during that time window.

6. 对于包含相同哈希算法和值的请求,可能会发生无意或故意的重播。由于介入网络元件中的问题,当同一请求消息的多个副本被发送到TSA时,会发生意外重播。当中间人重播合法的TS响应时,会发生故意重播。为了检测这些情况,可以使用几种技术。使用nonce总是允许检测重播,因此建议使用它。另一种可能是同时使用本地时钟和移动时间窗口,在此期间请求者记住在该时间窗口期间发送的所有哈希。当接收到响应时,请求者确保响应的时间在时间窗口内,并且在该时间窗口中仅出现一次哈希值。如果相同的散列值在一个时间窗口内出现不止一次,请求者可以使用nonce,或者等到时间窗口移动后返回到相同的散列值在该时间窗口内只出现一次的情况。

5. Intellectual Property Rights
5. 知识产权

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to per-tain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

IETF对本文件所述技术的实施或使用可能要求的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息,请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。

The following eight (8) United States Patents related to time stamping, listed in chronological order, are known by the authors to exist at this time. This may not be an exhaustive list. Other patents MAY exist or be issued at any time. This list is provided for informational purposes; to date, the IETF has not been notified of intellectual property rights claimed in regard to any of the

以下八(8)项与时间戳相关的美国专利,按时间顺序列出,作者已知此时存在。这可能不是一份详尽的清单。其他专利可能存在或随时发布。本清单仅供参考;迄今为止,IETF尚未收到任何与以下内容相关的知识产权要求通知:

specification contained in this document. Should this situation change, the current status may be found at the online list of claimed rights (IETF Page of Intellectual Property Rights Notices).

本文件中包含的规范。如果这种情况发生变化,可在在线权利声明列表(IETF知识产权声明页面)中找到当前状态。

Implementers of this protocol SHOULD perform their own patent search and determine whether or not any encumbrances exist on their implementation.

本协议的实施者应自行进行专利检索,并确定其实施是否存在任何产权负担。

Users of this protocol SHOULD perform their own patent search and determine whether or not any encumbrances exist on the use of this standard.

本协议的用户应自行进行专利检索,并确定本标准的使用是否存在任何产权负担。

# 5,001,752 Public/Key Date-Time Notary Facility Filing date: October 13, 1989 Issued: March 19, 1991 Inventor: Addison M. Fischer

#5001752公开/关键日期时间公证机构申请日期:1989年10月13日发布日期:1991年3月19日发明人:Addison M.Fischer

# 5,022,080 Electronic Notary Filing date: April 16, 1989 Issued: June 4, 1991 Inventors: Robert T. Durst, Kevin D. Hunter

#5022080电子公证申请日期:1989年4月16日发布日期:1991年6月4日发明人:罗伯特·T·杜斯特,凯文·D·亨特

# 5,136,643 Public/Key Date-Time Notary Facility Filing date: December 20, 1990 Issued: August 4, 1992 Inventor: Addison M. Fischer Note: This is a continuation of patent # 5,001,752.)

#5136643公开/关键日期时间公证机构申请日期:1990年12月20日发布日期:1992年8月4日发明人:Addison M.Fischer注:这是专利#5001752的延续。)

# 5,136,646 Digital Document Time-Stamping with Catenate Certificate Filing date: August 2, 1990 Issued: August 4, 1992 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. (assignee) Bell Communications Research, Inc.,

#5136646带连系证书的数字文件时间戳提交日期:1990年8月2日发布日期:1992年8月4日发明人:斯图尔特A.哈伯,韦克菲尔德S.斯托内塔Jr.(受让人)贝尔通信研究公司。,

# 5,136,647 Method for Secure Time-Stamping of Digital Documents Filing date: August 2, 1990 Issued: August 4, 1992 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. (assignee) Bell Communications Research, Inc.,

#5136647数字文件安全时间戳方法提交日期:1990年8月2日发布日期:1992年8月4日发明人:斯图尔特A.哈伯,韦克菲尔德S.斯托内塔Jr.(受让人)贝尔通信研究公司。,

# 5,373,561 Method of Extending the Validity of a Cryptographic Certificate Filing date: December 21, 1992 Issued: December 13, 1994 Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr. (assignee) Bell Communications Research, Inc.,

#5373561延长加密证书有效期的方法申请日期:1992年12月21日发布日期:1994年12月13日发明人:斯图尔特a.哈伯,韦克菲尔德S.斯托内塔Jr.(受让人)贝尔通信研究公司。,

# 5,422,953 Personal Date/Time Notary Device Filing date: May 5, 1993 Issued: June 6, 1995 Inventor: Addison M. Fischer

#5422953个人日期/时间公证装置申请日期:1993年5月5日发布日期:1995年6月6日发明人:Addison M.Fischer

# 5,781,629 Digital Document Authentication System Filing date: February 21, 1997 Issued: July 14, 1998 Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr. (assignee) Surety Technologies, Inc.,

#5781629数字文件认证系统申请日期:1997年2月21日发布日期:1998年7月14日发明人:Stuart A.Haber,Wakefield S.Stornetta Jr.(受让人)Surety Technologies,Inc。,

6. References
6. 工具书类

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.

[RFC2246]Dierks,T.和C.Allen,“TLS协议,版本1.0”,RFC2246,1999年1月。

[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 2510, March 1999.

[RFC2510]Adams,C.和S.Farrell,“互联网X.509公钥基础设施,证书管理协议”,RFC25101999年3月。

[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.

[RFC2459]Housley,R.,Ford,W.,Polk,W.和D.Solo,“互联网X.509公钥基础设施,证书和CRL配置文件”,RFC 2459,1999年1月。

[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

[CMS]Housley,R.,“加密消息语法”,RFC 2630,1999年6月。

[DSS] Digital Signature Standard. FIPS Pub 186. National Institute of Standards and Technology. 19 May 1994.

[DSS]数字签名标准。FIPS第186号酒吧。国家标准与技术研究所。1994年5月19日。

[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.

[ESS]Hoffman,P.,“S/MIME的增强安全服务”,RFC 2634,1999年6月。

[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.

[ISONR]ISO/IEC 10181-5:开放系统中的安全框架。不可否认框架。1997年4月。

[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

[MD5]Rivest,R.,“MD5消息摘要算法”,RFC 13211992年4月。

[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 17 April 1995.

[SHA1]安全哈希标准。FIPS Pub 180-1。国家标准与技术研究所。1995年4月17日。

7. Authors' Addresses
7. 作者地址

Carlisle Adams Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 CANADA

卡莱尔·亚当斯信托公司,加拿大安大略省渥太华市创新大道1000号K2K 3E7

   EMail: cadams@entrust.com
        
   EMail: cadams@entrust.com
        

Pat Cain BBN 70 Fawcett Street Cambridge, MA 02138 U.S.A.

美国马萨诸塞州剑桥福塞特街70号帕特凯恩BBN 02138。

   EMail: pcain@bbn.com
        
   EMail: pcain@bbn.com
        

Denis Pinkas Integris 68 route de Versailles B.P. 434 78430 Louveciennes FRANCE

Denis Pinkas Integris 68 route de Versailles B.P.434 78430 Louveciennes法国

   EMail: Denis.Pinkas@bull.net
        
   EMail: Denis.Pinkas@bull.net
        

Robert Zuccherato Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 CANADA

Robert Zuccherato Trust,Inc.加拿大安大略省渥太华市创新大道1000号K2K 3E7

   EMail: robert.zuccherato@entrust.com
        
   EMail: robert.zuccherato@entrust.com
        

APPENDIX A - Signature Time-stamp attribute using CMS

附录A-使用CMS的签名时间戳属性

One of the major uses of time-stamping is to time-stamp a digital signature to prove that the digital signature was created before a given time. Should the corresponding public key certificate be revoked this allows a verifier to know whether the signature was created before or after the revocation date.

时间戳的主要用途之一是给数字签名加上时间戳,以证明数字签名是在给定时间之前创建的。如果相应的公钥证书被撤销,这允许验证者知道签名是在撤销日期之前还是之后创建的。

A sensible place to store a time-stamp is in a [CMS] structure as an unsigned attribute.

存储时间戳的合理位置是在[CMS]结构中作为未签名属性。

This appendix defines a Signature Time-stamp attribute that may be used to time-stamp a digital signature.

本附录定义了可用于数字签名时间戳的签名时间戳属性。

The following object identifier identifies the Signature Time-stamp attribute:

以下对象标识符标识签名时间戳属性:

   id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }
        
   id-aa-timeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }
        

The Signature time-stamp attribute value has ASN.1 type SignatureTimeStampToken:

签名时间戳属性值具有ASN.1类型SignatureTimeStampToken:

   SignatureTimeStampToken ::= TimeStampToken
        
   SignatureTimeStampToken ::= TimeStampToken
        

The value of messageImprint field within TimeStampToken shall be a hash of the value of signature field within SignerInfo for the signedData being time-stamped.

TimeStampToken中messageImprint字段的值应是SignerInfo中签名字段的值的散列,用于标记时间的已签名数据。

APPENDIX B - Placing a Signature At a Particular Point in Time

附录B-在特定时间点放置签名

We present an example of a possible use of this general time-stamping service. It places a signature at a particular point in time, from which the appropriate certificate status information (e.g., CRLs) MUST be checked. This application is intended to be used in conjunction with evidence generated using a digital signature mechanism.

我们提供了一个可能使用此通用时间戳服务的示例。它在特定时间点放置签名,必须从该时间点检查适当的证书状态信息(例如CRL)。本应用程序旨在与使用数字签名机制生成的证据一起使用。

Signatures can only be verified according to a non-repudiation policy. This policy MAY be implicit or explicit (i.e., indicated in the evidence provided by the signer). The non-repudiation policy can specify, among other things, the time period allowed by a signer to declare the compromise of a signature key used for the generation of digital signatures. Thus a signature may not be guaranteed to be valid until the termination of this time period.

签名只能根据不可否认策略进行验证。该政策可以是隐含的或明确的(即,在签字人提供的证据中指明)。除其他外,不可否认策略可以指定签名者声明用于生成数字签名的签名密钥的泄露所允许的时间段。因此,在这段时间结束之前,签名可能无法保证有效。

To verify a digital signature, the following basic technique may be used:

为了验证数字签名,可以使用以下基本技术:

A) Time-stamping information needs to be obtained soon after the signature has been produced (e.g., within a few minutes or hours).

A) 签名产生后(例如,几分钟或几小时内)需要立即获得时间戳信息。

1) The signature is presented to the Time Stamping Authority (TSA). The TSA then returns a TimeStampToken (TST) upon that signature.

1) 签名提交给时间戳管理局(TSA)。然后,TSA根据该签名返回时间戳令牌(TST)。

2) The invoker of the service MUST then verify that the TimeStampToken is correct.

2) 然后,服务的调用方必须验证TimeStampToken是否正确。

B) The validity of the digital signature may then be verified in the following way:

B) 然后可通过以下方式验证数字签名的有效性:

1) The time-stamp token itself MUST be verified and it MUST be verified that it applies to the signature of the signer.

1) 必须验证时间戳令牌本身,并且必须验证它是否适用于签名者的签名。

2) The date/time indicated by the TSA in the TimeStampToken MUST be retrieved.

2) 必须检索时间戳令牌中TSA指示的日期/时间。

3) The certificate used by the signer MUST be identified and retrieved.

3) 必须识别并检索签名者使用的证书。

4) The date/time indicated by the TSA MUST be within the validity period of the signer's certificate.

4) TSA指示的日期/时间必须在签字人证书的有效期内。

5) The revocation information about that certificate, at the date/time of the Time-Stamping operation, MUST be retrieved.

5) 必须检索在时间戳操作的日期/时间有关该证书的吊销信息。

6) Should the certificate be revoked, then the date/time of revocation shall be later than the date/time indicated by the TSA.

6) 如果证书被撤销,则撤销日期/时间应晚于TSA指示的日期/时间。

If all these conditions are successful, then the digital signature shall be declared as valid.

如果所有这些条件都成功,则应宣布数字签名有效。

APPENDIX C: ASN.1 Module using 1988 Syntax

附录C:使用1988语法的ASN.1模块

PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
        
PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
        
DEFINITIONS IMPLICIT TAGS ::=
        
DEFINITIONS IMPLICIT TAGS ::=
        

BEGIN

开始

-- EXPORTS ALL --

--全部出口--

IMPORTS

进口

     Extensions, AlgorithmIdentifier
     FROM PKIX1Explicit88 {iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7)
     id-mod(0) id-pkix1-explicit-88(1)}
        
     Extensions, AlgorithmIdentifier
     FROM PKIX1Explicit88 {iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7)
     id-mod(0) id-pkix1-explicit-88(1)}
        
     GeneralName FROM PKIX1Implicit88 {iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
        
     GeneralName FROM PKIX1Implicit88 {iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
        
     ContentInfo FROM CryptographicMessageSyntax {iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) modules(0) cms(1)}
        
     ContentInfo FROM CryptographicMessageSyntax {iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) modules(0) cms(1)}
        
     PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-cmp(9)} ;
        
     PKIFreeText FROM PKIXCMP {iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-cmp(9)} ;
        

-- Locally defined OIDs --

--局部定义的OID--

-- eContentType for a time-stamp token

--时间戳令牌的eContentType

id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
        
id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
        

-- 2.4.1

-- 2.4.1

TimeStampReq ::= SEQUENCE  {
   version                  INTEGER  { v1(1) },
   messageImprint           MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
     --time-stamped
   reqPolicy                TSAPolicyId                OPTIONAL,
   nonce                    INTEGER                    OPTIONAL,
   certReq                  BOOLEAN                    DEFAULT FALSE,
   extensions               [0] IMPLICIT Extensions    OPTIONAL  }
        
TimeStampReq ::= SEQUENCE  {
   version                  INTEGER  { v1(1) },
   messageImprint           MessageImprint,
     --a hash algorithm OID and the hash value of the data to be
     --time-stamped
   reqPolicy                TSAPolicyId                OPTIONAL,
   nonce                    INTEGER                    OPTIONAL,
   certReq                  BOOLEAN                    DEFAULT FALSE,
   extensions               [0] IMPLICIT Extensions    OPTIONAL  }
        
MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }
        
MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }
        
TSAPolicyId ::= OBJECT IDENTIFIER
        
TSAPolicyId ::= OBJECT IDENTIFIER
        

-- 2.4.2

-- 2.4.2

TimeStampResp ::= SEQUENCE  {
     status                  PKIStatusInfo,
     timeStampToken          TimeStampToken     OPTIONAL  }
        
TimeStampResp ::= SEQUENCE  {
     status                  PKIStatusInfo,
     timeStampToken          TimeStampToken     OPTIONAL  }
        
-- The status is based on the definition of status
-- in section 3.2.3 of [RFC2510]
        
-- The status is based on the definition of status
-- in section 3.2.3 of [RFC2510]
        
PKIStatusInfo ::= SEQUENCE {
    status        PKIStatus,
    statusString  PKIFreeText     OPTIONAL,
    failInfo      PKIFailureInfo  OPTIONAL  }
        
PKIStatusInfo ::= SEQUENCE {
    status        PKIStatus,
    statusString  PKIFreeText     OPTIONAL,
    failInfo      PKIFailureInfo  OPTIONAL  }
        
PKIStatus ::= INTEGER {
    granted                (0),
    -- when the PKIStatus contains the value zero a TimeStampToken, as
       requested, is present.
    grantedWithMods        (1),
     -- when the PKIStatus contains the value one a TimeStampToken,
       with modifications, is present.
    rejection              (2),
    waiting                (3),
    revocationWarning      (4),
     -- this message contains a warning that a revocation is
     -- imminent
    revocationNotification (5)
     -- notification that a revocation has occurred   }
        
PKIStatus ::= INTEGER {
    granted                (0),
    -- when the PKIStatus contains the value zero a TimeStampToken, as
       requested, is present.
    grantedWithMods        (1),
     -- when the PKIStatus contains the value one a TimeStampToken,
       with modifications, is present.
    rejection              (2),
    waiting                (3),
    revocationWarning      (4),
     -- this message contains a warning that a revocation is
     -- imminent
    revocationNotification (5)
     -- notification that a revocation has occurred   }
        
    -- When the TimeStampToken is not present
    -- failInfo indicates the reason why the
    -- time-stamp request was rejected and
    -- may be one of the following values.
        
    -- When the TimeStampToken is not present
    -- failInfo indicates the reason why the
    -- time-stamp request was rejected and
    -- may be one of the following values.
        
PKIFailureInfo ::= BIT STRING {
    badAlg               (0),
      -- unrecognized or unsupported Algorithm Identifier
    badRequest           (2),
      -- transaction not permitted or supported
    badDataFormat        (5),
      -- the data submitted has the wrong format
    timeNotAvailable    (14),
      -- the TSA's time source is not available
    unacceptedPolicy    (15),
      -- the requested TSA policy is not supported by the TSA.
    unacceptedExtension (16),
      -- the requested extension is not supported by the TSA.
    addInfoNotAvailable (17)
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }
        
PKIFailureInfo ::= BIT STRING {
    badAlg               (0),
      -- unrecognized or unsupported Algorithm Identifier
    badRequest           (2),
      -- transaction not permitted or supported
    badDataFormat        (5),
      -- the data submitted has the wrong format
    timeNotAvailable    (14),
      -- the TSA's time source is not available
    unacceptedPolicy    (15),
      -- the requested TSA policy is not supported by the TSA.
    unacceptedExtension (16),
      -- the requested extension is not supported by the TSA.
    addInfoNotAvailable (17)
      -- the additional information requested could not be understood
      -- or is not available
    systemFailure       (25)
      -- the request cannot be handled due to system failure  }
        
TimeStampToken ::= ContentInfo
        
TimeStampToken ::= ContentInfo
        
     -- contentType is id-signedData as defined in [CMS]
     -- content is SignedData as defined in([CMS])
     -- eContentType within SignedData is id-ct-TSTInfo
     -- eContent within SignedData is TSTInfo
        
     -- contentType is id-signedData as defined in [CMS]
     -- content is SignedData as defined in([CMS])
     -- eContentType within SignedData is id-ct-TSTInfo
     -- eContent within SignedData is TSTInfo
        
TSTInfo ::= SEQUENCE  {
    version                      INTEGER  { v1(1) },
    policy                       TSAPolicyId,
    messageImprint               MessageImprint,
      -- MUST have the same value as the similar field in
      -- TimeStampReq
    serialNumber                 INTEGER,
     -- Time-Stamping users MUST be ready to accommodate integers
     -- up to 160 bits.
    genTime                      GeneralizedTime,
    accuracy                     Accuracy                 OPTIONAL,
    ordering                     BOOLEAN             DEFAULT FALSE,
    nonce                        INTEGER                  OPTIONAL,
      -- MUST be present if the similar field was present
      -- in TimeStampReq.  In that case it MUST have the same value.
    tsa                          [0] GeneralName          OPTIONAL,
    extensions                   [1] IMPLICIT Extensions  OPTIONAL   }
        
TSTInfo ::= SEQUENCE  {
    version                      INTEGER  { v1(1) },
    policy                       TSAPolicyId,
    messageImprint               MessageImprint,
      -- MUST have the same value as the similar field in
      -- TimeStampReq
    serialNumber                 INTEGER,
     -- Time-Stamping users MUST be ready to accommodate integers
     -- up to 160 bits.
    genTime                      GeneralizedTime,
    accuracy                     Accuracy                 OPTIONAL,
    ordering                     BOOLEAN             DEFAULT FALSE,
    nonce                        INTEGER                  OPTIONAL,
      -- MUST be present if the similar field was present
      -- in TimeStampReq.  In that case it MUST have the same value.
    tsa                          [0] GeneralName          OPTIONAL,
    extensions                   [1] IMPLICIT Extensions  OPTIONAL   }
        
Accuracy ::= SEQUENCE {
                seconds        INTEGER           OPTIONAL,
                millis     [0] INTEGER  (1..999) OPTIONAL,
                micros     [1] INTEGER  (1..999) OPTIONAL  }
        
Accuracy ::= SEQUENCE {
                seconds        INTEGER           OPTIONAL,
                millis     [0] INTEGER  (1..999) OPTIONAL,
                micros     [1] INTEGER  (1..999) OPTIONAL  }
        

END

终止

APPENDIX D: Access descriptors for Time-Stamping.

附录D:时间戳访问描述符。

[This annex describes an extension based on the SIA extension that will be defined in the "son-of-RFC2459". Since at the time of publication of this document, "son-of-RFC2459" is not yet available, its description is placed in an informative annex. The contents of this annex will eventually become incorporated into the son-of-RFC2459 document, at which time this annex will no longer be needed. A future version of this document will likely omit this annex and refer to son-of-RFC2459 directly.]

[本附件描述了基于SIA扩展的扩展,该扩展将在“son-of-RFC2459”中定义。自本文件发布之时起,“son-of-RFC2459”尚未提供,其说明放在资料性附录中。本附录的内容最终将并入son-of-RFC2459文件,届时不再需要本附录。本文件的未来版本可能会省略本附录,并直接参考son-of-RFC2459。]

A TSA's certificate MAY contain a Subject Information Access (SIA) extension (son of RFC2459) in order to convey the method of contacting the TSA. The accessMethod field in this extension MUST contain the OID id-ad-timestamping:

TSA证书可能包含主题信息访问(SIA)扩展(RFC2459之子),以传达联系TSA的方法。此扩展中的accessMethod字段必须包含OID id ad时间戳:

The following object identifier identifies the access descriptors for time-Stamping.

以下对象标识符标识时间戳的访问描述符。

   id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
                         identified-organization(3) dod(6)
                         internet(1) security(5) mechanisms(5) pkix(7)
                         ad (48) timestamping (3)}
        
   id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
                         identified-organization(3) dod(6)
                         internet(1) security(5) mechanisms(5) pkix(7)
                         ad (48) timestamping (3)}
        

The value of the accessLocation field defines the transport (e.g., HTTP) used to access the TSA and may contain other transport dependent information (e.g., a URL).

accessLocation字段的值定义了用于访问TSA的传输(例如HTTP),并且可能包含其他传输相关信息(例如URL)。

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

版权所有(C)互联网协会(2001年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。