ネットワーク WG
Request for Comments: 3628
分類: 情報提供


 

D. Pinkas
Bull
N. Pope
J. Ross
Security & Standards
2003年11月

English

TSA についてのポリシー要件
(Policy Requirements for Time-Stamping Authorities (TSAs))

このメモの位置づけ

この文書は、インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、改善するために議論と示唆を求めるものです。このメモの配布に制限はありません。

著作権表記

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

要旨

本書は、TSA(Time Stamping Authority)が、公開鍵証明書によってサポートされた、1 秒以内の精度をもつタイムスタンプトークンを発行するための最低限のタイムスタンプポリシーについての要件を規定します。TSA は、本書中に規定されたポリシーを拡張して自らのポリシーを規定することができます。このようなポリシーは、本書において識別された要件を、組み込むか、あるいは、さらに絞り込むものとなります。

目次

1.  はじめに

2.  概要

3.  定義と短縮語

3.1. 定義
3.2. 短縮語

4.  一般的な概念

4.1. タイムスタンピングサービス
4.2. TSA
4.3. 加入者
4.4. タイムスタンプポリシーと TSA 実施規定
     4.4.1.  目的
     4.4.2.  特性のレベル
     4.4.3.  アプローチ

5.  タイムスタンプポリシー

5.1. 概要
5.2. 識別
5.3. ユーザコミュニティと適用可能性
5.4. 準拠性

6.  社会的義務と法的義務

6.1. TSA の社会的義務
     6.1.1.  一般
     6.1.2.  TSA の加入者に対する社会的義務
6.2. 加入者の社会的義務
6.3. 信頼者の社会的義務
6.4. 法的義務

7.  TSA の実施についての要件

7.1. 実施規定と開示規定
     7.1.1.  TSA 実施規定
     7.1.2.  TSA 開示規定
7.2. 鍵管理のライフサイクル
     7.2.1.  TSU 鍵の生成
     7.2.2.  TSU プライベート鍵の防護
     7.2.3.  TSU 公開鍵の配布
     7.2.4.  TSU 鍵の再生成
     7.2.5.  TSU 鍵の有効期限
     7.2.6.  タイムスタンプ署名用の暗号モジュールのライフサイクル管理
7.3. タイムスタンピング
     7.3.1.  タイムスタンプトークン
     7.3.2.  時計を UTC に同期させる
7.4. TSA の管理と運用
     7.4.1.  セキュリティマネジメント
     7.4.2.  資産の区分と管理
     7.4.3.  要員のセキュリティ
     7.4.4.  物理的セキュリティと環境的セキュリティ
     7.4.5.  運用の管理
     7.4.6.  システムへのアクセスの管理
     7.4.7.  信頼に値するシステムの開発と保守
     7.4.8.  TSA サービスの侵害
     7.4.9.  TSA の廃業
     7.4.10. 法的要件への準拠性
     7.4.11. タイムスタンピングサービスの運用に関する情報の記録
7.5. 組織論

8.  セキュリティに関する考慮事項

9.  謝辞

10. 参考文献

    10.1. 規範的参考文献
    10.2. 参考資料

補遺 A (参考資料): UTC(Coordinated Universal Time)

補遺 B (参考資料): 実装アーキテクチャとタイムスタンピングサービスについて可能な事項

補遺 C (参考資料): タイムスタンプトークンの長期的検証

補遺 D (参考資料): TSA 開示規定の構成のモデル

著者のアドレス

著作権表記全文

 

1.  はじめに English

この情報提供 RFC の内容は、技術的に、ETSI TS 102 023 V 1.2.1 (2002-06) [TS 102023] と同等のものです。ETSI TS は、ETSI の著作権のもとにあります。この ETSI の配布物の複製は、http://www.etsi.org からダウンロードできます。

信頼でき、かつ、管理可能なデジタル証拠を作成する際に、それらが後日、相互に比較できるように、時刻データをトランザクションに関連づける手法について合意していることが、必要不可欠です。この証拠の品質は、イベントを表現するデータ構造を作成して管理することと、「現実世界と結びつけるパラメータとしてのデータポイントの品質」に基づきます。この例においては、これらは、時刻データと、「どのように、時刻データは、適用されたか?」です。

典型的なトランザクションは、デジタル署名された文書です。ここでは、「署名者からのデジタル署名は、その署名者の証明書が有効であったときに適用されたこと」を証明することが必要不可欠です。

あるデジタル署名値に適用されたタイムスタンプもしくはタイムマークは、「そのデジタル署名は、そのタイムスタンプ(もしくは、タイムマーク)中の日付より前に作成されたこと」を証明します。(タイムマークは、信用される第三者からのセキュアな監査証跡に保存された監査記録です。)

「デジタル署名が署名者の証明書が有効な期間になされた」というためには、そのデジタル署名は、検証されなければならず、下記の条件を満たさなければなりません。:

  1. タイムスタンプ(もしくは、タイムマーク)は、署名者の証明書の有効期限内になされたこと。
     
  2. タイムスタンプ(もしくは、タイムマーク) は、その署名者の証明書が失効されていない間か、あるいは、証明書の失効日前になされたこと。

それゆえ、この作法で適用されたタイムスタンプ(もしくは、タイムマーク)は、「そのデジタル署名は、署名者の証明書が有効な期間中になされたこと」を提供します。この概念は、あらゆる証明書チェーンの全体にわたって、デジタル署名の有効性を提供します。

この場合を扱うためのポリシー要件が、本書を書いた主要な動機です。しかし、これらのポリシー要件は、他のニーズに対応するためも使えるようにする必要があります。

電子的なタイムスタンプは、電子署名の重要なコンポーネントとして、産業界から注目を集めつつあります。これは、ETSI の 電子署名フォーマット標準 [TS101733]、もしくは、(タイムスタンププロトコル [RFC 3161] 上に策定されている)長期電子署名用の電子署名フォーマット [RFC 3126] によっても、とりあげられています。合意された最低限のセキュリティと品質の要件は、長期電子署名の信用に値する検証を確保するために、必要不可欠です。

European Directive 1999/93/EC [Dir 99/93/EC] は、認証(certification)サービスを「証明書を発行するか、あるいは、電子署名に関する他のサービスを提供する実態もしくは法人もしくは自然人」と定義しています。認証サービスプロバイダーの一例は、タイムスタンピング機関です。

本書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" および "OPTIONAL" は、BCP 14, RFC 2119 [RFC 2119] に記述されているように解釈されるべきものです。

 

2.  概要 English

これらのポリシー要件は、適格な電子署名のサポートにおいて使われるタイムスタンピングサービスを対象としています。(すなわち、電子署名のためのコミュニティのフレームワークについての "the European Directive" の article 5.1 と整合しています。)しかし、これは、「あるデータが、特定の時刻以前に存在したこと」を提供することを要求する、あらゆるアプリケーションに適用される可能性があります。

これらのポリシー要件は、公開鍵暗号技術、公開鍵証明書および信頼できる時刻の源泉の利用に基づきます。本書は、「TSA は、タイムスタンピングサービスを提供することについて信用できること」を確認するための基礎として独立主体によって使われる可能性があります。

本書は、UTC(Coordinated universal time) をもっており、TSU によってデジタル的に署名された TST を発行している TSA を同期化するための要件に対応します。

加入者と 信頼者は、「具体的に、どのように、このタイムスタンプポリシーは、その特定の TSA によって実施されているか?」の詳細を入手するために TSA の実施規定にあたる必要があります。(例: このサービスを提供する際に使われるプロトコル。)

本書は、下記の事項については、規定しません。:

注 1: タイムスタンピングプロトコルは、RFC 3161 [RFC 3161] に規定されており、TS 101 861 [TS 101861] に、その属性が書かれています。

 

注 2: CEN Workshop Agreement 14172 "EESSI Conformity Assessment Guidance" 参照。[CWA 14172]

 

3.  定義と短縮語 English

3.1.  定義 English

本書の目的については、下記の用語と定義が適用されます。:

注: 定義が参照された文書からコピーされている場合、これらは、その定義の最後に、参照の識別番号を含めて示しています。

信頼者(relying party):

タイムスタンプトークンに依拠するそのタイムスタンプトークンの受信者。

加入者(subscriber):

TSA によって提供されるサービスを要求する主体。この者は、明示的に、あるいは、黙示的に、その期間と条件に合意しています。

TST(Time Stamp Token:タイムスタンプトークン):

一定のデータを特定の時刻に結合するデータオブジェクト。それゆえ、「そのデータは、その時点以前に存在していた」という証拠を確立する。

TSA(Time Stamping Authority:タイムスタンピング機関):

タイムスタンプトークンを発行する機関。

TSA 開示規定:

