RFC4998 日本語訳

4998 Evidence Record Syntax (ERS). T. Gondrom, R. Brandner, U.Pordesch. August 2007. (Format: TXT=66888 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         T. Gondrom
Request for Comments: 4998                         Open Text Corporation
Category: Standards Track                                    R. Brandner
                                                   InterComponentWare AG
                                                             U. Pordesch
                                                 Fraunhofer Gesellschaft
                                                             August 2007

Gondromがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4998年のオープンテキスト社のカテゴリ: 標準化過程R.Brandner InterComponentWare株式会社U.Pordeschフラウンホーファー利益社会2007年8月

                      Evidence Record Syntax (ERS)

記録的な構文を証明してください。(ERS)

Status of This Memo

このメモの状態

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

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   In many scenarios, users must be able prove the existence and
   integrity of data, including digitally signed data, in a common and
   reproducible way over a long and possibly undetermined period of
   time.  This document specifies the syntax and processing of an
   Evidence Record, a structure designed to support long-term non-
   repudiation of existence of data.

多くのシナリオでは、ユーザは存在とデータの完全性を立証して、デジタルにサインされたデータを含むのにおいてできるに違いありません、長くてことによると非決定した期間の間の一般的で再現可能な方法で。 このドキュメントはEvidence Record(データの存在の長期の非拒否を支持するように設計された構造)の構文と処理を指定します。

Gondrom, et al.             Standards Track                     [Page 1]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[1ページ]。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  General Overview and Requirements  . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.4.  Conventions Used in This Document  . . . . . . . . . . . .  6
   2.  Identification and References  . . . . . . . . . . . . . . . .  7
     2.1.  ASN.1 Module Definition  . . . . . . . . . . . . . . . . .  7
       2.1.1.  ASN.1 Module Definition for 1988 ASN.1 Syntax  . . . .  7
       2.1.2.  ASN.1 Module Definition for 1997-ASN.1 Syntax  . . . .  7
     2.2.  ASN.1 Imports and Exports  . . . . . . . . . . . . . . . .  7
       2.2.1.  Imports and Exports Conform with 1988 ASN.1  . . . . .  8
       2.2.2.  Imports and Exports Conform with 1997-ASN.1  . . . . .  8
     2.3.  LTANS Identification . . . . . . . . . . . . . . . . . . .  9
   3.  Evidence Record  . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Generation . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Verification . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Archive Timestamp  . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Generation . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.3.  Verification . . . . . . . . . . . . . . . . . . . . . . . 15
   5.  Archive Timestamp Chain and Archive Timestamp Sequence . . . . 16
     5.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.2.  Generation . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.3.  Verification . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 21
       6.1.1.  EncryptionInfo in 1988 ASN.1 . . . . . . . . . . . . . 21
       6.1.2.  EncryptionInfo in 1997-ASN.1 . . . . . . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Appendix A.  Evidence Record Using CMS . . . . . . . . . . . . . . 26
   Appendix B.  ASN.1-Module with 1988 Syntax . . . . . . . . . . . . 27
   Appendix C.  ASN.1-Module with 1997 Syntax . . . . . . . . . . . . 29

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 動機. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 概要と要件. . . . . . . . . . . . 4 1.3。 用語. . . . . . . . . . . . . . . . . . . . . . . 5 1.4。 コンベンションは本書では.6 2を使用しました。 識別と参照. . . . . . . . . . . . . . . . 7 2.1。 ASN.1モジュール定義. . . . . . . . . . . . . . . . . 7 2.1.1。 1988ASN.1構文. . . . 7 2.1.2のためのASN.1モジュール定義。 1997-ASN.1構文. . . . 7 2.2のためのASN.1モジュール定義。 ASN.1は.1に.72.2を輸入して、輸出します。 輸入と輸出は2.2に.2に1988ASN.1…8に従います。 輸入と輸出は2.3に1997-ASN.1…8に従います。 LTANS識別. . . . . . . . . . . . . . . . . . . 9 3。 記録. . . . . . . . . . . . . . . . . . . . . . . 9 3.1を証明してください。 構文. . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2。 世代. . . . . . . . . . . . . . . . . . . . . . . . 10 3.3。 検証. . . . . . . . . . . . . . . . . . . . . . . 11 4。 タイムスタンプ. . . . . . . . . . . . . . . . . . . . . . 11 4.1を格納してください。 構文. . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2。 世代. . . . . . . . . . . . . . . . . . . . . . . . 12 4.3。 検証. . . . . . . . . . . . . . . . . . . . . . . 15 5。 タイムスタンプチェーンとアーカイブタイムスタンプ系列. . . . 16 5.1を格納してください。 構文. . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2。 世代. . . . . . . . . . . . . . . . . . . . . . . . 17 5.3。 検証. . . . . . . . . . . . . . . . . . . . . . . 19 6。 暗号化. . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1。 構文. . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1.1。 1988ASN.1のEncryptionInfo… 21 6.1 .2。 1997-ASN.1のEncryptionInfo… 22 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 22 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 23 8.2。 1997年の構文. . . . . . . . . . . . 29で1988年の構文. . . . . . . . . . . . 27付録C.ASN.1-モジュールがあるcm. . . . . . . . . . . . . . 26付録B.ASN.1-モジュールを使用する有益な参照. . . . . . . . . . . . . . . . . . 24付録A.証拠記録

Gondrom, et al.             Standards Track                     [Page 2]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[2ページ]。

1.  Introduction

1. 序論

1.1.  Motivation

1.1. 動機

   In many application areas of electronic data exchange, a non-
   repudiable proof of the existence of digital data must be possible.
   In some cases, this proof must survive the passage of long periods of
   time.  An important example is digitally signed data.  Digital
   signatures can be used to demonstrate data integrity and to perform
   source authentication.  In some cases, digitally signed data must be
   archived for 30 years or more.  However, the reliability of digital
   signatures over long periods is not absolute.  During the archival
   period, hash algorithms and public key algorithms can become weak or
   certificates can become invalid.  These events complicate the
   reliance on digitally signed data after many years by increasing the
   likelihood that forgeries can be created.  To avoid losing the
   desired security properties derived from digital signatures, it is
   necessary to prove that the digitally signed data already existed
   before such a critical event.  This can be accomplished using a
   timestamp.  However, some timestamps rely upon mechanisms that will
   be subject to the same problems.  To counter this problem, timestamps
   are renewed by simply obtaining a new timestamp that covers the
   original data and its timestamps prior to the compromise of
   mechanisms used to generate the timestamps.  This document provides a
   syntax to support the periodic renewal of timestamps.

オンラインデータ交換の多くの応用分野では、ディジタルデータの存在の非repudiableな証拠が可能であるに違いありません。 いくつかの場合、この証拠は長期間の通路を乗り切らなければなりません。 重要な例はデジタルにサインされたデータです。 データ保全を示して、ソース認証を実行するのにデジタル署名を使用できます。 いくつかの場合、30年間以上デジタルにサインされたデータを格納しなければなりません。 しかしながら、長期の間のデジタル署名の信頼性は絶対ではありません。 記録保管所の期間、細切れ肉料理アルゴリズムと公開鍵アルゴリズムが弱くなることができますか、または証明書は無効になることができます。 これらの出来事は、長い年月を経て偽造を作成できる可能性を広げることによって、デジタルにサインされたデータへの信用を複雑にします。 デジタル署名から得られた必要なセキュリティ資産をなくすのを避けるために、デジタルにサインされたデータがそのような批判的なイベントの前に既に存在したと立証するのが必要です。 タイムスタンプを使用することでこれを達成できます。 しかしながら、いくつかのタイムスタンプが同じ問題を被りやすくなるメカニズムを当てにします。この問題を打ち返すために、タイムスタンプは単にタイムスタンプを発生させるのに使用されるメカニズムの妥協の前にオリジナルのデータとそのタイムスタンプを含んでいる新しいタイムスタンプを得ることによって、更新されます。 このドキュメントは、タイムスタンプの周期的な更新を支持するために構文を提供します。

   It is necessary to standardize the data formats and processing
   procedures for such timestamps in order to be able to verify and
   communicate preservation evidence.  A first approach was made by IETF
   within [RFC3126], where an optional Archive Timestamp Attribute was
   specified for integration in signatures according to the
   Cryptographic Messages Syntax (CMS) [RFC3852].

そのようなタイムスタンプのためにデータ形式と現像処理を標準化するのが、保存証拠を確かめて、伝えることができるように必要です。 最初のアプローチは[RFC3126]の中でIETFによってされました。そこでは、Cryptographic Messages Syntax(CMS)[RFC3852]によると、任意のアーカイブTimestamp Attributeが署名における統合に指定されました。

   Evidence Record Syntax (ERS) broadens and generalizes this approach
   for data of any format and takes long-term archive service
   requirements [RFC4810] into account -- in particular, the handling of
   large sets of data objects.  ERS specifies a syntax for an
   EvidenceRecord, which contains a set of Archive Timestamps and some
   additional data.  This Evidence Record can be stored separately from
   the archived data, as a file, or integrated into the archived data,
   i.e., as an attribute.  ERS also specifies processes for generation
   and verification of Evidence Records.  Appendix A describes the
   integration and use of an EvidenceRecord in context of signed and
   enveloped messages according to the Cryptographic Message Syntax
   (CMS).  ERS does not specify a protocol for interacting with a long-
   term archive system.  The Long-term Archive Protocol specification
   being developed by the IETF LTANS WG addresses this interface.

アカウントによる証拠Record Syntax(ERS)のためにどんな形式に関するデータのためにもこのアプローチを広くして、一般化して、長期のアーカイブサービス要件[RFC4810]は特に取ります、大きいデータ・オブジェクトの取り扱い。 ERSはEvidenceRecordに構文を指定します。(EvidenceRecordはアーカイブTimestampsといくつかの追加データの1セットを含みます)。 このEvidence Recordを別々にファイルとして格納されたデータから格納するか、または格納されたデータと統合できます、すなわち、属性として。 また、ERSはEvidence Recordsの世代と検証のための過程を指定します。 Cryptographic Message Syntax(CMS)に従って、付録Aは状況内においてサインされておおわれたメッセージのEvidenceRecordの統合と使用について説明します。 ERSは長い用語アーカイブシステムと対話するのにプロトコルを指定しません。 IETF LTANS WGによって開発されるLong-用語アーカイブプロトコル仕様はこのインタフェースを記述します。

Gondrom, et al.             Standards Track                     [Page 3]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[3ページ]。

1.2.  General Overview and Requirements

1.2. 概要と要件

   ERS is designed to meet the requirements for data structures set
   forth in [RFC4810].

ERSは、[RFC4810]に詳しく説明されたデータ構造のために条件を満たすように設計されています。

   The basis of the ERS are Archive Timestamps, which can cover a single
   data object (as an RFC3161 compliant timestamp does) or can cover a
   group of data objects.  Groups of data objects are addressed using
   hash trees, first described by Merkle [MER1980], combined with a
   timestamp.  The leaves of the hash tree are hash values of the data
   objects in a group.  A timestamp is requested only for the root hash
   of the hash tree.  The deletion of a data object in the tree does not
   influence the provability of others.  For any particular data object,
   the hash tree can be reduced to a few sets of hash values, which are
   sufficient to prove the existence of a single data object.
   Similarly, the hash tree can be reduced to prove existence of a data
   group, provided all members of the data group have the same parent
   node in the hash tree.  Archive Timestamps are comprised of an
   optional reduced hash tree and a timestamp.

ERSの基礎はアーカイブTimestampsです。(そのTimestampsは単一のデータ・オブジェクト(対応するタイムスタンプがするRFC3161としての)を覆うことができるか、またはデータ・オブジェクトのグループをカバーできます)。 最初にMerkle[MER1980]によって説明された木がタイムスタンプに混ぜた細切れ肉料理を使用することでデータ・オブジェクトのグループは演説されます。 細切れ肉料理木の葉はグループで、データ・オブジェクトのハッシュ値です。 タイムスタンプは細切れ肉料理木の根の細切れ肉料理のためだけに要求されています。 木でのデータ・オブジェクトの削除は他のもののprovabilityに影響を及ぼしません。 どんな特定のデータ・オブジェクトに関してはも、細切れ肉料理木は数セットのハッシュ値に減少できます。(ハッシュ値は単一のデータ・オブジェクトの存在を立証できます)。 同様に、細切れ肉料理木はデータグループの存在を立証するために減少できます、データグループのすべてのメンバーが細切れ肉料理木に同じ親ノードを持っているなら。 アーカイブTimestampsは任意の減少している細切れ肉料理木とタイムスタンプから成ります。

   An EvidenceRecord may contain many Archive Timestamps.  For the
   generation of the initial Archive Timestamp, the data objects to be
   timestamped have to be determined.  Depending on the context, this
   could be a file or a data object group consisting of multiple files,
   such as a document and its associated digital signature.

EvidenceRecordは多くのアーカイブTimestampsを含むかもしれません。 初期のアーカイブTimestampの世代において、timestampedされるべきデータ・オブジェクトは断固としていなければなりません。 文脈によって、これは、複数のファイルから成るファイルかデータ・オブジェクトグループであるかもしれません、ドキュメントやその関連デジタル署名のように。

   Before the cryptographic algorithms used within the Archive Timestamp
   become weak or timestamp certificates become invalid, Archive
   Timestamps have to be renewed by generating a new Archive Timestamp.
   (Note: Information about the weakening of the security properties of
   public key and hash algorithms, as well as the risk of compromise of
   private keys of Time Stamping Units, has to be closely watched by the
   Long-Term Archive provider or the owner of the data objects himself.
   This information should be gathered by "out-of-band" means and is out
   of scope of this document.)  ERS distinguishes two ways for renewal
   of an Archive Timestamp: Timestamp Renewal and Hash-Tree Renewal.

アーカイブTimestampの中で使用された暗号アルゴリズムが弱くなるか、またはタイムスタンプ証明書が無効になる前に、アーカイブTimestampsは、新しいアーカイブTimestampを発生させることによって、取り替えられなければなりません。 (以下に注意してください。 公開鍵と細切れ肉料理アルゴリズムのセキュリティの特性の弱化、およびTime Stamping Unitsの秘密鍵の妥協のリスクに関する情報はLong-用語アーカイブプロバイダーかデータ・オブジェクトの所有者自身によって密接に見られなければなりません。 この情報は、「バンドの外」による集まっている手段であるべきであり、このドキュメントの範囲の外にあります。) ERSはアーカイブTimestampの更新のための2つの方法を区別します: タイムスタンプ更新と細切れ肉料理木の更新。

   Depending on the conditions, the respective type of renewal is
   required: The timestamp renewal is necessary if the private key of a
   Timestamping Unit has been compromised, or if an asymmetric algorithm
   or a hash algorithm used for the generation of the timestamps is no
   longer secure for the given key size.  If the hash algorithm used to
   build the hash trees in the Archive Timestamp loses its security
   properties, the Hash-Tree Renewal is required.

条件によって、それぞれのタイプの更新が必要です: Timestamping Unitの秘密鍵が妥協して、与えられた主要なサイズには、タイムスタンプの世代に使用される非対称のアルゴリズムか細切れ肉料理アルゴリズムがもう安全でないなら、タイムスタンプ更新が必要です。 アーカイブTimestampに細切れ肉料理木を建てるのに使用される細切れ肉料理アルゴリズムがセキュリティの特性をなくすなら、Hash-木のRenewalが必要です。

   In the case of Timestamp Renewal, the timestamp of an Archive
   Timestamp has to be hashed and timestamped by a new Archive
   Timestamp.  This mode of renewal can only be used when it is not

Timestamp Renewalの場合では、アーカイブTimestampに関するタイムスタンプは、新しいアーカイブTimestampによって論じ尽くされて、timestampedされなければなりません。 それが使用されないときだけ、更新のこの方法を使用できます。

Gondrom, et al.             Standards Track                     [Page 4]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[4ページ]。

   necessary to access the archived data objects covered by the
   timestamp.  For example, this simple form of renewal is sufficient if
   the public key algorithm of the timestamp is going to lose its
   security or the timestamp authority certificate is about to expire.
   This is very efficient, in particular, if Archive Timestamping is
   done by an archiving system or service, which implements a central
   management of Archive Timestamps.

タイムスタンプで覆われた格納されたデータ・オブジェクトにアクセスするために、必要です。 例えば、タイムスタンプの公開鍵アルゴリズムがセキュリティを失おうとしているだろうか、またはタイムスタンプ権威証明書が期限が切れようとしているなら、この単純形の更新は十分です。 これは非常に効率的です、特に、格納システムかサービス(アーカイブTimestampsの主要な管理を実行する)でアーカイブTimestampingをするなら。

   Timestamp renewal is not sufficient if the hash algorithm used to
   build the hash tree of an Archive Timestamp becomes insecure.  In the
   case of Hash-Tree Renewal, all evidence data must be accessed and
   timestamped.  This includes not only the timestamps but also the
   complete Archive Timestamps and the archived data objects covered by
   the timestamps, which must be hashed and timestamped again by a new
   Archive Timestamp.

アーカイブTimestampの細切れ肉料理木を建てるのに使用される細切れ肉料理アルゴリズムが不安定になるなら、タイムスタンプ更新は十分ではありません。 Hash-木のRenewalの場合では、すべての証拠データにアクセスされて、timestampedしなければなりません。 これはタイムスタンプだけではなく、新しいアーカイブTimestampによって論じ尽くさなければならないタイムスタンプで覆われて、再びtimestampedされた完全なアーカイブTimestampsと格納されたデータ・オブジェクトも含んでいます。

1.3.  Terminology

1.3. 用語

   Archived data object: A data unit that is archived and has to be
   preserved for a long time by the Long-term Archive Service.

格納されたデータ・オブジェクト: それは、データ単位、格納されて、長い間、Long-用語アーカイブServiceによって保存されなければなりません。

   Archived data object group: A set of two or more of data objects,
   which for some reason belong together.  For example, a document file
   and a signature file could be an archived data object group, which
   represent signed data.

格納されたデータ物は分類されます: 1セットの2個以上のデータ・オブジェクト。(そのデータ・オブジェクトはある理由でグループを成します)。 例えば、ドキュメントファイルと署名ファイルは格納されたデータ・オブジェクトグループであるかもしれません。(そのグループはサインされたデータを表します)。

   Archive Timestamp: A timestamp and typically lists of hash values,
   which allow the verification of the existence of several data objects
   at a certain time.  (In its most simple variant, when it covers only
   one object, it may only consist of the timestamp.)

タイムスタンプを格納してください: ハッシュ値のタイムスタンプと通常リスト。(ハッシュ値は一定の時刻に数個のデータ・オブジェクトの存在の検証を許します)。 (1個の物だけについて言及するときだけ、最も簡単な異形では、それはタイムスタンプから成るかもしれません。)

   Archive Timestamp Chain: Part of an Archive Timestamp Sequence, it is
   a time-ordered sequence of Archive Timestamps, where each Archive
   Timestamp preserves non-repudiation of the previous Archive
   Timestamp, even after the previous Archive Timestamp becomes invalid.
   Overall non-repudiation is maintained until the new Archive Timestamp
   itself becomes invalid.  The process of generating such an Archive
   Timestamp Chain is called Timestamp Renewal.

タイムスタンプチェーンを格納してください: アーカイブTimestamp Sequenceの一部、それはアーカイブTimestampsの時間で規則正しい系列です、前のアーカイブTimestampが無効になった後にさえ。(そこでは、それぞれのアーカイブTimestampが前のアーカイブTimestampの非拒否を保存します)。 新しいアーカイブTimestamp自身が無効になるまで、総合的な非拒否は維持されます。 そのようなアーカイブTimestamp Chainを発生させる過程はTimestamp Renewalと呼ばれます。

   Archive Timestamp Sequence: Part of the Evidence Record, it is a
   sequence of Archive Timestamp Chains, where each Archive Timestamp
   Chain preserves non-repudiation of the previous Archive Timestamp
   Chains, even after the hash algorithm used within the previous
   Archive Timestamp's hash tree became weak.  Non-repudiation is
   preserved until the last Archive Timestamp of the last chain becomes
   invalid.  The process of generating such an Archive Timestamp
   Sequence is called Hash-Tree Renewal.

タイムスタンプ系列を格納してください: Evidence Recordの一部、それはアーカイブTimestampチェインズの系列です、前のアーカイブTimestampの細切れ肉料理木の中で使用された細切れ肉料理アルゴリズムが弱くなった後にさえ。そこでは、それぞれのアーカイブTimestamp Chainが前のアーカイブTimestampチェインズの非拒否を保存します。 最後のチェーンの最後のアーカイブTimestampが無効になるまで、非拒否は保存されます。 そのようなアーカイブTimestamp Sequenceを発生させる過程はHash-木のRenewalと呼ばれます。

Gondrom, et al.             Standards Track                     [Page 5]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[5ページ]。

   Evidence: Information that may be used to resolve a dispute about
   various aspects of authenticity of archived data objects.

証拠: 格納されたデータ・オブジェクトの信憑性の種々相で争議を解決するのに使用されるかもしれない情報。

   Evidence record: Collection of evidence compiled for one or more
   given archived data objects over time.  An evidence record includes
   all Archive Timestamps (within structures of Archive Timestamp Chains
   and Archive Timestamp Sequences) and additional verification data,
   like certificates, revocation information, trust anchors, policy
   details, role information, etc.

記録を証明してください: 1のためにコンパイルされるか、またはもう少し与えられた形跡の収集は時間がたつにつれて、データ・オブジェクトを格納しました。 証拠記録はすべてのアーカイブTimestamps(アーカイブTimestampチェインズとアーカイブTimestamp Sequencesの構造の中の)と追加検証データを含んでいます、証明書、取消し情報、信用アンカー、方針の詳細、役割の情報などのように

   Long-term Archive (LTA) Service: A service responsible for preserving
   data for long periods of time, including generation and collection of
   evidence, storage of archived data objects and evidence, etc.

長期のアーカイブ(LTA)サービス: 世代を含む長期間の間のデータと証拠、格納されたデータ・オブジェクトと証拠の格納などの収集を保存するのに原因となるサービス

   Reduced hash tree: The process of reducing a Merkle hash tree
   [MER1980] to a list of lists of hash values.  This is the basis of
   storing the evidence for a single data object.

減少している細切れ肉料理木: Merkle細切れ肉料理木[MER1980]をハッシュ値のリストのリストに減少させる過程。 これは単一のデータ・オブジェクトに関する証拠を格納する基礎です。

   Timestamp: A cryptographically secure confirmation generated by a
   Time Stamping Authority (TSA).  [RFC3161] specifies a structure for
   timestamps and a protocol for communicating with a TSA.  Besides
   this, other data structures and protocols may also be appropriate,
   e.g., such as defined in [ISO-18014-1.2002], [ISO-18014-2.2002],
   [ISO-18014-3.2004], and [ANSI.X9-95.2005].

タイムスタンプ: Aは暗号でTime Stamping Authority(TSA)によって発生した確認を保証します。 [RFC3161]はTSAとコミュニケートするとタイムスタンプとプロトコルに構造を指定します。 また、この他、他のデータ構造とプロトコルも適切であるかもしれません、例えば、[ISO-18014-1.2002]、[ISO-18014-2.2002]、[ISO-18014-3.2004]、および[ANSI.X9-95.2005]で定義されるように。

   An Archive Timestamp relates to a data object, if the hash value of
   this data object is part of the first hash value list of the Archive
   Timestamp.  An Archive Timestamp relates to a data object group, if
   it relates to every data object of the group and no other data
   objects.  An Archive Timestamp Chain relates to a data object / data
   object group, if its first Archive Timestamp relates to this data
   object/data object group.  An Archive Timestamp Sequence relates to a
   data object / data object group, if its first Archive Timestamp Chain
   relates to this data object/data object group.

アーカイブTimestampはデータ・オブジェクトに関連します、このデータ・オブジェクトのハッシュ値がアーカイブTimestampの最初のハッシュ値リストの一部であるなら。 アーカイブTimestampはデータ・オブジェクトグループに関連します、グループのあらゆるデータ・オブジェクトに関連しますが、他のどんなデータ・オブジェクトも関連しないなら。 アーカイブTimestamp Chainはデータ・オブジェクト/データ・オブジェクトグループに関連します、最初のアーカイブTimestampがこのデータ・オブジェクト/データ・オブジェクトグループに関連するなら。 アーカイブTimestamp Sequenceはデータ・オブジェクト/データ・オブジェクトグループに関連します、最初のアーカイブTimestamp Chainがこのデータ・オブジェクト/データ・オブジェクトグループに関連するなら。

1.4.  Conventions Used in This Document

1.4. 本書では使用されるコンベンション

   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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Gondrom, et al.             Standards Track                     [Page 6]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[6ページ]。

2.  Identification and References

2. 識別と参照

2.1.  ASN.1 Module Definition

2.1. ASN.1モジュール定義

   As many open ASN.1 compilers still support the 1988 syntax, this
   standard offers to support two versions of ASN.1 1997-ASN.1 and 1988-
   ASN.1.  (For specification of ASN.1 refer to [CCITT.X208.1988],
   [CCITT.X209.1988], [CCITT.X680.2002] and [CCITT.X690.2002].)  This
   specification defines the two ASN.1 modules, one for 1988 conform
   ASN.1 and another in 1997-ASN.1 syntax.  Depending on the syntax
   version of your compiler implementation, you can use the imports for
   the 1988 conformant ASN.1 syntax or the imports for the 1997-ASN.1
   syntax.  The appendix of this document lists the two complete
   alternative ASN.1 modules.  If there is a conflict between both
   modules, the 1988-ASN.1 module precedes.

多くの開いているASN.1コンパイラがまだ1988年の構文をサポートしているとき、この規格は、ASN.1 1997-ASN.1と1988ASN.1の2つのバージョンを支持すると申し出ます。 (ASN.1の仕様について、[CCITT.X208.1988]、[CCITT.X209.1988]、[CCITT.X680.2002]、および[CCITT.X690.2002]を参照してください。) この仕様は2つのASN.1モジュールを定義して、1988年の1つは1997-ASN.1構文でASN.1と別のものを従わせます。 あなたのコンパイラ実現の構文バージョンによって、あなたは1988年のconformant ASN.1構文のための輸入か1997-ASN.1構文のための輸入を使用できます。 このドキュメントの付録は2の完全な代替のASN.1モジュールを記載します。 両方のモジュールの間には、闘争があれば、1988-ASN.1モジュールは先行します。

2.1.1.  ASN.1 Module Definition for 1988 ASN.1 Syntax

2.1.1. 1988ASN.1構文のためのASN.1モジュール定義

   1988 ASN.1 Module start

1988ASN.1Moduleは始まります。

   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) }
   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

ERSのiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)ltans(11)イドモッズ風の(0)イド-mod-ers88(2)イド-mod-ers88-v1(1)、DEFINITIONS IMPLICIT TAGS:、:= 始まってください。

2.1.2.  ASN.1 Module Definition for 1997-ASN.1 Syntax

2.1.2. 1997-ASN.1構文のためのASN.1モジュール定義

   ASN.1 Module start

ASN.1Moduleは始まります。

   ERS {iso(1) identified-organization(3) dod(6)
         internet(1) security(5) mechanisms(5)
         ltans(11) id-mod(0) id-mod-ers(1) id-mod-ers-v1(1) }
   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

ERS、iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)ltans(11)イドモッズ(0)イドモダー(1)イドモッズers-v1(1)、DEFINITIONS IMPLICIT TAGS:、:= 始まってください。

2.2.  ASN.1 Imports and Exports

2.2. ASN.1輸入と輸出

   The specification exports all definitions and imports various
   definitions.  Depending on the ASN.1 syntax version of your
   implementation, you can use the imports for the 1988 conform ASN.1
   syntax below or the imports for the 1997-ASN.1 syntax in
   Section 2.2.2.

仕様は、すべての定義を輸出して、様々な定義を意味します。 あなたの実現のASN.1構文バージョンによって、あなたは1988年の輸入がASN.1構文を従わせる使用か1997-ASN.1構文のためのセクション2.2.2における輸入を依存できます。

