RFC4810 日本語訳
4810 Long-Term Archive Service Requirements. C. Wallace, U. Pordesch,R. Brandner. March 2007. (Format: TXT=35690 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Wallace
Request for Comments: 4810 Cygnacom Solutions
Category: Informational U. Pordesch
Fraunhofer Gesellschaft
R. Brandner
InterComponentWare AG
March 2007
コメントを求めるワーキンググループC.ウォレス要求をネットワークでつないでください: 4810年のCygnacomソリューションカテゴリ: 2007年の情報のU.のフラウンホーファー利益社会R.Brandner InterComponentWare株式会社Pordesch行進
Long-Term Archive Service Requirements
長期のアーカイブサービス要件
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services.
ユーザが時間内に、特定のポイントでデータの存在を立証して、その時以来にデータの完全性を示すことができなければならない多くのシナリオがあります、存在の時間からデモンストレーションの時間までの持続時間が大きい期間にかかるときさえ。 さらに、ユーザは署名の世代何年も後にデジタルにサインされたデータで署名について確かめることができなければなりません。 このドキュメントは、そのようなサービスと対話するためのそのようなシナリオと技術的要求事項を支持するために長期的にアーカイブサービスのクラスについて説明します。
Wallace, et al. Informational [Page 1] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[1ページ]のRFC4810は2007年3月に要件を格納します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Principles . . . . . . . . . . . . . . . . . . . . . . 5
4. Technical Requirements . . . . . . . . . . . . . . . . . . . . 6
4.1. Enable Submission, Retrieval, and Deletion of Archived
Data Objects . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Functional Requirements . . . . . . . . . . . . . . . 7
4.1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Operate in accordance with a long-term archive policy . . 8
4.2.1. Functional Requirements . . . . . . . . . . . . . . . 8
4.2.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Enable Management of Archived Data Objects . . . . . . . . 9
4.3.1. Functional Requirements . . . . . . . . . . . . . . . 9
4.3.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Provide Evidence Records that Support Demonstration of
Data Integrity . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Functional Requirements . . . . . . . . . . . . . . . 10
4.4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Support Data Confidentiality . . . . . . . . . . . . . . . 11
4.5.1. Functional Requirements . . . . . . . . . . . . . . . 11
4.5.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Provide Means to Transfer Data and Evidence from One
Service to Another . . . . . . . . . . . . . . . . . . . . 11
4.6.1. Functional Requirements . . . . . . . . . . . . . . . 11
4.6.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Support Operations on Groups of Data Objects . . . . . . . 12
4.7.1. Functional Requirements . . . . . . . . . . . . . . . 12
4.7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Application Scenarios . . . . . . . . . . . . . . . . 15
A.1. Archive Service Supporting Long-Term Non-Repudiation . . . 15
A.2. Pure Long-Term Non-Repudiation Service . . . . . . . . . . 15
A.3. Long-Term Archive Service as Part of an Internal
Network . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.4. Long-Term Archive External Service . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 綱領. . . . . . . . . . . . . . . . . . . . . . 5 4。 技術的要求事項. . . . . . . . . . . . . . . . . . . . 6 4.1。 格納されたデータ・オブジェクト. . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1の服従、検索、および削除を可能にしてください。 機能条件書. . . . . . . . . . . . . . . 7 4.1.2。 原理. . . . . . . . . . . . . . . . . . . . . . 7 4.2。 長期のアーカイブ方針. . 8 4.2.1に従って、作動してください。 機能条件書. . . . . . . . . . . . . . . 8 4.2.2。 原理. . . . . . . . . . . . . . . . . . . . . . 9 4.3。 格納されたデータ・オブジェクト. . . . . . . . 9 4.3.1の管理を可能にしてください。 機能条件書. . . . . . . . . . . . . . . 9 4.3.2。 原理. . . . . . . . . . . . . . . . . . . . . . 9 4.4。 データの保全. . . . . . . . . . . . . . . . . . . . . . 10 4.4.1のそのSupport DemonstrationをEvidence Recordsに供給してください。 機能条件書. . . . . . . . . . . . . . . 10 4.4.2。 原理. . . . . . . . . . . . . . . . . . . . . . 10 4.5。 データの機密性. . . . . . . . . . . . . . . 11 4.5.1を支持してください。 機能条件書. . . . . . . . . . . . . . . 11 4.5.2。 原理. . . . . . . . . . . . . . . . . . . . . . 11 4.6。 別の.114.6に対する1つのサービスからデータと証拠を.1に移す手段を提供してください。 機能条件書. . . . . . . . . . . . . . . 11 4.6.2。 原理. . . . . . . . . . . . . . . . . . . . . . 11 4.7。 データ・オブジェクト. . . . . . . 12 4.7.1人のグループで操作を支持してください。 機能条件書. . . . . . . . . . . . . . . 12 4.7.2。 原理. . . . . . . . . . . . . . . . . . . . . . 12 5。 操作上の問題. . . . . . . . . . . . . . . . . . 12 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 14 8。 有益な参照. . . . . . . . . . . . . . . . . . . . 14付録A.アプリケーションシナリオ. . . . . . . . . . . . . . . . 15A.1。 長期の非拒否.15A.2を支持するサービスを格納してください。 純粋な長期の非拒否サービス. . . . . . . . . . 15A.3。 内部のネットワーク. . . . . . . . . . . . . . . . . . . . . . . . . 15A.4の一部としての長期のアーカイブサービス。 長期のアーカイブ外部サービス. . . . . . . . . . . . 15
Wallace, et al. Informational [Page 2] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[2ページ]のRFC4810は2007年3月に要件を格納します。
1. Introduction
1. 序論
Digital data durability is undermined by continual progress and change on a number of fronts. The useful lifetime of data may exceed the life span of formats and mechanisms used to store the data. The lifetime of digitally signed data may exceed the validity periods of public-key certificates used to verify signatures or the cryptanalysis period of the cryptographic algorithms used to generate the signatures, i.e., the time after which an algorithm no longer provides the intended security properties. Technical and operational means are required to mitigate these issues. A solution must address issues such as storage media lifetime, disaster planning, advances in cryptanalysis or computational capabilities, changes in software technology, and legal issues.
ディジタルデータの耐久性は多くの前部で絶え間ない進歩と変化によってひそかに害せられます。 データの役に立つ寿命は形式の寿命を超えるかもしれません、そして、メカニズムは以前はよくデータを格納していました。 デジタルにサインされたデータの寿命が署名について確かめるのに使用される公開カギ証明書の有効期間を超えるかもしれませんか、または暗号アルゴリズムの暗号文解読術の期間は以前は、署名(すなわち、アルゴリズムがもう意図しているセキュリティ資産を提供しない時)をよく発生させていました。 技術的で操作上の手段が、これらの問題を緩和するのに必要です。 解決策は記憶媒体生涯や災害対策や暗号文解読術における進歩やコンピュータの能力や、ソフトウェア技術における変化や、法律問題などの問題を記述しなければなりません。
A long-term archive service aids in the preservation of data over long periods of time through a regimen of technical and procedural mechanisms designed to support claims regarding a data object. For example, it might periodically perform activities to preserve data integrity and the non-repudiability of data existence by a particular point in time or take actions to ensure the availability of data. Examples of periodic activities include refreshing time stamps or transferring data to a new storage medium.
データ・オブジェクトに関するクレームを支持するように設計された技術的で手続き上のメカニズムの養生法による長期間の間のデータの保存における長期のアーカイブサービスエイド。 例えば、それは、データの利用可能性を確実にするためにデータ保全と時間内にの特定のポイントのデータ存在か撮影の非repudiability動作を保存するために定期的に活動を実行するかもしれません。 周期的な活動に関する例は、壮快なタイムスタンプか新しい記憶媒体にデータを移すのを含んでいます。
A long-term archive service may be used to provide evidence that supports validation of the existence of documents or assertions of agreements that were originally asserted with digital signatures. Validation may occur at times in the future well beyond the validity period of the private key originally used to generate the signature, or even beyond the time when the algorithms available for digital signatures, message digesting, or data encryption cease to offer effective protection because of improvements in computing speeds and methods.
長期のアーカイブサービスは、ドキュメントの存在の合法化か元々デジタル署名で断言された協定の主張を支持する証拠を提供するのに利用されるかもしれません。 合法化は将来、時には、元々署名を発生させるのに使用された秘密鍵の有効期間を超えてデジタル署名、メッセージの読みこなすこと、またはデータ暗号化に利用可能なアルゴリズムが改良のために、速度と方法を計算する際に有効保護を提供するのをやめる時間さえ、よく起こるかもしれません。
A long-term archive service may be located within an enterprise network, communicating with local storage mechanisms and other applications, or a long-term archive service may be implemented as an external service accessible via the Internet. A long-term archive service may use functionality, e.g., time stamping, provided by independent service providers.
ローカルの格納メカニズムと他のアプリケーションとコミュニケートして、長期のアーカイブサービスが企業網の中に位置するかもしれませんか、または長期のアーカイブサービスはインターネットを通してアクセスしやすい外部サービスとして実行されるかもしれません。 長期のアーカイブサービスは機能性、例えば独立しているサービスプロバイダーによって提供された時間の刻印を使用するかもしれません。
A primary goal of a long-term archive service is to support the credible assertion of a claim that is currently asserted, at points well into the future. A long-term archive service may support a range of applications, including: wills, land records, medical data, criminal case files, personnel files, and contracts. A long-term archive service may be used by any type of entity, e.g.,
第一の長期的にアーカイブサービスの目標は現在断言されるクレームの確かな主張を支持することです、よく未来までのポイントで。 長期のアーカイブサービスはさまざまなアプリケーション、包含を支持するかもしれません: 意志、陸の記録、医学のデータ、犯罪のケース・ファイル、職員のファイル、および契約。 長期のアーカイブサービスは例えばどんなタイプの実体によっても利用されるかもしれません。
Wallace, et al. Informational [Page 3] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[3ページ]のRFC4810は2007年3月に要件を格納します。
organizations, citizens, notaries. Examples of long-term archive service usage by submitters include:
組織、市民、公証人。 submittersによる長期のアーカイブサービス用法に関する例は:
- A company stores contracts using a third party service.
- 会社は、第三者サービスを利用することで契約を格納します。
- A hospital stores medical data using an internal service.
- 病院は、内部のサービスを利用することで医学のデータを格納します。
- An individual wants to generate evidence of data possession at a
particular point in time, e.g., for intellectual property purposes
or endorsement of a contract.
- 個人は時間内に特定のポイントでデータ所有物に関する証拠を発生させたがっています、例えば、契約の知的所有権目的か裏書きのために。
- A law enforcement officer wants to store criminal data such that
integrity of the data can be demonstrated years later.
- 執行官は、何年も後にデータの保全を示すことができるように刑事上のデータを格納したがっています。
For each of the above examples, there is a corresponding example involving retrievers, e.g., a company retrieves a contract in the case of a dispute or a law enforcement officer prepares information for a criminal trial.
それぞれの上記の例に関しては、レトリーバーにかかわる対応する例があるか、例えば、会社が論争の場合で契約を検索するか、または執行官は刑事裁判のために情報を準備します。
This document addresses the technical requirements for a long-term archive service.
このドキュメントは長期のアーカイブサービスのための技術的要求事項を記述します。
2. Terminology
2. 用語
We define the following terms based on their usage in the archiving community, in order to provide a vocabulary for describing requirements and the standards around them.
私たちは格納共同体でそれらの用法に基づく次の用語を定義します、それらの周りで要件と規格について説明するのにボキャブラリーを提供するために。
Arbitrator: Principal for whom the validity of archived data
characteristics, e.g., origin, integrity or time of existence,
must be demonstrated.
仲裁者: 格納されたデータの特性、例えば、起源の正当性(存在の保全か時間)を示さなければならない校長。
Archival Period: The period during which an archived data object is
preserved by a long-term archive service.
記録保管所の期間: 格納されたデータ・オブジェクトが長期のアーカイブサービスで保存される期間。
Archived Data Object: Data unit to be preserved by a long-term
archive service.
格納されたデータ・オブジェクト: 長期のアーカイブサービスで保存されるべきデータ単位。
Archive Package: Collection of information including archived data
objects and associated Evidence Record.
パッケージを格納してください: 情報包含の収集はデータ・オブジェクトと関連Evidence Recordを格納しました。
Cryptographic Maintenance Policy: A set of rules that defines how
to maintain the validity of digitally signed objects should one of
the hash or asymmetric algorithms used to create a digital
signature become weak, or one of the private keys used to create a
digital signature be compromised or become weak.
暗号の維持方針: デジタルにサインされた物の正当性がそうするべきであると主張するために、細切れ肉料理か非対称のアルゴリズムの1つが以前はよくデジタル署名を作成した方法を定義する1セットの規則が弱くなるか、またはデジタル署名を作成するのに使用される秘密鍵の1つは、妥協するか、弱くなります。
Wallace, et al. Informational [Page 4] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[4ページ]のRFC4810は2007年3月に要件を格納します。
Evidence: Information that may be used to demonstrate the validity
of an archived data object or related attestations.
証拠: 格納されたデータ・オブジェクトか関連する証明の正当性を示すのに使用されるかもしれない情報。
Evidence Record: Collection of evidence compiled for one or more
archived data objects. An Evidence Record may include
acknowledgements from a long-term archive service, time stamps and
verification data, such as public-key certificates, revocation
information, trust anchors, policy details and role information.
記録を証明してください: 1以上のためにコンパイルされた証拠の収集はデータ・オブジェクトを格納しました。 Evidence Recordは長期のアーカイブサービス、タイムスタンプ、および検証データからの承認を含むかもしれません、公開カギ証明書や、取消し情報や、信用アンカーや、方針の詳細や役割の情報などのように。
Long-Term Archive Policy: A set of rules that define operational
characteristics of a long-term archive service.
長期のアーカイブ方針: 操作上の長期的にアーカイブサービスの特性を定義する1セットの規則。
Long-Term Archive Service (LTA): A service that is responsible for
preserving data for long periods.
長期のアーカイブサービス(LTA): 長期の間、データを保存するのに原因となるサービス。
Modifier: Principal who modifies attributes associated with an
archived data object and/or Evidence Record held by a long-term
archive service.
修飾語: 格納されたデータ・オブジェクト、そして/または、Evidence Recordに関連している属性を変更する校長が長期のアーカイブサービスを固守しました。
Originator: Principal who produces, and possibly digitally signs,
an archived data object. The Originator does not necessarily have
any relationship with a long-term archive service or any awareness
of an Evidence Record associated with the archived data object.
創始者: 格納されたデータ・オブジェクトを作り出して、ことによるとデジタルにサインする校長。 Originatorには、長期のアーカイブサービスとのどんな関係か格納されたデータ・オブジェクトに関連しているEvidence Recordの少しの認識も必ずあるというわけではありません。
Retriever: Principal who retrieves archived data objects and/or
Evidence Records from a long-term archive service.
レトリーバー: 長期のアーカイブサービスから格納されたデータ・オブジェクト、そして/または、Evidence Recordsを検索する校長。
Submitter: Principal who submits data objects for archiving.
Submitter: データを提出する校長は格納のために反対します。
Time Stamp: An attestation generated by a Time Stamping Authority
(TSA) that a data item existed at a certain time. For example,
[RFC3161] specifies a structure for signed time stamp tokens as
part of a protocol for communicating with a TSA.
タイムスタンプ: 証明はTime Stamping Authorityで(TSA)を発生させました。データ項目は一定の時刻に存在しました。 例えば、[RFC3161]は、TSAとコミュニケートするためにプロトコルの一部としてサインされたタイムスタンプ象徴に構造を指定します。
Time Stamping Authority (TSA): A trusted service that provides
attestations of existence of data at particular points in time.
For example, [RFC3161] defines protocol elements for interacting
with a TSA.
時間の刻印権威(TSA): 時間内に特定のポイントでデータの存在の証明を提供する信じられたサービス。 例えば、[RFC3161]は、TSAと対話するためにプロトコル要素を定義します。
3. General Principles
3. 綱領
A long-term archive service may accept any type of data for preservation. The data might be in any format, whether textual data, images, documents, applications, or compound packages of multiple components. The data may be digitally signed, time stamped, encrypted, or not subject to any cryptographic processing.
長期のアーカイブサービスは保存のためのどんなタイプに関するデータも受け入れるかもしれません。 複数のコンポーネントの原文のデータ、イメージ、ドキュメント、アプリケーション、または合成パッケージであることにかかわらずどんな形式にもデータがあるかもしれません。 データはデジタルにサインされるかもしれなくて、時間はどんな暗号の処理への押し込まれて、コード化された対象です。
Wallace, et al. Informational [Page 5] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[5ページ]のRFC4810は2007年3月に要件を格納します。
A long-term archive service may preserve archived data objects as opaque collections of bytes with the primary aim of data integrity.
サービスが保存するかもしれない長期のアーカイブはデータ保全の主要目的があるバイトの不明瞭な収集としてデータ・オブジェクトを格納しました。
A long-term archive service is not required to operate upon evidence related to the content of archived data objects. Content-focused operations, including data format migration or translation, may be performed by another service. However, an LTA may incorporate support for such services.
長期のアーカイブサービスは、格納されたデータ・オブジェクトの内容に関連する証拠を作動させるのに必要ではありません。 データの形式移動か翻訳を含む内容で集中している操作は別のサービスで実行されるかもしれません。 しかしながら、LTAはそのようなサービスのサポートを取り入れるかもしれません。
Different long-term archive services may establish policies and procedures for archiving data objects over different lengths of time. For example, an LTA may refuse to preserve archived data objects for periods longer than 30 years. Similarly, LTAs may establish policies that limit the types of data that will be accepted for deposit by a particular LTA.
異なった長期のアーカイブサービスは異なった長さの時間データ・オブジェクトを格納するための方針と手順を確立するかもしれません。 例えば、LTAは、30年より長いときに期間、格納されたデータ・オブジェクトを保存するのを拒否するかもしれません。 同様に、LTAsは預金で特定のLTAによって受け入れられるデータのタイプを制限する方針を確立するかもしれません。
A long-term archive service provides evidence that may be used to demonstrate the existence of an archived data object at a given time and the integrity of the archived data object since that time. Additionally, the evidence identifies the LTA(s) that have participated in the preservation of the archived data object. If the archived data object itself contains digitally signed data, authentication of the signer is also possible.
長期のアーカイブサービスは一時に格納されたデータ・オブジェクトの存在を示すのに使用されるかもしれない証拠とその時以来の格納されたデータ・オブジェクトの保全を提供します。 さらに、証拠は格納されたデータ・オブジェクトの保存に参加したLTA(s)を特定します。 また、格納されたデータ・オブジェクト自体がデジタルにサインされたデータを含んでいるなら、署名者の認証も可能です。
A long-term archive service may be an adjunct component of a document management system. In such cases, the Evidence Record generated and maintained by the LTA is a property of data that is otherwise managed by the document management system.
長期のアーカイブサービスはドキュメント管理システムの付属物の部品であるかもしれません。 そのような場合、LTAによって発生して、維持されたEvidence Recordは別の方法でドキュメント管理システムによって管理されるデータの特性です。
4. Technical Requirements
4. 技術的要求事項
This section describes the requirements for the protocol for accessing a long-term archive system and for the data formats associated with data preservation.
このセクションは長期のアーカイブシステムにアクセスして、データ保存に関連しているデータ形式のためにプロトコルのための要件について説明します。
4.1. Enable Submission, Retrieval, and Deletion of Archived Data
Objects
4.1. 格納されたデータ・オブジェクトの服従、検索、および削除を可能にしてください。
Wallace, et al. Informational [Page 6] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[6ページ]のRFC4810は2007年3月に要件を格納します。
4.1.1. Functional Requirements
4.1.1. 機能条件書
A long-term archive service must permit clients to request the following basic operations:
長期のアーカイブサービスは、クライアントが以下の基本的な操作を要求することを許可しなければなりません:
- submit data objects for archive
- アーカイブのためにデータ・オブジェクトを提出してください。
- retrieve archived data objects
- 格納されたデータ・オブジェクトを検索してください。
- delete archived data objects
- 格納されたデータ・オブジェクトを削除してください。
Following submission, the service must provide an identifier that can be used to retrieve the archived data and/or associated evidence. For example, it may be possible to retrieve archive packages by using a hash value of an archived data object. Possession of this value is not necessarily an authorization to access the associated archived data object or evidence record.
服従に続いて、サービスは格納されたデータ、そして/または、関連証拠を検索するのに使用できる識別子を提供しなければなりません。 例えば、格納されたデータ・オブジェクトのハッシュ値を使用することによってアーカイブパッケージを検索するのは可能であるかもしれません。 この価値の所有物は必ず関連格納されたデータ・オブジェクトか証拠記録にアクセスする認可であるというわけではありません。
It must be possible to authenticate requests and responses, e.g., to enable LTAs to render an authorization decision. This may be accomplished by using transport security mechanisms. Requests, in particular retrieval or deletion requests, may be rejected if the requestor is not authorized. An authorization policy must be defined and observed by the long-term archive service. An LTA may disallow deletion as a matter of policy.
要求と応答を認証して、例えばLTAsが認可決定を表すのを可能にするのは可能であるに違いありません。 これは、輸送セキュリティー対策を使用することによって、達成されます。要請者が認可されていないなら、要求(特に検索か削除要求)は、拒絶されるかもしれません。 長期のアーカイブサービスで認可方針を定義されて、観測しなければなりません。 LTAは政策の問題として削除を禁じるかもしれません。
The format for the acknowledgements must allow the identification of the archiving provider and the participating client.
承認のための形式は格納プロバイダーと参加しているクライアントの識別を許さなければなりません。
The LTA must provide an acknowledgement of the deposit that permits the submitter to confirm the correct data was accepted by the LTA. This proof need not be provided immediately.
LTAはsubmitterが、正しいデータがLTAによって受け入れられたと確認することを許可する預金の承認を提供しなければなりません。 すぐに、この証拠を提供する必要はありません。
4.1.2. Rationale
4.1.2. 原理
Submission, retrieval, query state, and deletion of archived data objects are necessary basic functions of a long-term archive service.
格納されたデータ・オブジェクトの服従、検索、質問状態、および削除は必要な長期的にアーカイブサービスの基本機能です。
Deletion may be disallowed due to procedural difficulties in fulfilling the request. For example, an archived data object may be stored on write-once media, along with other records that are not subject to deletion.
削除は要求を実現させることにおける手続き上の苦労のため禁じられるかもしれません。 例えば、格納されたデータ・オブジェクトは-一度書いているメディアで格納されるかもしれません、削除を受けることがない他の記録と共に。
Acknowledgements may not be provided immediately due to implementation of a grace period. A generic query state mechanism should be provided to address such situations. For example, a
承認はすぐ据置期間の実現のため提供されないかもしれません。 そのような状況を記述するために一般的な質問州のメカニズムを提供するべきです。 例えば、a
Wallace, et al. Informational [Page 7] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[7ページ]のRFC4810は2007年3月に要件を格納します。
submission response may indicate that a submission has been accepted and a subsequent query state response may indicate a submission has completed all necessary preservation steps.
服従応答は、服従が受け入れられたのを示すかもしれません、そして、その後の質問州の応答は服従がすべての必要な保存ステップを終了したのを示すかもしれません。
4.2. Operate in accordance with a long-term archive policy
4.2. 長期のアーカイブ方針に従って、作動してください。
4.2.1. Functional Requirements
4.2.1. 機能条件書
A long-term archive service must operate in accordance with a long- term archive service policy that defines characteristics of the implementation of the long-term archive service. A long-term archive service policy contains several components, including:
長期的にアーカイブサービスの実現の特性を定義する長い用語アーカイブサービス方策によると、長期のアーカイブサービスは作動しなければなりません。 長期のアーカイブサービス方策は数個のコンポーネント、包含を含んでいます:
- Archived data object maintenance policy
- 格納されたデータ・オブジェクト維持方針
- Authorization policy
- 認可方針
- Service policy
- サービス方策
A long-term archive service policy must include specifications of the preservation activities performed for archived data objects subject to the policy. A maintenance policy should define rules for the following operational aspects: preservation activity triggers, default archival period, and default handling upon expiration of archival period.
長期のアーカイブサービス方策は格納されたデータ・オブジェクトのために方針を条件として実行された保存活動の仕様を含まなければなりません。 維持方針は以下の操作上の局面と規則を定義するべきです: 記録保管所の期間の満了の保存活動引き金、デフォルトの記録保管所の期間、およびデフォルト取り扱い。
Maintenance policies should include mechanism-specific details describing LTA operation. For example, where cryptographic mechanisms are employed, a cryptographic maintenance policy ought to be defined.
維持方針はLTA操作について説明するメカニズム特有の詳細を含むべきです。 例えば、暗号のメカニズムが採用しているところでは、暗号の維持方針は定義されるべきです。
An authorization policy should define the entities permitted to exercise services provided by the LTA, including who is permitted to submit, retrieve, or manage specific archived data objects.
認可方針はLTAによって提供されたサービスを運動させるのが許容された実体を定義するべきです、だれが特定の格納されたデータ・オブジェクトを提出するか、検索するか、または管理することを許可されているかを含んでいて。
A service policy defines the types of services provided by an LTA, including acceptable data types, description of requests that may be accepted, and deletion procedures.
サービス方策はLTAによって提供されたサービスのタイプを定義します、許容できるデータ型、受け入れられるかもしれない要求の記述、および削除手順を含んでいて。
Policies must be unambiguously identified, e.g., by an object identifier. Alternatively, an LTA may support a protocol that permits clients to specify policy parameters explicitly instead of by reference to a policy.
例えば、物の識別子で明白に方針を特定しなければなりません。 あるいはまた、LTAはクライアントが方針の参照の代わりに明らかに方針パラメタを指定することを許可するプロトコルをサポートするかもしれません。
A long-term archive service must be able to provide information identifying the policies relevant for a given archived data object.
長期のアーカイブサービスは与えられた格納されたデータ・オブジェクトにおいて、関連している方針を特定する情報を提供できなければなりません。
Wallace, et al. Informational [Page 8] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[8ページ]のRFC4810は2007年3月に要件を格納します。
4.2.2. Rationale
4.2.2. 原理
Similar to a certificate policies [RFC3647], which are identified using object identifiers, a long-term archive policy provides a shorthand means of technically identifying a set of rules that govern the operation of a long-term archive service.
証明書方針[RFC3647]と同様です、長期のアーカイブ方針は長期的にアーカイブサービスの操作を治める1セットの規則を技術的に特定する手段を速記に提供します。(]は、物の識別子を使用することで特定されます)。
Over the course of many years, the policies under which an LTA operates may undergo modification. Thus, an evidence record may feature multiple indications of policies active at various points during the life of an archived data object.
何年も過程にわたって、LTAが作動する方針は変更を受けるかもしれません。 したがって、証拠記録は格納されたデータ・オブジェクトの人生の間、様々なポイントでアクティブな方針の複数のしるしを特集するかもしれません。
4.3. Enable Management of Archived Data Objects
4.3. 格納されたデータ・オブジェクトの管理を可能にしてください。
4.3.1. Functional Requirements
4.3.1. 機能条件書
A long-term archive service must permit clients to request the following basic operations:
長期のアーカイブサービスは、クライアントが以下の基本的な操作を要求することを許可しなければなりません:
- specify an archival period for submitted data objects
- 提出されたデータ・オブジェクトに記録保管所の期間を指定してください。
- extend or shorten the archival period for an archived data object
- 格納されたデータ・オブジェクトのために記録保管所の期間を延ばすか、または短くしてください。
- specify metadata associated with an archived data object
- 格納されたデータ・オブジェクトに関連しているメタデータを指定してください。
- specify an archive policy under which the submitted data should be
handled
- 提出されたデータが扱われるべきであるアーカイブ方針を指定してください。
It should be possible to express an archival period in terms of time, an event or a combination of time and event.
時間と出来事の時間、出来事または組み合わせで記録保管所の期間を言い表すのは可能であるべきです。
Submitters should be able to specify metadata that, for example, can be used to enable retrievers to render the data correctly, to locate data in an archive or to place data in a particular context. Examples include, classification codes, type of format, contributors, title, author, and date. Alternatively, such information may be included in the content of an archived data object.
Submittersは、レトリーバーが正しくデータを表すか、アーカイブのデータの場所を見つけるか、または特定の文脈のデータを置くのを可能にするために、例えば使用できるメタデータを指定するはずであることができます。 インクルード、形式のタイプ(貢献者)が題をつける分類コードが書いて、日付を入れる例。 あるいはまた、そのような情報は格納されたデータ・オブジェクトの内容に含まれるかもしれません。
If a long-term archive service does not support a requested policy, it must return an error indication. A service must provide an indication of the archive policy enforced by the service.
長期のアーカイブサービスが要求された方針を支持しないなら、それは誤り表示を返さなければなりません。 サービスはサービスによって励行されるアーカイブ方針のしるしを供給しなければなりません。
4.3.2. Rationale
4.3.2. 原理
Submission, retrieval, and deletion of archived data objects are necessary basic functions of a long-term archive service.
格納されたデータ・オブジェクトの服従、検索、および削除は必要な長期的にアーカイブサービスの基本機能です。
Wallace, et al. Informational [Page 9] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[9ページ]のRFC4810は2007年3月に要件を格納します。
Specification and management of the archival period is necessary to avoid unnecessary preservation activities.
記録保管所の期間の仕様と管理が、不要な保存活動を避けるのに必要です。
4.4. Provide Evidence Records that Support Demonstration of Data
Integrity
4.4. データの保全のそのSupport DemonstrationをEvidence Recordsに供給してください。
4.4.1. Functional Requirements
4.4.1. 機能条件書
A long-term archive service must be capable of providing evidence that can be used to demonstrate the integrity of data for which it is responsible, from the time it received the data until the expiration of the archival period of the data.
長期のアーカイブサービスはそれが責任があるデータの完全性を示すのに使用できる証拠を提供できなければなりません、それがデータを受信した時からデータの記録保管所の期間の満了まで。
This may be achieved by providing evidence records that support the long-term non-repudiation of data existence at a point in time, e.g., in the case of legal disputes. The evidence record should contain sufficient information to enable the validity of an archived data object's characteristics to be demonstrated to an arbitrator. The characteristics subject to verification will vary. For example, authentication of an originator may not be possible in all cases, e.g., where the object submitted to the archive is not signed or where the object does not include the necessary information to authenticate the object's signer.
これは時間内にポイントでデータ存在の長期の非拒否を支持する証拠記録を提供することによって、達成されるかもしれません、例えば、法律に関する論争の場合で。 証拠記録は格納されたデータ・オブジェクトの特性の正当性が仲裁者に示されるのを可能にすることができるくらいの情報を含むべきです。 検証を条件とした特性は異なるでしょう。 例えば、創始者の認証はすべての場合で可能でないかもしれません、例えば、アーカイブに提出された物がサインされないか、または物が物の署名者を認証するために必要事項を含んでいないところで。
Evidence records must be structured such that modifications to an archived data object or its evidence record can be detected, including modifications made by administrators of an LTA.
格納されたデータ・オブジェクトかその証拠記録への変更を検出できるように証拠記録を構造化しなければなりません、LTAの管理者によってされた変更を含んでいて。
4.4.2. Rationale
4.4.2. 原理
Supporting non-repudiation of data existence, integrity, and origin is a primary purpose of a long-term archive service. Evidence may be generated, or otherwise obtained, by the service providing the evidence to a retriever. A long-term archive service need not be capable of providing all evidence necessary to produce a non- repudiation proof, and in some cases, should not be trusted to provide all necessary information. For example, trust anchors [RFC3280] and algorithm security policies should be provided by other services. An LTA that is trusted to provide trust anchors could forge an evidence record verified by using those trust anchors.
データ存在、保全、および起源の非拒否を支持するのは、第一の長期的にアーカイブサービスの目的です。 証拠を発生するか、または別の方法で得るかもしれません、証拠をレトリーバーに提供するサービスで。長期のアーカイブサービスは非拒否している証拠を生産するのに必要なすべての証拠を提供できなければならないというわけではありません、そして、いくつかの場合、すべての必要事項を提供すると信じるべきではありません。 例えば、アンカー[RFC3280]とアルゴリズム安全保障政策が他のサービスで提供されるべきであると信じてください。 信用アンカーを提供すると信じられるLTAはそれらの信用アンカーを使用することによって確かめられた証拠記録を作り出すことができました。
Demonstration that data has not been altered while in the care of a long-term archive service is a first step towards supporting non- repudiation of data. Certification services support cases in which data must be modified, e.g., translation or format migration. An LTA may provide certification services.
データの非拒否を支持することに向かったデータが長期的にアーカイブサービスの注意にはある間変更されていないというデモンストレーションは第一歩です。 証明サービスは、データを変更しなければならない場合、例えば翻訳を支持するか、または移動をフォーマットします。 LTAは証明サービスを提供するかもしれません。
Wallace, et al. Informational [Page 10] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[10ページ]のRFC4810は2007年3月に要件を格納します。
4.5. Support Data Confidentiality
4.5. サポートデータの機密性
4.5.1. Functional Requirements
4.5.1. 機能条件書
A long-term archive service must provide means to ensure confidentiality of archived data objects, including confidentiality between the submitter and the long-term archive service. An LTA must provide a means for accepting encrypted data such that future preservation activities apply to the original, unencrypted data. Encryption, or other methods of providing confidentiality, must not pose a risk to the associated evidence record.
長期のアーカイブサービスは格納されたデータ・オブジェクトの秘密性を確実にする手段を提供しなければなりません、submitterと長期のアーカイブサービスの間に秘密性を含んでいて。 LTAがコード化されたデータを受け入れるための手段を提供しなければならないので、今後の保存活動はオリジナルの、そして、非コード化されたデータに適用されます。 暗号化、または秘密性を提供する他の方法が関連証拠記録への危険を引き起こしてはいけません。
A long-term archive service should maintain contact information for the parties responsible for each archived data object so warning messages can be sent when encryption algorithms require maintenance.
長期のアーカイブサービスは、それぞれに責任があるパーティーへの問い合わせ先が暗号化アルゴリズムが維持を必要とするとき、警告メッセージを送ることができるようにデータ・オブジェクトを格納したと主張するべきです。
4.5.2. Rationale
4.5.2. 原理
Individuals may wish to use the services of a commercial long-term service without disclosing data to the commercial service. However, access to the original data may be necessary to perform some preservation activities.
商業サービスにデータを明らかにしないで、個人は長期的に商業サービスのサービスを利用したがっているかもしれません。 しかしながら、オリジナルのデータへのアクセスが、いくつかの保存活動を実行するのに必要であるかもしれません。
4.6. Provide Means to Transfer Data and Evidence from One Service to
Another
4.6. 別のものに対する1つのサービスからデータと証拠を移す手段を提供してください。
4.6.1. Functional Requirements
4.6.1. 機能条件書
It must be possible to submit data along with previously generated evidence, i.e., to support transfer of data from one archive to another. A long-term archive service must support the transfer of archived data objects, evidence and evidence records from one service to another. It must be possible for evidence records to span multiple providers over the course of time, without losing value as evidence.
すなわち、1個のアーカイブから別のアーカイブまでのデータ転送を支持するために以前に発生している証拠に伴うデータを提出するのは可能であるに違いありません。 長期のアーカイブサービスは別のものに対する1つのサービスから格納されたデータ・オブジェクト、証拠、および証拠記録の転送を支持しなければなりません。 証拠記録が時間の過程の上で複数のプロバイダーにかかるのは、可能であるに違いありません、証拠として価値を失わないで。
4.6.2. Rationale
4.6.2. 原理
Before the end of an archived data object's archival period, a long- term archive service may cease operation. In such cases, it must be possible for the archived data object (and any associated evidence) to be transferred to another service that will continue preservation of the data until the end of the archival period.
格納されたデータ・オブジェクトの記録保管所の期間の終わりまでには、長い用語アーカイブサービスは操作をやめるかもしれません。 そのような場合、格納されたデータ・オブジェクト(そして、どんな関連証拠も)を記録保管所の期間の終わりまでデータの保存を続けている別のサービスに移すのは可能でなければなりません。
Submitters may change service providers before the end of an archived data object's archival period. In such cases, it must be possible for the submitter to transfer an archived data object and all associated evidence from the original LTA to a new LTA.
Submittersは格納されたデータ・オブジェクトの記録保管所の期間の終わりまでにサービスプロバイダーを変えるかもしれません。 そのような場合、submitterがオリジナルのLTAから新しいLTAまで格納されたデータ・オブジェクトとすべての関連証拠を移すのは、可能でなければなりません。
Wallace, et al. Informational [Page 11] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[11ページ]のRFC4810は2007年3月に要件を格納します。
4.7. Support Operations on Groups of Data Objects
4.7. データ・オブジェクトのグループで操作をサポートしてください。
4.7.1. Functional Requirements
4.7.1. 機能条件書
An LTA should support submission of groups of data objects. Submitters should be able to indicate which data objects belong together, i.e. comprise a group, and retrievers should be able to retrieve one, some or all members of a group of data objects.
LTAはデータ・オブジェクトのグループの提出をサポートするはずです。 すなわち、グループを包括して、Submittersは、どのデータ・オブジェクトがグループを成すかを示すことができるはずです、そして、レトリーバーは1つを検索できるべきです、データ・オブジェクトのグループのいくつかかすべてのメンバー。
It should be possible to provide evidence for groups of archived data objects. For example, it should be possible to archive a document file and a signature file together such that they are covered by the same evidence record.
格納されたデータ・オブジェクトのグループに関する証拠を提供するのは可能であるべきです。 例えば、ドキュメントファイルと署名ファイルを一緒に格納するのが可能であるべきであるので、それらは同じ証拠記録でカバーされています。
Where an LTA operates upon groups of data objects, non-repudiation proof must still be available for each archived data object separately.
LTAがデータ・オブジェクトのグループを経営するところでは、非拒否証拠は別々にまだそれぞれの格納されたデータ・オブジェクトに利用可能でなければなりません。
4.7.2. Rationale
4.7.2. 原理
In many cases data objects belong together. Examples include:
多くの場合、データ・オブジェクトはグループを成します。 例は:
- a document file and an associated signature file, which are two
separate objects
- ドキュメントファイルと関連署名ファイル。(その署名ファイルは2個の別々のオブジェクトです)。
- TIF-files representing pages of a document
- ドキュメントのページを表すTIF-ファイル
- a document file and an evidence file (possibly generated by
another LTA)
- ドキュメントファイルと証拠ファイル(ことによると別のLTAによって生成されます)
- a document and its translation to another format or language
- 別の形式か言語へのドキュメントとその翻訳
In these cases, it is to the best advantage to handle these data objects as a group.
これらの場合には、グループとしてこれらのデータ・オブジェクトを扱う最も良い利点にはそれがあります。
5. Operational Considerations
5. 操作上の問題
A long-term archive service must be able to work efficiently even for large amounts of archived data objects. In order to limit expenses and to achieve high performance, it may be desirable to minimize the use of trusted third parties, e.g., LTA operations should be designed to limit the number of time stamps required to provide the desired level of service.
長期のアーカイブサービスは多量の格納されたデータ・オブジェクトのためにさえ効率的に働くことができなければなりません。 費用を制限して、高性能を達成するために、信頼できる第三者機関の使用を最小にするのが望ましいかもしれない、例えば、LTA操作は必要なレベルのサービスを提供するのに必要であるタイムスタンプの数を制限するように設計されるべきです。
Necessity to access archived data objects should be minimized. It may only be necessary to access the archived data objects if the archived data objects are requested by users, or if hash algorithms used for indexing, or evidence record generation become insecure.
格納されたデータ・オブジェクトにアクセスする必要性は最小にされるべきです。 格納されたデータ・オブジェクトがユーザによって要求されているか、または索引をつけているか、証拠過去最高の世代に使用されるハッシュアルゴリズムが不安定になるなら、単に格納されたデータ・オブジェクトにアクセスするのが必要であるかもしれません。
Wallace, et al. Informational [Page 12] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[12ページ]のRFC4810は2007年3月に要件を格納します。
An LTA must be capable of operating in accordance with any applicable legal regime. For example, an LTA may be required to reject a deletion request from an authorized requestor if the target of the request has been subpoenaed by law enforcement authorities.
どんな適切な法的な政権に従っても、LTAは作動できなければなりません。 例えば、要求の目標が法執行当局によって召喚されたなら、LTAが、認可された要請者からの削除要求を拒絶するのに必要であるかもしれません。
Some applications may require processing of a chain of archive policies present in an evidence record, e.g., to ensure that compatible policies were used throughout the lifetime of the archived data objects.
いくつかのアプリケーションが、例えばコンパチブル方針が格納されたデータ・オブジェクトの生涯の間中使用されたのを保証するために証拠記録の現在のアーカイブ方針のチェーンを処理に要求するかもしれません。
6. Security Considerations
6. セキュリティ問題
Data is the principal asset protected by a long-term archive service. The principle threat that must be addressed by a long-term archive service is an undetected loss of data integrity.
データは長期のアーカイブサービスで保護された主要な資産です。 長期のアーカイブサービスで扱わなければならない原則的な脅威は非検出されたデータの喪失保全です。
In cases where signature verification relies on a PKI, certificate revocation could retroactively invalidate previously verified signatures. An LTA may implement measures to support such claims by an alleged signer, e.g., collection of revocation information after a grace period during which compromise can be reported or preservation of subsequent revocation information.
署名照合がPKIを当てにする場合では、証明書取消しは以前に確かめられた署名を遡及して無効にするかもしれません。 LTAはどの感染を報告できるか、そして、その後の取消し情報の保存の間、据置期間の後に申し立てられた署名者によるそのようなクレーム、例えば取消し情報の収集をサポートする政策を実施するかもしれません。
When selecting access control mechanisms associated with data stored by a LTA, the lifespan of the archived data object should be considered. For example, the credentials of an entity that submitted data to an archive may not be available or valid when the data needs to be retrieved.
LTAによって保存されるデータに関連しているアクセス管理機構を選択するとき、格納されたデータ・オブジェクトの寿命は考えられるべきです。 データが、検索される必要があるとき、例えば、アーカイブにデータを提出した実体の資格証明書は、利用可能であるか、または有効でないかもしれません。
During the lifespan of an archived data object, formats may cease to be supported. Software components to process data, including content or signatures, may no longer be available. This could be a problem particularly if non-standard formats are used or proprietary processing is employed. The submitter should take care to avoid such problems. For example, the submitter (or other authorized entity) could periodically retrieve data, convert the data, and re-submit it in a new format. Additional mechanisms, applications, or tools may be needed to preserve the value of evidence records associated with the original archived data object.
格納されたデータ・オブジェクトの寿命の間、形式は、サポートされるのをやめるかもしれません。 内容か署名を含んでいて、データを処理するソフトウェアコンポーネントはもう利用可能でないかもしれません。 特に標準的でない形式が使用されているなら、これは問題であるかもしれませんか独占処理が採用しています。 submitterは、そのような問題を避けるために注意されるはずです。例えば、submitter(または、他の権限のある機関)は定期的にデータを検索して、データを変換して、新しい形式でそれを再提出できました。 追加メカニズム、アプリケーション、またはツールが、オリジナルに関連している記録がデータ・オブジェクトを格納したという証拠の価値を守るのに必要であるかもしれません。
A long-term archive system may require correlation of different identities that represent the same entity at different points in time. For example, an individual's identity may be represented by different employers at different points in time.
長期のアーカイブシステムは時間内に異なったポイントで同じ実体を表す異なったアイデンティティの相関関係を必要とするかもしれません。 例えば、個人のアイデンティティは時間内に、異なったポイントで異なった雇い主によって表されるかもしれません。
A long-term archive system must perform maintenance activities on a schedule that considers factors such as the strength of relevant cryptographic algorithms, lifespan of relevant certification
長期のアーカイブシステムはそれが関連暗号アルゴリズムの強さなどの要素であると考えるスケジュールにメインテナンス活動を実行しなければなりません、関連証明の寿命
Wallace, et al. Informational [Page 13] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[13ページ]のRFC4810は2007年3月に要件を格納します。
authorities, and revocation status of relevant entities, e.g., timestamp authorities. Standards for use of cryptographic algorithms are expected to be established by organization or governmental bodies, not by individual LTAs.
当局、および関連実体、例えば、タイムスタンプ当局の取消し状態。 個々のLTAsによって設立されるのではなく、組織か政府のボディーによって暗号アルゴリズムの使用の規格が設立されると予想されます。
7. Acknowledgements
7. 承認
Thanks to members of the LTANS mailing list for review of earlier drafts and many suggestions. In particular, thanks to Larry Masinter, Denis Pinkas, and Peter Sylvester for review and suggestions.
以前の草稿と多くの提案のレビューのためのLTANSメーリングリストのメンバーをありがとうございます。 特に、レビューと提案のためにラリーMasinter、デニス・ピンカス、およびピーター・シルベスターをありがとうございます。
8. Informative References
8. 有益な参照
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[RFC3161] アダムス、C.、カイン、P.、ピンカス、D.、およびR.Zuccherato、「インターネットX.509公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)」、RFC3161(2001年8月)。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
November 2003.
[RFC3647] Chokhani、S.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、「インターネットX.509公開鍵暗号基盤証明書方針と証明はフレームワークを練習します」、RFC3647、2003年11月。
Wallace, et al. Informational [Page 14] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[14ページ]のRFC4810は2007年3月に要件を格納します。
Appendix A. Application Scenarios
付録A.アプリケーションシナリオ
Below are several example application scenarios demonstrating one or more of the basic service features mentioned above.
以下に、前記のように基本サービス機能の1つ以上を示すいくつかの例のアプリケーションシナリオがあります。
A.1. Archive Service Supporting Long-Term Non-Repudiation
A.1。 長期の非拒否をサポートするアーカイブサービス
A long-term archive service may store data objects, such as signed or unsigned documents, for authenticated users. It may generate time stamps for these data objects and obtain verification data during the archival period or until a deletion request is received from an authorized entity.
長期のアーカイブサービスは認証されたユーザのために署名されるようなデータ・オブジェクトか未署名のドキュメントを保存するかもしれません。 それは、記録保管所の期間か権限のある機関から削除要求を受け取るまでこれらのデータ・オブジェクトのために時間がスタンプであると生成して、検証データを得るかもしれません。
A.2. Pure Long-Term Non-Repudiation Service
A.2。 純粋な長期の非拒否サービス
A long-term archive service may only guarantee non-repudiation of existence of data by periodically generating time stamps and obtaining verification data. It stores data objects (e.g., documents and signatures) locally only for the purpose of non-repudiation and does not function as a document archive for users. It does not support retrieval and deletion of data objects.
長期のアーカイブサービスは、時間がスタンプであると生成して、検証データを得ながら、定期的でデータの存在の非拒否を保証するだけであるかもしれません。 それは、非拒否の目的のためだけに、局所的に、データ・オブジェクト(例えば、ドキュメントと署名)を保存して、ユーザのためにドキュメントアーカイブとして機能しません。 それはデータ・オブジェクトの検索と削除をサポートしません。
A.3. Long-Term Archive Service as Part of an Internal Network
A.3。 内部のネットワークの一部としての長期のアーカイブサービス
A long-term archive service may be part of an enterprise network. The network provider and archive service may be part of the same institution. In this case, the service should obtain non-repudiation evidence from a third party. An internally generated acknowledgement may be viewed worthless.
長期のアーカイブサービスは企業網の一部であるかもしれません。 ネットワーク内の提供者とアーカイブサービスは同じ団体の一部であるかもしれません。 この場合、サービスは第三者から非拒否証拠を得るべきです。 内部的に生成している承認は価値がない状態で見られるかもしれません。
A.4. Long-Term Archive External Service
A.4。 長期のアーカイブ外部サービス
A long-term archive service may be provided over the Internet for enterprises or consumers. In this case, archiving and providing evidence (via time stamps or other means) may be adduced by one organization and its own technical infrastructure, without using external services.
企業か消費者のために長期のアーカイブサービスをインターネットの上に提供するかもしれません。 この場合、1つの組織とそれ自身の技術インフラで証拠(タイムスタンプか他の手段を通した)を格納して、提供するのを提出するかもしれません、外部サービスを使用しないで。
Wallace, et al. Informational [Page 15] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[15ページ]のRFC4810は2007年3月に要件を格納します。
Authors' Addresses
作者のアドレス
Carl Wallace Cygnacom Solutions Suite 5200 7925 Jones Branch Drive McLean, VA 22102
スイート5200 7925ジョーンズ支店のDriveマクリーン、カールウォレスCygnacom Solutionsヴァージニア 22102
Fax: +1(703)848-0960 EMail: cwallace@cygnacom.com
Fax: +1 (703) 848-0960 メールしてください: cwallace@cygnacom.com
Ulrich Pordesch Fraunhofer Gesellschaft Rheinstrasse 75 Darmstadt, Germany D-64295
ダルムシュタット、ユーリッヒPordeschフラウンホーファー利益社会Rheinstrasse75ドイツD-64295
EMail: ulrich.pordesch@zv.fraunhofer.de
メール: ulrich.pordesch@zv.fraunhofer.de
Ralf Brandner InterComponentWare AG Otto-Hahn-Strabe 3 Walldorf, Germany 69190
ラルフBrandner InterComponentWare株式会社オットーハーンStrabe3Walldorf、ドイツ69190
EMail: ralf.brandner@intercomponentware.com
メール: ralf.brandner@intercomponentware.com
Wallace, et al. Informational [Page 16] RFC 4810 Archive Requirements March 2007
ウォレス、他 情報[16ページ]のRFC4810は2007年3月に要件を格納します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Wallace, et al. Informational [Page 17]
ウォレス、他 情報[17ページ]
一覧
スポンサーリンク