例えば、規制要件に適合するようにするために、加入者や 信頼者宛に強調したり、あるいは、開示するようことを特別に要する TSA のポリシーと実践についての言明の集合。

TSA 実施規定:

TSA がタイムスタンプトークンを発行する際に採用する実践についての言明。

TSA システム:

タイムスタンピングサービスの規定をサポートするために組織化された IT 製品とコンポーネントから構成されるもの。

タイムスタンプポリシー:

特定のコミュニティに対するタイムスタンプトークンの適用可能性、および/または、共通のセキュリティ要件についての適用のクラスを示す、命名されたルールの集合。

タイムスタンピングユニット:

単ユニットとして管理されており、一定時点においては単一のアクティブなタイムスタンプトークン署名用の鍵をもつハードウェアとソフトウェアの集合。

UTC(Coordinated Universal Time):

ITU-R Recommendation TF.460-5 [TF.460-5] において規定されているように、秒に基づく時間の尺度。

注: ほとんどの実践的な用途において、UTC は、本初子午線(prime meridian)における「太陽時(solar time)」と同義です。より具体的に、UTC は、安定性の高い原子時(TAI: Temps Atomique International)と、不規則な地球の自転から得られる太陽時の折衷です。(「グリニッジに関する」とは、慣例的な関係による恒星時(GMST)を意味します。)(より詳細については、補遺 A 参照。)

UTC(k):

「k 研究所」によって実現されており、誤差プラス/マイナス 100 ナノ秒を達成するという目標をもって UTC との密接な関係が保たれている時刻の尺度。(ITU-R Recommendation TF.536-1 [TF.536-1])

注: UTC(k) の「k 研究所」のリストは、BIPM によって配布されている Circular T の第 1 章にあり、BIPM の web サイト(http://www.bipm.org/)から入手可能です。

3.2.  短縮語 English

本書においては、下記の短縮語が使われます。:

TSA  タイムスタンピング機関
TSU  タイムスタンピングユニット
TST  タイムスタンプトークン
UTC(Coordinated Universal Time)

 

4.  一般的な概念 English

4.1.  タイムスタンピングサービス English

タイムスタンピングサービスの規定は、要件を区分するために、下記のコンポーネントサービスに細分化されます。:

このサービスの分割は、本書中に規定されている要件を明確化するためだけにあるものであり、タイムスタンピングサービスの実施の分割について、何ら制限するものではありません。

4.2.  TSA English

タイムスタンピングサービスのユーザ(すなわち、加入者と信頼者)によって信用されている TST を発行する機関は、TSA(タイムスタンピング機関)と呼ばれています。TSA は、4.1 節において識別されたタイムスタンピングサービスについて、全体の責任を負います。TSA は、その TSA の代わりに作成・署名する、ひとつ、もしくは、複数の TSU の運用について、責任を負います。TST の発行に責任を負う TSA は、識別可能です。 (7.3.1 h 参照)

TSA は、タイムスタンピングサービスの部分を提供するために、他の主体を使う可能性があります。しかし、TSA は、常に、全般的な責任を維持管理し、「本書において識別されたポリシー要件に適合すること」を確保します。例えば、TSA は、TSU の鍵を使って TST を生成するサービスを含む、すべてのコンポーネントサービスを再請負に出す可能性があります。しかし、TST を生成するために使われるプライベート鍵、もしくは、鍵は、本書中の要件に適合することについての責任全体を維持管理する TSA に帰属します。

TSA は、いくつかの識別可能なTSUを運用する可能性があります。各ユニットは、異なる鍵をもちます。(可能な実装については、補遺 B を参照。)

TSA は、電子署名についての EU ダイレクティブ(article 2(11) 参照)において規定されているように、TST を発行する認証サービスプロバイダーです。

4.3.  加入者 English

加入者は、数人のエンドユーザから成る組織体である可能性もあれば、個人のエンドユーザである可能性があります。

加入者が組織体であるとき、その組織体に適用される義務のうちのいくつかは、そのエンドユーザにも適用する必要があります。それゆえ、組織体が責任を負う、どのような場合においても、そのエンドユーザからの義務が正しく満たされていない場合、その組織体には、そのエンドユーザ宛てに適切に知らせることが期待されます。

加入者がエンドユーザであるとき、そのエンドユーザは、その義務が正しく果たされない場合、直接的に責任を負います。

4.4.  タイムスタンプポリシーと TSA 実施規定 English

この節については、「タイムスタンプポリシー」と「TSA 実施規定」に関する役割を説明します。「タイムスタンプポリシー」もしくは「TSA 実施規定」の形態については、制約しません。

4.4.1.  目的 English

一般に、「タイムスタンプポリシー」は、「何に準拠すべきか?」を述べる一方、「TSA 実施規定」は、「どのように準拠するか?(すなわち、タイムスタンプの作成と、その時計の正確性の維持管理の際に行われるプロセス)」を述べます。「タイムスタンプポリシー」と「TSA 実施規定」の関係は、事業の要件について言明する他のビジネスポリシーの関係と同様の性格をもつ一方、運用的なユニットは、「どのように、これらのポリシーは、実施されるべきか?」の詳細と手順を規定します。

本書は、信用されるタイムスタンピングサービスについての一般要件に適合するように「タイムスタンプポリシー」を規定しています。TSA は、TSA 実施規定において、「どのように、これらの要件は、適合されるか?」を規定します。

4.4.2.  特性のレベル English

「TSA 実施規定」は、「タイムスタンプポリシー」より具体的です。「TSA 実施規定」は、期間と条件と、発行する際、あるいは、タイムスタンピングサービスを管理する際の TSA のビジネスと運用的な実践についての、より詳細な記述です。TSA の「TSA 実施規定」は、「タイムスタンプポリシー」によって確立されるルールを強要します。「TSA 実施規定」は、「どのように、ある特定の TSA が「タイムスタンプポリシー」中に識別された技術的要件、組織論的要件および手続的要件に適合するか?」を規定します。

注: たとえ重要度が低い内部文書であっても、TSA がその「TSA 実施規定」において識別された実践を完遂するための必要不可欠な具体的手順を詳細化するために、適切である可能性があります。

4.4.3.  アプローチ English

「タイムスタンプポリシー」のアプローチは、「TSA 実施規定」とは、まったく異なります。「タイムスタンプポリシー」は、TSA 固有の運用環境の具体的な詳細とは独立に規定されます。一方、「TSA 実施規定」は、組織論的な構造、運用手順、施設、および TSA のコンピューティング環境に合わせて仕立てられます。「タイムスタンプポリシー」は、タイムスタンプサービスのユーザによって規定される可能性があります。一方、「TSA 実施規定」は、常に、プロバイダによって規定されます。

 

5.  タイムスタンプポリシー English

5.1.  概要 English

「タイムスタンプポリシー」は、「TST の特定のコミュニティに対する適用可能性、および/または、共通のセキュリティ要件をもつアプリケーションのクラスを示す命名されたルールの集合」です。(3.1 節 および 4.4 節 参照)

本書は、TSA が 1 秒以内の精度をもつ公開鍵証明書によってサポートされた TST を発行することについて、基礎となる「タイムスタンプポリシー」についての要件を規定しています。

注 1: その信頼者は、追加的手段が無くては、サポートしている証明書の有効期間を越えて TST の有効性を確認することができない可能性があります。TSU の証明書の有効期間以降の TST の有効性の検証については、補遺 C 参照。

本書中に規定されたポリシーを拡張する TSA は、自身のポリシーを規定する可能性があります。このようなポリシーは、本書において識別された要件を組み込むか、あるいは、さらに制約するものとします。

1 秒以内の正確性が TSA によって提供される場合で、かつ、すべての TSU が、その同じ特徴をもつ場合、その正確性は、「各 TST は、1 秒以内の精度をもって発行される」という TSA の開示規定中に示されるものとします(7.1.2 節 参照)。

注 2: 「TST は、適用可能なポリシーについての識別子を含むこと」が要求されます。(7.3.1 節 参照)

5.2.  識別 English

基本線となる「タイムスタンプポリシー」のオブジェクト識別子 [X.208] は、下記のとおり。:
itu-t(0) identified-organization(4) etsi(0) time-stamp-policy(2023) policy-identifiers(1) baseline-ts-policy (1)

加入者と 信頼者が利用可能となっている「TSA 開示規定」において、TSA は、その準拠性を示すために、その「タイムスタンプポリシー」についての識別子も含むものとします。

5.3.  ユーザコミュニティと適用可能性 English

このポリシーは、長期の有効性(例: TS 101 733 [TS 101733] に規定されているもの)のための適格な電子署名(European Directive on Electronic Signatures 参照) についてのタイムスタンピングの要件に適合することを目的にしていますが、一般に、同等の品質についての、あらゆる要件に適用可能です。

このポリシーは、公的なタイムスタンピングサービス、もしくは、閉じたコミュニティ内で使われるタイムスタンピングサービスに使われる可能性があります。

5.4.  準拠性 English

TSA は、5.2 節 にあるように、TST 中の「タイムスタンプポリシー」についての識別子を使うか、あるいは、自身の「タイムスタンプポリシー」を規定するものとします。これは、本書において識別された要件を組み込んだり、あるいは、絞り込んだりします。:

a) その TSA が識別された「タイムスタンプポリシー」への準拠性を主張し、加入者と信頼者が準拠性の主張を裏付ける証拠を求めれば入手できるようにする場合

