更に言えば、実在認証を否定しサーバ証明書のコモンネーム以外の情報を否定しているにも関わらず、プライベートCAを否定するのは矛盾しています。 認証局の証明書もエンドエンティティの証明書も、一部の情報が異なるだけで同じ書式の証明書です。WebTrust for CAに準拠した認証局は、全て「実在認証された証明書」で運営されています。実在認証を否定しSubject CNが合致していれば十分であるというのならば、プライベートCAの実在認証されていない認証局証明書でもそれで「十分」です。否定する理由が有りません。
むしろ、 (スコア:0)
# というか、上場企業の証明書が、エロサイトと同じ発行元だったらそれはそれで常識を疑う。良いか悪いかは別として。
Re: (スコア:0)
いや、全然疑わない。サーバ証明書は単なる暗号化の道具ですよ？
どこのを使っても暗号化には全く能力は同じです。
Re: (スコア:1)
> どこのを使っても暗号化には全く能力は同じです。
それは半分は正しいですが、半分は誤りです。
サーバ証明書は暗号化の道具には違い有りませんが、その記載事項の目的は通信相手が「誰なのか」を明確にする事です。暗号化の能力は同じ(というより、むしろサーバ証明書には無関係)ですが、「誰なのか」を明確にする能力は認証局の認証方針とその信頼性に依存します。
幾ら高度な暗号方式を用いて暗号化したところで、その相手がどこの誰か判らないのなら、暗号化の能力など全く意味を為しません。
Re: (スコア:0)
相手がどこの誰かなんて必要でありません。slashdot.jp を利用するときに必要なのは通信相手がいつもの slashdot.jp であることの確認であり、それさえ確認されれば（多くの人にとって）十分であり、中の人がどこの会社かということなど確認を必要としていません。なぜなら、既に slsahdot.jp 自体が既に信頼を得ているからです。「全く意味を為しません」は虚偽です。
Re: (スコア:1)
「通信相手がいつもの××であることの確認」をどうすれば良いのかという事が問題なのですから、「それさえ確認されれば」というのは論点が違います。
「それさえ確認されれば」というのは問題が解決した後の話であって、その場合の論点は「暗号」や「ハッシュ」の方式やビット長の話です。サーバ/クライアン
Re: (スコア:0)
なら、あなたはどうやって今 slashdot.jp にログインしてそれを書き込んだのですか？
これはひどい。そこまで無知な人と話をしているとは思いませんでした。お話しになりまん。さようなら。
Re: (スコア:1)
貴方と同じ方法です。
しかし/.にログインする話と、例えば銀行のオンラインバンクにログインする話では、その重要性は全く違います。銀行のオンラインバンクが別の銀行と共同で利用しているような場合には、銀行のその他のページとは別のドメインで運用されている事も有ります。それが「いつも使っている銀行のオンラインバンクであるのは確からしい」と確信をどうやって持てるのかという話です。
>>> 無関係？まさか自己署名証明書でも暗号化能力が同じだとか思ってませんか？
Re: (スコア:0)
> 銀行のその他のページとは別のドメインで運用されている事も有ります。
> それが「いつも使っている銀行のオンラインバンクであるのは確からしい」
> と確信をどうやって持てるのかという話です。
別のドメインで運用するのが間違いではないでしょうか。
私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。
私だったら別のドメインで運用している銀行は使わないです。
もっともそういうのは地方銀行の一部だけのようですが。
Re: (スコア:1)
> 私が使っている都銀ではその銀行のドメインでサーバが運用されていますよ。
いや、間違いでは有りませんよ。
もちろん利用者が直感的に判りやすいという意味ではそうすべきという考え方も有りますが、全てのWebサイトを同じドメイン名で運営できるとは限りませんよね。Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。オンラインバンクに限らず、認証ページだけ別のWebサイトというのも有り得る話だと思います。
第一、httpで運営されているWebサイトとhttpsで運営されているWebサイトが、同一の運営主体であるという確認をするのは、片方にしか証明書が存在しない以上、確実性に乏しい事は間違い無いと思います。
> 私だったら別のドメインで運用している銀行は使わないです。
> もっともそういうのは地方銀行の一部だけのようですが。
そうですね。そういう考え方も有ると思います。
Re: (スコア:0)
いや、できますよ。ASP利用でもDNS設定すればいいことだし、
実際IBMのASPはそうしているようですよ。
> Webサイトの負荷や管理運営体制に強く依存する話ではないでしょうか。
いえいえ、バーチャルホストなら負荷の問題はありませんし、
IPベースバーチャルホストなら SSLも普通に使えます。
地方銀行がやっていないのは ASP会社のNTTデータが怠慢なだけですね。
> オンラインバンクに限らず、認証ページだけ別のWebサイトというのも
> 有り得る話だと思います。
それで、その場合に、認証ページのサーバ証明書のサブジェクトは銀行名に
なるんでしょうか？ ならないようですが？
Re:むしろ、 (スコア:1)
> 実際IBMのASPはそうしているようですよ。
いいえ、それは一概には言えません。
名前ベースのバーチャルドメインでは、サーバ証明書の運用は技術的な仕様により困難です。
> いえいえ、バーチャルホストなら負荷の問題はありませんし、
> IPベースバーチャルホストなら SSLも普通に使えます。
いや、私が申し上げているのは、もっと広い意味での運営体制です。
Webサーバの運用体制というより、何らかのサービスを提供するWebサイトを維持し運営する体制といった事を想定しており、サービス毎に別々のドメイン名を使う事や、負荷分散のために機能的にサーバ分けたり、或いは機能や価格を考慮して外部のASPサービスを部分的に利用する事など、「ドメイン認証のサーバ証明書を利用する」という目的にもならない目的のためにドメイン名を統一する事より、他に優先される事が多いのではないかという事を言っています。
オンラインバンクだけに限った話をしている訳ではありません。
> それで、その場合に、認証ページのサーバ証明書のサブジェクトは銀行名に
> なるんでしょうか？ ならないようですが？
それはオンラインバンクの実例ではしていないというだけであって、実在認証されたサーバ証明書としてはできるものですよ。
servicename.comの認証ページがcompanyname.comでも良いですよね。
Re: (スコア:0)
> 仕様により困難です。
だから、「IPベースバーチャルホストなら SSLも普通に使えます」と言った
のに、IPベースバーチャルホストを知らないのですか？
> 負荷分散のために機能的にサーバ分けたり、
IPベースバーチャルホストで解決すると言っているんですけど？
> 或いは機能や価格を考慮して外部のASPサービスを部分的に利用する事など
実在証明付きサーバ証明書を必要とするようなサイトが、そんな
安かろう悪かろうのサービスを選択すること自体が間違いですね。
> 他に優先される事が多いのではないかという事
Re:むしろ、 (スコア:1)
> のに、IPベースバーチャルホストを知らないのですか？
知っています。
しかし「*機能や価格*を考慮して外部のASPサービスを部分的に利用する」時に、IPベースの仮想ドメインが必ずしも選択される合理的な根拠など有りませんよね。むしろIPベースの仮想ドメインの方がIPアドレスという資源を占有するための費用が(明示的か暗黙的かに関わらず)必要となるのでは有りませんか? またあくまでも可能性の話ならば、仮にIPベースの実装であっても独自ドメイン名によるサーバ証明書の運用が認められ、商品として提供されているとは限りません。
技術的に問題が無い事は全ての問題が解決した事を意味しません。
何にしても、貴方が仰っているのは「IPベースバーチャルホストなら」という条件下でのみ通用する話であって、私が言っているのはそういう条件に合致しない場合も有りますよね、という話なのです。以前に(別の方に対してかも知れませんが)「/.と貴方との関係に限定した話であり、広く一般に適用できる事例では有りません」という事を言いましたが、そのようにある限定された条件下の話をしているのではないんです。
> 実在証明付きサーバ証明書を必要とするようなサイトが、そんな
> 安かろう悪かろうのサービスを選択すること自体が間違いですね。
それは貴方の主観に過ぎません。
私の印象としては、広く一般向けのサイトであるにも関わらず、自らの身元も明らかにせずドメイン認証の証明書で運用している方が、よほど「安かろう悪かろうのサービス」だとしか思えませんね。仮想ドメインの実装が名前ベースかIPベースかなど、サイトの利用者には確認できない話ですし、直接関係の無い話です。
第一、広く一般向けのサイトに使う事を目的として、ドメイン認証しかされていない証明書を販売している公的認証局は有るんですか? 建前としては、ドメイン認証の証明書は組織内など限られた範囲で使う事を目的としていたと思います。それなら接続先のサイトが「どこの誰か」は予め判っている事ですので、ドメイン認証の証明書でもセキュリティ上の問題は有りません。
# ただ限られた範囲で使うのなら、プライベートCAでも全く問題は有りません。
>> 他に優先される事が多いのではないかという事を言っています。
> そんなものはありませんよ。
もっと社会を勉強しましょう。
> 言っていることがおかしいですよ。ASP利用で他社管理のサーバを使わざるを得ない
> からという話をしているのに、どうして、認証ページのサーバ証明書のサブジェクトが
> 自社のものにできるのですか？
「ASP利用で他社管理のサーバを使わざるを得ないからという話」*のみ*をしているのでは有りません。私はドメイン名を統一できない状況の一例としてそれを挙げていただけであり、サービス提供サイトと認証サイトが同一企業の別ドメインという事も想定しています。
「servicename.comの認証ページがcompanyname.comでも良いですよね」というのは、「サービス毎に別々のドメイン名」を運用している企業を意図していました。
前にも少し触れましたが、もっと基本的なPKIの仕組みから理解するべきだと思います。
TLS/SSLはPKI(公開鍵暗号基盤)の実装です。そうであるにも関わらず「基盤」である事を無視して、TLS/SSLを単なる「暗号化道具」と考えるのは過剰に単純化した見方であり、正しい理解の仕方では有りません。逆に言えば、TLS/SSLが単なる「暗号化道具」なら過剰品質も甚だしい「大袈裟過ぎる」代物としか思えません。
# その程度のものなら苦労しませんよ。(-_-;
Re: (スコア:0)
で、そのときに、（詐欺まがいの商法で売りつけている）サーバ証明書の実在証明で、その会社の会社名が Subject に記載されるのですか？されないでしょ？いったい何が言いたいの？
Re:むしろ、 (スコア:1)
サーバ証明書はそのサイトの運営主体に発行され、そのサイトの運営主体をSubjectに記載します。
「servicename.comの認証ページがcompanyname.comでも良いですよね」
その両方がA社の物で両方ともhttpsで運営するなら、両方のサーバ証明書のSubjectにはA社が記載される事になります。
貴方こそ、私には一体何が言いたいのか判りません。
詐欺まがい商法というのは、貴方の歪んだ主観に過ぎません。
> ハア？主従が逆だよ。PKIのためにTLSがあるんじゃなくて、TLSで達成したいこと（end-to-endの暗号化通信）を実現するためにPKIの仕組みを活用しているだけ。
逆でも何でも有りません。同じ事を言っています。
TLSで達成したい事は狭義の暗号化だけではないという事です。それを貴方が理解されていないだけです。
> TLSは仕様として Subject の CN だけ検証することになっていて、ぶっちゃけ O とか TLSの目的状は無用。
違います。TLS/SSLの検証はもっと複雑です。
拡張領域のSubjectAltnativeNameに記載が有ればそれも検証対象となりますし、証明書の有効期限も考慮されます。また証明書の失効情報を利用する場合は、証明書の失効情報やその失効情報自体の有効期限も考慮されます。それらの情報を発行した認証局についてそれと同様の検証が為され、更に発行された証明書を発行する資格が認証局に有るかどうかを含めて、検証者の信頼ポイントまで遡るように行われます。
Subjectに記載されたその他の情報は、貴方が無用と感じているだけです。
貴方は全ての利用者を代表する者では有りません。
> ベリサインとかあなた方のような実在証明を売りにしている証明書販売業者は、TLSの必要性にかこつけて、それとは独立した無関係の機能を押し売りしているだけ。
別に押し売りなどしていません。
「詐欺まがい」だの「押し売り」だのと仰いますが、まるで事実とは異なります。
要するに他の大勢の人が認める価値を貴方が認めていないだけです。
> あなた、いまだにTLS的な end-to-end の暗号化通信のために、自己署名証明書で十分とか勘違いしているわけ？
私は「TLS的な end-to-end の暗号化通信のために、自己署名証明書で十分」などと言った事は有りません。*ネットワークを介した相手が「どこの誰か」明確である場合ならば*、プライベートCAの発行した証明書でも何らセキュリティ上の問題は無いという事を言っています。認証局がパブリックであろうがプライベートであろうが、実際のデータ通信で選択される暗号の種類とビット長は何ら変わりません。
何が「勘違い」なのか具体的に指摘して下さい。
更に言えば、実在認証を否定しサーバ証明書のコモンネーム以外の情報を否定しているにも関わらず、プライベートCAを否定するのは矛盾しています。
認証局の証明書もエンドエンティティの証明書も、一部の情報が異なるだけで同じ書式の証明書です。WebTrust for CAに準拠した認証局は、全て「実在認証された証明書」で運営されています。実在認証を否定しSubject CNが合致していれば十分であるというのならば、プライベートCAの実在認証されていない認証局証明書でもそれで「十分」です。否定する理由が有りません。
Re:むしろ、 (スコア:1)
公開鍵と共通鍵の使い分け、X.509証明書の書式、検証者が行う証明書の検証手順、PKIにおける信頼できる第三者の役割などは、TLS/SSLの技術論を議論するためには必要な事です。
しかし、どうやら散々文句を言っていた匿名の臆病者は、単にそれらの知識が足りない人のようですね。彼の主張はそれらの技術的裏づけも客観的な事実の裏付けもなく、彼の主張に反論しても無視されますし、彼が主張する「勘違い」についても結局具体的な指摘もできないようです。
散々人をこき下ろしておいて最後がこれとは実に無責任。匿名でも臆病者でも結構ですが、発言した事の責任を果たせないのなら、発言しないで頂きたい。