(57)【要約】  本発明の実施形態は、メッセージ受信者又はメッセージングシステムがメッセージの、特にデジタル署名されたコンテンツを含むメッセージの、信頼性を示すことを可能にする。  また、実施形態は、メッセージがユーザにさせようとすることをユーザに行わせないことによってユーザの行動を変えるように、メッセージを変更してよい又は制御してよい。一部の実施形態において、メッセージの様々な特性及び指標が決定される。例えば、デジタル署名されたコンテンツを有するＥメールメッセージについては、特定の実施形態は、信頼の基準を表明する１つ又は２つ以上の主体、送信者の状態又は役割、送信者の名前、送信者の所属、メッセージのアドレス及びロケーション、並びに信頼関係の最新状態を決定してよい。決定された指標に基づいて、平易言語の通知が作成され、該通知とともに、メッセージが表示される。例えば、通知は、メッセージのコンテンツの上方若しくは下方の表示バーに表示されてよい、又はポップアップウィンドウとして現れてよい。また、一部の実施形態において、受信者は、指標の正確さ、信憑性、及び信頼性などの、自身による指標の評価を提供してよい。メッセージに関連した様々な関係者間における対話の履歴も、検討されてよい。例えば、送信者と受信者との間の対話の履歴が、検討されてよい。認証機関又はその他の主体の信頼性も、検討されてよい。
2011501578.tif 000002
【特許請求の範囲】
【請求項１】
受信されたメッセージの信頼性を示す方法であって、
デジタル署名者によってデジタル署名されたコンテンツを含むメッセージを受信することと、
メッセージを受信したソフトウェアにとって既知であるが必ずしも信頼されていない第三者主体による証明一式にアクセスすることと、
メッセージに署名するために使用された暗号化鍵及び該鍵を保持している主体を識別することと、
前記セキュアなバインド及び前記暗号的にセキュアな証明をもとに指標一式を決定することと、
前記指標を前記ユーザに提示することと、
前記指標を変更するように前記ユーザに要求することと、
を備える方法。
【請求項２】
請求項１に記載の方法であって、
デジタル署名者は、メッセージの送信者である、方法。
【請求項３】
請求項１に記載の方法であって、
デジタル署名者は、メッセージの受信者である、方法。
【請求項４】
請求項１に記載の方法であって、
デジタル署名者は、受信者又は送信者の少なくとも一方によって信頼されている第三者である、方法。
【請求項５】
請求項１に記載の方法であって、
メッセージに署名するために使用された暗号化鍵及び該鍵を保持している主体を識別することは、前記コンテンツと、前記メッセージと、前記デジタル署名者との間、及び前記デジタル署名者と、前記信頼されている主体との間の、複数の暗号的にセキュアなバインドを決定することを含む、方法。
【請求項６】
請求項１に記載の方法であって、
前記デジタル署名者は、認証機関である、方法。
【請求項７】
請求項１に記載の方法であって、
前記暗号的にセキュアなバインドは、非対称暗号に基づく、方法。
【請求項８】
請求項１に記載の方法であって、
前記証明は、時刻の証明を示す、方法。
【請求項９】
請求項８に記載の方法であって、
時刻の証明は、暗号的に署名されている、方法。
【請求項１０】
請求項８に記載の方法であって、
時刻の証明は、第三者による証明を有するメッセージの一部である、方法。
【請求項１１】
請求項１０に記載の方法であって、
第三者による証明は、ＯＣＳＰ応答の関係者である、方法。
【請求項１２】
請求項１に記載の方法であって、
前記証明は、デジタル署名者に関する証明を示す、方法。
【請求項１３】
請求項１に記載の方法であって、
信頼されている紹介者が、メッセージの送信者をメッセージの受信者に紹介している、方法。
【請求項１４】
請求項１に記載の方法を実施するように構成された手段を備える装置。
【請求項１５】
請求項１に記載の方法を実施するようにプロセッサを構成する実行可能プログラムコードを備えるコンピュータ可読媒体。
【請求項１６】
受信されたメッセージの信頼性を評価する方法であって、
デジタル署名者によってデジタル署名されたコンテンツを含むメッセージを受信することと、
信頼されている主体による認証一式にアクセスすることと、
メッセージに署名するために使用された暗号化鍵及び該鍵を保持している主体を識別することと、
前記セキュアなバインド及び前記暗号的にセキュアな証明をもとに指標一式を決定することと、
前記指標をもとに役割を決定することと、
前記役割及び受信されたメッセージの受信者に対する前記指標に基づいてメッセージを変更することと、
を備える方法。
【請求項１７】
請求項１６に記載の方法であって、
デジタル署名者は、メッセージの送信者である、方法。
【請求項１８】
請求項１６に記載の方法であって、
デジタル署名者は、メッセージの受信者である、方法。
【請求項１９】
請求項１６に記載の方法であって、
デジタル署名者は、受信者又は送信者の少なくとも一方によって信頼されている第三者である、方法。
【請求項２０】
請求項１６に記載の方法であって、
メッセージに署名するために使用された暗号化鍵及び該鍵を保持している主体を識別することは、前記コンテンツと、前記メッセージと、前記デジタル署名者との間、及び前記デジタル署名者と、前記信頼されている主体との間の、複数の暗号的にセキュアなバインドを決定することを含む、方法。
【請求項２１】
請求項１６に記載の方法であって、
メッセージを変更することは、役割に基づいて、受信者に対するメッセージの表示を保留することを含む、方法。
【請求項２２】
請求項１６に記載の方法であって、
前記変更は、参照を所定のリソース順列に制限する、方法。
【請求項２３】
請求項１６に記載の方法であって、
前記参照は、前記メッセージにインラインロードされるリソースに対する、方法。
【請求項２４】
請求項１６に記載の方法であって、
前記参照は、前記メッセージの外部にロードされるリソースに対する、方法。
【請求項２５】
請求項１６に記載の方法であって、
前記所定のリソース順列は、メッセージに関連付けられた時刻を示す、方法。
【請求項２６】
請求項１６に記載の方法であって、
前記指標は、前記メッセージの出所を示す、方法。
【請求項２７】
請求項１６に記載の方法であって、
前記メッセージは、Ｅメールである、方法。
【請求項２８】
請求項１６に記載の方法を実施するように構成された手段を備える装置。
【請求項２９】
請求項１６に記載の方法を実施するようにプロセッサを構成する実行可能プログラムコードを備えるコンピュータ可読媒体。
【請求項３０】
メッセージの信頼性を示す方法であって、前記メッセージは、デジタル署名されたコンテンツを含み、前記方法は、
メッセージを送信している主体の名前を決定することと、
主体を分類することと、
デジタル署名の有効性を決定することと、
メッセージを送信している主体の名前と、主体が個人であるか又は組織であるかと、デジタル署名の有効性を少なくとも示す平易言語文法テンプレート一式とにしたがって構成される通知を作成することと、
メッセージが表示されるときに通知を含むようにメッセージを構成することと、
を備える方法。
【請求項３１】
請求項３０に記載の方法であって、
主体を分類することは、主体を個人として分類することを含む、方法。
【請求項３２】
請求項３０に記載の方法であって、
主体を分類することは、主体を組織として分類することを含む、方法。
【請求項３３】
請求項３０に記載の方法であって、
メッセージはＥメールである、方法。
【請求項３４】
請求項３０に記載の方法であって、更に、
メッセージを送信している主体のアドレスを決定することと、
メッセージを送信している主体のアドレスを示すように通知を作成することと、
を備える方法。
【請求項３５】
請求項３０に記載の方法であって、更に、
デジタル署名に関する第三者による証明を決定することと、
第三者による証明を示すように通知を作成することと、
を備える方法。
【請求項３６】
請求項３０に記載の方法であって、更に、
メッセージが存在した時刻を決定することと、
メッセージがいつ存在したかを示すように通知を作成することと、
を備える方法。
【請求項３７】
請求項３０に記載の方法であって、更に、
メッセージが受信されたときの時刻及びメッセージに基づいて情報を決定することと、
メッセージがいつ受信されたかを示すように通知を作成することと、
を備える方法。
【請求項３８】
請求項３７に記載の方法であって、
メッセージが受信されたときの時刻及びメッセージに基づいて情報を決定することは、メッセージのハッシュを決定することを含む、方法。
【請求項３９】
請求項３０に記載の方法であって、更に、
メッセージを送信している主体の物理的ロケーションを決定することを備える方法。
【請求項４０】
請求項３０に記載の方法であって、
デジタル署名の有効性を決定することは、デジタル署名のために使用されるデジタル証明書を発行した認証機関を決定することを含む、方法。
【請求項４１】
請求項４０に記載の方法であって、更に、
認証機関がデジタル証明書を破棄したかどうかを決定することを備える方法。
【請求項４２】
請求項３０に記載の方法であって、
デジタル署名の有効性を決定することは、デジタル署名が自己署名デジタル証明書に基づくかどうかを決定することを含む、方法。
【請求項４３】
請求項１６に記載の方法であって、
メッセージを構成することは、更に、受信者によって選択されたときに受信者によるメッセージの信頼性の評価を示すユーザインターフェース要素一式を含むようにメッセージを構成することを含む、方法。
【請求項４４】
請求項３０に記載の方法であって、更に、
受信者とメッセージを送信している主体との間のこれまでの対話の履歴を決定することと、
受信者とメッセージを送信している主体との間の履歴に基づいて通知を作成することと、
を備える方法。
【請求項４５】
請求項３０に記載の方法であって、更に、
デジタル署名のために使用されるデジタル証明書を発行した認証機関を識別することと、
受信者と認証機関との間のこれまでの対話の履歴を決定することと、
受信者と認証機関との間の履歴に基づいて通知を作成することと、
を備える方法。
【請求項４６】
請求項３０に記載の方法であって、更に、
受信者に信頼されている関係者によってこれまでに受信された少なくとも１つのその他のメッセージにメッセージが関連しているかどうかを決定することと、
受信者によって受信された少なくとも１つのその他のメッセージにメッセージが関連しているかどうかに基づいて通知を作成することと、
を備える方法。
【請求項４７】
請求項１６に記載の方法であって、更に、
受信者によってこれまでに送信された少なくとも１つのその他のメッセージにメッセージが関連しているかどうかを決定することと、
受信者によって送信された少なくとも１つのその他のメッセージにメッセージが関連しているかどうかに基づいて通知を作成することと、
を備える方法。
【請求項４８】
請求項１６に記載の方法であって、更に、
受信者に信頼されている関係者によってこれまでに送信された少なくとも１つのその他のメッセージにメッセージが関連しているかどうかを決定することと、
受信者によって信頼されている関係者によって送信された少なくとも１つのその他のメッセージにメッセージが関連しているかどうかに基づいて通知を作成することと、
を備える方法。
【請求項４９】
請求項３０に記載の方法を実施するように構成された手段を備える装置。
【請求項５０】
請求項３０に記載の方法を実施するようにプロセッサを構成する実行可能プログラムコードを備えるコンピュータ可読媒体。
【請求項５１】
デジタル証明書を発行する方法であって、
メッセージの署名者の名前に関する情報を決定することと、
署名者の役割を決定することであって、該役割は、デジタル証明書に関連付けられた鍵によって署名者が署名する可能性が高いメッセージのタイプを示す、ことと、
署名者の名前及び署名者の役割に基づいてデジタル証明書を発行することと、
を備える方法。
【請求項５２】
請求項５１に記載の方法であって、
デジタル証明書を発行することは、メッセージの送信者及び証明者を示すメッセージに関する指標を計算するようにプロセッサを構成することができるフィールドを有するデジタル証明書を発行することであって、指標は、メッセージが表示されるときに提示される、ことを含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
＜関連出願＞
本出願は、２００７年１０月２０日に出願され「Ｂｏｏｔｓｔｒａｐｐｅｄ  Ｔｒｕｓｔ  Ｒｅｌａｔｉｏｎｓｈｉｐ（ブートストラップされた信頼関係）」と題されたＳｅａｎ  Ｊ．  Ｌｅｏｎａｒｄによる米国仮特許出願第６０／９８１，４７９号の優先権を主張するものであり、該出願は、参照によって全体を本明細書に組み込まれる。
【０００２】
＜技術分野＞
本発明は、電子通信メッセージングシステムに関する。本発明は、とりわけ、暗号化認証メッセージングシステムなどのセキュアメッセージングシステムと、セキュアメッセージの信頼性を決定するため及び示すための手順及びシステムとに関する。
【背景技術】
【０００３】
今日、インターネットやモバイルネットワークなどのネットワークは、Ｅメール、テキストメッセージ、インスタントメッセージなどの通信及びメッセージングに対する広範なアクセスを可能にする。しかしながら、驚くことに、この通信及びメッセージングのトラフィックの大半は、セキュアでない、すなわち保護されていない。例えば、Ｅメールメッセージの圧倒的多数は、暗号化及び署名を経ずに送信されるので、このようなＥメールは、インターネットを通じた通信セッションにおいて、移動又は保存の際に任意の傍受者によって読まれたり変更されたりする可能性がある。
【０００４】
暗号化され署名された（例えば認証された）メッセージの送信及び受信は、当該分野において周知の機能である。代表的なシステムにおいて、ユーザは、認証又は認証機関（ＣＡ）から無料又は有料で証明書を取得してよい。ＣＡは、ユーザのＩＤ及びＥメールアドレスを検証する。ユーザは、次いで、ＣＡのウェブサイトに進み、そのウェブサイト上においてフォームに記入するなどの一連の作業を完了することができる。これは、通常は、Ｅメールアドレスを含む個人データをユーザに入力させる。すると、そのユーザ用に、１対の公開鍵と秘密鍵とが生成される。ユーザは、ウェブサイトにデータをサブミットする際に、上記の残りの情報とともに自身の公開鍵を含む証明書要求をサブミットする。秘密鍵は、ユーザのコンピュータに保存される。ＣＡのウェブサイトは、次いで、例えばＥメールを通じてユーザに確認を送信することによって、ユーザのＩＤを検証する。確認にはリンクが含まれ、ユーザが手動でそのリンクをたどると、ＣＡのウェブサイトは、発行証明書をユーザのウェブブラウザにインストールさせ、関連の秘密鍵と統合させる。
【０００５】
あいにく、これらのセキュリティメカニズムの使用は、広く普及していない。例えば、定評あるＣＡ及び公開鍵インフラ（ＰＫＩ）が存在するにもかかわらず、Ｓ／ＭＩＭＥ及びＰＧＰなどの技術の使用は、あまり広く普及していない。支持されていない理由の１つは、たとえＥメールにデジタル署名及び暗号化コンテンツが使用されたとしても、ユーザが、誰が自分に接触しているか及び誰に自分が接触しているかを、確信を持って知ることが困難なことにある。
【０００６】
多くのメッセージングシステムに伴う問題は、メッセージが、そのメッセージが誰からであるかに関する情報を（例えば「Ｆｒｏｍ」行に）含んでいることにある。しかしながら、代表的なＥメールシステムは、このようなメッセージが本当にＦｒｏｍ行に挙げられた送信者から来たものであるかを検証する独立した方法を持たない。
【０００７】
また、大半のユーザは、コンピュータ又はメッセージングサービスがどのように機能し
ているかを理解していない。むしろ、ユーザは、通常は、自分のソフトウェア及びシステムが大半の状況において理に叶った初期設定を有しているとして依存している。ユーザは、このような設定が自分のコンピュータ環境に著しく影響するときにのみ、それらを変えようとする。例えば、上記のように、ＰＫＩは、当該分野において知られている。しかしながら、大概のユーザは、ＰＫＩがどのように機能するかを理解することなく、尚且つＰＫＩが効果的に又は任意の特定の形で機能することをはっきりと信頼することなく、ＰＫＩに依存している。
【０００８】
別の既知の技術は、暗号化ゲートウェイサーバであり、これは、組織内のユーザから平文メッセージを受信すること、複合的なポリシー一式に照らしてメッセージを検査すること、及びふさわしいと見なされたら先方への引き渡し前にメッセージを署名又は暗号化することを、全て、エンドユーザによって詳細を見られることなく実施する。更に別の既知の技術は、ＣＡ又はその他の第三者によってではなく継続的関係における連続使用を通じて認証された自作の自己署名証明書を用いるものである。
【０００９】
しかしながら、既知の技術は、依然として、使用及び理解が困難である。したがって、ほとんどの場合、大概のユーザは、単純にこれらの既知の技術を回避する、又はこれらの技術を誤った方法で用いる。
【発明の概要】
【００１０】
一実施形態において、受信されたメッセージの信頼性を示す方法は、デジタル署名者によってデジタル署名されたコンテンツを含むメッセージを受信することと、メッセージを受信したソフトウェアにとって「既知であるが必ずしも信頼されていない」第三者主体による証明一式にアクセスすることと、メッセージに署名するために使用された暗号化鍵及びその鍵を保持している主体を識別することと、上記セキュアなバインド及び上記暗号的にセキュアな証明をもとに指標（ｉｎｄｉｃｉｕｍ）一式を決定することと、上記指標を上記ユーザに提示することと、上記指標を変更するように上記ユーザに要求することと、を含む。
【００１１】
別の実施形態において、受信されたメッセージの信頼性を評価する方法は、デジタル署名者によってデジタル署名されたコンテンツを含むメッセージを受信することと、信頼されている主体による証明一式にアクセスすることと、メッセージに署名するために使用された暗号化鍵及びその鍵を保持している主体を識別することと、上記セキュアなバインド及び上記暗号的にセキュアな証明をもとに指標一式を決定することと、上記指標をもとに役割を決定することと、上記役割及び受信されたメッセージの受信者に対する上記指標に基づいてメッセージを変更することと、を含む。
【００１２】
別の実施形態において、メッセージの信頼性を示す方法であって、上記メッセージが、デジタル署名されたコンテンツを含む、方法は、メッセージを送信している主体の名前を決定することと、主体を分類することと、デジタル署名の有効性を決定することと、メッセージを送信している主体の名前、主体が個人であるか又は組織であるか、及びデジタル署名の有効性を少なくとも示す平易言語文法テンプレート一式にしたがって構成される通知を作成することと、メッセージが表示されるときに通知を含むようにメッセージを構成することと、を含む。
【００１３】
別の実施形態において、デジタル証明書を発行する方法は、メッセージの署名者の名前に関する情報を決定することと、署名者の役割を決定することであって、役割は、デジタル証明書に関連付けられた鍵によって署名者が署名する可能性が高いメッセージのタイプを示す、ことと、署名者の名前及び署名者の役割に基づいてデジタル証明書を発行することと、を含む。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に適合した代表的なシステムを示している。
【図２Ａ】図２Ａ〜Ｂは、同様のタイプの情報を異なるフォーマットで伴う２つの異なるプロバイダからの証明書を示している。
【図２Ｂ】図２Ａ〜Ｂは、同様のタイプの情報を異なるフォーマットで伴う２つの異なるプロバイダからの証明書を示している。
【図３】本明細書において説明されるシステムの代表的な実施形態についてのアルゴリズム及びデータフローを示している。
【図４】計算された指標を伴うメッセージ表示の例を示している。
【図５Ａ】実施形態によって決定されるであろう代表的な指標を示している。
【図５Ｂ】実施形態によって決定されるであろう代表的な指標を示している。
【図５Ｃ】実施形態によって決定されるであろう代表的な指標を示している。
【図５Ｄ】実施形態によって決定されるであろう代表的な指標を示している。
【図５Ｅ】実施形態によって決定されるであろう代表的な指標を示している。
【図５Ｆ】実施形態によって決定されるであろう代表的な指標を示している。
【図６Ａ】セキュリティレベル及び信頼レベルに注意を払うようにユーザを仕向けようとする、段階的に更新される指標の代表的な表示である。
【図６Ｂ】セキュリティレベル及び信頼レベルに注意を払うようにユーザを仕向けようとする、段階的に更新される指標の代表的な表示である。
【図７Ａ】ＥメールメッセージのＦｒｏｍ行に集約される代表的な指標を示している。
【図７Ｂ】ＥメールメッセージのＦｒｏｍ行に集約される代表的な指標を示している。
【図７Ｃ】ＥメールメッセージのＦｒｏｍ行に集約される代表的な指標を示している。
【図８】図６Ａ〜Ｂに示された動画的表示の代表的なフローチャートである。
【図９Ａ】信頼されていない自己署名の証明書及び認証機関についての代表的な指標を示している。
【図９Ｂ】信頼されていない自己署名の証明書及び認証機関についての代表的な指標を示している。
【図１０Ａ】ユーザが信頼関係を発展させようと試みるときに提示される代表的な指標、ユーザ動作の例、システム応答、及びユーザインターフェースを示している。
【図１０Ｂ】ユーザが信頼関係を発展させようと試みるときに提示される代表的な指標、ユーザ動作の例、システム応答、及びユーザインターフェースを示している。
【図１０Ｃ】ユーザが信頼関係を発展させようと試みるときに提示される代表的な指標、ユーザ動作の例、システム応答、及びユーザインターフェースを示している。
【図１１】ユーザから又は別の証明主体から表明された信頼の変化を伝える代表的な指標を示している。
【図１２】一部の実施形態による指標衝突の解消を示している。
【図１３】一部の実施形態によって指標衝突を解消する別の例を示している。
【図１４】一部の実施形態によって指標衝突を解消する別の例を示している。
【図１５Ａ】図１５Ａ〜Ｃは、署名されたメッセージが続いた後に未署名のメッセージが現れるときなどの様々な署名パターンにおけるメッセージの信頼性の解消を示している。
【図１５Ｂ】図１５Ａ〜Ｃは、署名されたメッセージが続いた後に未署名のメッセージが現れるときなどの様々な署名パターンにおけるメッセージの信頼性の解消を示している。
【図１５Ｃ】図１５Ａ〜Ｃは、署名されたメッセージが続いた後に未署名のメッセージが現れるときなどの様々な署名パターンにおけるメッセージの信頼性の解消を示している。
【図１５Ｄ】送信者の指標の解消が成功したにもかかわらず指標の衝突を示すために表示される代表的なユーザプロンプトを示している。
【図１６Ａ】メッセージの信頼性を示す代表的な一覧を示している。
【図１６Ｂ】メッセージの信頼性を示す代表的な一覧を示している。
【図１７Ａ−１】既知のシステムのユーザインターフェースを示している。
【図１７Ａ−２】既知のシステムのユーザインターフェースを示している。
【図１７Ｂ】既知のシステムのユーザインターフェースを示している。
【図１８】代表的なデジタル証明書を、送信者の役割に関連した情報とともに示している。
【図１９】図１８に示されたデジタル証明書に基づく代表的な指標を示している。
【図２０】「スパム報告」ボタンを伴う従来のウェブメールインターフェースを示している。
【図２１】ユーザが役割ベースのマーケティング信頼関係の低下を表明しようと試みるときの、指標、ユーザ動作、システム応答、及びユーザインターフェースを示している。
【図２２Ａ】役割ベースのポリシーにしたがった、とりわけ画像及びリンクに関する代表的な指標を示している。
【図２２Ｂ】役割ベースのポリシーにしたがった、とりわけ画像及びリンクに関する代表的な指標を示している。
【発明を実施するための形態】
【００１５】
本発明は、暗号化認証メッセージングシステムに関し、特に、ユーザと、メッセージングサービスと、メッセージ送信者との間の信頼関係をブートストラップ（自ら構築）する及び追跡するシステム及び方法に関する。とりわけ、本発明の実施形態は、対話の妨害を最小限に抑えた容易な方法でユーザがデジタル証明書及びその他の暗号技術を使用してセキュア通信に携わることを可能にする。したがって、実施形態は、メッセージの信頼性を決定する及び示すのに有用であろう。通例、信頼性は、メッセージの送信者を識別することを目的として、メッセージが有すると見られる信憑性、機密性、又は正確さに関連するものであってよい。すなわち、メッセージの信頼性は、署名者が秘密鍵の所有者であること及び実際にメッセージを送信した主体であることの証拠として署名の信憑性が足るかどうかに関連していてよい。
【００１６】
代表的な実施形態において、システムは、ユーザが依存することができる信頼の、予め準備された知識ベースを含む。システムは、更に、ユーザが自分のコンピュータデバイスと、メッセージングサービス及び該メッセージングサービスによって提示されるインターフェースと、既知及び未知の送信者とに対して有することができる様々なレベルの信頼を承認する。ユーザがシステムを使用するにつれて、システムは、観察されるイベントと、対話と、明確なユーザ承認との組み合わせを通じてユーザの信頼プロフィールを発展させる及び維持することができる。
【００１７】
通例は、様々な関係者が、メッセージの信頼性又は信憑性に関連する証明者の働きをしてよく、ユーザは、これらの関係者との間に様々な信頼関係を有してよい。例えば、信頼のある紹介者、認証機関、及び様々なタイプの送信者が、何らかの形の証明者であってよい。
【００１８】
例示を目的として、本発明の実施形態は、Ｅメールメッセージのセキュア化に関係して説明される。もちろん、Ｅメールは、例として提供されたものであり、ウェブメール、テキストメッセージ、ＳＭＳ、インスタントメッセージなどのその他の形態のメッセージングも、本開示の範囲内である。当業者ならば、本発明の実施形態が、テキストメッセージ
、インスタントメッセージ、電話の伝言又は通話、口頭で伝えられるメッセージ、その他の形態の視覚ユーザインターフェース若しくは音声ユーザインターフェース若しくはその他の感覚ユーザインターフェースなどの、任意の形のメッセージングに実装できることがわかる。
【００１９】
一部の実施形態において、Ｅメールメッセージに関する指標は、個々のＥメールが表示されるとき又はＥメールメッセージの一覧が表示されるときに示されてよい。とりわけ、本発明の実施形態は、デジタル署名されたＥメール又はその他のタイプのメッセージを個別に又は一覧に表示する革新的な方式に関するものであってよい。不要なメッセージは、アイコン、色、アイコンに線を引く、メッセージをフェードアウトさせるなどの、様々な標識で示すことができる。一覧では、表示スペースが限られることがあるので、アイコンは、現行状態におけるＥメールメッセージの信頼関係及び指標を反映するとともにその信頼関係が時間とともにどのように発展してきたかを反映するために、様々な形に変更することができる。不要なメッセージは、一覧に現れないように除外することもできる。したがって、デジタル署名を伴う把握された関係に基づいて、実施形態は、メッセージ及びそれらの一覧の表示及び提示を変更することができる。
【００２０】
代表的な実施形態において、システムは、デジタル署名者による表明に基づいてユーザが自身の信頼レベルに気付くことができるようにする方法を提供する。一部の実施形態において、システムは、特定の証明書又は認証機関（ＣＡ）を、そして拡大解釈により、信憑できることがわかっている特定のデジタル証明書を承認することによって、ＰＫＩシステムをベースにして構築される。ＣＡは、実質的に、ユーザ自身であるすなわちユーザが自分のＣＡとして機能するか、既知又は既存のＣＡでるか、メッセージの送信者であるか、又はその他の何らかの第三者であるかしてよい。システムは、対応する秘密鍵の所有者によってデジタル証明書に提供される特定のタイプの情報において特定の信頼レベルを確立するにあたり、ユーザのコンピュータ上においてＣＡを、システム自体のリストを、又はそれらを様々に組み合わせて考慮してよい。これらの情報は、ＣＡ又はその他のユーザが確実に請け合うことができる情報である。
【００２１】
上記では、セキュリティ技術としてＰＫＩが挙げられているが、実施形態は、任意の形態のセキュリティメカニズムを用いてよい。例えば、実施形態は、ＤＮＳ  ｓｅｃｕｒｉｔｙ  ｅｘｔｅｎｓｉｏｎ（ＤＮＳＳＥ）、ＤｏｍａｉｎＫｅｙｓ及びＤｏｍａｉｎＫｅｙｓ  Ｉｄｅｎｔｉｆｉｅｄ  Ｍａｉｌ（ＤＫＩＭ）、Ｐｒｅｔｔｙ  Ｇｏｏｄ  Ｐｒｉｖａｃｙ（ＰＧＰ）、及びＷｅｂ  ｏｆ  Ｔｒｕｓｔなど、ドメインネームシステム（ＤＮＳ）の様々なセキュリティ特徴を用いてよい。
【００２２】
しかしながら、ＣＡは、上記情報のロケーション及びフォーマットを司る基準にもかかわらず、比較的自由な形式で情報の記録及び提示を行う。例えば、図２Ａ〜Ｂに示されるように、同じ技術的フィールド及びエントリを伴う証明書が、異なるレベルの検証及び信頼に対応している可能性がある。
【００２３】
この状況に対処するために、一部の実施形態の特徴は、このような関係を把握する及び可視化することにある。このような関係及び証明の把握は、例えばＣＡの証明書ポリシー規定、発行証明書の例、及び悪意のある申請者が虚偽の記録をする余地を残すことでＣＡが負うリスクなどの、ＣＡの実際の行為を分析することによって決定されてよい。これらの関係及び証明が把握された後、システム設計者は、これらの把握内容をユーザのストレージメカニズム内（例えば関係データベース内又は符号化論理シーケンス内）に公開する。
【００２４】
実施形態は、これらの把握内容から収集された情報を、とりわけ送信者のＩＤをユーザ
が検証することを助ける形でユーザに対して提示する。これらの実施形態では、システムは、システムが何を信頼できるものとして信じているか、システムがどのように特定の提案に達したか、及びユーザがどのようにシステムの仮定に挑めるかを示してよい。一実施形態において、システムは、暗喩、象徴、又は専門用語の利用を回避した平易言語の文を使用することによって、通常のユーザが理解できる形でこのような指標を提供する。
【００２５】
指標は、例えばテキスト、画像、及び音声などの、情報を伝える任意のタイプの指示を言う。一実施形態において、表示される指標は、送信者のアドレス（Ｅメールアドレスなど）及び送信者名の一部を含んでよい。指標は、更に、同一の又は同様の指標を伴うその他の既知の送信者からの名前を示してよい。指標は、また、企業体、個人、自動処理などの、異なるタイプの送信者同士を区別してもよい。例えば、大半の個人が、苗字と名前とを有する一方で、企業は、単独の企業名を有する。企業は、法人所在地又は主な事業場所などの、その他の際立った特徴を有してよい。
【００２６】
実施形態において、システムは、複数の証明者からの指標を提示する及び組み合わせることができる。例えば、署名メッセージは、タイムスタンピング機関（ＴＳＡ）によって副署名されてよく、該機関による副署名は、メッセージ及び署名が遅くとも署名日には存在していたことの証拠を提供する。別の例として、ＣＡは、秘密鍵の侵害が報告された場合に特定の下位証明書の信頼性について警告するために、証明書破棄リスト及びオンライン証明書状態プロトコル（ＯＣＳＰ）サーバなどの更新サービスを提供してよい。
【００２７】
本開示の実施形態は、メッセージの送信者を識別する目的で、送信者がメッセージを作成する及び署名する時刻が送信者の署名が信頼できるか又は信憑できるかどうかの問題に関係することを認識するように構成される。メッセージの信頼性は、署名者が秘密鍵の所有者であること及び実際にメッセージを送信した主体であることの証拠として署名の信憑性が足るかどうかに関連している。例えば、信頼できるはずの送信者が、対応する自身の秘密鍵を時刻ｔにおいて失うことがある。時刻ｔの後は、信頼できる署名がなくなる。しかも、攻撃者（信頼できない送信者）が日付の証拠を捏造し、メッセージをあたかも時刻ｔより前に署名されたかのように見せかける可能性がある。したがって、一部の実施形態においては、特定のメッセージの信頼性を証明するために、メッセージが時刻ｔより前に作成されたことの独立した証拠を提供することができる。一部の実施形態においては、タイムスタンピングを目的として、メッセージに、実際のメッセージのコンテンツ、１つ若しくは２つ以上のデジタル署名（又は匹敵する暗号ハッシュ値などの、デジタル署名の再現）、及び実にその他のあらゆる情報を含ませることによって、実際のメッセージのコンテンツ、その主張される署名者、及びその他のあらゆる情報を、時刻ｔに存在していたものとして証明できることがわかる。
【００２８】
実施形態は、１つ又は２つ以上のタイプの証拠に依存してよい。送信者は、第三者ＴＳＡから暗号タイムスタンプを調達することができる。受信者の受信メールサーバは、メッセージのＲｅｃｅｉｖｅｄ行に受信の日付を刻印してよい。受信サーバは、自身がＴＳＡとして機能して、暗号タイムスタンプを生成することができる。受信サーバは、自身がＴＳＡとして機能して、高セキュリティコプロセッサから暗号タイムスタンプを調達することができる。受信サーバは、第三者ＴＳＡから暗号タイムスタンプを調達することができる。受信者は、ユーザの秘密鍵によってメッセージに注釈を付ける又は副署名することができ、このとき、注釈又は副署名は、メッセージが別途信頼できるとして知られている間の、ユーザにしたがったタイムスタンプを含む。注釈又は副署名は、元のメッセージを引用する自分宛の応答メッセージの使用によって、又はクライアントにカスタムデータをメッセージに追加させるためにサーバがクライアントに提示するフラグ若しくはラベルなどのメカニズムの使用によって、添付されてよい。
【００２９】
デジタル署名に代わり、受信者としてのユーザは、信頼性又は送信者の信頼性などの、メッセージに関するその他の側面に関して証明するために、メッセージ自体に注釈を付けることもできる。
【００３０】
その他の実施形態において、システム１００は、メッセージの信頼性又は信憑性を評価するために、間接的に得られた情報を用いてよい。例えば、システム１００は、オンライン証明書状態プロトコル（ＯＣＳＰ）メッセージ内の情報を解析してよい。このようなメッセージは、デジタル証明書の現行状態及びそれが破棄されたかどうかを示すために使用することができる。システム１００は、メッセージが信頼できるか又は信憑できるかどうかを評価するために、１つ又は２つ以上のタイムスタンプなどの、ＯＣＳＰメッセージ内の様々な情報を使用してよい。また、システム１００は、決定を下すために、メッセージのハッシュ、又はＯＣＳＰメッセージからなどの、タイムスタンプを含むメッセージのハッシュを用いてよい。
【００３１】
一実施形態において、システムは、発行する応答に対して中立で、独立で、不偏なタイムソースとして機能するとともに要求者指定のデータをその応答に含ませることを可能にする任意のデジタル署名者からの応答に依存する。送信者側からの対応するシステムは、このような応答を中立の第三者から要求すると考えられる。中立の第三者は、たとえタイムスタンプ機関（ＴＳＡ）であることを主張も約束もしていなくても、署名者が正確な時刻を生成する義務を負う限り、依存されてよい。
【００３２】
一実施形態において、時刻の確かな証拠を調達するためのシステムは、オンライン証明書状態プロトコル（ＯＣＳＰ）要求をサブミットする。要求は、ハッシュアルゴリズム、発行者名ハッシュ、発行者鍵ハッシュ、及び真偽の疑わしい証明書のシリアル番号をそれぞれに含む証明書ＩＤ構造を伴う要求ＳＥＱＵＥＮＣＥなどの特定の情報を含む。随意には、要求拡張（エクステンション）の１つとして、要求のノンス（乱数）が含まれる。ＯＣＳＰサーバ（ＯＣＳＰ応答者）は、署名された応答を返す。署名された応答は、ＯＣＳＰ応答者自身に関する情報、応答が作成された時刻、要求者によって提供された証明書ＩＤ、及び随意には要求のノンスを含むことができる。このような要求及び応答のサイクルが、以下に例示される。
【００３３】
ＯＣＳＰ要求及びＯＣＳＰ応答のサイクルの例
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1 <-メッセージのハッシュアルゴリズムであってよい
Issuer Name Hash: DEADBEEFE271B9518326761CF21D4E33576A8370 <-メッセージのハッシュであってよい
Issuer Key Hash: DEADBEEF4C8813F078D98977B56DC589DFBCB17A <-メッセージのハッシュであってよい
Serial Number: DEADBEEF74202438B197F1C9DE2E3610   <-メッセージのハッシュであってよい
Request Extensions:
OCSP Nonce:
DEADBEEFB3A991077B364693A4D6AAF01576  <-メッセージのハッシュであってよく、実のところ、メッセージ自体であってよい
<-ここにはその他のデータがきてよい
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = XX, ST = XXX, L = XXXX, O = Cert., CN = Class 1 OCSP, emailAddress = support@cert.org
Produced At: Oct 20 20:10:00 2008 GMT  <-この時刻に記録が存在することの極めて確証的な証拠
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: DEADBEEFE271B9518326761CF21D4E33576A8370
Issuer Key Hash: DEADBEEF4C8813F078D98977B56DC589DFBCB17A
Serial Number: DEADBEEF74202438B197F1C9DE2E3610
Cert Status: unknown  <-証明書ＩＤが本物の証明書に対応しない（したがってメッセージに対応する）ことの確証的な証拠
This Update: Oct 20 20:10:00 2008 GMT  <-この時刻後に記録が存在することの確証的な証拠
Next Update: Oct 20 20:20:00 2008 GMT  <-この時刻前に記録が存在することの確証的な証拠
Response Extensions:
OCSP Nonce:
DEADBEEFB3A991077B364693A4D6AAF01576
Certificate:
Data:
Version:
Serial Number: 00000 (00000)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support@cacert.org
Validity
Not Before: Aug 22 07:13:00 2006 GMT
Not After : Aug 22 07:13:00 2011 GMT
Subject: C=XX, ST=XXX, L=XXX, O=Cert., CN=Class 1 OCSP
emailAddress= support@certificationauthority.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e1:8d:ff:c8:17:9e:de:e6:91:fd:91:80:1c:0a ...:
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication, OCSP Signing <-これが定期的に業務記録を生成するこのタイプのサーバであるという事実の確証
X509v3 Subject Alternative Name:
email: support@certificationauthority.org
【００３４】
複合ＯＣＳＰ要求／応答サイクルの例
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID: <-有効な証明書の例
Hash Algorithm: sha1
Issuer Name Hash: 0000621693A6DA5AD0B98D3A135E35D1EB183661
Issuer Key Hash: 000071604C8813F078D98977B56DC589DFBCB17A
Serial Number: 123A
Certificate ID: <-不良（破棄された）証明書の例
Hash Algorithm: sha1
Issuer Name Hash: 0000621693A6DA5AD0B98D3A135E35D1EB183661
Issuer Key Hash: 000071604C8813F078D98977B56DC589DFBCB17A
Serial Number: 123B
Certificate ID: <-実際にメッセージハッシュを含む偽の証明書ＩＤ
Hash Algorithm: 
Issuer Name Hash: CAFEBABEE271B9518326761CF21D4E33576A8370
Issuer Key Hash: CAFEBABE4C8813F078D98977B56DC589DFBCB17A
Serial Number: CAFEBABE74202438B197F1C9DE2E3610 <-この「偽」シリアル番号（実際はメッセージハッシュ）を上記のシリアル番号と比較する；それは、このＣＡのフォーマットと同じフォーマットではない
Request Extensions:
OCSP Nonce:
CAFEBABEF9BF1550C638C0CF47F561C27CFF
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = XX, ST = XXX, L = XXX, O = Cert., CN = Class 1 OCSP, emailAddress = support@certificationauthority.org
Produced At: Oct 20 23:09:00 2008 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 0000621693A6DA5AD0B98D3A135E35D1EB183661
Issuer Key Hash: 000071604C8813F078D98977B56DC589DFBCB17A
Serial Number: 321A
Cert Status: good  <-証明書ＩＤが、このＣＡに知られ且つ恐らくはこのＣＡによって発行された本物の証明書に対応する（したがってメッセージに対応しない）ことの確証的な証拠
This Update: Oct 20 20:43:00 2008 GMT
Next Update: Oct 20 23:19:00 2008 GMT
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 0000621693A6DA5AD0B98D3A135E35D1EB183661
Issuer Key Hash: 000071604C8813F078D98977B56DC589DFBCB17A
Serial Number: 321B
Cert Status: revoked  <-証明書ＩＤが、このＣＡに知られ且つ恐らくはこのＣＡによって発行された本物の証明書に対応する（したがってメッセージに対応しない）ことの
確証的な証拠
Revocation Time: Oct 03 16:53:00 2008 GMT
This Update: Oct 20 20:43:00 2008 GMT
Next Update: Oct 20 23:19:00 2008 GMT
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: CAFEBABEE271B9518326761CF21D4E33576A8370
Issuer Key Hash: CAFEBABE4C8813F078D98977B56DC589DFBCB17A
Serial Number: CAFEBABE74202438B197F1C9DE2E3610
Cert Status: unknown  <-証明書ＩＤが本物の証明書に対応しない（したがってメッセージに対応する）ことの確証的な証拠
This Update: Oct 20 23:09:00 2008 GMT 
Next Update: Oct 20 23:19:00 2008 GMT 
Response Extensions:
OCSP Nonce:
CAFEBABEF9BF1550C638C0CF47F561C27CFF <-考えられるメッセージハッシュのロケーション
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 00000 (00000)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Root CA, OU=XX, CN=XX Cert Signing Authority/emailAddress=support@certificationauthority.org
Validity
Not Before: Aug 22 07:13:00 2006 GMT
Not After : Aug 22 07:13:00 2011 GMT
Subject: C=XX, ST=XXX, L=XXX, O=Cert., CN=Class 1 OCSP/emailAddress= support@certificationauthority.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
.:
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication, OCSP Signing
X509v3 Subject Alternative Name:
email:support@certificationauthority.org
Signature Algorithm: sha1WithRSAEncryption
【００３５】
要求を生成するシステムは、ＯＣＳＰ要求を作成するが、ユーザ供給された要求情報を、メッセージハッシュに、又はそれ以外の形でメッセージを明確に識別する構造に置き換
える。これは、カプセル化ＭＩＭＥメッセージのメッセージダイジェスト（又はハッシュ）を内包するＳ／ＭＩＭＥ及びＰＫＣＳ＃７／ＣＭＳに使用されるＳｉｇｎｅｒＩｎｆｏブロックのハッシュ、又はひいてはＳｉｇｎｅｒＩｎｆｏブロックの全体若しくはメッセージ自体の全体などの、メッセージ用のその他の置き換えを含んでよい。例えば、発行者名ハッシュ、発行者鍵ハッシュ、シリアル番号、又はノンスが、ハッシュに置き換えられてよい。発行者名ハッシュ及び発行者鍵ハッシュは、通常は、有効とされる特定の証明書ＩＤ構造内におけるハッシュアルゴリズム選択に制約されるが、要求者は、自分がそこに記録するアルゴリズムによって識別されるハッシュを使用して、メッセージを表す適切なハッシュを生成することを選択してよい。証明書シリアル番号は、通常は、ハッシュ値（及び場合によってはアルゴリズム選択）を数値に符号化するのに十分なＡＳＮ．１タイプのＩＮＴＥＧＥＲに制約される。ノンスは、ＡＳＮ．１タイプのＯＣＴＥＴ  ＳＴＲＩＮＧであるｅｘｔｎＶａｌｕｅに符合化され、したがって、理論的にバインドされていない。メッセージ全体は、実装形態及び実施上の配慮に応じてＯＣＴＥＴ  ＳＴＲＩＮＧに入れることができるであろう。ノンスのためのｅｘｔｎＶａｌｕｅは、ノンスによって提供されるとされる新鮮さの保証を得るために、メッセージ（又はその表現及びもし不明瞭な場合は随意として対応するハッシュアルゴリズム識別子）と、実際にノンスとしての働きをするランダムデータとの両方を含んでよい。非ＯＣＳＰ関連のハッシュをノンスに導入しようとする要求者の試みがＯＣＳＰサーバによって検出されないようにするため、要求者は、ランダムに見えないデータ（すなわちアルゴリズム識別子）をノンスに入れないようにし、その代わりに、メッセージハッシュ値に対応するアルゴリズムを識別するための基準として証明書ＩＤ内のアルゴリズム情報を使用してよい。いずれにせよ、メッセージハッシュは、ＯＣＳＰ応答者がその応答に署名する限り、（新しい拡張内など）ＯＣＳＰ要求内のどこに配されてもよい。
【００３６】
この情報を検証する対応するシステムは、本明細書において説明される様々な関連付け方法を通じてメッセージに関連付けられたＯＣＳＰ応答を取得する。代表的な実施形態において、もし送信者がＯＣＳＰ応答を調達する場合は、ＯＣＳＰ応答を配するようなロケーションの１つは、Ｓ／ＭＩＭＥメッセージの一部を構成するＰＫＣＳ＃７又はＣＭＳのＳｉｇｎｅｄＤａｔａ構造のＲｅｖｏｃａｔｉｏｎＩｎｆｏＣｈｏｉｃｅｓ構造内である。当業者ならば、この挿入を「ＯＣＳＰステープリング」として識別することができる。ＯＣＳＰ応答を解析するときに、検証システムは、上述された任意の領域内におけるメッセージハッシュの存在をチェックする。もし証明書ＩＤ構造の１つに入っている場合は、そのハッシュに対応する発行者名、発行者鍵、又はシリアル番号が記録されていないので、その証明書ＩＤについてのＯＣＳＰ応答者の状態応答は、恐らくは「未知」であろう。それでもなお、その状態応答は、無視されるか、又はＯＣＳＰ応答の信憑性に関する確証となる証拠として使用されるかしてよい。例えば、もし要求者が、実在する証明書の証明書ＩＤを要求した（そしてＣＡがそれらの記録をまだ維持している）場合は、予期される応答は、「有効」又は「破棄された」であると考えられる。反対に、もし要求者が、メッセージ又はその表現を内包する証明書ＩＤを要求した場合は、予期される応答は、「未知」である。もしＯＣＳＰ応答者が、メッセージデータを内包する証明書ＩＤについての要求に「有効」（又はひいては「破棄された」）を返す場合は、ＯＣＳＰ応答者が信憑できない（すなわち実在しない証明書について証明書ＩＤの状態を偽っている若しくは誤って伝えている）か、又はハッシュ衝突が存在するかのいずれかであり、これは、暗号的裏付けについての更に深刻な問題を示している。
【００３７】
もしノンス内にある場合は、検証システムは、ノンスのＯＣＴＥＴ  ＳＴＲＩＮＧからハッシュ値（又は実のところメッセージ自体）を、そして場合によってはアルゴリズム選択も抽出するか、又はＯＣＳＰ応答のその他の部分からそれを推測する。メッセージ又はその表現を見つけ、それを問題のメッセージと同一と見なすと、システムは、そのメッセージが時刻ｔにおいて存在していたと結論付け、したがって、そのメッセージが（刻印さ
れた情報に応じて）送信又は受信されたと合理的に結論付けることが可能になる。システムは、次いで、図５Ｃに示されるような、この結論に準じた指標を生成してよい。
【００３８】
ＯＣＳＰ応答は、文字通りＴＳＡとして機能するのではないが、それでもなお、広範囲の状況において、信憑でき且つ許容できる証拠である。連邦証拠規則下において、例えば、このようなＯＣＳＰ応答記録は、一部が伝聞証拠で一部が非伝聞証拠である。先ず、応答内における暗号ハッシュ値の存在は、作成時タイムスタンプ及び現更新時タイムスタンプと相まって、それらの時刻にメッセージが存在していたことを示す傾向があるので、ＯＣＳＰ応答記録は、メッセージの存在の問題に関連している。問題となる真実は、その時刻に要求者がメッセージを保有していたかどうかである。ノンスは、文字通り「メッセージはハッシュ０１２３４５６７ではない」ことを示してよいが、もし０１２３４５６７が、それが高い確率でメッセージに対して固有であることを示すメッセージダイジェスト関数のみを起源とするものとして示すことができる場合は、０１２３４５６７の存在自体が、０１２３４５６７に対応するメッセージが存在したこと及び０１２３４５６７がそのメッセージのハッシュであることを裏付ける傾向がある。
【００３９】
それでもなお、完全なＯＣＳＰ応答の存在は、伝聞証拠である。なぜならば、ＯＣＳＰ応答は、特定の時刻に生成されることを主張するものであり、したがって、そこに宣言された事項の真実のために提供されなければならないからである。更に、ＯＣＳＰ応答は、定期的に行われる活動の記録であってよく、したがって、伝聞証拠を許容できない一般則の「業務記録例外」に該当するであろう。ＯＣＳＰ応答は、行為（「何者かが要求を行った」）、イベント（「何者かが要求を行った」）、状況（「ＩＤに関連付けられた証明書が破棄された若しくは破棄されていない、又は未知である」）、及び意見（「ＣＡポリシーに違反する疑いがあるゆえに証明書が破棄された」）の報告、記録、又はデータ編集であり、知識を有する人物（すなわち信憑できる組織体としてのＣＡ）によって伝送される情報をもとにその時点でなされ、定期的に行われる業務活動（証明書状態を提供し、ＯＣＳＰ応答者を通じてＣＡの制御下に維持される秘密鍵で各応答に署名する）の過程で維持される。
【００４０】
ＣＡの制御下にあるＯＣＳＰ応答者が、応答をその時刻に生成されたものと主張する真実を否定するためには、ＣＡは、それが（その機械的エージェントすなわちＯＣＳＰ応答者を通じて）記録に署名したこと、又はそれがＯＣＳＰの寿命中の少なくとも一時点において時刻の正確な追跡に失敗したことを否認する必要があると考えられる。しかしながら、信憑できるＯＣＳＰサービスを維持する信憑できるＣＡは、ＯＣＳＰがなしたその他の全ての応答の信頼性も否定しない限り、これらの提案を否定することができないと考えられる。このような否定は、可能ではあるが、その認証実施規定（ＣＰＳ）に違反する可能性があり、したがって、ＣＡをその監視役（ＷｅｂＴｒｕｓｔなど）によってなされ且つ承認された宣言にしたがわなくさせると考えられる。更に、要求者は、総じて（「未知」ではなく）「有効」又は「破棄された」として知られる実際に存在する証明書ＩＤの状態をＯＣＳＰサーバに対して要求することによって、更なる裏付け証拠を導き出すことができる。実際に発行されたアクティブな証明書に対するＯＣＳＰサーバからの「有効」応答は、ＯＣＳＰサーバの応答が、実際の証明書が発行された時刻までの少なくとも早期に境界を定められた証明書の「有効」期間中に生成されることの、確証となると考えられる。証明書の有効期限及びアーカイブ停止日は、更なる裏付け証拠として後の時刻の境界を定めるのに役立つことができる。更に、ＣＡは、通常は、十分に信憑できるものであるために、自身のＣＰＳに適合するために、及び（ＷｅｂＴｒｕｓｔなどの）その監視役の承認を維持するために、自身が発行する証明書の発行日及び有効期限に対して正確な時刻を保持及び維持しなければならない。
【００４１】
実施形態は、メッセージが別途信頼できるとして知られている間にユーザがメッセージ
を閲覧して暗に信頼したことを、覚えておくこともできる。例えば、システムは、このような情報を、例えばシステムが作動しているコンピュータ上の基本設定データベースに、基本設定として格納することができる。（ユーザに代わって）システムは、第三者ＴＳＡから暗号タイムスタンプを調達し、そのタイムスタンプをメッセージに関連付けることができる。
【００４２】
次に、添付の図面に例示された本発明の代表的な実施形態について詳細に言及される。可能な限り、全ての図面を通して、同じ又は似た部分には同じ参照番号が使用される。
【００４３】
全体として、図１は、代表的なシステムを示している。図１は、本発明の実施形態に適合した代表的なシステムを示している。図１は、説明された実施形態に対するアーキテクチャ的限定ではなく、単なる一例であることを意図している。図示されるように、システム１００は、ネットワーク１０２と、ユーザコンピュータ１０４と、メッセージングサーバ１０６と、ＣＡサーバ１０８と、送信者によって操作される送信者コンピュータ１１０とを含んでよい。これらの構成要素は、以下において更に説明される。システム１００は、しかしながら、図示されていない更なるサーバ、クライアント、及びその他のデバイスを含んでよい。
【００４４】
ネットワーク１０２は、ユーザ１０４、メッセージングサーバ１０６、及びＣＡサーバ１０８などの、システム１００のその他の構成要素間の通信をサポートするための通信インフラとして機能する。このようなネットワークは、当業者にとって周知であり、ローカルエリアネットワーク、都市規模ネットワーク、広域ネットワーク、モバイル通信ネットワーク（３Ｇネットワークなど）、ＷｉＦｉネットワークなどを含む。一部の実施形態において、ネットワーク１０２は、１つ又は２つ以上のインターネットネットワークを含んでよい。
【００４５】
ユーザコンピュータ１０４は、ユーザが実施形態の方法及びシステムを用いるための、ハードウェア及びソフトウェアを提供する。ユーザコンピュータ１０４は、パソコン、ネットワークコンピュータ、モバイルフォン、ラップトップコンピュータなどの、周知のデバイスに実装されてよい。図示された例では、ユーザコンピュータ１０４は、プロセッサ、メモリ、ストレージシステム、ブートファイル、オペレーティングシステムイメージ、及びアプリケーション（ブラウザやブラウザ拡張など）などの、ハードウェア、ソフトウェア、及びデータ（不図示）を含んでよい。更に、ユーザコンピュータ１０４は、システム１００のその他の構成要素と通信するために、ＴＣＰ／ＩＰプロトコル一式を用いてよい。
【００４６】
メッセージングサーバ１０６は、メッセージングに関連したサービスを、例えばユーザ１０４に提供する。例えば、メッセージングサーバ１０６は、Ｅメールアプリケーションを実装する１つ又は２つ以上のサーバであってよい。このようなサーバは、当業者にとって周知である。もちろん、メッセージングサーバ１０６は、アカウント管理などのその他のサービス、又はその他の形態のメッセージングを提供してもよい。一部の実施形態において、メッセージングサーバ１０６は、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅなどの周知のＥメールサービス、又はＹａｈｏｏ！  ＭａｉｌやＧｍａｉｌなどのウェブメールサービスに関連したものであってよい。
【００４７】
図示された例では、メッセージングサーバ１０６は、プロセッサ、メモリ、ストレージシステム、ブートファイル、オペレーティングシステムイメージ、及びアプリケーション（ブラウザやブラウザ拡張など）などの、ハードウェア、ソフトウェア、及びデータ（不図示）を含んでよい。更に、メッセージングサーバ１０６は、システム１００のその他の構成要素と通信するために、ＴＣＰ／ＩＰプロトコル一式を用いてよい。
【００４８】
ＣＡサーバ１０８は、ユーザコンピュータ１０４、及び送信者や送信者コンピュータ１１０などのシステム１００のその他の主体の両方に信頼される第三者としての機能を果たすことができる。例えば、ユーザコンピュータ１０４及び送信者コンピュータ１１０は、例えば各コンピュータのＩＤを確認して各コンピュータの公開鍵を提供するなどの、特定の種類の証明のために、必ずしもユーザ又は送信者でなくＣＡサーバ１０８に依存してよい。全体として、ＣＡサーバ１０８は、各コンピュータが実際に言うとおりの者であることを確認し、次いで、各コンピュータの公開鍵を他者に提供する。一部の実施形態において、ＣＡサーバ１０８は、デジタル証明書と、ユーザコンピュータ１０４及びメッセージングサーバ１０６が自身のメッセージングをセキュアにすることを可能にするＰＫＩシステムとを提供する。例えば、一部の実施形態において、ＣＡサーバ１０８のサービスは、メッセージングサーバ１０６によって提供されるウェブメールアプリケーションによってユーザ１０４がＳ／ＭＩＭＥを使用することを可能にする。
【００４９】
図示された例では、ＣＡサーバ１０８は、プロセッサ、メモリ、ストレージシステム、ブートファイル、オペレーティングシステムイメージ、及びアプリケーション（ブラウザやブラウザ拡張など）などの、ハードウェア、ソフトウェア、及びデータ（不図示）を含んでよい。更に、ＣＡサーバ１０８は、システム１００のその他の構成要素と通信するために、ＴＣＰ／ＩＰプロトコル一式を用いてよい。
【００５０】
送信者コンピュータ１０４は、送信者が実施形態の方法及びシステムを用いるための、ハードウェア及びソフトウェアを提供する。送信者コンピュータ１１０は、パソコン、ネットワークコンピュータ、モバイルフォン、ラップトップコンピュータなどの、周知のデバイスに実装されてよい。図示された例では、送信者コンピュータ１１０は、プロセッサ、メモリ、ストレージシステム、ブートファイル、オペレーティングシステムイメージ、及びアプリケーション（ブラウザやブラウザ拡張など）などの、ハードウェア、ソフトウェア、及びデータ（不図示）を含んでよい。更に、ユーザコンピュータ１０４は、システム１００のその他の構成要素と通信するために、ＴＣＰ／ＩＰプロトコル一式を用いてよい。
【００５１】
図２Ａ〜Ｂは、同様のタイプの情報を異なるフォーマットで伴う２つの異なるプロバイダからの証明書を示している。当業者ならば、メッセージの信頼性又は信憑性を決定するために、実施形態によって、その他のフォーマットの証明書が用いられ分析されてよいことを認めるであろう。
【００５２】
図３は、説明されたシステムの代表的な実施形態についての代表的なアルゴリズム及びデータフローを示している。段階３００において、メッセージが受信される。例えば、ユーザがＯｕｔｌｏｏｋなどのＥメールクライアントを用いるときは、ユーザコンピュータ１０４が、メッセージを受信するであろう。或いは、ユーザがウェブメール又はその他の形態のメッセージングを用いるときは、メッセージングサーバ１０６が、最初にメッセージを受信するデバイスであろう。
【００５３】
一実施形態では、段階３０２において、メッセージダイジェスト及び様々な暗号的裏付けが計算される。次いで、段階３０４において、メッセージに関する様々な指標が決定される。
【００５４】
段階３０６において、メッセージに関する指標は、平易言語の文又は平易言語の能動態文法の文などの、ユーザによる容易な理解を意図した文に作成される。このような文が、図に例示されている。図中の例は、日本語（原文では「英語」）で示されているが、当業者ならば、実施形態が任意の言語の文で指標を提示できることを認識しているであろう。
【００５５】
段階３０８では、ユーザから受動的にフィードバックが要求されてよい。このフィードバックは、例えば指標を第三者証明からユーザによる第一者証明に変えるにあたって指標を変更するために使用されてよい。また、フィードバックの要求は、異なるタイプのユーザインターフェース要素を使用して提示されてよく、自動タイムアウトなどのその他の特徴を用いてよい。
【００５６】
段階３１０において、もしフィードバックが受信されない場合は、処理は、段階３１２に進んでよい。そうでない場合は、処理は、段階３１６に進んでよい。段階３１２では、ユーザが、例えば「怠け者」ユーザなどの応答しないユーザであるかどうかが決定される。もしユーザが「怠け者」である又はその他の理由で応答しない場合は、実施形態は、ユーザからのフィードバックを求めるために、ポップアップウィンドウなどの、より能動的なユーザインターフェースの手段に訴えてよい。もしフィードバックが実際に受信された場合は、処理は、段階３１６に進んでよく、そこでは、指標を変更するためにフィードバックが使用されるとともに、様々な信頼関係が変更されてよい。
【００５７】
もしユーザが「怠け者」でない場合は、又はフィードバックが受信されたときは、処理は、段階３１８に進んでよく、そこで、ユーザコンピュータ１０４又はメッセージングサーバ１０６は、ユーザがメッセージから離れるまで待つ。例えば、ユーザは、別のメッセージを選択してよい、又はメッセージの一覧に戻ってよい。
【００５８】
段階３２０において、ユーザコンピュータ１０４又はメッセージングサーバ１０６は、ユーザのフィードバック、指標、及び様々な信頼関係に関する統計値を（随意に）記録する。段階３２２において、システム１００は、次のメッセージの処理に進んでよい。
【００５９】
図４は、計算された指標を伴うメッセージ表示の例を示している。図に示されるように、下線のテキストは、通常は、ハイバーリンク、又はインタラクティブなその他のテキストオブジェクトを示している。テキストは、アクティブにされると、下線情報に関する情報を立ち上げるように、又は更なる処理で応答するように、ユーザコンピュータ１０４を促してよい。
【００６０】
図４では、メッセージの上方に、情報バーが現れている。図に示された例では、情報バーは、把握された信頼関係に基づく指標を含む。これらの関係は、ＰＫＩを通じて確立されメッセージングサーバ１０６によるなどシステム１００によって解析された認証関係に依存してよい。別の実施形態では、信頼関係は、信頼の暗号ウェブを通じて確立されシステム１００によって解析された認証関係を通じて到達される。
【００６１】
図に示されるように、メッセージ４００は、ヘッダ部分４０２と、コンテンツのメッセージ本体４０４とを含む。また、メッセージ４００の一部としてメッセージ４０６が示されており、これは、信頼関係に関する指標を含むとともに、信頼関係に関する指標を変更するための「信頼する」、「信頼しない」、「追加情報」などのユーザインターフェース要素を含んでよい。
【００６２】
図５Ａ〜Ｆは、ユーザコンピュータ１０４にメッセージが表示されるときにシステム１００によって生成することができる指標のヴァリエーションを示している。図に示されるように、二重下線のテキストは、姓と名などの、二重下線を用いないと曖昧になる指標を区別することを除き、総じて、下線のテキストと同じ働きをする。クリックされると、ユーザコンピュータ１０４は、メッセージの伝送中に実際に何が起きたか又はテキストが文脈内において何を意味しているかに関する説明を立ち上げることができる。
【００６３】
とりわけ、図５Ａは、実施形態において用いることができる平易言語の文の言い回しのヴァリエーションを示している。図５Ａは、タイムスタンプ及び複数の証明者を示している。図５Ｃは、情報をどのように詳細化又は省略化できるかを示している。図５Ｄは、期限切れの証明書を、そうでなければ有効であった暗号的裏付けとともに示している。図５Ｅは、メッセージダイジェスト障害を示している。ダイジェスト障害の場合は、代表的一実施形態は、警戒及び警告としてこれ以上指標をユーザに表示しないように構成されてよい。図５Ｆは、時間に依存する様々な状況下において証明書が破棄された場合の指標を示している。したがって、図５Ａ〜Ｆに示されるように、指標の内容には多くのヴァリエーションが可能である。
【００６４】
初めに、システム１００において、対応するデジタル証明書から指標の内容を取得することができる。システム１００は、指標について、以下を含む幾つかのタイプの情報を把握してよい。
１．  信頼の基準を表明する１つ又は２つ以上の主体。
２．  送信者の立場。人であるか、又は企業であるか。
３．  名前の特定の順列の形をとる送信者の名前。
４．  送信者の所属。
５．  メッセージングアドレス。
６．  ロケーション。
７．  信頼関係の最新状態：恐らくは指標に対するユーザの第一印象後に「怠け者更新」を通じて追加されている。
８．  ユーザが信頼関係を変える機会を示す情報。
【００６５】
次に、図５Ｂ及び図５Ｆを参照すると、一部の実施形態の特徴は、システムがタイムスタンピング情報のためにもっぱら第三者ＴＳＡに依存する必要はないことにある。例えば、もしシステム１００が受信サーバ（すなわちメッセージングサーバ１０６）に依存するならば、システム１００は、時刻表明の基準が受信サーバであることを示す。ユーザは、ユーザ自身が受信サーバ１０６を信頼できるものとして信じている限り、この時刻に依存してよい。
【００６６】
図６Ａ〜Ｂは、段階的に更新される指標の目立つ表示を示している。これらの表示は、例えば、表示されるセキュリティレベル及び信頼レベルに注意を払うようにユーザを仕向けようとするために使用されてよい。上記に示された指標の特徴は、信頼の基準を証明する主体を、図６に示されるように目立つ形で（すなわちユーザが一瞥で見てとれる形で）ユーザに提示することにある。
【００６７】
特定の実施形態において、この証明主体の提示は、幾つかの利益を伴うことができる。ユーザは、証明主体に直接依存できるであろう。証明主体は、ますます多くのユーザに知られ、認められるようになるであろう。証明主体は、評価値などの更なる値を有することができるであろう。
【００６８】
代替の実施形態において、情報バーの情報は、１つ又は２つ以上のメッセージヘッダに集約される。ユーザは、Ｆｒｏｍ：行の詳細を無視する可能性があるので、代表的な実施形態において、システムは、指標を目立たせるために、図４にあるようなユーザインターフェース要素を有してよい。ただし、図７Ａ〜Ｃは、本開示の一部の実施形態にしたがった、Ｆｒｏｍ行に集約される指標を示している。
【００６９】
一実施形態において、システム１００は、セキュリティレベル及び信頼レベルに注意を払うようにユーザを仕向けようとする。システム１００は、例えば、図６Ａに示されるように、メッセージの大部分の表示を保留してよい、又はあとで消える若しくは最小化され
る視覚的表示（ポップアップウィンドウなど）でユーザの目を捉えてメッセージを明らかにする。したがって、ユーザには、待機期間に表示を読む機会がある。
【００７０】
一実施形態において、ユーザは、応答することを求められる。或いは、ユーザは、受身で待機してよく、指標の表示は、短いタイムアウト又は予めプログラムされた動画シーケンスによって消される。
【００７１】
更に、システム１００は、タイムスタンプ又は破棄情報などの更新後の指標を計算するために、更なる情報を収集してよい。このような視覚的表示は、強調又は出しゃばり具合を漸減させてよい。このような動画表示のフローチャートが、図８に示されている。
【００７２】
図６Ａ〜Ｂのような図からわかるように、情報バーによって提示される情報は、メッセージ空間内において目立つように特徴付けることができる。システム１００のオーバーレイ（信頼できるもの）とメッセージのコンテンツ（ユーザが評価するもの）とを区別するために、更なる視覚的標識が使用されてよい。例えば、メッセージのコンテンツによって無効にすることができないボックス内に、指標を囲ってよい。このような実施形態では、システム１００のオーバーレイのみが信頼できるとみなされ、ボックスの境界を破ることを許可される。例えば、図６Ａ〜Ｂに示されるように、オーバーレイ６００は、信頼できるとみなされ、ユーザによる評価のために様々な指標を提示してよい。
【００７３】
更に、図４に示されるように、検証されていないメッセージヘッダ（ＲＦＣ２８２２ヘッダなど）などの、送信者に対して暗号的にバインドされていない値が、暗号的にバインドされているデータから分離されるか又は区別されるかしてよい。図４に示されるように、ヘッダ４０２は、メッセージの日付、宛先、送信元、及び件名を含んでよい。
【００７４】
図６Ａ〜Ｂに示されるように、（ボックス４００によって示されるような）バインドされていない値は、曖昧化されることによって区別される、すなわち示されないか、暗くされるか、又は覆い隠される。説明のため、図６Ａ〜Ｂは、曖昧化されている部分を例示するために、グレー表示部分を示している。これは、それが実際に表示されるであろう形とは異なる。
【００７５】
図８は、図６Ａ〜Ｂに示され且つ本明細書において説明される動画表示のフローチャートである。段階８００において、メッセージの指標が、例えばメッセージングサーバ１０６又はユーザコンピュータ１０４によって計算又は決定される。段階８０２において、システム１００は、ＣＡサーバ１０８などの様々なソースからの更新情報を要求する。段階８０４において、システム１００は、次いで、この情報に基づいてメッセージの指標を再計算又は変更してよい。一方、段階８０６において、ユーザコンピュータ１０４又はメッセージングサーバ１０６は、ユーザに指標を提示してよい。例えば、もしユーザがＯｕｔｌｏｏｋなどのＥメールクライアントを用いているならば、ユーザコンピュータ１０４が、ユーザに指標を提示してよい。或いは、もしユーザがウェブメールを用いているならば、メッセージングサーバ１０６が、ユーザコンピュータ１０４上で動作しているブラウザを通じてユーザに指標を提示してよい。
【００７６】
指標を提示するにあたっては、様々なユーザインターフェース要素が用いられてよい。例えば、図６Ａ〜Ｂに例示されるように、指標は、オーバーレイの形で提示されてよい。指標は、ユーザが指標を読んで理解することを可能にするために、様々な速度で表されてよい。この処理段階で、新しい指標が提示されてもよい。
【００７７】
一部の実施形態において、オーバーレイは、タイムアウトを通じて制御され、自動的に表示から後退してよい又は折り畳まれてよい。一部の実施形態では、ユーザに対して表示
するために、簡略化された指標が残されてよい。
【００７８】
段階８０８において、ユーザは、図１０Ａ〜Ｃなどの図に例示されるように、例えば指標を変更するために応答を返すように指示されてよい。もしユーザが応答を提供する場合は、段階８１０において、必要に応じて続きの質問が提示されてよい。すると、段階８１２において、ユーザは、メッセージを妨げなく見ることができる。
【００７９】
ユーザが応答を提供しない場合でも、段階８１４において、ユーザは、やはり、妨げなくメッセージを見ることを可能にされてよい。この移行は、例えば、タイムアウト時間の後に可能にされてよい。
【００８０】
図１０Ａ〜Ｃに示されるように、実施形態は、ユーザが第三者証明を第一者証明に切り替えること、すなわちユーザがメッセージ若しくは送信者に関する文を採用すること又はメッセージ若しくは送信者に関する自身の文を作成することを可能にするとともに促進する。ユーザが今信頼していることと、ユーザが過去に記録したことに基づいてシステムがユーザに提供できることとの間には、差がある。したがって、システムは、ユーザが今考えている又は信頼していることについて、この惰性を克服する必要がある。実施形態は、したがって、この見解を信頼することをやめて実施形態のソフトウェアを使用するように、ユーザを促してよい。
【００８１】
図１０Ａ〜Ｃは、ユーザが信頼関係を発展させようと試みるときに提示される指標、ユーザ動作の例、システム応答、及びユーザインターフェースを示している。とりわけ、図１０Ａは、個人についてのフローを提示しており、ユーザは、証明の諸側面がそれらの提供目的に叶う信憑性又は正確さを有するという結論に達し、その結果、信頼が増している。図１０Ｂは、企業についてのフローを提示しており、ユーザは、証明の諸側面がそれらの提供目的に叶う信憑性又は正確さを有するという結論に達し、その結果、信頼が増している。図１０Ｃは、企業についての（そして問題となるＣＡについての）フローを提示しており、ユーザは、証明の諸側面がそれらの提供目的に叶う信憑性又は正確さを有するという結論に達し、その結果、信頼が低下している。
【００８２】
図９Ａ〜Ｂは、信頼されていない自己署名の証明書及び認証機関についての指標を示している。実施形態は、自己署名証明書及びそれらによる影響を様々な形で扱うことができる。自己署名証明書は、第三者による証明を必要としないゆえに容易に作成することができるが、内部の情報を容易に捏造可能である。本システムの実施形態は、スパマ−又はフィッシャーなどの悪質な送信者が偽情報で自己署名証明書を作成する可能性があることを認識している。悪質な送信者は、また、認証機関を装って、このようなＣＡに代わって信頼できないデジタル証明書を署名させる可能性もある。
【００８３】
一部の実施形態において、自己署名主体についての指標は、仮にそれが現れるとすると、図９Ａに例示されるように、いかなる装飾も伴わずに現れてよい。本システムの実施形態によって表示される指標が、図９Ｂにも示されている。したがって、これらの実施形態の利点は、暗号技術、ＰＫＩ、又はＷｅｂｓ  ｏｆ  Ｔｒｕｓｔについてほとんど経験がないユーザでもシステム１００の特徴を容易に採用して尚且つ理解できることにある。
【００８４】
図９Ｂに示されるように、システム１００は、その他のソースからのいかなる独立した証明も情報も伴わずにユーザの個人的な評価又は知識に基づくユーザによる証明をサポートすることができる。したがって、ユーザは、自己署名証明書を信頼することを選択することもできる。しかしながら、実施形態は、ユーザがメッセージをやみくもに信頼することは許さない。一部の実施形態において、たとえメッセージの認証に関わる任意のメッセージ側面を証明する信憑できる証明者がない場合でも、ユーザ又はユーザコンピュータ１
０４は、依然として、例えば送信者がメッセージにどのように署名したかに基づいて、又はメッセージから得られるＳＨＡ−１フィンガープリントなどのその他の暗号情報を解析することによって、信頼性に対する何らかの評価を行ってよい。
【００８５】
図１１は、ユーザから又は別の証明主体から表明された信頼の変化を伝える代表的な指標を示している。図１２は、一部の実施形態による指標衝突の解消を示している。図１３は、一部の実施形態によって指標衝突を解消する別の例を示している。図１４は、一部の実施形態によって指標衝突を解消する別の例を示している。図１５Ａ〜Ｃは、署名されたメッセージが続いた後に未署名のメッセージが現れるときなどの様々な署名パターンにおけるメッセージの信頼性の解消を示している。図１５Ｄは、送信者の指標の解消が成功したにもかかわらず指標の衝突を示すために表示される代表的なユーザプロンプトを示している。図１６Ａ〜Ｂは、メッセージの信頼性を示す代表的な一覧を示している。図１７Ａ〜Ｂは、既知のシステムのユーザインターフェースを示している。
【００８６】
図１８は、代表的なデジタル証明書と、送信者の役割に関連した情報とを示している。図１９は、図１８に示されたデジタル証明書に基づく指標の例を示している。図２０は、「スパム報告」ボタンを伴う既知のウェブメールインターフェースを示している。
【００８７】
図２１は、ユーザが役割ベースの（マーケティング）信頼関係の低下を表明しようと試みるときの、指標、ユーザ動作、システム応答、及びユーザインターフェースを示している。図２２Ａ〜Ｂは、本明細書において説明される役割ベースのポリシーにしたがった、とりわけ画像及びリンクに関する指標を示している。
【００８８】
図４から図９に例示されるような、システムが初期の信頼レベルを確立するための方法の様々な実施形態が説明されてきたが、これらの実施形態は、更に、ユーザがこのような信頼レベルを時間とともに変更することを助けることもできる。リンク又はその他の指標は、ユーザに、差し出された提案に対する自身の信頼感を上げる又は下げるように指示してよい。ユーザが信頼関係の進展を望むことを示したときは、ユーザは、ユーザが送信者に関する詳細に注釈を付けることを可能にする図１０Ａのようなインターフェースを提示される。ユーザは、個々の情報に関して確認、否認、又は非選択の表明をしてよい。随意として、ユーザは、このような詳細をユーザのアドレス帳に追加してよい、又は注釈の付いた証明書をそれ以外の方法で既存のアドレス帳のエントリに結びつけてよい。随意として、システムは、注釈の付いたこのような詳細をユーザの秘密鍵でデジタル署名する。
【００８９】
ユーザは、メッセージを何度も見ることができるが、メッセージを単に見るだけでは、どの程度であれユーザが送信者又は特定のメッセージを信頼していることにはならない。例えば、送信者は、スパムボットのＥメールアドレスを付帯している正当に取得された証明書を有するスパムボットであるかもしれない。送信者は、最近になってコンピュータ及び秘密鍵を不運にも侵害されたユーザの友人であるかもしれない。
【００９０】
したがって、一部の実施形態は、メッセージを、（Ａ）メッセージが送信者からであると主張するものと、（Ｂ）メッセージが送信者の秘密鍵を保持する何者かからであると主張するものとで明確にする又は区別することができる。これらの実施形態において、システム１００は、ユーザが特定のメッセージを見る回数を考慮してよいが、ユーザが自身の信頼レベルに対して行う肯定表明に、より重きを置く傾向があってよい。
【００９１】
メッセージングサーバ１０６又はその他の何らかの構成要素（不図示）などの、システム１００は、ユーザが読むこと（読む時間の長さを含む）と、同じデジタル署名を一貫して提示する送信者からのメッセージを暗黙に受諾することを監視してよい。ユーザが、信頼判定を示すことなくこのようなメッセージを数回読んだ後、システム１００は、ユーザ
に、その送信者によって一貫して使用されている証明書を信頼するかどうかを示すように指示してよい。
【００９２】
更に、一部のメッセージは、例えば、コンテンツベースの発見的（ヒューリスティック）手法によって高スコアの疑惑を報告されたゆえに、又は証明書を自己署名されているゆえに、又は以下に挙げられる技術を使用して検出され表示された履歴的期待に合わないゆえに、疑わしいことがわかるであろう。システム１００は、（Ａ）情報バーの中で受動的に尋ねるなど、ユーザがメッセージを読んでいる間に、及び（Ｂ）ポップアッププロンプト又はポップアップウィンドウなどのユーザインターフェースを使用して能動的に尋ねるなど、ユーザがメッセージを読んだ後に、メッセージを信頼するかどうかをユーザに肯定的に尋ねることができる。
【００９３】
更に、システム１００は、ユーザが自身の信頼関係を変える時刻を記録することができる。図１１に示されるように、このような時刻は、のちのメッセージにおいて、指標として使用されてよい。このような指標は、証明者からの更なる時刻ベースの指標によって強化されてよい。例えば、ＣＡは、特定の下位証明書の信頼性について警告するために、証明書破棄リスト及びオンライン証明書状態プロトコルサーバなどの更新サービスを提供してよい。
【００９４】
通常のユーザは、モーダルダイヤログを読まずにすぐ閉じることがあるので、ユーザは、多くの個人データを入力又は肯定しそこなった状態で信頼関係を肯定することがある。モーダルダイヤログは、ユーザがメールクライアントソフトウェアアプリケーションなどのそれ以外のアプリケーションと対話することを阻む、小ウィンドウなどのユーザインターフェース要素として知られている。したがって、ユーザは、Ｅメールアドレスのみを承認するであろう。このような場合、システム１００は、信頼されている同じ送信者からの他のメッセージをユーザが受動的に読んだ後に、ユーザに、より多くのデータを入力するように指示してよい。このプロンプトにおいて、システム１００は、別のソースからの証明情報がなければ未証明とされるデータ（未証明のＦｒｏｍ行に一貫して提示される名前など）を示唆してよい。これは、例えば、大抵の場合、余分な情報を多く提供することなくユーザが追加データを承認することを可能にするのに有用である。
【００９５】
更に別の実施形態では、一貫した履歴的なデジタル署名情報の存在及び呼び戻しが、異なる署名情報又は署名情報の欠落による攻撃を区別することを助ける。システム１００のユーザインターフェース要素の特定の実施形態は、２つの別々の送信主体について指標が衝突する可能性を提起している。上記のように、図１２〜１６は、このような状況の例を示している。
【００９６】
例えば、有効で且つ信頼できる２つの送信者が、同じ又は著しく似た指標を有することがある。すなわち、（カリフォルニアにある）「ＣｏｍｐａｎｙＣｏｒｐ」の「Ｌｉｚ  Ｃａｒｌｓｏｎ」＜ｌｉｚ＠ｃｏｍｐａｎｙｃｏｒｐ．ｃｏｍ＞と、（デラウェアにある）「ＣｏｍｐａｎｙＣｏｒｐ」の「Ｌｉｚ  Ｃａｒｌｓｏｎ」＜ｌｉｚ＠ｃｏｍｐａｎｙｃｏｒｐ．ｂｉｚ＞とがいて、いずれの会社も、その所在地に関する十分な情報をＣＡに提供していないことがある。別の例として、信頼できない送信者が、信頼できる送信者に成りすまそうとすることがある。すなわち、「Ｌｉｚ  Ｃａｒｌｓｏｎ」＜ｌｉｚ＠ｈｏｔｍａｉｌ．ｃｏｍ＞が、「Ｌｉｚ  Ｃａｒｌｓｏｎ」＜Ｉｉｚ＠ｃｏｍｐａｎｙｃｏｒｐ．ｃｏｍ＞に成りすまそうとする。信頼できない送信者は、異なる自己署名デジタル証明書を伴って、信頼できる送信者に成りすまそうとするであろう。信頼できない送信者は、様々な送信者のＥメールアドレス及び氏名を識別する目的に叶う信頼性又は全体的信憑性を有するものとしてシステムが扱うＣＡによって署名された証明書を伴って、信頼できる送信者に成りすまそうとするであろう。信頼できない送信者は、メッセージに署名する
ことなしに、信頼できる送信者に成りすまそうとするであろう。上記のように、衝突及び異常を記録した指標が、図１２に提示されている。近いケースは、紛らわしい類似のドメイン名を解析するために提案されたアルゴリズムなどの、ホモグラフ攻撃を特定するアルゴリズムを用いることによって、システム１００によって判定されてよい。
【００９７】
システム１００の技術に固有の信頼関係は、指標の衝突が表示されるのを阻止するであろう。システム１００は、信頼できる又は信憑できるＣＡが、下位のＥメールアドレス又はその他の指標を検証することなく信頼できない送信者に証明書を発行することはないと、予め把握しているので、指標の衝突の大半は、発生しないのが通常である。それでもなお、指標の衝突は、例えば、古いＥメールアドレス用の送信者証明書が期限切れになる前に下位のドメイン名の所有者が変わるなどのように、Ｅメールアドレスの持ち主が変わるときに発生することがある。
【００９８】
代表的な実施形態において、システムは、正当に更新された証明書を送信者から受信し、新しい証明書によってシステムの信頼履歴を自動的に更新する。このような正当性を実証する分野における例として、署名されたメッセージに副署名すること、又は署名されたメッセージを別の署名されたメッセージに包むことが挙げられる。副署名又は外署名は、古い秘密鍵によって生成され、元の署名又は内署名は、新しい秘密鍵によって生成される。一部の実施形態は、「不要なＩＤ集中攻撃」などの特定のタイプの攻撃を回避するために、古い鍵で新しい鍵に副署名すること及びその反対によって又は等しい鍵のみを明確に識別するメッセージに二重署名することによって生成されるデータを検証する。このような攻撃では、新しい鍵の所有者は、古い証明書（又は古い鍵を含むその他の形態のデータ）に署名するが、古い鍵の所有者のＩＤは、新しい鍵の所有者のＩＤと異なるので、古い鍵の所有者は、新しい鍵の所有者による等価性の主張を望まない又は受け入れない。システム１００の更なる実施形態は、メッセージの送信者だけでなく、ＣＡからなど任意の証明者からの証明を受け入れることができる。システムは、随意として、図１３に示されるように、このような更新に関する通知を提示し、これは、ユーザがもし古い秘密鍵が侵害されたと考えた場合に変化を拒絶することができるように、ユーザに変化を通知する働きをする。
【００９９】
このような正当な更新がない限り、この場合は、信頼できる送信者と信頼できない送信者とで鍵が異なる。したがって、実施形態によって使用される代表的な解決策が、図１４に示されている。
【０１００】
指標の衝突に対する解決策が、図１５Ａ〜Ｃに示されている。システムは、信頼できる送信者の署名パターンに関する履歴を提示する。ユーザが、警告を閉じる必要があるために次第にイラつくことがなく警告（図１５Ａ）を読むことができるように、システムは、短い遅延の後にメッセージを提示する。ユーザが、「ＩＤに個人的に尋ねる」リンクをクリックすると、リンクは、（もし可能又は所望ならば）署名された随意に暗号化されたメッセージをシステムに作成させる。
【０１０１】
図１５Ａは、未署名メッセージ攻撃として知られる部類の攻撃において選択された指標及び要求を例示している。このような攻撃では、攻撃者は、捏造したＦｒｏｍ：アドレスで、ただしデジタル署名を伴わずに、メッセージを送信する。
【０１０２】
ＲＦＣ２８２２Ｅメールの場合は、Ｆｒｏｍアドレスは、Ｍａｉｌｂｏｘのリストを含み、各Ｍａｉｌｂｏｘは、Ｅメールアドレス（アドレス指定）と随意の表示名とによって定められる。文字的に捏造されたＦｒｏｍ：アドレス（例えばアドレス指定）は、たとえ随意の表示名が消されている又は表示されていない場合でも、メッセージが上記アドレスに似た指標（個人名又は商標など）を有する人物から本当に送信されたものだと受信者に
信じ込ませることを意図していると考えられる。更に、Ｆｒｏｍ：アドレスは、「ｌｉｚｃａｒｌｓｏｎ＠ｇｍａｉｌ．ｃｏｍ．」のように、文字的には正確であるにもかかわらず、虚偽であることがある。この攻撃は、メッセージのコンテンツが送信者を示している場合に更に受信者を混乱させるであろう。最後に、Ｆｒｏｍ：アドレスは、攻撃者が送信者のアカウントへのアクセスを得たゆえに、又は攻撃者が、送信者が任意の時点で使用しているメールプロバイダの内部ネットワークを破ったゆえに（したがって、メッセージは、ＳＰＦ又はＤＮＳのように様々な記録にしたがって既知のメールサーバから発しているので中継メールサーバを混乱させる）、文字的に正確であることがある。
【０１０３】
図１５Ａにおいて、システムは、署名メッセージ攻撃を検出した結果としての指標を計算する。随意には、指標は、攻撃の性質を具体的に示している、すなわち、署名の不在は、送信者の行動の側面をもとに結論付けられる送信者のＩＤの確証となる。行動とは、特定の指標に関連付けられたときに、有効なデジタル署名の存在及び具体的には特定の鍵をもとにしたデジタル署名の存在をシステムが予期することである。この行動の側面は、図１３〜１４及びこれまでの説明において例示されるように、指標「Ｂａｎｋ  ｏｆ  Ａｍｅｒｉｃａ」で表される主体がメッセージに署名するときにその主体が常に特定の鍵を使用して署名するという行動証明と同様である。
【０１０４】
行動的側面は、信頼履歴における様々な証明及び結論をもとに結論付けることができる。一実施形態において、行動は、図１５Ａの上部（「通常は…を送信する」）に示されるように、送信者のパターン及び行為をもとに把握される。別の実施形態では、主体は、その指標の特定部分（図１５Ａの下部に示されるように、Ｅメールアドレス指定「ｎｅｗｓ＠ｂｏｆａ．ｃｏｍ」又は名称「Ｂａｎｋ  ｏｆ  Ａｍｅｒｉｃａ」のいずれかの部分）が常に添付のデジタル署名情報を伴うという証明に自身で署名してよく、このような情報は、署名メッセージのＰＫＣＳ＃７構造若しくはＣＭＳ構造の符号付き属性内などに、メッセージの一部として入れられてよい、又はＭＩＭＥコンテンツヘッダフィールドのように、署名されたフィールド値として提供することができる。或いは、値は、メッセージ、すなわち文字テキスト「I, Bank of America, declare that all messages from news@bofa.com or purporting to be Bank of America shall be digitally signed.（私、Ｂａｎｋ  ｏｆ  Ａｍｅｒｉｃａは、ｎｅｗｓ＠ｂｏｆａ．ｃｏｍ、又はＢａｎｋ  ｏｆ  Ａｍｅｒｉｃａと称するところからの全てのメッセージがデジタル署名されていることを宣言する。）」から、「ページスクレーピング」技術を通じて直接に抽出されてよい。
【０１０５】
更なる実施形態において、ＣＡなどの証明者は、この行動的宣言を、Ｘ．５０９デジタル証明書のデータ構造内などに、送信者に関する全体的証明の一部として挿入する。ＣＡは、この行動的宣言を、送信者及びメッセージの特定の役割及び部類を基準にして挿入してよく、このような役割及び部類については、後ほど詳述される。本実施形態の特徴は、特定の指標に関連付けられたメッセージが署名されていることを常に予期する行動などの特定の行動的特性を証明することにある。行動に関する証明を送信メッセージごとに異ならせないことによって、このような特徴は、ユーザの利益のために、送信者の行動を制約する働きをする傾向がある。このため、プライバシー又は真正性を懸念しているユーザは、署名されていないメッセージ又は様々な種類の信憑できない証明を伴うメッセージの紛らわしい表示を容易に阻止することができる。
【０１０６】
このようないずれの場合も、システムの実施形態は、これらの宣言を、システムのポリシーの一部とみなし、後ほど更に説明されるように、指標及びメッセージのコンテンツを基準にして報償及び制裁を加えることができる。システムの実施形態は、これらの宣言を、（図３に示されるように）初期信頼関係の一部として把握し、履歴を適切に「プリシード」してよい。更に、システムの実施形態は、例えばシステムを開始させる最初の段階でリモートサーバにアクセスする、宣言をダウンロードするなどの、当該分野において知ら
れた様々な方法を通じて適切な時刻にこれらの宣言を取得してよい。
【０１０７】
システム１００は、ノンスを含む図１５Ｂと同様のテキストを自動的に含むことができる。コードを含む第１の応答を受信すると、システム１００は、図１５Ｃのような指標を提示する。にもかかわらず、もし応答が非常に古い場合は、システム１００は、第三者による（例えば他者のメールボックスに侵入することによる）割り込みのリスクが高まるゆえに応答の信頼性が下がったかもしれないことを示す指標を提示することができる。システム１００は、コードが再生又はそれ以外の形で再利用されないように、ユーザの応答と、コードと、第１の応答との間のこの関連性を記憶することができる。
【０１０８】
更に、システムの特徴は、特徴的な注釈の使用を通じて、そうでなければ同じ指標を伴う送信者をユーザが見分けられることにある。注釈は、例えば、色、音、ニックネーム、写真、テキスト、又は図１５Ｂに示されるように（技術系ユーザ用の）鍵情報の表示を含む。衝突が発生すると、システム１００は、図１６に示されるように、２つのユーザを区別する機会をユーザに提示することができる。
【０１０９】
更なる実施形態において、システムは、たとえＣＡがこのような更新を提供しない場合でも、脅威又はユーザ認識の変化に応答してそのユーザインターフェースを迅速に再構成することができる。鍵の破棄は、信頼関係を変えるように他者に指示するための、当該分野において知られた方法である。ＣＡは、証明書破棄リスト及びオンライン証明書状態プロトコルサーバを提供する。それにもかかわらず、システム１００は、たとえＣＡがこのような変化を、技術的ルートを通じて直接報告しない場合でも、ユーザインターフェースを変更するコード更新又は特定の指標を計算するためのアルゴリズムを周期的にダウンロードしてよい。例えば、システムの管理者は、ＣＡの証明書ポリシー規定が変更された旨の知らせを受信してよく、次いで、変更後の規定の根底にある実際の信頼関係を反映するためにユーザインターフェースを更新する。
【０１１０】
上記に例示されたようなシステムによってブートストラップされるとともに展開される信頼関係に鑑みると、実施形態の更なる特徴は、異なるセキュリティプロフィール及びセキュリティリスクを有する異なるタイプのメッセージ送信者同士を区別することにある。このようなプロフィール及びリスクは、２つの部類のメッセージ、すなわち大量マーケティングメッセージ（「マーケティングＥメール」）及びトランザクションメッセージ（「トランザクションＥメール」）において、とりわけ明白である。マーケティングメッセージは、ニュースレター、及び通常はバルクメールの対象であるその他の内容を含む。トランザクションメッセージは、未決取引についての状態更新として送信され、このようなメッセージは、送り状、出荷の知らせ、配達（又はｅ−ｄｅｌｉｖｅｒｙ）の確認、及び銀行取引明細の更新を含む。いずれの部類のメッセージも、直接的な応答を求めることは滅多になく、むしろ、（商品を購入する又は注文の状態をチェックするなどの）行為をユーザに促す。これらの両タイプのメッセージに似た不正な又は不要なメッセージは、「スパム」又は「フィッシングスキーム」として一般に知られている。
【０１１１】
Ｇｏｏｄｍａｉｌと呼ばれるシステムが、図１７Ａ〜Ｂに示されている。図に示されるように、Ｇｏｏｄｍａｉｌシステムでは、メッセージは、特別な青色リボン封筒のアイコンを伴って表示され、そのＥメールメッセージが検証済みの送信者から来ており真正であることを消費者に知らせる。
【０１１２】
しかしながら、本発明の一実施形態において、システムは、システムの把握の方法にしたがって、デジタル証明書内の指標を検出する。システム１００は、このような指標を、例えば、送信者の役割又は部類と、送信者が送信する可能性が高いメッセージの部類とに関する情報をもとに計算する。システム１００は、更に、送信者の役割又はタイプに関連
した認証を行うＣＡの能力範囲内の情報をもとに、このような指標を計算する。ＣＡは、このような情報を、例えば図１８に示されるようなこの情報を含むデジタル証明書として発行することができる。
【０１１３】
次に具体例を見ると、図１８に示されるようなデジタル証明書は、ＣＡによって署名された情報を有する。Ｘ．５０９デジタル証明書標準を使用すると、役割ベースの情報は、識別名（ＤＮ）の要素として、又は拡張内のデータとして示される。情報は、ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｎｄｉｃａｔｏｒｓ）、ＵＲＬステム、及びこのようなＵＲＬステムの個別化に関連した署名メッセージ内のフィールドの識別を含む。図１８に提示されたデータを使用して、システムは、「役割特有の情報」に提示されたＯＩＤ値を再利用することによって、適切なメッセージごとのフィールドを決定することができる。
【０１１４】
マーケティングの場合、対応するデジタル証明書は、（Ａ）「プロフィールの更新／編集」及び（Ｂ）「登録解除」のためのＵＲＬステムを提供する。デジタル証明書は、（Ｃ）「プライバシーポリシーの閲覧」のための完全ＵＲＬを提供する。個別化値は、署名メッセージのＰＫＣＳ＃７構造若しくはＣＭＳ構造の符号付き属性内のように、メッセージごとの単位で提供することができる、又はＭＩＭＥコンテンツヘッダフィールドのように、署名されたフィールド値として提供することができる。或いは、値は、「ページスクレーピング」技術を通じてメッセージから直接に抽出されてよい。
【０１１５】
トランザクションの場合、対応するデジタル証明書は、（Ａ）「アカウントの更新」）及び（Ｂ）「トランザクション（又は注文）の追跡」のために用意されたＵＲＬステムを提供する。デジタル証明書は、（Ｃ）「プライバシーポリシーの閲覧」のための完全ＵＲＬを提供する。個別化値は、署名メッセージのＰＫＣＳ＃７構造若しくはＣＭＳ構造の符号付き属性内のように、メッセージごとの単位で提供することができる、又はＭＩＭＥコンテンツヘッダフィールドのように、署名されたフィールド値として提供することができる。或いは、値は、「ページスクレーピング」技術を通じてメッセージから直接に抽出されてよい。
【０１１６】
上記に言及された個別化値は、メッセージのＩＤ及び状態を追跡するためにマーケティング又はトランザクションのシステムが使用する値を含む。当該分野において知られているＥメールマーケティングシステムでは、このような個別化値は、特定のメッセージと、特定の受信者と、メッセージがどのサーバから来ているかなどのメッセージの伝送に関する関連の内部パフォーマンス特性とを識別する。これらの個別化値は、悪意ある受信者が、例えばユーザＩＤを操作して別のユーザのプロフィールを取り出すなどによって成りすまし攻撃をすることのないように、難読化（例えばハッシュ化又は暗号化）されてよい。
【０１１７】
当該分野において知られている特定のＥメールでは、これらの個別化値は、ユーザが登録解除などの動作を実施するためにたどる完全ＵＲＬに組み込まれる。このようなＵＲＬは、マーケティングプロバイダ又はＥメール配信会社によってまるごと提供されることが多く、移行中に改変されないことを想定している。したがって、ＵＲＬの有効性は、送信者又はＥメール配信会社にもっぱら依存しており、ユーザは、このようなＵＲＬを信頼しなければならない。
【０１１８】
攻撃者が送信者の秘密鍵を侵害すると、その攻撃者は、ユーザを詐欺又は更にひどいものに迂回させるリンクを含む一見正当な大量Ｅメールを送信することができる。本実施形態の特徴は、ＣＡが特定のＵＲＬ及びＵＲＬステムを、このような値を発行デジタル証明書内に配することによって証明することにあり、一方で、メッセージごとの情報は、メッセージの署名者によって（暗に）証明されたメッセージ内に配される。システムは、作成
されたＵＲＬから個別化情報を除外する更なる選択肢を提示することができる。したがって、プライバシーを懸念するユーザは、システムがこのような相関情報をＵＲＬの宛先に伝えることを容易に阻止することができる。図１９は、上述の特徴についての指標の例を示している。本発明の更なる特徴は、もし攻撃者が、上述のような技術を使用してこのようなマーケティングメッセージ又はトランザクションメッセージを攻撃しようとした場合に、システム１００が、その攻撃を検出できることにある。
【０１１９】
代替の実施形態において、メッセージが証明書の更新を含む場合は、システムは、新しい証明書の新しいＵＲＬパターンの代わりに、既に信頼を得ている証明書内のＵＲＬパターンをユーザに提示する。更に、メッセージを正当でないと疑う理由を見つけた場合は、システム１００は、それでもなお、有効なＵＲＬをユーザに提示することができるが、疑わしいメッセージから得られた個別化値をサブミットする選択肢を排除する。
【０１２０】
メッセージを閲覧した後（そして随意として信頼関係を確立した後）に、ユーザは、送信者からのメッセージを欲するかどうかについて、気が変わることがある。図２０が示すように、現存の一部の実装形態では、「スパム報告」（「これはスパムである」としても知られる）ボタンは、ユーザがメッセージをスパムとして識別することを可能にする。「スパム」は、マーケティング業者の視点からすると、「未承諾商業用Ｅメール」を意味するが、ユーザの視点からすると、たとえこれまでは欲していたとしても、「不要なＥメール全て」を意味することがある。
【０１２１】
次に、図２１について、ユーザがこれまでに信頼関係を有していた場合のメッセージ（マーケティングＥメールが具体例になる）に対し、システム１００は、ユーザに、なぜユーザがもうこれ以上はメッセージ又は送信者を望ましいとしないかを確認するように指示する。上述のように、システム１００は、信頼関係の変化を追跡することができるので、それらの変化の時刻（「昨日」、「先週」、又は「２００７年１０月１７日以来」）をユーザに突き付けることができる。図２１は、システムからのプロンプトと、考えられるユーザ応答とを提示している。「終了」は、対話の終了を告げるものであり、その後、システムは、適宜、信頼関係を変更すること又はユーザ要求を請け負うことに進む。
【０１２２】
当該分野において知られているＥメールは、表向きの送信者の制御外のコンテンツを含む、任意のリソースへの参照を含むことができる。代表的な実施形態において、本システムは、画像及びリンクなどの被参照コンテンツに対して同一出所ポリシーを強いる。ＣＡが（ブートストラップされた信頼関係を通じて）又はユーザが（発展している信頼関係を通じて）、自身が送信者のアドレスを検証したことを証明した場合は、その検証者は、ドメイン名などのアドレス下位部分が信頼できることを暗に承認したことになる。検証者は、このような保証を、上述された方法を通じて明確にすることができる。とりわけ、検証者は、特定のＵＲＬステム又はパターンが信憑できるリソースにつながることを証明する。検証者は、ＵＲＬが個別化情報を悪質な第三者に漏らさないという更なる保証をすることができ、これは、ｈｔｔｐｓなどのセキュアなＵＲＬの使用を示唆している。随意として、検証者は、このようなドメイン名に関連付けられた検証済みのＩＰアドレスを提供して更なる保証をすることによって、もし画像又はリンクがアクセスされた時点でＤＮＳキャッシュが侵害された場合にＤＮＳキャッシュ攻撃を阻止する。これらの証明は、役割（「マーケティングメッセージ」）ごとに、そして実際は送信者ごとに、差別化されてよい。したがって、システムは、検証済み送信者を、（Ａ）同じ出所からの画像をロードするように、そして（Ｂ）同じ出所へのリンクを参照するように制限する。
【０１２３】
システムは、このポリシーを守る送信者に報償を与えるか、又はこのポリシーを破る送信者に罰を与えるかしてよい。報償の一例は、ユーザが画像を見る又はリンクをクリックする心配がないように、メッセージがポリシーに適合していることをチェックマーク又は
その他のプラス指標で示すことである。罰の例としては、ポリシーに背くリンクをたどる前にユーザに不吉な警告メッセージを提示すること、ポリシーに背くこのようなリンクを全て表示メッセージから取り除くこと、及びポリシーに背くこのようなリンクを全て指標内に列挙することが挙げられる。通常、システム１００は、メッセージが属している役割又は部類についてのポリシーにしたがってメッセージ及び指標を変更してよく、これは、メッセージの表示を完全に保留することを含む。システムは、沈黙を保ってもよい。
【０１２４】
上記の議論を考慮して、更なる実施形態は、ユーザのネットワークアドレス（ＩＰアドレスなど）より他は何も伝えることなく画像がロードされることを可能にする。画像又はその他のインラインに読み込まれたリソース（「画像」）の場合は、ＣＡ（又は総じて検証者）は、画像用の検証済みの部分的ＵＲＬステムを指定してよい。しかしながら、画像をロードするときに、システムは、更に、ＨＴＭＬメッセージ内の画像参照を、１．ｊｐｇ、２．ｊｐｇ、．．．．．．、９．ｊｐｇなどの所定の単調な値の小セットに制限する。システムは、これらの画像を、どの特定の組み合わせがメッセージ内に現れるかにかかわらず、常にロードする。もしメッセージ内に画像がない場合は、システムは、どの画像もロードせずに済ますことができる。もし送信者が、送信者のメッセージが何枚の画像をロードするかを選別及び選択することを許可された場合は、被参照サーバは、ロードされる具体的画像を異なるヴァリエーションのメッセージと関連付けることができる。したがって、最大限のセキュリティのために、システムは、ロードされるリソースに関してバイナリ情報のみを公開する、すなわち全てのリソースか又はリソースなしかのいずれかを公開する。別のヴァリエーションは、２つの部類のリソース、すなわち、送信者のメッセージに含ませようとする動機を送信者が常に有しているような、送信者に対して常に要求される画像（送信者の企業ロゴなど）と、もし存在するのであれば、上記ルールにしたがう「その他の全ての画像」とを許容する。当業者ならば明らかなように、たとえ受信者又はユーザコンピュータのネットワークアドレスでも、混合ネットワーク（Ｔｏｒなど）、ファイヤウォール、又はプロキシを通じて隠すことができる。
【０１２５】
しかしながら、送信者は、そのデジタル証明書の寿命の間に多くのメッセージを送出する可能性が高い。したがって、システムは、ＵＲＬステム及び所定の画像名を、メッセージの部類を固有に識別するが特定のユーザに対する相関付け情報をほとんど持たないトークンと組み合わせる。メッセージの個別化値は、例えば、速記的技術を使用して隠されるゆえにシステムが効果的に把握する（そして排除する）ことができない相関付け情報を十分に含んでいてよい。相関耐性トークンの例には、（Ａ）ユーザのメッセージングサービスにしたがったメッセージの受信日（例えば日にちに切り捨てされた時刻）と、（Ｂ）第三者ＴＳＡによって生成されたタイムスタンプにしたがったメッセージの日付（例えば日にちに切り捨てされた時刻）、又は送信者が制御できない上記に例示されたようなその他の値とがある。送信者が毎日ｎ件のメッセージを送信すると仮定すると、送信者は、特定の受信者がそのメッセージ内の画像をダウンロードしたか（及びしたがってメッセージを開封したか）をｎ分の１を超える確実性で言うことができない。更に、送信者は、受信者のバルクリストを、追跡目的で、異なる部類のユーザへのメッセージの配信を幾日かに分けてずらす程度にしか分割することができない。システムは、タイムゾーンに依存する受信日を、タイムゾーン情報を用いずにトークンとして処理することによって、日付に対して意図的な不確実性を加えてもよい。このような不確実性は、送信者が真夜中の直前及び直後の送信によってリストを２つの部類に分割することを思いとどまらせる。したがって、以上の実施形態では、システムは、ユーザのプライバシーをほぼ全て守りつつ、送信者が「開封率」について及び非常に限られた受信者の下位分類について学習することを可能にする。
【０１２６】
上記の様々な代替形態を考慮して、代表的な実施形態は、以下のポリシーを定めるとともに以下の指標を提示する。（Ａ）個人などの一般送信者に対して：全ての画像及びリン
クが同一出所ポリシーにしたがっているメッセージには、チェックマーク及び肯定文を提供する。異なる出所につながる画像又はリンクには、いかなる指標も提供しないが、もしユーザが通常の経路でリンクをたどろうと試みた場合は、適切なアルゴリズムを通じてホモグラフ攻撃についてユーザに警告する。本実施形態の特徴は、友人から友人へと送信される面白いウェブペースのリンクなどの、知人間で送信されるリンクが、単に同一出所ポリシーに反するというだけで危険なものとしてフラグ付けされることはないことにある。（Ｂ）マーケティングメッセージ及びトランザクションメッセージに対して：全ての画像及びリンクが同一出所ポリシーにしたがっているメッセージには、チェックマーク及び肯定文を提供する。同一出所ポリシー及び相関耐性ポリシーにしたがっている画像を自動的にロードする。もし任意のリンク又は画像が同一出所ポリシーにしたがっていない場合は、不吉な警告を提供する。本実施形態の特徴は、マーケティング業者及びトランザクション業者（「送信者」）が、署名メッセージを送信することに対して、プロフィール／アカウントの変更、登録解除／追跡、及び役割証明書に本来備わっているプライバシーポリシーリンクに加えて、コンテンツを中心とした何らかの付加的な利益を受けることにある。本発明の別の特徴は、送信者が「コピー」（すなわちメッセージの書式設定又はコンテンツ）に制約されないことにある。本発明の別の特徴は、送信者に対する利益がユーザのプライバシーを実質的に損なわないことにある。
【０１２７】
システムポリシーの順守は、システムが自動的に画像をロードすることを必ずしも意味しない。したがって、上記のポリシーの例では、ユーザは、新しい送信者からの画像及びリンクが「安全」であることを知っているが、それでもなお、メッセージのテキストコンテンツ及び一般的レイアウトを見た後に、画像をロードするかを肯定的に選択する。ユーザは、「信頼する」と示すことに不快を感じないときには、全ての画像が自動的にロードされるように指定することができる。システムによって作成される指標の例が、図２２Ａ〜Ｂに示されている。
【０１２８】
詳述及び例は、単なる例示と見なされることを意図している。例えば、システムは、特権的ソフトウェアとして一コンピュータ上に構築されてよい、複数のコンピュータに分散されてよい、又はサーバ上で動作してユーザインターフェースをユーザのクライアントコンピュータに伝送されるとともに提示されてよい。ウェブメールサーバ又は任意の個別のソフトウェアは、これらの機能を全て実施して、情報バー及び縁取りボックスなどの適切なインターフェース要素をユーザに提示することができる。ウェブメールの実施形態について、一解決策は、「ホットメール及びＡＯＬなどのウェブメールプロバイダは、それらのシステム内においてＳ／ＭＩＭＥを直接サポートするように動作することが望ましい」こと、並びに「次のステップは、ウェブメールプロバイダがそれらの顧客に代わってＳ／ＭＩＭＥ証明書を取得し、それらの証明書を使用して全ての発送メールに自動的に署名するためのものである」ことを挙げている。
【０１２９】
本システムの特徴は、ユーザがユーザコンピュータと異なる形でメッセージングサービスを信頼するような場合に構築及び使用できることである。例えば、ウェブメールサーバは、署名及び暗号化を経たユーザのＥメールにアクセスすることができるが、ユーザの秘密鍵がないと、メッセージを捏造することも復号することもできない。しかしながら、ウェブメールサーバは、（Ａ）ユーザがウェブブラウザ内において作成しているものを密かに読む悪質なコード、（Ｂ）ウェブブラウザ内の復号化されたメッセージを密かに中継してサーバに戻す悪質なコード、（Ｃ）メッセージの信頼性を偽って示す（又はウェブメールプロバイダ若しくはメッセージ送信者に有利になるようにメッセージの信頼性を歪曲する）悪質なコード、或いは（Ｄ）暗号化されたメッセージのコンテンツを偽って提示する悪質なコードを送信する可能性があるので、ウェブメールサーバによって提供される（すなわちユーザコンピュータ上のウェブブラウザの内部の）任意のコードは、信頼できないことがある。
【０１３０】
たとえ悪質なウェブメールサーバオペレータが存在しない場合でも、ウェブメールサーバは、監視される又はそれ以外の形で侵害される可能性がある。したがって、別の実施形態では、ブラウザは、システムの一部を統合した拡張を含む。拡張は、ブラウザの行動を変更する１つのソフトウェアであり、このような技術の例には、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ用の「Ｂｒｏｗｓｅｒ  Ｈｅｌｐｅｒ  Ｏｂｊｅｃｔｓ」及びＭｏｚｉｌｌａ  Ｆｉｒｅｆｏｘ用の「Ｅｘｔｅｎｓｉｏｎｓ」がある。
【０１３１】
拡張は、あらゆる必要な暗号化、復号化、署名、及び検証の手順を仲介する。拡張は、セキュアでない行動についてウェブメールサーバからの非特権的コードを監視し、上述されたシステムインターフェース要素の幾つかを提供してよい。もし何らかの初期設定が、ウェブメールサーバ上などに非局所的に格納されているならば、拡張は、改ざんを阻止するため及び随意として機密性を保証するために、このような初期設定に対して署名及び随意の暗号化を行う。したがって、読者は、説明された少なくとも１つの実施形態が、ユーザと、メッセージングサービスと、メッセージの送信者との間の信頼関係をブートストラップ（自ら構築）する及び追跡することがわかった。また、本発明の実施形態は、ＤＫＩＭ、ＰＧＰなどの異なる標準にまたがって指標を計算する及び異なる標準を活用することが可能である。例えば、ＤＫＩＭは、ＤＫＩＭ署名者の鍵を通じて把握されるような、メッセージの中継者に関する情報を決定するために、実施形態において使用することができる。指標は、ＰＧＰ構造をもとに計算することができる。異なる標準から収集された情報は、（空間的に及び時間的に）別々に又は同時に提示されてよい。本発明の真の範囲及び趣旨は、以下の特許請求の範囲によって示される。
【図１】
2011501578.tif 000003
【図２Ａ】
2011501578.tif 000004
【図２Ｂ】
2011501578.tif 000005
【図３】
2011501578.tif 000006
【図４】
2011501578.tif 000007
【図５Ａ】
2011501578.tif 000008
【図５Ｂ】
2011501578.tif 000009
【図５Ｃ】
2011501578.tif 000010
【図５Ｄ】
2011501578.tif 000011
【図５Ｅ】
2011501578.tif 000012
【図５Ｆ】
2011501578.tif 000013
【図６Ａ】
2011501578.tif 000014
【図６Ｂ】
2011501578.tif 000015
【図７Ａ】
2011501578.tif 000016
【図７Ｂ】
2011501578.tif 000017
【図７Ｃ】
2011501578.tif 000018
【図８】
2011501578.tif 000019
【図９Ａ】
2011501578.tif 000020
【図９Ｂ】
2011501578.tif 000021
【図１０Ａ】
2011501578.tif 000022
【図１０Ｂ】
2011501578.tif 000023
【図１０Ｃ】
2011501578.tif 000024
【図１１】
2011501578.tif 000025
【図１２】
2011501578.tif 000026
【図１３】
2011501578.tif 000027
【図１４】
2011501578.tif 000028
【図１５Ａ】
2011501578.tif 000029
【図１５Ｂ】
2011501578.tif 000030
【図１５Ｃ】
2011501578.tif 000031
【図１５Ｄ】
2011501578.tif 000032
【図１６Ａ】
2011501578.tif 000033
【図１６Ｂ】
2011501578.tif 000034
【図１７Ａ−１】
2011501578.tif 000035
【図１７Ａ−２】
2011501578.tif 000036
【図１７Ｂ】
2011501578.tif 000037
【図１８】
2011501578.tif 000038
【図１９】
2011501578.tif 000039
【図２０】
2011501578.tif 000040
【図２１】
2011501578.tif 000041
【図２２Ａ】
2011501578.tif 000042
【図２２Ｂ】
2011501578.tif 000043
【国際調査報告】
2011501578.tif 000044
2011501578.tif 000045