b) その TSA が、独立主体によって、識別された「タイムスタンプポリシー」に照らして確認する評価がなされた場合

準拠する TSA は、下記の事項を実証しなければなりません。:

a) 6.1 節 に規定されているように、その社会的義務に適合すること。

b) 7 章に規定された要件に適合するコントロールを実施していること。

 

6.  社会的義務と法的義務 English

6.1.  TSA の社会的義務 English

6.1.1.  一般 English

TSA は、「7 章 に詳細に述べてある TSA についてのすべての要件は、選択された『信用されるタイムスタンプポリシー』について適用可能なものとして実施されていること」を確保するものとします。

TSA は、たとえ、その TSA 機能が再請負契約先によって行われるときでも、このポリシーに書かれた手順への準拠性を確保するものとします。

TSA は、タイムスタンプ中に(直接、あるいは、参照によって)示された、あらゆる追加的義務への準拠性を確保するものとします。

TSA は、そのすべてのタイムスタンピングサービスを、その実施規定に準拠して提供するものとします。

6.1.2. 加入者に対する TSA の社会的義務 English

TSA は、(そのサービスの利用可能性と精度を含む)期間と条件について行った自身の主張に合致するものとします。

6.2.  加入者の社会的義務 English

本書は、TSA の期間と条件に言明されている事項以外には、加入者について、具体的な義務を設けません。

注: 「TST を取得するとき、その加入者は、『その TST が正しく署名されていること』と、『TST に署名するために使われるプライベート鍵は、侵されていないこと』を検証すること」が助言されます。

6.3.  信頼者の社会的義務 English

信頼者が利用可能とされた期間と条件(7.1.2 節 参照)は、「TST に依拠する際の、信頼者の社会的義務」を含むものとします。:

a) 「TST は、正しく署名されたこと」と、「タイムスタンプに署名するために使われるプライベート鍵は、検証時点までに侵されていないこと」を検証する。

注: 検証する時点が対象の証明書の有効期限を過ぎている場合、TSU の証明書の有効期間の間、署名用の鍵の有効性は、当該 TSU の証明書についての現在の「失効ステータス(状態(項目))」を使ってチェックすることができます。(ガイダンスについては、補遺 C 参照。)

b) 「タイムスタンプポリシー」によって示されたタイムスタンプの利用法についてのあらゆる制限を考慮する。

c) 契約等において指示された、あらゆる他の予防策を考慮する。

 

6.4.  法的義務 English

本書は、法的義務について、いかなる要件も規定しません。特に、「TSA は、別途、適用可能な法律に明記されない限り、あらゆる法的義務を否認/制限する可能性があること」を知っておく必要があります。


7.  TSA 実践についての要件 English

TSA は、下記の要件に適合するコントロールを実施するものとします。

これらのポリシー要件は、TSA サービスについて課す、いかなる制約も意図していません。

要件は、セキュリティのための観点から示され、「これらの目的に適合すること」を確保することが必要不可欠である場合、これらの目的に適合するためのコントロールについての、より詳細な要件を従えます。

注: 目的に適合するために要求されるコントロールの詳細は、必要不可欠な事項を確保する一方、TSA が TST を発行する際に採用する可能性のあるテクニックについての制約を最小化することのバランスです。7.4 節(TSA の管理と運用)の場合、より詳細なコントロール要件の情報源に対して参照されます。これらの要素に起因して、ある論点についての要件の具体的な程度は、多様である可能性があります。

リクエストに対応する TST の規定は、その TSA の考え方次第であり、その加入者とのあらゆる SLA(サービスレベルについての合意)に依存します。

7.1.  実施規定と開示規定 English

7.1.1.  TSA 実施規定 English

TSA は、「タイムスタンピングサービスを提供するために必要不可欠な信頼性を実証すること」を確保するものとします。

特記事項:

a) TSA は、必要不可欠なセキュリティコントロールや運用的な手順を判断するために、事業資産や、それらの資産に対する脅威を評価するためにリスク分析を行うものとします。

b) TSA は、このタイムスタンプポリシー中で識別される、すべての要件に対応するために使われる実践と手順についての言明をもつものとします。

注 1: このポリシーは、「TSA 実施規定」の構成に関して、要件を設けません。

c) 「TSA 実施規定」は、適用可能なポリシーと実践を含む TSA サービスをサポートしているすべての外部の組織体の義務を識別するものとします。

d) TSA は、そのタイムスタンプポリシーへの準拠性を評価するために必要不可欠なものとして、加入者および信頼者宛に、その実施規定および他の関連する文書を入手可能にするものとします。

注 2: TSA は、一般に、その実践の詳細のすべてを公にすることは要求されません 。

e) TSA は、7.1.2 節 において規定されているように、すべての加入者と潜在的な 信頼者宛てに、そのタイムスタンピングサービスの利用に関する期間と条件を開示するものとします。

f) TSA は、「TSA 実施規定」を承認する最終的な権能をもつ上層部の管理主体をもつものとします。

g) TSA の上級経営管理者は、「実践が正しく実施されていること」を確認するものとします。

h) TSA は、TSA 実施規定を維持管理することについての責任を含む実践についてのレビューのプロセスを規定するものとします。

i) TSA は、上記 f) のような承認に従って、その実施規定について意図する変更を通知するもとのし、上記 d) において要求されているように、改訂版の「TSA 実施規定」を、をすぐに入手できるようにします。

7.1.2.  TSA 開示規定 English

TSA は、すべての加入者と潜在的な 信頼者に、そのタイムスタンピングサービスの利用に関する期間と条件を開示するものとします。この言明は、少なくとも、その TSA によってサポートされる各「タイムスタンプポリシー」について規定するものとします。:

a) TSA 連絡先情報

b) 適用されるタイムスタンプポリシー

c) 少なくとも、ひとつのハッシュ化アルゴリズム
これは、タイムスタンプされたデータを再現するために使われる可能性があります。(必須のハッシュルゴリズムは、ありません。)

d) TST に使われる署名の期待される有効期間
(使われているハッシュ化アルゴリズム、使われている署名アルゴリズムおよびプライベート鍵の長さに依存する。)

e) UTC に照らした TST 中の時刻の正確性

f) タイムスタンピングサービスの利用についてのあらゆる制限

g) 6.2 節 に規定されているように、加入者の義務があれば、 加入者の義務

h) 6.3 節 に規定された信頼者の義務

i) 「信頼者は、その TST (6.3 節 参照)を『合理的に信頼している』といえる」ような、「どのように、その TST を検証するか?」についての情報、および、有効期間についてのあらゆる可能性ある制約

j) TSA イベントログ(7.4.10 節 参照)が保持される期間

k) 国内法のもとで、タイムスタンピングサービスについての要件に適合する、あらゆる主張を含む適用可能な法的システム

l) 責任の制限

m) 苦情や争議の解決についての手順

n) 「その TSA は、識別されたタイムスタンプポリシーに準拠していると宣言されているか否か?」その場合、「どの主体によるか?」

注 1: 「TSA が、そのタイムスタンピング開示規定中に、そのサービスの利用可能性についてを含めること」も推奨されます。例えば、タイムスタンピングサービスの失敗間に見積もられる期間、失敗からの復旧のための期間、および、災害復旧(バックアップサービスを含む)について設けられた規定が挙げられます。

この情報は、意思疎通の永続する手段を通じて入手可能なものにします。この情報は、そのまま理解可能な言語で利用可能なものとします。これは、電子的に転送される可能性があります。

注 2: このような意思疎通の基礎として使うことができるモデルとしての「TSA 開示規定」は、補遺 D にあります。代替的に、これは、「加入者との合意」/「信頼者との合意」の一部として提供される可能性があります。これらの「TSA 開示規定」は、それらが読者にとって目立つ(conspicuous)ものであるとき、「TSA 実施規定」に含められる可能性があります。

7.2.  鍵管理のライフサイクル English

7.2.1.  TSA 鍵の生成 English

TSA は、「あらゆる暗号技術的な鍵が、コントロールされた状況において生成されること」を確保するものとします。

特記事項:

