OpenIDセキュリティ周りの雑考察

「Man-in-the-Middle攻撃をされたらひとたまりもない ( http://sho.tdiary.net/20051021.html#p01 )」ということですね。
httpsでも、どの認証局を信用するかという問題が残りますね。

おっともう言及されてたんですね…。
セキュリティ素人なのでMan-in-the-Middleという言葉がなんか背伸びし過ぎてる気がしてつかえませんでした(びびり)。

でも一応、認証局の問題はおくとしても、各認証サーバのアカウントページを使う限りは（http://kokogiko.videntity.org/とかhttp://profile.typekey.com/kokogiko/とかの）、これらがhttps化されれば（今のところされてないけど）、問題はなくなると考えていいんでしょうか？
もしそうなら、問題はopenid.delegateの部分になるのかな…個人サイトは簡単にはhttps化できないし。
htmlのメタ情報として置くからよくないんじゃないか。
たとえばFOAFの中に突っ込んで、FOAFに埋め込んだ電子署名で、記述されたdelegate・server設定の正当性を検証するとか。
その信頼性は、foaf:mboxからKey Serverで取得した公開鍵の、署名ベースの信頼性から判断するとか。
httpで指定された（改ざんされ得る）html -> FOAF情報であっても、指定された公開鍵がある程度信頼出来るなら、OKみたいな。
これなら、どこかで誰かが書いてたけど、OpenIDの信頼性はサーバとユーザ双方の信頼性検証が必要になる、とあったけど、ユーザの信頼性は公開鍵の署名で検証し、サーバの信頼性はhttps認証局の信頼性で検証して、両方検証できるようになるんじゃないかと思ったり。

できるならば、OpenIDのアカウントをWebのURLベースではなく 、メールアドレスにして、直接Key Serverから公開鍵取得して…なんて事ができればいいんだけど、今のところその方法だとメールアドレス -> WebサイトURLの逆引きができないから駄目ですね。
メールアドレスの方が自分のID、という感じも強いんだけど...。

あと、現行はopenid.delegateの仕様が、delegate先を本当に確認するのではなく、delegateで指定されたURLを使ってopenid.serverで識別する、という仕様になってるんだけど、これも安全性を徹底するには、本当にdelegate先を訪問して、そこのopenid.serverを確認して識別する、という手順にした方がいいと思う。
OpenID MLの過去ログを読み返してみると、この辺は昔話題に上がってたけど、一手手順が増えてプロトコルが重くなるのと、delegateの連鎖による多重ホップを恐れて、あんまり議論されずに消えてたみたいだけど、手順が増えても安全性を考慮した方がよいと思うし、多重ホップは最初から「多重ホップはしない -> 多重ホップするようなら識別失敗」とでもすればいいので、delegate先は訪れるべきだと思うんだけどなあ...。

そういう風にdelegate元でopenid.serverを指定せずに、delegate先だけを指定するようにすると、もう1つ利点があって、delegate先を1箇所だけでなく複数並べられるようになること。
そうすると、delegate先を通じて複数のopenid.serverを指定できるようになるので、1箇所のopenid.serverが落ちていても、別のopenid.serverに依頼したり出来るので、可用性が高まる。
また識別を要請する側で、openid.serverの信頼性を選択して、自分の信頼できるopenid.serverでの識別を選択したり出来るようになる。
例えば、あるopenid.serverの識別サービスを提供している業者のサーバセキュリティに、問題が発覚したとする。
危険なのでサービス提供側が軒並みそのopenid.serverからのログインを拒否するようになったとすると、それを使ってログインしてきたユーザ側が、自分のサイトのdelegate・server指定を他のところに書き換えないとサービス継続不可能になり、大混乱になる。
でも、複数delegateを認めていると、あるopenid.serverが信用できなくても他のところが一緒に指定されていればそこに識別依頼できるので、ユーザに何の混乱も起こさず、コンシューマ側の設定だけで危険を回避できる。
というわけで、やっぱりdelegate先は複数指定できた方がよい、と思うのでした。

でも、こんなの全部突っ込めば、すごい思い仕様になるかな...。Simpleではないよね...。