(57)【要約】本発明により、ユーザは、セキュアで透過的な電子的通信が提供され、暗号化または署名したメッセージの送受信をユーザの関与なしに行えるようになる。またユーザへの電子メールセキュリティの提供が、セキュアなメッセージの透過的な送受信のための自動化された階層的技法によって行われ、管理者に対する負荷が低減される。本発明は、ユーザと開放型通信ネットワークの間のプロキシとして働くローカルネットワーク内のサーバを含み、これにより、ユーザのためにセキュアなメッセージの透過的な送受信を提供することができる。これは、セキュアなメール送受信のために、またはインスタントメッセージング（ＩＭ）をセキュア化するために使用できる。本発明によるサーバは、アンセキュアなメッセージをユーザから傍受し、かかるメッセージを自動的に変換してセキュアなメッセージにし、そのセキュアなメッセージを意図する受信者へと送信することができる。
2006518949.tif 000002
【特許請求の範囲】
【請求項１】
ローカルネットワーク内の第１のサーバを、開放型通信ネットワークとユーザの間のプロキシとして提供するステップと、
前記開放型通信ネットワークまたは前記ユーザに振り向けられたメッセージを、前記第１のサーバで傍受するステップと、
前記メッセージを、前記メッセージ内部に含まれる徴表に従って処理して、前記開放型通信ネットワークを介するセキュアなメッセージの透過的な送受信を提供するステップと
を含む方法。
【請求項２】
１つまたは複数のメッセージを前記ローカルネットワーク内の第２のサーバ上に保存するステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記メッセージが、電子メールメッセージをさらに含む、請求項１に記載の方法。
【請求項４】
前記メッセージが、インスタントメッセージをさらに含む、請求項１に記載の方法。
【請求項５】
前記処理が、
前記ユーザに対する前記第１のサーバ内部の複数の暗号鍵を管理するステップと、
必要な場合には、前記ユーザに対する１つまたは複数の暗号鍵を作成するステップと、
前記ユーザからのアンセキュアなメッセージを受け取ると、前記アンセキュアなメッセージをセキュア化するステップと、
前記ユーザに対するセキュアなメッセージを受け取ると、前記メッセージをアンセキュア化するステップと
をさらに含む、請求項１に記載の方法。
【請求項６】
前記セキュア化するステップが、前記アンセキュアなメッセージを暗号化するステップをさらに含む、請求項５に記載の方法。
【請求項７】
前記アンセキュア化するステップが、前記セキュアなメッセージを復号するステップをさらに含む、請求項５に記載の方法。
【請求項８】
送信者からのアンセキュアなメッセージを傍受するステップと、
前記アンセキュアなメッセージを自動的に変換して受信者に対するセキュアなメッセージにするステップと、
前記セキュアなメッセージを前記受信者に送信するステップと
を含む方法。
【請求項９】
前記アンセキュアなメッセージが、電子メールメッセージをさらに含む、請求項８に記載のシステム。
【請求項１０】
前記送信するステップが、前記セキュアなメッセージを第２のサーバを介して送るステップを含む、請求項８に記載のシステム。
【請求項１１】
セキュアなメッセージを透過的に受け取る方法であって、
送信者からのセキュアなメッセージを傍受するステップと、
前記メッセージを自動的にアンセキュア化して、アンセキュアなメッセージを作成するステップと、
前記アンセキュアなメッセージが、それに関連付けられている電子署名を有するとき、前記セキュアなメッセージの前記送信者に対応するデジタル識別を検索するステップと、
前記アンセキュアなメッセージに関連付けられているどの電子署名も前記デジタル識別を用いて検証するステップと、
前記アンセキュアなメッセージを受信者へと送信するステップと
を含む方法。
【請求項１２】
開放型通信ネットワークとユーザの間のプロキシとして働く、ローカルネットワーク内の第１のサーバと、
１つまたは複数のメッセージを保存する、前記ローカルネットワーク内の第２のサーバと、
前記メッセージの暗号化および復号を自動的に行って、前記開放型通信ネットワークを介するセキュアなメッセージの透過的な送受信を提供するための暗号モジュールと
を備えるシステム。
【請求項１３】
セキュアなメッセージを透過的に送信するためのシステムであって、
送信者からのアンセキュアなメッセージを傍受するためのメッセージ受信モジュールと、
前記アンセキュアなメッセージを自動的に変換して受信者に対するセキュアなメッセージにするための暗号モジュールと、
前記セキュアなメッセージを前記受信者に送信するためのメッセージ送信モジュールと
を備えるシステム。
【請求項１４】
セキュアなメッセージを透過的に受信するためのシステムであって、
送信者からのセキュアなメッセージを傍受するためのメッセージ受信モジュールと、
前記アンセキュアなメッセージがそれに関連付けられている電子署名を有するとき、前記セキュアなメッセージの前記送信者に対応するデジタル識別を検索する証明書検索モジュールと、
前記メッセージをアンセキュア化してアンセキュアなメッセージを作成し、前記アンセキュアなメッセージに関連付けられているどの電子署名も前記デジタル識別を用いて検証する暗号モジュールと、
前記アンセキュアなメッセージを受信者に送信するためのメッセージ送信モジュールと
を備えるシステム。
【請求項１５】
セキュアなメッセージの透過的な送受信を開放型通信ネットワークを介して行うためのコンピュータプログラム命令を含むコンピュータ可読媒体であって、
前記開放型通信ネットワークと前記ユーザの間のプロキシとして働くこと、
前記開放型通信ネットワークまたは前記ユーザに向けられたメッセージを傍受すること、および
前記メッセージを、前記メッセージ内部に含まれる徴表に従って処理して、前記開放型通信ネットワークを介するセキュアなメッセージの透過的な送受信を提供すること
のための命令を含む、コンピュータ可読媒体。
【請求項１６】
受信者へのセキュアなメッセージの透過的な送信を開放型通信ネットワークを介して行うためのコンピュータプログラム命令を含むコンピュータ可読媒体であって、
送信者からのアンセキュアなメッセージを傍受すること、
前記アンセキュアなメッセージを自動的に変換して受信者に対するセキュアなメッセージにすること、および
前記セキュアなメッセージを前記受信者に送信すること
のための命令を含む、コンピュータ可読媒体。
【請求項１７】
受信者に対するセキュアなメッセージの透過的な受信を開放型通信ネットワークを介して行うためのコンピュータプログラム命令を含むコンピュータ可読媒体であって、
送信者からのセキュアなメッセージを傍受すること、
前記メッセージを自動的にアンセキュア化して、アンセキュアなメッセージを作成すること、
前記アンセキュアなメッセージが、それに関連付けられている電子署名を有するとき、前記セキュアなメッセージの前記送信者に対応するデジタル識別を検索すること、
前記アンセキュアなメッセージに関連付けられているどの電子署名も前記デジタル識別を用いて検証すること、および
前記アンセキュアなメッセージを受信者へと送信すること
のための命令を含む、コンピュータ可読媒体。
【請求項１８】
セキュアなメッセージを透過的に送信するための方法であって、
送信者からのアンセキュアなメッセージを傍受するステップと、
前記アンセキュアなメッセージを第１のサーバ上に保存するステップと、
前記アンセキュアなメッセージを前記第１のサーバから第２のサーバへとローカルネットワーク内で送信するステップと、
前記アンセキュアなメッセージを自動的に変換して受信者に対するセキュアなメッセージにするステップと、
前記セキュアなメッセージを前記受信者に送信するステップと
を含む方法。
【請求項１９】
セキュアなメッセージを透過的に受信するための方法であって、
送信者からのセキュアなメッセージを傍受すること、
前記メッセージを自動的にアンセキュア化して、アンセキュアなメッセージを作成すること、
前記アンセキュアなメッセージをローカルネットワーク内に保存すること、
前記アンセキュアなメッセージが、それに関連付けられている電子署名を有するとき、前記セキュアなメッセージの前記送信者に対応するデジタル識別を検索すること、
前記アンセキュアなメッセージに関連付けられているどの電子署名も前記デジタル識別を用いて検証すること、および
前記アンセキュアなメッセージを受信者へと送信すること
のための命令を含む、方法。
【発明の詳細な説明】
【発明の分野】
【０００１】
この発明は、一般には、コンピュータネットワーク内の電子的メッセージをセキュア化（安全確保処理）することに関する。より詳細には、この発明は、コンピュータネットワーク内でユーザ間のセキュアで（安全で或いは保証された）透過的な電子的通信を提供する技法に関する。
【発明の背景】
【０００２】
暗号化は、暗号化鍵を使用して、電子的メッセージの内容（すなわち、平文）をスクランブルし、これを対応する鍵の保持者（すなわち、意図する受信者）以外の誰にも判読不能にするプロセスであり、その結果は理解不能なメッセージ（すなわち、暗号文）となる。復号は、暗号文を変換して平文に戻すことによって暗号化プロセスを反転させ、それにより、元のメッセージを復元する。暗号化および復号を使用すると、メッセージのセキュリティを提供することができる。メッセージのセキュリティ、特に電子メール（ｅｌｅｃｔｒｏｎｉｃ  ｍａｉｌ（ｅ−ｍａｉｌ））の暗号化および復号は、インターネットのユーザの間で比較的低い率でしか採用されてきていない。インターネットなどの開放型の（ｏｐｅｎ）ネットワークを介して伝送されるメッセージがあからさまに（ｐｌａｉｎｌｙ）判読可能であるであることを、多くのユーザは承知しているが、それでも、一般に、この問題を解決するために暗号化を使用してはいない。さらに、組織だった研究からエピソードめいた証言に至るまで、多くの人々が暗号化ソフトウェアを効果的に使用することに困難を経験しているようである。
【０００３】
図１に示すように、従来のセキュアな電子メールシステムは、ユーザコンピュータ１０２およびインターネット１０００などの開放型通信ネットワークと接続した電子メールサーバ１０６を含んでいる。メッセージの送信を、インターネット１０００を介して安全に行うために、ユーザは、普通、暗号化ソフトウェア１０４をユーザコンピュータ１０２上にインストールする。次いで、ユーザは、通常、暗号化ソフトウェア１０４での様々な設定を、鍵長（ｋｅｙ  ｌｅｎｇｔｈ）、アルゴリズム、パスワード、および他のセキュリティ関連パラメータなどの事柄を含めて、構成することが必要になる。
【０００４】
セキュアな電子的通信のアーキテクチャ上の中心となる目的は、暗号化をやさしく使えてユビキタスなものとすることである。しかし、セキュリティ専門家は、しばしば、セキュリティを「すべてかゼロか」（ａｌｌ−ｏｒ−ｎｏｔｈｉｎｇ）という視点で見てしまう。このことが、例えば、複雑なソフトウェア、使いにくいインターフェース、および低いパフォーマンスを招くことになっている。したがって、エンドユーザが暗号化ソフトウェアと対話する必要性の問題を多少とも解決する、セキュアで、透過的な電子的通信システムが必要とされている。
【発明の概要】
【０００５】
本発明により、セキュアで透過的な電子的通信が提供される。これにより、ユーザは、暗号化したおよび／または署名のあるメッセージの送受信を、ほとんどまたはまったくユーザの関与なしに行うことができるようになる。一実施形態では、セキュアで透過的な電子的通信により、エンドユーザ透過性（ｅｎｄ−ｕｓｅｒ  ｔｒａｎｓｐａｒｅｎｃｙ）が提供される。ユーザは、セキュリティの詳細を、つまり、例えば、あるセッションが暗号化されているということを、知る必要はない。その代わりに、セキュアで透過的な電子的通信の提供を、例えば、別個のサーバが行う。このため、セキュアで透過的な電子的通信により、一実施形態では、ユーザへの電子メールセキュリティの提供が、セキュアなメッセージの透過的な送受信のための自動化された階層的技法によって行われる。セキュアで透過的な電子的通信の第２の特徴は、これにより管理者に対する負荷が軽くなることである。その焦点は、多くのクライアント上よりも、比較的少数のサーバ上のソフトウェアセットアップに置かれている。また、管理者の視点からは、セキュアで透過的な電子的通信により、ＰＫＩ（ｐｕｂｌｉｃ  ｋｅｙ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、公開鍵基盤）を動的に構築し操作できるようになる。第３の特徴は、これにより、セキュリティの使用の容易さとのトレードオフの尺度が提供されることである。その最も洗練された形では、セキュアで透過的な電子的通信は、その全体がサーバ上で行われる暗号化である。セキュアで透過的な電子的通信は、クライアントベースの暗号化とフルに相互動作を行い、より強いセキュリティさえ、そのようなより高度なセキュリティを要求するユーザに対して提供する。さらに、これは、高度なデジタル証明書検索の提供を、暗号化の鍵および証明書をもたない可能性のあるユーザに対して行う。
【０００６】
本発明の一実施形態は、ユーザと開放型通信ネットワークの間のプロキシとして働く、ローカルネットワーク内のサーバを含み、そのサーバは、ローカルネットワーク内のユーザとの間のメッセージを傍受し、そうしたメッセージの変換をメッセージの内部に含まれるまたは関連する徴表を用いて行い、これにより、ユーザに対するセキュアなメッセージの透過的な送受信を提供する。例示的な一実施形態では、本発明によるシステムを使用すると、セキュアな電子メールの送受信を行えるはずである。別の実施形態では、そのようなシステムを使用すると、インスタントメッセージング（ｉｎｓｔａｎｔ  ｍｅｓｓａｇｉｎｇ、ＩＭ）をセキュア化することができるはずである。また別の実施形態では、そのようなシステムでは、ユーザに対する暗号鍵および証明書の管理、および、必要なときには、ユーザに対するそのような鍵および証明書の作成を行う。
【０００７】
本発明の別の態様によれば、ユーザからのアンセキュアなメッセージを、サーバで傍受し、セキュアなメッセージへと自動的に変換し、受信者へと送信する。別の実施形態では、メッセージのサーバによる自動的な変換を、受信者が、セキュアなメッセージを変換して判読可能なメッセージに（すなわち、暗号文から平文へと）戻すのに必要なソフトウェアをダウンロードし、デジタル識別をサーバに送った後で行う。
【０００８】
同様に、本発明の別の態様は、ユーザに対するセキュアなメッセージを傍受し、そのユーザに対するそのメッセージを自動的にアンセキュア化し、そのアンセキュアなメッセージをそのユーザへと送信するものである。
【０００９】
本発明のまた別の態様では、サーバは、ユーザが正しく認証されているという標示を受け取り、そのユーザが暗号鍵をもっているかどうかを検査し、もっていない場合は鍵を自動的に作成し、これにより、あらかじめ定義したコミュニティ内部のユーザを自動的に登録し、そのユーザはセキュアな電子的メッセージを透過的に送受信できるようになる。
【００１０】
本発明のさらなる態様は、サーバで、ユーザからのアンセキュアなメッセージを傍受し、意図する受信者のデジタル識別を検索し、そのようなデジタル識別を見つけると前記デジタルメッセージをセキュア化し、そのセキュアなメッセージを意図する受信者に透過的に送信するものである。
【発明の詳細説明】
【００１１】
セキュアで透過的な電子的通信は、従来技術にまさる多大の改善をエンドユーザおよびＩＴスタッフに対して提供する１組の方策（ｓｔｒａｔｅｇｉｅｓ）である。また、セキュアで透過的な電子的通信により、改善された開発プラットフォームが提供され、これにより、その試験および品質の保証の実施がより容易になり、したがって顧客には低コストが提供される。ある実施形態では、クライアントプログラムは、ユーザのコンピュータ上にはインストールされない。その代わりに、サーバにより、そのクライアントに対するセキュアなメッセージングのすべてが管理される。
【００１２】
図２に、内部ネットワーク２０２の内部で動作し、インターネット１０００との接続がファイアウォール２１２（これにより、内部ネットワーク２０２が保護される）を通して行われる、本発明によるセキュアサーバ（ｓｅｃｕｒｅ  ｓｅｒｖｅｒ）２０８を含むシステム２００を示している。内部ネットワーク２０２は、例えば、ＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ、構内通信網）またはＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ、広域通信網）を含むことができる。また、内部ネットワーク２０２には、（クライアントコンピュータまたはクライアントマシンとしても知られている）ユーザコンピュータ２０４および２０６が接続されている。セキュアサーバ２０８は、例えば、カリフォルニア州パロアルト（Ｐａｌｏ  Ａｌｔｏ、Ｃａｌｉｆｏｒｎｉａ）のＰＧＰコーポレーション（ＰＧＰ  Ｃｏｒｐｏｒａｔｉｏｎ）が設計し流通を行っているＯｖｉｄサーバとすることができる。一実施形態では、セキュアサーバ２０８から、電子メールセキュリティを、クライアントコンピュータ２０４および２０６のユーザに提供することができる。
【００１３】
セキュアサーバ２０８は透過的（ｔｒａｎｓｐａｒｅｎｔ）であり、これはユーザにとっては、セキュアサーバ２０８を内部ネットワーク２０２に付け加えても、機能における知覚可能な変化が、そのユーザのコンピュータは依然として電子メールの送受信を普段と変わらずに行うため、引き起こされないことを意味する。図２に示す実施形態では、セキュアサーバ２０８は、ネットワークプロトコルのプロキシを行い、クライアント、すなわちクライアントコンピュータ２０４および２０６に対する暗号化の操作すべてを管理している。セキュアサーバ２０８がセキュリティの提供を行う、標準的でよく知られているプロトコルとしては、電子メールの送信のためのＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ならびに、電子メールの取り出しのためのＰＯＰ３（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌのバージョン３）および／またはＩＭＡＰ４（Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｅ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌのバージョン４）があるが、これに制限されるものではない。さらに、保護の可能な他のプロトコルおよび機能としては、
・  Ａｍｅｒｉｃａ  Ｏｎ−Ｌｉｎｅ，Ｉｎｃの提供する、ＡＯＬインスタントメッセージング（ＡＩＭ、ＡＯＬ  Ｉｎｓｔａｎｔ  Ｍｅｓｓａｇｉｎｇ）
・  ＩＣＱ（他のユーザをインターネット上で探し出すプロトコル）
・  Ｊａｂｂｅｒ、すなわち、インターネット上の任意の２点間でリアルタイムにメッセージの交換を行うためのＸＭＬベースのプロトコル
・  ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）メッセージ（ＭＡＰＩは、電子メールをＷｉｎｄｏｗｓアプリケーションの内部から送り、文書をその電子メールに添付できるようにするＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓプログラミングインターフェースである）
・  ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）、すなわち、アプリケーションまたはアプリケーション内部のオブジェクトのアクティベーションを、（インターネットを含めて）ネットワークおよびコンピュータプラットフォームを越えて行えるようにするＸＭＬベースのプロトコル
があるが、これに限定されるものではない。セキュアサーバ２０８により、可能であり適当なときには、こうしたプロトコルは、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）プロトコルによって、さらに安全なものとされるが、これは下で論じる。
【００１４】
下でさらに詳細に述べることになるが、セキュアサーバ２０８は、ユーザコンピュータ２０４および２０６と実際の電子メールサーバ２１０との間の標準ネットワークプロトコルのプロキシを行う。その結果、ユーザコンピュータ２０４および２０６と電子メールサーバ２１０は、ほとんどどのような電子メールクライアントまたは電子メールサーバも使用することができる。ユーザコンピュータ２０４および２０６が標準プロトコルを利用する限り、セキュアサーバ２０８の提供するセキュアで透過的な電子的通信の機能により、セキュアで透過的な電子メールを可能にすることができる。また、セキュアサーバ２０８は、ウイルスまたは敵対的（ｈｏｓｔｉｌｅ）内容に関してスキャンを行う他のプロキシと併せて使用することもできる。
【００１５】
ある実施形態では、セキュアサーバ２０８は、それ自体のオペレーティングシステムを動作させており、セキュアサーバ２０８がソフトウェア更新をＰＧＰコーポレーションから受け取ることができるようにするソフトウェアを含んでいる。セキュアサーバ２０８は、ターンキーシステムの装置（ｔｕｒｎｋｅｙ  ｂｏｘ）（例えば、１Ｕラックマウントシステム、または可能な場合にはＳＯＨＯ（ｓｍａｌｌ  ｏｆｆｉｃｅ／ｈｏｍｅ  ｏｆｆｉｃｅ）コンピュータ）として、または、主要なメーカ（例えば、Ｄｅｌｌ、ＨＰなど）製のパーソナルコンピュータなどの適切に構成したハードウェア上にインストールしたソフトウェアとして、出荷することができる。
【００１６】
［動作モード］
「プロキシモード」
図２に、本発明に従ってプロキシモードで動作するセキュアサーバの一例を示している。このモードでは、セキュアサーバ２０８は、論理上、クライアントマシン２０４および２０６のローカルユーザと電子メールサーバ２１０の間に配置される。典型的な電子メールサーバは、ネットワーク内のユーザと直接に通信を行うが、セキュアサーバ２０８は、クライアントマシン２０４および２０６のローカルユーザとの通信をすべて取り扱う。プロキシモードでは、クライアントマシン２０４および２０６は、電子メールサーバ２１０とやり取りを行わない。特に、セキュアサーバ２０８では、インターネット１０００をあて先とするアウトバウンドのＳＭＴＰ電子メールの暗号化と、ローカルのＰＯＰおよびＩＭＡＰ電子メールの復号を行う。
【００１７】
セキュアサーバ２０８は、この暗号化および復号のプロセスを、そのメッセージの内部に含まれる、または付随する、徴表（ｉｎｄｉｃｉａ）に基づいて行い、これには、ｕｓｅｒｎａｍｅ（ユーザ名）、ｄｉｓｔｉｎｇｕｉｓｈｅｄ  ｎａｍｅ（識別名）、ｃｏｍｍｏｎ  ｎａｍｅ（一般名）、ｄｏｍａｉｎ  ｎａｍｅ（ドメイン名）、または証明書があるが、これに限定されるものではない。プロキシモードでは、電子メールサーバ２１０上の電子メールは、すべて、暗号化して保存してあり、復号は、セキュアサーバ２０８が、クライアントマシン２０４または２０６のユーザがそれをダウンロードするときに行うだけである。さらに、セキュアサーバ２０８は、電子メールの復号を、ローカルネットワーク２０２のリモートユーザ（すなわち、リモートユーザ２２０などのローカルネットワーク２０２の外側に物理的に位置するユーザ）がダウンロードするときに行う。さらに、アウトバウンドの電子メールは、自由選択で、別個のＳＭＴＰリレー（図２には図示せず）を通して中継される。セキュアサーバ２０８が動作するのは、プロキシモードでは、管理者によるセキュアサーバ２０８の構成が、ユーザがメッセージを電子メールサーバ２１０からダウンロードすると、電子メールの復号が行われるようになっているときである。また、プロキシモードにより、セキュアサーバ２０８は、電子メールエリアスの検出を正しく行えるようになる。
【００１８】
より具体的に、例示的な一実施形態では、セキュアサーバ２０８は、既存の電子メールサーバ２１０と、クライアントマシン２０４または２０６上で動作する既存の電子メールクライアントプログラムとの間の電子メールのプロキシを行う。電子メールサーバ２１０は、ＭＴＡ（Ｍａｉｌ  Ｔｒａｎｓｐｏｒｔ  Ａｇｅｎｔ、メール転送エージェント）としても知られ、これは、電子メールを送付するのにネットワーク内で利用されるツールである。電子メールクライアントプログラムは、ＭＵＡ（Ｍａｉｌ  Ｕｓｅｒ  Ａｇｅｎｔ）としても知られ、これは、ユーザとＭＴＡの間のインターフェースである。セキュアサーバ２０８は、ＳＭＴＰ、ＰＯＰ３、およびＩＭＡＰ４などの標準のネットワークプロトコルを使用するどのような電子メールのサーバまたはクライアントとも、共に動作する。さらに、セキュアサーバ２０８は、Ｍｉｃｒｏｓｏｆｔ  ＥｘｃｈａｎｇｅサーバおよびＬｏｔｕｓ  Ｎｏｔｅｓ用のＭＡＰＩインターフェースをサポートしている。また、これは、これらのプロトコルを、よく知られているＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）プロトコル、または、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）プロトコル（両方でＳＳＬ／ＴＬＳ）上でサポートしている。通常、サーバ２０８は、ライブプロキシ（ｌｉｖｅ  ｐｒｏｘｙ）として働き、これは、ＭＵＡおよびＭＴＡの間の実際の接続を仲介することを意味する。時おり、このサーバは、接続を直ちに処理できない場合に、ＳＭＴＰリレーとして働くこともできる。
【００１９】
透過的な暗号化および復号を提供するために、セキュアサーバ２０８は、ユーザに対する暗号化鍵、証明書、およびプロセスをすべて管理する。セキュアサーバ２０８を使用するシステムでは、ソフトウェアを何もエンドユーザシステム上に置く必要はない。暗号化または復号を提供するためのソフトウェアが、何もエンドユーザのマシン上に存在しないとき、通信が保護されているという、エンドユーザにとって識別可能な標示は、何もないはずである。一代替実施形態では、セキュリティソフトウェアを、クライアントマシン２０４および２０６上にインストールして、セキュアサーバ２０８の行う処理の一部を低減させることができる。
【００２０】
セキュアサーバ２０８は、鍵および証明書をｏｐｐｏｒｔｕｎｉｓｔｉｃ（便宜的）に作成するが、これは、セキュアサーバ２０８が、電子メールサーバ２１０に接続している有効なユーザを見つけると、そのユーザに対する鍵および証明書を自動的で透過的に作成することを意味する。セキュアサーバ２０８は、その鍵および証明書の更新を、認証済みのＳＭＴＰ接続上での有効なＦＲＯＭアドレスを用いて行うことができる。鍵および証明書を含んでいる鍵データベースは、定期的に、別のシステムへのバックアップおよび保存が、ＦＴＰまたは電子メールによって行われる。一実施形態では、バックアップデータベースは、管理者の鍵を用いて、ＰＧＰ暗号化される。
【００２１】
プロキシモードでは、電子メールメッセージを電子メールサーバ２１０上に保存し、暗号化および復号をセキュアサーバ２０８が取り出し時に行う。セキュアサーバ２０８は、ポリシに従って、暗号化および復号の操作を完全に透過的に実行すること、その電子メールが暗号化または署名されたことを示すテキストヘッダを追加すること、または、通知を伴うリッチテキストを入れることが可能である。セキュアサーバ２０８は、なりすまし（ｓｐｏｏｆｉｎｇ）を失敗させるために、普通のメッセージの解析（ｐａｒｓｅ）も行わなければならないことに注意されたい。
【００２２】
通常、セキュアサーバ２０８では、クライアントマシン２０４および２０６のユーザのアカウント名およびパスワードを保存しない。逆に、セキュアサーバ２０８は、そのユーザのための別のサーバ（すなわち、電子メールサーバ２１０）に対する接続のプロキシを行っているので、電子メールサーバ２１０がその接続を認証済みと見なす場合には、セキュアサーバ２０８はその接続を認証済みと見なす。
【００２３】
例示的な一実施形態では、クライアントマシン２０４および２０６上で動作するセキュリティソフトウェアにより、ファイルの暗号化および復号、ディスクの暗号化および復号、およびセキュアなファイル削除など、従来型のＰＧＰ暗号化機能がエンドユーザに提供される。さらに、セキュリティソフトウェアにより、クライアントマシン２０４または２０６とセキュアサーバ２０８の間のデジタル証明書（単に証明書とも呼ぶ）の共用が可能になるが、これは、ユーザに証明書ベースのシステムの利益をもたらす一方で、データ喪失の可能性を低減させる。セキュアサーバ２０８の提供するセキュリティは、モバイルユーザ２２０に対しても有効である。ある実施形態では、モバイルユーザ２２０と内部ネットワーク２０２の間の接続が、ＳＳＬで保護される。
【００２４】
「Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｈａｎｇｅ」
ワシントン州レッドモンド（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ）のＭｉｃｒｏｓｏｆｔコーポレーション（Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐ．）製のＥｘｃｈａｎｇｅという製品では、クライアント−サーバ通信のために、特許（ｐｒｏｐｒｉｅｔａｒｙ）プロトコルを使用している。このため、本発明のある実施形態では、特定の変更が、セキュアサーバ２０８がＥｘｃｈａｎｇｅベースの電子メールサーバ（これを、電子メールサーバ２１０の１タイプとすることもできる）と相互動作できるようにするためには必要である。Ｅｘｃｈａｎｇｅサーバプラグイン（すなわち、小さなプログラムモジュール）により、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０上のメッセージと、セキュアサーバ２０８上のメッセージは、互いに容易に送受信することができるようになる。
【００２５】
動作時に、電子メールサーバ２１０上で動作するＥｘｃｈａｎｇｅプラグインは、電子メールメッセージを傍受し、これをセキュアサーバ２０８に転送する。次いで、セキュアサーバ２０８は、何らかの鍵ルックアップおよびメッセージ変換を実行する。次いで、アウトバウンドのＳＭＴＰメッセージの受信者（これは、リモートの電子メールサーバ２３０に接続しているユーザを含むこともできる）への送信が、自由選択でＳＭＴＰ電子メールリレーを通して行われる。ローカルのＥｘｃｈａｎｇｅのユーザに向けられたメッセージは、Ｅｘｃｈａｎｇｅサーバに送り返される。
【００２６】
セキュアなサーバ２０８とＥｘｃｈａｎｇｅベースの電子メールサーバ２１０の間の通信では、ＳＨＴＴＰ（Ｓｅｃｕｒｅ  Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用している。認証は、両側でのクライアント側ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）を含む。すなわち、セキュアサーバ２０８では、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０の証明書を認証し、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０では、セキュアサーバ２０８の証明書を認証する。管理者は、セキュアサーバ２０８の構成を、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０のＴＬＳ証明書によって行い、この逆の場合も同様である。ポート４４３は、どちらのサーバ上でも衝突を引き起こすので、ある実施形態では、ポート４４４をデフォルトとして使用する。
【００２７】
通信の開始を、ユーザ構成コンソールなどを通して、ユーザが行う場合には、セキュアサーバ２０８は、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０内のプラグインに接続して、そのユーザのユーザ名およびパスワードを検証する。ユーザ認証は処理パワーの点で非常に高くつくものであり、非常に頻繁に行われる必要があるため、通信が、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０上で動作するＥｘｃｈａｎｇｅプラグインから直接来ているときには、認証は必要とされない。これは、セキュアサーバ２０８が、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０を信頼して、どのような操作を実行する必要があり、どのようなユーザがその操作を実行する必要があるかを指示するためである。この信頼が存在するのは、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０のＴＬＳ証明書がすでに認証されているからである。
【００２８】
Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０がセキュアサーバ２０８に送るメッセージには、標準の電子メールヘッダがなく、このため、通信は、送信者および受信者などの情報も含んでいる。さらに、Ｅｘｃｈａｎｇｅベースの電子メールサーバ２１０上で動作するＥｘｃｈａｎｇｅプラグインでは、いつ、あるメッセージがＥｘｃｈａｎｇｅ配布リスト（ｄｉｓｔｒｉｂｕｔｉｏｎ  ｌｉｓｔ）に送られたかが認識され、セキュアサーバ２０８に、そのメッセージを暗号化すべきでないという信号を出す。
【００２９】
「ゲートウェイモード」
図３に、ゲートウェイモードにある、本発明による典型的なセキュアサーバを示している。そのようなインストールにより、クライアントマシン３０４および３０６は、セキュアサーバ３０８への接続を、ＳＳＬで強化した接続を介して行えるようになる。クライアントマシン３０４および３０６を、図３に、ファイアウォール装置３１２の提供する、企業ファイアウォールの内側にある内部ネットワーク３０２の部分として示している。クライアントマシン３０４および３０６が、電子メールメッセージを送ると、そのメッセージは、電子メールサーバ３１０の中を通るが、インターネット１０００への送出および受信者（例えば、リモートユーザ３２０またはサーバ３３０に接続しているユーザを含む）に宛てた送信の前に、そのメールをセキュアサーバ３０８が傍受し暗号化する。ネットワーク内部への電子メールを電子メールサーバ３１０が受け取ると、セキュアサーバ３０８は、その電子メールの傍受および復号を、クライアントマシンに宛てた送信の前に行う。この実施形態では、セキュアサーバ３０８は、証明書の取り扱いすべてを、ならびに、バルク暗号化を実行する。
【００３０】
ゲートウェイモードでは、セキュアサーバ３０８は、論理上、電子メールサーバ３１０とインターネット１０００の間に配置される。電子メールサーバ３１０は、クライアントマシン３０４および３０６のローカルユーザとの通信すべてを取り扱う。セキュアサーバ３０８の取り扱う唯一のタスクは、アウトバウンドのＳＭＴＰ電子メールの暗号化および着信するＳＭＴＰ電子メールの復号である。この構成では、電子メールは、すべて電子メールサーバ３１０上に、暗号化せずに保存される。さらに、アウトバウンドの電子メールは、自由選択で、別個のＳＭＴＰリレーを通して中継される。セキュアサーバ３０８が動作するのは、このモードでは、管理者によるセキュアサーバ３０８の構成が、電子メールの復号が、その電子メールを受け取ると行われるようになっているときである。
【００３１】
「補足サーバのあるプロキシモード」
図７に、追加的な機能を、プロキシモードに展開したセキュアサーバに提供するための補足サーバ（ｓｕｐｐｌｅｍｅｎｔａｌ  ｓｅｒｖｅｒ）の使用を含む、本発明の一代替実施形態を示している。図７に示しているシステム７００は、内部ネットワーク７０２および「ＤＭＺ」（ｄｅｍｉｌｉｔａｉｚｅｄ  ｚｏｎｅ、非武装地帯）７０３を含んでいる。内部ネットワーク７０２は、電子メールサーバ７１０およびプロキシモードにあるセキュアサーバ７０８を含み、後者は、以前に述べたように、クライアントマシン７０４および７０６との間のメッセージ傍受し、これにより、内部ネットワーク７０２内部のユーザに対するセキュアな電子的通信を提供する。ＤＭＺ７０８は、補足サーバ７１１およびファイアウォール７１２を含む。補足サーバ７１１の構成は、追加的または補足的な機能をセキュアサーバ７０８に提供するようになっている。一実施形態では、補足サーバ７１１は、セキュアサーバ７０８へのロードバランシングの提供を、着信する鍵に対する要求を取り扱うことによって行うことができる。さらに、補足サーバ７１１は、セキュアなＵＲＬメール要求を取り扱うように構成することができる（これは、下で図５に関して論じる）。
【００３２】
［セキュアサーバおよびクライアントのうちでの通信］
図４に、セキュアサーバ４０８、クライアントマシン４７０、電子メールサーバ４２０、およびファイアウォール４８０がすべて、ローカルネットワーク４９０を介して通信しているネットワーク構成図を示している。典型的な実施形態では、単一のクライアントマシン４７０だけよりもずっと多くのクライアントマシンがあるはずであることに注意されたい。上に述べたように、セキュアサーバ４０８は、プロキシモードで（論理上、クライアントマシン４７０と電子メールサーバ４２０の間に位置することによって）、またはゲートウェイモードで（論理上、電子メールサーバ４２０とインターネット１０００の間に位置することによって）、動作することができる。図４に示すように、セキュアサーバ４０８は、ネットワーク接続装置４５４、ＣＰＵ（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ、中央処理装置）４５２、およびメモリユニット４５５を含めて、標準的なサーバコンピュータの構成要素を含む。メモリユニット４５５は、様々なタスクを実行するためのモジュールへと編成された１組のコンピュータ命令を含むことができる。例示的な一実施形態では、メモリユニット４５５は、標準的なネットワーク接続を実現する通信モジュール４５６、および様々な標準的なメッセージハンドリングプロトコルを実装するためのメッセージ処理モジュール４６８を含む。さらに、メモリユニット４５５は、本発明の一態様に従って様々な証明書検索方策（ｓｔｒａｔｅｇｉｅｓ）を実装するための証明書検索モジュール４６２、メッセージ受信モジュール４５８、メッセージ送信モジュール４６０、および、本発明の一態様に従って様々な暗号および鍵関連の機能を実行するための鍵処理および暗号モジュール４６４を含む。
【００３３】
「クライアントソフトウェア」
クライアントマシン４７０は、ネットワーク接続装置４７４、ＣＰＵ４７２、および、標準的なネットワーク通信を実現する通信モジュール４７６を含むメモリユニット４７５を含めて、標準的なクライアントコンピュータの構成要素を含む。クライアントマシン４７０上で動作するクライアントソフトウェア（例えば、メッセージクライアントモジュール４７８）は、セキュアサーバ４０８との通信を、セキュアサーバ４０８上で動作する通信モジュール４５６の提供するＳＨＴＴＰインターフェースを通して行う。クライアントマシン４７０上のメッセージクライアントモジュール４７８とセキュアサーバ４０８の間の通信は、
１．ユーザの秘密鍵（ｐｒｉｖａｔｅ  ｋｅｙ）のアップロード／ダウンロードすること、および
２．特定の管理者ポリシをセキュアサーバ４０８からクライアントマシン４７０へとダウンロードすること
を含む。
【００３４】
セキュアサーバ４０８では、いつ、ユーザがメッセージをダウンロードまたは送信するか、およびクライアントマシン４７０がメッセージクライアントモジュール４７８を動作させているかどうかが認識される。クライアントマシン４７０がメッセージクライアントモジュール４７８を動作させているときには、セキュアサーバ４０８は、ダウンロードしたメッセージの復号または送信すべきメッセージの暗号化を行わないが、これは、これらのタスクの実行をメッセージクライアントモジュール４７８が行うためである。ＰＯＰおよびＩＭＡＰの通信では、クライアントマシン４７０上のメッセージクライアントモジュール４７８で、いつ、それがセキュアサーバ４０８と通信しているかの検出が、例えば、サーバグリーティング（ｇｒｅｅｔｉｎｇ）中の特別な文字列を識別することにより、またはＩＭＡＰの中のＣＡＰＡＢＩＬＩＴＹコマンドにより、行われる。
【００３５】
セキュアサーバ４０８に接続するために、メッセージクライアントモジュール４７８では、ユーザ名およびパスワードが提供される。クライアントマシン４７０がそのユーザのパスワードをまったく見ることのない特定の場合がある（例えば、そのユーザの電子メールクライアントがＭＤ５  ｃｈａｌｌｅｎｇｅ  ｐａｓｓｗｏｒｄ方式を使用している場合）ため、クライアントマシン４７０からセキュアサーバ４０８への認証が成功しているときには、セキュアサーバ４０８からは小さな、一意のデータファイルがクライアントに提供し（例えば、クッキー（ｃｏｏｋｉｅ））、次いで、これを後でクライアントマシン４７０が使用して、セキュアサーバ４０８への認証をそのユーザのパスワードを必要とせずに行う。
【００３６】
クライアントマシン４７０に、それがセキュアサーバ４０８と通信していることがわかると、クライアントマシン４７０は、次いで、「ＤＯＮＴＤＥＣＲＹＰＴ」や「ＤＯＮＴＥＮＣＲＹＰＴ」などの新しいコマンドを送ることができ、これは、セキュアサーバ４０８だけが解釈することができる。
【００３７】
「ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ）」
管理上の選択肢で、クライアントマシン４７０とセキュアサーバ４０８の間のローカル通信チャネル（例えば、ローカルネットワーク４９０）を介した通信が、ＳＳＬ／ＴＬＳを使用すべきかどうかを指定する。管理上のオプションは、（１）ＳＳＬ／ＴＬＳが必須（ｒｅｑｕｉｒｅ）、または（２）ＳＳＬ／ＴＬＳを許容（ａｌｌｏｗ）を含む。この通信がユーザにとって透過的に働くように、セキュアサーバ４０８のための証明書が、クライアントマシン４７０上の適当な電子メールクライアント内にインストールされる。
【００３８】
ＰＧＰ  ｋｅｙｒｉｎｇ（すなわち、ＰＧＰアルゴリズムを動作させているどのマシン上にも存在する、ＰＧＰ公開鍵および証明書のためのリポジトリ）は、セキュアサーバ４０８上のメモリユニット４５５内に、鍵処理および暗号モジュール４６４で使用するためにあり、これにより、顧客の既存の電子メールサーバ上の証明書を検証できるようになる。例示的な一実施形態では、セキュアサーバ４０８上のＰＧＰソフトウェアにより、ＰＧＰコーポレーション製のＴＬＳパッケージ（ＰＧＰｔｌｓとして知られている）をＳＳＬ／ＴＬＳ機能のために使用できるようになる。さらに、ＰＧＰ  ｋｅｙｒｉｎｇを使用すると、顧客が、追加のＣＡ証明書をＸ．５０９ＣＡ  ｋｅｙｒｉｎｇに付け加えることが、その顧客がすでにそれ自体の内部認証局（ｉｎｔｅｒｎａｌ  ＣＡ）を動作させている場合、できるようになる。
【００３９】
ＳＭＴＰ（これは、メッセージ処理モジュール４６８内に実装しセキュアサーバ４０８が電子メールメッセージを転送するのに使用するプロトコルである）では、異なる２つの機構を、ＳＳＬ／ＴＬＳの実装のために利用している。第１に、（よく知られているＲＦＣ３２０７による）ＳＴＡＲＴＴＬＳ拡張が使用されており、これにより、ポート２５上のＴＬＳネゴシエーションが実行される（ＲＦＣ３２０７に従っているので、「公式」の方法である）。第２に、ポート４６５上のＳＳＬラップしたＳＭＴＰサービスが使用されている（ＲＦＣ３２０７に従っていないので、「非公式」な方法である）。ポート２５上ＳＴＡＲＴＴＬＳ拡張をサポートしない一部のクライアントソフトウェアパッケージがあり（例えば、Ｘｉｍｉａｎ  Ｅｖｏｌｕｔｉｏｎ）、非公式なポート４６５のＳＳＬラップしたＳＭＴＰをサポートしない他のクライアントもある（例えば、Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ）ため、セキュアサーバ４０８では、どちらの方法もサポートしている。
【００４０】
ＳＳＬ証明書の要求／取り出しプロセスは、セキュアサーバ４０８の管理コンソールの統合された一部となっている。セキュアサーバ４０８は、証明書を生成する前に、顧客のライセンス番号、ライセンス認可、およびＤＮＳ名の認可を行う。セキュアサーバ４０８の管理コンソールでは、証明書の要求は、指定した当局（ａｕｔｈｏｒｉｔｙ）とＳＨＴＴＰを介して通信し、直ちにその証明書のダウンロードを試みることによって行われる。そのような実施形態では、手動で介入することは、証明書要求の承認に必要ではない。
【００４１】
例示的な一実施形態では、ＳＳＬ証明書は、発行日から１年間有効である。下でさらに詳細に論じるが、証明書の有効期限が近づくと、セキュアサーバ４０８内部の鍵処理および暗号モジュール４６４が自動的に証明書を更新する。ユーザの便宜のために、新しいＳＳＬ証明書の提供は、顧客ライセンス番号により、そのユーザがその製品の使用をライセンス許諾されていることが示されている限り、継続される。
【００４２】
［電子メールの送信］
セキュアサーバ４０８が、メッセージを（プロキシモードにある）クライアントマシン４７０または（ゲートウェイモードにある）電子メールサーバ４２０からＳＭＴＰを介して受け取ると、これが、メッセージを送ることに対応する。これをメッセージを送ることと呼ぶのは、この接続が、あるユーザ（ローカルユーザまたはリモートユーザ）がセキュアなものとする必要のあるメッセージを送ることに対応しているためである。セキュアサーバ４０８は、認証済みの接続（例えば、ＳＭＴＰ−ＡＵＴＨ。これは、サーバの使用すべき認証方法を示すＳＭＴＰ命名体系（ｎｏｍｅｎｃｌａｔｕｒｅ）中のＳＭＴＰサービス拡張である。）または未認証の接続とともに動作することができる。認証済みの接続は、電子メールを送信するユーザ（例えば、メッセージを送るクライアントマシン４７０のユーザ）に相当する接続であるのに対し、未認証の接続は、例えば、インターネット１０００側のユーザに対して受信中の電子メールに相当する。
【００４３】
典型的な実施形態では、セキュアサーバ（例えば、図４のセキュアサーバ４０８）は、ＳＭＴＰ−ＡＵＴＨを使用して、それ自体のユーザからの電子メールを送信する。ＳＭＴＰ−ＡＵＴＨを使用することは、あるサーバがオープンリレー（ｏｐｅｎ  ｒｅｌａｙ）として使用されるのを回避するための一般的なテクニック（ｍｅｃｈａｎｉｓｍ）である。これにより、セキュアサーバ４０８は、いつ、セキュアサーバ４０８がそれ自体のユーザのうちの１人のプロキシを行っているかを認識し、適切に動作できるようになる。メッセージ送信モジュール４６０は、例えば、そのユーザの証明書の、ユーザの好ましい名前を使った編集を、それを認可済みの電子メールＦＲＯＭ行で読み取ることによって行うことができる。同様に、そのサーバでは、ユーザ特有の選択設定（ｐｒｅｆｅｒｅｎｃｅ）の設定が、ＳＭＴＰ−ＡＵＴＨ（またはＰＯＰ／ＩＭＡＰ接続）を、そのユーザを認証する一手法として使用することによって可能である。
【００４４】
図５に、電子メールメッセージをあるユーザから別のユーザへとセキュアに送信するための、本発明によるセキュアサーバの一実施形態で使用するプロセスを示している。そのようなプロセスは、例えば、図４のセキュアサーバ４０８のメモリユニット４５５内に示したいくつものモジュールのうちで実行できるはずである。プロセス５００のステップ５０５で、受信プログラム（ｒｅｃｅｉｖｅｒ）へと送信すべき、あるユーザからのメッセージを傍受する。そのようなメッセージは、例えば、電子メールメッセージまたはインスタントメッセージとすることができる。傍受後、受信者の証明書を探し出すことができるかどうかの決定を行う。ステップ５１０で、意図する受信者の証明書の検索をローカルキャッシュ内で実行する。証明書が見つかった場合、ステップ５１５で制御はステップ５５５へと移り、ここで、外向きの電子メールメッセージの処理を、ローカルキャッシュからのその受信者の証明書を用いて行う。
【００４５】
ローカルキャッシュ内に証明書が見つからなかった場合、ローカルネットワークの検索をステップ５２０で行う。ここでも、証明書がローカルネットワーク内部のどこかで見つかった場合、ステップ５２５で制御はステップ５５５へと移る。証明書がローカルネットワーク内に見つからなかった場合、ネットワーク全体の検索をステップ５３０で行う。証明書がローカルネットワーク内部で見つかった場合、ステップ５３５で制御はステップ５５５へと移る。ネットワーク全体でも見つからなかった場合は、セキュアなメッセージＵＲＬ（例えば、Ｂｏｏｍｅｒａｎｇメッセージ）の受信者への送信を、ステップ５４０で行う。これにより、受信者は、セキュアなメッセージを交換する機能を提供するあるソフトウェアを（例えば、ＰＧＰコーポレーション製の暗号化クライアントまたは何らかの他のタイプのクライアント側の保護ソフトウェアによって）受け取ることができるようになる。受信者が、そのようなクライアントソフトウェアパッケージの受け取りを希望する場合は（この決定はステップ５４５で行う）、そのクライアントソフトウェアの受信者への送信を、ステップ５５０で行う。
【００４６】
［証明書検索］
セキュアな電子メールの送信で重要なのが、意図する受信者の証明書を取り出すということである。証明書（ｃｅｒｔｉｆｉｃａｔｅ）とは、１つまたは複数の公開鍵と並んで、（ａ）それらの鍵の保持者についてのデータと、（ｂ）鍵の保持者についてのデータのある部分集合を公開鍵そのものの部分集合とバインドする１つまたは複数の署名との、どのような組合せも含むデータオブジェクトである。鍵の保持者についてのデータは、例えば、鍵の保持者の名前、鍵の保持者の電子メールアドレス、鍵の保持者の写真、および、その鍵の保持者の認可の何らかの標示を含むことができる。
【００４７】
戻って図４を参照すると、セキュアサーバ４０８内部の証明書検索モジュール４６２には、使用するのに適当な証明書を見つけるための特定の機構がある。そのような検索における第１の考慮は、証明書に置かれる信頼のレベルである。この決定は、部分的には、信頼ポリシによって行われるが、これは下でさらに詳細に論じる。
【００４８】
セキュアサーバが、適当な証明書を探すうちに、それを、次の場所を含めて、いくつもの場所で見つけることがあるはずである。
１）証明書のローカルキャッシュ
２）ローカルの証明書データベース（例えば、ローカルのパブリックＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）サーバ）
３）他のセキュアなサーバ、特に、受信者の、インターネットドメイン内のサーバ。セキュアサーバ４０８は、例えば、ＤＮＳメール交換レコード（ＤＮＳ  ｍａｉｌ  ｅｘｃｈａｎｇｅ  ｒｅｃｏｒｄｓ）（すなわち、特定のドメインに対するメールサーバレコード）を使用し、または、ふさわしいサーバになるように適切に名前を付けたホスト（例えば、ｋｅｙｓ．ｄｏｍａｉｎという名前を付けたホスト）を探すことができる。
４）指定したＰＧＰ鍵サーバ
５）公開ＰＧＰ鍵サーバ
６）証明書を保持できる他のディレクトリ
【００４９】
セキュアサーバ４０８の管理者は、セキュアサーバ４０８が使用する可能性のある実際のオプションを、証明書検索ならびに整列（ｏｒｄｅｒｉｎｇ）に合わせることができる。上の検索方策（ｓｔｒａｔｅｇｉｅｓ）は、本発明のある実施形態において、セキュアサーバ４０８が従うように構成するポリシのうちにあるものである。
【００５０】
上で説明した第１の想定状況（ｓｃｅｎａｒｉｏ）の例示的な一実施形態では、図４に示したセキュアサーバ４０８が、証明書キャッシュ４１１を含んでいる。証明書キャッシュ４１１は、セキュアサーバ４０８が利用したことのある証明書のすべての部分集合を含んでいる。一例として、証明書キャッシュ４１１は、最近使用した（ｍｏｓｔ  ｒｅｃｅｎｔｌｙ  ｕｓｅｄ）証明書の所定の番号を含んでいる。したがって、ある証明書が必要であり、それが最近使用されたという場合、セキュアサーバ４０８により、その証明書が証明書キャッシュ４１１から迅速に取り出される。一代替実施形態では、証明書キャッシュ４１１は、使用頻度が上位の証明書を含んでいる。したがって、ある証明書が必要であり、それが使用頻度が上位の証明書のうちの１つである（これは、例えば、使用頻度（ｆｒｅｑｕｅｎｃｙ−ｏｆ−ｕｓｅ）アルゴリズムで決定する）場合、それが証明書キャッシュ４１１から迅速に取り出される。
【００５１】
また、図４に、上の第２の想定状況の例を示している。具体的には、電子メールサーバ４２０が、ＬＤＡＰデータベース４２５を含んでいる。ＬＤＡＰデータベース４２５は、例えば、ローカルネットワーク４９０のユーザすべてに対する証明書を含むことができる。一代替実施形態では、別個のＬＤＡＰサーバが、ある特定の部門または企業の従業員すべてに対する証明書を、または、ある特定の組織のメンバーすべてに対する証明書を、（こうした従業員またはメンバーのすべてが必ずしもローカルネットワーク４９０のユーザでなくても）含むこともできる。したがって、受信者がしばしば共通のグループに属すると思われる検索では、ＬＤＡＰデータベースを含むＬＤＡＰまたは他のサーバにより、（例えば、インターネット全体にわたって検索するのに比べると）証明書に対する検索時間を改善することができる。別の代替実施形態では、セキュアサーバ４０８は、ＬＤＡＰデータベース４２５を実装するように構成することもできる。
【００５２】
上の第３の実施形態の例では、セキュアサーバは、別のサーバに対する問い合わせを、ＬＤＡＰルックアップ、ＨＴＴＰ要求、または、別のセキュアサーバへのＳＭＴＰ要求に「ｐｉｇｇｙｂａｃｋ」（便乗）した要求を使用することにより、行うことができる。セキュアサーバは、証明書要求に関するＳＭＴＰ拡張を提供している。これが、セキュアサーバによって直接信頼（ｄｉｒｅｃｔ  ｔｒｕｓｔ）を実装する方法になっている。すなわち、電子メールを別のドメイン内のユーザへと送信すると、送信ドメイン内のセキュアサーバが、単に、受信ドメイン内の電子メールサーバに対して、正当な証明書の問い合わせを行うのである。受信ドメイン内の電子メールサーバに、その電子メールアドレスに関する証明書があるときは、その証明書を取り出して使用する。
【００５３】
直接信頼の方策は、下でさらに詳細に論じるが、これにより、従来の機構にまさる強化点が２つ提供される。すなわち、パートナー組織との協調の容易さ、および証明書問題での近道（ｓｈｏｒｔｃｕｔ）である。例えば、２つのワークグループでセキュアサーバをインストールすると、自動的に、暗号化された電子メールがこの２つの組織全体に広まることになる。信頼関係は、２つの電子メールサーバ間の簡単な協力に基づいている。さらにこれを強化することが、ＤＮＳｓｅｃやＩＰｓｅｃなど、他のネットワークセキュリティプロトコルによって可能である。
【００５４】
例示的な一実施形態における、受信者の証明書を検索する第４の可能性は、１つまたは複数の指定したＰＧＰ鍵サーバを検索することを含んでいる。ＰＧＰ鍵サーバは、ＰＧＰユーザ、その公開鍵、および証明書のデータベースを含むサーバである。セキュアサーバ４０８は、ある実施形態では、受信者の証明書を見つけるための、その検索パス内の次のエントリとして、指定する１組のＰＧＰ鍵サーバを含むことができる。指定するＰＧＰ鍵サーバは、例えば、セキュアサーバ４０８およびローカルネットワーク４９０を配置している場所に地理的に近い地域に配置することもでき、または（特定の大学など）かなりの数の受信者が存在する可能性のある施設に収容することもできる。
【００５５】
１つまたは複数の指定するＰＧＰ鍵サーバを検索するほかに、第５の想定状況では、セキュアサーバ４０８を、ポリシによって構成して、パブリックＰＧＰサーバすべての検索を、指定する受信者の証明書に関して行うようにもできる。パブリックＰＧＰ鍵サーバは、誰もがインターネットを介してアクセスできるＰＧＰ鍵サーバである（すなわち、そのパブリックＰＧＰ鍵サーバのデータベース内部の証明書にアクセスし取り出すことは、インターネットへのアクセスを有する誰もが行える）。この優先度を下げる１つの理由は、パブリックＰＧＰ鍵サーバすべての検索に要する時間が、ローカルキャッシュ、ローカルデータベース、他のセキュアサーバ、または１組の指定するＰＧＰ鍵サーバを検索するよりもかなり長い可能性があることである。
【００５６】
最後に、セキュアサーバ４０８を構成して、１つまたは複数の他のディレクトリの検索を、あるユーザからのメッセージの意図する受信者の証明書に関して行うようにすることもできる。そのような他のディレクトリは、例えば、証明書の特定の部分集合または非公開の（ｎｏｎｐｕｂｌｉｃ）証明書を含むカスタムの企業用ディレクトリ（ｃｕｓｔｏｍ  ｅｎｔｅｒｐｒｉｓｅ  ｄｉｒｅｃｔｏｒｙ）を含むこともできる。
【００５７】
証明書が見つかった後は、その証明書をローカルのパブリック証明書キャッシュに追加して、同じ証明書の多重ルックアップを速める。ローカルのパブリック証明書キャッシュに追加した証明書は、有効期限が管理者の構成した時間後に切れ、そうして削除される。
【００５８】
あるメッセージの意図する受信者に関する証明書を探し出せなかった場合、セキュアサーバ４０８では、いくつかの代替案を提供するが、その振る舞いは管理用の選択設定（ｐｒｅｆｅｒｅｎｃｅ）で決まる。ある実施形態では、可能な動作は、次のものを含むことができる。
１．そのメッセージを発信元の（ｏｒｉｇｉｎａｌ）送信者に返す
２．そのメッセージを暗号化せずに送る
３．そのメッセージの暗号化していないテキストの後に「ｓｍａｒｔ  ｔｒａｉｌｅｒ」を付ける。これには、受信者をセキュアサーバに導くＵＲＬがあり、これにより、受信者は、暗号化クライアント（例えば、ＰＧＰクライアント）をダウンロードするリンクが渡され、またはセキュアＵＲＬ電子メールを使用するための選択設定（ｐｒｅｆｅｒｅｎｃｅ）を設定できるようになる。
４．セキュアなＵＲＬ電子メールメッセージ（例えば、ＰＧＰコーポレーションの提供するＢｏｏｍｅｒａｎｇ電子メール）を送る
【００５９】
［セキュアＵＲＬ電子メールメッセージ］
セキュアＵＲＬ電子メールの表している概念は、暗号化すべきであるアウトバウンドの電子メールが、実際にはセキュアサーバ４０８上にとどまり、受信者はその電子メールの閲覧をセキュアサーバ４０８上のＳＨＴＴＰ  Ｗｅｂページを通して行うよう要求される、というものである。ある例示的な実施形態では、暗号化されていないメッセージを受け取る代わりに、受信者が受け取るのは、セキュアサーバ４０８自体を指す（ｐｏｉｎｔｉｎｇ  ｂａｃｋ）ＵＲＬ、ならびに、例えば、暗号化クライアントソフトウェアをダウンロードするための他のＵＲＬを含むメッセージである。例示的な一実施形態では、そのＵＲＬは、受信者をセキュアサーバ４０８上のＳＨＴＴＰ  Ｗｅｂページへと導き戻す。ＳＨＴＴＰで安全になっているこのＷｅｂページにより、受信者は、安全にメッセージを読めるようになる。例えば、このＷｅｂページは、次の質問、およびその下に続くオリジナルの平文のメッセージを含むことができるはずである（ただし、それでもＳＨＴＴＰ接続によってセキュアになっている）。
【００６０】
「Ｊｏｈｎ  Ｓｍｉｔｈ  ｊｏｈｎ＠ｏｖｉｄｂｕｙｅｒ．ｃｏｍからのメッセージを今後安全にお読みになれます。次のオプションを１つ選択してください。
１．暗号化を使って電子メールをデスクトップ上で安全に読む（選択すると、暗号化クライアントがインストールされます）
２．パスフレーズを入力してｏｖｉｄｂｕｙｅｒ．ｃｏｍからの電子メールをこのサイト上で安全に読む
３．自分への電子メールの暗号化を希望しない」
【００６１】
本発明のある実施形態では、セキュアサーバ４０８が電子メールを送信しようとする電子メールアドレスごとに、セキュアサーバ４０８により、新しいセキュアＵＲＬ電子メールアカウントが作成される。これにより、セキュアで透過的な電子的通信をデフォルトで可能にしておくための一手法が提供される。（以前説明したような）特定の受信者に関する証明書が見つからない場合でも、セキュアＵＲＬ電子メールアカウントが提供されていれば、ユーザと受信者の間の通信はセキュアであることになる。
【００６２】
受信者が上のオプション２を選択すると、セキュアサーバ４０８は、セキュアＵＲＬ電子メールデータベース内のそのアカウントに関するエントリにパスフレーズを作成する。その受信者へのそれ以降のメッセージを読むには、このパスフレーズを使用する。そのパスフレーズをもつ受信者だけがセキュアサーバ４０８の送るメッセージを閲覧することができるので、パスフレーズを提供することにより、セキュリティのレベルがさらに追加される。これにより、原始的なレベルの認証が提供される。
【００６３】
受信者が上のオプション３を選択した場合、セキュアサーバ４０８は、その受信者のメッセージを平文で（すなわち、暗号化せずに）、それでもＳＨＴＴＰ接続でセキュア化して送るように、セキュアＵＲＬ電子メールデータベース内のエントリにフラグを追加する。
【００６４】
したがって、本発明の一実施形態では、セキュアＵＲＬ電子メールにより、セキュアで透過的な電子的通信の１つの形式の提供が、受信者にはセキュアな通信機能がその受信者のコンピュータまたは他の電子的装置上にないときでも行われる。セキュアで透過的な電子的通信は、ユーザと受信者の間の通信が、ユーザと受信者のどちらの意図にもかかわらず、セキュアなものとなるようにする。
【００６５】
［電子メールの受信］
ユーザが電子メールをセキュアサーバ４０８から取り出すと、このサーバは、接続のプロキシをメッセージ受信モジュール４５８内で、メッセージの復号を鍵処理および暗号モジュール４６４内で、その電子メールをＳＳＬを介してユーザのシステムへと送る前に行う。このプロセスは、適用可能なポリシの指示する通りに、完全に透過的であることもでき、またはテキストまたはＨＴＭＬで強化して、ユーザにその電子メールが暗号化または署名されて送られたことを知らせることもできる。
【００６６】
受信した電子メールメッセージ上のデジタル署名を検証するには、電子メールを送るのに必要な証明書検索に類似の証明書検索が必要である。また、デジタル署名の検証では、ＯｐｅｎＰＧＰ  Ｐｒｅｆｅｒｒｅｄ  Ｋｅｙ  Ｓｅｒｖｅｒ署名サブパケット（ＲＦＣ２４４０、セクション５．２．３．１７）を利用するが、これにより、（失効（ｒｅｖｏｃａｔｉｏｎ）などの）署名する証明書のステータスを更新するために正当な証明書がどこにあるはずかがわかる。
【００６７】
図６に、電子メールメッセージをユーザからセキュアに受け取るための、本発明によるセキュアサーバの一実施形態で使用するプロセスを示している。そのようなプロセスは、例えば、図４のセキュアサーバ４０８のメモリユニット４５５内に示すいくつものモジュールのうちで実行することができるはずである。プロセス６００のステップ６０５で、あるユーザから、別のユーザから送られたセキュアなメッセージを傍受する。メッセージの受け取り後、セキュアサーバ４０８は、ユーザの証明書の取り出しを、ステップ６１０で行う。ステップ６１５で、受け取ったセキュアなメッセージの処理（一実施形態では、暗号化されたメッセージの復号を含む）を行う。処理して判読可能なテキストにすると、次いで、そのメッセージをそのユーザ宛てに、ステップ６２０で送ることができる。
【００６８】
［自動化ＰＫＩ］
従来のＰＫＩとは異なり、セキュアサーバ４０８をインストールすると、ＰＫＩが、使用される状態で作成される。セキュアサーバ４０８では、認可されたユーザの、メインの電子メールサーバとのやり取りを利用して、そのユーザが誰であるかを判断しているので、そのようなＰＫＩでは、セキュアサーバ４０８にはプロビジョニングがほとんど必要ない。これは、ユーザを発見すると証明書を作成し、また、メッセージの他の組織との交換が、ＰＧＰ鍵サーバ、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）証明書サーバ、または他のセキュアなサーバを用いて行われると、その動的な基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を拡張する。これにより、さらに、セキュアサーバ４０８をプロビジョンするＩＴスタッフに対する必要は、最小限なものになる。さらに、この動的ＰＫＩは、Ｘ．５０９証明書ならびにＰＧＰ証明書とともに動作し、ＰＧＰとＳ／ＭＩＭＥベースのシステムの間の相互運用性を提供することができる。
【００６９】
「鍵の生成」
あるユーザのセキュアサーバ４０８への認証が（ＳＭＴＰ、ＰＯＰ、またはＩＭＡＰを介した電子メールサーバ４２０での認証によって）成功すると、検査を行って、そのユーザに証明書を発行したことがあるかどうかを判断する。そのユーザが鍵を持っていない場合、セキュアサーバ４０８は、新しい公開鍵ペアおよび証明書の生成を、鍵処理および暗号モジュール４６４を用いて行い、新しい証明書の自動的な署名を、セキュアサーバ４０８からのＰＧＰ証明鍵（ＰＧＰ  ｃｅｒｔｉｆｉｃａｔｉｏｎ  ｋｅｙ）を用いて行う。
【００７０】
鍵ペアを生成するには、ユーザ特有の情報が２つ必要である。すなわち、そのユーザの名前および電子メールアドレスである。ユーザがＳＭＴＰ電子メールを送る場合には、ユーザ名と電子メールアドレスのどちらも、送信中の電子メールの「Ｆｒｏｍ：」行から読み出すことができる。ユーザが電子メールをＰＯＰまたはＩＭＡＰを介して受け取る場合には、ユーザ名は、システムへの認証のために使用している名前から得られ、ドメインは、おそらくすでに知られている（ただし、複数の電子メールドメインを管理しているときは、そうでない可能性がある）。さらに、ＰＯＰおよびＩＭＡＰの場合は、電子メールアドレスを決定する。しかし、そのユーザの本当の名前を決定する手法はない。この問題を回避するには、証明書を電子メールアドレスだけで生成する。そのユーザが後でＳＭＴＰによって認証を行うときには、その証明書のｓｅｌｆ  ｓｉｇｎａｔｕｒｅを、アウトバウンドのメッセージの「Ｆｒｏｍ：」行から取った名前で更新する。
【００７１】
セキュアサーバ４０８内の鍵処理および暗号モジュール４６４の生成するローカルユーザの公開鍵は、（ＲＦＣ２４４０、セクション５．２．３．２０に定める）対応する証明書内で「ｇｒｏｕｐ  ｋｅｙ」フラグが設定され、そのユーザの秘密鍵は意図する受信者が独占所有するわけではないことが、他のユーザに通知される。さらに、（ＲＦＣ２４４０、セクション５．２．３．１７に定める）「ｐｒｅｆｅｒｒｅｄ  ｋｅｙ  ｓｅｒｖｅｒ」オプションは、セキュアサーバ４０８上で動作するＯｐｅｎ  ＬＤＡＰに設定される。一実施形態では、そのＵＲＬは、
ｌｄａｐ：／／ｈｏｓｔ：ｐｏｒｔ／ｐｇｐｃｅｒｉｄ＝１２３４５６７８９０ＡＢＣＤＥＦ，ｏｕ＝ＰＧＰ  Ｋｅｙｓｐａｃｅ，ｏ＝ＯｒｇＮａｍｅ
などの標準的なＬＤＡＰ  ＵＲＬである。
【００７２】
「証明書の更新」
メッセージ処理モジュール４６８内部では、追加のユーザＩＤのセキュアサーバ４０８内のユーザ証明書への関連付けが、特にユーザがｍｓｍｉｔｈ＠ｃｏｍｐａｎｙ．ｃｏｍやｍｉｋｅ．ｓｍｉｔｈ＠ｃｏｍｐａｎｙ．ｃｏｍなど、１つまたは複数のエリアスアドレスをもつことを検出したときには可能である。ユーザが、そのユーザの証明書上にないアドレスを含む「Ｆｒｏｍ：」ヘッダのあるメッセージを送ると、セキュアサーバ４０８により、そのアドレスが追加される。
【００７３】
より複雑な場合が生じるのは、ユーザが複数のエリアスをもっているが、電子メールの１つのアドレスだけから行うとき、例えば、マイクスミス（Ｍｉｋｅ  Ｓｍｉｔｈ）が電子メールの送信はｍｓｍｉｔｈ＠ｃｏｍｐａｎｙ．ｃｏｍから行うが、受信はｍｉｋｅ＠ｃｏｍｐａｎｙ．ｃｏｍ、ｍｉｋｅ．ｓｍｉｔｈ＠ｃｏｍｐａｎｙ．ｃｏｍ、などからも行うようなときである。この場合、新しいヘッダ（Ｏｖｉｄサーバが関係する本発明の一実施形態では「Ｘ−Ｏｖｉｄ−Ｒｅｃｉｐｉｅｎｔ」など）の追加を、メッセージ処理モジュール４６８が、セキュアサーバ４０８の受け取るメーリングリストでない着信の電子メール（すなわち、アドレスが個別になっている電子メール）すべてに対して行う。この新しいヘッダは、実際のＳＭＴＰ受信者アドレス（すなわち、ＳＭＴＰセッション中のＲＣＰＴコマンド中に指定してあるアドレス）を含んでいる。そのユーザが電子メールをダウンロードすると、セキュアサーバ４０８では、Ｘ−Ｏｖｉｄ−Ｒｅｃｉｐｉｅｎｔヘッダに追加してある受信者アドレスを、認証済みのユーザ名と比較する。受信者アドレスがユーザ名と異なる場合は、セキュアサーバ４０８で、受信者アドレスを、そのユーザの証明書に新しいユーザＩＤとして関連付ける。
【００７４】
電子メールサーバ４２０内部の内部メーリングリストはすべて、除外リスト（ｅｘｃｌｕｓｉｏｎ  ｌｉｓｔ）に追加される。一実施形態では、メーリングリストへと送信されたメッセージは、Ｘ−Ｏｖｉｄ−Ｒｅｃｉｐｉｅｎｔヘッダが追加されず、ダウンロード時にこのヘッダが検査されることもない。あるメーリングリストが除外リストに追加され損なっている場合に、非ローカルユーザから内部にホストのあるメーリングリスト（例えば、ｌｉｓｔ＠ｃｏｍｐａｎｙ．ｃｏｍ）に送られた電子メールがあると、「Ｘ−Ｏｖｉｄ−Ｒｅｃｉｐｉｅｎｔ：ｌｉｓｔ＠ｃｏｍｐａｎｙ．ｃｏｍ」というヘッダのＳＭＴＰメッセージへの追加が、最初の受信時に引き起こされる。受信者がそのメッセージをダウンロードすると、セキュアサーバ４０８で、Ｘ−Ｏｖｉｄ−Ｒｅｃｉｐｉｅｎｔヘッダの処理、およびｌｉｓｔ＠ｃｏｍｐａｎｙ．ｃｏｍのそのユーザの証明書への追加が行われる。セキュアサーバ４０８内のメッセージ受信モジュール４５８内部のメーリングリスト検出機構では、ユーザがメッセージをダウンロードするときにこの状況が検出し防止する。
【００７５】
ゲートウェイモードでは、ユーザが電子メールをダウンロードするとき、セキュアサーバ４０８は、これを処理せず、そのため、ユーザがメッセージを異なるアドレスから送るときには、エリアスの追加だけを行うことに注意されたい。
【００７６】
「証明書の有効期限切れおよび更新」
セキュアサーバ４０８内の鍵処理および暗号モジュール４６４の生成する証明書には、管理者によって構成可能な有効期間があり、その範囲は、一実施形態では、１日から有効期限なしにわたる。デフォルトの有効期間が設定してあり、これは、例示的な一実施形態では、２週間である。セキュアサーバ４０８の鍵処理および暗号モジュール４６４内部の証明書維持機能により、ある証明書の有効期限切れが近づいていると判断されると、その証明書に対する新しいｓｅｌｆ  ｓｉｇｎａｔｕｒｅおよび新しい有効期限をもつ新しい証明書の生成が（既存の証明書の有効期限が切れるままにし、そのユーザに対する新しい証明書を生成する代わりに）行われる。これにより、ユーザは同じ暗号鍵を持ち続けるが、その証明書内には新しい有効期限および新しい署名があるということが可能になる。
【００７７】
「ｄｅａｄ  ｃｅｒｔｉｆｉｃａｔｅ」問題（すなわち、有効期限切れの証明書を無期限に持ち続けること）を解決するために、構成可能な３つのタイムアウト期間が、本発明の一実施形態では存在する。すなわち、
１．証明書有効期限切れタイムアウト（Ｃｅｒｔｉｆｉｃａｔｅ  ｅｘｐｉｒａｔｉｏｎ  ｔｉｍｅｏｕｔ）
２．アカウント無活動タイムアウト（Ａｃｃｏｕｎｔ  ｉｎａｃｔｉｖｉｔｙ  ｔｉｍｅｏｕｔ）
３．最終アカウント無活動タイムアウト（Ｆｉｎａｌ  Ａｃｃｏｕｎｔ  ｉｎａｃｔｉｖｉｔｙ  ｔｉｍｅｏｕｔ）
【００７８】
第１のタイムアウト、すなわち証明書有効期限切れタイムアウトは、デフォルトの証明書有効期間である。上で説明した証明書維持機能により、有効期限切れになっている、または所定の期間内に有効期限切れになる証明書がどれか見つかると、セキュアサーバ４０８で、そのユーザが電子メールサーバ４２０に最後にログインしたときの検査を行う。ユーザが、アカウント無活動タイムアウト（第２のタイムアウト期間）の定める期間内にログインしていた場合は、新しいｓｅｌｆ  ｓｉｇｎａｔｕｒｅを、新しい有効期限をもつ証明書に対して生成する。ユーザが、アカウント無活動タイムアウト内にログインしていなかった場合は、証明書の有効期限を切れるままにする。最終アカウント無活動タイムアウトが経過してしまった後、ユーザがまだログインしていない場合は、その証明書を削除する。延長した期間の間いない可能性のあるユーザに関する証明書を削除してしまうことを回避するために、最終アカウント無活動タイムアウトは、非常に長く設定すべきである。
【００７９】
［信頼ポリシ］
証明書の有効性を指定する３つの基本的な信頼ポリシがある。階層的信頼（ｈｉｅｒａｒｃｈｉｃａｌ  ｔｒｕｓｔ）、累積的信頼（ｃｕｍｕｌａｔｉｖｅ  ｔｒｕｓｔ）、および直接信頼（ｄｉｒｅｃｔ  ｔｒｕｓｔ）である。セキュアで透過的な電子的通信を提供するサーバでは、３つのポリシをすべて使用している。階層的信頼で、証明書を有効と見なすのは、何らかの信頼されたルート証明機関（ｔｒｕｓｔｅｄ  ｒｏｏｔ  ａｕｔｈｏｒｉｔｙ）またはその指定する証明機関のうちの１つによって証明される場合である。信頼されたルート証明機関は、例えば、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ、認証局）を含むことができる。従来のＸ．５０９証明書またはＰＧＰ  Ｍｅｔａ−Ｉｎｔｒｏｄｕｃｅｒｓは、階層的信頼システムに見られる例である。累積的信頼で、証明書を有効と見なす際には、その証明（ｃｅｒｔｉｆｉｃａｔｉｏｎｓ）を加算し、そうした証明を重み付けし、検査してそれがあるしきい値よりも大きいかどうかを確かめる。ＰＧＰ  Ｗｅｂ  ｏｆ  Ｔｒｕｓｔは、累積的信頼システムである。直接信頼で、証明書を有効と見なすのは、その証明書を、その所有者またはその証明書の所有者の使用するセキュアサーバから直接に受け取った場合である。通常、個人では直接信頼を使用する。そのようなシステムで、ある人が、証明書を有効と見なす理由が、証明書の保持者の名刺上に指紋が印刷してあるからという場合は、受信者は直接信頼を使用している。
【００８０】
セキュアサーバ４０８により、その管理者は、階層的信頼ではルート証明機関の証明書を、累積的信頼では重み付け証明書を指定できるようになる。例えば、ある実施形態では、管理者は、適切な鍵、証明書、署名、およびその組織に関する信頼レベルのすべてを伴う通常のＰＧＰ  ｐｕｂｌｉｃ  ｋｅｙｒｉｎｇファイル（．ｐｋｒという拡張子をもつ）をアップロードすることができる。セキュアサーバ４０８は、直接信頼を使用することもできる。これは、証明書を受信者のドメインから検索し、そのユーザが平文を送ろうとしていたドメインが、証明書のなりすましを行っていた場合、平文を送る寄りも実質的に悪くはないと仮定することによって行われる。したがって、セキュアサーバ４０８は、証明書を受信者と直接の関係がある発信元から受け取っているときはいつでも、直接信頼を使用することになる。一実施形態では、証明書は、次の発信元のうちの１つから来るとき、直接に信頼される。
１．ｋｅｙｓ．ｄｏｍａｉｎ．ｃｏｍで動作するＬＤＡＰサーバ。ただし、ｄｏｍａｉｎ．ｃｏｍは受信者のドメインである。
２．受信者のＳＭＴＰサーバ上で動作するＬＤＡＰサーバ。
【００８１】
［ポリシ］
ポリシは、セキュアサーバが様々な状況でどのように動作するかを律する１組のルールを定義する。一実施形態では、セキュアで透過的な電子的通信を提供するサーバは、次のようなものなどの構成可能なポリシ要素を含む。
・  ドメイン内部で暗号化および／または署名を行うことに対する要件
・  検索方策（ｓｔｒａｔｅｇｉｅｓ）
・  信頼された証明書およびサーバ
・  無証明書方策
・  証明書管理ポリシ
・  電子メール表示ポリシ
・  バックアップ頻度、送付、その他
・  管理者のユーザ名
・  管理者のパスワード
・  グローバルのイネーブル／ディゼーブル暗号化（学習モード）
・  鍵生成オプション
○  鍵サイズ
○  鍵アルゴリズム
○  有効期間−１日から有効期限なしまでの範囲、デフォルトは２週間
・  アカウント無活動タイムアウト−デフォルトは１週間
・  最終アカウント無活動タイムアウト−デフォルトは４か月
・  ローカルユーザとの通信にＳＳＬ／ＴＬＳが必要かどうか
・  受信者の証明書を見つけられない場合メッセージをどうするか
−  これはドメインごとに構成可能であるべきである
○  平文で送る
○  メッセージを送らない
○  ｓｍａｒｔ  ｔｒａｉｌｅｒを付ける
○  セキュアＵＲＬ電子メールメッセージを送る
・  いつメッセージに署名するか
○  必ずする
○  まったくしない
○  暗号化も行うとき
・  どのような鍵／証明書をセキュアサーバは信頼すべきか
・  公開鍵を検索するためにドメインごとおよびパブリックな鍵サーバを追加／削除する
・  どのくらい長くルックアップした公開鍵をキャッシュするか−デフォルトは２４時間
・  グローバル除外リスト−暗号化を行わないアドレス
・  ユーザがメーリングリストに対してユーザごとの除外を追加できるようにするかどうか
・  グローバル除外リストにアドレスを追加する必要のあるユーザの数
・  いつメッセージを復号するか−セキュアサーバが受け取るときか、ユーザがダウンロードするときか
・  セキュアサーバクライアントに対するポリシ
○  セキュアサーバクライアントはその秘密鍵をセキュアサーバに渡すべきか
○  パスフレーズの長さ
○  パスフレーズの品質（ｐａｓｓｐｈｒａｓｅ  ｑｕａｌｉｔｙ）
○  鍵生成オプション（上を参照）
○  公開鍵および証明書を検索するためのドメインごとおよびパブリックの鍵サーバ
○  受信者の証明書が見つけられないときに暗号化が必要か平文メッセージを許容するか
・  ＥｘｃｈａｎｇｅサーバのＴＬＳ証明書
・  アプライアンスネットワークの構成−ＩＰアドレス、サブネット、ＤＮＳ名
・  自分たちが管理する電子メールドメインのリスト
・  実体の電子メールサーバのアドレス
○  電子メールを受け取る着信ＳＭＴＰサーバ
○  アウトバウンドの電子メールのためのＳＭＴＰリレー
○  ＰＯＰサーバ
○  ＩＭＡＰサーバ
○  Ｅｘｃｈａｎｇｅサーバのアドレスおよび通信用のポート
・  Ｂｏｏｍｅｒａｎｇ電子メールのアカウント有効期限
・  Ｂｏｏｍｅｒａｎｇ電子メールのストレージクォータ
・  Ｂｏｏｍｅｒａｎｇ受信者が自分宛電子メールを暗号化しないオプションを選択できるようにする
・  データベースバックアップを暗号化するための管理者ＰＧＰ鍵
・  バックアップのアップロード先のＦＴＰサーバ
○  サーバアドレス
○  ログイン情報
○  バックアップファイル用のディレクトリ
・  いくつバックアップを保管するか
・  何回バックアップするか
○  何曜日か
○  何時にバックアップを始めるか
・  バックアップの成功後、管理者に電子メールアラート（ｅ−ｍａｉｌ  ａｌｅｒｔ）をおくるかどうか、およびどこにアラートを送るか
・  ソフトウェア更新を自動的にインストールするか、またはセーブして管理者が手動でインストールするか
・  アプライアンスへのシェルアクセス用ＳＳＨ公開鍵を提供するための管理者用フィールド
・  ｓｙｓｌｏｇメッセージを送るための他のマシンのリスト
・  日毎のログ（ｄａｉｌｙ  ｌｏｇ）を電子メールで送るための電子メールアドレス
【００８２】
本発明の一実施形態では、管理コンソールにより、管理者は次のタスクも行えるようになっている。
・  ローカルの証明書データベースを検索し、個人の鍵および証明書を取り消しまたは削除する
・  ダウンロードしたソフトウェア更新のリストを閲覧し、それを手動でインストールする
・  自分たちのＣＡからＳＳＬ／ＴＬＳ証明書を要求する
・  Ｂｏｏｍｅｒａｎｇ電子メールアカウントを管理する
・  セキュアサーバ上に保存してあるデータベースバックアップのリストを閲覧し、選択したバックアップをダウンロードする
・  データベースバックアップを手動で開始する
・  ローカルのパブリック証明書キャッシュを手動でクリアする
・  ローカルのアウトバウンド電子メールキューを管理する
・  現在のセキュアサーバのログを閲覧する
・  どのようにダウンロードした電子メールをフォーマットするか−いつもプレーンテキスト、いつもｈｔｍｌ、または元のメッセージのタイプに基づく
・  除外リスト−暗号化を行わないアドレス
・  セキュアサーバのＴＬＳ証明書
・  セキュアサーバのアドレスおよび通信用のポート
【００８３】
［インストール］
例示的な一実施形態では、セキュアサーバ４０８は、ノースカロライナ州レイリー（Ｒａｌｅｉｇｈ、ＮＣ）のＲｅｄ  Ｈａｔ，Ｉｎｃ．の製作するＲｅｄＨａｔ  ７．３  Ｌｉｎｕｘディストリビューションなどの修正したＬｉｎｕｘオペレーティングシステムを利用している。ＲｅｄＨａｔは、すでに、ｏｐｅｎｌｄａｐやａｐａｃｈｅなど、セキュアサーバ４０８に必要な多くの付属（ｅｘｔｒａ）のライブラリおよびアプリケーションを提供している。異なる一実施形態では、Ｉｍｍｕｎｉｘなど、別のＲｅｄＨａｔベースディストリビューションを使用することもできる。セキュアサーバソフトウェアの多用途でモジュラーな設計により、他のＵｎｉｘベースのオペレーティングシステムへの、また必要な場合には、Ｗｉｎｄｏｗｓベースのアーキテクチャへの、容易な移植が可能になっている。
【００８４】
セキュアサーバ４０８用のプログラム／ライブラリは、標準の署名済みＲＰＭとしてパッケージ化されている。ＲＰＭは、ＲｅｄＨａｔ  Ｐａｃｋａｇｅ  Ｍａｎａｇｅｒに適合するように書かれたパッケージである。これにより、ＲｅｄＨａｔインストーラに容易に含めることが可能になり、自動更新機構が単純化される。セキュアサーバ４０８のある配布は、ＲｅｄＨａｔ  ＲＰＭパッケージの一部を、適切に修正して、どのようなものであれ必要なデフォルトの構成とともに含むことになる。必要のないパッケージを含めないことにより、配布全体が単一のインストレーションＣＤ上に収まる。
【００８５】
［初期セットアップ］
セキュアで透過的な電子的通信を提供するセキュアサーバの使用への移行を容易にするために、「学習モード」（Ｌｅａｒｎ  Ｍｏｄｅ）がセキュアサーバ４０８の一実施形態には存在する。このモードでは、セキュアサーバ４０８は、どのような暗号化／復号も実行しないが、ＰＯＰ、ＩＭＡＰ、およびＳＭＴＰのメッセージは依然として電子メールサーバ４２０へとプロキシが行われ、ＰＫＩ（ｐｕｂｌｉｃ  ｋｅｙ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、公開鍵基盤）を構築し除外リストを作成することができるようになるはずである。
【００８６】
一実施形態では、セキュアサーバ４０８へのソフトウェア更新の提供は、ネットワークを介して自動的に行われる。こうした更新は署名されており、その結果、正当な更新だけがセキュアサーバ４０８上にインストールされる。自動更新は署名済みＲＰＭとして配布され、これは、ＲＰＭによってすでに埋め込みＰＧＰ署名が可能になっているという事実によって容易になっている。
【００８７】
例示的な一実施形態では、セキュアサーバ４０８には、更新されたＲＰＭの定期的なダウンロード、ＰＧＰ署名の検証、および、（１）管理者に代わってそれを自動的にインストールすること、または（２）電子メールで管理者に通知し、インストールを管理Ｗｅｂコンソールから手動で開始できるようにすることのための（Ｕｎｉｘの「ｃｒｏｎ」ジョブなどの）スケジュールされたタスクがある。更新されたパッケージへのアクセスは、検証された顧客に限られている。顧客に有効なライセンス番号およびライセンス認可の提供を要求するＳＨＴＴＰサーバが維持されている。標準のＲＰＭを使用することにより、外部的に提供されるセキュリティ更新を、セキュアサーバ４０８内で使用する他のどのようなパッケージにも行うことができるようになる。
【００８８】
上で説明した実施形態は、電子メールに焦点を置いているが、例えば、インスタントメッセージングを含めて、ユーザの必要に密接に関連するいくつもの他のプロトコルがある。インスタントメッセージングプロトコルは、広く使用されており、最も速く成長しているタイプのインターネット通信である。また、これは完全にセキュアではない。セキュアサーバプロキシは、こうしたプロトコルにセキュリティを提供することができる。
【００８９】
上で詳細に述べたのは、本発明の少なくとも１つの実施形態の諸態様である。上で述べた特徴のそれぞれは、本発明の一実施形態に従って、１つのシステム、方法、および／またはコンピュータ実行可能なコードで実装することができる。あるいは、上で述べた特徴のそれぞれを、本発明の諸実施形態に従って、異なるシステム、方法、および／またはコンピュータ実行可能なコードで実装することもできる。
【００９０】
さらに、本発明の諸原理、好ましい実施形態、および利用モードを、以上の説明の中で説明してきた。しかし、保護すべきものである発明を、ここに開示した特定の実施形態に限定されるものとして解釈すべきではない。さらに、本明細書で説明した諸実施形態は、制限的ではなく例示的と見なすべきである。他の者が変形および変更を行うこと、および均等物の使用は、本発明の趣旨から逸脱することなく行うことができる。したがって、以上の特許請求の範囲で定義する本発明の趣旨および範囲の範囲内に入るそのような変形、変更、および均等物はすべて、それにより、明確に包摂されるものとする。
【図面の簡単な説明】
【００９１】
【図１】従来技術による、ネットワーク環境で動作する暗号化ソフトウェアパッケージを示す図である。
【図２】本発明の一実装形態による、プロキシモードで動作するサーバを伴うネットワークを示す図である。
【図３】本発明の一代替実装形態による、ゲートウェイモードで動作するサーバを伴うネットワークを示す図である。
【図４】本発明の一実装形態による、セキュアで透過的な電子的通信を提供するサーバの論理接続を示すネットワーク図（ｎｅｔｗｏｒｋ  ｄｉａｇｒａｍ）である。
【図５】本発明の一実装形態による、セキュアな電子メールを送るプロセスを示す流れ図である。
【図６】本発明の一実装形態による、セキュアな電子メールを受け取るプロセスを示す流れ図である。
【図７】本発明の一代替実装形態の図である。
【図１】
2006518949.tif 000003
【図２】
2006518949.tif 000004
【図３】
2006518949.tif 000005
【図４】
2006518949.tif 000006
【図５】
2006518949.tif 000007
【図６】
2006518949.tif 000008
【図７】
2006518949.tif 000009
【手続補正書】
【提出日】平成17年9月6日(2005.9.6)
【手続補正１】
【補正対象書類名】図面
【補正対象項目名】図３
【補正方法】追加
【補正の内容】
【図３】
2006518949.tif 000010
【国際調査報告】
2006518949.tif 000011