今日の出来事 電子証明書アルゴリズム編
2009年05月06日07:49
今日は午後からスタバに行って設計をやって、そのあとＰさんと食事に行った。
設計のほうは、今、公開鍵暗号のスキームと呼ばれる、組み合わせ方の設計をしているところで、証明書というファイルのフォーマットを考えている。 証明書といえばX.509と呼ばれるフォーマットが一番有名なのだけど、これが僕にはどうしても必要充分な機能を持っていると思えなくて、かつ、不要な機能が多く曖昧な点が多いと感じてる。 そこで、基本的な考え方を継承しつつ、これをもっとカリカリに絞ったファイルフォーマットを設計したい、と思う。
よく、ファイルフォーマットの設計でよくある失敗（アンチパターン）に、拡張領域を作ってしまうというのがあると思う。 そのファイルフォーマットがどのように利用されるのか想定しきれないとき、設計者は「将来の拡張の為に」と、どのような使い方も許されるようなマップ領域をそのフォーマットに加えてしまうのだ。 これは便利なようにみえて実は非常に害が大きい設計方法だと思う。 なぜかというと、このフォーマットをつかってデータを作成する人が、その拡張領域マップにどのようなデータを追加できるのかはっきりせず、またそのデータを利用する側も、その拡張領域マップにどのようなデータが存在することを期待できるのかはっきりしなくなってしまうからだ。 こうなると、作成者側も利用者側も、ありとあらゆる可能性を想定してプログラムを組む必要に駆られてしまう。 すべてのケースを予測しつくすことは不可能で、結果的にデータの互換性を損なってしまうプログラムを氾濫させてしまう。 これは、ある種の設計者の怠惰だといえる。 僕には、X.509というものに、そういう利用目的がはっきりしないパラメータが多いと感じる。
電子署名というのは、パソコンで作れるサインのことだ。 クレジットカードで買い物したときに書くサインと同じ意味を持つ。 このサインというものを、西洋では手紙の末尾などに書いたりして、その手紙が確かに本人が書いたということを証明する手がかりにしたりする。 また、契約を交わしたときなどに、契約書に連名でサインを書いたりすることもある。
で、よく考えてみると、このサインというものには、いくつか意味があると思う。 ひとつには手紙などによくあるように「この文章は確かに私が書きました」 という意味だ。 あるいは他人が書いた文章のときであっても「この文章内容に確かに同意しました」という意味のときもある。 このようにサインするという行為には、場合によって、いくつかの違う意味合いが持たされている。
この点電子署名も同じではないか、と僕は思った。 だから電子署名にはこの意味合いをはっきりと区別するための識別子が必要ではないだろうか、と考えたのだ。 特に電子署名の場合、手紙や契約書といったシンプルな利用方法を越えた、システム内部のアルゴリズムに関連する複雑な処理に使われることもあり、このような場合には、署名の意味合いをはっきりとさせなければ、この署名を基盤とした更なる大きな設計をする上で大きな制約となりうる。
曖昧さがなく、多様な使い方に耐える設計というのは容易でなく、色々なことを考える必要がある。 僕にとって最高の設計とは「レゴブロック」だ。 ひとつひとつのブロックはあんなにシンプルな形なのに、無限の形を生み出すことができるレゴブロックというのは、設計のひとつの理想系だと思う。 しかも子供用に出来たすこし大き目のブロック「デュプロ」と互換性を持っている。
（ちなみに日本人にはこういう「互換性を持たせよう」っていう発想があまりない。 確かに、何で互換性を持たせることが大切なのか、と問われても、日本人が好むようなはっきりした答えはないかもしれない。 だけど互換性があるということは、そのものにあらゆる状況に対応できる能力を与える。 それがどういう状況なのかはまだ誰も知らないかもしれないが、互換性というものは、そんな知らない状況に対応できる能力を与えるのだ。）
ところで X509というものには、「有効期限」というものが定められるようになっている。 だが、これって、よく考えてみると、本当に必要なものだろうか。 有効期限とは実にデメリットの多い機能だ。 これがあるおかげで、発行した証明書はいずれ期限がきれて使えなくなってしまう。 だから、自分が発行した証明書をすべて把握した上で、定期的にすべてを発行しなおす必要がある。
何故、そうまでして有効期限を決めたいのだろうか。 恐らく、鍵の紛失の対策として考えられたのではないか、と僕は思う。 鍵を紛失して（盗難されて）しまうと、鍵を無効化することすら出来なくなってしまう。 だからそうならないように証明書にあらかじめ有効期限を定めて、時間がたったら勝手に無効化するようにしたのではないだろうか。
でも、僕は思うのだが、鍵を盗まれても、鍵を盗まれていなくても、鍵の無効化が必要な状況になってしまうと、自分で鍵の無効化が出来なくなってしまう、という点に変わりはない。
この鍵の無効化というのは、実はすごく難しい問題で、多分具体的な解決策は見つかっていないのだと思う。 だから、苦肉の策として有効期限を決めたのではないだろうか。 有効期限を決めると、そこに手作業が必要になるので、そんな手作業に手数料を取って日銭を稼いでいる巨大な会社＝ベリサイン社のような電子セキュリティー会社としても好都合だ。
しかし、僕は思うのだけど、こういう面倒な手作業が必要にならないままに鍵の無効化を実現するうまい方法というのは、おそらく存在するだろう。
この証明書の有効期限管理というのは実に面倒で、これが電子署名・電子証明書の普及を阻害している、ということは少なくともあるだろうと思う。 このアルゴリズムを再考することはきっと有意義じゃないか、と思う。
そういうわけで、電子署名のフォーマットを考えている。
設計のほうは、今、公開鍵暗号のスキームと呼ばれる、組み合わせ方の設計をしているところで、証明書というファイルのフォーマットを考えている。 証明書といえばX.509と呼ばれるフォーマットが一番有名なのだけど、これが僕にはどうしても必要充分な機能を持っていると思えなくて、かつ、不要な機能が多く曖昧な点が多いと感じてる。 そこで、基本的な考え方を継承しつつ、これをもっとカリカリに絞ったファイルフォーマットを設計したい、と思う。
よく、ファイルフォーマットの設計でよくある失敗（アンチパターン）に、拡張領域を作ってしまうというのがあると思う。 そのファイルフォーマットがどのように利用されるのか想定しきれないとき、設計者は「将来の拡張の為に」と、どのような使い方も許されるようなマップ領域をそのフォーマットに加えてしまうのだ。 これは便利なようにみえて実は非常に害が大きい設計方法だと思う。 なぜかというと、このフォーマットをつかってデータを作成する人が、その拡張領域マップにどのようなデータを追加できるのかはっきりせず、またそのデータを利用する側も、その拡張領域マップにどのようなデータが存在することを期待できるのかはっきりしなくなってしまうからだ。 こうなると、作成者側も利用者側も、ありとあらゆる可能性を想定してプログラムを組む必要に駆られてしまう。 すべてのケースを予測しつくすことは不可能で、結果的にデータの互換性を損なってしまうプログラムを氾濫させてしまう。 これは、ある種の設計者の怠惰だといえる。 僕には、X.509というものに、そういう利用目的がはっきりしないパラメータが多いと感じる。
電子署名というのは、パソコンで作れるサインのことだ。 クレジットカードで買い物したときに書くサインと同じ意味を持つ。 このサインというものを、西洋では手紙の末尾などに書いたりして、その手紙が確かに本人が書いたということを証明する手がかりにしたりする。 また、契約を交わしたときなどに、契約書に連名でサインを書いたりすることもある。
で、よく考えてみると、このサインというものには、いくつか意味があると思う。 ひとつには手紙などによくあるように「この文章は確かに私が書きました」 という意味だ。 あるいは他人が書いた文章のときであっても「この文章内容に確かに同意しました」という意味のときもある。 このようにサインするという行為には、場合によって、いくつかの違う意味合いが持たされている。
この点電子署名も同じではないか、と僕は思った。 だから電子署名にはこの意味合いをはっきりと区別するための識別子が必要ではないだろうか、と考えたのだ。 特に電子署名の場合、手紙や契約書といったシンプルな利用方法を越えた、システム内部のアルゴリズムに関連する複雑な処理に使われることもあり、このような場合には、署名の意味合いをはっきりとさせなければ、この署名を基盤とした更なる大きな設計をする上で大きな制約となりうる。
曖昧さがなく、多様な使い方に耐える設計というのは容易でなく、色々なことを考える必要がある。 僕にとって最高の設計とは「レゴブロック」だ。 ひとつひとつのブロックはあんなにシンプルな形なのに、無限の形を生み出すことができるレゴブロックというのは、設計のひとつの理想系だと思う。 しかも子供用に出来たすこし大き目のブロック「デュプロ」と互換性を持っている。
（ちなみに日本人にはこういう「互換性を持たせよう」っていう発想があまりない。 確かに、何で互換性を持たせることが大切なのか、と問われても、日本人が好むようなはっきりした答えはないかもしれない。 だけど互換性があるということは、そのものにあらゆる状況に対応できる能力を与える。 それがどういう状況なのかはまだ誰も知らないかもしれないが、互換性というものは、そんな知らない状況に対応できる能力を与えるのだ。）
ところで X509というものには、「有効期限」というものが定められるようになっている。 だが、これって、よく考えてみると、本当に必要なものだろうか。 有効期限とは実にデメリットの多い機能だ。 これがあるおかげで、発行した証明書はいずれ期限がきれて使えなくなってしまう。 だから、自分が発行した証明書をすべて把握した上で、定期的にすべてを発行しなおす必要がある。
何故、そうまでして有効期限を決めたいのだろうか。 恐らく、鍵の紛失の対策として考えられたのではないか、と僕は思う。 鍵を紛失して（盗難されて）しまうと、鍵を無効化することすら出来なくなってしまう。 だからそうならないように証明書にあらかじめ有効期限を定めて、時間がたったら勝手に無効化するようにしたのではないだろうか。
でも、僕は思うのだが、鍵を盗まれても、鍵を盗まれていなくても、鍵の無効化が必要な状況になってしまうと、自分で鍵の無効化が出来なくなってしまう、という点に変わりはない。
この鍵の無効化というのは、実はすごく難しい問題で、多分具体的な解決策は見つかっていないのだと思う。 だから、苦肉の策として有効期限を決めたのではないだろうか。 有効期限を決めると、そこに手作業が必要になるので、そんな手作業に手数料を取って日銭を稼いでいる巨大な会社＝ベリサイン社のような電子セキュリティー会社としても好都合だ。
しかし、僕は思うのだけど、こういう面倒な手作業が必要にならないままに鍵の無効化を実現するうまい方法というのは、おそらく存在するだろう。
この証明書の有効期限管理というのは実に面倒で、これが電子署名・電子証明書の普及を阻害している、ということは少なくともあるだろうと思う。 このアルゴリズムを再考することはきっと有意義じゃないか、と思う。
そういうわけで、電子署名のフォーマットを考えている。
コメント一覧
ねこ☆ミ。 2009年05月06日 09:11
自分は、証明書の有効期限は、暗号は時間をかけると解かれてしまうので、その対策かと思ってた。
現状では、ある程度有効と思ってるけど、本当に最適であるかを問われると、確かに疑問を感じる。
有効期限を定めなくとも、鍵交換ができる仕組みがあればいいのかもしれない（正直よくわからない。）。
電子署名が付与したモノが、いつでも、何があっても、どんな場合でも、どれでも、必ず、絶対に、電子署付与者のモノであることが保証され、受取人が検証できれば、いいわけだけど、、、
昔、先輩のKさんからのメールの電子署名が受け取った時は有効だったのだが、後から見たときに時間がたったので、失効してたことがある気がする。。。うむうむむむ。なんか変な気が、、、
========以下、よくしらない自分の学習用。
ベリサイン等で、認証局を前提とすれば電子証明書の失効とかできるみたいだけど、、、
信頼できる認証局がないと、失効できないのかな。。。
http://www.verisign.co.jp/personal/class2/help/faq/520066/index.html
証明書失効リスト (CRL) 【Certificate Revocation List】か。
http://www.verisign.co.jp/basic/glossary/crl.html
Online Certificate Status Protocol
http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
現状では、ある程度有効と思ってるけど、本当に最適であるかを問われると、確かに疑問を感じる。
有効期限を定めなくとも、鍵交換ができる仕組みがあればいいのかもしれない（正直よくわからない。）。
電子署名が付与したモノが、いつでも、何があっても、どんな場合でも、どれでも、必ず、絶対に、電子署付与者のモノであることが保証され、受取人が検証できれば、いいわけだけど、、、
昔、先輩のKさんからのメールの電子署名が受け取った時は有効だったのだが、後から見たときに時間がたったので、失効してたことがある気がする。。。うむうむむむ。なんか変な気が、、、
========以下、よくしらない自分の学習用。
ベリサイン等で、認証局を前提とすれば電子証明書の失効とかできるみたいだけど、、、
信頼できる認証局がないと、失効できないのかな。。。
http://www.verisign.co.jp/personal/class2/help/faq/520066/index.html
証明書失効リスト (CRL) 【Certificate Revocation List】か。
http://www.verisign.co.jp/basic/glossary/crl.html
Online Certificate Status Protocol
http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
ねこ☆ミ。 2009年05月06日 09:16
＞昔、先輩のKさんからのメールの電子署名が受け取った時は有効だったのだが、後から見たときに時間がたったので、失効してたことがある気がする。。。うむうむむむ。なんか変な気が、、、
変な気がと思ったが、論理的にそれしかありえないと思った。
あび 2009年05月06日 11:36
証明書の有効期限は、一定期間ごとにその証明書の所有者の正統性を認証局が確認したり、与信情報を再確認するためにあると思っていました。あとは、強制的に今ある証明書を使用不能にして、より暗号強度の強いものへ段階的に移行させるための手段だと思ってました。もしくは、ベリサインの商売のためかと・・・・。
でも、まあ実際のところ、証明書の有効期限切れで運行管理システムが動作せず、全日空の旅客機が運行不能になるという事態も発生した事があるしねえ。
サポートセンターでは、３月末になると、「新しい証明書への切り替えがうまくいきません。明日の午前9時までしか現行の証明書の期限が無いので、なんとかして下さい。」というお客様からの問い合わせが来る事がもはや風物詩になってます。
いずれにせよ、有効期限以外の方法でより良い方法があれば、喜ぶ人たちはいるでしょうね。ポイントは、ユーザも認証局側にとってもメリットがある形にすることかなと思います。
でも、まあ実際のところ、証明書の有効期限切れで運行管理システムが動作せず、全日空の旅客機が運行不能になるという事態も発生した事があるしねえ。
サポートセンターでは、３月末になると、「新しい証明書への切り替えがうまくいきません。明日の午前9時までしか現行の証明書の期限が無いので、なんとかして下さい。」というお客様からの問い合わせが来る事がもはや風物詩になってます。
いずれにせよ、有効期限以外の方法でより良い方法があれば、喜ぶ人たちはいるでしょうね。ポイントは、ユーザも認証局側にとってもメリットがある形にすることかなと思います。
おかあつ 2009年05月06日 17:25
１．
＞自分は、証明書の有効期限は、暗号は時間をかけると解かれてしまうので、その対策かと思ってた。
これは多分違うと思う。 なぜかというと、もしも将来有効期限を過ぎてから暗号が解かれてしまった（＝内部キーを知ることが出来た等新しい署名を作成する何らかの方法を得た）とすると、暗号を解いた人は、過去にさかのぼって有効期限が改変された証明書を偽造することが出来てしまうからだ。 有効期限があってもなくても、暗号が解かれてしまったらなんでも出来てしまうので、意味がないと思う。
２．
＞証明書の有効期限は、一定期間ごとにその証明書の所有者の正統性を認証局が確認したり、与信情報を再確認するためにあると思っていました。あとは、強制的に今ある証明書を使用不能にして、より暗号強度の強いものへ段階的に移行させるための手段だと思ってました。
これは僕も気がつかなかったけど、そうだと思う。 ただし、これって「鍵証明書」という使い方のときを前提とした使い方じゃないかと思う。 鍵証明書であれば、誰かが証明書を使ってその鍵の正当性を証明するにあたって、一定期間ごとに再調査を行い、再調査の結果不適格だとわかったら、証明書の再発行を行わなければ自動的に失効する。
だけどこの使い方は鍵のときなど、第三者による認証というときだけに有効な使い方ではないかと思う。 例えば、もしも誰かが、メールの内容の証明書をつけメールを送ったとしたら、その人が送ったすべてのメールにたいして、そのメールの有効期限が過ぎるごとに証明書の再発行を行わなければいけなくなるはずだ。
メールの内容に証明書をつける場合は、「その瞬間・その時点に、その人がメールを書いたことに変わりはありません」という意味であるはずなのだ。 その事実が時を経て変わってしまうことはない。 だから有効期限を設けるということに、有効期限を設けることで生まれるオーバーヘッド以上の意義は持ち得ないと思う。 だから有効期限を持たせないのが、正当な使い方であるはずではないだろうか。
＞昔、先輩のKさんからのメールの電子署名が受け取った時は有効だったのだが、後から見たときに時間がたったので、失効してたことがある気がする。。。うむうむむむ。なんか変な気が、、
もし僕の推論が正しければ、この疑問は正統だと思う。
３．
＞サポートセンターでは、３月末になると、「新しい証明書への切り替えがうまくいきません。明日の午前9時までしか現行の証明書の期限が無いので、なんとかして下さい。」というお客様からの問い合わせが来る事がもはや風物詩になってます。
しばしば切り替えがうまくいかない理由ってどんな理由なんだろう。
４．
＞いずれにせよ、有効期限以外の方法でより良い方法があれば、喜ぶ人たちはいるでしょうね。ポイントは、ユーザも認証局側にとってもメリットがある形にすることかなと思います。
ＰＧＰと同じ考え方を僕も持っているので、僕はＰＫＩっていう考え方があまり好きじゃない。 確かに、今ベリサイン社のクラスＡとかの証明書を持っていたら、少なくとも詐欺師じゃないだろう、というぐらいなことは思うけど、本当はもっと多様な使い方が出来るはずで、ＰＫＩという考え方にはそういう多様な使い方に対応するポテンシャルがない。
僕が、ねこミさんとかあび氏とかが本当に存在するって言うことを確認するために、何でわざわざベリサイン社の手を煩わせなければいけないのだろうか。 僕が直接会った時に、認証すれば言い話だ。 これは僕だけでなく、誰もが、こうやって実際にあったときに認証すれば事足りるはずで、本来はベリサイン社というのはそこまでは重要じゃないはずだ。
店であれば、実際にその店に足を運んで見たときに、この店は信用できるって思えばその店を認証すればいい。 その人が個人的にその店に裏切られたらその認証は取り消すべきだ。 こうしてどれくらい多くの人がその店を認証しているかを見ることで、ある程度の精度を持った認証が可能になる。 ベリサイン社がそれをする必要は、実はない。
＞自分は、証明書の有効期限は、暗号は時間をかけると解かれてしまうので、その対策かと思ってた。
これは多分違うと思う。 なぜかというと、もしも将来有効期限を過ぎてから暗号が解かれてしまった（＝内部キーを知ることが出来た等新しい署名を作成する何らかの方法を得た）とすると、暗号を解いた人は、過去にさかのぼって有効期限が改変された証明書を偽造することが出来てしまうからだ。 有効期限があってもなくても、暗号が解かれてしまったらなんでも出来てしまうので、意味がないと思う。
２．
＞証明書の有効期限は、一定期間ごとにその証明書の所有者の正統性を認証局が確認したり、与信情報を再確認するためにあると思っていました。あとは、強制的に今ある証明書を使用不能にして、より暗号強度の強いものへ段階的に移行させるための手段だと思ってました。
これは僕も気がつかなかったけど、そうだと思う。 ただし、これって「鍵証明書」という使い方のときを前提とした使い方じゃないかと思う。 鍵証明書であれば、誰かが証明書を使ってその鍵の正当性を証明するにあたって、一定期間ごとに再調査を行い、再調査の結果不適格だとわかったら、証明書の再発行を行わなければ自動的に失効する。
だけどこの使い方は鍵のときなど、第三者による認証というときだけに有効な使い方ではないかと思う。 例えば、もしも誰かが、メールの内容の証明書をつけメールを送ったとしたら、その人が送ったすべてのメールにたいして、そのメールの有効期限が過ぎるごとに証明書の再発行を行わなければいけなくなるはずだ。
メールの内容に証明書をつける場合は、「その瞬間・その時点に、その人がメールを書いたことに変わりはありません」という意味であるはずなのだ。 その事実が時を経て変わってしまうことはない。 だから有効期限を設けるということに、有効期限を設けることで生まれるオーバーヘッド以上の意義は持ち得ないと思う。 だから有効期限を持たせないのが、正当な使い方であるはずではないだろうか。
＞昔、先輩のKさんからのメールの電子署名が受け取った時は有効だったのだが、後から見たときに時間がたったので、失効してたことがある気がする。。。うむうむむむ。なんか変な気が、、
もし僕の推論が正しければ、この疑問は正統だと思う。
３．
＞サポートセンターでは、３月末になると、「新しい証明書への切り替えがうまくいきません。明日の午前9時までしか現行の証明書の期限が無いので、なんとかして下さい。」というお客様からの問い合わせが来る事がもはや風物詩になってます。
しばしば切り替えがうまくいかない理由ってどんな理由なんだろう。
４．
＞いずれにせよ、有効期限以外の方法でより良い方法があれば、喜ぶ人たちはいるでしょうね。ポイントは、ユーザも認証局側にとってもメリットがある形にすることかなと思います。
ＰＧＰと同じ考え方を僕も持っているので、僕はＰＫＩっていう考え方があまり好きじゃない。 確かに、今ベリサイン社のクラスＡとかの証明書を持っていたら、少なくとも詐欺師じゃないだろう、というぐらいなことは思うけど、本当はもっと多様な使い方が出来るはずで、ＰＫＩという考え方にはそういう多様な使い方に対応するポテンシャルがない。
僕が、ねこミさんとかあび氏とかが本当に存在するって言うことを確認するために、何でわざわざベリサイン社の手を煩わせなければいけないのだろうか。 僕が直接会った時に、認証すれば言い話だ。 これは僕だけでなく、誰もが、こうやって実際にあったときに認証すれば事足りるはずで、本来はベリサイン社というのはそこまでは重要じゃないはずだ。
店であれば、実際にその店に足を運んで見たときに、この店は信用できるって思えばその店を認証すればいい。 その人が個人的にその店に裏切られたらその認証は取り消すべきだ。 こうしてどれくらい多くの人がその店を認証しているかを見ることで、ある程度の精度を持った認証が可能になる。 ベリサイン社がそれをする必要は、実はない。
おかあつ 2009年05月06日 17:28
もしも、友達を認証するとき、「この人は僕の友達です」っていうことであるなら、有効期限があったほうが運用しやすいのだと思う。 ある時点から友達とは認めない、ということがありえるからだ。 あるいは、「この鍵は間違いなくこの人の持ち物です」ということを認証するのであれば、「ある時点でこの鍵はこの人の持ち物でした」という意味になるので、有効期限はないまま運用するのが適切だと思う。
こうして考えると「ある時点での確かさを認証する場合」と「恒久的な確かさを認証する場合」とあるような気がしてきた。
この発想を元に今日一日また考え事をしてみようと思う。
こうして考えると「ある時点での確かさを認証する場合」と「恒久的な確かさを認証する場合」とあるような気がしてきた。
この発想を元に今日一日また考え事をしてみようと思う。
おかあつ 2009年05月06日 18:00
Online Certificate Status Protocol ってなんとなくアドホックな香りのする技術だな．．．。
あび 2009年05月07日 12:14
> しばしば切り替えがうまくいかない理由ってどんな理由なんだろう。
そもそも証明書の更新方法を把握してなかったとか、更新手順が前任者から引継ぎされてないとか、中間証明書が必要になった事を認識してなくてエラーになったとか、そんなパターンが殆どですよ。
そもそも証明書の更新方法を把握してなかったとか、更新手順が前任者から引継ぎされてないとか、中間証明書が必要になった事を認識してなくてエラーになったとか、そんなパターンが殆どですよ。
ねこ☆ミ。 2009年05月07日 13:28
＞＞自分は、証明書の有効期限は、暗号は時間をかけると解かれてしまうので、その対策かと思ってた。
＞これは多分違うと思う。なぜかというと、もしも将来有効期限を過ぎてから暗号が解かれてしまった（＝内部キーを知ることが出来た等新しい署名を作成する何らかの方法を得た）とすると、暗号を解いた人は、過去にさかのぼって有効期限が改変された証明書を偽造することが出来てしまうからだ。有効期限があってもなくても、暗号が解かれてしまったらなんでも出来てしまうので、意味がないと思う。
ちょっと考えてみた、現状の自分の理解では、、、
証明書の有効期限は、署名作成できる有効期限ではなく、検証可能な有効期限であると思う。
そのため、将来有効期限を過ぎてから、証明書が偽造されてもなんら問題はない。
たとえば、受け取った瞬間はただしい署名であっても、時間がたつと有効期限が過ぎて正しいとは限らない署名となる。
もう一例、7年保存義務のある文章の場合、署名の有効期限が途中で切れてしまうので、再度、前回分と今回分の期間が有効なタイムスタンプを押すようだ。
http://www.nri.co.jp/opinion/kinyu_itf/2005/pdf/itf20050305.pdf
＞これは多分違うと思う。なぜかというと、もしも将来有効期限を過ぎてから暗号が解かれてしまった（＝内部キーを知ることが出来た等新しい署名を作成する何らかの方法を得た）とすると、暗号を解いた人は、過去にさかのぼって有効期限が改変された証明書を偽造することが出来てしまうからだ。有効期限があってもなくても、暗号が解かれてしまったらなんでも出来てしまうので、意味がないと思う。
ちょっと考えてみた、現状の自分の理解では、、、
証明書の有効期限は、署名作成できる有効期限ではなく、検証可能な有効期限であると思う。
そのため、将来有効期限を過ぎてから、証明書が偽造されてもなんら問題はない。
たとえば、受け取った瞬間はただしい署名であっても、時間がたつと有効期限が過ぎて正しいとは限らない署名となる。
もう一例、7年保存義務のある文章の場合、署名の有効期限が途中で切れてしまうので、再度、前回分と今回分の期間が有効なタイムスタンプを押すようだ。
http://www.nri.co.jp/opinion/kinyu_itf/2005/pdf/itf20050305.pdf
おかあつ 2009年05月07日 13:41
このPDF、ドンピシャな内容だ！ ... しかもNRIだ。
おかあつ 2009年05月07日 13:46
このPDF極めて具体的だと思う。 最終的にどういう行動を起こすべきなのかまでが網羅的に考えられていて、とてもいい。 さすがNRI。
おかあつ 2009年05月07日 13:51
＞ ヒステリシス署名と呼ばれるこの方式は、日立製作所、早稲田大学他6)が共同で開発したもので、定期的な再署名を必要としない長期保存に適した署名方式である。この方式の署名には、過去に行われた全ての署名の情報の一部が取り込まれるため、過去の署名を改ざんするためには、それ以降に署名された全ての署名をも改ざんせねばならなくなる。連鎖の履歴を順に検証することで、改ざんの検知が可能であり、また署名の一部を定期的に新聞に掲載して歴史的事実の一部としたり、公証局に預託したりすることで改ざんの難易度をさらに高めることも可能である。
これは恐らく、ある値に対して繰り返しDIGEST値を求めることで実装するんじゃないだろうか。
これは恐らく、ある値に対して繰り返しDIGEST値を求めることで実装するんじゃないだろうか。
おかあつ 2009年05月07日 14:01
＞一方、情報処理推進機構（IPA）が中心となって研究されているUSDSS署名方式は、従来とは全く異なる暗号技術を利用している。現在デジタル署名に用いられている公開鍵暗号は、時間さえあれば計算によって鍵を見つけることは原理的に可能だが、USDSS署名方式では攻撃者が入手可能な情報が十分でないため、いかに高速なコンピュータをもってしても解読は原理的に不可能なのである。
一方で、こちらはかなり胡散臭い感じする。
そんな性質のいい暗号があったら今頃世界中で大騒ぎになってるはずと思う。
４年前の話だけど、多分立ち消えになってるんじゃないだろうか。
http://www.iftech.or.jp/center/kbes/dictonary/cnot_01.htm
これを見る限り、公開鍵を単に鍵管理センター方式にしただけの物じゃないだろうか。
しょぼいなぁ．．．。
一方で、こちらはかなり胡散臭い感じする。
そんな性質のいい暗号があったら今頃世界中で大騒ぎになってるはずと思う。
４年前の話だけど、多分立ち消えになってるんじゃないだろうか。
http://www.iftech.or.jp/center/kbes/dictonary/cnot_01.htm
これを見る限り、公開鍵を単に鍵管理センター方式にしただけの物じゃないだろうか。
しょぼいなぁ．．．。
おかあつ 2009年05月07日 14:06
＞この方式の署名には、過去に行われた全ての署名の情報の一部が取り込まれるため、過去の署名を改ざんするためには、それ以降に署名された全ての署名をも改ざんせねばならなくなる。
よく読んでみると、これも、ちょっと怪しい。 もしも署名の改ざんが成功するとしたら、そのときには署名の改ざんが簡単になるような何かしらの新しい技術が生まれているかもしれず、であればすべての署名を、自動的な処理を使って一定時間の間に破ることは、可能になっているかもしれない。 そうなっていたら、連続ダイジェスト値を署名に含めたところで何の意味もないだろうと思う。
そこまで考えるならダイジェスト値の衝突を見つけるたやすい方法が見つかったときのことも想定しなければいけないはずで、そこまで考えると、ちょっとキリが無い感じがする。
よく読んでみると、これも、ちょっと怪しい。 もしも署名の改ざんが成功するとしたら、そのときには署名の改ざんが簡単になるような何かしらの新しい技術が生まれているかもしれず、であればすべての署名を、自動的な処理を使って一定時間の間に破ることは、可能になっているかもしれない。 そうなっていたら、連続ダイジェスト値を署名に含めたところで何の意味もないだろうと思う。
そこまで考えるならダイジェスト値の衝突を見つけるたやすい方法が見つかったときのことも想定しなければいけないはずで、そこまで考えると、ちょっとキリが無い感じがする。
おかあつ 2009年05月07日 14:09
結果的に、この文章、一枚目の問題提起はとてもすばらしいけど、二枚目の解決策の提示がすごく甘いと思う。 問題提起の部分は、現実社会においてのデジタル署名のあり方を非常に具体的に捉えているのでリアリティーがある。 一方で解決策は暗号に対する知識の不足が目立つ。
おかあつ 2009年05月07日 14:35
http://en.wikipedia.org/wiki/Public_key_infrastructure
これを読むとますます何故 expiration date が設定されるのか訳がわからなくなる。 一般的に expiration date を設定するのは、暗号が破られたときのことを想定している物ではないとされているように思う。 本人と鍵の結びつきを検証するとき、一定期間以上立つとその結びつきの確かさが失われるため、それを再度確実にするために expire するのではないかと思う。
これを読むとますます何故 expiration date が設定されるのか訳がわからなくなる。 一般的に expiration date を設定するのは、暗号が破られたときのことを想定している物ではないとされているように思う。 本人と鍵の結びつきを検証するとき、一定期間以上立つとその結びつきの確かさが失われるため、それを再度確実にするために expire するのではないかと思う。
おかあつ 2009年05月07日 14:37
ここにSPKIというアイデアが書き込まれている。 これは恐らく開発者自身が自分で書き込んだんじゃないか、って想像するけど、この考え方は僕が好きな考え方だ。 鍵と本人の結びつきを管理する必要は、実はない。 鍵自体がその人の顔の役割を果たす、と考えることは出来る。
おかあつ 2009年05月07日 15:00
恐らくプログラマ的にはこれ以上のことを考える必要は無いかもしれない。 言葉の上でどちらが正しいか確認することが出来ないなら、実験するしかないし、プログラマには自分の手で実験が可能という特権がある。
おかあつ 2009年05月07日 15:09
ところで、
＞ たとえば、受け取った瞬間はただしい署名であっても、時間がたつと有効期限が過ぎて正しいとは限らない署名となる。
これはタイムスタンプサーバーという物を使えば、その署名がその瞬間に作られた物だということが証明できる。 署名がなされた後にその鍵が compromise してしまったとしても、その署名がcompromise される以前の、その瞬間に作られたことだけは保障されるはず（＝タイムスタンプがあれば新しい鍵の保有者が過去にさかのぼって書名を偽造することは出来ないはず）なので、 だからこれも有効期限が必要な理由にはならない。
＞ たとえば、受け取った瞬間はただしい署名であっても、時間がたつと有効期限が過ぎて正しいとは限らない署名となる。
これはタイムスタンプサーバーという物を使えば、その署名がその瞬間に作られた物だということが証明できる。 署名がなされた後にその鍵が compromise してしまったとしても、その署名がcompromise される以前の、その瞬間に作られたことだけは保障されるはず（＝タイムスタンプがあれば新しい鍵の保有者が過去にさかのぼって書名を偽造することは出来ないはず）なので、 だからこれも有効期限が必要な理由にはならない。
おかあつ 2009年05月07日 18:27
本当によく考えてみると、NRI のドキュメントで説明されているような証明書って、ひょっとして、まったくのあかの他人が「このドキュメント、自分が書きました」っていう証明書を発行することをまったく防ぐ手段がないような気がする。
うーむ．．．。 これってよく考えてみると、まったくきちんとワークしてなくね？
うーむ．．．。 これってよく考えてみると、まったくきちんとワークしてなくね？
おかあつ 2009年05月08日 18:02
中間証明書
http://www.verisign.co.jp/ssl/help/faq/110089/index.html
中間証明書というものを知らなかった。 あび氏が発言したとき、それってなんだろう、と思ったけどその後のＮＲＩのドキュメントに気を取られて忘れていた。
要するに校長先生が田中先生を信頼していて田中先生が山田君を信頼していて、山田君は、俺を信頼しているわけだから、俺の言うことは絶対、みたいなことだよね。
ということは、今までは証明書さえあれば何でも信用していたのだろうか。
http://www.verisign.co.jp/ssl/help/faq/110089/index.html
中間証明書というものを知らなかった。 あび氏が発言したとき、それってなんだろう、と思ったけどその後のＮＲＩのドキュメントに気を取られて忘れていた。
要するに校長先生が田中先生を信頼していて田中先生が山田君を信頼していて、山田君は、俺を信頼しているわけだから、俺の言うことは絶対、みたいなことだよね。
ということは、今までは証明書さえあれば何でも信用していたのだろうか。
おかあつ 2009年05月08日 18:06
つまり、PKIも結果的に Web Of Trust と同じようなことになっているんだな。 Web Of Trust の方も PKIと同じようにExpiration を設定するようになっていたりするし、僕が考えたこと（鍵の政治関係説）は、どうやら間違っていなさそうだ。