a) TSU の署名用の鍵の生成は、少なくとも、デュアルコントロールのもとで、「信用される役割」にたずさわる要員(7.4.3 節 参照)によって、物理的にセキュア化された環境(7.4.4 節 参照)において行われるものとします。この機能を行うことを認可された要員は、その TSA の実践において、そのようにすることが要求される者に制限されるものとします。

b) TSU の署名用の鍵の生成は、下記のいずれかのような暗号モジュール内において行われるものとします。:

c) 署名用の TST の鍵に使われる TSU 鍵の生成アルゴリズム(その結果としての署名用鍵長と署名アルゴリズム)は、あらゆる国家的な監督機関によって認知されるものとするか、あるいは、その TSA によって発行されたように、その TST の目的に適合するものとして、現行法に準拠するものとします。

7.2.2.  TSU プライベート鍵の防護 English

TSA は、「TSU プライベート鍵の守秘」を確保し、そのインテグリティを維持管理するものとします。

特記事項:

a) TSU の署名用のプライベート鍵は、下記のような暗号モジュール中に保持され、使われるものとします。 :

注: TSU のプライベート鍵のバックアップは、鍵の危殆化のリスクを最小化するために止めるべきです。

b) TSU プライベート鍵がバックアップされる場合、それらは、少なくとも、物理的にセキュア化された環境においてデュアルコントロールを使って(7.4.4 節 参照)、「信用される役割」にたずさわる要員のみによって、複製・蓄積・復元されるものとします。この機能を行うことが認可された要員は、その TSA の実践において、そのようにすることが要求される者に制限されるものとします。

c) あらゆる署名用の TSU のプライベート鍵のバックアップ用の複製は、そのデバイス以外に保存される前に暗号モジュールによって、その秘匿性を確保するために防護されるものとします。

7.2.3.  TSU 公開鍵の配布 English

TSA は、「その TSU 署名検証(公開)鍵とあらゆる関連するパラメータのインテグリティおよび真正性は、その信頼者宛ての配布の間、維持管理されていること」を確保するものとします。

特記事項:

a) TSU 署名検証用(公開)鍵は、公開鍵証明書中の信頼者が入手可能なものとします 。

注: 例えば、TSU の証明書は、その TSAと同一主体によって運用される CA によって発行される可能性もあれば、他の機関によって発行される可能性もあります 。

b) TSU の署名検証用の公開鍵証明書は、この「タイムスタンピングポリシー」と同等以上の水準のセキュリティを提供する CPS(訳注:原文では CP となっているが誤り。)に基づいて運用されている CA(認証機関)によって発行されるものとします。

7.2.4.  TSU 鍵の再生成 English

TSU の証明書の有効期間は、「選択されたアルゴリズムと鍵長は、目的に適すると考えられる」期間より長くないものとします。(7.2.1 c) 参照)

注 1: 下記の追加的な考慮事項は、有効期間を制限するときに適用されます。:

注 2: TSU 鍵の侵害は、使われている暗号モジュールの特徴によるのみならず、(その機能がサポートされているときには)システムの初期化と鍵のエキスポートの際に行われる手順にも、依存します。

7.2.5.  TSU 鍵の有効期限 English

TSA は、「TSU プライベート 署名用鍵は、それらの有効期限を越えて使われていないこと」を確保するものとします。

特記事項:

a) 運用的手順もしくは技術的手順は、「TSU の鍵の期限が切れるとき、新しい鍵が投入されること」を確保するために整備されているものとします。

b) 複製を含む TSU プライベート署名用の鍵、もしくは、あらゆる鍵の部分は、そのプライベート鍵が取得できないように破壊されるものとします。

c) その TST 生成システムは、その署名用のプライベート鍵の有効期限が切れた場合、TST を発行する、いかなる試みも棄却するものとします(SHALL)

7.2.6.  タイムスタンプ署名用の暗号モジュールのライフサイクル管理 English

TSA は、暗号技術的ハードウェアのセキュリティを、そのライフサイクルを通じて確保するものとします。

特に、TSA は、下記の事項を確保するものとします。:

a) TST に署名する暗号技術的ハードウェアは、出荷の過程において、不正にいじられていないこと。

b) TST に署名する暗号技術的ハードウェアは、保管時に不正にいじられていないこと。

c) 暗号技術的ハードウェア中の TSU の署名用の鍵のインストール、アクティベートおよび複製の作成は、少なくとも、物理的にセキュア化された環境におけるデュアルコントロールを使って、信用される役割を担う要員によってのみ行われるものとします。(7.4.4 節 参照)

d) TST に署名する暗号技術的ハードウェアは、正しく機能していること。

e) TSU 暗号モジュール中に保存された TSU の署名用プライベート鍵は、デバイスの廃棄の際に消去されること。

7.3.  タイムスタンピング English

7.3.1.  タイムスタンプトークン English

TSA は、「TST がセキュアに発行され、正しい時刻をもつこと」を確保するものとします。

特記事項:

a) その TST は、「タイムスタンプポリシー」についての識別子を含むものとします 。

b) 各 TST は、固有な識別子をもつものとします。

c) TSU が TST 中に使う時刻の値は、少なくとも UTC(k) の「k 研究所」によって配信される本当の時刻の値のひとつを追跡可能なものとします。

注 1: BIPM(Bureau International des Poids et Mesures)は、世界中の国立計量機関や国立天文台にある原子時計の大きなアンサンブルから(求められる)現地版の UTC(k) に基づいて、UTC を算出します。BIPM は、UTC を、その月例の Circular T [list 1] を通じて配布しています。これは、BIPM の Web サイト(www.bipm.org)から入手可能であり、これは、公式に認知されている UTC(k) 時刻尺度をもつ、それらすべての機関を識別します。

d) TST 中に含まれる時刻は、このポリシー中に定められた精度内で(その TST 自体の中で規定された精度がある場合、その精度内で)UTC と同期化されるものとします。

e) タイムスタンププロバイダーの時計が、記述された精度(7.1.2 e) 参照)から外れて検出される場合(7.3.2 c) 参照)、TST は、発行されないものとします。

f) TST は、要求者によって提示されたように、タイムスタンプされたデータの表現(例: ハッシュ値)を含むものとします。

g) TST は、完全にこの目的のために生成された鍵を使って署名されるものとします。

注 2: TST についてのプロトコルは、RFC 3631 に規定されており、TS 101 861 [TS 101861] において、その属性が示されています。

注 3: 数多くのリクエストがほぼ同時にあった場合、その TSU 時計の精度の時間内の順番は、強制されません。

h) TST は、下記の事項を含むものとします。:

7.3.2.  時計を UTC に同期させる English

TSA は、「その時計が、宣言された正確さで、UTC と同期していること」を確保するものとします。

特記事項:

a) TSU 時計の時刻合わせは、その時計が、宣言された精度から外れないように期待されるものとなるように維持管理されるものとします。

b) TSU 時計は、その時計合わせを外部に行っている時計について、検出されない変更をもたらす可能性がある脅威から防護されるものとします。

注 1: 脅威には、認可されていない要員による不正な変更(tampering)、電波もしくは電子的なショックが含まれる可能性があります。

c) TSA は、「TST 中に示される時刻が UTC との同期化からずれたり、外れたりする場合、これが検知されること」を確保するものとします。(7.3.1 e) も参照)

注 2: 信頼者には、そのようなイベントについて知らされることが要求されます。(7.4.8 節 参照)

d) TSA は、「時計の同期化は、適切な主体によって通知されて、うるう秒が発生するとき、維持管理されること」を確保するものとします。うるう秒を考慮することに伴う変化は、うるう秒が発生する予定であるとき、その日の最後の分(minute)に発生するものとします。記録は、この変更が発生したとき、正確な時刻を(宣言された精度内で)維持管理されるものとします。(詳細については、補遺 A 参照)

注 3: うるう秒は、秒を飛ばしたり、追加的な秒を UTC 月の最後の秒に加えることによる UTC についての微調整です。第 1 候補は、12月末と 6月末とされており、第 2 候補は、3月末と 9月末とされています。

7.4.  TSA 管理と運用 English

7.4.1.  セキュリティマネジメント English

TSA は、「適用される運用管理手順と管理手順が、適切であり、認識されているベストプラクティスに対応するものであること」を確保するものとします。

特記事項:

TSA 一般

a) TSA は、そのタイムスタンプポリシーの範囲内において、機能が再請負先にアウトソーシングされているか否かに関わらず、すべての局面におけるタイムスタンピングサービスの規定についての責任を保持するものとします。第三者の責任は、その TSA によって、明確に規定されるものとし、「第三者は、その TSA によって要求される、あらゆるコントロールを実施しなければならない」ことを確保するために行われる適切な協定が行われます。TSA は、すべての主体の関連する実践の開示についての責任を保持するものとします。

