[要約] RFC 5544は、ドキュメントにタイムスタンプを付けるための構文を定義しています。このRFCの目的は、ドキュメントの信頼性と完全性を確保するために、タイムスタンプを使用する方法を提供することです。
Independent Submission A. Santoni
Request for Comments: 5544 Actalis S.p.A.
Category: Informational February 2010
ISSN: 2070-1721
Syntax for Binding Documents with Time-Stamps
タイムスタンプを使用したバインディングドキュメントの構文
Abstract
概要
This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time-stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed.
このドキュメントでは、「タイムスタンプトークン」がRFC 3161で定義されている意味をそのファイルに対して取得した1つまたは複数のタイムスタンプトークンを使用して、ファイル（必ずしも暗号化技術によって保護されているわけではありません）をバインドするために使用できるエンベロープについて説明します。またはその後継者。追加の種類の時間的証拠も許可されています。
The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652.
提案されているエンベロープは、RFC 5652で定義されている暗号化メッセージの構文に基づいています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5544.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5544で取得できます。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. The standards track specification RFC 4998, Evidence Record Syntax (ERS), specifies an alternative mechanism. Readers are encouraged to also review RFC 4998 when evaluating the suitability of this mechanism.
このRFCは、インターネット標準のレベルの候補者ではありません。標準は、仕様RFC 4998、証拠記録構文（ERS）を追跡し、代替メカニズムを指定します。読者は、このメカニズムの適合性を評価する際にもRFC 4998をレビューすることをお勧めします。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http：trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Syntax for TimeStampedData ......................................3
3. Compliance Requirements .........................................6
4. Recommended Processing ..........................................6
4.1. Generating a New TimeStampedData Structure .................7
4.2. Verifying an Existing TimeStampedData Structure ............8
4.3. Extending the Validity of an Existing
TimeStampedData Structure ..................................9
5. Security Considerations .........................................9
6. Normative References ...........................................10
7. Informative References .........................................10
Appendix A. ASN.1 Module ..........................................11
Appendix B. Acknowledgments .......................................12
Time-stamping has become the standard technique for proving the existence of a document before a certain point in time. Several legislations around the world embrace the concept and provide for time-stamping services, mainly for the purpose of extending the validity of signed documents. However, while time-stamping enhances digital signatures, its value does not depend on them. It can clearly be useful to time-stamp a document even if it is not signed. And it can also be useful, or even mandatory in some cases, to time-stamp a signed document in its entirety, regardless of how many signatures it contains.
タイムスタンピングは、特定の時点でドキュメントの存在を証明するための標準的な手法となっています。世界中のいくつかの法律は、主に署名されたドキュメントの有効性を拡張する目的で、概念を採用し、タイムスタンプサービスを提供します。ただし、タイムスタンプはデジタル署名を強化しますが、その価値はそれらに依存しません。ドキュメントが署名されていなくても、ドキュメントをタイムスタンプすることは明らかに役立ちます。また、含まれる署名の数に関係なく、署名されたドキュメント全体をタイムスタンプするために、それは有用であるか、場合によっては必須です。
When a time-stamp is related to a digital signature, there already exists a way to keep the two pieces together: RFC 3161 [TSP] describes how one or more TimeStampTokens can be included in a SignerInfo structure as unsigned attributes. On the other hand, there is no standard way to keep together a time-stamped document, whether signed or not, and the related time-stamps.
タイムスタンプがデジタル署名に関連している場合、2つのピースを一緒に保つ方法がすでに存在しています。RFC3161[TSP]は、1つ以上のタイムスタンプケンを署名のない属性としてSignerINFO構造にどのように含めることができるかを説明しています。一方、署名であろうとなかろうと、関連するタイムスタンプを維持するための標準的な方法はありません。
In such cases, two approaches are typically being adopted:
そのような場合、通常、2つのアプローチが採用されています。
o time-stamps are kept as separate files (keeping track of what time-stamps belong to what documents is up to the user);
o タイムスタンプは、個別のファイルとして保持されます（どのタイムスタンプがユーザー次第であるかに属するタイムスタンプを追跡します）。
o an ad hoc solution is adopted for specific applications, e.g., a ZIP archive or a proprietary "envelope" of some kind.
o アドホックソリューションは、特定のアプリケーションに採用されています。たとえば、ZIPアーカイブまたはある種の独自の「エンベロープ」です。
Both solutions impede interoperability, which is the objective of this memo.
どちらのソリューションも相互運用性を妨げます。これはこのメモの目的です。
This document describes a simple syntax for binding one document (actually, any kind of file) to the corresponding temporal evidence; the latter is typically represented by one or more RFC 3161 TimeStampTokens. Additional types of temporal evidence, e.g., an RFC 4998 EvidenceRecord [ERS], are also supported via an "open" syntax. However, for the sake of interoperability, the emphasis in this document is on TimeStampTokens.
このドキュメントでは、対応する時間的証拠に1つのドキュメント（実際には、あらゆる種類のファイル）をバインドするための単純な構文について説明しています。後者は通常、1つ以上のRFC 3161タイムスタンプケンで表されます。追加の種類の時間的証拠、例えば、RFC 4998 evidencerecord [ers]も、「開いた」構文を介してサポートされています。ただし、相互運用性のために、このドキュメントの重点はTimestamptokensにあります。
The proposed syntax is broadly based on the Cryptographic Message Syntax (CMS) defined in RFC 5652 [CMS].
提案された構文は、RFC 5652 [CMS]で定義されている暗号化メッセージ構文（CMS）に大きく基づいています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [kWords]に記載されているとおりに解釈されます。
The terms "document" and "file" are used interchangeably. The terms "TimeStampToken" and "time-stamp token" are used interchangeably, both referring to the data structure defined in RFC 3161.
「ドキュメント」と「ファイル」という用語は、交換可能に使用されます。「タイムスタンプキン」と「タイムスタンプトークン」という用語は、RFC 3161で定義されているデータ構造を指すと同じ意味で使用されます。
The proposed data structure is called TimeStampedData, and it is based on the ContentInfo envelope defined in [CMS]:
提案されたデータ構造はTimestampedDataと呼ばれ、[CMS]で定義されているContentInfoエンベロープに基づいています。
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
While CMS defines six content types (data, signed-data, enveloped-data, digested-data, encrypted-data, and authenticated-data), this memo defines an additional content type, timestamped-data, identified by the following Object Identifier (OID):
CMSでは、6つのコンテンツタイプ（署名されたデータ、包括的なデータ、消化データ、暗号化されたデータ、および認証されたデータ）を定義しますが、このメモは、次のオブジェクト識別子によって識別される追加のコンテンツタイプであるタイムスタンプ付きDATAを定義します（oid）：
id-ct-timestampedData OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) id-smime(16) id-ct(1) 31 }
This particular OID signals that the content field of the ContentInfo has the following syntax:
この特定のOIDは、ContentInfoのコンテンツフィールドに次の構文があることを示しています。
TimeStampedData ::= SEQUENCE {
version INTEGER { v1(1) },
dataUri IA5String OPTIONAL,
metaData MetaData OPTIONAL,
content OCTET STRING OPTIONAL,
temporalEvidence Evidence
}
MetaData ::= SEQUENCE {
hashProtected BOOLEAN,
fileName UTF8String OPTIONAL,
mediaType IA5String OPTIONAL,
otherMetaData Attributes OPTIONAL
}
Attributes ::=
SET SIZE(1..MAX) OF Attribute -- according to RFC 5652
Evidence ::= CHOICE {
tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161
ersEvidence [1] EvidenceRecord, -- see RFC 4998
otherEvidence [2] OtherEvidence
}
OtherEvidence ::= SEQUENCE {
oeType OBJECT IDENTIFIER,
oeValue ANY DEFINED BY oeType }
TimeStampTokenEvidence ::=
SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL
TimeStampAndCRL ::= SEQUENCE {
timeStamp TimeStampToken, -- according to RFC 3161
crl CertificateList OPTIONAL -- according to RFC 5280
}
The version field contains the version number of the TimeStampedData syntax. It SHALL be 1 for this version of the document.
バージョンフィールドには、タイムスタンペドダタ構文のバージョン番号が含まれています。ドキュメントのこのバージョンの場合は1になります。
The dataUri field contains a URI reference conforming to [URI]. When the content field is absent, dataUri MUST be present and contain a URI allowing retrieval of the document that was time-stamped (unless the document is later moved). When the content field is present, this field MAY also be present.
Datauriフィールドには、[uri]に準拠したURI参照が含まれています。コンテンツフィールドが存在しない場合、datauriが存在し、URIが含まれている必要があります。コンテンツフィールドが存在する場合、このフィールドが存在する場合があります。
The metaData field contains metadata related to the document that was time-stamped, if applicable. In particular:
メタデータフィールドには、該当する場合、タイムスタンプされたドキュメントに関連するメタデータが含まれています。特に：
The hashProtected field indicates whether the metadata have been included in the computation of the digest within the first TimeStampToken (see further on). This makes it possible to detect a subsequent alteration of the metadata.
ハッシュ保護されたフィールドは、メタデータが最初のTimestamptoken内のダイジェストの計算に含まれているかどうかを示します（詳細を参照）。これにより、メタデータのその後の変化を検出できます。
The fileName field contains the original filename of the document that was time-stamped.
Filenameフィールドには、タイムスタンプされたドキュメントの元のファイル名が含まれています。
The mediaType field contains a media type/subtype and possible parameters for the time-stamped document, according to [MIME]. This information may help decide how to "open" or deal with the time-stamped document.
MediATypeフィールドには、[MIME]によると、時間刻印されたドキュメントのメディアタイプ/サブタイプと可能なパラメーターが含まれています。この情報は、タイムスタンプされたドキュメントを「開く」または取引する方法を決定するのに役立ちます。
The otherMetaData field contains further attributes of the time-stamped document (e.g., a description, claimed author, etc.), where each attribute is specified by an object identifier and a corresponding set of values, as described in [CMS]. When this field is present, it MUST contain at least one Attribute.
その他のメタダタフィールドには、[CMS]で説明されているように、各属性はオブジェクト識別子と対応する値のセットによって指定されます。このフィールドが存在する場合、少なくとも1つの属性を含める必要があります。
Within the metaData field (if present), at least one of the fileName, mediaType, and otherMetaData sub-fields MUST be present.
メタデータフィールド内（存在する場合）内には、ファイル名、mediatype、およびothermetadataサブフィールドの少なくとも1つが存在する必要があります。
The Attribute values within the otherMetaData field MUST be DER encoded, even if the rest of the structure is BER encoded.
構造の残りの部分がエンコードされていても、他のメタダタフィールド内の属性値をderエンコードする必要があります。
The content field, when present, carries the entire contents, in its original format and encoding, of the document that was time-stamped. This can actually be any kind of data, e.g., a text document, an executable, a movie, a message, etc. The omission of the content field makes it possible to bind the temporal evidence to external data. In such a case, the temporal evidence is computed as though the content field were present.
コンテンツフィールドは、存在するときに、タイムスタンプされたドキュメントのコンテンツ全体を元の形式とエンコードで運びます。これは、実際には、テキストドキュメント、実行可能ファイル、映画、メッセージなど、あらゆる種類のデータである可能性があります。コンテンツフィールドの省略により、一時的な証拠を外部データに結合することができます。そのような場合、一時的な証拠は、コンテンツフィールドが存在するかのように計算されます。
The temporalEvidence field carries the evidence that the time-stamped document did exist before a certain point in time. Several types of evidence are allowed, but compliant applications are only required to support the RFC 3161 type -- namely, the tstEvidence choice.
一時的なフィールドには、特定の時点でタイムスタンプされた文書が存在したという証拠があります。いくつかのタイプの証拠が許可されていますが、RFC 3161タイプ、つまりTStevidenceの選択をサポートするには準拠したアプリケーションのみが必要です。
The TimeStampTokenEvidence sequence MUST contain at least one element of type TimeStampAndCRL.
TimestamptokenEvidenceシーケンスには、タイプタイプのタイプの要素を少なくとも1つの要素を含める必要があります。
The elements of the TimeStampTokenEvidence sequence MUST conform to the following rule:
TimestamptokenEvidenceシーケンスの要素は、次のルールに準拠する必要があります。
o if the metaData field is absent or the value of its hashProtected field is FALSE, then the TimeStampToken within the first element SHALL be computed over the value octets of the content field (if this field is absent, use the octets retrieved via the dataUri field);
o メタデータフィールドが存在しない場合、またはそのハッシュ保護されたフィールドの値が誤っている場合、最初の要素内のタイムスタンプがコンテンツフィールドの値で計算されます（このフィールドが存在しない場合は、Datauriフィールドを介して取得したオクテットを使用します）;
o otherwise (the metaData field is present and the value of its hashProtected field is TRUE), the TimeStampToken within the first element SHALL be computed over the concatenation of the following fields:
o それ以外の場合は、（メタデータフィールドが存在し、そのハッシュ保護されたフィールドの値が当てはまります）、最初の要素内のタイムスタンプが次のフィールドの連結について計算されなければなりません。
- the DER encoding of the metaData field;
- メタデータフィールドのderエンコード。
- the value octets of the content field (if this field is absent, use the octets retrieved via the dataUri field);
- コンテンツフィールドの値オクテット（このフィールドがない場合は、Datauriフィールドを介して取得したオクテットを使用します）。
o the TimeStampToken within the second element SHALL be computed over the first element;
o 2番目の要素内のタイムスタンプが最初の要素を介して計算されます。
o the TimeStampToken within each subsequent element SHALL be computed over its preceding element in the sequence.
o 次の各要素内のタイムスタンプは、シーケンス内の前の要素を介して計算されなければならない。
Within the TimeStampAndCRL construct, the optional crl field carries a suitable CRL (Certificate Revocation List) demonstrating that the certificate of the TSA (Time-Stamping Authority) that issued the TimeStampToken was not revoked at the time when the subsequent element in the TimeStampTokenEvidence sequence was added. See the Security Considerations section for further discussion on this topic.
TimestampandCRLコンストラクト内では、オプションのCRLフィールドには、タイムスタンプキンを発行したTSA（タイムスタンプ当局）の証明書が、タイムスタンプエクセイションシーケンスの後続の要素が撤廃されなかったことを実証する適切なCRL（証明書の取り消しリスト）があります。追加した。このトピックに関する詳細については、セキュリティに関する考慮事項セクションを参照してください。
Compliant applications MUST support at least the RFC 3161-based type of evidence (i.e., the tstEvidence CHOICE).
準拠アプリケーションは、少なくともRFC 3161ベースのタイプの証拠（つまり、TSTEVIDENTIANCEの選択）をサポートする必要があります。
This section is focused on the RFC 3161-based type of evidence. Processing of the structure for other types of evidence would be done in a similar manner.
このセクションは、RFC 3161ベースのタイプの証拠に焦点を当てています。他のタイプの証拠の構造の処理は、同様の方法で行われます。
In this case, applications are supposed to behave as follows:
この場合、アプリケーションは次のように動作することになっています。
o populate the version field with the integer value v1(1);
o バージョンフィールドに整数値v1（1）を入力します。
o if a self-contained envelope is to be generated, always populate the content field with the content of the file in its original format and encoding; depending on the application, the dataUri field may also be added;
o 自己完結型の封筒を生成する場合は、常に元の形式とエンコードでファイルのコンテンツをコンテンツフィールドに入力してください。アプリケーションに応じて、Datauriフィールドも追加される場合があります。
o otherwise (a detached envelope is to be generated), always populate the dataUri field with the URI of the time-stamped document (e.g., http://foo.example.com/Contract12345.pdf); using an absolute URI or a relative reference depends on the application;
o それ以外の場合は、（分離したエンベロープを生成する）、常にdatauriフィールドにタイムスタンプのドキュメントのURIに入力されます（例：http://foo.example.com/contract12345.pdf）;絶対URIまたは相対参照を使用すると、アプリケーションによって異なります。
o if the metaData field is being added, decide on the value of its hashProtected field; set its value to TRUE if the application needs the remaining fields of the metaData construct to be hash-protected as described in Section 2; otherwise, set it to FALSE;
o メタデータフィールドが追加されている場合は、ハッシュ保護されたフィールドの値を決定します。セクション2で説明されているように、アプリケーションがメタデータコンストラクトの残りのフィールドをハッシュ保護する必要がある場合、その値をtrueに設定します。それ以外の場合は、それをfalseに設定します。
o if the metaData field is being added, optionally populate the fileName field (e.g., "Contract12345.pdf"), the mediaType field with a suitable media type/subtype and possible parameters according to [MIME], and the otherMetaData field, depending on the application;
o メタデータフィールドが追加されている場合、オプションでファイル名フィールド（例： "Contract12345.pdf"）に設定されている場合、[MIME]に従って適切なメディアタイプ/サブタイプと可能なパラメーターを備えたメディアタイプフィールド、および他のメタデータフィールドは、応用;
o select a suitable one-way hash function and compute a hash value using that function over the content, or the concatenation of the metadata and the content, as described in Section 2; this hash value will then be used for requesting the first TimeStampToken;
o セクション2で説明されているように、適切な一方向ハッシュ関数を選択し、その関数、またはメタデータとコンテンツの連結を使用してハッシュ値を計算します。このハッシュ値は、最初のタイムスタンプが要求するために使用されます。
o obtain the first temporal evidence from a TSA and add it to the temporalEvidence field;
o TSAから最初の一時的な証拠を取得し、それを一時的なフィールドに追加します。
o insert the TimeStampedData into a ContentInfo structure, with the id-ct-timestampedData OID in the contentType field;
o ContentTampedDataをコンテンツタイプフィールドにID-CT-TIMESTAMPEDDATA OIDを使用して、ContentInfo構造に挿入します。
o BER-encode the ContentInfo structure (except for the fields that are required to be DER encoded) and save it with a reasonable file name (e.g., derived from the name of the time-stamped file).
o Ber-Encode contentinfo構造（derエンコードする必要があるフィールドを除く）を除く）、合理的なファイル名（たとえば、タイムスタンプされたファイルの名前から派生した）で保存します。
In this case, applications are supposed to behave as follows:
この場合、アプリケーションは次のように動作することになっています。
o check that the contentType field of the ContentInfo structure has the expected value (id-ct-timestampedData) in its contentType field; then, extract the inner TimeStampedData structure and continue processing;
o ContentInfo構造のContentTypeフィールドには、ContentTypeフィールドに期待値（ID-CT-TimestameData）があることを確認します。次に、内部のタイムスタンプドダタ構造を抽出し、処理を継続します。
o check the version field (it should be v1);
o バージョンフィールドを確認します（V1である必要があります）。
o check that the temporalEvidence field is not empty;
o 一時的なフィールドが空でないことを確認してください。
o check whether the content is present; if it is not, use the dataUri field to retrieve the file;
o コンテンツが存在するかどうかを確認してください。そうでない場合は、datauriフィールドを使用してファイルを取得します。
o open the first element of the TimeStampTokenEvidence sequence, open the time-stamp token within it and use the hash function that was used to obtain it to re-compute the hash of the fields indicated in Section 2; if the re-computed hash value matches the one within the time-stamp token, continue processing; otherwise, the TimeStampedData structure has been modified;
o TimestamptokenEvidenceシーケンスの最初の要素を開き、その中のタイムスタンプトークンを開き、それを取得するために使用されたハッシュ関数を使用して、セクション2に示されているフィールドのハッシュを再計算します。再計算されたハッシュ値がタイムスタンプトークン内の値と一致する場合は、処理を継続します。それ以外の場合、TimestampedData構造が変更されました。
o validate the temporalEvidence by checking that:
o 次のことをチェックすることにより、一時的な率を検証します
- each TimeStampToken in the chain does contain the correct digest value (according to the rule described in Section 2) and it was signed by a trusted TSA,
- チェーン内の各タイムスタンプは正しいダイジェスト値を含んでおり（セクション2で説明されているルールに従って）、信頼できるTSAによって署名されました。
- the corresponding TSA signing certificate was not revoked at the time when the subsequent TimeStampToken was issued, based on the associated CRL;
- 対応するTSA署名証明書は、関連するCRLに基づいて、その後のタイムスタンプキンが発行された時点では取り消されませんでした。
o depending on the application, use the temporal evidence for whatever purpose the application was designed for;
o アプリケーションに応じて、アプリケーションが設計された目的で一時的な証拠を使用します。
o depending on the application, show the dataUri, the fileName, the mediaType, the otherMetaData, and the temporal evidence to the user;
o アプリケーションに応じて、datauri、filename、mediatype、othermetadata、およびユーザーへの一時的な証拠を表示します。
o depending on the application, save the content to a separate file;
o アプリケーションによっては、コンテンツを別のファイルに保存します。
o depending on the application, store at a different place the content that has been retrieved using the dataUri field, then update the dataUri field accordingly;
o アプリケーションに応じて、Datauriフィールドを使用して取得されたコンテンツを別の場所に保存し、それに応じてDatauriフィールドを更新します。
o depending on the application, show the time-stamped file to the user, possibly by activating a suitable "viewer".
o アプリケーションに応じて、適切な「視聴者」をアクティブにすることにより、タイムスタンプのファイルをユーザーに表示します。
In this case, applications are supposed to behave as follows:
この場合、アプリケーションは次のように動作することになっています。
o validate the TimeStampedData structure as described above;
o 上記のように、タイムスタンプドダタ構造を検証します。
o select the time-stamp token from the last TimeStampAndCRL element in the chain and obtain the latest available CRL for the corresponding TSA certificate (if this CRL is not fresh enough, wait until the next one is available), then store it in the TimeStampAndCRL element;
o チェーン内の最後のタイムスタンパンドクルル要素からタイムスタンプトークンを選択し、対応するTSA証明書の最新のCRLを取得します（このCRLが十分に新鮮でない場合は、次のCRLが利用可能になるまで待ちます）。;
o instantiate a new TimeStampAndCRL element and obtain a new time-stamp token computed over the previous one, according to the rule described in Section 2; insert the new time-stamp token into the new TimeStampAndCRL element, then append the latter to the end of the chain.
o セクション2で説明されているルールに従って、新しいタイムスタンパンドクルル要素をインスタンス化し、前のもので計算された新しいタイムスタンプトークンを取得します。新しいタイムスタンプトークンを新しいタイムスタンパンドクルル要素に挿入し、後者をチェーンの端に追加します。
See the Security Considerations section for further discussion on extending the validity of an existing TimeStampedData structure.
既存のタイムスタンプドダタ構造の妥当性を拡張するためのさらなる議論については、セキュリティに関する考慮事項セクションを参照してください。
When the metaData field is present and the hashProtected sub-field is set to TRUE, the metadata are also included in the computation of the digest within the first time-stamp token, so that any subsequent alteration of the metadata will be easily detected. However, the integrity of hash-protected metadata does not imply that the metadata were correct at the time when the TimeStampedData object was created. That can only be inferred by other means (e.g., from context). For instance, when TimeStampedData objects are created by an archival service provider, it may be reasonable to assume that the metadata are correct at creation time. Instead, when a TimeStampedData object is received from an unknown party, the recipient cannot safely assume that the metadata are correct, lacking further information.
メタデータフィールドが存在し、ハッシュ保護されたサブフィールドがTrueに設定されている場合、メタデータは最初のタイムスタンプトークン内のダイジェストの計算にも含まれているため、メタデータのその後の変更が簡単に検出されます。ただし、ハッシュ保護されたメタデータの整合性は、タイムスタンプドダタオブジェクトが作成された時点でメタデータが正しかったことを意味するものではありません。それは他の手段によってのみ推測できます（例：コンテキストから）。たとえば、TimeStampedDataオブジェクトがアーカイブサービスプロバイダーによって作成されている場合、メタデータが作成時に正しいと仮定するのが合理的かもしれません。代わりに、未知の当事者からタイムスタンプドダタオブジェクトが受信された場合、受信者はメタデータが正しいと想定することはできず、さらなる情報がありません。
In general, a time-stamp token should not be considered valid after the certificate of the issuing TSA is expired (also, this consideration depends on the legislation and the policy under which the TSA operates). However, a time-stamp token can itself be time-stamped to extend the validity of the TSA's signature. By repeatedly applying this technique, a whole chain of time-stamp tokens can be grown to extend the validity of the first one ad libitum. Thus, this approach can be adopted to extend the validity of a TimeStampedData structure beyond the expiry date of the first TimeStampToken within it, by adding further elements to the TimeStampTokenEvidence sequence according to the rule described in Section 2. Of course, each additional TimeStampToken must be added in a timely manner (before the previous one is expired or has been revoked).
一般に、発行TSAの証明書が期限切れになった後、タイムスタンプトークンは有効と見なされるべきではありません（また、この考慮事項は、法律とTSAが運営するポリシーに依存します）。ただし、TSAの署名の有効性を拡張するために、タイムスタンプトークン自体をタイムスタンプすることができます。この手法を繰り返し適用することにより、タイムスタンプトークンのチェーン全体を成長させて、最初の広告リビタムの有効性を拡張することができます。したがって、このアプローチは、セクション2で説明されているルールに従ってタイムスタンプペンデーエビデンスシーケンスにさらなる要素を追加することにより、その中の最初のタイムスタンプが発生したタイムスタンプドタ構造の妥当性を拡張するために採用できます。タイムリーに追加されます（前のものが期限切れになるか、取り消される前に）。
The validity extension technique described above requires that the TSA signing certificates can still be verified long after they have expired, typically by checking a CRL. The CRL must be captured at the suitable time, because expired certificates are typically removed from the CRL regardless of their being revoked. The TimeStampAndCRL construct allows adding a CRL next to the related TimeStampToken, so that the TSA certificate will still be verifiable at any later time. The CRL must be captured at the time when another element is about to be added to the TimeStampTokenEvidence sequence, or even later -- to allow for a last-minute revocation request to be processed by the CA (see the discussion about "grace periods" in [CADES]).
上記の有効性拡張手法では、TSA署名証明書を、通常CRLをチェックすることにより、有効期限が切れてからずっと検証できることが必要です。期限切れの証明書は通常、取り消されていてもCRLから削除されるため、CRLは適切な時間にキャプチャする必要があります。TimestampandCrlコンストラクトにより、関連するTimestamptokenの横にCRLを追加できるため、TSA証明書は後で検証可能になります。CRLは、別の要素がタイムスタンプのエビデンスシーケンスに追加されようとしているときにキャプチャする必要があります。[ケード]）。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 5652、2009年9月。
[ERS] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007.
[ers] Gondrom、T.、Brandner、R。、およびU. Pordesch、「証拠記録構文（ERS）」、RFC 4998、2007年8月。
[KWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[KWORDS] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[PKIX1] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIX1] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、「Internet X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[TSP] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「インターネットX.509公開キーインフラストラクチャタイムスタンププロトコル（TSP）」、RFC 3161、2001年8月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[CADES] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced Electronic Signatures (CAdES)", RFC 5126, March 2008.
[Cades] Pinkas、D.、Pope、N。、およびJ. Ross、「CMS Advanced Electronic Signatures（Cades）」、RFC 5126、2008年3月。
The ASN.1 module contained in this appendix defines the structures that are needed to implement this specification. It is expected to be used in conjunction with the ASN.1 modules in [CMS], [TSP], [PKIX1], and [ERS].
この付録に含まれるASN.1モジュールは、この仕様を実装するために必要な構造を定義しています。[CMS]、[TSP]、[PKIX1]、および[ERS]のASN.1モジュールと組み合わせて使用されることが予想されます。
TimeStampedDataModule
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) 35 }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
輸入
-- Imports from RFC 5652 [CMS]
Attribute
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 3161 [TSP]
TimeStampToken
FROM PKIXTSP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-tsp(13)}
-- Imports from RFC 5280 [PKIX1]
CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(18)}
-- Imports from RFC 4998 [ERS]
EvidenceRecord
FROM ERS
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) id-mod(0)
id-mod-ers88(2) id-mod-ers88-v1(1) };
-- TimeStampedData Content Type and Object Identifier
-TimeStampedDataコンテンツタイプとオブジェクト識別子
id-ct-timestampedData OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 31 }
TimeStampedData ::= SEQUENCE {
version INTEGER { v1(1) },
dataUri IA5String OPTIONAL,
metaData MetaData OPTIONAL,
content OCTET STRING OPTIONAL,
temporalEvidence Evidence
}
MetaData ::= SEQUENCE {
hashProtected BOOLEAN,
fileName UTF8String OPTIONAL,
mediaType IA5String OPTIONAL,
otherMetaData Attributes OPTIONAL
}
Attributes ::=
SET SIZE(1..MAX) OF Attribute -- according to RFC 5652
Evidence ::= CHOICE {
tstEvidence [0] TimeStampTokenEvidence, -- see RFC 3161
ersEvidence [1] EvidenceRecord, -- see RFC 4998
otherEvidence [2] OtherEvidence
}
OtherEvidence ::= SEQUENCE {
oeType OBJECT IDENTIFIER,
oeValue ANY DEFINED BY oeType }
TimeStampTokenEvidence ::=
SEQUENCE SIZE(1..MAX) OF TimeStampAndCRL
TimeStampAndCRL ::= SEQUENCE {
timeStamp TimeStampToken, -- according to RFC 3161
crl CertificateList OPTIONAL -- according to RFC 5280
}
END
終わり
Thanks to Stephen Kent for encouraging the author in the early stages of this work.
この作業の初期段階で著者を励ましてくれたStephen Kentに感謝します。
Thanks to Russ Housley for reviewing this memo, suggesting useful amendments and assigning a value to the OIDs herein defined.
このメモをレビューしてくれたRuss Housleyに感謝し、有用な修正を提案し、ここで定義されているOIDに値を割り当てることを提案してくれました。
Thanks are also due to other people who reviewed this memo and helped improving it, but prefer not to be mentioned.
また、このメモをレビューし、それを改善するのを手伝ってくれた他の人々に感謝しますが、言及しないことを好みます。
Author's Address
著者の連絡先
Adriano Santoni Actalis S.p.A. Via Taramelli 26 I-20124 Milano Italy
Adriano Santoni Actalis S.P.A.
EMail: adriano.santoni@actalis.it