Gondrom, et al.             Standards Track                     [Page 7]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[7ページ]。

2.2.1.  Imports and Exports Conform with 1988 ASN.1

2.2.1. 輸入と輸出は1988ASN.1に従います。

   -- EXPORTS ALL --

-- すべてを輸出します--

   IMPORTS

輸入

    -- Imports from RFC 3852 Cryptographic Message Syntax
   ContentInfo, Attribute
       FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

-- RFC3852の暗号のメッセージから、CryptographicMessageSyntax2004、[RFC3852]から構文ContentInfo、属性を輸入します。iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)

     -- Imports from RFC 3280 [RFC3280], Appendix A.1
   AlgorithmIdentifier
       FROM PKIX1Explicit88
           { iso(1) identified-organization(3) dod(6)
           internet(1) security(5) mechanisms(5) pkix(7)
           mod(0) pkix1-explicit(18) }
   ;

-- RFC3280[RFC3280]からの輸入、Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)モッズ(0)pkix1明白な(18)。

2.2.2.  Imports and Exports Conform with 1997-ASN.1

2.2.2. 輸入と輸出は1997-ASN.1に従います。

   -- EXPORTS ALL --

-- すべてを輸出します--

   IMPORTS

輸入

    -- Imports from PKCS-7
   ContentInfo
       FROM PKCS7
           {iso(1) member-body(2) us(840) rsadsi(113549)
           pkcs(1) pkcs-7(7) modules(0)}

-- PKCS7からのPKCS-7 ContentInfoからの輸入iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-7(7)モジュール(0)

     -- Imports from AuthenticationFramework
   AlgorithmIdentifier
       FROM AuthenticationFramework
           {joint-iso-itu-t ds(5) module(1)
           authenticationFramework(7) 4}

-- AuthenticationFrameworkからのAuthenticationFramework AlgorithmIdentifierからの輸入共同iso-itu t ds(5)モジュール(1)authenticationFramework(7)4

    -- Imports from InformationFramework
   Attribute
       FROM InformationFramework
           {joint-iso-itu-t ds(5) module(1)
           informationFramework(1) 4}
   ;

-- InformationFramework Attribute FROM InformationFramework共同iso-itu t ds(5)モジュール(1)informationFramework(1)4からの輸入。

Gondrom, et al.             Standards Track                     [Page 8]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[8ページ]。

2.3.  LTANS Identification

2.3. LTANS識別

   This document defines the LTANS object identifier tree root.

このドキュメントはLTANS物の識別子木の根を定義します。

   LTANS Object Identifier tree root

LTANS Object Identifier木の根

   ltans OBJECT IDENTIFIER ::=
            { iso(1) identified-organization(3) dod(6) internet(1)
              security(5) mechanisms(5) ltans(11) }

ltans OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)ltans(11)

3.  Evidence Record

3. 証拠記録

   An Evidence Record is a unit of data, which can be used to prove the
   existence of an archived data object or an archived data object group
   at a certain time.  The Evidence Record contains Archive Timestamps,
   generated during a long archival period and possibly useful data for
   validation.  It is possible to store this Evidence Record separately
   from the archived data objects or to integrate it into the data
   itself.  For data types, signed data and enveloped data of the CMS
   integration are specified in Appendix A.

Evidence Recordはデータのユニットです。(一定の時刻に格納されたデータ・オブジェクトか格納されたデータ・オブジェクトグループの存在を立証するのにデータを使用できます)。 Evidence Recordは合法化のための長い記録保管所の期間とことによると役に立つデータの間に発生するアーカイブTimestampsを含んでいます。 別々に格納されたデータ・オブジェクトでこのEvidence Recordを格納するか、またはそれをデータ自体と統合するのが可能です。 データ型として、CMS統合のサインされたデータとおおわれたデータはAppendix Aで指定されます。

3.1.  Syntax

3.1. 構文

   Evidence Record has the following ASN.1 Syntax:

証拠Recordには、以下のASN.1Syntaxがあります:

   ASN.1 Evidence Record

ASN.1証拠記録

   EvidenceRecord ::= SEQUENCE {
      version                   INTEGER { v1(1) } ,
      digestAlgorithms          SEQUENCE OF AlgorithmIdentifier,
      cryptoInfos               [0] CryptoInfos OPTIONAL,
      encryptionInfo            [1] EncryptionInfo OPTIONAL,
      archiveTimeStampSequence  ArchiveTimeStampSequence
      }

EvidenceRecord:、:= 系列バージョンINTEGER v1(1)、digestAlgorithms SEQUENCE OF AlgorithmIdentifier、cryptoInfos[0]CryptoInfos OPTIONAL、encryptionInfo[1]EncryptionInfo OPTIONAL、archiveTimeStampSequence ArchiveTimeStampSequence

   CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute

CryptoInfos:、:= 属性の系列サイズ(1..MAX)

   The fields have the following meanings:

分野には、以下の意味があります:

   The 'version' field indicates the syntax version, for compatibility
   with future revisions of this specification and to distinguish it
   from earlier non-conformant or proprietary versions of the ERS.  The
   value 1 indicates this specification.  Lower values indicate an
   earlier version of the ERS has been used.  An implementation
   conforming to this specification SHOULD reject a version value below
   1.

'バージョン'分野は、この仕様の今後の改正との互換性、ERSの以前の非conformantの、または、独占であるバージョンとそれを区別するために構文バージョンを示します。 値1はこの仕様を示します。 下側の値は、ERSの以前のバージョンが使用されたのを示します。 1の下でこの仕様SHOULD廃棄物にバージョン値を従わせる実現。

Gondrom, et al.             Standards Track                     [Page 9]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[9ページ]。

   digestAlgorithms is a sequence of all the hash algorithms used to
   hash the data object over the archival period.  It is the union of
   all digestAlgorithm values from the ArchiveTimestamps contained in
   the EvidenceRecord.  The ordering of the values is not relevant.

digestAlgorithmsは記録保管所の期間、データ・オブジェクトを論じ尽くすのに使用されるすべての細切れ肉料理アルゴリズムの系列です。 それはEvidenceRecordに含まれたArchiveTimestampsからのすべてのdigestAlgorithm値の組合です。 値の注文は関連していません。

   cryptoInfos allows the storage of data useful in the validation of
   the archiveTimeStampSequence.  This could include possible Trust
   Anchors, certificates, revocation information, or the current
   definition of the suitability of cryptographic algorithms, past and
   present (e.g., RSA 768-bit valid until 1998, RSA 1024-bit valid until
   2008, SHA1 valid until 2010).  These items may be added based on the
   policy used.  Since this data is not protected within any timestamp,
   the data should be verifiable through other mechanisms.  Such
   verification is out of scope of this document.

cryptoInfosはarchiveTimeStampSequenceの合法化で役に立つデータ記憶を許容します。 これが暗号アルゴリズムの過去の、そして、現在の適合の可能なTrust Anchors、証明書、取消し情報、または現在の定義を含むかもしれない、(例えば、RSA、2008年まで有効な1024 1998、RSAまで有効な768ビットビット、2010年まで)有効なSHA1。 これらの項目は使用される方針に基づいて加えられるかもしれません。 このデータがどんなタイムスタンプの中にも保護されないので、データは他のメカニズムを通して証明可能であるべきです。このドキュメントの範囲の外にそのような検証はあります。

   encryptionInfo contains the necessary information to support
   encrypted content to be handled.  For discussion of syntax, please
   refer to Section 6.1.

encryptionInfoは扱われるためにコード化された内容を支持する必要事項を含んでいます。 構文の議論について、セクション6.1を参照してください。

   ArchiveTimeStampSequence is a sequence of ArchiveTimeStampChain,
   described in Section 5.

ArchiveTimeStampSequenceはセクション5で説明されたArchiveTimeStampChainの系列です。

   If the archive data objects were encrypted before generating Archive
   Timestamps but a non-repudiation proof is needed for unencrypted data
   objects, the optional encryptionInfos field contains data necessary
   to unambiguously re-encrypt data objects.  If omitted, it means that
   data objects are not encrypted or that a non-repudiation proof for
   the unencrypted data is not required.  For further details, see
   Section 6.

アーカイブTimestampsを発生させる前に、アーカイブデータ・オブジェクトがコード化されましたが、非拒否証拠が非コード化されたデータ・オブジェクトに必要であるなら、任意のencryptionInfos分野は明白にデータ・オブジェクトを再コード化するのに必要なデータを含んでいます。 省略されるなら、それは、データ・オブジェクトがコード化されていないか、または非コード化されたデータのための非拒否証拠が必要でないことを意味します。 さらに詳しい明細については、セクション6を見てください。

3.2.  Generation

3.2. 世代

   The generation of an EvidenceRecord can be described as follows:

以下の通りEvidenceRecordの世代について説明できます:

   1.  Select a data object or group of data objects to archive.

1. 格納するデータ・オブジェクトのデータ・オブジェクトかグループを選択してください。

   2.  Create the initial Archive Timestamp (see Section 4, "Archive
       Timestamp").

2. 初期のアーカイブTimestamp(セクション4、「アーカイブタイムスタンプ」を見る)を作成してください。

   3.  Refresh the Archive Timestamp when necessary, by Timestamp
       Renewal or Hash-Tree Renewal (see Section 5).

3. Timestamp RenewalかHash-木のRenewalで必要であるときにはアーカイブTimestampをリフレッシュしてください(セクション5を見てください)。

   The process of generation depends on whether the Archive Timestamps
   are generated, stored, and managed by a centralized instance.  In the
   case of central management, it is possible to collect many data
   objects, build hash trees, store them, and reduce them later.  In
   case of local generation, it might be easier to generate a simple
   Archive Timestamp without building hash trees.  This can be

世代の経過はアーカイブTimestampsが集結された例によって発生して、格納されて、管理されるかどうかに依存します。 主要な管理の場合では、多くのデータ・オブジェクトを集めて、細切れ肉料理木を建てて、それらを格納して、後でそれらを減少させるのは可能です。 地方の世代の場合には、ビル細切れ肉料理木なしで簡単なアーカイブTimestampを発生させるのは、より簡単であるかもしれません。 これはそうであることができます。

Gondrom, et al.             Standards Track                    [Page 10]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[10ページ]。

   accomplished by omitting the reducedHashtree field from the
   ArchiveTimestamp.  In this case, the ArchiveTimestamp covers a single
   data object.  Using this approach, it is possible to "convert"
   existing timestamps into ArchiveTimestamps for renewal.

ArchiveTimestampからreducedHashtree分野を省略することによって、達成されます。 この場合、ArchiveTimestampは単一のデータ・オブジェクトを覆います。 このアプローチを使用して、既存のタイムスタンプが更新のためにArchiveTimestampsに「変換」であることは可能です。

3.3.  Verification

3.3. 検証

   The Verification of an EvidenceRecord overall can be described as
   follows:

以下の通り全体的に見てEvidenceRecordのVerificationについて説明できます:

   1.  Select an archived data object or group of data objects

1. データ・オブジェクトの格納されたデータ・オブジェクトかグループを選択してください。

   2.  Re-encrypt data object/data object group, if encryption field is
       used (for details, see Section 6).

2. 暗号化分野が使用されているなら(詳細に関して、セクション6を見てください)、データ・オブジェクト/データ・オブジェクトグループを再コード化してください。

   3.  Verify Archive Timestamp Sequence (details in Section 4 and
       Section 5).

3. アーカイブタイムスタンプ系列(セクション4とセクション5の詳細)について確かめてください。

4.  Archive Timestamp

4. アーカイブタイムスタンプ

   An Archive Timestamp is a timestamp and a set of lists of hash
   values.  The lists of hash values are generated by reduction of an
   ordered Merkle hash tree [MER1980].  The leaves of this hash tree are
   the hash values of the data objects to be timestamped.  Every inner
   node of the tree contains one hash value, which is generated by
   hashing the concatenation of the children nodes.  The root hash
   value, which represents unambiguously all data objects, is
   timestamped.

アーカイブTimestampはハッシュ値のリストのタイムスタンプとセットです。 ハッシュ値のリストは命令されたMerkle細切れ肉料理木[MER1980]の減少で発生します。 この細切れ肉料理木の葉はtimestampedされるべきデータ・オブジェクトのハッシュ値です。 木のあらゆる内側の節が1つのハッシュ値を含んでいます。(それは、子供ノードの連結を論じ尽くすことによって、発生します)。 根のハッシュ値(明白にすべてのデータ・オブジェクトを表す)はtimestampedされます。

4.1.  Syntax

4.1. 構文

   An Archive Timestamp has the following ASN.1 Syntax:

アーカイブTimestampには、以下のASN.1Syntaxがあります:

   ASN.1 Archive Timestamp

ASN.1アーカイブタイムスタンプ

   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     attributes      [1] Attributes OPTIONAL,
     reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
     timeStamp       ContentInfo}

