アカウント名:
パスワード:
鍵の真正性
LDAPってグローバルに運用できるんだっけか。
「署名用の鍵」と「確認用の鍵」に曖昧さはないよ。同時に使うことがないんだから。# それに署名の場合P/Sが暗号の場合と逆にならなかったっけ？
「LDAPをインターネット全体に対して運用して問題はないのか(設定に問題はないのか)」
根本的な解決にはなりません。なるよ。言っとくけど強度付き証明の話だからね。
根本的な解決にはなりません。
「署名用」と署名に限定した上でその対になる「確認用」に対して署名以外のものを想定して曖昧だと主張するのはどういう了見なのさ。
クライアント側で設定が必要なこと自体も問題視しているんだけど？
だから通信路の暗号化や通信先の証明ではなくデータに対する署名の話だと(ry
暑名用の鍵を置いとく認証局っぽい場所ってないよね？そこにIDを問い合わせると鍵見せてくれるみたいな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
それってレポジトリ… (スコア:1)
だったら、LDAPかなんかで証明書なりフィンガープリントなりを公開しておけば良いんじゃないかと愚考いたしますが、それじゃダメなんでしょうか？
Re:それってレポジトリ… (スコア:1)
どっちかというと違うよ。署名の鍵がメインターゲット。つまり問題になるのは鍵の真正性。非対称暗号の公開鍵が違ってても復号できないだけだけど、ある書類の署名が本人の署名であることを確認するには確認用の鍵の真正性が問題になる。そして非対称暗号の公開鍵にしてもグローバルに、かつ一度設定するだけで運用できないと何かと面倒...LDAPってグローバルに運用できるんだっけか。
PGPの鍵サーバ? (スコア:1)
とか？
もっともこれは「本当にその公開鍵が登録名の人のものか」が判らないからなんとも言えないね。結局、CA的な何かによって本人確認(本人と鍵ペアの結び付きの確認)が必要だったり。
それか「信頼の輪」をソフト的に実装したサーバがあれば…(もしかしてすでにある？)
Re:PGPの鍵サーバ? (スコア:1)
そうそう、それそれ。
TLSなんかは伝送路の真正性を証明するものでもあるけど。データの真正性が証明できるなら伝送路の方はどうでもいいじゃない。というのがミソ。P2Pな「伝送路」だとメッセージダイジェストが使われてるけど、今の署名やメッセージダイジェストは結局のところオレオレ証明書と同じレベルなので何とかならんかなというのもある。
>「信頼の輪」をソフト的に実装したサーバ
少なくともノードの真正性は担保されるかな？
Re:それってレポジトリ… (スコア:1)
X.509的に言うとどの辺りが問題だと言っているのでしょうか？
「署名用の鍵」「確認用の鍵」というのも曖昧な表現でよく解りません。
例えば、非対称鍵ペア(P,S)があったとき、データTに署名するには、A=encrypt(S,hash(T))とTを相手に送ればいい。
送られた相手は、Pを何らかの方法で入手しておき、decrypt(P,A)とhash(T)を比較する。
一般に、PおよびSは、それぞれ公開鍵および秘密鍵と呼ばれます(Sが「署名用の鍵]でPが「確認用の鍵」?)。
Pの入手方法及びその正しさ(これが「真正性」?)は、別の方法で保証されねばなりません。例えばX.509的な方法だと、信頼できるCAの署名を検証することになりますが、これは上の問題が入れ子になっただけで、根本的な解決にはなりません。
一般には、フィンガープリントを信用できる方法で入手したり、あるいはOSやブラウザに組み込みのものを信用する、という方法が採られています。
この仕組みや方法に対して、いろんな議論があるのは当然なのですが、どこが問題だと捉えるかによって答は変わってきますので、正確な議論が必要です。
「グローバルに運用」ってのが意味不明です。
が例えば、インターネット上にディレクトリを公開することはできます。
Bigfoot(ldap.bigfoot.com)あたりが昔からやってたと思います。
Re:それってレポジトリ… (スコア:1)
その話をしているの。だから最初のコメントの「証明書なりフィンガープリントなりを公開しておけば良いんじゃないか」に対して「どうするのが良いのか」「LDAPをインターネット全体に対して運用して問題はないのか(設定に問題はないのか)」とかいう話になっているわけですよ。それに、ディレクトリを公開できるだけじゃ結局オレオレ証明書だし。
「署名用の鍵」と「確認用の鍵」に曖昧さはないよ。同時に使うことがないんだから。
# それに署名の場合P/Sが暗号の場合と逆にならなかったっけ？
>信頼できるCAの署名を検証することになりますが、これは上の問題が入れ子になっただけで、根本的な解決にはなりません。
なるよ。言っとくけど強度付き証明の話だからね。
Re:それってレポジトリ… (スコア:1)
普通、署名するときにはA=encrypt(S,hash(T))を計算し、署名を検証(普通「確認」ではなく「検証」と言います)するときにはdecrypt(P,A)を計算します。このときだけを見れば、仮にSを署名用、Pを検証用(確認用)と呼んでも混乱はしません。
一方、暗号時には、対称鍵Kを生成しておいて、Ct=encrypt(K,T)とCk=encrypt(P,K)を計算します。復号時には、decrypt(S,Ck)を計算してKを得て(…{1})、decrypt(K,Ct)を計算してTを得ます(…{2})。{1}では、正しくKが得られるかどうか「確認」しますし、{2}では正しくTが得られるかどうか「確認」します。
復号時に、「確認用の鍵」と呼ぶとすれば、どれのことでしょうか？Kかもしれませんし、Sかも知れませんね。でも、Pではないでしょう。
以上、少なくとも、「確認用の鍵」と言った場合、PなのかSなのか、各セッション毎のKなのか、それともまったく別のものなのか、どれを指すかが曖昧です。少なくとも、一般に通用する用語ではありません。オレオレ用語を使うのは自由ですが、少なくとも定義が必要です。
LDAPにどんな設定があったら問題がある、と考えているんですか？
もちろんヘンな設定によって問題は生じますが、着目点によって問題は変わってきます。
「根本的な解決」になるのなら、なにも問題ないのでは？
Re:それってレポジトリ… (スコア:1)
>LDAPにどんな設定があったら問題がある、と考えているんですか？
コメントちゃんと読んでないでしょ？
クライアント側で設定が必要なこと自体も問題視しているんだけど？
>「根本的な解決」になるのなら、なにも問題ないのでは？
だから通信路の暗号化や通信先の証明ではなくデータに対する署名の話だと(ry
Re:それってレポジトリ… (スコア:1)
「署名用」というのだって曖昧ですよ。確かに通常の署名はSで署名しますが、Pで署名することも可能です(意味はないでしょうけどね)。
…と私の主張があなたに「曖昧でなく」通用しているのは、PとSを明示的に定義したからですし、一般的な用語を使ったからです。そうすればいいだけなのに、なんで「署名用」「確認用」という判り難い特殊な用語を使うのでしょう？それこそ「どういう了見なのさ」。
クライアント側で何も設定しないような認証ってのも難しい話だと思いますが。
通信先の証明とデータへの署名、基本的には同じような仕組みですが、そういう話ではないのですか？
＃「通信先の証明」というのも曖昧ですが、例えばSSL/TLSのサーバ認証の類だと理解しています。
＃＃というような確認をしなくていい文章を書いた方がいいんじゃないかな。
で、元の問題は、X.509 PKIのようなもので解決するようなものじゃないんですか？「根本的に解決」するって話でしたっけ？ハッキリさせて欲しいなあ。
Re:それってレポジトリ… (スコア:1)
で、元の問題に戻って考えると、翻訳すれば「秘密鍵Sを預けておいて、IDを問い合わせると、対応する秘密鍵を見せてくれるような機関」って話になりますね。どういうときに秘密鍵を見せてくれるのか不明ですが、秘密鍵を秘密で無くしてしまう様なものは、無い方が「真正性」が保てるでしょう。
＃ホントにそんな機関が必要だとお考えですか？
ちなみに、PKIでは鍵の紛失や、組織のメンバーの死亡・退会(・失踪(笑))に備えて秘密鍵を預けておく「鍵回復機関」(あるいか「鍵回復サービス」)を準備しておく場合があります。ただこれは、本人もしくは相当の権限を持つ管理者の要求によってのみ鍵を提示します。多分、上のような使い方はしません。