パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Comodo CAがサーバ証明書を関係のない第三者に発行、大問題に」記事へのコメント

  • by Anonymous Coward
    こういう業者がたくさんいることで、ベリサインなどの業者が証明書を高い値段で売りつけることが出来るようになるわけで、単にいなくなれば良いというわけでもないでしょう。

    # というか、上場企業の証明書が、エロサイトと同じ発行元だったらそれはそれで常識を疑う。良いか悪いかは別として。

    • by Anonymous Coward

      上場企業の証明書が、エロサイトと同じ発行元だったらそれはそれで常識を疑う。良いか悪いかは別として。

      いや、全然疑わない。サーバ証明書は単なる暗号化の道具ですよ?
      どこのを使っても暗号化には全く能力は同じです。

      • > いや、全然疑わない。サーバ証明書は単なる暗号化の道具ですよ?
        > どこのを使っても暗号化には全く能力は同じです。

        それは半分は正しいですが、半分は誤りです。

        サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は通信相手が「誰なのか」を明確にする事です。暗号化の能力は同じ(というより、むしろサーバ証明書には無関係)ですが、「誰なのか」を明確にする能力は認証局の認証方針とその信頼性に依存します。

        幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。
        • by Anonymous Coward

          幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。

          相手がどこの誰かなんて必要でありません。slashdot.jp を利用するときに必要なのは通信相手がいつもの slashdot.jp であることの確認であり、それさえ確認されれば(多くの人にとって)十分であり、中の人がどこの会社かということなど確認を必要としていません。なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。

          サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は

          • > 相手がどこの誰かなんて必要でありません。slashdot.jp を利用するときに必要なのは通信相手がいつもの slashdot.jp であることの確認であり、それさえ確認されれば(多くの人にとって)十分であり、中の人がどこの会社かということなど確認を必要としていません。

            「通信相手がいつもの××であることの確認」をどうすれば良いのかという事が問題なのですから、「それさえ確認されれば」というのは論点が違います。

            「それさえ確認されれば」というのは問題が解決した後の話であって、その場合の論点は「暗号」や「ハッシュ」の方式やビット長の話です。サーバ/クライアン
            • by Anonymous Coward

              > なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。

              それは/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません。どのようにすれば、ネットワークを介した相手が「××であるのは確からしい」と確信を持つ事ができるかという話をしているのですよ。

              なら、あなたはどうやって今 slashdot.jp にログインしてそれを書き込んだのですか?

              > 無関係?まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか?

              同じですよ。slashdot.jpのプライベートCAが発行した証明書で何ら問題は有りません。

              これはひどい。そこまで無知な人と話をしているとは思いませんでした。お話しになりまん。さようなら。

              • > なら、あなたはどうやって今 slashdot.jp にログインしてそれを書き込んだのですか?

                貴方と同じ方法です。

                しかし/.にログインする話と、例えば銀行のオンラインバンクにログインする話では、その重要性は全く違います。銀行のオンラインバンクが別の銀行と共同で利用しているような場合には、銀行のその他のページとは別のドメインで運用されている事も有ります。それが「いつも使っている銀行のオンラインバンクであるのは確からしい」と確信をどうやって持てるのかという話です。

                >>> 無関係?まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか?
              • by Anonymous Coward
                横から失礼します。

                > 銀行のその他のページとは別のドメインで運用されている事も有ります。
                > それが「いつも使っている銀行のオンラインバンクであるのは確からしい」
                > と確信をどうやって持てるのかという話です。

                別のドメインで運用するのが間違いではないでしょうか。
                私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。
                私だったら別のドメインで運用している銀行は使わないです。
                もっともそういうのは地方銀行の一部だけのようですが。
              • > 別のドメインで運用するのが間違いではないでしょうか。
                > 私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。

                いや、間違いでは有りませんよ。

                もちろん利用者が直感的に判りやすいという意味ではそうすべきという考え方も有りますが、全てのWebサイトを同じドメイン名で運営できるとは限りませんよね。Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。オンラインバンクに限らず、認証ページだけ別のWebサイトというのも有り得る話だと思います。

                第一、httpで運営されているWebサイトとhttpsで運営されているWebサイトが、同一の運営主体であるという確認をするのは、片方にしか証明書が存在しない以上、確実性に乏しい事は間違い無いと思います。

                > 私だったら別のドメインで運用している銀行は使わないです。
                > もっともそういうのは地方銀行の一部だけのようですが。

                そうですね。そういう考え方も有ると思います。
              • by Anonymous Coward
                > 全てのWebサイトを同じドメイン名で運営できるとは限りませんよね。

                いや、できますよ。ASP利用でもDNS設定すればいいことだし、
                実際IBMのASPはそうしているようですよ。

                > Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。

                いえいえ、バーチャルホストなら負荷の問題はありませんし、
                IPベースバーチャルホストなら SSLも普通に使えます。
                地方銀行がやっていないのは ASP会社のNTTデータが怠慢なだけですね。

                > オンラインバンクに限らず、認証ページだけ別のWebサイトというのも
                > 有り得る話だと思います。

                それで、その場合に、認証ページのサーバ証明書のサブジェクトは銀行名に
                なるんでしょうか? ならないようですが?
              • > いや、できますよ。ASP利用でもDNS設定すればいいことだし、
                > 実際IBMのASPはそうしているようですよ。

                いいえ、それは一概には言えません。
                名前ベースのバーチャルドメインでは、サーバ証明書の運用は技術的な仕様により困難です。

                > いえいえ、バーチャルホストなら負荷の問題はありませんし、
                > IPベースバーチャルホストなら SSLも普通に使えます。

                いや、私が申し上げているのは、もっと広い意味での運営体制です。

                Webサーバの運用体制というより、何らかのサービスを提供するWebサイトを維持し運営する体制といった事を想定しており、サービス毎に別々のド
              • by Anonymous Coward
                > 名前ベースのバーチャルドメインでは、サーバ証明書の運用は技術的な
                > 仕様により困難です。

                だから、「IPベースバーチャルホストなら SSLも普通に使えます」と言った
                のに、IPベースバーチャルホストを知らないのですか?

                > 負荷分散のために機能的にサーバ分けたり、

                IPベースバーチャルホストで解決すると言っているんですけど?

                > 或いは機能や価格を考慮して外部のASPサービスを部分的に利用する事など

                実在証明付きサーバ証明書を必要とするようなサイトが、そんな
                安かろう悪かろうのサービスを選択すること自体が間違いですね。

                > 他に優先される事が多いのではないかという事
              • > だから、「IPベースバーチャルホストなら SSLも普通に使えます」と言った
                > のに、IPベースバーチャルホストを知らないのですか?

                知っています。

                しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか? またあくまでも可能性の話ならば、仮にIPベースの実装であっても独自ドメイン名によるサーバ証明書の運用が
              • by Anonymous Coward

                しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか?

                で、そのときに、(詐欺まがいの商法で売りつけている)サーバ証明書の実在証明で、その会社の会社名が Subject に記載されるのですか?されないでしょ?いったい何が言いたいの?

                TLS/SSLはPKI(公開鍵暗号基盤)の実装です。そうであるにも関わらず「基盤」である事を無視して、T

              • > で、そのときに、(詐欺まがいの商法で売りつけている)サーバ証明書の実在証明で、その会社の会社名が Subject に記載されるのですか?されないでしょ?いったい何が言いたいの?

                サーバ証明書はそのサイトの運営主体に発行され、そのサイトの運営主体をSubjectに記載します。
                「servicename.comの認証ページがcompanyname.comでも良いですよね」
                その両方がA社の物で両方ともhttpsで運営するなら、両方のサーバ証明書のSubjectにはA社が記載される事になります。
                貴方こそ、私には一体何が言いたいのか判りません。

                詐欺まがい商法というのは、貴方の歪んだ主観に過ぎません。
              • by nisiguti (1286) on 2009年01月07日 5時55分 (#1486589)
                全く返事がありませんね…。

                公開鍵と共通鍵の使い分け、X.509証明書の書式、検証者が行う証明書の検証手順、PKIにおける信頼できる第三者の役割などは、TLS/SSLの技術論を議論するためには必要な事です。
                しかし、どうやら散々文句を言っていた匿名の臆病者は、単にそれらの知識が足りない人のようですね。彼の主張はそれらの技術的裏づけも客観的な事実の裏付けもなく、彼の主張に反論しても無視されますし、彼が主張する「勘違い」についても結局具体的な指摘もできないようです。

                散々人をこき下ろしておいて最後がこれとは実に無責任。匿名でも臆病者でも結構ですが、発言した事の責任を果たせないのなら、発言しないで頂きたい。
                親コメント

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...