ArchiveTimeStamp:、:= 系列digestAlgorithm[0]AlgorithmIdentifier OPTIONAL、属性[1]属性OPTIONAL、reducedHashtree[2]SEQUENCE OF PartialHashtree OPTIONAL、timeStamp ContentInfo

   PartialHashtree ::= SEQUENCE OF OCTET STRING

PartialHashtree:、:= 八重奏ストリングの系列

   Attributes ::= SET SIZE (1..MAX) OF Attribute

属性:、:= 属性のサイズ(1..MAX)を設定してください。

   The fields of type ArchiveTimeStamp have the following meanings:

タイプArchiveTimeStampの分野には、以下の意味があります:

Gondrom, et al.             Standards Track                    [Page 11]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[11ページ]。

   digestAlgorithm identifies the digest algorithm and any associated
   parameters used within the reduced hash tree.  If the optional field
   digestAlgorithm is not present, the digest algorithm of the timestamp
   MUST be used.  Which means, if timestamps according to [RFC3161] are
   used in this case, the content of this field is identical to
   hashAlgorithm of messageImprint field of TSTInfo.

digestAlgorithm identifies the digest algorithm and any associated parameters used within the reduced hash tree. If the optional field digestAlgorithm is not present, the digest algorithm of the timestamp MUST be used. Which means, if timestamps according to [RFC3161] are used in this case, the content of this field is identical to hashAlgorithm of messageImprint field of TSTInfo.

   attributes contains information an LTA might want to provide to
   document individual renewal steps and the creation of the individual
   ArchiveTimeStamps, e.g., applied policies.  As the structure of the
   ArchiveTimeStamp may be protected by hash and timestamps, the
   ordering is relevant, which is why a SET is used instead of a
   SEQUENCE.

attributes contains information an LTA might want to provide to document individual renewal steps and the creation of the individual ArchiveTimeStamps, e.g., applied policies. As the structure of the ArchiveTimeStamp may be protected by hash and timestamps, the ordering is relevant, which is why a SET is used instead of a SEQUENCE.

   reducedHashtree contains lists of hash values, organized in
   PartialHashtrees for easier understanding.  They can be derived by
   reducing a hash tree to the nodes necessary to verify a single data
   object.  Hash values are represented as octet strings.  If the
   optional field reducedHashtree is not present, the ArchiveTimestamp
   simply contains an ordinary timestamp.

reducedHashtree contains lists of hash values, organized in PartialHashtrees for easier understanding. They can be derived by reducing a hash tree to the nodes necessary to verify a single data object. Hash values are represented as octet strings. If the optional field reducedHashtree is not present, the ArchiveTimestamp simply contains an ordinary timestamp.

   timeStamp should contain the timestamp as defined in Section 1.3.
   (e.g., as defined with TimeStampToken in [RFC3161]).  Other types of
   timestamp MAY be used, if they contain time data, timestamped data,
   and a cryptographically secure confirmation from the TSA of these
   data.

timeStamp should contain the timestamp as defined in Section 1.3. (e.g., as defined with TimeStampToken in [RFC3161]). Other types of timestamp MAY be used, if they contain time data, timestamped data, and a cryptographically secure confirmation from the TSA of these data.

4.2.  Generation

4.2. Generation

   The lists of hash values of an Archive Timestamp can be generated by
   building and reducing a Merkle hash tree [MER1980].

The lists of hash values of an Archive Timestamp can be generated by building and reducing a Merkle hash tree [MER1980].

   Such a hash tree can be built as follows:

Such a hash tree can be built as follows:

   1.  Collect data objects to be timestamped.

1. Collect data objects to be timestamped.

   2.  Choose a secure hash algorithm H and generate hash values for the
       data objects.  These values will be the leaves of the hash tree.

2. Choose a secure hash algorithm H and generate hash values for the data objects. These values will be the leaves of the hash tree.

   3.  For each data group containing more than one document, its
       respective document hashes are binary sorted in ascending order,
       concatenated, and hashed.  The hash values are the complete
       output from the hash algorithm, i.e., leading zeros are not
       removed, with the most significant bit first.

3. For each data group containing more than one document, its respective document hashes are binary sorted in ascending order, concatenated, and hashed. The hash values are the complete output from the hash algorithm, i.e., leading zeros are not removed, with the most significant bit first.

   4.  If there is more than one hash value, place them in groups and
       sort each group in binary ascending order.  Concatenate these
       values and generate new hash values, which are inner nodes of

4. If there is more than one hash value, place them in groups and sort each group in binary ascending order. Concatenate these values and generate new hash values, which are inner nodes of

Gondrom, et al.             Standards Track                    [Page 12]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 12] RFC 4998 ERS August 2007

       this tree.  (If additional hash values are needed, e.g., so that
       all nodes have the same number of children, any data may be
       hashed using H and used.)  Repeat this step until there is only
       one hash value, which is the root node of the hash tree.

this tree. (If additional hash values are needed, e.g., so that all nodes have the same number of children, any data may be hashed using H and used.) Repeat this step until there is only one hash value, which is the root node of the hash tree.

   5.  Obtain a timestamp for this root hash value.  The hash algorithm
       in the timestamp request MUST be the same as the hash algorithm
       of the hash tree, or the digestAlgorithm field of the
       ArchiveTimeStamp MUST be present and specify the hash algorithm
       of the hash tree.

5. Obtain a timestamp for this root hash value. The hash algorithm in the timestamp request MUST be the same as the hash algorithm of the hash tree, or the digestAlgorithm field of the ArchiveTimeStamp MUST be present and specify the hash algorithm of the hash tree.

   An example of a constructed hash tree for 3 data groups, where data
   groups 1 and 3 only contain one document, and data group 2 contains 3
   documents:

An example of a constructed hash tree for 3 data groups, where data groups 1 and 3 only contain one document, and data group 2 contains 3 documents:

                 +------+
                 | h123 |
                 +------+
               /         \
              /           \
           +----+      +----+
           | h12|      | h3 |
           +----+      +----+
           /     \
          /       \
       +----+  +-------+
       | h1 |  | h2abc |
       +----+  +-------+
               /   |   \
              /    |    \
             /     |     \
            /      |      \
        +----+  +----+  +----+
        | h2a|  | h2b|  | h2c|
        +----+  +----+  +----+

+------+ | h123 | +------+ / \ / \ +----+ +----+ | h12| | h3 | +----+ +----+ / \ / \ +----+ +-------+ | h1 | | h2abc | +----+ +-------+ / | \ / | \ / | \ / | \ +----+ +----+ +----+ | h2a| | h2b| | h2c| +----+ +----+ +----+

   Figure 1: Hash tree

Figure 1: Hash tree

     h1 = H(d1) where d1 is the only data object in data group 1
     h3 = H(d3) where d3 is the only data object in data group 3
     h12 = H( binary sorted and concatenated (h1, h2abc))
     h123 = H( binary sorted and concatenated (h12, h3))
     h2a = H(first data object of data object group 2)
     h2b = H(second data object of data object group 2)
     h2c = H(third data object of data object group 2)
     h2abc = H( binary sorted and concatenated (h2a, h2b, h2c))

h1 = H(d1) where d1 is the only data object in data group 1 h3 = H(d3) where d3 is the only data object in data group 3 h12 = H( binary sorted and concatenated (h1, h2abc)) h123 = H( binary sorted and concatenated (h12, h3)) h2a = H(first data object of data object group 2) h2b = H(second data object of data object group 2) h2c = H(third data object of data object group 2) h2abc = H( binary sorted and concatenated (h2a, h2b, h2c))

Gondrom, et al.             Standards Track                    [Page 13]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 13] RFC 4998 ERS August 2007

   The hash tree can be reduced to lists of hash values, necessary to
   have a proof of existence for a single data object:

The hash tree can be reduced to lists of hash values, necessary to have a proof of existence for a single data object:

   1.  Generate hash value h of the data object, using hash algorithm H
       of the hash tree.

1. Generate hash value h of the data object, using hash algorithm H of the hash tree.

   2.  Select all hash values, which have the same father node as h.
       Generate the first list of hash values by arranging these hashes,
       in binary ascending order.  This will be stored in the structure
       of the PartialHashtree.  Repeat this step for the father node of
       all hashes until the root hash is reached.  The father nodes
       themselves are not saved in the hash lists -- they are
       computable.

2. Select all hash values, which have the same father node as h. Generate the first list of hash values by arranging these hashes, in binary ascending order. This will be stored in the structure of the PartialHashtree. Repeat this step for the father node of all hashes until the root hash is reached. The father nodes themselves are not saved in the hash lists -- they are computable.

   3.  The list of all partialHashtrees finally is the reducedHashtree.
       (All of the specified hash values under the same father node,
       except the father node of the nodes below, are grouped in a
       PartialHashtree.  The sequence list of all Partialhashtrees is
       the reducedHashtree.)

3. The list of all partialHashtrees finally is the reducedHashtree. (All of the specified hash values under the same father node, except the father node of the nodes below, are grouped in a PartialHashtree. The sequence list of all Partialhashtrees is the reducedHashtree.)

   4.  Finally, add the timestamp and the info about the hash algorithm
       to get an Archive Timestamp.

4. Finally, add the timestamp and the info about the hash algorithm to get an Archive Timestamp.

   Assuming that the sorted binary ordering of the hashes in Figure 1
   is: h2abc < h1, then the reduced hash tree for data group 1 (d1) is:

Assuming that the sorted binary ordering of the hashes in Figure 1 is: h2abc < h1, then the reduced hash tree for data group 1 (d1) is:

       +--------------------------------+
       | +-----------------+ +--------+ |
       | | +------+ +----+ | | +----+ | |
       | | | h2abc| | h1 | | | | h3 | | |
       | | +------+ +----+ | | +----+ | |
       | +-----------------+ +--------+ |
       +--------------------------------+

+--------------------------------+ | +-----------------+ +--------+ | | | +------+ +----+ | | +----+ | | | | | h2abc| | h1 | | | | h3 | | | | | +------+ +----+ | | +----+ | | | +-----------------+ +--------+ | +--------------------------------+

   Figure 2: Reduced hash tree for data group 1

Figure 2: Reduced hash tree for data group 1

      The pseudo ASN1 for this reduced hash tree rht1 would look like:
        rht1 = SEQ(pht1, pht2)

The pseudo ASN1 for this reduced hash tree rht1 would look like: rht1 = SEQ(pht1, pht2)

      with the PartialHashtrees pht1 and pht2
        pht1 = SEQ (h2abc, h1)
        pht2 = SEQ (h3)

with the PartialHashtrees pht1 and pht2 pht1 = SEQ (h2abc, h1) pht2 = SEQ (h3)

Gondrom, et al.             Standards Track                    [Page 14]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 14] RFC 4998 ERS August 2007

   Assuming the same hash tree as in Figure 1, the reduced hash tree for
   all data objects in data group 2 is identical.

Assuming the same hash tree as in Figure 1, the reduced hash tree for all data objects in data group 2 is identical.

    +-------------------------------------------------+
    | +----------------------+  +--------+ +--------+ |
    | | +----+ +----+ +----+ |  | +----+ | | +----+ | |
    | | | h2b| | h2c| | h2a| |  | | h1 | | | | h3 | | |
    | | +----+ +----+ +----+ |  | +----+ | | +----+ | |
    | +----------------------+  +--------+ +--------+ |
    +-------------------------------------------------+

+-------------------------------------------------+ | +----------------------+ +--------+ +--------+ | | | +----+ +----+ +----+ | | +----+ | | +----+ | | | | | h2b| | h2c| | h2a| | | | h1 | | | | h3 | | | | | +----+ +----+ +----+ | | +----+ | | +----+ | | | +----------------------+ +--------+ +--------+ | +-------------------------------------------------+

   Figure 3: Reduced hash tree for data object group 2

Figure 3: Reduced hash tree for data object group 2

      The pseudo ASN1 for this reduced hash tree would look like:
        rht2 = SEQ(pht3, pht4, pht5)

