3 タイムスタンプ・プロトコル (RFC 161)
3.4 IETF/PKIX での TSP 事情
3.4.1 I-D PKIX RoadmapにおけるTSP
解説：IETF/PKIXでは、WGの作業概要やロードマップを示す文書としてイン
ターネットドラフトPKIX Roadmap[id-roadmap]を公開し、定期的に更新してき た。PKIX Roadmapの最新版(-09)は、2002年7月に公開されて以降更新されて おらず既に期限切れとなっているが、その”4.4 Time Stamping and Data
Certification”18において、[TSP]が策定された経緯について簡単に触れている。
タイムスタンプとデータ証明19は、当初WGの計画にはなかったが、PKIXの望 むセキュリティサービスを提供するインフラに必要なものとして1998年後半から 検討が開始された。
タイムスタンプは、あるデータが与えられた時間よりも以前に存在していた証 拠を提供するために、TTP20であるTSAが署名するサービスである。署名された タイムスタンプの存在は、(問題となる)トランザクションがタイムスタンプの示す 時刻以降に偽造できないことを示すことができるため、ある程度の否認防止を実 現することができる。
PKIXではRFC 3161を検討する過程で、そのインターネットドラフトにおいて
TDA(Temporal Data Authority)の役割についても定義した。TDAは時間を表すデ ータトークン21を生成するTTP20である。この時間を表すデータトークンは、メッ セージを特定のイベントと結びつけ、補助的な証拠をタイムスタンプ・トークン の中に含まれる時刻に対して提供する。
しかし、ミネアポリスでの44th IETFにおいて、このドラフトのいくつかの素 材22が特許に抵触するかもしれないことが明らかになり、利用は認められなかった ため、以降のドラフトからはTDAに関する記述は削除された。
18 [id-roadmap]には何故か4.4節が2箇所存在する。TSPについて触れられているのは後者であ
る。
19 データ証明についてはDVCS(RFC3029)として標準化された。DVCSについては本報告書4.4 節にて解説している。
20 Trusted Third Party: 信頼できる第三者機関
21 temporal data token
22 material
3.4.2 MLでの議論内容
IETF/PKIX WGのメーリングリスト(ML)上では、RFC 3161も含め関連する資 料などについて議論が交わされている。本節では、このML上で議論された内容 からいくつか主要なトピックを紹介する。
3.4.2.1 PKIStatusInfoについて
タイムスタンプ・レスポンスのPKIFailureには複数の値を格納することができ る。これはrfc3161bisにおいて明記する必要があり、またその際一つしかない
statusStringフィールドに複数のエラーメッセージをどのように記述することが
できるか(エラーメッセージのセパレータをどうするか)、についても追記する必要 がある、というコメントが出された。
3.4.2.2 PKIStatusについて
タイムスタンプ・レスポンスに用いられているPKIStatusのオリジナルは CMP[CMP]で定義されたものだが、RFC 3161ではCMPにおけるPKIStatusの 定義がそのままコピー&ペーストされてしまった。このためTSPにおいてはいく つか不要なエラーコードがあり、開発者たちがしばしば混乱に陥っている。
これらの解釈について何度か質問が上がっており、TSPの実装においては、以 下のような解釈をすることが望ましいようである。
PKIStatus TST 解釈
granted (0) 含む TSQに対してTSTを含む正しいTSRを
返す場合
grantedWithMods (1) 含む TSTを含んだTSRを返せるものの、TSQ に含まれるプライベート拡張が、TSR において利用できない場合
rejection (2) 含めない 3〜5以外の理由でTSRにTSTを含める ことができない場合
waiting (3) 含めない
(レシートを含む)
TSAがTSTを生成できず代わりにレシ ートのみを含めて返す場合
revocationWarning (4) 含めない TSU証明書の失効が差し迫っている場 合
また、revocationWarning(4)やrevocationNotification(5)は定義はされているも のの、実質的には全てのエラーに対してrejection(2)を返すことになるのではない か、という意見も出されていた。
3.4.2.3 TSPが扱うポリシー
TSAには署名ポリシーだけでなく、法的証拠などの司法権や商業ポリシーを示 す情報がタイムスタンプリクエトおよびタイムスタンプ・レスポンスに必要では ないか、という議論がなされている。
タイムスタンプ・リクエストやタイムスタンプ・レスポンスにofficialReqとい うフィールドを組み込む案と、タイムスタンプ・リクエストやタイムスタンプ・
レスポンスそれぞれの拡張フィールドにJurisdiction拡張を定義する案の2案が 議論されている。しかし、このofficialReqあるいはJurisdiction拡張がどう処理 されるべきか、という点についてはあまり具体的な案は示されていないように見 える。
3.4.2.4 転送プロトコル
TSPを扱う転送プロトコルのデフォルトを決めるべきだ、という議論がなされ ている。HTTPという意見が多い中、WGチェアからはエリアディレクターの見 解も聞きたい、という意見も出ていた。
3.4.2.5 複数のSignerInfoを持つSignedDataのmessageImprint
SignedDataが複数のSignerInfo(とsignature)を持つ場合には、その messageImprintはどうなっているべきか?という質問が出されていた。
これに対して、複数のSignerInfoがあるならばタイムスタンプも複数必要であ る、一つのタイムスタンプだけを使いたいならば署名されたCMSを別の署名され たCMSの中に組み込む方法を使うべきである、という回答が出されていた。23 3.4.2.6 nonceの処理について
nonceは、TSPに限らずOCSPレスポンダなどにも利用されている技術で、ネ
ットワークの盗聴等によるパケット再生攻撃を防ぐためのものである。このうち
OCSP[OCSP]では、nonceの解釈に関して以下の点が明確になっていなかったた
めに目下ML上で議論が交わされている。
23 これはまさに本報告書2.3.4節にて解説している並列署名に関する解説そのものである。
nonceをリクエストに含めたクライアントが、nonceを含まないレスポ ンスを受け取った場合に、クライアントはそのレスポンスを拒否すべ きかどうか。
nonceを含んだレスポンスを生成できないサーバーが、nonceを含んだ リクエストを受け取った場合に、どのように振る舞うべきか｡
これらの問題については58th IETFにおいてOCSPの著者の一人である Michael Myers氏と、セキュリティエリア24のエリアディレクターであるRussel
Housley氏から見解25が示されたものの、既存の実装へのインパクトを懸念する声
もあり、なお議論が継続中である。
RFC 3161においては前者については文中に明記されているものの、後者につい
てはOCSP同様明記されていないため、この問題に関して動向を観察しておく必 要がある。
24 IETFにおけるPKIX WGの上位組織。部会に相当する。
25 2003年11月25日時点でPKIX WGの議事録草案が以下のURIにて公開されているので詳細