RFC3161 日本語訳
3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol(TSP). C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001. (Format: TXT=54585 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Adams
Request for Comments: 3161 Entrust
Category: Standards Track P. Cain
BBN
D. Pinkas
Integris
R. Zuccherato
Entrust
August 2001
コメントを求めるワーキンググループC.アダムスの要求をネットワークでつないでください: 3161はカテゴリをゆだねます: R.Zuccheratoが2001年8月にゆだねる標準化過程P.カインBBN D.ピンカスIntegris
Internet X.509 Public Key Infrastructure
Time-Stamp Protocol (TSP)
インターネットX.509公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
このドキュメントはTime Stamping Authority(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はTrusted Thirdパーティ(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]は指定された回の前にデータの存在を確立する能力を必要とします。 このプロトコルは、そのようなサービスを支持するのにブロックとして使用されるかもしれません。 デジタル署名が公開鍵証明書の有効期間の間発生したとどう立証するかに関する例は別館で出されます。
Adams, et al. Standards Track [Page 1] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[1ページ]。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」、“SHALL"であるべきである(中[RFC2119]の解釈されて、このドキュメント(示されるとしての大文字の)には説明されるとしてある「お勧め」の、そして、「5月」の、そして、「任意」のコネ)
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.
時間内に特定のポイントにデータを関連づけるために、Time Stamp Authority(TSA)は、使用される必要があるかもしれません。 このTrusted Thirdパーティは時間内に、瞬間に「存在の証拠」をこの特定のデータに提供します。
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規格がまさしくカリフォルニアの操作のためのそのような要件を確立しないように。 むしろ、TSAがそれが正確なタイムスタンプ世代を確実にするために実施する政策を将来のクライアントに明らかにすると予期されて、それらがこれらの方針が彼らの需要を満たすのが満たされている場合にだけ、クライアントはTSAのサービスを利用するでしょう。
2. The TSA
2. TSA
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はREQUIREDです:
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. 新たにそれぞれのためのユニークな整数を含んでいるのはタイムスタンプ象徴を発生させました。
Adams, et al. Standards Track [Page 2] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[2ページ]。
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. タイムスタンプ象徴に追加情報を含むように、リクエスタによって拡大にだけ拡大分野を使用することで尋ねられるなら、それはTSAによって支持されます。 これが可能でないなら、TSA SHALLはエラーメッセージで応じます。
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を含んでいる)をTime Stamping Authorityに送ることによって、タイムスタンプ象徴を要求します。 2番目のメッセージとして、Time Stamping Authorityは、応答(以下で定義されるようにあるか、またはTimeStampRespを含んでいる)を要求実体に送ることによって、応じます。
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
応答(どれがあるか、またはそんなに通常、TimeStampRespを含んでいるかが以下で定義されるようにTimeStampToken(TST)を含んでいる)を受けると、要求実体SHALLは応答で返された状態誤りについて確かめます、そして、どんな誤りもそれを提示することでないなら、SHALLはTimeStampTokenに含まれた多岐とTimeStampTokenのデジタル署名の正当性について確かめます。 特にそれ、SHALLは、時間によって押し込まれたことが時間によって押し込まれてください要求されたことに対応することを確かめます。 SHALLが確かめるTimeStampTokenが正しい証明書識別子を含むリクエスタ
Adams, et al. Standards Track [Page 3] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[3ページ]。
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。 それ、そして、要求に値を含んでいることに対してSHALLは、1つが利用可能であるなら応答でローカルの信じられた時間参照に対して含められているか、または応答で一回だけ(クライアントによって一度だけ発生するという高い確率がある大きい乱数)の値を含めて、時間について確かめることによって、応答のタイムリーさであるのについて確かめます。 反射攻撃検出に関するその他の詳細に関しては、セキュリティ問題部(項目6)を見てください。 やり損ない、TimeStampToken SHALLの上の検証のいずれでもある、拒絶されてください。
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の証明書がそうするかもしれないので、取り消されてください、そうした、証明書SHOULDの状態。証明書がまだ有効であることを確かめるのがチェックされてください(例えば、適切な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.
そして、クライアントアプリケーションSHOULDは、アプリケーションにおいて、象徴が発行された方針が許容できるかどうか決定するために方針分野をチェックします。
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 MUSTは明確にそのために予約されたキーでそれぞれのタイムスタンプメッセージに署名します。 TSA MAYには、例えば異なった方針、異なったアルゴリズム、異なった秘密鍵サイズを収容するか、または性能を向上させるように、異なった秘密鍵があります。 対応する証明書はKeyPurposeID有がある.13が評価する[RFC2459]セクション4.2.1で定義されるように拡張主要な用法分野拡大の1つの例だけを含まなければなりません:
id-kp-timeStamping. This extension MUST be critical.
イド-kp-timeStamping。 この拡大は批判的であるに違いありません。
The following object identifier identifies the KeyPurposeID having value id-kp-timeStamping.
以下の物の識別子は値のイド-kp-timeStampingを持っている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)}
イド-kp-timeStamping物の識別子:、:= (8)をtimestampingするiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7) kp(3)
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、バージョンINTEGER v1(1)、messageImprint MessageImprint--、aは論じ尽くすためにデータのアルゴリズムOIDとハッシュ値を論じ尽くします。
Adams, et al. Standards Track [Page 4] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[4ページ]。
--time-stamped
reqPolicy TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL }
--時間で押し込まれたreqPolicy TSAPolicyId OPTIONAL、一回だけのINTEGER OPTIONAL、certReq BOOLEAN DEFAULT FALSE、拡大[0]IMPLICIT Extensions OPTIONAL
The version field (currently v1) describes the version of the Time- Stamp request.
バージョン分野(現在のv1)はTimeスタンプ要求のバージョンについて説明します。
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分野SHOULDは時間によって押し込まれるべきデータの細切れ肉料理を含んでいます。 細切れ肉料理はOCTET STRINGとして表されます。 長さはそのアルゴリズム(例えば、SHA-1のための20バイトかMD5のための16バイト)のためのハッシュ値の長さに合わなければなりません。
MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }
MessageImprint:、:= 系列hashAlgorithm AlgorithmIdentifier、hashedMessage八重奏ストリング
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分野SHOULDで知られている細切れ肉料理アルゴリズム(片道と耐衝突の)であるように示しました。 それがそれを意味する、それ、SHOULD、片道であって衝突抵抗力があってください。 Time Stamp Authority SHOULDは、与えられた細切れ肉料理アルゴリズムが「十分であること」が(暗号文解読術による知識の現状とコンピュータのリソースの芸術の現状に基づいて例えば)知られているかどうかチェックします。 TSAが、細切れ肉料理アルゴリズムを認めないか、または細切れ肉料理アルゴリズムが弱いのを知っているなら(決定はそれぞれの個々のTSAにいなくなりました)、TSA SHOULDは、'悪い_alg'のpkiStatusInfoを返すことによってタイムスタンプ象徴を提供するのを拒否します。
The reqPolicy field, if included, indicates the TSA policy under which the TimeStampToken SHOULD be provided. TSAPolicyId is defined as follows:
含まれているならreqPolicy分野がTSA方針を示す、どれ、TimeStampToken SHOULD、提供してくださいか。 TSAPolicyIdは以下の通り定義されます:
TSAPolicyId ::= OBJECT IDENTIFIER
TSAPolicyId:、:= 物の識別子
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.
どんな地方の時計も利用可能でないときに、一回だけで、含まれているなら、クライアントは応答のタイムリーさであるのについて確かめることができます。 一回だけはクライアントがそれを一度だけ発生させるという高い確率(例えば、64ビットの整数)がある大きい乱数です。 応答にこのような場合には同じ一回だけの値を含まなければなりません。さもなければ、応答は拒絶されるものとします。
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分野が存在していて、本当に設定されるなら、証明書分野のTSAはESSCertID識別子で応答におけるSigningCertificate属性で参照をつけられるTSAの公開鍵証明書をSignedData構造からその応答に提供しなければなりません。 また、その分野は他の証明書を含むかもしれません。
Adams, et al. Standards Track [Page 5] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[5ページ]。
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分野が存在しているか、そして、セットであるなら、SignedData構造からの証明書分野は応答で存在しているはずがありません。
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).
拡大分野は将来追加情報を要求に追加する一般的な方法です。 拡大は[RFC2459]で定義されます。 拡大がそれが批判的であるか、または批判的でないとマークされるか否かに関係なく、リクエスタによって使用されますが、時間の刻印サーバによって認識されないなら、サーバSHALLは象徴を発行しません、そして、SHALLは失敗(unacceptedExtension)を返します。
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:、:= 系列状態PKIStatusInfo、timeStampToken TimeStampToken OPTIONAL
The status is based on the definition of status in section 3.2.3 of [RFC2510] as follows:
状態は以下の.3セクション3.2[RFC2510]との状態の定義に基づいています:
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }
PKIStatusInfo:、:= 系列状態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:
状態が値ゼロか1を含むとき、TimeStampTokenは存在していなければなりません。 状態がゼロか1以外の値を含むとき、TimeStampTokenは存在しているはずがありません。 状態に以下の値の1つを含まなければなりません:
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:、:= PKIStatusが値1を含んでいると、値はTimeStampTokenのゼロに合って、要求された通り、プレゼントgrantedWithModsは(1)です。INTEGER、PKIStatusであるときに、(0)を与える、含有、TimeStampTokenはプレゼント拒絶(2)、変更がある待ち(3)です、revocationWarning(4)
Adams, et al. Standards Track [Page 6] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[6ページ]。
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5)
-- notification that a revocation has occurred }
-- このメッセージは取消しがそうであるという警告--差し迫っているrevocationNotification(5)--取消しが起こったという通知を含んでいます。
Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present.
言いなりになっているサーバSHOULD NOTはいかなる他の値も生産します。 それが理解していない値が存在しているなら、言いなりになっているクライアントはエラーを起こさなければなりません。
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.
TimeStampTokenが存在していないとき、failInfoはタイムスタンプ要求が拒絶されて、以下の値の1つであるかもしれない理由を示します。
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:、:= ビット列{ badAlg(0)--取引がbadDataFormat(5)を可能にもしませんでしたし、支持もしなかったというデータが提出した認識されていないかサポートされないAlgorithm Identifier badRequest(2)は間違った形式timeNotAvailable(14)を持っています--TSAの時間ソースは利用可能なunacceptedPolicy(15)ではありません; 要求されたTSA方針はTSA unacceptedExtension(16)によって支持されません--要求された拡張子は、TSA addInfoNotAvailable(17)(理解できません追加情報が、要求した)によって支持されないか、利用可能なsystemFailure(25)ではありません--システム障害のため要求を扱うことができません; }
These are the only values of PKIFailureInfo that SHALL be supported.
これらはPKIFailureInfoの唯一の値です。SHALLは支持されます。
Compliant servers SHOULD NOT produce any other values. Compliant clients MUST generate an error if values it does not understand are present.
言いなりになっているサーバSHOULD NOTはいかなる他の値も生産します。 それが理解していない値が存在しているなら、言いなりになっているクライアントはエラーを起こさなければなりません。
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.
TimeStampTokenは以下の通りです。 それはContentInfo([CMS])と定義されます、そして、SHALLはデータのサインされた内容タイプを要約します。
TimeStampToken ::= ContentInfo
-- contentType is id-signedData ([CMS])
-- content is SignedData ([CMS])
TimeStampToken:、:= ContentInfo--contentTypeはイド-signedData([CMS])です--内容はSignedDataです。([cm])
Adams, et al. Standards Track [Page 7] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[7ページ]。
The fields of type EncapsulatedContentInfo of the SignedData construct have the following meanings:
SignedData構造物のタイプEncapsulatedContentInfoの分野には、以下の意味があります:
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}
イドct TSTInfo、物の識別子:、:= iso(1)は(2) 私たち(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 SHALLはDERにコード化です。TSTInfoの値。
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の署名以外のどんな署名も含んではいけません。 signerInfo属性としてSigningCertificate属性でTSA証明書に関する証明書識別子(ESSCertID)を含まなければなりません。
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:、:= 系列{ バージョンINTEGER v1(1)、方針TSAPolicyId、messageImprint MessageImprint--時間を押し込む--TimeStampReq serialNumber INTEGER--ユーザに同様の分野と同じ値を持たなければならないのは整数を収容する準備ができているに違いありません; genTime GeneralizedTime、精度Accuracy OPTIONAL、BOOLEAN DEFAULT FALSEを注文して、一回だけのINTEGER OPTIONAL--同様の分野であるなら存在していなければならないのはTimeStampReqに存在していました。最大160ビットその場合、同じ値tsa0GeneralName OPTIONALを持たなければなりません、拡大1IMPLICIT 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.
任意の分野の中では、一回だけの分野だけを支持しなければなりません。
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がすべての任意の分野が存在している象徴を時押し込みますが、どんな拡大の意味論も理解するために強制されないと認めることができて、存在していなければなりません。
Adams, et al. Standards Track [Page 8] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[8ページ]。
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はタイムスケールです、2番目の(SI)に基づいて、CCIRによって定義されて、推薦されて、国際度量衡局(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.1GeneralizedTime構文は2番目の部分の詳細を含むことができます。 そのような構文、[RFC2459]セクション4.1.2.5からの制限がなければ、.2はここでGeneralizedTimeが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値は秒を含まなければなりません。 しかしながら、いつに、精度が2分の1つのSHOULDに制限されている2番目、当時のGeneralizedTimeより良い精度を使用させる必要は全くありませんか?([RFC2459]のように)
The syntax is: YYYYMMDDhhmmss[.s...]Z Example: 19990609001326.34352Z
構文は以下の通りです。 YYYYMMDDhhmmss[. s.]Zの例: 19990609001326.34352 Z
X.690 | ISO/IEC 8825-1 provides the following restrictions for a DER-encoding.
X.690| ISO/IEC8825-1はDER-コード化に以下の制限を提供します。
Adams, et al. Standards Track [Page 9] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[9ページ]。
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.
(グリニッジ標準時)の真夜中はフォームに表されるものとします: "YYYYMMDD"が問題の真夜中に続く1日を表す"YYYYMMDD000000Z"。
Here are a few examples of valid representations:
ここに、有効な表現に関するいくつかの例があります:
"19920521000000Z"
"19920622123421Z"
"19920722132100.3Z"
"19920521000000Z""19920622123421Z""19920722132100.3Z"
accuracy represents the time deviation around the UTC time contained in GeneralizedTime.
精度はGeneralizedTimeに含まれたUTC時頃に時間逸脱を表します。
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL,
millis [0] INTEGER (1..999) OPTIONAL,
micros [1] INTEGER (1..999) OPTIONAL }
精度:、:= 系列秒INTEGER OPTIONAL、ミリ[0]INTEGER(1 .999)OPTIONAL、ミクロ[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.
精度価値をGeneralizedTimeに高めることによって、タイムスタンプ象徴がTSAによって作成された時の上限を得ることができます。 同様に、GeneralizedTimeに精度を引き算することによって、タイムスタンプ象徴が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.
注文分野が取り逃がすこと、注文分野が存在しているか、そして、または誤っていることへのセットであるなら、genTime分野はタイムスタンプ象徴がTSAによって作成された時を示すだけです。 最初のタイムスタンプ象徴のgenTimeと2番目のタイムスタンプ象徴のgenTimeの違いがgenTimeの精度の合計よりそれぞれのタイムスタンプ象徴にすばらしいときにだけ、このような場合には、同じTSAか異なったTSAsによって発行されたタイムスタンプ象徴の注文は可能です。
Adams, et al. Standards Track [Page 10] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[10ページ]。
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.
注文分野を存在していて、本当に設定するなら、genTimeフィールドに基づくように同じTSAからのあらゆるタイムスタンプ象徴をいつも注文できます、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.
それがTimeStampReqに存在していたなら、一回だけの分野は存在していなければなりません。 このような場合にはそれは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という名前を特定する際にちょっとほのめかすことです。 存在しているなら、象徴について確かめるのに使用されることになっている証明書に名前を含んでいる場合、それは対象の1つに対応しなければなりません。 しかしながら、応答にサインした実体の実際の識別はsignerInfoの一部であるSigningCertificate属性で証明書識別子(ESSCertID Attribute)の使用でいつも起こるでしょう([ESS]のセクション5を見てください)。
extensions is a generic way to add additional information in the future. Extensions is defined in [RFC 2459].
拡大は将来追加情報を加える一般的な方法です。 拡大は[RFC2459]で定義されます。
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.
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.
Two MIME objects are specified as follows:
Two MIME objects are specified as follows:
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.
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.
Adams, et al. Standards Track [Page 11] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 11] RFC 3161 Time-Stamp Protocol (TSP) August 2001
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:
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 Type File Extension
application/timestamp-query .TSQ
application/timestamp-reply .TSR
MIME Type File Extension 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.
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. File Based Protocol
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.
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.
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).
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).
3.3. Socket Based Protocol
3.3. Socket Based Protocol
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.
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.
The protocol basically assumes a listener process on a TSA that can accept TSA messages on a well-defined port (IP port number 318).
The protocol basically assumes a listener process on a TSA that can accept TSA messages on a well-defined port (IP port number 318).
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.
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.
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.
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.
When the final TSA response message has been picked up by the initiator then no new polling reference is supplied.
When the final TSA response message has been picked up by the initiator then no new polling reference is supplied.
Adams, et al. Standards Track [Page 12] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 12] RFC 3161 Time-Stamp Protocol (TSP) August 2001
The initiator of a transaction sends a "direct TCP-based TSA message" to the recipient. The recipient responds with a similar message.
The initiator of a transaction sends a "direct TCP-based TSA message" to the recipient. The recipient responds with a similar message.
A "direct TCP-based TSA message" consists of:
length (32-bits), flag (8-bits), value (defined below)
A "direct TCP-based TSA message" consists of: length (32-bits), flag (8-bits), value (defined below)
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.
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.
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:
The sequence of messages that can occur is:
a) entity sends tsaMsg and receives one of pollRep, negPollRep,
partialMsgRep, or finalMsgRep in response.
a) entity sends tsaMsg and receives one of pollRep, negPollRep, partialMsgRep, or finalMsgRep in response.
b) end entity sends pollReq message and receives one of
negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep in
response.
b) end entity sends pollReq message and receives one of negPollRep, partialMsgRep, finalMsgRep, or errorMsgRep in response.
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.
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.
It provides an estimate of the time that the end entity should send its next pollReq.
It provides an estimate of the time that the end entity should send its next pollReq.
Adams, et al. Standards Track [Page 13] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 13] RFC 3161 Time-Stamp Protocol (TSP) August 2001
3.4. Time-Stamp Protocol via HTTP
3.4. Time-Stamp Protocol via 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.
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.
Two MIME objects are specified as follows.
Two MIME objects are specified as follows.
Content-Type: application/timestamp-query
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
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.
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.
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.
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.
4. Security Considerations
4. Security Considerations
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.
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.
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. 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.
Adams, et al. Standards Track [Page 14] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 14] RFC 3161 Time-Stamp Protocol (TSP) August 2001
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. 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.
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. 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.
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. 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.
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. 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.
Adams, et al. Standards Track [Page 15] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 15] RFC 3161 Time-Stamp Protocol (TSP) August 2001
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. 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.
5. Intellectual Property Rights
5. Intellectual Property Rights
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.
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.
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.
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.
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
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
Adams, et al. Standards Track [Page 16] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 16] RFC 3161 Time-Stamp Protocol (TSP) August 2001
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).
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).
Implementers of this protocol SHOULD perform their own patent search and determine whether or not any encumbrances exist on their implementation.
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.
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
# 5,001,752 Public/Key Date-Time Notary Facility Filing date: October 13, 1989 Issued: March 19, 1991 Inventor: Addison M. Fischer
# 5,022,080 Electronic Notary Filing date: April 16, 1989 Issued: June 4, 1991 Inventors: Robert T. Durst, Kevin D. Hunter
# 5,022,080 Electronic Notary Filing date: April 16, 1989 Issued: June 4, 1991 Inventors: Robert T. Durst, Kevin D. Hunter
# 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.)
# 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.)
# 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.,
# 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.,
# 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.,
# 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.,
# 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.,
# 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.,
Adams, et al. Standards Track [Page 17] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 17] RFC 3161 Time-Stamp Protocol (TSP) August 2001
# 5,422,953 Personal Date/Time Notary Device Filing date: May 5, 1993 Issued: June 6, 1995 Inventor: Addison M. Fischer
# 5,422,953 Personal Date/Time Notary Device Filing date: May 5, 1993 Issued: June 6, 1995 Inventor: 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.,
# 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.,
6. References
6. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure, Certificate Management Protocols", RFC
2510, March 1999.
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 2510, March 1999.
[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. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[DSS] Digital Signature Standard. FIPS Pub 186. National
Institute of Standards and Technology. 19 May 1994.
[DSS] Digital Signature Standard. FIPS Pub 186. National Institute of Standards and Technology. 19 May 1994.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
2634, June 1999.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework. April 1997.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute
of Standards and Technology. 17 April 1995.
[SHA1] Secure Hash Standard. FIPS Pub 180-1. National Institute of Standards and Technology. 17 April 1995.
Adams, et al. Standards Track [Page 18] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 18] RFC 3161 Time-Stamp Protocol (TSP) August 2001
7. Authors' Addresses
7. Authors' Addresses
Carlisle Adams Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 CANADA
Carlisle Adams Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 CANADA
EMail: cadams@entrust.com
EMail: cadams@entrust.com
Pat Cain BBN 70 Fawcett Street Cambridge, MA 02138 U.S.A.
Pat Cain BBN 70 Fawcett Street Cambridge, MA 02138 U.S.A.
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 FRANCE
EMail: Denis.Pinkas@bull.net
EMail: Denis.Pinkas@bull.net
Robert Zuccherato Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 CANADA
Robert Zuccherato Entrust, Inc. 1000 Innovation Drive Ottawa, Ontario K2K 3E7 CANADA
EMail: robert.zuccherato@entrust.com
EMail: robert.zuccherato@entrust.com
Adams, et al. Standards Track [Page 19] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 19] RFC 3161 Time-Stamp Protocol (TSP) August 2001
APPENDIX A - Signature Time-stamp attribute using CMS
APPENDIX A - Signature Time-stamp attribute using 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.
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.
A sensible place to store a time-stamp is in a [CMS] structure as an unsigned attribute.
This appendix defines a Signature Time-stamp attribute that may be used to time-stamp a digital signature.
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:
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:
The Signature time-stamp attribute value has ASN.1 type 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.
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.
APPENDIX B - Placing a Signature At a Particular Point in Time
APPENDIX B - Placing a Signature At a Particular Point in Time
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.
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.
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.
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:
To verify a digital signature, the following basic technique may be used:
Adams, et al. Standards Track [Page 20] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 20] RFC 3161 Time-Stamp Protocol (TSP) August 2001
A) Time-stamping information needs to be obtained soon after the
signature has been produced (e.g., within a few minutes or hours).
A) Time-stamping information needs to be obtained soon after the signature has been produced (e.g., within a few minutes or hours).
1) The signature is presented to the Time Stamping Authority
(TSA). The TSA then returns a TimeStampToken (TST) upon
that signature.
1) The signature is presented to the Time Stamping Authority (TSA). The TSA then returns a TimeStampToken (TST) upon that signature.
2) The invoker of the service MUST then verify that the
TimeStampToken is correct.
2) The invoker of the service MUST then verify that the TimeStampToken is correct.
B) The validity of the digital signature may then be verified in the
following way:
B) The validity of the digital signature may then be verified in the following way:
1) The time-stamp token itself MUST be verified and it MUST be
verified that it applies to the signature of the signer.
1) The time-stamp token itself MUST be verified and it MUST be verified that it applies to the signature of the signer.
2) The date/time indicated by the TSA in the TimeStampToken
MUST be retrieved.
2) The date/time indicated by the TSA in the TimeStampToken MUST be retrieved.
3) The certificate used by the signer MUST be identified and
retrieved.
3) The certificate used by the signer MUST be identified and retrieved.
4) The date/time indicated by the TSA MUST be within the
validity period of the signer's certificate.
4) The date/time indicated by the TSA MUST be within the validity period of the signer's certificate.
5) The revocation information about that certificate, at the
date/time of the Time-Stamping operation, MUST be retrieved.
5) The revocation information about that certificate, at the date/time of the Time-Stamping operation, MUST be retrieved.
6) Should the certificate be revoked, then the date/time of
revocation shall be later than the date/time indicated by
the TSA.
6) Should the certificate be revoked, then the date/time of revocation shall be later than the date/time indicated by the TSA.
If all these conditions are successful, then the digital signature shall be declared as valid.
If all these conditions are successful, then the digital signature shall be declared as valid.
APPENDIX C: ASN.1 Module using 1988 Syntax
APPENDIX C: ASN.1 Module using 1988 Syntax
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
BEGIN
-- EXPORTS ALL --
-- EXPORTS ALL --
IMPORTS
IMPORTS
Adams, et al. Standards Track [Page 21] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 21] RFC 3161 Time-Stamp Protocol (TSP) August 2001
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 --
-- Locally defined OIDs --
-- eContentType for a time-stamp token
-- eContentType for a time-stamp token
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 }
Adams, et al. Standards Track [Page 22] RFC 3161 Time-Stamp Protocol (TSP) August 2001
Adams, et al. Standards Track [Page 22] RFC 3161 Time-Stamp Protocol (TSP) August 2001
-- 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:、:= ビット列{ badAlg(0)--取引がbadDataFormat(5)を可能にもしませんでしたし、支持もしなかったというデータが提出した認識されていないかサポートされないAlgorithm Identifier badRequest(2)は間違った形式timeNotAvailable(14)を持っています--TSAの時間ソースは利用可能なunacceptedPolicy(15)ではありません; 要求されたTSA方針はTSA. unacceptedExtension(16)によって支持されません--要求された拡張子は、TSA. addInfoNotAvailable(17)(理解できません追加情報が、要求した)によって支持されないか、利用可能なsystemFailure(25)ではありません--システム障害のため要求を扱うことができません; }
TimeStampToken ::= ContentInfo
TimeStampToken:、:= ContentInfo
Adams, et al. Standards Track [Page 23] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[23ページ]。
-- 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は[CMS]で定義されるようにイド-signedDataです--内容は([CMS])で定義されるようにSignedDataです--SignedDataの中のeContentTypeがそうである、イドct TSTInfo、--SignedDataの中のeContentが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:、:= 系列{ バージョンINTEGER v1(1)、方針TSAPolicyId、messageImprint MessageImprint--時間を押し込む--TimeStampReq serialNumber INTEGER--ユーザに同様の分野と同じ値を持たなければならないのは整数を収容する準備ができているに違いありません; genTime GeneralizedTime、精度Accuracy OPTIONAL、BOOLEAN DEFAULT FALSEを注文して、一回だけのINTEGER OPTIONAL--同様の分野であるなら存在していなければならないのはTimeStampReqに存在していました。最大160ビットその場合、同じ値tsa0GeneralName OPTIONALを持たなければなりません、拡大1IMPLICIT Extensions OPTIONAL; }
Accuracy ::= SEQUENCE {
seconds INTEGER OPTIONAL,
millis [0] INTEGER (1..999) OPTIONAL,
micros [1] INTEGER (1..999) OPTIONAL }
精度:、:= 系列秒INTEGER OPTIONAL、ミリ[0]INTEGER(1 .999)OPTIONAL、ミクロ[1]INTEGER(1 .999)OPTIONAL
END
終わり
APPENDIX D: Access descriptors for Time-Stamping.
付録D: Time押し込む記述子にアクセスしてください。
[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.]
この別館は「RFC2459の息子」で定義されるSIA拡張子に基づく拡大について説明します。「RFC2459の息子」がこのドキュメントの公表時点でまだ利用可能でないので、記述は有益な別館に置かれます。この別館のコンテンツは結局、息子に法人組織になるでしょう。-これがどの時間を付加するかでRFC2459ドキュメントについて、もう必要でないでしょう。[このドキュメントの将来のバージョンは、おそらくこの別館を省略して、直接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の証明書は、TSAに連絡する方法を伝えるために、Subject情報Access(SIA)拡張子(RFC2459の息子)を含むかもしれません。 この拡大におけるaccessMethod分野はOIDイド広告timestampingを含まなければなりません:
The following object identifier identifies the access descriptors for time-Stamping.
以下の物の識別子は時間押し込むアクセス記述子を特定します。
Adams, et al. Standards Track [Page 24] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[24ページ]。
id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
ad (48) timestamping (3)}
イド広告timeStamping、物の識別子:、:= (3)をtimestampingするiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)広告(48)
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)を含むかもしれません。
Adams, et al. Standards Track [Page 25] RFC 3161 Time-Stamp Protocol (TSP) August 2001
アダムス、他 規格は2001年8月にRFC3161タイムスタンププロトコル(ティースプーンフル)を追跡します[25ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Adams, et al. Standards Track [Page 26]
アダムス、他 標準化過程[26ページ]
一覧
スポンサーリンク