The pseudo ASN1 for this reduced hash tree would look like: rht2 = SEQ(pht3, pht4, pht5)

      with the PartialHashtrees pht3, pht4, and pht5
       pht3 = SEQ (h2b, h2c, h2a)
       pht4 = SEQ (h1)
       pht5 = SEQ (h3)

with the PartialHashtrees pht3, pht4, and pht5 pht3 = SEQ (h2b, h2c, h2a) pht4 = SEQ (h1) pht5 = SEQ (h3)

   Note there are no restrictions on the quantity or length of hash-
   value lists.  Also note that it is profitable but not required to
   build hash trees and reduce them.  An Archive Timestamp may consist
   only of one list of hash-values and a timestamp or only a timestamp
   with no hash value lists.

Note there are no restrictions on the quantity or length of hash- value lists. Also note that it is profitable but not required to build hash trees and reduce them. An Archive Timestamp may consist only of one list of hash-values and a timestamp or only a timestamp with no hash value lists.

   The data (e.g. certificates, Certificate Revocation Lists (CRLs), or
   Online Certificate Status Protocol (OCSP) responses) needed to verify
   the timestamp MUST be preserved, and SHOULD be stored in the
   timestamp itself unless this causes unnecessary duplication.  A
   timestamp according to [RFC3161] is a CMS object in which
   certificates can be stored in the certificates field and CRLs can be
   stored in the crls field of signed data.  OCSP responses can be
   stored as unsigned attributes [RFC3126].  Note [ANSI.X9-95.2005],
   [ISO-18014-2.2002], and [ISO-18014-3.2004], which specify verifiable
   timestamps that do not depend on certificates, CRLs, or OCSP
   responses.

The data (e.g. certificates, Certificate Revocation Lists (CRLs), or Online Certificate Status Protocol (OCSP) responses) needed to verify the timestamp MUST be preserved, and SHOULD be stored in the timestamp itself unless this causes unnecessary duplication. A timestamp according to [RFC3161] is a CMS object in which certificates can be stored in the certificates field and CRLs can be stored in the crls field of signed data. OCSP responses can be stored as unsigned attributes [RFC3126]. Note [ANSI.X9-95.2005], [ISO-18014-2.2002], and [ISO-18014-3.2004], which specify verifiable timestamps that do not depend on certificates, CRLs, or OCSP responses.

4.3.  Verification

4.3. Verification

   An Archive Timestamp shall prove that a data object existed at a
   certain time, given by timestamp.  This can be verified as follows:

An Archive Timestamp shall prove that a data object existed at a certain time, given by timestamp. This can be verified as follows:

   1.  Calculate hash value h of the data object with hash algorithm H
       given in field digestAlgorithm of the Archive Timestamp.

1. Calculate hash value h of the data object with hash algorithm H given in field digestAlgorithm of the Archive Timestamp.

Gondrom, et al.             Standards Track                    [Page 15]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 15] RFC 4998 ERS August 2007

   2.  Search for hash value h in the first list (partialHashtree) of
       reducedHashtree.  If not present, terminate verification process
       with negative result.

2. Search for hash value h in the first list (partialHashtree) of reducedHashtree. If not present, terminate verification process with negative result.

   3.  Concatenate the hash values of the actual list (partialHashtree)
       of hash values in binary ascending order and calculate the hash
       value h' with algorithm H.  This hash value h' MUST become a
       member of the next higher list of hash values (from the next
       partialHashtree).  Continue step 3 until a root hash value is
       calculated.

3. Concatenate the hash values of the actual list (partialHashtree) of hash values in binary ascending order and calculate the hash value h' with algorithm H. This hash value h' MUST become a member of the next higher list of hash values (from the next partialHashtree). Continue step 3 until a root hash value is calculated.

   4.  Check timestamp.  In case of a timestamp according to [RFC3161],
       the root hash value must correspond to hashedMessage, and
       digestAlgorithm must correspond to hashAlgorithm field, both in
       messageImprint field of timeStampToken.  In case of other
       timestamp formats, the hash value and digestAlgorithm must also
       correspond to their equivalent fields if they exist.

4. Check timestamp. In case of a timestamp according to [RFC3161], the root hash value must correspond to hashedMessage, and digestAlgorithm must correspond to hashAlgorithm field, both in messageImprint field of timeStampToken. In case of other timestamp formats, the hash value and digestAlgorithm must also correspond to their equivalent fields if they exist.

   If a proof is necessary for more than one data object, steps 1 and 2
   have to be done for all data objects to be proved.  If an additional
   proof is necessary that the Archive Timestamp relates to a data
   object group (e.g., a document and all its signatures), it can be
   verified additionally, that only the hash values of the given data
   objects are in the first hash-value list.

If a proof is necessary for more than one data object, steps 1 and 2 have to be done for all data objects to be proved. If an additional proof is necessary that the Archive Timestamp relates to a data object group (e.g., a document and all its signatures), it can be verified additionally, that only the hash values of the given data objects are in the first hash-value list.

5.  Archive Timestamp Chain and Archive Timestamp Sequence

5. Archive Timestamp Chain and Archive Timestamp Sequence

   An Archive Timestamp proves the existence of single data objects or
   data object group at a certain time.  However, this first Archive
   Timestamp in the first ArchiveTimeStampChain can become invalid, if
   hash algorithms or public key algorithms used in its hash tree or
   timestamp become weak or if the validity period of the timestamp
   authority certificate expires or is revoked.

An Archive Timestamp proves the existence of single data objects or data object group at a certain time. However, this first Archive Timestamp in the first ArchiveTimeStampChain can become invalid, if hash algorithms or public key algorithms used in its hash tree or timestamp become weak or if the validity period of the timestamp authority certificate expires or is revoked.

   Prior to such an event, the existence of the Archive Timestamp or
   archive timestamped data has to be reassured.  This can be done by
   creating a new Archive Timestamp.  Depending on whether the timestamp
   becomes invalid or the hash algorithm of the hash tree becomes weak,
   two kinds of Archive Timestamp renewal are possible:

Prior to such an event, the existence of the Archive Timestamp or archive timestamped data has to be reassured. This can be done by creating a new Archive Timestamp. Depending on whether the timestamp becomes invalid or the hash algorithm of the hash tree becomes weak, two kinds of Archive Timestamp renewal are possible:

   o  Timestamp Renewal: A new Archive Timestamp is generated, which
      covers the timestamp of the old one.  One or more Archive
      Timestamps generated by Timestamp Renewal yield an Archive
      Timestamp Chain for a data object or data object group.

o Timestamp Renewal: A new Archive Timestamp is generated, which covers the timestamp of the old one. One or more Archive Timestamps generated by Timestamp Renewal yield an Archive Timestamp Chain for a data object or data object group.

Gondrom, et al.             Standards Track                    [Page 16]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 16] RFC 4998 ERS August 2007

   o  Hash-Tree Renewal: A new Archive Timestamp is generated, which
      covers all the old Archive Timestamps as well as the data objects.
      A new Archive Timestamp Chain is started.  One or more Archive
      Timestamp Chains for a data object or data object group yield an
      Archive Timestamp Sequence.

o Hash-Tree Renewal: A new Archive Timestamp is generated, which covers all the old Archive Timestamps as well as the data objects. A new Archive Timestamp Chain is started. One or more Archive Timestamp Chains for a data object or data object group yield an Archive Timestamp Sequence.

   After the renewal, always only the last (i.e., most recent)
   ArchiveTimeStamp and the algorithms and timestamps used by it must be
   watched regarding expiration and loss of security.

After the renewal, always only the last (i.e., most recent) ArchiveTimeStamp and the algorithms and timestamps used by it must be watched regarding expiration and loss of security.

5.1.  Syntax

5.1. Syntax

   ArchiveTimeStampChain and ArchiveTimeStampSequence have the following
   ASN.1 Syntax:

ArchiveTimeStampChain and ArchiveTimeStampSequence have the following ASN.1 Syntax:

   ASN.1 ArchiveTimeStampChain and ArchiveTimeStampSequence

ASN.1 ArchiveTimeStampChain and ArchiveTimeStampSequence

   ArchiveTimeStampChain    ::= SEQUENCE OF ArchiveTimeStamp

ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp

   ArchiveTimeStampSequence ::= SEQUENCE OF
                                ArchiveTimeStampChain

ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain

   ArchiveTimeStampChain and ArchiveTimeStampSequence MUST be ordered
   ascending by time of timestamp.  Within an ArchiveTimeStampChain, all
   reducedHashtrees of the contained ArchiveTimeStamps MUST use the same
   Hash-Algorithm.

ArchiveTimeStampChain and ArchiveTimeStampSequence MUST be ordered ascending by time of timestamp. Within an ArchiveTimeStampChain, all reducedHashtrees of the contained ArchiveTimeStamps MUST use the same Hash-Algorithm.

5.2.  Generation

5.2. Generation

   The initial Archive Timestamp relates to a data object or a data
   object group.  Before cryptographic algorithms that are used within
   the most recent Archive Timestamp (which is, at the beginning, the
   initial one) become weak or their timestamp certificates become
   invalid, Archive Timestamps have to be renewed by generating a new
   Archive Timestamp.

The initial Archive Timestamp relates to a data object or a data object group. Before cryptographic algorithms that are used within the most recent Archive Timestamp (which is, at the beginning, the initial one) become weak or their timestamp certificates become invalid, Archive Timestamps have to be renewed by generating a new Archive Timestamp.

   In the case of Timestamp Renewal, the content of the timeStamp field
   of the old Archive Timestamp has to be hashed and timestamped by a
   new Archive Timestamp.  The new Archive Timestamp MAY not contain a
   reducedHashtree field, if the timestamp only simply covers the
   previous timestamp.  However, generally one can collect a number of
   old Archive Timestamps and build the new hash tree with the hash
   values of the content of their timeStamp fields.

In the case of Timestamp Renewal, the content of the timeStamp field of the old Archive Timestamp has to be hashed and timestamped by a new Archive Timestamp. The new Archive Timestamp MAY not contain a reducedHashtree field, if the timestamp only simply covers the previous timestamp. However, generally one can collect a number of old Archive Timestamps and build the new hash tree with the hash values of the content of their timeStamp fields.

   The new Archive Timestamp MUST be added to the ArchiveTimestampChain.
   This hash tree of the new Archive Timestamp MUST use the same hash
   algorithm as the old one, which is specified in the digestAlgorithm

The new Archive Timestamp MUST be added to the ArchiveTimestampChain. This hash tree of the new Archive Timestamp MUST use the same hash algorithm as the old one, which is specified in the digestAlgorithm

Gondrom, et al.             Standards Track                    [Page 17]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 17] RFC 4998 ERS August 2007

   field of the Archive Timestamp or, if this value is not set (as it is
   optional), within the timestamp itself.

field of the Archive Timestamp or, if this value is not set (as it is optional), within the timestamp itself.

   In the case of Hash-Tree Renewal, the Archive Timestamp and the
   archived data objects covered by the Archive Timestamp must be hashed
   and timestamped again, as described below:

In the case of Hash-Tree Renewal, the Archive Timestamp and the archived data objects covered by the Archive Timestamp must be hashed and timestamped again, as described below:

   1.  Select a secure hash algorithm H.

1. Select a secure hash algorithm H.

   2.  Select data objects d(i) referred to by initial Archive Timestamp
       (objects that are still present and not deleted).  Generate hash
       values h(i) = H((d(i)).  If data groups with more than one
       document are present, then one will have more than one hash for a
       group, i.e., h(i_a), h(i_b).., h(i_n)

2. Select data objects d(i) referred to by initial Archive Timestamp (objects that are still present and not deleted). Generate hash values h(i) = H((d(i)). If data groups with more than one document are present, then one will have more than one hash for a group, i.e., h(i_a), h(i_b).., h(i_n)

   3.  atsc(i) is the encoded ArchiveTimeStampSequence, the
       concatenation of all previous Archive Timestamp Chains (in
       chronological order) related to data object d(i).  Generate hash
       value ha(i) = H(atsc(i)).
       Note: The ArchiveTimeStampChains used are DER encoded, i.e., they
       contain sequence and length tags.

3. atsc(i) is the encoded ArchiveTimeStampSequence, the concatenation of all previous Archive Timestamp Chains (in chronological order) related to data object d(i). Generate hash value ha(i) = H(atsc(i)). Note: The ArchiveTimeStampChains used are DER encoded, i.e., they contain sequence and length tags.

   4.  Concatenate each h(i) with ha(i) and generate hash values
       h(i)' = H (h(i)+ ha(i)).  For multi-document groups, this is:
       h(i_a)' = H (h(i_a)+ ha(i))
       h(i_b)' = H (h(i_b)+ ha(i)), etc.

4. Concatenate each h(i) with ha(i) and generate hash values h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: h(i_a)' = H (h(i_a)+ ha(i)) h(i_b)' = H (h(i_b)+ ha(i)), etc.

   5.  Build a new Archive Time Stamp for each h(i)'.  (Hash-tree
       generation and reduction is defined in Section 4.2; note that
       each h(i)' will be treated in Section 4.2 as the document hash.
       The first hash value list in the reduced hash tree should only
       contain h(i)'.  For a multi-document group, the first hash value
       list will contain the new hashes for all the documents in this
       group, i.e., h(i_a)', h(i_b)'.., h(i_n)')

5. Build a new Archive Time Stamp for each h(i)'. (Hash-tree generation and reduction is defined in Section 4.2; note that each h(i)' will be treated in Section 4.2 as the document hash. The first hash value list in the reduced hash tree should only contain h(i)'. For a multi-document group, the first hash value list will contain the new hashes for all the documents in this group, i.e., h(i_a)', h(i_b)'.., h(i_n)')

   6.  Create new ArchiveTimeStampChain containing the new Archive
       Timestamp and append this ArchiveTimeStampChain to the
       ArchiveTimeStampSequence.

6. Create new ArchiveTimeStampChain containing the new Archive Timestamp and append this ArchiveTimeStampChain to the ArchiveTimeStampSequence.

Gondrom, et al.             Standards Track                    [Page 18]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 18] RFC 4998 ERS August 2007

                 +-------+
                 | h123' |
                 +-------+
               /         \
              /           \
           +-----+      +----+
           | h12'|      | h3'|
           +-----+      +----+
           /     \
          /       \
       +----+  +--------+
       | h1'|  | h2abc' |
       +----+  +--------+
               /   |   \
              /    |    \
             /     |     \
            /      |      \
        +----+  +----+  +----+
        |h2a'|  |h2b'|  |h2c'|
        +----+  +----+  +----+