b) TSA 管理は、そのTSA の情報セキュリティポリシーを規定することに責任を負う、適切な上層部の運用フォーラムを通じて、情報セキュリティについての方向付けを提供するものとします。その TSA は、このポリシーを、これによって影響を受けるすべての従業員に対して発行することと意思疎通を確保するものとします。

c) TSA 内のセキュリティを管理するために必要不可欠な情報セキュリティインフラストラクチャは、常に維持管理されるものとします。提供されるセキュリティのレベルに影響を与えるあらゆる変更は、TSA 管理フォーラムによって承認されるものとします。

注 1: 情報セキュリティインフラストラクチャ、経営管理者層の情報セキュリティフォーラムおよび情報セキュリティポリシーを含む情報セキュリティマネジメントについてのガイダンスについては、ISO/IEC 17799 [ISO 17799] を参照。

d) タイムスタンピングサービスを提供する TSA 施設、システムおよび情報資産についてのセキュリティコントロールおよび運用手順は、文書化され、実施され、保守されるものとします。

注 2: (通常、システムセキュリティポリシー、もしくは、マニュアルと呼ばれる)本書は、提供されるサービスと、7.1.1 a) のもとで要求されるリスクアセスメントと整合する、それらの脅威による影響を避けたり、制限するために要求される対策に関する、すべての関連する標的、対象および潜在的な脅威を識別する必要があります。これは、「どのように、規定されたサービスと、関連するセキュリティ保証が、インシデントや災害についてのポリシー以外に認められているか?」に関するルール、指令および手順を記述する必要があります。

e) TSA は、「情報のセキュリティは、TSA の機能についての責任が、その他の組織体もしくは主体にアウトソーシングされているとき、維持管理されること」を確保するものとします。

7.4.2.  資産の区分と管理 English

TSA は、「その情報と他の資産が適切なレベルの防護を受けること」を確保するものとします。

特記事項:

7.4.3.  要員についてのセキュリティ English

TSA は、「要員と採用の実務は、その TSA の運用についての信用可能性を向上し支援すること」を確保するものとします。

特記事項(TSA 一般):

a) TSA は、提示されたサービスに必要不可欠であり、その職務に適切な、卓越した知識・経験・資格を保持する要員を雇うものとします。

注 1: TSA 要員は、公式な訓練やクレデンシャル、実経験、もしくは、この両者の組み合わせを通じて、「卓越した知識、経験および資格」の要件を満たすことができる必要があります。

注 2: TSA によって雇用されている要員は、その TSA のタイムスタンピングサービスのサポートを行うことについて、契約によって参画している個々の要員を含みます。TSA サービスの監視に参画する可能性がある要員は、TSA 要員でない必要があります。

b) TSA のセキュリティポリシー内に規定されているように、セキュリティの役割と責任は、業務規定中に文書化されるものとします。その TSA の運用のセキュリティが依拠する「信用される役割」は、明確に識別されるものとします。

c) TSA 要員(一時的なスタッフと長期雇用のスタッフの両方)は、職務の分割や最小特権の観点から職務規程が定められ、義務とアクセスレベルに基づく職位の決定、経歴による選考、および、従業員の訓練と啓発を行うものとします。適切であれば、これらは、一般的な機能と TSA 固有の機能を区別するものとします。これらは、スキルと職務経験についての要件を含むものとします。

d) 要員は、その TSA の情報セキュリティマネジメント手順に沿った運用管理的、管理手順および手順を実施するものとします。(7.4.1 節 参照)

注 3: ガイダンスについては、ISO/IEC 17799 [ISO 17799] を参照。

 

下記の追加的コントロールが、タイムスタンピング管理に適用されるものとします。:

e) 管理者層としては、下記の事項をもつ者が雇われるものとします。:

f) 「信用される役割」において、その TSA の運用の公正さについて、偏見を持つ可能性がある、すべての TSA 要員は、利害対立の影響を受けないものとします。

g) 「信用される役割」は、下記の責任を伴う役割を含みます。:

h) TSA 要員は、セキュリティについて責任を負う上級管理者によって、「信用される役割」に、公式に指名されるものとします。

i) TSA は、「信用される役割」もしくは管理職に適任であるかに影響するような深刻な犯罪もしくは他の加害についての前科があることが知られている者は、いかなる人物も任命しないものとします。要員は、あらゆる必要不可欠なチェックが完了するまで、「信用される機能」に対するアクセス権をもたないものとします。

注 4: 国によっては、TSA が、その従業員候補と協働することなく、前科についての情報を取得することは、不可能である可能性があります。

7.4.4.  物理的セキュリティと環境的セキュリティ English

TSA は、「重要度の高いサービスへの物理的アクセスは、コントロールされており、その資産に対する物理的リスクが、最小化されること」を確保するものとします。

特記事項(一般):

a) タイムスタンピング規定とタイムスタンピング管理の両方について:

b) アクセスコントロールは、7.2.1 節7.2.2 節 において識別されているように、暗号モジュールが、そのセキュリティ要件に適合するように提供されるものとします。

c) 下記の追加的コントロールが、タイムスタンピング管理に適用されるものとします。:

注 1: 物理的セキュリティと環境的セキュリティについてのガイダンスとしては、ISO/IEC 17799 [ISO 17799] を参照。

注 2: 他の機能が、そのアクセスが認可された要員に制限される場合、セキュア化された同じ空間において、サポートされる可能性があります。

7.4.5.  運用の管理 English

TSA は、「TSA システムコンポーネントは、セキュア化されており、最小の失敗のリスクで正しく運用されること」を確保するものとします。:

特記事項(一般):

a) TSA システムコンポーネントと情報のインテグリティは、ウイルス・「悪意あるソフトウェア」・「認可されていないソフトウェア」から防護されるものとします。

b) インシデントの報告と対応の手順は、「セキュリティインシデントや誤動作から被害が最小化される」ようなやり方で採用されるものとします。

c) TSA の信用に値するシステムにおいて使われるメディアは、メディアを被害、盗難、認可されていないアクセス、および、老朽化から防ぐために、セキュアに取り扱われるものとします。

注 1: 管理責任をもつ要員の全員は、「TSA 実施規定」中に文書化されているように、「タイムスタンプポリシー」と、その関連実践の計画立案と効果的な実施に責任を負います。

d) 手順は、タイムスタンピングサービスの規定に影響を与える、すべての信用される運用管理的な役割について、確立され、実施されるものとします。

メディアの取扱いとセキュリティ

e) すべてのメディアは、情報の区分管理スキームの要件に準拠してセキュアに扱われるものとします(7.4.2 節 参照)。取扱いに注意を要するデータを格納するメディアは、もはや不要となったとき、セキュアに廃棄されるものとします。

システム計画

f) 要求される容量が監視されるものとし、将来の容量の要件についての推定は、「適切な処理能力とストレージが利用可能であること」を確保するものとします。

インシデントについての報告と対応

g) TSA は、インシデントに迅速に対応し、セキュリティの侵害の影響を限定するために、適時に調整的な作法で行動するものとします。すべてのインシデントは、そのインシデント後、遅滞なく報告されるものとします。

下記の追加的コントロールが、タイムスタンピング管理に適用されるものとします。:

運用手順と責任

h) TSA のセキュリティ運用は、他の運用からは分離されているものとします。

注 2: TSA セキュリティ運用の責任は、下記の事項を含みます。:

これらの運用は、TSA の信用される要員によって管理されるものとしますが、適切なセキュリティポリシーや、役割と責任についての文書中において規定されるように、(監督の下で) 非専門家、運用要員によって実際に行われる可能性があります。

7.4.6.  システムへのアクセスの管理 English

TSA は、「TSA システムアクセスが、正しく認可された個人に制限されること」を確保するものとします。

特記事項(一般):

a) コントロール(例: ファイアウォール)は、(加入者や第三者によるアクセスを含む)認可されていないアクセスから TSA の内部ネットワークドメインを防護するために実装されるものとします。

注 1: ファイアウォールは、その TSA の運用に不要な、すべてのプロトコルやアクセスを防ぐためにも設定される必要があります。

b) TSA は、システムセキュリティを維持管理するためのユーザ(これは、運用者、運用管理者および監査人を含む) のアクセス、ユーザアカウントの管理、監査、および、適時なアクセス権限の変更と削除を含む、効果的な運用管理を確保するものとします。

c) TSA は、「情報やアプリケーションシステム機能へのアクセスは、セキュリティ運用管理者と運用機能の分離を含むアクセスコントロールポリシーに従って制限されていること」および「その TSA システムが TSA の実践の中で識別された『信用される役割』の分離のために十分なコンピュータセキュリティコントロールを提供すること」を確保するものとします。特に、システムユーティリティプログラムの利用は、制限され、厳密にコントロールされます。

