アカウント名:
パスワード:
CAはその信用を守るためにも、OCSPなりCRLなり使ってRevokeしたほうがいいんじゃないかなー。(もちろん何日以内に対応セヨ、と事前に通知することが必要ですが)
だがまぁ秘密鍵を漏らした恐れのある顧客に対して証明書の再発行を行うくらいのサービスはやっても良いんじゃね？その一環としてまずは失効処理(予定)と再発行案内(ついでに件のバグの大雑把な説明ととりあえずの対策案内)をやるとかさ。
パスワード流出したサービスでパスワードを再発行するってのはまま有る事だし、こういう客を放置してSSL/TLSが信用できない状況を改善するってのはCAって業務を行う企業にとってもそう悪いことでは無いと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
CAの信用 (スコア:0)
CAはその信用を守るためにも、OCSPなりCRLなり使ってRevokeしたほうがいいんじゃないかなー。
(もちろん何日以内に対応セヨ、と事前に通知することが必要ですが)
Re: (スコア:0)
死ぬほどタコな顧客がうっかり誰でもダウンロード出来るところに秘密鍵を置いていないか? とか、
考え出すと、ちゃんと面倒を見るために監査しなきゃならない項目が無限に増えて行く。
Re: (スコア:0)
だがまぁ秘密鍵を漏らした恐れのある顧客に対して証明書の再発行を行うくらいのサービスはやっても良いんじゃね？
その一環としてまずは失効処理(予定)と再発行案内(ついでに件のバグの大雑把な説明ととりあえずの対策案内)をやるとかさ。
パスワード流出したサービスでパスワードを再発行するってのはまま有る事だし、こういう客を放置してSSL/TLSが信用できない状況を改善するってのはCAって業務を行う企業にとってもそう悪いことでは無いと思う。
Re:CAの信用 (スコア:0)
対策をお願いする立場なのか、ある程度強制できる立場なのか。
非営利無償のCAで、「以前に発効した分は失効手続きを行うので、いついつまでに新しい秘密鍵を作って
署名リクエストを\送れ」というのをやってのけたところもありましたが。
その組織がCAをやっている目的が営利ではなく、特定分野のセキュリティ向上なので納得出来る対応でした。
営利の場合でも、証明書を発行する際の契約に「流出が強く疑われる場合は、確認後、猶予時間をおいて失効させます」と決めておけば良いんですね。