+-------+ | h123' | +-------+ / \ / \ +-----+ +----+ | h12'| | h3'| +-----+ +----+ / \ / \ +----+ +--------+ | h1'| | h2abc' | +----+ +--------+ / | \ / | \ / | \ / | \ +----+ +----+ +----+ |h2a'| |h2b'| |h2c'| +----+ +----+ +----+

   Figure 4: Hash tree from Hash-Tree Renewal

Figure 4: Hash tree from Hash-Tree Renewal

     Let H be the new secure hash algorithm
     ha(1), ha(2), ha(3) are as defined in step 4 above
     h1' = H( binary sorted and concatenated (H(d1), ha(1)))
       d1 is the original document from data group 1
     h3' = H( binary sorted and concatenated (H(d3), ha(3)))
       d3 is the original document from data group 3

Let H be the new secure hash algorithm ha(1), ha(2), ha(3) are as defined in step 4 above h1' = H( binary sorted and concatenated (H(d1), ha(1))) d1 is the original document from data group 1 h3' = H( binary sorted and concatenated (H(d3), ha(3))) d3 is the original document from data group 3

     h2a = H(first data object of data object group 2)
      ...
     h2c = H(third data object of data object group 2)
     h2a' = H( binary sorted and concatenated (h2a, ha(2)))
      ...
     h2c' = H( binary sorted and concatenated (h2c, ha(2)))