d) TSA 要員は、タイムスタンピングに関する重要性の高いアプリケーションを使う前に、正しく識別され、本人認証されるものとします。

e) TSA 要員は、例えば、イベントログを保持することによって、自らの活動について、説明可能であるものとします。(7.4.10 節 参照)

 

下記の追加的コントロールが、タイムスタンピング管理に適用されるものとします。:

f) TSA は、「ローカルなネットワークコンポーネント(例: ルーター)が、物理的にセキュアな環境にあること」と、「それらの設定は、その TSA によって規定された要件への準拠性について、定期的に監査されること」を確保するものとします。

g) TSA が、その資源に対するあらゆる認可されていない、かつ/または、不規則なアクセスの試みについて、適時に検知・登録・対応することを可能にするために、継続的な監視と警報の設備が提供されるものとします。

注 2: これは、例えば、侵入検知システム、アクセスコントロールの監視と警報の設備を使う可能性があります。

7.4.7.  信用に値するシステムの配備と保守 English

TSA は、変更に対して防護されている信頼に値するシステムや製品を使うものとします。

注: TSA のサービス(7.1.1 節 参照)について行われるリスク分析は、信用に値するシステムを要する重要度の高いサービスと、要求される保証のレベルを識別するものとします。

特記事項:

a) セキュリティ要件の分析は、「セキュリティが IT システム中に組み込まれていること」を確保するために、当該 TSA、もしくは、その TSA の代理によって行われるあらゆるシステム開発プロジェクトの設計と要件定義の段階において、実行されるものとします。

b) 変更コントロール手順は、あらゆる運用用のソフトウェアのリリース、変更、および、緊急のソフトウェア問題修正に適用されるものとします。

 

7.4.8.  TSA サービスの侵害 English

TSA は、その TSA のサービスのセキュリティに影響を与えるイベントが起きた場合、その関連情報を加入者や信頼者が入手できるようにすることを確保するものとします。(このイベントは、TSU の署名用のプライベート鍵の危殆化、もしくは、検出された時刻合わせの失敗を含みます。)

特記事項:

a) TSA の災害復旧計画は、TSU のプライベート署名用の鍵の侵害/侵害の懸念、もしくは、既発行の TST に影響を与える可能性がある TSU 時計の時刻合わせの失敗に対応するものとします。

b) 侵害/侵害の疑惑/時刻合わせの失敗が発生した場合、その TSA は、すべての加入者と信頼者宛てに、発生した侵害の記述を入手可能にするものとします。

c) TSU の運用に対する侵害(例: TSU 鍵の危殆化)、侵害の疑い、もしくは、時刻合わせの失敗があった場合、その TSU は、侵害からの復旧手順が行われるまで、TST を発行しないものとします。

d) その TSA の運用に重大な侵害があった場合、もしくは、推測できない事態になった場合、その TSA は、可能であれば、影響を受けた可能性がある TST を識別するために使える情報を、(これが、その TSA ユーザのプライバシ、もしくは、その TSA サービスのセキュリティを侵害しない限り)すべての加入者と信頼者情報が入手できるようにするものとします。

注: そのプライベート鍵が侵害された場合、その TSA によって生成されたすべてのトークンの監査証跡は、本物のトークンと偽の日付を遡ったトークンを区別する手段を提供する可能性があります。2 つの異なる TSA からの 2 つの TST は、この論点に対応する別の方法である可能性があります。

 

7.4.9.  TSA の廃業 English

TSA は、その TSA のタイムスタンピングサービスの停止の結果として想定される加入者と信頼者に対する混乱を最小化するものとし、特に、TST の正しさを検証するために要求される情報の継続的な維持管理を確保します。

特記事項:

a) TSA が、そのタイムスタンピングサービスを廃業する前に、最低限、下記の手順が実行されるものとします。:

b) TSA は、破産した場合、あるいは、 他の理由によって、自身では費用をまかなえない場合、これらの最低限の要件を満たすための費用を扱う協定をもつものとします。

c) TSA は、その実施(規定)中に、サービスの廃業についての規定を言明するものとします。これは、下記の事項を含むものとします。:

d) TSA は、その TSU の証明書が失効されるようにする手続を行うものとします。

7.4.10.  法的要件への準拠性 English

TSA は、法的要件への準拠性を確保するものとします。

特記事項:

a) TSA は、「国内法を通じて施行されている "European Data protection Directive" [Dir 95/46/EC] の要件に適合すること」を確保するものとします。

b) 適切な技術的な手段と、組織論的な手段が、パーソナルなデータについての認可されていない処理/非合法な処理や、パーソナルなデータの偶発的な損失/破壊、もしくは、パーソナルなデータの被害に対して講じられるものとします。

c) ユーザによって TSA 宛に与えられた情報は、彼らの契約、もしくは、裁判所の命令か他の法的要件によらない限り、開示から完全に防護されるものとします。

7.4.11.  タイムスタンピングサービスの運用に関する情報の記録 English

TSA は、「タイムスタンピングサービスの運用に関するすべての関連情報は、規定された期間にわたって、(特に、法的手順の目的のために)証拠を提供する目的のために記録されること」を確保するものとします。

特記事項:

一般

a) 記録されるべき具体的なイベントやデータは、その TSA によって文書化されるものとします。

b) タイムスタンピングサービスの運用に関する現在と過去の記録の守秘性とインテグリティは、維持管理されるものとします。

c) タイムスタンピングサービスの運用に関する記録は、開示されているビジネス実践に準拠して、完全かつ守秘性を確保して保管されるものとします。

d) タイムスタンピングサービスの運用に関する記録は、法的手続の目的のために、当該タイムスタンピングサービスの正常な運用についての証拠を提供する目的で要求された場合、入手可能にされるものとします。

e) 顕著な TSA 環境的イベント、鍵管理イベントおよび時刻の同期化イベントの詳細な時刻は、記録されるものとします。

f) タイムスタンピングサービスに関する記録は、必要不可欠な法的証拠を提供するのに適切な限り、「TSA 開示規定」において通知されているように、その TSU の署名用の鍵の有効期間の期限切れ後の一定期間、保持されるものとします。(7.1.2 節 参照)

g) そのイベントは、(信頼できる長期保存用メディアに転送されている場合を除いて)保存することが要求されている期間、簡単には削除/破壊できない作法で、ログに記録されるものとします。

注: これは、例えば、「焼く」メディアの利用、使われた各リムーバルメディアの記録、および、サイト外におけるバックアップの利用によって達成される可能性があります。

h) 加入者について記録されたあらゆる情報は、その加入者から、そのより広い発行について同意が得られている場合を除いて、機密に保たれるものとします。

TSU 鍵の管理

i) TSU 鍵のライフサイクルにおける、すべてのイベントに関する記録は、ログに記録されるものとします。

j) (適切な場合、TSU 証明書のライフサイクルに関する、すべてのイベントに関する記録は、記録されるものとします。)

時計の同期化

k) UTC への TSU の時計の同期化に関するすべてのイベントに関する記録は、ログに記録されるものとします。これは、タイムスタンピングに使われる時計の通常の時刻の再合わせもしくは同期化に関する情報を含むものとします。

l) 非同期の検出に関するすべてのイベントに関する記録は、ログに記録されるものとします。

7.5.  組織論 English

TSA は、「その組織体が信頼可能であること」を確保するものとします。

特記事項:

a) TSA が運用時に従うポリシーおよび手順は、非差別的なものとします。

b) TSA は、宣言された運用範囲内に収まる活動をしており、かつ、その「TSA 開示規定」に規定された義務を負うことに合意する、すべての希望者がそのサービスにアクセスできるようにするものとします。

c) TSA は、国内法に準拠する法人です。

d) TSA は、提供しているタイムスタンピングサービスのために適切な品質と情報セキュリティマネジメントのためのシステムをもちます。

e) TSA は、その運用、および/または、活動に起因する法的義務を扱うために、適切な契約をもちます。

f) TSA は、財務的健全性と、このポリシーに準拠して運用するために要求される資源をもちます。

注 1: これは、7.4.9 節において識別された TSA の廃業についての要件を含みます。

g) TSA は、タイムスタンピングサービスを提供するために必要不可欠な作業の種類・範囲・量に関して必要不可欠な教育、訓練、技術的な知識および経験をもつ十分な人数の要員を雇用します。

注 2: TSA によって雇用される要員には、その TSA のタイムスタンピングサービスのサポートを行うことについて、契約によって参画している個々の要員が含まれます。その TSA サービスの監視にのみ参画する可能性がある要員は、TSA 要員である必要があります。

h) TSA は、そのタイムスタンピングサービスの規定、もしくは、他のあらゆる関連事項について、顧客もしくは他の主体から受け取る苦情や争議の解決についてのポリシーと手順をもちます。

