アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
べつに間違ったことじゃない (スコア:1, 興味深い)
高木氏も次の日のエントリー [takagi-hiromitsu.jp]で、銀行のEV-SSLの例を挙げて、NTT DATAになっているのも悪くないと言っていますよ。
Re:べつに間違ったことじゃない (スコア:2, 興味深い)
1つ目は、co.jpドメイン(登録には、簡潔ながら、企業の存在確認、担当者の存在確認、業務内容の審査がある)から、汎用jpドメイン(誰でも自由に登録できる)へリダイレクト。といった、ドメイン(間の主従関係が全く無い)ダウングレード。逆に、必要な説明とともにb-cas.jpからb-cas.co.jp(または、b-cas.co.jpからnttdata.co.jp)へ、リダイレクトされていたならば、話題にすらならない可能性が高い。しかし、今回件の場合、構築、運用担当者のPKIに対する理解力の程度は知れたもので、「NTT DATAが著名企業だから(ユーザが「きっと安全なアウトソース先であろう」と仮定して)信頼してOK」という高木論は、厳密には問題かと。
実際問題として、件のSSL証明書はEV SSLでないだろうし、現場感覚として、EV SSL(対応Webブラウザ)はスタンダードと言えない状況だと思う。
2つ目の、代行申請、取得、運用は問題ないという判断は正しいと思うけど、使用、運用者が所有権を主張する証明書は拙い(これは証明書を発行した認証局のポリシ、もしくは商品である証明書グレードの問題)。
例えば、多くの銀行は、ノンバンクに看板を貸し出して自社ブランドの金融商品を扱っており、どのノンバンクの金融商品かを明らかにしている銀行もあるけれど、多くの場合、エンドユーザの立場としては対銀行として取り引きしており、看板の信頼性はノンバンクではなく、銀行にあるという認識が正しいはずで、実際の契約、契約後のトラブル窓口は、銀行が対応すると期待してサービスを利用するのではないかと思うし、(契約後はアウトソースというパターンが多いものの、)その方が信頼性が高い上、安心感がある。
これは、SMB○に契約に行ったはずが、担当者はSMB○の制服を着たプ■ミスの職員だった(可能性がある)という状況に近く、「担当者(プ■ミス職員)が(SMB○職員を)偽装していた可能性を検証したところ、正規の職員ではない外部委託の可能性が高そうで、渡された契約書もプ■ミスと契約締結するものだったが、その説明が無かった」という程度の検証にしかならないのでは。
要は、この程度の曖昧さを許してしまうと今後のドメイン、PKI運用もアレですなぁ、というか、(信頼性でなく、)知名度がNTT DATA以下のアウトソースを許さないような迂闊な表現を鵜呑みにしていては、先が思いやられる、と、感じた次第。今一度熟考されたし。
Re: (スコア:0)
まぁ、大企業の不正意識なんてそんなもんじゃないですかね。
Re: (スコア:0)