h2a = H(first data object of data object group 2) ... h2c = H(third data object of data object group 2) h2a' = H( binary sorted and concatenated (h2a, ha(2))) ... h2c' = H( binary sorted and concatenated (h2c, ha(2)))

     h2abc = H( binary sorted and concatenated (h2a', h2b', h2c'))

h2abc = H( binary sorted and concatenated (h2a', h2b', h2c'))

   ArchiveTimeStamps that are not necessary for verification should not
   be added to an ArchiveTimeStampChain or ArchiveTimeStampSequence.

ArchiveTimeStamps that are not necessary for verification should not be added to an ArchiveTimeStampChain or ArchiveTimeStampSequence.

5.3.  Verification

5.3. Verification

   To get a non-repudiation proof that a data object existed at a
   certain time, the Archive Timestamp Chains and their relations to
   each other and to the data objects have to be proved:

To get a non-repudiation proof that a data object existed at a certain time, the Archive Timestamp Chains and their relations to each other and to the data objects have to be proved:

Gondrom, et al.             Standards Track                    [Page 19]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 19] RFC 4998 ERS August 2007

   1.  Verify that the first Archive Timestamp of the first
       ArchiveTimestampChain (the initial Archive Timestamp) contains
       the hash value of the data object.

1. Verify that the first Archive Timestamp of the first ArchiveTimestampChain (the initial Archive Timestamp) contains the hash value of the data object.

   2.  Verify each ArchiveTimestampChain.  The first hash value list of
       each ArchiveTimeStamp MUST contain the hash value of the
       timestamp of the Archive Timestamp before.  Each Archive
       Timestamp MUST be valid relative to the time of the following
       Archive Timestamp.  All Archive Timestamps within a chain MUST
       use the same hash algorithm and this algorithm MUST be secure at
       the time of the first Archive Timestamp of the following
       ArchiveTimeStampChain.

2. Verify each ArchiveTimestampChain. The first hash value list of each ArchiveTimeStamp MUST contain the hash value of the timestamp of the Archive Timestamp before. Each Archive Timestamp MUST be valid relative to the time of the following Archive Timestamp. All Archive Timestamps within a chain MUST use the same hash algorithm and this algorithm MUST be secure at the time of the first Archive Timestamp of the following ArchiveTimeStampChain.

   3.  Verify that the first hash value list (partialHashtree) of the
       first Archive Timestamp of all other ArchiveTimeStampChains
       contains a hash value of the concatenation of the data object
       hash and the hash value of all older ArchiveTimeStampChain.
       Verify that this Archive Timestamp was generated before the last
       Archive Timestamp of the ArchiveTimeStampChain became invalid.

3. Verify that the first hash value list (partialHashtree) of the first Archive Timestamp of all other ArchiveTimeStampChains contains a hash value of the concatenation of the data object hash and the hash value of all older ArchiveTimeStampChain. Verify that this Archive Timestamp was generated before the last Archive Timestamp of the ArchiveTimeStampChain became invalid.

   In order to complete the non-repudiation proof for the data objects,
   the last Archive Timestamp has to be valid at the time the
   verification is performed.

In order to complete the non-repudiation proof for the data objects, the last Archive Timestamp has to be valid at the time the verification is performed.

   If the proof is necessary for more than one data object, steps 1 and
   3 have to be done for all these data objects.  To prove the Archive
   Timestamp Sequence relates to a data object group, verify that each
   first Archive Timestamp of the first ArchiveTimeStampChain of the
   ArchiveTimeStampSequence of each data object does not contain other
   hash values in its first hash value list (than the hash values of the
   other data objects).

If the proof is necessary for more than one data object, steps 1 and 3 have to be done for all these data objects. To prove the Archive Timestamp Sequence relates to a data object group, verify that each first Archive Timestamp of the first ArchiveTimeStampChain of the ArchiveTimeStampSequence of each data object does not contain other hash values in its first hash value list (than the hash values of the other data objects).

6.  Encryption

6. Encryption

   If service providers are used to archive data and generate Archive
   Timestamps, it might be desirable or required that clients only send
   encrypted data to be archived.  However, this means that evidence
   records refer to encrypted data objects.  ERS directly protects the
   integrity of the bit-stream and this freezes the bit structure at the
   time of archiving.  This precludes changing of the encryption scheme
   during the archival period, e.g., if the encryption scheme is no
   longer secure, a change is not possible without losing the integrity
   proof of the EvidenceRecord.  In such cases, the services of a data
   transformation (and by this also possible re-encryption) done by a
   notary service might be a possible solution.  To avoid problems when
   using the evidence records in the future, additional special
   precautions have to be taken:

If service providers are used to archive data and generate Archive Timestamps, it might be desirable or required that clients only send encrypted data to be archived. However, this means that evidence records refer to encrypted data objects. ERS directly protects the integrity of the bit-stream and this freezes the bit structure at the time of archiving. This precludes changing of the encryption scheme during the archival period, e.g., if the encryption scheme is no longer secure, a change is not possible without losing the integrity proof of the EvidenceRecord. In such cases, the services of a data transformation (and by this also possible re-encryption) done by a notary service might be a possible solution. To avoid problems when using the evidence records in the future, additional special precautions have to be taken:

Gondrom, et al.             Standards Track                    [Page 20]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 20] RFC 4998 ERS August 2007

   o  Evidence generated to prove the existence of encrypted data cannot
      always be relied upon to prove the existence of unencrypted data.
      It may be possible to choose an algorithm or a key for decryption
      that is not the algorithm or key used for encryption.  In this
      case, the evidence record would not be a non-repudiation proof for
      the unencrypted data.  Therefore, only encryption methods should
      be used that make it possible to prove that archive-timestamped
      encrypted data objects unambiguously represent unencrypted data
      objects.  All data necessary to prove unambiguous representation
      should be included in the archived data objects.  (Note: In
      addition, the long-term security of the encryption schemes should
      be analyzed to determine if it could be used to create collision
      attacks.)

o Evidence generated to prove the existence of encrypted data cannot always be relied upon to prove the existence of unencrypted data. It may be possible to choose an algorithm or a key for decryption that is not the algorithm or key used for encryption. In this case, the evidence record would not be a non-repudiation proof for the unencrypted data. Therefore, only encryption methods should be used that make it possible to prove that archive-timestamped encrypted data objects unambiguously represent unencrypted data objects. All data necessary to prove unambiguous representation should be included in the archived data objects. (Note: In addition, the long-term security of the encryption schemes should be analyzed to determine if it could be used to create collision attacks.)

   o  When a relying party uses an evidence record to prove the
      existence of encrypted data objects, it may be desirable for
      clients to only store the unencrypted data objects and to delete
      the encrypted copy.  In order to use the evidence record, it must
      then be possible to unambiguously re-encrypt the unencrypted data
      to get exactly the data that was originally archived.  Therefore,
      additional data necessary to re-encrypt data objects should be
      inserted into the evidence record by the client, i.e., the LTA
      never sees these values.

o When a relying party uses an evidence record to prove the existence of encrypted data objects, it may be desirable for clients to only store the unencrypted data objects and to delete the encrypted copy. In order to use the evidence record, it must then be possible to unambiguously re-encrypt the unencrypted data to get exactly the data that was originally archived. Therefore, additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client, i.e., the LTA never sees these values.

   An extensible structure is defined to store the necessary parameters
   of the encryption methods.  The use of the specified
   encryptionInfoType and encryptionInfoValue may be heavily dependent
   on the mechanisms and has to be defined in other specifications.

An extensible structure is defined to store the necessary parameters of the encryption methods. The use of the specified encryptionInfoType and encryptionInfoValue may be heavily dependent on the mechanisms and has to be defined in other specifications.

6.1.  Syntax

6.1. Syntax

   The EncryptionInfo field in EvidenceRecord has the following syntax
   depending on the version of ASN.1.

The EncryptionInfo field in EvidenceRecord has the following syntax depending on the version of ASN.1.

6.1.1.  EncryptionInfo in 1988 ASN.1

6.1.1. EncryptionInfo in 1988 ASN.1

   1988 ASN.1 EncryptionInfo

1988 ASN.1 EncryptionInfo

   EncryptionInfo       ::=     SEQUENCE {
       encryptionInfoType     OBJECT IDENTIFIER,
       encryptionInfoValue    ANY DEFINED BY encryptionInfoType
   }

EncryptionInfo ::= SEQUENCE { encryptionInfoType OBJECT IDENTIFIER, encryptionInfoValue ANY DEFINED BY encryptionInfoType }

Gondrom, et al.             Standards Track                    [Page 21]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 21] RFC 4998 ERS August 2007

6.1.2.  EncryptionInfo in 1997-ASN.1

6.1.2. EncryptionInfo in 1997-ASN.1

   1997-ASN.1 EncryptionInfo

1997-ASN.1 EncryptionInfo

   EncryptionInfo       ::=     SEQUENCE {
       encryptionInfoType   ENCINFO-TYPE.&id
                                      ({SupportedEncryptionAlgorithms}),
       encryptionInfoValue  ENCINFO-TYPE.&Type
                  ({SupportedEncryptionAlgorithms}{@encryptionInfoType})
   }

EncryptionInfo ::= SEQUENCE { encryptionInfoType ENCINFO-TYPE.&id ({SupportedEncryptionAlgorithms}), encryptionInfoValue ENCINFO-TYPE.&Type ({SupportedEncryptionAlgorithms}{@encryptionInfoType}) }

   ENCINFO-TYPE ::= TYPE-IDENTIFIER

ENCINFO-TYPE ::= TYPE-IDENTIFIER

   SupportedEncryptionAlgorithms ENCINFO-TYPE ::= {...}

SupportedEncryptionAlgorithms ENCINFO-TYPE ::= {...}

   encryptionInfo contains information necessary for the unambiguous
   re-encryption of unencrypted content so that it exactly matches with
   the encrypted data objects protected by the EvidenceRecord.

encryptionInfo contains information necessary for the unambiguous re-encryption of unencrypted content so that it exactly matches with the encrypted data objects protected by the EvidenceRecord.

7.  Security Considerations

7. Security Considerations

   Secure Algorithms

Secure Algorithms

   Cryptographic algorithms and parameters that are used within Archive
   Timestamps must be secure at the time of generation.  This concerns
   the hash algorithm used in the hash lists of Archive Timestamp as
   well as hash algorithms and public key algorithms of the timestamps.
   Publications regarding security suitability of cryptographic
   algorithms ([NIST.800-57-Part1.2006] and [ETSI-TS102176-1-2005]) have
   to be considered by verifying components.  A generic solution for
   automatic interpretation of security suitability policies in
   electronic form is desirable but not the subject of this
   specification.

Cryptographic algorithms and parameters that are used within Archive Timestamps must be secure at the time of generation. This concerns the hash algorithm used in the hash lists of Archive Timestamp as well as hash algorithms and public key algorithms of the timestamps. Publications regarding security suitability of cryptographic algorithms ([NIST.800-57-Part1.2006] and [ETSI-TS102176-1-2005]) have to be considered by verifying components. A generic solution for automatic interpretation of security suitability policies in electronic form is desirable but not the subject of this specification.

   Redundancy

Redundancy

   Retrospectively, certain parts of an Archive Timestamp may turn out
   to have lost their security suitability before this has been publicly
   known.  For example, retrospectively, it may turn out that algorithms
   have lost their security suitability, and that even TSAs are
   untrustworthy.  This can result in Archive Timestamps using those
   losing their probative force.  Many TSAs are using the same signature
   algorithms.  While the compromise of a private key will only affect
   the security of one specific TSA, the retrospective loss of security
   of a signature algorithm will have impact on a potentially large
   number of TSAs at once.  To counter such risks, it is recommended to

Retrospectively, certain parts of an Archive Timestamp may turn out to have lost their security suitability before this has been publicly known. For example, retrospectively, it may turn out that algorithms have lost their security suitability, and that even TSAs are untrustworthy. This can result in Archive Timestamps using those losing their probative force. Many TSAs are using the same signature algorithms. While the compromise of a private key will only affect the security of one specific TSA, the retrospective loss of security of a signature algorithm will have impact on a potentially large number of TSAs at once. To counter such risks, it is recommended to

Gondrom, et al.             Standards Track                    [Page 22]

RFC 4998                          ERS                        August 2007

Gondrom, et al. Standards Track [Page 22] RFC 4998 ERS August 2007

   generate and manage at least two redundant Evidence Records with
   ArchiveTimeStampSequences using different hash algorithms and
   different TSAs using different signature algorithms.

generate and manage at least two redundant Evidence Records with ArchiveTimeStampSequences using different hash algorithms and different TSAs using different signature algorithms.

   To best achieve and manage this redundancy, it is recommended to
   manage the Archive Timestamps in a central LTA.

To best achieve and manage this redundancy, it is recommended to manage the Archive Timestamps in a central LTA.

   Secure Timestamps

Secure Timestamps

   Archive Timestamping depends upon the security of normal time
   stamping.  Security requirements for Time Stamping Authorities stated
   in security policies have to be met.  Renewed Archive Timestamps
   should have the same or higher quality as the initial Archive
   Timestamp.  Archive Timestamps used for signature renewal of signed
   data, should have the same or higher quality than the maximum quality
   of the signatures.

アーカイブTimestampingは正常な時間の刻印のセキュリティによります。 安全保障政策で述べられたTime Stamping Authoritiesのためのセキュリティ必要条件は満たされなければなりません。 更新されたアーカイブTimestampsには、初期のアーカイブTimestampとして同じであるか、より高い品質があるはずです。 サインされたデータの署名更新に使用されるアーカイブTimestamps、署名の最大の品質より同じであるか高い品質を持つべきです。

   Secure Encryption

安全な暗号化

   For non-repudiation proof, it does not matter whether encryption has
   been broken or not.  Nevertheless, users should keep secret their
   private keys and randoms used for encryption and disclose them only
   if needed, e.g., in a lawsuit to a judge or expert.  They should use
   encryption algorithms and parameters that are prospected to be
   unbreakable as long as confidentiality of the archived data is
   important.

非拒否証拠のために、暗号化が中断しているかどうかは重要ではありません。 それにもかかわらず、必要である場合にだけ、ユーザは、暗号化に使用される彼らの秘密鍵とrandomsを秘密にして、彼らを明らかにするべきです、例えば、裁判官か専門家への訴訟で。 彼らは格納されたデータの秘密性が重要である限り、こわしにくくなるように試掘される暗号化アルゴリズムとパラメタを使用するべきです。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [CCITT.X208.1988]
              International Telephone and Telegraph Consultative
              Committee, "Specification of Abstract Syntax Notation One
              (ASN.1)", CCITT Recommendation X.208, November 1988.

国際[CCITT.X208.1988]は、1988年11月に諮問委員会、「抽象構文記法1(ASN.1)の仕様」、CCITT推薦X.208に電話をして、電報を打ちます。

   [CCITT.X209.1988]
              International Telephone and Telegraph Consultative
              Committee, "Specification of Basic Encoding Rules for
              Abstract Syntax Notation One (ASN.1)",
              CCITT Recommendation X.209, 1988.

国際[CCITT.X209.1988]は、諮問委員会、「抽象構文記法1(ASN.1)のための基本的な符号化規則の仕様」、CCITT推薦X.209、1988に電話をして、電報を打ちます。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [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月)。

Gondrom, et al.             Standards Track                    [Page 23]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[23ページ]。

   [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月)。

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

[RFC3852] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。

8.2.  Informative References

8.2. 有益な参照

   [ANSI.X9-95.2005]
              American National Standard for Financial Services,
              "Trusted Timestamp Management and Security", ANSI X9.95,
              June 2005.

金融サービスと、「信じられたタイムスタンプ管理とセキュリティ」のための[ANSI.X9-95.2005]米国標準規格、ANSI X9.95、2005年6月。

   [CCITT.X680.2002]
              International Telephone and Telegraph Consultative
              Committee, "Abstract Syntax Notation One (ASN.1):
              Specification of basic notation", CCITT Recommendation
              X.680, July 2002.

[CCITT.X680.2002]国際電話と電報諮問委員会、「構文記法1(ASN.1)を抜き取ってください」 「基本的な記法の仕様」、CCITT Recommendation X.680、2002年7月。

   [CCITT.X690.2002]
              International Telephone and Telegraph Consultative
              Committee, "ASN.1 encoding rules:  Specification of basic
              encoding Rules (BER), Canonical encoding rules (CER) and
              Distinguished encoding rules (DER)", CCITT Recommendation
              X.690, July 2002.

[CCITT.X690.2002] 国際TelephoneとTelegraph Consultative Committee、「ASN.1コード化は統治します」。 「基本的なコード化Rules(BER)、Canonical符号化規則(CER)、およびDistinguished符号化規則(DER)の仕様」、CCITT Recommendation X.690、2002年7月。

   [ETSI-TS102176-1-2005]
              European Telecommunication Standards Institute (ETSI),
              Electronic Signatures and Infrastructures (ESI);,
              "Algorithms and Parameters for Secure Electronic
              Signatures; Part 1: Hash functions and asymmetric
              algorithms", ETSI  TS 102 176-1 V1.2.1, July 2005.

[ETSI-TS102176-1-2005]ヨーロッパ電気通信規格研究所(ETSI)、電子署名、およびインフラストラクチャ(ESI)「安全な電子署名のためのアルゴリズムとパラメタ」という 第1部: 「ハッシュ関数の、そして、非対称のアルゴリズム」、ETSI TS102 176-1V1.2.1、2005年7月。

   [ISO-18014-1.2002]
              ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1:
              Framework", ISO ISO-18014-1, February 2002.

[ISO-18014-1.2002]ISO/IEC JTC1/サウスカロライナ27、「タイムスタンピングサービス--第1部:、」 「枠組み」、ISO ISO-18014-1、2002年2月。

   [ISO-18014-2.2002]
              ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2:
              Mechanisms producing independent tokens", ISO ISO-18014-2,
              December 2002.

[ISO-18014-2.2002]ISO/IEC JTC1/サウスカロライナ27、「タイムスタンピングサービス--第2部:、」 「独立している象徴を生産するメカニズム」、ISO ISO-18014-2、2002年12月。

   [ISO-18014-3.2004]
              ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3:
              Mechanisms producing linked tokens", ISO ISO-18014-3,
              February 2004.

[ISO-18014-3.2004]ISO/IEC JTC1/サウスカロライナ27、「タイムスタンピングサービス--3を分けてください」 「繋がっている象徴を生産するメカニズム」、ISO ISO-18014-3、2004年2月。

Gondrom, et al.             Standards Track                    [Page 24]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[24ページ]。

   [MER1980]  Merkle, R., "Protocols for Public Key Cryptosystems,
              Proceedings of the 1980 IEEE Symposium on Security and
              Privacy (Oakland, CA, USA)", pages 122-134, April 1980.

[MER1980]Merkle、「公開鍵暗号方式のためのプロトコル、セキュリティとプライバシー(オークランド(カリフォルニア)(米国))における1980年のIEEEシンポジウムの議事」というR.は122-134を呼び出します、1980年4月。

   [NIST.800-57-Part1.2006]
              National Institute of Standards and Technology,
              "Recommendation for Key Management - Part 1: General
              (Revised)", NIST 800-57 Part1, May 2006.

[NIST.800-57-Part1.2006]米国商務省標準技術局、「推薦、Key Management--第1部のために:、」 「一般(改訂されます)」(NIST800-57Part1)は2006がそうするかもしれません。

   [RFC3126]  Pinkas, D., Ross, J., and N. Pope, "Electronic Signature
              Formats for long term electronic signatures", RFC 3126,
              September 2001.

[RFC3126]ピンカス、D.、ロス、J.、およびN.ポープ、「長期の電子署名のための電子Signature Formats」、RFC3126、2001年9月。

   [RFC4810]  Wallace, C., Pordesch, U., and R. Brandner, "Long-Term
              Archive Service Requirements", RFC 4810, March 2007.

[RFC4810] ウォレスとC.とPordesch、U.とR.Brandner、「長期のアーカイブサービス要件」、RFC4810、2007年3月。

Gondrom, et al.             Standards Track                    [Page 25]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[25ページ]。

Appendix A.  Evidence Record Using CMS

cmを使用する付録A.証拠記録

   An Evidence Record can be added to signed data or enveloped data in
   order to transfer them in a conclusive way.  For CMS, a sensible
   place to store such an Evidence Record is an unsigned attribute
   (signed message) or an unprotected attribute (enveloped message).

決定的な方法でそれらを移すためにサインされたデータかおおわれたデータにEvidence Recordを追加できます。 CMSに関しては、そのようなEvidence Recordを格納する分別がある場所は、無記名の属性(メッセージにサインする)か保護のない属性(メッセージをおおう)です。

   One advantage of storing the Evidence Record within the CMS structure
   is that all data can be transferred in one conclusive file and is
   directly connected.  The documents, the signatures, and their
   Evidence Records can be bundled and managed together.  The
   description in the appendix contains the normative specification of
   how to integrate ERS in CMS structures.

CMS構造の中にEvidence Recordを格納する1つの利点はすべてのデータが1個の決定的なファイルで移すことができて、直接接続されるということです。 ドキュメント、署名、およびそれらのEvidence Recordsを一緒に束ねて、対処できます。 付録における記述はCMS構造でどうERSを統合するかに関する標準の仕様を含んでいます。

   The Evidence Record also contains information about the selection
   method that was used for the generation of the data objects to be
   timestamped.  In the case of CMS, two selection methods can be
   distinguished:

また、Evidence Recordはtimestampedされるべきデータ・オブジェクトの世代に使用された選択方法の情報を含んでいます。 CMSの場合では、2つの選択方法を区別できます:

   1.  The CMS Object as a whole including contentInfo is selected as
       data object and archive timestamped.  This means that a hash
       value of the CMS object MUST be located in the first list of hash
       values of Archive Timestamps.

1. データ・オブジェクトとアーカイブがtimestampedされたとき、全体でcontentInfoを含むCMS Objectは選択されます。 これは、CMS物のハッシュ値がアーカイブTimestampsのハッシュ値の最初のリストに位置しなければならないことを意味します。

   2.  The CMS Object and the signed or encrypted content are included
       in the Archive Timestamp as separated objects.  In this case, the
       hash value of the CMS Object as well as the hash value of the
       content have to be stored in the first list of hash values as a
       group of data objects.

2. CMS Objectとサインされたかコード化された内容は切り離された物としてアーカイブTimestampに含まれています。 この場合、データのグループが反対するように内容のハッシュ値と同様にCMS Objectのハッシュ値はハッシュ値の最初のリストに格納されなければなりません。

   However, other selection methods could also be applied, for instance,
   as in [RFC3126].

しかしながら、また、例えば、[RFC3126]のように他の選択方法を適用できました。

   In the case of the two selection methods defined above, the Evidence
   Record has to be added to the first signature of the CMS Object of
   signed data.  Depending on the selection method, the following Object
   Identifiers are defined for the Evidence Record:

上で定義された2つの選択方法の場合では、Evidence RecordはサインされたデータのCMS Objectの最初の署名に加えられなければなりません。 選択方法によって、以下のObject IdentifiersはEvidence Recordのために定義されます:

   ASN.1 Internal EvidenceRecord Attribute

ASN.1の内部のEvidenceRecord属性

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

イドaa、えー、内部、OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)49をメンバーと同じくらい具体化させます。

   ASN.1 External EvidenceRecord Attribute

ASN.1の外部のEvidenceRecord属性

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

イドaa、えー、外部、OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)50をメンバーと同じくらい具体化させます。

Gondrom, et al.             Standards Track                    [Page 26]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[26ページ]。

   The attributes SHOULD only occur once.  If they appear several times,
   they have to be stored within the first signature in chronological
   order.