i) TSA は、正しく文書化された合意や契約的な関係を整備します。これらにおいて、サービスの規定は、再請負、アウトソーシングもしくは他の第三者との協定を含みます。

 

8.  セキュリティについての考慮事項 English

TST を検証するとき、その検証者が「その TSU 証明書は、信用されており、失効されていないこと」を確認することが必要不可欠です。これは、「セキュリティは、証明書の発行と、その証明書についての正確な失効状態情報を提供することの両方について、その TSU 証明書を発行した CA のセキュリティに依存すること」を意味します。

タイムスタンプがある時点において妥当であると検証されるとき、これは、「必ずしも、以降も有効であり続けること」を意味するものではありません。毎回、TST は、その TSU 証明書の有効期間の間、検証され、これは、現在の失効状態情報に照らして、再度、検証されねばなりません。なぜなら、TSU プライベート鍵が侵されてしまった場合、その TSU によって生成された、すべての TST は、無効になるからです。補遺 C は、TST の長期的検証についてのガイダンスを提供します。

タイムスタンピングをアプリケーションに適用する際に、そのアプリケーションのセキュリティについても考慮される必要があります。特に、タイムスタンプを適用するとき、「データのインテグリティは、そのタイムスタンプがなされる前に維持管理されてること」を確認することが必要不可欠です。その要求者は、「その TST 中に含まれたハッシュ値がそのデータのハッシュと一致すること」を本当に確認すべきです。

 

9.  謝辞 English

本書の策定は、ETSI と EU(European Union)によって支援されました。価値ある情報を提供してくださった Franco Ruggieri 氏には、特別に感謝しています。

 

10.  参考文献

10.1.  規範的参考文献

[RFC 2119]  Bradner, S.
「RFC において要請の程度を示すために用いるキーワード
(Key words for use in RFCs to Indicate Requirement Levels)」,
BCP 14, RFC 2119, 1997年 3月.
 
[TF.460-5] ITU-R Recommendation TF.460-5 (1997): Standard-frequency and time-signal emissions.
 
[TF.536-1] ITU-R Recommendation TF.536-1 (1998): Time-scale notations.
 
[CWA 14167-2] CEN Workshop Agreement 14167-2: Cryptographic Module for CSP Signing Operations - Protection Profile (MCSO-PP).
 
[FIPS 140-1] FIPS PUB 140-1 (1994): Security Requirements for Cryptographic Modules.
 
[ISO 15408]  ISO/IEC 15408 (1999) (parts 1 to 3): Information technology - Security techniques and Evaluation criteria for IT security.

10.2.  参考資料

[CWA 14172] CEN Workshop Agreement 14172: EESSI Conformity Assessment Guidance.
 
[Dir 95/46/EC] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data.
 
[Dir 99/93/EC]

Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures.

[ISO 17799] ISO/IEC 17799: Information technology Code of practice for information security management
 
[RFC 3126] Pinkas, D., Ross, J. and N. Pope,
"Electronic Signature Formats for long term electronic signatures",
RFC 3126, 2001年 9月.
 
[RFC 3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
「X.509インターネット PKI タイムスタンププロトコル(TSP)
(Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP))」,
RFC 3161, 2001年 8月.
 
[TS 101733]   

ETSI Technical Specification TS 101 733 V.1.2.2 (2000-12).
Electronic Signature Formats. 
注: ETSI TS 101 733 のコピーは、ETSI の web サイト(www.etsi.org)から自由にダウンロードすることができます。
 

[TS 101861] ETSI Technical Specification TS 101 861 V1.2.1. (2001-11). 
Time stamping profile. 
注: ETSI TS 101 861 のコピーは、ETSI の web サイト(www.etsi.org)から自由にダウンロードすることができます。
 
[TS 102023] ETSI Technical Specification TS 102 023. 
Policy requirements for Time-Stamping Authorities. 
注: ETSI TS 102 023 のコピーは、ETSI の web サイト(www.etsi.org)から自由にダウンロードすることができます。
 
