数年前、S/MIME証明書を使用してメールに署名(および暗号化)しました。
署名を停止した理由は次のとおりです。2008年1月1日に私の(クラス2)証明書が発行されました(サンプル)。 1年間有効でした。したがって、2009年1月1日に有効期限が切れました。
2008年1月1日と2009年12月31日の間、私は数百通のメールを送りました。すべてうまくいきました。
2009年1月12日(サンプルのみ)に、2008年12月末に送信したメールを(おそらくもう一度読む)読み始めました。多分彼らは新年の休暇中だったのかもしれません。
とにかく、2008年12月にこれらのメールは有効な証明書で署名されました。しかし、2009年1月12日にこれらのメールを読んだとき、同じ証明書がすでに期限切れになっています。
どうした?まあ、受信者は警告を受けました。彼らは私に何が起こっているのか、ハッキングされたのかなどを尋ねてきました:)彼らは私のメールやそのようなものを削除し始めました。
これが再び発生するのを防ぐ方法はありますか(古いメールを読んでいるときに警告が表示されないようにする)
ありがとう!
追伸:これが私の最初の質問です。すべてのルールを遵守してください。簡単な例に沿って問題を説明するのは良い考えだと思いました。とにかく、私に厳しく対処しないでください:)
チャンスを与えましょう:
1年で期限が切れるキーがある場合、その年内にそのキーで署名されて送信されたすべてのデータは永久に有効です(キーが公開されていない限り)、ここでの問題は、データまたはそれを使用するアプリケーションが正しいことですいつ生成されたかについての情報? (日付署名スタンプ)。
もう1つの問題は、古いキーでデータに署名していることです。その場合、データmightは有効ですが、この問題は予測され、新しい証明書がすでに生成されているはずです(たとえば、有効期限が切れる1か月前など)。
少し問題が残っています。データまたはメッセージが復活するとどうなりますか?古い署名を残しておくべきですか?まあ、これはあなたの秘密の管理次第ですが、あなたができることはもう一度それに署名することです。もう1つの問題は、この証明書について通信相手に教育できるかどうかです。これは大変な作業であり、彼らが本当にこのようなことをしていなければ、警告は「すべてがうまくいっていて、問題はない」または「すべてが間違っている、軌道からそれを核に」のように感じるでしょう。
多分(そして私はあなたの説明の後にこれを追加しました)、ここであなたの最良のオプション(この警告のほとんどを本当に避けたいのであれば)は、情報で多かれ少なかれ有効期限が切れる証明書を選択することです、それであなたが1年かかるプロジェクトの場合は、キーを確認することをお勧めします。1か月以内に期限が切れる場合は、この問題に再び直面する可能性があるため、プロジェクトの新しいキーを生成することをお勧めします(これは、別のプロジェクトなど)。
結局のところ、クライアントのソフトウェアがどのように動作するかを知ることは不可能です。クライアントが使用しているソフトウェアさえ知らない可能性があるため、問題を予測することは不可能です。それらを教育し、証明書がいつであるかを常に認識する必要があります。期限切れになるので、事前にクライアントに気付くことができます。