muziyoshiz.jpまでどうぞ。
2005/07/03
■[年表][P2P]年表ウェブ：位置に依存しないID / IDと署名
※年表ウェブ：年表データのポータビリティ（2005/06/24）の続きです。
前回は「年表データにはポータビリティが必要だ」という話をしましたが、そのためには年表データそのもの、特にそのID（識別子）が位置非依存である必要があります。つまり、年表ウェブを固定サーバのみで運用するとしても、WWWと違ってURLが使えない、ということです。
そこで、今回はそのような要求を満たすIDの設計案と、IDにまつわるその他の問題について考えてみます。
■ データ構造とID
年表ウェブについて書いた最初の日記（2005/05/24）では、年表ウェブのデータ構造を、以下のような簡単な図式で示しました。
（クリックして拡大）
年表ウェブを実現するのにどんなIDが必要かは、これを具体的にどういうデータ構造で表現するかに依存します。ここでは、以下の図のような単純なデータ構造を考えます*1。
（クリックして拡大）
この場合、必要になるIDは下の3つです。
- 人ID（Person ID、以下P-ID）
- 年表ID（Chronology ID、以下C-ID）
- 出来事ID（Event ID、以下E-ID）
それぞれが、リレーショナルデータベースの主キー（primary key）相当のものだと思ってください。これらのIDが世界的に一意なら、年表データのポータビリティが実現されます。そのようなID決定方法として有名なのは、P2PフレームワークのJXTAでも採用されているUUIDです*2。
Insider's Computer Dictionary [GUID](＠IT)
http://www.atmarkit.co.jp/icd/root/52/94084052.html
A UUID URN Namespace(draft-mealling-uuid-urn-05)
http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-05.txt
また、P-IDは通常ユーザ当たり1つしか必要ないため、（年表データの位置には関係しないという前提で）メールアドレスのようなURIを利用するという方法も考えられます。
ここまでが、年表データとそのIDに関する基本的な話で、ポータビリティを確保するだけなら一応これだけでOKだと思います。
■ IDの重複、データの偽造を電子署名で防止
ただ、IDの重複やデータの偽造に対処しようと思うと、もう少し機能が必要になります。
IDの重複というのは、他のID……例えばIPアドレスでも起こりうる話ですけど、この場合はUUIDのようなものを使うと、IDが重複しても「こちらの利用が正当、そちらは不正」と言い切れないのが問題です。
一方、データの偽造は「他人の作ったイヤな年表データが自分の名前で公開」されたときに問題になるため、これは「年表データや出来事データに含まれる作者のP-IDを偽造できる」と問題がある、と言い換えられます。
で、これらの問題を簡単に解決するには、
- C-IDとE-IDに、必ず作者のP-IDを前置する
- 人、年表、出来事それぞれのデータに電子署名を付ける
として、IDの重複＝P-IDの偽造と言い切る、という方法が考えられます（下図参照）。
（クリックして拡大）
まぁ、「簡単に」と言ってもあくまで理屈の上では簡単、というだけのことで。実際にこういう方法を取るとなるとユーザ側での鍵管理が面倒になるので、それもまた問題なんですけどね……。
■ 電子署名で気になる点
しかしこの方法では、鍵管理が面倒という以外にも2つ気になる点があります。
1つ目は、P-IDと公開鍵の対応関係が「正しい」ことを証明する方法です。例えば、P-IDと公開鍵証明書を発行する機関が別れていると、任意のP-IDに対応する正当な公開鍵証明書を誰でも取得できてしまいます（下図）。
（クリックして拡大）
C/S型CertifierではP-IDと公開鍵証明書を同じ機関が発行する、という対策が可能です。しかしP2P型Certifierではそれも難しいので、何かうまい解決策が必要になりそうです。
そして2つ目は、公開鍵証明者の発行者の変更、つまりCertifier間のポータビリティを実現する方法です。通常の証明書利用ではこのような権限委譲は考えられていないので、何か対策が必要になります。
例えば、ユーザが既に新しいCeritifierに乗り換えていたとしても、前のCertifierがCRL（Certificate Revocation List；証明書失効リスト）を発行すると、その公開鍵は全く使えなくなってしまいます。まぁ、Certifierを変えるぐらいなら、鍵も変えて、署名し直したデータを再度流通させろという話かもしれませんけど……。
----
さて、ここまで長々と机上の空論を書いてきたわけですけど、現時点で僕が描いているイメージはここまでで一通り書き終えました。あとは、実際に動く形にしてみないと、どういう効果や、課題があるかは良く分からなそうです。
そこで、ひとまず年表ウェブ関連の連載日記はここまでということにして、あとは暇を見てプロトタイプを実装してみます。いつ出来るかはわかりませんけど、他に作ってくれそうな人もいないしなぁ……まぁ、気長にお待ち頂ければ幸いです。
[ツッコミを入れる]
本日のTrackBacks(全1件)
[]
前回は「年表データにはポータビリティが必要だ」という話をしましたが、そのためには年表データそのもの、特にそのID（識別子）が位置非依存である必要があります。つまり、年表ウェブを固定サーバのみで運用するとしても、WWWと違ってURLが使えない、ということです。 ..
スパム対策のため、60日以上前の日記へのコメント及びトラックバックは管理者が確認後に表示します。
また、この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。ご了承ください。
また、この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。ご了承ください。