[X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.

 


補遺 A (参考資料): UTC(Coordinated Universal Time) English

UTC(Coordinated Universal Time)は、1972年 1月 1日に施行された国際的な時刻標準です。UTC は、GMT(Greenwich Mean Time)を置き換えました。しかし、実際には、両者は、決して 1 秒以上離れることはありません。それゆえ、多くの人々は、実際には UTC を指すときも、GMT と呼び続けています。

UTC のゼロ(0)時は、経度 0 に位置するイギリスのグリニッジにおける真夜中です。Universal time は、24 時間時計に基づいています。それゆえ、UTC の午後 4 時のような午後の時刻は、16:00 UTC(16時 0分)のように表現されます。

TAI(International Atomic Time)は、世界中の 30 ヵ国以上の計量機関や天文台にある 200 以上の原子時計の読みとりから BIPM(Bureau International des Poids et Mesures)によって算出されます。TAI についての情報は、BIPM Circular T(ftp://62.161.69.5/pub/tai/publication)から、毎月、入手可能になっています。これは、「TAI は、仮想の完全な時計に基づいて、年に、およそ 1 マイクロ秒(0.0000001 秒)の10分の1 以上は増減しない」というものです。

UTC(Coordinated Universal Time): ITU-R(International Telecommunications Radio Committee)によって規定・推奨され、BIPM(Bureau International des Poids et Mesures)によって維持管理されているように、秒単位の時間の尺度。BIPM による維持管理は、世界中の様々な国立研究所間の協力を含みます。UTC の完全な定義は、ITU-R Recommendation TF.460-4 にあります。

原子時は、セシウム 133 原子の基底状態(ground state)の 2 つの超微細レベル間の遷移にともない放出される光の振動周期の 9 192 631 770 倍を 1秒と定めます。TAI は、「国際的な原子時の尺度」であり、数多くの原子時計に基づく固定的な時間の尺度です。

UT(Universal Time)は、地球の自転における変動に関わらず、できるだけ均等となるように規定されており、平均太陽日の持続期間をもつ単位で、真夜中の 0時から刻まれます。

UTC(Coordinated Universal Time)は、国際的な時刻の維持についての基礎であり、2001年における 32秒のみを例外として、TAI に従います。これらの「うるう秒」は、IERS((International Earth Rotation Servive)の勧告(http://hpiers.obspm.fr/)に則って、「不規則性を考慮したとき、グリニッジの子午線上において、太陽が、12:00:00 UTC の誤差 0.9 秒以内に真上にあること」を確保するように挿入されます。それゆえ、UTC は、時刻のユニットが平均太陽日であったときに使われた GMT(Greenwich Mean Time)の後継です。

原子時の尺度への微調整(すなわち、UTC)は、(「うるう秒」と呼ばれる)1秒を折にふれて追加/削除することによって行われます。年に 2 回、6月30日と 12月31日の最後の分(minute)に、UT は、「積もった UTC と UT1 間の差異は、次に予定された微調整の前に 0.9 秒を越えないこと」を確保するために、微調整が行われる可能性があります。経緯的に、微調整は、それが必要不可欠なとき、通常、地球の自転が追いつくことを認めるための UTC 時刻尺度への秒の追加でした。それゆえ、微調整が行われる日の UTC 時刻尺度の最後の分(minute)は、61 秒、もちます。微調整日は、典型的には、数ヶ月前に IERS Bulletin C:(ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)においてアナウンスされます。

それゆえ、UTC(Coordinated Universal Time)は、TAI と整数秒だけ違います。UTC は、1 秒(「うるう秒」)の導入によって、UT1 の 0.9 秒以内に保たれます。今日、これらの手順は、常に行われてきました。

 


補遺 B (参考資料): 実装アーキテクチャとタイムスタンピングサービスについて可能な事項 English

B.1.  管理されたタイムスタンピングサービス English

組織体によっては、これらの TSU の導入・運用・管理について責任を負うことなく、そのタイムスタンピングサービスの近接性と品質の両方の優位性を活用するために、ひとつ(もしくは複数の)TSU を運用することを望んでいる可能性があります。

これは、運用している組織体(Hosting Organization)の構内に導入されているユニットを使って、運用している組織体に提供されるサービスの品質の全体について責任を負う TSA によって遠隔から管理されることによって達成されます。

  +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  +                                                                   +
  +                      Time-Stamping Authority                      +
  +_____________              _____________              _____________+
 |+ __________  |            |             |            |  __________ +|
 |+|          | |            |    Time -   |            | |          |+|
 |+|   Time - |<-------------|   Stamping  |------------->|   Time - |+|
 |+| Stamping | | Install.   |  Management | Install.   | | Stamping |+|
 |+|   Unit   | | Management |             | Management | |   Unit   |+|
 |+|__________| |            |_____________|            | |__________|+|
 |+             |                                       |             +|
 |+             |                                       |             +|
 |+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
 |   Hosting    |                                       |   Hosting    |
 | Organization |                                       | Organization |
 |______________|                                       |______________|

図 B.1: 管理されたタイムスタンピングサービス

本書に記述されているタイムスタンピングサービスについての要件は、タイムスタンピング管理についての要件と、そのTST を発行するユニットの運用についての要件の両方を含みます。TSA は、TST において識別されるように、「(例えば、契約的な義務を通じて)これらの要件に適合すること」を確保するために責任を負います。「運用する組織体は、通常、そのサービスの利用を監視できることを望み、少なくとも、『そのサービスが機能しているか否か?』および『そのサービスのパフォーマンスさえも測定できること 』を知っていること」が明確である必要があります。(例: 一定期間に生成されたタイムスタンプの数。)このような監視は、TSA の外部にあると考えられます。

それゆえ、その文書の本文に記述された管理操作の記述は、限定列挙ではありません。監視操作は、そのユニット上で直接、行われた場合、そのタイムスタンピングサービスプロバイダーによって許可される可能性があります。

B.2.  品質を代替する特徴の選択 English

信頼者には、特定の署名アルゴリズムおよび/または鍵長、もしくは、その TST 中に含まれる時刻についての一定の精度のような、TST の特定の特徴を活用することを望む者がいる可能性があります。これらのパラメータは、TST についての「品質」を規定するものと見なすことができます。

様々な品質をもつ TST は、同一の TSA もしくは異なる TSA によって運用される異なる TSU によって発行される可能性があります。

特定の TSU は、アルゴリズムと鍵長のひとつの組み合わせのみを提供します。(なぜなら、TSU は、ひとつのユニットとして管理され、ひとつの TST 署名用の鍵をもつハードウェアとソフトウェアの集合であるからです。)アルゴリズムと鍵長の異なる組み合わせを得るために、異なる TSU が使われるものとします。

特定の TSU は、特定のアクセス方法(例: e-mail もしくは http) によって行う場合、あるいは、リクエスト中に特定のパラメータを使うことによって命令されている場合、その TST に含まれている時刻について、固定値の精度もしくは異なる精度を提供する可能性があります。

 


補遺 C (参考資料): タイムスタンプトークンについての長期的検証 English

通常、TST は、TSU からの証明書の有効期間の期限以降、検証不能になります。なぜならば、その証明書を発行した CA は、もはや、失効データ(鍵の危殆化に起因する失効についてのデータを含む)を発行することを保証しないからです。しかし、TST の検証は、その TSU からの証明書の有効期限以降も、検証時に下記の事項を検証できる場合、行われる可能性があります。:

これらの条件に適合しない場合、その有効性は、以前のタイムスタンプのインテグリティを防護するために、追加的なタイムスタンプを適用することによって維持管理される可能性があります。

本書は、「どのように、このような防護が得られる可能性があるか?」の詳細を規定しません。当面、これらの機能をサポートするための何らかの拡張が規定されるまで、その情報は、オフラインの手段を使うか、あるいは、代わりに、閉じた環境において得られる可能性があります。一例として、万一、ある CA が、その有効期限以降も、その TSU 証明書の有効期間、 維持管理することを保証する場合、これは、最初の要件を満たします。

注 1: タイムスタンピングについての代替案のひとつは、信用されるサービスプロバイダーが、監査証跡中の特定の時刻におけるデータの再現を記録することであり、それゆえ、「そのデータは、その時点以前に存在した」という証拠を確立することになります。(タイムマーキングと呼ばれる)このテクニックは、署名の長期的有効性をチェックすることについて、価値ある代替案である可能性があります。

注 2: TSA もしくは他の信用される第三者としてのサービスプロバイダーは、TST の検証をサポートする可能性があります。

 


補遺 D (参考資料): TSA 開示規定の構成のモデル English

「TSA 開示規定」は、定義された各言明の種別についての章をもちます。「TSA 開示規定」の各章は、網羅的な言明を含みます。これは、関連する証明書ポリシー/認証実施規定の章へのハイパーリンクを含む可能性があります(MAY)

D.1.  STATEMENT TYPE: 契約の全体

STATEMENT DESCRIPTION:
「開示規定は、契約の全体ではなく、その一部に過ぎないこと」を示す言明

D.2.  STATEMENT TYPE:TSA 連絡先情報

STATEMENT DESCRIPTION:
TSA についての名前、所在地および関連する連絡先情報

D.3.  STATEMENT TYPE: TST の種別と用途

STATEMENT DESCRIPTION:
TSA によって、(各タイムスタンプポリシーに準拠して)発行された TST の各クラスもしくは各種類についての記述、および、タイムスタンプ用途についてのあらゆる制限。

SPECIFIC REQUIREMENT:
適用されているポリシーの表示。何に、その TST は、使えるか?(例: 電子署名用のみ)について、そのハッシュアルゴリズム、TST の署名について想定される有効期間、TST の利用についてのあらゆる制限、および「どのように、TST を検証するか?」についての情報を含む。

D.4.  STATEMENT TYPE: 信頼の制約

STATEMENT DESCRIPTION:
(存在する場合、信頼の制約)

SPECIFIC REQUIREMENT:
TST 中の時刻の精度の表示、TSA イベントログ(7.4.10 節 参照)が維持管理される期間
(および、それゆえ、証拠を提供可能な期間)

D.5.  STATEMENT TYPE: 加入者の義務

STATEMENT DESCRIPTION:
重要な加入者の義務についての記述、もしくは、それに対する参照

SPECIFIC REQUIREMENT:
本書において、具体的な要件は、識別されていません。適用可能な限り、TSA は、追加的義務を規定することができます。

D.6.  STATEMENT TYPE: 信頼者が TSU 公開鍵の状態をチェックする義務

STATEMENT DESCRIPTION:
信頼者が TSU 公開鍵の状態をチェックし、さらなる説明を参照する義務を負う程度

SPECIFIC REQUIREMENT:
「どのように、TSU 公開鍵の状態を検証するか?」についての情報
信頼者が、その TST に「合理的に信頼している」といえるような TSU 公開鍵の失効状態をチェックするための要件を含む。(6.3 節 参照)

D.7.  STATEMENT TYPE: 制限された保証および免責/責任の制限

STATEMENT DESCRIPTION:
保証、免責事項、責任の制限、および、あらゆる適用可能な保証プログラム/保険プログラムの要約

SPECIFIC REQUIREMENT:
責任の制限(6.4 節 参照)

D.8.  STATEMENT TYPE: 適用可能な契約および実施規定

STATEMENT DESCRIPTION:
適用可能な契約、実施規定、タイムスタンプポリシーおよび他の関連文書の識別と、それらへの参照

D.9.  STATEMENT TYPE: プライバシーポリシー

STATEMENT DESCRIPTION:
適用可能なプライバシーポリシーについての記述、および、適用可能なプライバシーポリシーへの参照

SPECIFIC REQUIREMENT:
注: このポリシーに従う TSA は、データ保護規制の要件に準拠することが要求されます。

D.10. STATEMENT TYPE: 払い戻しのポリシー

STATEMENT DESCRIPTION:
適用可能な払い戻しのポリシーについての記述、および、参照

D.11. STATEMENT TYPE: 適用可能な法、苦情や争議の解決機構

STATEMENT DESCRIPTION:
法、苦情の手順および争議の解決機構の選択についての言明

SPECIFIC REQUIREMENT:
苦情や争議の解決についての手順。適用可能な法的システム

D.12. STATEMENT TYPE: TSA とリポジトリの免許、信用マークおよび監査

STATEMENT DESCRIPTION:
あらゆる国家免許やシールプログラムの要約、および、監査手順の記述と、監査法人が利用可能な場合はその旨

SPECIFIC REQUIREMENT:
TSA が識別されたタイムスタンプポリシーに準拠していると評価されているか否か?(その場合、どの独立主体によるか?)

 


著者のアドレス

Denis Pinkas
Bull
Rue Jean Jaures,
78340 Les Clayes CEDEX
FRANCE

EMail: Denis.Pinkas@bull.net

Nick Pope
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom

EMail: pope@secstan.com

John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom

EMail: ross@secstan.com

この情報提供 RFC は、ETSI ESI において策定されました。

ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis
Valbonne - France
Tel:+33 4 92 94 42 00  Fax:+33 4 93 65 47 16
secretariat@etsi.fr
http://www.etsi.org

連絡先

Claire d'Esclercs
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis, Cedex
FRANCE

EMail:claire.desclercs@etsi.org

翻訳者のアドレス

宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター

miyakawa@ipa.go.jp

 

著作権表記全文

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

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

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

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

謝辞

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