属性SHOULDは一度起こるだけです。 彼らが何度か現れるなら、それらは最初の署名の中に年代順に格納されなければなりません。

   If the CMS object doesn't have the EvidenceRecord Attributes -- which
   indicates that the EvidenceRecord has been provided externally -- the
   archive timestamped data object has to be generated over the complete
   CMS object within the existing coding.

CMS物がアーカイブがtimestampedしたEvidenceRecord Attributes(EvidenceRecordが外部的に提供されたのを示す)を持っていないなら、データ・オブジェクトは既存のコード化の中で完全なCMS物の上に発生しなければなりません。

   In case of verification, if only one EvidenceRecord is contained in
   the CMS object, the hash value must be generated over the CMS object
   without the one EvidenceRecord.  This means that the attribute has to
   be removed before verification.  The length of fields containing tags
   has to be adapted.  Apart from that, the existing coding must not be
   modified.

検証の場合には、1EvidenceRecordだけがCMS物に含まれているなら、ハッシュ値はCMS物の上に1EvidenceRecordなしで発生しなければなりません。 これは、属性が検証の前に取り除かれなければならないことを意味します。 タグを含む分野の長さは適合させられなければなりません。 それは別として、既存のコード化を変更してはいけません。

   If several Archive Timestamps occur, the data object has to be
   generated as follows:

数個のアーカイブTimestampsが起こるなら、データ・オブジェクトは以下の通り発生しなければなりません:

   o  During verification of the first (in chronological order)
      EvidenceRecord, all EvidenceRecord have to be removed in order to
      generate the data object.

o 最初(年代順に)のEvidenceRecordの検証の間、すべてのEvidenceRecordが、データ・オブジェクトを発生させるように取り外されなければなりません。

   o  During verification of the nth one EvidenceRecord, the first n-1
      attributes should remain within the CMS object.

o n番目の1EvidenceRecordの検証の間、最初のn-1属性はCMS物に残るべきです。

   o  The verification of the nth one EvidenceRecord must result in a
      point of time when the document must have existed with the first n
      attributes.  The verification of the n+1th attribute must prove
      that this requirement has been met.

o n番目の1EvidenceRecordの検証はドキュメントが最初のn属性で存在したに違いない時のポイントをもたらさなければなりません。 n+最初の属性の検証は、この必要条件を満たしてあると立証しなければなりません。

Appendix B.  ASN.1-Module with 1988 Syntax

1988年の構文がある付録B.ASN.1-モジュール

   ASN.1-Module

ASN.1-モジュール

   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) }
   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

ERSのiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)ltans(11)イドモッズ風の(0)イド-mod-ers88(2)イド-mod-ers88-v1(1)、DEFINITIONS IMPLICIT TAGS:、:= 始まってください。

   -- EXPORTS ALL --

-- すべてを輸出します--

   IMPORTS

輸入

    -- Imports from RFC 3852 Cryptographic Message Syntax
   ContentInfo, Attribute

-- RFC3852の暗号のメッセージから、構文ContentInfo、属性を輸入します。

Gondrom, et al.             Standards Track                    [Page 27]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[27ページ]。

       FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
        { iso(1) member-body(2) us(840) rsadsi(113549)
          pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

[RFC3852]からのCryptographicMessageSyntax2004からiso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)

     -- Imports from RFC 3280 [RFC3280], Appendix A.1
   AlgorithmIdentifier
       FROM PKIX1Explicit88
           { iso(1) identified-organization(3) dod(6)
           internet(1) security(5) mechanisms(5) pkix(7)
           mod(0) pkix1-explicit(18) }
   ;

-- RFC3280[RFC3280]からの輸入、Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)モッズ(0)pkix1明白な(18)。

   ltans OBJECT IDENTIFIER ::=
            { iso(1) identified-organization(3) dod(6) internet(1)
              security(5) mechanisms(5) ltans(11) }

ltans OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)ltans(11)

   EvidenceRecord ::= SEQUENCE {
      version                   INTEGER { v1(1) } ,
      digestAlgorithms          SEQUENCE OF AlgorithmIdentifier,
      cryptoInfos               [0] CryptoInfos OPTIONAL,
      encryptionInfo            [1] EncryptionInfo OPTIONAL,
      archiveTimeStampSequence  ArchiveTimeStampSequence
      }

EvidenceRecord:、:= 系列バージョンINTEGER v1(1)、digestAlgorithms SEQUENCE OF AlgorithmIdentifier、cryptoInfos[0]CryptoInfos OPTIONAL、encryptionInfo[1]EncryptionInfo OPTIONAL、archiveTimeStampSequence ArchiveTimeStampSequence

   CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute

CryptoInfos:、:= 属性の系列サイズ(1..MAX)

   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     attributes      [1] Attributes OPTIONAL,
     reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
     timeStamp       ContentInfo}

ArchiveTimeStamp:、:= 系列digestAlgorithm[0]AlgorithmIdentifier OPTIONAL、属性[1]属性OPTIONAL、reducedHashtree[2]SEQUENCE OF PartialHashtree OPTIONAL、timeStamp ContentInfo

   PartialHashtree ::= SEQUENCE OF OCTET STRING

PartialHashtree:、:= 八重奏ストリングの系列

   Attributes ::= SET SIZE (1..MAX) OF Attribute

属性:、:= 属性のサイズ(1..MAX)を設定してください。

   ArchiveTimeStampChain    ::= SEQUENCE OF ArchiveTimeStamp

ArchiveTimeStampChain:、:= ArchiveTimeStampの系列

   ArchiveTimeStampSequence ::= SEQUENCE OF
                                ArchiveTimeStampChain

ArchiveTimeStampSequence:、:= ArchiveTimeStampChainの系列

   EncryptionInfo       ::=     SEQUENCE {

EncryptionInfo:、:= 系列

Gondrom, et al.             Standards Track                    [Page 28]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[28ページ]。

       encryptionInfoType     OBJECT IDENTIFIER,
       encryptionInfoValue    ANY DEFINED BY encryptionInfoType}

encryptionInfoType物の識別子、encryptionInfoTypeによって少しも定義されたencryptionInfoValue

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

イドaa、えー、内部、OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)49をメンバーと同じくらい具体化させます。

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

イドaa、えー、外部、OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)50をメンバーと同じくらい具体化させます。

   END

終わり

Appendix C.  ASN.1-Module with 1997 Syntax

1997年の構文がある付録C.ASN.1-モジュール

   ASN.1-Module

ASN.1-モジュール

   ERS {iso(1) identified-organization(3) dod(6)
         internet(1) security(5) mechanisms(5)
         ltans(11) id-mod(0) id-mod-ers(1) id-mod-ers-v1(1) }
   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

ERS、iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)ltans(11)イドモッズ(0)イドモダー(1)イドモッズers-v1(1)、DEFINITIONS IMPLICIT TAGS:、:= 始まってください。

   -- EXPORTS ALL --

-- すべてを輸出します--

   IMPORTS

輸入

    -- Imports from PKCS-7
   ContentInfo
       FROM PKCS7
           {iso(1) member-body(2) us(840) rsadsi(113549)
           pkcs(1) pkcs-7(7) modules(0)}

-- PKCS7からのPKCS-7 ContentInfoからの輸入iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-7(7)モジュール(0)

     -- Imports from AuthenticationFramework
   AlgorithmIdentifier
       FROM AuthenticationFramework
           {joint-iso-itu-t ds(5) module(1)
           authenticationFramework(7) 4}

-- AuthenticationFrameworkからのAuthenticationFramework AlgorithmIdentifierからの輸入共同iso-itu t ds(5)モジュール(1)authenticationFramework(7)4

    -- Imports from InformationFramework
   Attribute
       FROM InformationFramework
           {joint-iso-itu-t ds(5) module(1)
           informationFramework(1) 4}
   ;

-- InformationFramework Attribute FROM InformationFramework共同iso-itu t ds(5)モジュール(1)informationFramework(1)4からの輸入。

   ltans OBJECT IDENTIFIER ::=
            { iso(1) identified-organization(3) dod(6) internet(1)
              security(5) mechanisms(5) ltans(11) }

ltans OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)ltans(11)

Gondrom, et al.             Standards Track                    [Page 29]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[29ページ]。

   EvidenceRecord ::= SEQUENCE {
      version                   INTEGER { v1(1) } ,
      digestAlgorithms          SEQUENCE OF AlgorithmIdentifier,
      cryptoInfos               [0] CryptoInfos OPTIONAL,
      encryptionInfo            [1] EncryptionInfo OPTIONAL,
      archiveTimeStampSequence  ArchiveTimeStampSequence
      }

EvidenceRecord:、:= 系列バージョンINTEGER v1(1)、digestAlgorithms SEQUENCE OF AlgorithmIdentifier、cryptoInfos[0]CryptoInfos OPTIONAL、encryptionInfo[1]EncryptionInfo OPTIONAL、archiveTimeStampSequence ArchiveTimeStampSequence

   CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute
           (WITH COMPONENTS {
              ...,
              valuesWithContext   ABSENT
            })

CryptoInfos:、:= 属性の系列サイズ(1..MAX)(コンポーネントが…で、valuesWithContext欠けている)

   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     attributes      [1] Attributes OPTIONAL,
     reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
     timeStamp       ContentInfo}

ArchiveTimeStamp:、:= 系列digestAlgorithm[0]AlgorithmIdentifier OPTIONAL、属性[1]属性OPTIONAL、reducedHashtree[2]SEQUENCE OF PartialHashtree OPTIONAL、timeStamp ContentInfo

   PartialHashtree ::= SEQUENCE OF OCTET STRING

PartialHashtree:、:= 八重奏ストリングの系列

   Attributes ::= SET SIZE (1..MAX) OF Attribute
           (WITH COMPONENTS {
              ...,
              valuesWithContext   ABSENT
            })

属性:、:= 属性のサイズ(1..MAX)を設定してください。(コンポーネントが…で、valuesWithContext欠けている)

   ArchiveTimeStampChain    ::= SEQUENCE OF ArchiveTimeStamp

ArchiveTimeStampChain:、:= ArchiveTimeStampの系列

   ArchiveTimeStampSequence ::= SEQUENCE OF
                                ArchiveTimeStampChain

ArchiveTimeStampSequence:、:= ArchiveTimeStampChainの系列

   EncryptionInfo       ::=     SEQUENCE {
       encryptionInfoType   ENCINFO-TYPE.&id
                                      ({SupportedEncryptionAlgorithms}),
       encryptionInfoValue  ENCINFO-TYPE.&Type
                  ({SupportedEncryptionAlgorithms}{@encryptionInfoType})
   }

EncryptionInfo:、:= 系列encryptionInfoType ENCINFO-TYPE encryptionInfoValue ENCINFO-TYPEイド(SupportedEncryptionAlgorithms)、タイプ、(SupportedEncryptionAlgorithms、@encryptionInfoType)

   ENCINFO-TYPE ::= TYPE-IDENTIFIER

以下をENCINFOタイプしてください:= タイプ識別子

   SupportedEncryptionAlgorithms ENCINFO-TYPE ::= {...}

以下をSupportedEncryptionAlgorithms ENCINFOタイプしてください:= {...}

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

イドaa、えー、内部、OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)49をメンバーと同じくらい具体化させます。

   id-aa-er-external  OBJECT IDENTIFIER ::= { iso(1) member-body(2)

イドaa、えー、外部、OBJECT IDENTIFIER:、:= iso(1)メンバーボディー(2)

Gondrom, et al.             Standards Track                    [Page 30]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[30ページ]。

      us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 50 }

私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)50

   END

終わり

Authors' Addresses

作者のアドレス

   Tobias Gondrom
   Open Text Corporation
   Werner-von-Siemens-Ring 20
   Grasbrunn, Munich  D-85630
   Germany

トビアスGondromオープンテキスト社のヴェルナーフォンジーメンス一味20Grasbrunn、ミュンヘンD-85630ドイツ

   Phone: +49 (0) 89 4629-1816
   Fax:   +49 (0) 89 4629-33-1816
   EMail: tobias.gondrom@opentext.com

以下に電話をしてください。 +49 (0) 89 4629-1816Fax: +49 (0) 89 4629-33-1816 メールしてください: tobias.gondrom@opentext.com

   Ralf Brandner
   InterComponentWare AG
   Industriestra?e 41
   Walldorf  D-69119
   Germany

ラルフBrandner InterComponentWare株式会社Industriestra?e41Walldorf D-69119ドイツ

   EMail: ralf.brandner@intercomponentware.com

メール: ralf.brandner@intercomponentware.com

   Ulrich Pordesch
   Fraunhofer Gesellschaft
   Rheinstra?e 75
   Darmstadt  D-64295
   Germany

ユーリッヒPordeschフラウンホーファー利益社会Rheinstra?e75ダルムシュタットD-64295ドイツ

   EMail: ulrich.pordesch@zv.fraunhofer.de

メール: ulrich.pordesch@zv.fraunhofer.de

Gondrom, et al.             Standards Track                    [Page 31]

RFC 4998                          ERS                        August 2007

Gondrom、他 規格はERS2007年8月にRFC4998を追跡します[31ページ]。

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機能のための基金は現在、インターネット協会によって提供されます。

Gondrom, et al.             Standards Track                    [Page 32]

Gondrom、他 標準化過程[32ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ATAN関数 逆タンジェント(アークタンジェント)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る