"ロギングコンポーネントと;請求コンポーネントと;署名コンポーネントと;保証サービス、証明書ステータスチェックサービス、または支払い補償サービスの、少なくとも一つと;および前記コンポーネントのオペレーションと、少なくとも一つのサービスとを、一つ以上のトランザクションに結びつけるための、トランザクション処理モニタと;を具備するトランザクション処理システムであって、前記一つ以上のトランザクションは、原子性、一貫性、分離性、および耐久性の属性を有する、前記システム。電子ネットワークを介して、証明書ステータスチェックを実行するための安全な方法であって、少なくとも一つの電子ネットワーク、少なくとも一つの署名取引先、少なくとも一つの信用取引先、少なくとも一つの発行関係先、少なくとも一つの信用関係先、および少なくとも一つのルートを具備する前記方法であって:aスマートカードを前記少なくとも一つの署名取引先に発行するステップであって;前記署名取引先は、署名されるべきデータを、前記スマートカードに送信し;および前記スマートカードは、署名を生成し、ならびに前記署名を、前記署名取引先の証明書と前記発行関係先の証明書とともに戻す、前記ステップとb前記署名されたデータ、前記署名取引先の証明書、および前記発行関係先の証明書を、前記少なくとも一つの信用取引先に送信するステップであって;前記少なくとも一つの信用取引先は、前記署名されたデータの前記署名を確認し、および前記署名取引先の証明書および前記発行関係先の証明書を含む、オンライン証明書ステータスプロトコルOCSP要求を作成し;および前記OCSP要求は、署名のためにハードウェアセキュリティモジュールに送信されている、前記署名取引先の証明書および前記発行関係先の証明書を含み;および前記ハードウェアセキュリティモジュールは、署名ならびに前記信用取引先の証明書を戻す前記ステップと;c前記署名取引先の証明書および前記発行関係先の証明書を含む前記OCSP要求を、前記信用取引先の証明書とともに、前記信用関係先のトランザクションコーディネータに送信するステップであって;前記信用関係先のトランザクションコーディネータは、前記要求を処理する前に、前記要求が、現存の信用取引先によって署名されたことを確認するために、取引先データベースをチェックし;および前記信用関係先のトランザクションコーディネータは、未処理トランザクションデータを未処理トランザクションログに記憶し、および請求データを請求ログに記憶し;および前記信用関係先のトランザクションコーディネータは、前記サービス要求とともに送信された、前記信用取引先の証明書を用いて、前記サービス要求における前記信用取引先の署名を確認し;および前記信用関係先の証明書およびルートパブリックキーであって、その両方が、そのハードウェアセキュリティモジュールに記憶され;および前記信用関係先のトランザクションコーディネータは、前記信用取引先の証明書を含むOCSP要求を生成し、それに署名をし、およびそれを同じ場所にあるOCSPレスポンダに送信し;および前記OCSPレスポンダは、前記要求における前記信用取引先の署名を確認し、そのローカルレポジトリをチェックし、および応答を、前記信用関係先のトランザクションコーディネータに返し;および前記信用関係先のOCSPレスポンダは、前記署名取引先の証明書に対する要求を生成し、それに署名し、およびそれを、前記信用関係先の証明書とともに、前記発行関係先に送信する前記ステップと;d前記発行関係先のトランザクションコーディネータによる、前記署名取引先証明書に対する前記要求を受信するステップであって;前記発行関係先のトランザクションコーディネータは、前記要求を処理する前に、現存する署名取引先が前記サービス要求に署名したことを確認するために、その取引先データベースをチェックし;および前記発行関係先のトランザクションコーディネータは、前記未処理トランザクションデータを、その未処理トランザクションログに記憶し;および前記発行関係先のトランザクションコーディネータは、前記要求に対する請求データを、その請求ログに記憶し;および前記発行関係先のトランザクションコーディネータは、前記要求とともに送信される前記信用関係先のトランザクションコーディネータの証明書と、および前記発行関係先のトンラザクションコーディネータのハードウェアセキュリティモジュールに記憶される、前記ルートパブリックキーを用いることによって、前記要求における前記信用関係先のトランザクションコーディネータの署名を確認し;および前記発行関係先のトランザクションコーディネータは、前記信用関係先の証明書に対する、署名されたOCSP要求を生成し、およびそれを、前記ルートのトランザクションコーディネータに送信する前記ステップと;e前記ルートのトランザクションコーディネータによる、前記信用関係先の証明書に対する前記要求を受信するステップであって、前記ルートのトランザクションコーディネートは、前記未処理トランザクションデータを、その未処理トランザクションログに記憶し、および請求データをその請求ログに記憶する前記ステップであって;および前記ルートのトランザクションコーディネータは、前記要求における前記署名を確認し、および前記要求を、そのOCSPレスポンダに送信し;および前記ルートのOCSPレスポンダは、そのローカルレポジトリをチェックし、および応答を、ルートのトランザクションコーディネータに返し;および前記ルートのトランザクションコーディネータは、署名された応答を、前記発行関係先のトランザクションコーディネータに送信する前記ステップと;f前記発行関係先のトランザクションコーディネータによる前記応答を受信するステップであって、前記発行関係先のトランザクションコーディネータは、否認防止の目的で、前記応答を、その未処理トランザクションログに記憶し;および前記発行関係先のトランザクションコーディネータは、前記署名取引先の証明書を含む、それが受信した前記要求から、OCSP要求を生成し、それに署名をし、およびそれ自らの証明書とともに、それを前記発行関係先のOCSPレスポンダに送信し;および前記発行関係先のOCSPレスポンダは、前記要求における前記署名を確認し、応答を生成し、それに署名し、および前記署名された応答を、前記発行関係先のトランザクションコーディネータに返し;および前記発行関係先のトランザクションコーディネータは、前記OCSPレスポンダの署名を確認し、前記応答に再署名し、およびそれ自らの証明書とももに、それを、前記信用関係先のトランザクションコーディネータに返す前記ステップと;g前記信用関係先のトランザクションコーディネータによる応答を受信するステップであって、前記信用関係先のトランザクションコーディネータは、否認防止の目的で、前記未処理応答データを、その未処理トランザクションログに記憶し;および前記信用関係先のトランザクションコーディネータは、前記発行関係先トランザクションコーディネータの証明書、およびそのハードウェアセキュリティモジュールに記憶されている前記ルートパブリックキーを用いて、前記応答における前記署名を確認し;および前記信用関係先のトランザクションコーディネータは、前記発行関係先の証明書に対するOCSP要求を生成し、およびそれを、前記ルートのトランザクションコーディネータに送信する前記ステップと;h前記ルートのトランザクションコーディネータによる要求を受信するステップであって、前記ルートのトランザクションコーディネータは、前記未処理要求データをその未処理トランザクションログに記憶し、および前記請求データを、その請求ログに記憶し;および前記ルートのトランザクションコーディネータは、前記要求における前記署名を確認し;および前記ルートのトランザクションコーディネータは、前記要求を、そのOCSPレスポンダに送信し;および前記ルートのOCSPレスポンダは、そのローカルレポジトリをチェックし、および応答を、前記ルートのトランザクションコーディネータに返し;および前記ルートのトランザクションコーディネータは、前記応答を、前記信用関係先のトランザクションコーディネータに送信する前記ステップと;i前記信用関係先のトランザクションコーディネータによる前記応答を受信するステップであって、前記信用関係先のトランザクションコーディネータは、否認防止の目的で、前記応答を、その未処理トランザクションログに記憶し;および前記信用関係先のトランザクションコーディネータは、前記発行関係先の証明書に対する、署名されたOCSP要求を生成し、およびそれを、前記ルートのトランザクションコーディネータに送信する前記ステップと;j前記ルートのトランザクションコーディネータによる前記要求を受信するステップであって、前記ルートのトランザクションコーディネータは、前記未処理要求データを、その未処理トランザクションログに記憶し;および前記ルートのトランザクションコーディネータは、関連する請求データを、その請求ログに記憶し;および前記ルートのトランザクションコーディネータは、前記要求における前記署名を確認し、および前記要求を、そのOCSPレスポンダに送信し;および前記ルートのOCSPレスポンダは、そのローカルレポジトリをチェックし、および応答を、前記ルートのトランザクションコーディネータに返し;および前記ルートのトランザクションコーディネータは、署名された応答を、前記信用関係先のトランザクションコーディネータに送信する前記ステップと;k前記信用関係先のトランザクションコーディネータによる前記応答を受信するステップであって、前記信用関係先のトランザクションコーディネータは、否認防止の目的で、前記応答を、その未処理トランザクションログに記憶し;および前記信用関係先のトランザクションコーディネータは、前記発行関係先のトランザクションコーディネータから受信された前記応答からOCSP応答を生成し、それに署名をし、およびそれを、前記信用関係先の証明書とともに信用取引先に送信する前記ステップと;l前記信用取引先による前記応答を受信するステップであって、前記信用取引先は、そのハードウェアセキュリティモジュールに記憶された前記ルートのパブリックキー証明書を用いて、前記応答を確認し;および前記証明書が取り消されたか決めるために、前記信用取引先は、前記信用関係先の証明書に対する要求を送信する前記ステップと;m前記信用関係先のトランザクションコーディネータによる前記要求を受信するステップであって、前記信用関係先のトランザクションコーディネータは、前記要求における前記署名を確認し、および前記信用取引先の証明書が取り消されなかったことを確証するために、要求を、そのローカルOCSPレスポンダに送信し;および前記信用関係先のローカルOCSPレスポンダは、前記信用関係先のトランザクションコーディネータに、応答を返し;および前記信用関係先のトランザクションコーディネータは、前記信用関係先の証明書における要求を、前記ルートのトランザクションコーディネータに送信する前記ステップと;n前記ルートのトランザクションコーディネータによる前記要求を受信するステップであって、前記ルートのトランザクションコーディネータは、前記要求における前記署名を確認し、および前記信用関係先の証明書のステータスを決めるために、そのローカルOCSPレスポンダと照合し;および前記ルートのトランザクションコーディネータは、そのローカルOCSPレスポンダから受信された前記応答を、前記信用関係先のトランザクションコーディネータに転送する前記ステップとo前記信用関係先のトランザクションコーディネータによる前記応答を受信するステップであって、前記信用関係先のトランザクションコーディネータは、前記応答を、前記信用取引先に転送する前記ステップとp前記信用取引先による前記応答を受信するステップであって、前記信用取引先は、前記署名取引先に受領通知をする前記ステップとを具備する前記方法。ネットワークを介して、一つ以上のサービスを供給するためのシステムであって:ルートエンティティであって、ルートエンティティ認証局を操作し、前記ルートエンティティ認証局に対するルートエンティティコンフィギュレーションベースラインを維持し、前記ルートエンティティコンフィギュレーションベースラインは、前記ルートエンティティ認証局の動作環境を含む、前記ルートエンティティと;少なくとも一つのレベル1関係先であって、レベル1認証局を操作し、前記レベル1認証局に対するコンフィギュレーションベースラインを維持し、前記レベル1認証局に対する前記コンフィギュレーションベースラインは、前記レベル1認証局の動作環境を含む、前記レベル1関係先と;少なくとも一つのレベル2関係先であって、レベル2認証局を操作し、前記レベル2認証局に対するコンフィギュレーションベースラインを維持し、前記レベル2認証局に対する前記コンフィギュレーションベースラインは、前記レベル2認証局の動作環境を含む、前記レベル2関係先と;を具備する前記システム。各エンティティの認証局の前記コンフィギュレーションベースラインは、ある形式で記録されることを特徴とする、請求項3に記載のシステム。各エンティティのコンフィギュレーションベースラインのコピーは、前記ルートエンティティによって維持されることを特徴とする、請求項3に記載のシステム。コンフィギュレーションマネージャをさらに具備する、請求項3に記載のシステムであって、前記コンフィギュレーションマネージャは、前記ルートエンティティの役員であり、さらに、前記システム内のコンフィギュレーション管理に第一の責任を有する、前記システム。各認証局は、技術操作スタッフを具備し、前記技術操作スタッフは、エンティティ認証局のコンフィギュレーションの記録を管理することに対して第一の責任を有することを特徴とする、請求項3に記載のシステム。各エンティティの認証局に対する前記コンフィギュレーションベースラインは、前記エンティティの認証局の同じ物理的ロケーションに維持されることを特徴とする、請求項3に記載のシステム。各エンティティの認証局に対する前記コンフィギュレーションベースラインは、前記エンティティの認証局の前記物理的ロケーションの外部の、安全なロケーションに維持されることを特徴とする、請求項3に記載のシステム。各エンティティの認証局に対する前記コンフィギュレーションベースラインは、オフサイトロケーションに維持されることを特徴とする、請求項3に記載のシステム。システム要件に取り組むために、エンティティの認証局の前記コンフィギュレーションベースラインに変更がなされることを特徴とする、請求項3に記載のシステム。影響を受ける当事者は、エンティティの認証局の前記コンフィギュレーションベースラインへの変更を通知されることを特徴とする、請求項3に記載のシステム。エンティティの認証局の前記コンフィギュレーションベースラインへの変更は、統治機関によって示されるコンフィギュレーション変更基準を考慮することを特徴とする、請求項3に記載のシステム。エンティティの認証局の前記コンフィギュレーションベースラインへの変更は、基準設定機関によって示されるコンフィギュレーション変更基準を考慮することを特徴とする、請求項3に記載のシステム。少なくとも一つのルートエンティティ、少なくとも一つの発行関係先、および少なくとも一つの信用関係先を含む複数のエンティティを含むネットワークを介して、証明書ステータスチェックを供給するステップであって、各エンティティは:トランザクションコーディネータと;オンライン証明書ステータスプロトコルレスポンダであって、証明書のステータスをチェックし、前記トランザクションコーディネータから、オンライン証明書ステータス要求を受信し、オンライン証明書ステータス応答を、前記トランザクションコーディネータに送信する、前記オンライン証明書ステータスプロトコルレスポンダと;および少なくとも一つのハードウェアセキュリティモジュールとを具備する、前記システム。前記オンライン証明書ステータスプロトコルレスポンダは、チェックされた証明書に関連する取り消された応答を送信することを特徴とする、請求項15に記載のシステムであって、前記取り消された応答は、前記証明書、すなわち前記証明書の証明書チェーンにおける一つの証明書が、特定の時間よりも前に取り消されたことを示す、前記システム。前記発行関係先は、前記チェックされた証明書に対応するプライベートキーを用いて、前記特定の時間の後に署名されたドキュメントに対する責任を受け入れないことを特徴とする、請求項16に記載のシステム。前記オンライン証明書ステータスプロトコルレスポンダは、チェックされた証明書に関連する良い応答を送信することを特徴とする、請求項15に記載のシステムであって、前記良い応答は、前記証明書および前記証明書の前記証明書チェーンにおける一つおきの証明書が、特定の時間においてすでに支払い済みであることを示す、前記システム。前記発行関係先は、前記チェックされた証明書に対応するプライベートキーを用いて、前記特定の時間の前に署名されたドキュメントに対する責任を受け入れることを特徴とする、請求項18に記載のシステム。前記オンライン証明書ステータスプロトコルレスポンダは、証明書に関する不明応答を送信することを特徴とする、請求項15に記載のシステムであって、前記不明応答は、前記証明書、すなわち前記証明書の前記証明書チェーンにおける一つの証明書が、特定の時間において、支払済みであることが不明であることを示す、前記システム。前記発行関係先は、前記チェックされた証明書に対応するプライベートキーを用いて、前記特定の時間より前に署名されたドキュメントに対する責任を受け入れないことを特徴とする、請求項20に記載のシステム。前記オンライン証明書ステータスプロトコルレスポンダは、そのプライベートキーを、ハードウェアセキュリティモジュールに記憶することを特徴とする、請求項15に記載のシステム。前記オンライン証明書ステータスプロトコルレスポンダは、前記ルートエンティティによって確立された、一組の最小セキュリティ要件に適合することを特徴とする、請求項15に記載のシステム。第一の関係先、第二の関係先、第一の取引先、および第二の取引先を具備するシステムであって、前記第一の取引先は、前記第一の関係先の取引先であり、前記第二の取引先は、前記第二の関係先の取引先であり、各エンティティは、デジタル証明書および関連するプライベートキーを供給される前記システムにおいて、証明書を認可するための方法は:a前記第一の取引先が、そのプライベートキーでデータに署名をし;b前記第一の取引先が、前記署名されたデータを、前記第二の取引先に送信し;c前記第二の取引先が、前記第一の取引先の証明書に対する認可要求を生成し;d前記第二の取引先が、前記第一の取引先の証明書に対する前記認可要求を、前記第二の関係先に送信し;e前記第二の関係先が、前記認可要求を前記第一の関係先に転送し;f前記第一の関係先が、前記認可要求に対する応答を、前記第二の関係先へ送信し;およびg前記第二の関係先が、前記応答を、前記第二の取引先に送信することを具備する前記方法。前記第二の取引先は、前記認可要求に署名するために、ハードウェアセキュリティモジュールを使用することを特徴とする、請求項24に記載の方法。各関係先は、否認防止のために、前記認可要求に関するデータを記憶することを特徴とする、請求項24に記載の方法。各関係先は、請求のために、前記認可要求に関するデータを記憶することを特徴とする、請求項24に記載の方法。各関係先は、前記要求を処理する前に、前記認可要求が、承認されたエンティティから受信されたことを確認するために、取引先データベースをチェックすることを特徴とする、請求項24に記載の方法。各関係先は、前記認可要求を生成するために、オンライン証明書ステータスプロトコルレスポンダを使用することを特徴とする、請求項24に記載の方法。第一の関係先、第二の関係先、第一の取引先、および第二の取引先を具備するシステムであって、前記第一の取引先は、前記第一の関係先の取引先であり、前記第二の取引先は、前記第二の関係先の取引先であり、各エンティティはデジタル証明書および関連するプライベートキーを供給される前記システムにおいて、保証サービスを供給する方法は:a前記第一の取引先が、そのプライベートキーでデータに署名をし;b前記第一の取引先が、前記署名されたデータおよびその証明書を、前記第二の取引先に送信し;c前記第二の取引先が、前記第一の取引先の証明書に対する保証要求を生成し;d前記第二の取引先が、前記保証要求を、前記第二の関係先に送信し;e前記第二の関係先が、前記保証要求を、前記第一の関係先に転送し;f前記第一の関係先が、保証を発行するべきか否かを決定し;g前記第一の関係先が、前記決定を、前記第二の関係先に送信し;およびh前記第二の関係先は、前記決定を、前記第二の取引先に送信することを具備する前記方法。前記第二の取引先は、前記保証要求に署名をするために、ハードウェアセキュリティモジュールを使用することを特徴とする、請求項30に記載の方法。各関係先は、否認防止のために、前記保証要求に関するデータを記憶することを特徴とする、請求項30に記載の方法。各関係先は、請求のために、前記保証要求に関するデータを記憶することを特徴とする、請求項30に記載の方法。各関係先は、要求を処理する前に、前記要求が承認されたエンティティから受信されたことを確認するために、取引先データベースをチェックすることを特徴とする、請求項30に記載の方法。ルートエンティティ、第一の関係先、第二の関係先、第一の取引先、および第二の取引先を具備するシステムであって、前記第一の取引先は、前記第一の関係先の取引先であり、前記第二の取引先は、前記第二の関係先の取引先であり、各エンティティは、デジタル証明書および関連するプライベートキーを供給される前記システムにおいて、証明書を認可するための方法は:a前記第二の取引先が、前記第二の関係先の証明書を含む認可要求を生成し;b前記第二の取引先が、前記第二の関係先の証明書を含む前記認可要求を、前記第二の関係先に送信し;c前記第二の関係先が、前記第二の関係先の証明書に対する認可要求を生成し;d前記第二の関係先が、前記第二の関係先の証明書を含む前記認可要求を、前記ルートエンティティに送信し;e前記ルートエンティティは、前記認可要求に対する応答を、前記第二の関係先に送信し;およびf前記第二の関係先は、前記応答を、前記第二の取引先に送信することを具備する前記方法。前記第二の関係先は、前記認可要求を生成するために、オンライン証明書ステータスプロトコルレスポンダを使用することを特徴とする、請求項35に記載の方法。しかし、送信者の公開鍵は、受信者には先験的に分からない場合がある。この場合、送信者は証明機関から発行されるデジタル証明書を署名付きメッセージと一緒に送信できる。証明書は、それ自身、特定の公開鍵が送信者の公開鍵であることを証明する、署名付き電子文書証明機関の秘密鍵を署名したである。時として、受信者は、認証機関の公開鍵に慣れていない場合があり、又は受信者は、証明書が依然として有効か否かが分からない場合がある。この場合、受信者は、信任をおこなうエンティティを用いて証明書の信憑性と有効性を調べようとする。公知の1つのプロトコルとして、証明書のステータスを調べるためのオンライン証明書ステータスプロトコルOCSPがある。本発明は、証明書の検証及び保証を含む証明書関連サービス及び他のサービスを安全に提供することによって、電子商取引を容易にするシステム及び方法を開示する。好適な実施形態において、このサービスは、4コーナー信用モデルのコンテキスト内で提供される。4コーナーモデルは、オンライン取引に従事する、署名取引先と呼ばれる買い手と、信用取引先と呼ばれる売り手とを含んでいる。買い手は、発行関係先と呼ばれる第1の金融機関の取引先である。発行関係先は、買い手の証明機関としての機能を果たし、買い手に秘密鍵及び発行関係先が署名したデジタル証明書を含むハードウェアトークンを発行する。売り手は、信用関係先と呼ばれる第2の金融機関の取引先である。信用関係先は、売り手に対する証明機関としての機能を果たし、買い手に秘密鍵及び信用関係先が署名したデジタル証明書を含むハードウェアトークンを発行する。取引時に、買い手は、取引データハッシュを生成し、ハッシュに署名し、売り手に取引データ、署名、及びそのデジタル証明書を送る。次に、売り手は、金融機関、信用関係先との通信によりシステムサービスを要求できる。好適な実施形態において、本システムサービスは、証明書ステータス照合サービス及び保証サービスを含むことができる。証明書ステータス照合サービスにより、信用関係先は、署名取引先の証明書を検証できる。保証サービスにより、信用取引先は、署名取引先の証明書が有効であるという担保裏書保証を受け取る。これらのサービスを提供する詳細なメッセージフローは以下の詳細な説明に示されている。好適な実施形態において、各々の関係先及びルートエンティティは、サービス及び業務を、原子性、一貫性、独立性、及び耐久性の特性をもつ単一の取引と組み合わせるための取引コーディネータートランザクションコーディネータに提供される。取引コーディネーターは、他のサービスに関連するメッセージ及びリクエストと同時に、証明書ステータスメッセージ及びリクエストに関する、単一の一貫性のあるインターフェイスを提供する。結果として、本発明は、必要な柔軟性を提供し、検査及び否認防止目的のための複数の提示サービスに関連する取引情報の集中的且つ一貫性のある取得を可能にする。更に、本発明は、付加的サービスの統合化と、それらのサービスを取引先に提供することを容易にする。本発明の取引コーディネーターは、単一のインターフェイスを備え、銀行間又は他の金融機関間の、又は、銀行又は金融機関と取引先との間の電子商取引を容易にするようになっている。また、取引コーディネーターは、取引先に対する単一の入口点を提供して証明書照合サービスを得るようになっており、更に柔軟性を提供して、単一の入口点を提供しながら保証サービス、支払いサービス、又は証明付きメールサービス等の新規なビジネス用途を付加するようになっている。生成された付加的サービスをサポートするために、容易に拡張できるよう設計されることが好ましい。本発明の取引コーディネーターは、現行のメッセージインフラストラクチャに対する解析、フロー制御、エラー処理を提供し、適切なシステムサービスに対するメッセージコンポーネントの手順を指示するためのメッセージスイッチとしての機能を果たす例えば、OCSP応答システム、保証エンジン等。更に、取引コーディネーターは、これらのサービスからの応答を統合された応答に順序正しくまとめ、応答を要求クライアントに送る。また、本発明の取引コーディネーターは、証明書照合サービス又は他のサービスに関する請求書発行データを集中的な一般方式で記録する。全ての銀行及び他の金融機関には、請求書発行に対する要求があるので、請求書発行データは、書き込み単純抽出機能よって、個々の金融機関のニーズに合わせて抽出及び修正できるようになっている。また、本発明の取引コーディネーターでは、銀行又は他の金融機関は、必要に応じて異なる形式の取引に対して互いに相互課金を行うことができる。更に、本発明の取引コーディネーターでは、市販規格品のソフトウエアアプリケーションを組み込むことができ、電子的に署名して文書を証明するための単一の電子署名サービスを提供できる。更に、本発明の取引コーディネーターは、全ての主要サービスを分離するので、コンポーネントの再利用を容易にして、これらのサービスの保守及び機能強化を単純化する。本発明の取引コーディネーターは、それを非標準にさせてベンダー固定と実行遅れをもたらすこともある、オンライン証明書照合機能性の交換を必要としない。本発明の前述及び他の目的、特徴、及び利点は、以下の詳細な説明及び添付図面を参照することにより理解できる。本発明は、金融機関が取引先に対して電子証明書ステータス照合及び他のサービスを安全に実行することを容易にするシステムに関する。好適な実施形態において、本発明のシステムは、これらのサービスを提供するためのコーナー信用モデルを使用する。図1は、本発明で使用する4コーナー信用モデルの好適な実施形態を示す。図1に示すように、4コーナーモデルは、第1の機関102と第2の機関104とを含んでいる。第1の機関102は、本システムの関係先であり、取引先にスマートカードを発行するという理由で、以下では発行関係先と呼ぶ。第2の機関104は、本システムの関係先であり、取引先は発行関係先102及び発行関係先102の取引先によってなされる表示を信用するという理由で、以下では信用関係先と呼ぶ。また、図1には、第1の取引先106と第2の取引先108とが示されている。第1の取引先106及び第2の取引先108は、それぞれ発行関係先102及び信用関係先104の取引先であることが好ましい。第1の取引先106は、発行関係先102により提供されるサービスに署名するという理由で署名取引先と呼ぶ。第2の取引先108は、発行関係先102及び署名取引先106によってなされる表示を信用するという理由で、信用取引先と呼ぶ。また、図1には、ルートエンティティ110が示されている。ルートエンティティ110は、典型的には、電子商取引及び電子通信を容易にするための運用ルールの共通セットを制定して施行する組織である。ルートエンティティ110は、運用ルールに従うことに同意した複数の銀行及び/又は他の金融機関が共同保有できる。このようなルートエンティティの例示的な1つの実施形態は、2000年2月11日に出願された係属中の米国特許出願第09/502,450号MethodforCertification-RelatedandOtherServicesに説明されており、その開示内容は、引用により本明細書に組み込まれている。図2は、4コーナーモデルのエンティティに設けるのが好ましいコンポーネントを示すブロック図である。図2に示すように、関係先102、104及びルートエンティティ110の各々は、本システムが提供するサービスに関連する、全てのエンティティ間のメッセージを送受信するためのゲートウェイとして機能する、取引コーディネーター202を備えている。以下に更に詳細に説明するように、取引コーディネーター202は、発行関係先102及び信用関係先104のオンラインサービスに対する単一のインターフェイスと、取引コーディネーター202と4コーナーモデルの他のエンティティとの間の安全な電子通信を保証するのに必要な装置用安全機能とを備えている。取引コーディネーター202の1つの好適な実施形態を図3から図6を参照して以下に詳細に説明する。関係先102、104及び信用関係先104の各々は、更にOCSPレスポンダ204及びハードウェアセキュリティモジュールHSM206を備えることが好ましい。OCSPレスポンダ204に関する例示的な要件を以下に説明する。HSM206は、図6を参照して以下に説明するように、メッセージに署名を行い、メッセージに対する署名を証明するようになっている。更に、関係先102、104及び信用関係先104の各々は、請求書発行データデータベース208関係先102、104の場合は、銀行の請求書発行アプリケーション210に接続される、未処理取引ログ212、取引先データデータベース214、リスクマネージャ216取引先データデータベース214に接続される、及び第2のハードウェアセキュリティモジュール218を更に備えることが好ましく、それぞれ取引コーディネーター202に接続されている。図2に示すように、信用取引先108は、インターネットを介して情報を送受信するようになったWebサーバー220を更に備えることが好ましい。信用取引先108は、以下に詳細に説明するように、信用関係先104と通信を行うための銀行インターフェイス222を更に備えることが好ましい。銀行インターフェイス222信用関係先に設けるのが好ましい追加コンポーネントと同様にの1つの好適な実施形態は、本出願と同時出願の係属中の米国特許出願番号09/657,604号SystemandMethodforFacilitatingAccessBySellerstoCertificate-RelatedandOtherServicesに説明されており、その開示内容は、引用により本明細書に組み込まれている。信用取引先108は、システムメッセージに署名及び証明を行うためのハードウェアセキュリティモジュール230を更に備えることが好ましい。図2に示すように、署名取引先106は、以下に説明するように、インターネットを見るためのWebブラウザ224と、デジタルメッセージを署名するためのスマートカード226及び関連の読み取り装置を備えことが好ましい。好適な実施形態において、各々のシステムエンティティは、認証を容易にするために、身元証明書保証証明書と呼ぶ場合もあると、ユーティリティ証明書である2つのデジタル証明書及び関連の秘密鍵を備えることが好ましい。更に、好適な実施形態において、各々の取引コーディネーター202は、自身の身元証明書、実用証明書、及び関連の秘密鍵を備えることが好ましい。身元秘密鍵は、電子商取引の内容に対するエンティティの契約責務の証拠としてルートエンティティ110が要求する電子署名を生成するのに利用される。証明書チェーンは、この鍵を使用する操作をサポートするのに必要である。以下に説明するように、身元証明書のステータスは、認証エンティティが取得してもよい。ユーティリティ秘密鍵は、追加的取引のセキュリティを与える電子署名を生成するのに利用される。典型的に、ユーティリティ秘密鍵は、セキュアソケットレイヤーSSLをサポートするために、S/MIMEメッセージに署名するために、及び他のユーティリティアプリケーションのために使用される。また、認証チェーンは、ユーティリティ秘密鍵を使用する操作をサポートするために必要である。しかし、ユーティリティ証明書のステータスは、リクエスタには利用できなくてもよい。本明細書の全範囲にわたって、用語証明書は、特に断らない限り身元証明書を呼ぶ。好適な実施形態において、署名取引先106のデジタル証明書及び関連の秘密鍵は、発行関係先102から署名取引先に与えられる。発行関係先102は、署名取引先106に対して、少なくとも署名取引先の身元証明書に関連する秘密鍵を含むスマートカード又は他の適切な手段を発行することが好ましい。所望であれば、スマートカードは、同様に署名取引先の身元証明書を含んでいてもよい。スマートカードに関する好適な仕様、その製造方法、及びその内容は、2000年8月14日に出願された係属中の米国特許仮出願第60/224,994号SigningInterfaceRequirements,SmartCardComplianceRequirements,andAdditionalDisclosureに説明されており、その開示内容は、引用により本明細書に組み込まれている。図3は、取引コーディネーター202の好適な実施形態を示すブロック図である。図3に示すように、取引コーディネーター202は、2つのコンポーネント、即ちTCリクエストマネージャ304と転送サービスコンポーネント306とを有するインターフェイス302を備えている。インターフェイス302は、複数のサービスモジュール308及びコアコンポーネント310との間で送受信を行う。サービスモジュール308は、証明書ステータス照合モジュール312、保証モジュール314、支払い保証サービス316、及び他のサービス318を含むことが好ましい。コアコンポーネント310は、ロギングコンポーネント320、請求書発行コンポーネント322、及び署名コンポーネント324を含むことが好ましい。転送サービスコンポーネント306は、取引コーディネーターへの単一の入口点を備え、リクエスタ、取引コーディネーターのサービスモジュール、及びコアコンポーネントとの間の分離レイヤーとしての機能を果たす。TCリクエストマネージャ304は、以下に詳細に説明するように、転送サービスコンポーネント306からのサービスリクエストを受け取り、それを適切なサービスモジュール及び/又はコアコンポーネントへ転送する。証明書ステータス照合モジュール312の機能は、図2におけるシステム内のエンティティの証明書を検証することである。保証モジュール314の機能は、特定のビジネス取引に関連する電子通信に署名を行うエンティティの身元を保証することである。好適な実施形態において、保証を行う典型的には発行関係先102である関係先は、署名取引先の秘密鍵により生成されるデジタル署名を署名取引先106が履行しなかったことが判明した場合に、いくらかの又は全ての取引金額に対する金融上の責任を引き受ける。支払い保証サービス316の機能は、信用取引先108に署名取引先106の金融債務の履行能力に関する即時確認を提供することによって、取引に関連するリスクを更に低減することである。更に、発行関係先102は、何らかの理由で署名取引先106が信用取引先108への支払いを滞納した場合に、いくらか又は全ての取引金額に対する支払い保証を発行してもよい。また、支払いサービスは、本出願と同日に出願された係属中の米国特許出願第09/657,622号SystemandMethodforProvidingPaymentServicesinElectronicCommerceに説明されているようにして行ってもよく、この開示内容は、引用により本明細書に組み込まれている。証明付きメールサービス318の機能は、オフライン取引をサポートするものである。オフライン取引は、即座にリクエストを提供する代わりに、受信エンティティがリクエストを処理待ち行列状態で出す場合に起こる。典型的に、受信確認通知は、リクエスタに送信される。このシナリオは、取引量が非常に多く、全てのリクエストに対してオンライン応答を行うことができない場合に実行されることが好ましい。証明付きメールサービス318は、信用取引先108と信用関係先104との間、信用関係先104と発行関係先102との間、及び任意のルートエンティティ110間のリクエストを満たすために使用することが好ましい。ロギングコンポーネント320の機能は、否認防止及びセキュリティ検査を目的として、未処理の取引ログ58図5参照における全てのサービスリクエスト及びOCSP応答を記録することである。請求書発行コンポーネント322は、取引コーディネーター202が受け取ったメッセージ応答及びリクエストに対する請求書発行履歴を生成して格納することである。このモジュール及びコンポーネントの好適な操作を以下に詳細に説明する。図4は、ブロック図/フローチャートを組み合わせたものであり、好適な実施形態における取引コーディネーター操作を示す。図4に示すように、ステップ4002で、取引コーディネーター202の転送サービスコンポーネント306は、他のシステムエンティティからのサービスリクエストを受け取り、リクエストマネージャ304にそのサービスを転送する。ステップ4002で、リクエストマネージャ304は、サービスリクエスト形式が有効か否かを照合する。サービスリクエスト形式が有効である場合、メッセージ検証モジュール404を呼び出してリクエスタ、請求書発行データ、及びサービスリクエスト形式に関する情報を要求する。メッセージ検証モジュール404は、解析モジュール406を呼び出して未処理サービスリクエストから関連情報を抽出する。ステップ4006で、リクエストマネージャ304は、認証モジュール408を呼び出してリクエスタを認証する。認証モジュール408は以下に詳細に説明する。ステップ4008で、認証モジュール408は、取引コーディネーター202の署名コンポーネント324を呼び出して、即ちハードウェア218を呼び出してリクエスタを認証する。署名コンポーネント324の好適な構造及び操作は以下に詳細に説明する。ステップ4010で、認証モジュール408は、証明書ステータス照合モジュール414を呼び出し、次にOCSPレスポンダ204を呼び出してリクエスタに関する証明書ステータス照合を行う。証明書ステータス照合モジュール414の好適な構造及び操作を以下に詳細に説明する。ステップ4012で、認証モジュール408は、取引先認証照合モジュール418を呼び出し、リクエスタが認定されていることを検証してサービスリクエストを出す。取引先認証照合モジュール418の好適な構成及び操作を以下に詳細に説明する。ステップ4014で、リクエストマネージャ304は、提供されたサービスに対する適切な請求書に必要な、任意の請求書発行データを請求書発行コンポーネント322に送り、請求書発行ログへ記録する。ステップ4018で、リクエストマネージャ304は、サービスリクエストをサービスリクエストルータ426へ送る。ステップ4020で、サービスリクエストルータ426は、適切なサービスモジュール308を呼び出してリクエストを実行する。ステップ4022で、サービスリクエストルータ426は、ステップ4020で呼び出したサービスモジュールからサービス応答を受け取る。サービスリクエストルータ426は、サービス応答をリクエストマネージャ304へ戻し、次にサービス応答を転送サービスコンポーネント306へ送る。転送サービスコンポーネント306は、サービス応答を、サービスリクエストを作るエンティティへ送る。図5は、署名コンポーネント324の好適な操作を示すブロック図/フローチャートを組み合わせたものである。署名コンポーネント324は、スマートカード及びハードウェアセキュリティモジュール等の種々の署名手段に対して単一のインターフェイスを備え、暗号化処理を用いて署名を証明することが好ましい。図5において、ステップ5002で、署名コンポーネント324は、リクエストを受け取ると、署名リクエストであるか又は検証リクエストであるかを決定する。検証リクエストの場合、署名コンポーネント324は、検証リクエストをハードウェアセキュリティモジュール218へ送るステップ5004。ステップ5008で、ハードウェアセキュリティモジュール218は、このリクエストに応答して検証を行い、署名検証応答を署名コンポーネント324へ戻す。リクエストが文書への署名である場合、署名コンポーネント324は、署名に関するリクエストこれは署名を行う文書を含む必要があるをハードウェアセキュリティモジュール218へ送るステップ5006。ステップ5010で、ハードウェアセキュリティモジュール218は、このリクエストに応答して文書に署名し、署名付き文書を署名コンポーネント324へ戻す。最後に、ステップ5012で、署名コンポーネント324は、署名-検証応答又は署名付き文書を、リクエストを行ったコンポーネントへ戻す。図6は、証明書ステータス照合を実行する場合に取引コーディネーター202が実行するステップの好適な操作を示すブロック図/フローチャートを組み合わせたものである。ステップ6002で、証明書照合サービスモジュール312は、サービスリクエストルータ426から未解析の証明書ステータス照合リクエストを受け取り、それをリクエストに応じて関連の取引先情報照合すべき証明書を含むを抽出する解析コンポーネント406へ送る。ステップ6004で、証明書照合サービスモジュール312は、取引先データベース606から任意の追加サービス仕様実行情報を取得する。ステップ6006で、照合すべき証明書が、取引コーディネーター202がリクエストを受け取った関係先の取引先に属する場合、証明書照合サービスモジュール312は、リクエストをローカル取引先ハンドラ602に引き渡す。そうでなければ、証明書照合サービスモジュール312は、リクエストを非ローカル取引先ハンドラ620へ引き渡す。ローカル取引先ハンドラ602がリクエストを引き渡す場合には、システムはステップ6008を実行し、ローカル取引先ハンドラ602は、証明書照合リクエストを証明書照合サービスモジュール312へ送る。次に、証明書ステータス照合コンポーネント312は、関連のOCSPレスポンダ204即ち、証明書ステータス照合コンポーネント312として同じ取引コーディネーター202に属するから、照合すべき証明書に関する証明書ステータスを取得する。この場合のフローは以下のステップ6032に進む。対照的に、照合すべき証明書が、リクエストを受け取った関係先の取引先に属していない場合には、ステップ6010で、非ローカル取引先ハンドラ605は、発行関係先のIPアドレスを調べるが、発行関係先は、静的DNSルックアップテーブル604におけるリクエストの対象である証明書を発行するようになっている。取引コーディネーター202RPは、証明書に関するAIA拡張子を用いて、発行関係先102の場所を識別するようになっていることが好ましい。ステップ6012で、非ローカル取引先ハンドラ610は、対象の証明書をOCSPリクエスト定式化モジュール608へ送る。ステップ6014で、OCSPリクエスト定式化モジュール608は、証明書に対するOCSPリクエストを定式化して、リクエストを署名コンポーネント324へ送る。ステップ6016で、署名コンポーネント324は署名付きリクエストを戻す。ステップ6018で、OCSPリクエスト定式化モジュール608は、署名付きリクエストを、対象の証明書を発行した発行関係先102へ送る。ステップ6020で、発行関係先102は、リクエストに対するOCSP応答をOCSPリクエスト定式化モジュール608へ戻す。ステップ6022で、OCSPリクエスト定式化モジュール608は、応答を非ローカル取引先ハンドラ610へ送る。ステップ6024で、非ローカル取引先ハンドラ610は、未処理応答データを否認防止目的の未処理取引ログ212へ記録する。ステップ6026で、非ローカル取引先ハンドラ610は、未処理応答データを関係先コンポーネント406へ送り、応答に応じて発行関係先102の証明書とその取引コーディネーター202IPを抽出する。ステップ6028で、非ローカル取引先ハンドラ610は、ステップ6012から6024を繰り返すことによって発行関係先102の取引コーディネーター証明書を検証すが、ステップ6014で生成されたOCSPリクエストを、発行関係先102ではなくルートエンティティ110へ送る。同様に、ステップ6030で、非ローカル取引先ハンドラ610は、ステップ6012から6024を繰り返すことによって発行関係先102の証明書を検証すが、ステップ6014で生成されたOCSPリクエストを、発行関係先102ではなくルートエンティティ110へ送る。ステップ6032で、非ローカル取引先ハンドラ610が受け取った、又はローカル取引先ハンドラ602が生成した証明書照合応答データは、応答に署名を行う署名コンポーネント324へ送る。ステップ6034で、署名付き応答は、証明書照合サービスモジュール312に戻され、次に証明書照合サービスモジュール312はこの応答をサービス要求ルータ426へ送る。図7は、証明書を検証するための、システム200内の取引フローの好適な実施形態を示すブロック図/フローチャートを組み合わせたものである。図7に示すように、ステップ7002で、署名取引先106は、署名取引先106と信用取引先108との間の取引を示すデータハッシュを生成し、ハッシュを署名用のスマートカード226へ送る。ステップ7004で、スマートカード226は、データに署名を行い、署名付きデータを、署名取引先106及び発行関係先102の証明書と共に戻す。ステップ7006で、署名取引先106は、署名付きデータ及び2つの証明書を信用取引先108へ送る。ステップ7008で、信用取引先108は、署名取引先106から送られてきたデータに関する署名を検証する。この検証は、受け取った証明書の有効期限の照合を含むことが好ましい。もしくは、検証は、信用関係先104による信用取引先108に対するサービスとして提供されてもよい。次に、信用取引先108は、署名取引先及び関係先の証明書を含むOSCPリクエストを生成し、このリクエストを署名用ハードウェアセキュリティモジュール230へ送る。ステップ7010で、ハードウェアセキュリティモジュール230は署名付きリクエストを戻す。ステップ7012で、信用取引先108は、署名付きOCSPリクエストを自身の証明書と共に信用関係先104へ送る。ステップ7014で、信用関係先104の取引コーディネーター202RPは、署名付きOCSPリクエストを受け取り、取引先データベースを照合して、リクエストを処理する前に、リクエストが実在の信用取引先により署名されていることを確認する。好適な実施形態において、信用関係先104は、異なる関係先の取引先から受け取ったリクエストを処理しない。ステップ7016で、取引コーディネーター202RPは、未処理の取引データ即ち、未解析リクエスト、署名、及び付随の信用取引先証明書を未処理取引ログ212RPへ格納する。ステップ7018で、提供されたサービスに対して適切に請求するのに必要な任意の請求書発行データは、請求書発行ログ208RPへ格納される。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。ステップ7020で、取引コーディネーター202RPは、信用取引先の証明書、信用関係先証明書、及び公開鍵を用いて、サービスリクエストに関する信用取引先の署名を検証する。信用取引先の証明書及び公開鍵は、ハードウェアセキュリティモジュール218RPに格納されることが好ましい。ステップ7022で、取引コーディネーター202RPは、信用取引先の証明書含むOCSPリクエストを発生して、それに署名を行いOCSPレスポンダ204へ送る。もしくは、取引コーディネーター及びOCSPレスポンダが同じ場所に配置される場合は、リクエストに関する署名を必要としないこともある。ステップ7024で、OCSPレスポンダ204は、リクエストの署名を検証し、ローカルリポジトリーを照合して信用取引先の証明書の有効性を決定し、証明書のステータスに関連する応答を取引コーディネーター202RPへ戻す。システム操作の一部として、信用取引先108は、多くの場合、信用関係先104以外の関係先の取引先である署名取引先106の証明書を検証する必要があることに留意されたい。この場合、信用関係先104は、検証すべき証明書を発行する発行関係先ではないので、信用関係先は証明書ステータスの直接の知識をもたない。好適な実施形態において、本システムでは、この問題を、他の関係先が発行した証明書に関するOCSPリクエストを受け取る各々の関係先が、リクエストを証明書に関する発行関係先へ送るようにさせることによって解決する。特にステップ7026において、信用関係先104は、署名取引先の発行関係先を決定する。署名取引先が別の関係先の取引先である場合、信用関係先104は、署名取引先の証明書に関する署名付き検証リクエストを発生し、それを自身の証明書と共に確認済み発行関係先102へ送る。もしくは、検証リクエストに署名するのではなく、代わりに信用関係先は、発行関係先102に対するクライアント側認証手段を備えることもでき、例えば、以下に説明するOCSPプロキシ中心モデルである。署名取引先及び信用取引先の両者が同じ関係先の取引先である場合、署名取引先の証明書の検証は、前述のローカルハンドラモジュール602が行う。ステップ7028で、発行関係先102は、その取引コーディネーター202RPを照合して、リクエストを行うことが認定されているエンティティがリクエストに署名したことを確認する。ステップ7030で、発行関係先102は、受け取った未処理データ即ち、未解析リクエスト、署名、及び付随の信用取引先証明書を未処理取引ログ212RPへ格納する。ステップ7032で、発行関係先102は、リクエストに対する関連の請求書発行データを請求書発行ログ208へ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。ステップ7034で、発行関係先102は、信用関係先の取引コーディネーター証明書リクエストと共に送られたと、ルート公開鍵ハードウェアセキュリティモジュール218IPに格納できるとを用いてリクエストに関する取引コーディネーター202RPの署名を検証する。ステップ7036で、発行関係先の取引コーディネーター202IPは、信用関係先の取引コーディネーター証明書に対する署名付きOCSPリクエストを発生し、このリクエストをルートエンティティ110へ送る。ステップ7038で、ルートエンティティ110の取引コーディネーター202Rは、リクエストを受け取り、未処理リクエストを未処理取引ログ212Rへ格納する。ステップ7040で、取引コーディネーター202Rは、リクエストに対する請求書発行データを請求書発行データログ208Rへ格納する。ステップ7042で、取引コーディネーター202Rは、リクエストの署名を検証し、次に、そのリクエストをOCSPレスポンダ204Rへ送る。ステップ7044で、OCSPレスポンダ204Rは、ローカルリポジトリーを照合して、対象の証明書のステータスを決定し、関連のステータスを取引コーディネーター202Rへ戻す。ステップ7056で、取引コーディネーター202Rは、信頼関係先の取引コーディネーター証明書のステータスを示す、署名付き応答を取引コーディネーター202IPへ送る。ステップ7048で、発行関係先102の取引コーディネーター202IPは、ルートエンティティ110からのOCSP応答を否認防止目的のための未処理取引ログ212IPへ格納する。ステップ7050で、取引コーディネーター202IPは、署名取引先の証明書に関するOCSPリクエストを発生し、それに署名し、自身のローカルOCSPレスポンダ204IPへ自身の証明書と共に送る。もしくは、取引コーディネーター202IP及びOCSPレスポンダ204IPが同じ場所に配置されている場合、リクエストに関する署名を必要としない場合もある。また、2つが同じ場所に配置されている場合、取引コーディネーターは、再署名リクエスト及び応答とは対照的に単なるパススルーとして機能する。ステップ7052で、OCSPレスポンダ204IPは、リクエストに関する署名を検証し、応答を発生し、それに署名し、署名付き応答を取引コーディネーター202IPへ戻す。ステップ7054で、取引コーディネーター202IPは、OCSPレスポンダの証明書を検証し、応答に再署名し、自身の証明書と共に取引コーディネーター202RPへ戻す。ステップ7056で、信用関係先104の取引コーディネーター202RPは、発行関係先102から受け取った未処理応答データを否認防止目的のための未処理取引ログ212RPへ格納する。ステップ7058で、取引コーディネーター202RPは、信用関係先の取引コーディネーター証明書リクエストと共に送られたと、ルート公開鍵ハードウェアセキュリティモジュール218RPに格納できるとを用いて、取引コーディネーター202IPの応答に関する署名を検証する。ステップ7060で、取引コーディネーター202RPは、信用関係先の取引コーディネーター証明書に対する署名付きOCSPリクエストを発生し、それをルートエンティティ110へ送る。ステップ7062で、ルートエンティティ110の取引コーディネーター202Rは、未処理リクエストデータを未処理取引ログ212Rへ格納する。ステップ7064で、取引コーディネーター202Rは、関連の請求書発行データを請求書発行ログ208Rへ格納する。ステップ7066で、取引コーディネーター202Rは、リクエストに関する署名を検証し、リクエストをOCSPレスポンダ204Rへ送る。ステップ7068で、OCSPレスポンダ204Rは、ローカルリポジトリーを照合して発行関係先の取引コーディネーター証明書のステータスを決定し、そのステータスに関する応答を取引コーディネーター202Rへ戻す。ステップ7070で、取引コーディネーター202Rは、対象の証明書のステータスに関する署名付き応答を取引コーディネーター202RPへ送る。ステップ7072で、信用関係先104の取引コーディネーター202RPは、応答を否認防止目的のための未処理取引ログ212RPへ格納する。この時点で、署名取引先の証明書の処理が完了する。ステップ7074で、取引コーディネーター202RPは、ここで応答即ち署名取引先の証明書の後半部を、署名付きOCSPリクエストを発生して、それをルートエンティティ110へ送ることで処理する。ステップ7076で、ルートエンティティ110の取引コーディネーター202Rは、未処理リクエストデータを未処理取引ログ212へ格納する。ステップ7078で、取引コーディネーター202Rは、関連の請求書発行データを請求書発行ログ208へ格納する。ステップ7080で、取引コーディネーター202Rは、リクエストに関する署名を検証し、そのリクエストをOCSPレスポンダ204Rへ送る。ステップ7082で、OCSPレスポンダ204Rは、ローカルリポジトリーを照合して対象の証明書のステータスを決定し、応答を取引コーディネーター202Rへ戻す。ステップ7084で、取引コーディネーター202Rは、署名付き応答を取引コーディネーター202RPへ送る。ステップ7086で、信用関係先104の取引コーディネーター202RPは、ルートエンティティ110からの応答を否認防止目的のための未処理取引ログ212RPへ格納する。ステップ7088で、取引コーディネーター202RPは、発行関係先102の取引コーディネーター202RP及びそのローカルキャッシュからの応答からOCSP応答を生成し、それに署名を行い、自身の証明書と共に信用取引先108へ送る。ステップ7090で、信用取引先108は、ハードウェアセキュリティモジュール230に格納されたルート公開鍵証明書を用いて応答を検証する。ステップ7094で、信用取引先108は、証明書が無効になっていないかを決定するために、信用関係先の取引コーディネーター証明書に対するリクエストを取引コーディネーター202Rへ送る。ステップ7094で、取引コーディネーター202RPは、リクエストに関する署名を検証し、リクエストをローカルOCSPレスポンダ204RPへ送り、信用取引先の取引コーディネーター証明書が無効になっていないことを保証する。ステップ7096で、ローカルOCSPレスポンダ204RPは、取引コーディネーター202RPからのこのリクエストに応答する。ステップ7098で、取引コーディネーター202RPは、信用関係先の取引コーディネーター証明書に対するOCSPリクエストを、ルートエンティティ110の取引コーディネーター202Rへ送る。ステップ7100で、取引コーディネーター202Rは、リクエストに関する署名を検証して、信用関係先の取引コーディネーター証明書のステータスを決定する。ステップ7102で、取引コーディネーター202Rは、ローカルOCSPレスポンダ204Rから受け取った応答を取引コーディネーター202RPへ送る。ステップ7104で、取引コーディネーター202RPは、ルートエンティティ110から受け取った応答を信用取引先108へ送る。ステップ7106で、信用取引先108は、確認通知を署名取引先106へ与える。前述のステップ7092から7104に関連して、システム操作の一部として、信用取引先108は、典型的に、信用関係先の取引コーディネーター証明書のステータスを取得することを必要とする点に留意されたい。4コーナーモデル内で、発行関係先102及び信用関係先104の取引コーディネーター及びOCSPレスポンダ証明書は、ルートエンティティ110により署名される。ルートエンティティ110はOCSPレスポンダを操作するが、このサービスは、関係先だけが利用できる。結果的に、信用取引先108は、信用関係先の証明書の検証をルートエンティティ110に要求できない。好適な実施形態において、本システムは、各々の関係先102、104にルートレスポンダプロキシを操作させることでこの問題を解決する。このプロキシは、典型的には、別の同様のリソースロケータを介して、ルートに代わって取引先からのリクエストを受け入れ、認証されたセキュアソケットレイヤー経路上でリクエストを送り、要求パーティへ戻す。また、前述の4コーナーモデルは、取引に署名した特定のエンティティ例えば署名取引先の身元を保証する保証サービスを提供するのに用いてもよい。このような保証サービスを提供する1つの実施形態は以下に説明される。保証サービスを提供する別の実施形態は、2000年8月14日に出願された係属中の米国特許仮出願第60/224,994号SigningInterfaceRequirements,SmartCardComplianceRequirements,andAdditionalDisclosureに説明されており、その開示内容は、引用により本明細書に組み込まれている。図8は、保証サービスの1つの好適な実施形態の取引フローチャートである。図8に示すように、ステップ8002で、署名取引先106は、署名取引先106と信用取引先108との間のデータハッシュを生成し、このハッシュを署名用のスマートカード226へ送る。ステップ8004で、スマートカード226は、データに署名し、署名を信用関係先の証明書及び信用関係先の証明書と共に戻す。随意的に、このメッセージは、カード及び署名セキュリティデータCSSDを含んでもよく、重複メッセージに対する保護といった追加的なセキュリティを与えるようになっている。ステップ8006で、署名取引先106は、署名付きデータ、署名、署名取引先の証明書、及び発行関係先の証明書随意的にCSSDを信用取引先108へ送る。ステップ8008で、信用取引先108は、署名取引先106が送付したデータに関する署名を検証する。もしくは、検証は、信用関係先104による信用取引先108へのサービスとして提供してもよい。次に、信用取引先108は、保証リクエストを生成し、リクエストを署名用のハードウェアセキュリティモジュール230へ送る。ステップ8010で、ハードウェアセキュリティモジュール230は、署名付きリクエストを信用取引先の証明書のコピーと共に戻す。ステップ8012で、信用取引先108は、署名付き保証リクエスト及び信用取引先証明書を信用関係先104へ送る。ステップ8014で、信用関係先104の取引コーディネーター202RPは、取引先データデータベース214RPを照合して、リクエストを処理する前に、実在の取引先がリクエストに署名したことを確認する。ステップ8016で、取引コーディネーター202RPは、取引に関する即ち未解析リクエスト、署名、及び付随の証明書未処理取引データを未処理取引ログ212RPへ格納する。ステップ8018で、取引コーディネーター202RPは、関連の請求書発行データを請求書発行ログ208RPへ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。ステップ8020で、取引コーディネーター202RPは、信用取引先証明書リクエストと共に送られた、信用関係先証明書、及びルート公開鍵両者ともハードウェアセキュリティモジュール218RPに格納できるを用いて、リクエストに関する関連取引先の署名を検証する。次に、取引コーディネーター202RPは、信用取引先証明書を含むOCSPリクエストを発生し、それに署名してローカルOCSPレスポンダ204RPへ送る。もしくは、取引コーディネーター又はOCSPレスポンダが同じ場所に配置されている場合は、リクエストに関する署名を必要ない場合もある。ステップ8022で、OCSPレスポンダ204RPは、リクエスに対する署名を検証し、信用取引先証明書のステータスに関するローカルリポジトリーを照合し、ステータスに関する応答を取引コーディネーター202RPへ戻す。ステップ8024で、取引コーディネーター202RPは、リスクマネージャ216RPを呼び出し、信用取引先108が保証リクエストを行うことが金融上認可されているか否かを決定する。認可されていれば、次に、ステップ8026で、取引コーディネーター202RPは、署名取引先106に対する保証リクエストに応じることについての関係先の責任を決定する。本実施例において、このエンティティは、発行関係先102である。次に、取引コーディネーター202RPは、署名取引先106に対する保証リクエストを生成し、それに署名し、自身の証明書と共に発行関係先102へ送る。署名取引先及び信用取引先の両者が同じ関係先の取引先である場合には、代わりに保証リクエストを関係先でローカル処理してもよい点に留意されたい。ステップ8028で、取引コーディネーター202IPは、取引先データデータベース214IPを照合してリクエストが、リクエストを行うことを認可されたエンティティにより署名されていることを確認する。ステップ8030で、取引コーディネーター202IPは、未処理取引データ即ち未解析リクエスト、署名、及び付随の証明書を未処理取引ログ212へ格納する。ステップ8032で、取引コーディネーター202IPは、リクエストに対する関連の請求書発行データを請求書発行ログ208IPへ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。ステップ8034で、取引コーディネーター202IPは、取引コーディネーター202RPの証明書リクエストと共に送られた、及びルート公開鍵ハードウェアセキュリティモジュール218IPに格納できるを用いて、リクエストに関する取引コーディネーター202RPの証明書を検証する。次に、取引コーディネーター202IPは、信用関係先取引コーディネーター202証明書に対するOCSPリクエストを発生し、それに署名してルートエンティティ110へ送る。ステップ8036で、ルートエンティティ110の取引コーディネーター202Rは、未処理リクエストを未処理取引ログ212Rへ格納する。ステップ8038で、取引コーディネーター202Rは、リクエストに対する関連の請求書発行データを請求書発行ログ208Rへ格納する。ステップ8040で、取引コーディネーター202Rは、リクエストに関する署名を検証し、次にリクエストをOCSPレスポンダ204Rへ送る。OCSPレスポンダ204Rは、ローカルリポジトリーを照合して信用関係先取引コーディネーター証明書のステータスを決定し、そのステータスに関連する応答を取引コーディネーター202Rへ戻す。次に、取引コーディネーター202Rは、署名付き応答を取引コーディネーター202IPへ戻す。ステップ8042で、発行関係先102の取引コーディネーター202IPは、未処理応答を否認防止目的のための未処理取引ログ212IPへ格納する。ステップ8044で、次に、取引コーディネーター202IPは、受け取ったリクエストから署名取引先証明書を含むOCSPリクエストを発生し、それに署名し、自身の証明書と共にローカルOCSPレスポンダ204IPへ送る。もしくは、取引コーディネーター及びOCSPレスポンダが同じ場所に配置されている場合には、リクエストに関する署名を必要としない場合もある。また、2つが同じ場所に配置されている場合には、取引コーディネーターは、再署名リクエスト及び応答とは対照的に単なるパススルーとして機能する。ステップ8046で、OCSPレスポンダ204IPは、リクエストに関する署名を検証し、応答を発生し、それに署名し、署名付き応答を取引コーディネーター202IPへ戻す。ステップ8048で、取引コーディネーター202IPは、リスクマネージャ216IPを呼び出し、署名取引先106に対する保証書を発行するか否かを決定する。ステップ8050で、リスクマネージャ216IPは、保証書を発行する必要があるか否かを示す署名付きメッセージを取引コーディネーター202IPへ戻す。ステップ8052で、取引コーディネーター202IPは、署名付き応答を未処理取引ログ212IPへ格納する。ステップ8054で、取引コーディネーター202IPは、署名付き応答をルートエンティティ110の取引コーディネーター202RPへ送り、発行関係先102が保証書を発行するに十分な担保を保有しているか否かを決定する。ステップ8056で、取引コーディネーター202Rは、リスクマネージャ216Rと相互作用して、発行関係先102が適切に担保によって保証されているか否かを決定し、保証されている場合、発行関係先102の担保レベルを発行された保証書にふさわしい大きさだけ低減し、応答を発行関係先102へ戻す。ステップ8058で、取引コーディネーター202IPは、取引コーディネーター202Rの署名を検証し、保証応答を生成し、自身の証明書と共に取引コーディネーター202RPへ戻す。ステップ8060で、信用関係先104の取引コーディネーター202RPは、未処理応答を否認防止目的のための未処理取引ログ212へ格納する。ステップ8062で、取引コーディネーター202RPは、取引コーディネーター202IPの証明書リクエストと共に送られた、及びルート公開鍵ハードウェアセキュリティモジュール218RPに格納できるを用いて、応答に関する取引コーディネーター202IPの署名を検証する。次に、取引コーディネーター202RPは、発行関係先の取引コーディネーター証明書に対する署名付きOCSPリクエストを生成し、それをルートエンティティ110へ送る。ステップ8064で、ルートエンティティ110の取引コーディネーター202Rは、未処理リクエストを未処理取引ログ212Rへ格納する。ステップ8066で、取引コーディネーター202Rは、関連の請求書発行データを請求書発行ログ208Rへ格納する。ステップ8068で、取引コーディネーター202Rは、リクエストに関する署名を検証する。次に、取引コーディネーター202Rは、リクエストをOCSPレスポンダ204Rへ格納する。OCSPレスポンダ204Rは、そのローカルリポジトリーを照合して対象の証明書のステータスを決定し、応答を取引コーディネーター202Rへ戻す。次に、取引コーディネーター202Rは、署名付き応答を取引コーディネーター202RPへ送る。ステップ8070で、信用関係先104の取引コーディネーター202RPは、未処理応答を否認防止目的のための未処理取引ログ212RPへ格納する。ステップ8072で、取引コーディネーター202RPは、ルートエンティティ110の取引コーディネーター202Rを調べて発行関係先が保証書を発行するだけの十分な担保を保有しているか否かを確認する。ステップ8074で、取引コーディネーター202Rは、未処理リクエストを未処理取引ログ212Rへ格納する。ステップ8076で、取引コーディネーター202Rは、関連の請求書発行データを請求書発行ログ208Rへ格納する。ステップ8078で、取引コーディネーター202Rは、発行関係先102が保証書を発行するだけの十分な担保を保有しているか否かに関連する、イエス又はノー応答を、信用関係先104の取引コーディネーター202RPへ送る。ステップ8080で、取引コーディネーター202RPは、未処理リクエストを否認防止目的のための未処理取引ログ212RPへ格納する。ステップ8082で、取引コーディネーター202RPは、取引コーディネーター202IPから受け取ったリクエストから保証リクエストを生成し、それに署名し、取引コーディネーター202RPの証明書と共に信用取引先108へ送る。ステップ8084で、信用取引先108は、ハードウェアセキュリティモジュール230に格納されたルート公開鍵を用いて応答を検証する。ステップ8086で、信用取引先108は、無効になっているか否かを調べるために、取引コーディネーター202RPの証明書に対するリクエストを取引コーディネーター202RPへ送る。ステップ8088で、取引コーディネーター202RPは、リクエストに関する署名を検証し、応答をOCSPレスポンダ204RPに送り、信用取引先108の取引コーディネーター証明書が無効になっていないことを保証する。ステップ8090で、ローカルOCSPレスポンダ204RPは、その証明書に対するOCSPリクエストを取引コーディネーター202Rへ送る。ステップ8094で、取引コーディネーター202Rは、リクエストに関する署名を検証し、ローカルOCSPレスポンダ204Rを調べて取引コーディネーター202RPの証明書のステータスを決定する。次に、取引コーディネーター202Rは、ローカルOCSPレスポンダ204Rから受け取った応答を取引コーディネーター202RPへ送る。ステップ8096で、取引コーディネーター202RPは、取引コーディネーター202Rから受け取った応答を信用取引先108へ送る。ステップ8098で、信用取引先108は、確認通知を署名取引先106へ送る。好適な実施形態において、各々の取引コーディネーター202は、取引に、取引コーディネーターによって調整された原子性、一貫性、独立性、及び耐久性をもたらす。原子性は、取引を終了するのに必要な全てのアクションが成功するか又は全て失敗すること、即ち取引は分割できない作業単位であることを意味する。一貫性は、取引の実行後に、システムは、正しい状態を保つ、安定状態にある、又は取引の開始を行う状態に戻ることを意味する。独立性は、各々の取引が、同時に実行できる他の取引に影響されないことを意味する。耐久性は、各々の取引の効果が、取引が委ねられた後に不変であることを意味する。原子性、一貫性、独立性、及び耐久性の組み合わせは、ACID特性と呼ぶ場合もある。取引コーディネーター202は、取引処理手続きモニタ又はコンポーネント取引モニタを組み込むことによって、分散コンピューティング環境においてACID特性を備えることが好ましい。好適な取引処理手続きモニタは、BERSystem社のBERTUXEDO、マイクロソフト社のMSMQ、NCR社のTopEnd、及びIBMTransarcのEncinaを含むことができる。好適なコンポーネント取引モニタは、IonaTechnologies社のOrbixOTM、BERSystem社のBEAWebLogicBERを含むことができる。取引コーディネーターが調整する取引ステップの任意の組み合わせは、ACID特性を有する取引を形作るよう組み合わせることができる。1つ又はそれ以上の予め定義された取引は、図5から図7に示す各々の工程に対して与えられる。つまり、例えば、図5に示すリクエストと応答との間に生じるステップは、ACID特性を有する取引を形作るよう組み合わせることができる。好適な実施形態において、取引コーディネーターコンポーネントは、取引処理ライブラリを介して取引処理手続きモニタと相互作用する。実行される取引処理手続きモニタを別の取引処理手続きモニタと置換できる、柔軟なアーキテクチャの実現を容易にするために、ライブラリは、特定ブランドの取引処理手続きモニタを使用していたとしても、取引処理手続きモニタ機能性にアクセスするよう書き込まれていてもよい。前述の各々の取引処理手続きモニタには、本システムの取引コーディネーターの会社に対する適合性に関連する特定の機能がある。例えば、TUXEDO取引処理手続きモニタは、以下のように設計されている。1高性能なメッセージ受け渡しエンジン。2クライアント及びサーバーが分散取引に参加して、アプリケーションに意識させないで2元コミットプロセスを管理することを可能にする、分散取引管理。3ハードウェアホスティングプログラムに無関係に、開発者がBEATUXEDOアプリケーションを書き込むことを可能にする、取引マネージャインターフェイス用アプリケーション。4自動的にアプリケーションの並列コピーを生成して管理し、それらを平等に利用することを保証する、動的作業負荷平衡化。5分散アプリケーションが非同期、非結合様式で同時に作動するのを可能にし、メッセージのコンテキスト、内容、及び日時に基づいてキューに優先順位をつける、取引キューイング。6最もデータを有効に利用できる場所で取引を処理することを可能にするデータ依存ルーチン。7サーバーマネージャが異常処理を再起動して、進行中であった取引をロールバックする、アプリケーション異常、取引異常、ネットワーク異常、及びノード異常からの自動回復。マイクロソフト社のMSMQ取引処理手続きモニタは、以下のように設計されている。1完全なCOMコンポーネントのサポート。2様々なプログラム言語例えば、VisualC、VisualJからのアクセス。3進化したメッセージキューイング利点をもたらす、5つオープン、クローズ、送信、受信、位置指定のAPI。4スライドウインドウプロトコル、回復可能ストレージ、メッセージ配信のための動的経路指定、定期的で順序正しいメッセージ配信。5データベース更新等の他の作動を有する取引内に含むことができる能力。6他のリソースに関する操作を委ねる又は中止して、取引中のデータ保全性を維持する能力。7組み込みメッセージ暗号化、保全性、及び署名サポート。8何れのMSMQイベントが、WindowsNT登録商標セキュリティログの検査記録を生成する必要があるかの指示能力をもつ管理者。典型的に、MSMQは、MSWindowsNT登録商標Server、StandardEdition4.0及びMSWindowsNT登録商標Server、EnterpriseEdition4.0の機能を含む。24クライアント以上のサポート、原価基準ルーチン、及びMSMQConnectorが必要な場合は、MSMQは、NTServer、EnterpriseEdition4.0上で実行するのが好ましい。MSMQは高性能なメッセージ受け渡しエンジンであるが、取引処理手続きモニタに必要な機能を有していないので、本システムでの使用には適していないことに留意されたい。IBMEcinaは、Sun、IBM、DigitalEquipmentCorp、HewlettPackard、及びWindows登録商標を含む多数のハードウェアプラットホームに関してTransarcから入手できる。IBMEcina取引処理手続きモニタは、以下のように設計されている。1多種多様なシステムを統合する分散取引処理手続きアプリケーションを可能にする相互運用性。2X/OpenXAアプリケーションプログラムインターフェイスを介し、メインフレームに付加的なソフトウェアを必要とすることなく、sync-level0,1,2サービスを含むメインフレームLU6.2同時使用を提供する、Oracle、Ingres、Infomix、又はSybase等の多重XAコンプライアントデータベース又はリソースマネージャの同時使用。3取引処理手続きアプリケーションが必要とする性能及び信頼性。4有効な完全分散型2元コミット機構。5性能を高め単点故障を排除する、自動負荷平衡化及びアプリケーション複製サービス。6クライアント及びサーバーの両者が、取引の関係先の身元及び権限を検証することを可能にする、基本的DCEの遺伝性セキュリティ機構。7自動認証照合を含み、検査記録構造を与えるのを容易にする、追加的なセキュリティ機構。8多数のユーザ及び大量のデータをサポートするための企業的拡張性。9有効な管理を可能にするのを容易にする集中管理。TopEnd取引処理手続きモニタは以下のように設計される。1堅固なミドルウェア2分散取引管理3クライアント/サーバー相互作用4信頼性の高いファイル転送5動的作業負荷平衡化6回復可能取引キューイング7アプリケーション並列化82元コミット処理手続き9自動回復10メッセージ依存ルーチン11多重データベースサポートMicrosoftSQLサーバー、Oracle、及びSybase12インターネットアプリケーションの拡張性及び有用性好適な実施形態において、本システムの各々の取引コーディネーターは、認証、認定、セッションセキュリティ、メッセージセキュリティ、否認防止、及び検査を含む複数のサービスを提供するようになっている。好適な実施形態において、取引コーディネーターは、ルートエンティティ110により定義されるPKIに基づくPKIX認証を利用する。本システム以外のサービスに関する他の認証機構は、取引コーディネーターを操作するエンティティにより決定されるのと同様にサポートできる。好適な実施形態において、認証は、デジタル認証を使用することでもたらされる。認証は、セッションレベル、メッセージレベル、又は両レベルで生じる。好適な実施形態において、セキュアソケットレイヤーSSLプロトコルは、セッションレベルの認証をもたらす。セキュアソケットレイヤープロコルは2つのフェーズからなる。即ち、サービス側認証と随意的なクライアント側認証とである。所定の取引コーディネーター202は、取引先又は他の取引コーディネーターからのリクエストを受け取る場合にはサーバーとして、他の取引コーディネーターへリクエストを送る場合にはクライアントとしての機能を果たす。図9は、サーバー側認証を示す。サーバー90は、クライアント95からのリクエストを受け取りステップ9002、そのユーティリティ証明書をクライアントへ送るステップ9004。ステップ9006で、クライアント95は、公開鍵を発生し、サーバーの公開鍵を用いて暗号化し、サーバー90へ送るステップ9006。ステップ9008で、サーバー90は秘密鍵を用いてクライアント95が送ってきた公開鍵を復号し、クライアントから受け取った公開鍵を用いて認証したメッセージを戻すことによって、クライアント95に対して自身を認証する。その後のデータは、クライアント生成の公開鍵を用いて暗号化し認証する。セキュアソケットレイヤーサーバー側認証により、クライアント95は誰と通信しているのかを知ることができる。サーバー側認証は、ネットワーク取引が行われる全てのセッションに必要とされることが望ましい。サーバー90を認証するために、クライアント95は、サーバー90のユーティリティ証明書チェーンにおけるルート証明書権限についての公開鍵証明書を所有する必要がある。図10は、随意的なクライアント側認証を示す。ステップ10002で、サーバー90はクライアント95へチャレンジを送る。クライアント95は、自身の秘密鍵を用いてチャレンジに署名を行い、自身の公開鍵と一緒に署名付きチャレンジを戻すことにより、サーバー90に対して自身を認証するステップ10004。セキュアソケットレイヤークライアント側認証は、クライアント95が有効なユーティリティ証明書と付随の秘密鍵とを所有することを保証する。好適な実施形態において、セキュアソケットレイヤークライアント側認証は随意的であるが、発行関係先102及び信用関係先104が、クライアント95からデジタル署名されたリクエストを要求しない場合に採用される。取引コーディネーター202IP、202RP、202Rは、クライアント95が有効なルート証明書を保持していることを決定するために、クライアントのユーティリティ証明書チェーンにおけるルート証明書権限についての公開鍵証明書を所有する必要がある。好適な実施形態において、セッションレベルで、発行関係先102及び信用関係先104は、自身で取引先クライアントに対する認証を行う。また、発行関係先102及び信用関係先104は、セッションが確立された時に、取引先クライアントに取引コーディネーター202IP、202RP、202Rに対して自身を認証するよう要求できる。つまり、クライアント95が、通信を行っている関係先の検証済み取引先でない場合、その関係先に対する取引コーディネーターは、メッセージを処理する前にセッションを中止できる。また、関係先は、メッセージレベルの認証を要求する代わりに、セッションレベルでの取引先のクライアント側認証を要求できる。取引コーディネーター202IP、202RP、202Rの間の認証は、セッションレベル又はメッセージレベル又はその両方の何れかで発生してもよい。対照的に、信用取引先は、取引コーディネーター202RPに送られる全てのリクエストにデジタル署名を行うことで、メッセージレベルの認証を提供することを要求されることが望ましい。しかし、前述のように、関係先は、信用取引先にセッションレベルでクライアント側認証を提供することを要求してもよい。図11は、好適な実施形態を示すブロック図/フローチャートを組み合わせたものである。以下に説明するように、この方法は、メッセージ中に含まれるデータにデジタル署名を付加することによって、取引コーディネーター202へ送られてきたメッセージを認証するように作動する。ステップ1102で、認証モジュール408は、ハードウェアセキュリティモジュール218を呼び出して、典型的にメッセージと共に送られてくる発信者の公開鍵証明書を用いて、受け取ったメッセージに関する署名を検証する。ステップ1104で、認証モジュール408は、ハードウェアセキュリティモジュール206を呼び出して、発信者のチェーンにおけるルートの証明書を発端にして発信者の証明書チェーンを有効にすることで、発信者が有効なルート保証証明書を所有していることを確認する。発信者の公開鍵証明書といった、発信者チェーンの複数部分は、メッセージと共に送られる。ルート証明書といった、チェーンの他の部分は、既にHSM206及び/又は取引先データベース214に格納されている。ステップ1106で、認証モジュール408は、タイムソース11を呼び出し、最新の時間を取得し、発信者のチェーンを含む証明書がいずれも既に期限切れになっていないことを検証する。全ての関係先及びルートエンティティ110は、同期タイムソースを備えることが望ましい。ステップ1108で、認証モジュール408は、OCSPレスポンダ204を呼び出し、ハードウェアセキュリティモジュール218に格納された証明書以外の、発信者のチェーンの証明書が無効になっていないことを確認する。メッセージ認証は、セッション認証に比べて高レベルの認証を提供する。セッション認証はユーティリティ鍵を利用する。一般的に、OCSP照合は、ユーティリティ鍵に関して行われないので、SSL証明書が無効になっている場合、認証プロセス中にクライアントもサーバーも確認できない。更に、ユーティリティ鍵は、保護を受けないで格納されるので、鍵が格納されているトークンを所有する誰もが認定ユーザを装うことができる。他方で、メッセージ認証をもたらすのに使用される保証鍵は、保護されているので、単にトークンを所有していても鍵に近づいて認定ユーザを装う資格はない。好適な実施形態において、取引先認証照合モジュール418図5参照は、サービスリクエスタがそのサービスを受けるよう認定されているかを確認する。認証を決定するために、リクエスタの身元は、セッションレベル認証又はメッセージレベル認証から決定できる。取引先認証照合モジュール418は、ユーザの認証済み身元、又は与えられたユーティリティからの識別名、又は保証証明書を抽出して、これを取引先データデータベース214の認定ユーザリストと比較することで認証照合を実行することが好ましい。好適な実施形態において、取引先認証照合は、金融機関の証明機関の識別名に従属する識別名をもつ任意のユーザといった、識別名の一部に基づいていてもよく、又は特定のユーザのみが認定されるよう完全な識別名に基づいていてもよい。取引先認証照合モジュール418は、複数のレベルで認証照合を実行できる。例えば、ユーザレベルでのサービスを許可又は否定する能力を有していてもよく、又は、ユーザが保有する担保の細かい基準に基づいて許可又は否定する能力を有していてもよい。好適な実施形態において、取引コーディネーター202は、セキュアソケットレイヤーSSLを用いてセッションセキュリティを提供する。典型的に、SSLは、3段階のセッションセキュリティを提供する。即ち、機密性、データ保全性、及びセッション認証である。取引コーディネーター202からの、又は取引コーディネーター202への通信は、SSLを用いて暗号化することが好ましい。本システムのメッセージセキュリティは、デジタル署名を用いて提供されることが好ましい。デジタル署名は、2段階のメッセージセキュリティを提供する。即ち、認証及びデータ保全性である。典型的に、デジタル署名は、保護された秘密鍵を用いて認証を行い、秘密鍵は署名メッセージに対して使用される。前述のように、デジタル署名は、署名プロセス中に生成されるハッシュ又はメッセージダイジェストを使用して、データ保全性をもたらすことが好ましい。メッセージダイジェストは、署名付きデータの何れかのビットが変更されると、別の指紋が生じてデータの受信者が署名を検証できないようになったデータの指紋を与える。好適な実施形態において、機密性は、セッションレベルにおいて、全てのルート通信に対して与えられる。取引コーディネーターは、ルートエンティティ110により定義された機密性ルールに従うことが好ましい。好適な実施形態において、各々の取引コーディネーター202は、ログ内の実行サービスの否認防止を保証し、これらのログの保全性を保証するのに必要な全てのデータを記録する。例えば、信用関係先104は、信用取引先108に対して実行する全てのサービスに関するそのような否認防止を提供することが好ましい。つまり、各々の実行サービスに対して、取引コーディネーター202RPは、信用取引先108への応答のみならず、サービスの実行に関係するどのパーティも提供サービスを拒否できないことを保証するのに必要な全てのデータを保持する。好適な実施形態において、デジタル署名付きメッセージは、この否認防止の基準を提供する。例えば、前述の検証サービスのコンテキストにおいて、取引コーディネーター202は、否認防止目的のために全ての受信データのログを保持する。取引コーディネーター202は、受信時にメッセージをそのとおりに記録し、解析しないこと、変更しないこと、又は受信形式とは別の形式で格納しないことが好ましい。受信メッセージの変更は、メッセージのデジタル署名を証明できなくするので、メッセージは否認防止目的には不適切なものになる。好適な実施形態において、各々の受信メッセージには、否認防止サービスの一部としてタイムスタンプが押される。応答は、特定の時間に実行される認証照合と関連する。認証照合の時間は、応答における署名付き属性であり、未処理取引ログ212が取得することが好ましい。好適な実施形態において、取引コーディネーター202は、検査目的のための情報も記録する。セキュリティ検査ログは、非取引先からの多数回の疑わしいリクエストや、多数回の疑わしい無効署名といった、システムに対する潜在的攻撃を検出するのに利用できる。また、セキュリティ検査ログは、鍵漏えいが発生した時に役に立つ。その理由は、記録され関連証明書が無効になる前に鍵は漏えいされ得るからである。セキュリティ検査ログは、漏えい鍵を用いて処理が発生したことを確認するのに使用できることが好ましい。検査記録は、係争解決、否認防止、及び請求書発行の目的で保持される。好適な実施形態において、取引コーディネーターは、送受信した全てのメッセージを記録し、メッセージ全体を記録する。メッセージは、未処理形式で記録できる。もしくは、取引コーディネーターは、メッセージを構成部分に分解してスキーマとして格納でき、メッセージ全体は、署名を保存した様態で再構成できる。好適な実施形態において、ログはこのような特性であるので、ログ入力は、検出されることなく偽造追加、削除、又は変更できない。更に、取引コーディネーターが未処理形式で記録される場合、未処理データをCOTSソリューションで読み取り可能な形式に変換する能力を含むことが好ましい。これは疎結合ユーティリティであってもよく、又は取引コーディネーター機能性の一部であってもよく、別個のおそらく優先順位が低いバックグラウンドプロセスとして実行される。また、これは完全に別個のシステムで実行されてもよい。ログは、転送及びセッションに関連する他のデータを含んでもよい。一例として、送信者/受信者のIPアドレス、ポストURL、SMTPヘッダー等を挙げることができる。転送サービスコンポーネント306図3参照は、取引コーディネーター202と、通信中のエンティティとの間のセキュアソケットレイヤーセッションを確立する、安全な通信コンポーネントを備えることが好ましい。好適な実施形態において、安全な通信コンポーネントは、前述のようなセッション認証を行う。つまり、取引コーディネーター202がサーバー90としての機能を果たす場合、安全な通信コンポーネントは、サーバー側のセッション認証をもたらし、クライアント側のセッション認証を要求できる。対照的に、取引コーディネーター202がクライアント95としての機能を果たす場合、安全な通信コンポーネントは、サーバー90の認証に対する責任を負う。クライアントとして、取引コーディネーター202は、セッション鍵を発生してその鍵を通信しようとする取引コーディネーターへ送ることで、セッションセキュリティの確立に対する責任も負うことが好ましく、鍵はサーバーの公開鍵で暗号化される。その後の2つのパーティ間の通信は、そのセッション鍵を用いて暗号化される。図12は、取引コーディネーター202のコンポーネントに関連したセキュリティ関連フローの好適な実施形態のブロック図/フローチャートを組み合わせたものである。図12に示すように、ステップ1202で、転送サービスコンポーネント306はリクエストを受け取る。ステップ1204で、転送サービスコンポーネント306は、そのリクエストをリクエストマネージャ304へ送る。リクエストマネージャ304は、入力メッセージに対して、そのメッセージ処理前に、全てのセキュリティ関連機能性を確実に実行することが好ましい。ステップ1206で、リクエストマネージャは、ロギングコンポーネント320を呼び出して、未処理データを記録する。ロギングコンポーネント320は、否認防止及び検査のサポートを必要とするデータを集める。前述のように、全てのリクエスト及び応答は、受信形式で記録されることが好ましい。ステップ1208で、リクエストマネージャ304は、リクエストに関する署名が要求されているかを確認する。ステップ1210で、リクエストマネージャ304が、リクエストには署名の必要がないことを確認すると、リクエストマネージャ304は、クライアントのユーティリティ証明書を用いて取引先認証照合モジュール54を呼び出す。ステップ1212で、リクエストマネージャ304が署名の必要があることを確認すると、リクエストマネージャ304は取引先認証モジュール408を呼び出す。ステップ1214で、取引先認証モジュール408は、リクエストに関する署名を証明し、署名コンポーネント324を呼び出して証明書チェーンを検証する。署名コンポーネント324は、メッセージセキュリティをもたらし、セッション及びメッセージ認証サービスをサポートすることが好ましい。署名コンポーネント324は、ハードウェアセキュリティモジュール218と相互作用して暗号化機能を果たす。ルートエンティティ110は、全ての取引に対して使用されるデジタル署名方法の仕様を定めることが好ましい。署名コンポーネント324は、ハードウェアセキュリティモジュール218と相互作用して署名検証プロセスに含まれる暗号化機能を果たすことが好ましい。ステップ1216で、取引先認証モジュール408は、前述のように証明書ステータス照合モジュール414を介してリクエストをOCSPレスポンダ204へ送ることで、取引先の保証証明書のステータスを照合する。ステップ1218で、取引先認証モジュール110は、取引先の保証証明書を用いて取引先認証照合モジュール418を呼び出す。ステップ1220で、取引先認証照合モジュール418は、取引先データベース214を照合して、取引先からのリクエストが、要求サービスを取得することの認定がなされているのを確認する。ステップ1222で、認定に関するリクエストは、リクエストマネージャ304へ戻され、前述のようにサービスが提供されたシステムの処理が継続する。取引コーディネーターと以下のエンティティとの間のネットワーク通信に関する好適なセキュリティ要件を説明する。エンティティは、取引先、OCSPレスポンダ、及び他の取引コーディネーターである。好適な要件、信用取引先108がリクエストを信用関係先104へ出すようになった一例として説明される。信用関係先104の取引コーディネーター202RPが信用取引先108からリクエストを受け取る場合、取引コーディネーター202RPは、リクエストを認証する。典型的に、署名は、信用取引先108から取引コーディネーター202RPへ送られた全てのメッセージに対して必要である。更に、取引コーディネーター202RPは、信用取引先108にセキュアソケットレイヤークライアント側セッション証明書の提供を要求する場合もある。取引コーディネーター202RPは、信用取引先108へ送られた全てのメッセージに対する認証をもたらすことが好ましい。更に、取引コーディネーター202RPは、信用取引先108を用いて何れかのセッションを確立した場合には、セキュアソケットレイヤーサーバー側セッション証明書をもたらす。好適な実施形態において、取引コーディネーター202RPは、認定を行って信用取引先108が信用関係先104に対する実在の取引先であるか否かを確認する。また、取引コーディネーター202RPは、認定を行って、要求されているサービスの形式又はレベルを受け取ることが認定されているか否か確認できる。信用取引先108は、資格があるサービスを列挙する取引先データベース214RPに関する入口を有することが好ましい。信用取引先108は、セキュアソケットレイヤーサーバー側セッション認証が採用される場合、識別名によって保証証明書に存在することが確認でき、また、その識別名によってユーティリティ証明書に存在することが確認できるのが好ましい。この取引コーディネーター態様は、COTSアクセス制御/認証パッケージと一体であってもよい。好適な実施形態において、信用取引先108と取引コーディネーター202RPとの間の通信は、ルートエンティティ110により定義される仕様に基づいて暗号化され、サーバー側の認証が必要である。典型的に、信用取引先108と取引コーディネーター202RPとの間で交換されるメッセーはデジタル署名される。取引コーディネーター202RPは、受け取った全ての署名付きメッセージを証明し、証明書チェーンを検証し、チェーン内の証明書が無効になっていないことを保証するのが好ましい。更に、取引コーディネーター202RPは、信用取引先108へ送る全てのメッセージに署名する。好適な実施形態において、取引コーディネーター202RPは、信用取引先108に対する否認防止サービスを提供する。典型的に、取引コーディネーター202RPは、任意のルートコンポーネントから受け取ったサービスに対するリクエストに関連する、全てのリクエストを記録する。これは他の関係先及びルートエンティティ110のコンポーネントはもちろん、取引コーディネーター202RPの他のコンポーネントも含む。信用関係先104は、信用取引先108からのサービスに対する全てのリクエストと、取引先からの否認申し立てから自身を保護するために信用取引先108から受け取った全ての確認通知とを記録するのが好ましい。好適な実施形態において、取引コーディネーター202RPは、検査目的で信用取引先108からのサービスに対するリクエストの全てを記録する。従って、システム管理者は、システムに対する潜在的攻撃を検出でき、鍵漏えいが発生した後でサービスに対するリクエストを受け取ったか否かを確認できる。また、リクエスト検査は、起こり得るどんな請求書発行係争をもサポートするのに利用できる。好適な実施形態において、取引コーディネーター202IP、202RP、202Rは、それぞれOCSPレスポンダ204IP、204RP、204Rだけと、即ち同じ金融機関にあるOCSPレスポンダと通信する。他の金融機関にあるOCSPレスポンダからの応答が必要な場合には、好ましくは、通信は他の金融機関の取引コーディネーター202を通過する必要がある。OCSPレスポンダ204IP、204RP、204Rは、リクエストを受け取っているエンティティの身元を識別でき、取引コーディネーター202IP、202RP、202Rは、OCSP応答を受け取っているエンティティの身元を識別できることが好ましい。同じ場所に配置された取引コーディネーター202IP、202RP、202RとOCSPレスポンダ204IP、204RP、204Rとは、何らかの明示的な認証なしでローカルプロセスからのメッセージを受け取っていることを識別できるのが好ましい。この場合、セキュアソケットレイヤー認証も署名付きリクエストも要求しない。しかし、OCSPレスポンダ204IP、204RP、204Rは、典型的に全てのリクエストに署名し、取引コーディネーター202IP、202RP、202Rは、典型的にインターネットPKIOCSP仕様に基づいて署名付きリクエストを受け取る。取引コーディネーター202IP、202RP、202R及びOCSPレスポンダ204IP、204RP、204Rが同じ場所に配置されておらず、誰と通信しているのかはっきり確認できない場合は、各々のコンポーネントの間の認証はなるべく必要である。リクエストに対する認証は、メッセージレベルであることが好ましく、セッションレベルであってもよい。同様に、応答に対する認証は、メッセージレベルであることが好ましく、セッションレベルであってもよい。取引コーディネーター202IP、202RP、202Rは、典型的に、OCSPレスポンダ204IP、204RP、204Rに関する認証照合を行わないことを理解されたい。その理由は、OCSPレスポンダ204IP、204RP、204Rは、典型的に、取引コーディネーター202IP、202RP、202Rからサービスを要求しないからである。OCSPレスポンダ204は、それぞれの取引コーディネーター202と同じ場所に配置されるのが好ましいので、典型的に、その間の通信に対して通信セキュリティ機構を提供する必要はない。2つのコンポーネントは、完全に1つの金融機関の制御下にある物理環境に収容されているので、保護は、セキュリティ機構の実施とは対照的にポリシーにより提供され得る。しかし、これらのコンポーネントが同じ場所に配置されていない場合は、通信の機密性又は保全性を危うくするネットワーク攻撃に対して通信を保護することが好ましい。この保護をもたらすSSLを利用することが好ましい。好適な実施形態において、各々のOCSPレスポンダ204は、それぞれの取引コーディネーター202と同じ場所に配置されているので、取引コーディネーター202は、OCSリクエストに署名する必要はない。しかし、OCSPレスポンダ204は、ルートエンティティ110により定義される仕様が要求する場合はリクエストに署名できる。OCSP応答が署名を行う場合、特に応答が提供サービスに直接的に関連している場合は、完全なレスポンダの署名を記録することが好ましい。しかし、サービスに対するリクエストに関する認証照合の一部として、取引コーディネーター202がOCSP応答を要求している場合、OCSP応答は、典型的に否認防止目的のために記録されない。その理由は、OCSP照合は、入ってくるリクエストを処理するか否かを確認するために実行されるものであり、リクエスト自身の処理の一部ではないからである。唯一、リクエスト処理に関連する情報は、否認防止目的で保持する必要がある。好適な実施形態において、ローカルOCSP応答は、信用関係先104が同様に該当証明書の発行関係先102であり、OCSPリクエストが、例えば証明書に対する検証リクエスト中に取引先証明書の証明を照合するサービス提供処理の一環である場合にのみ記録される。好適な実施形態において、OCSPレスポンダ204は取引コーディネーター202のサービスを要求しないので、セキュリティ検査目的のためにOCSP応答を記録する必要はない。更に、取引コーディネーター202は自身を検査できないので、セキュリティ検査目的のために取引コーディネーター202が生成したOCSPリクエストを記録する必要はない。取引コーディネーターは、他の取引コーディネーターからの全てのリクエストを認証する。典型的に、このことは、セキュアソケットレイヤークライアント証明書か、又は、取引コーディネーターを、他の取引コーディネーターからの全リクエストに関して署名を要求するよう設定している金融機関のいずれか一方で達成される。好適な実施形態において、第2の取引コーディネーターからリクエストを受け取る第1の取引コーディネーターは、認証照合を行って、要求している取引コーディネーターがリクエストを行うことが認定されているか否かを確認する。この認証照合は、そこからサービスを得ようとする取引コーディネーターの取引先データベースに対する入口を備える、全て認定済み取引コーディネーター202IP、202RP、202Rを設けることで容易になる。サービス要求を受けた取引コーディネーター202が署名を必要とする場合、リクエスタは、識別名によって保証証明書に存在することが確認できることが好ましい。そうでない場合には、ユーティリティ証明書からの検証は、セキュアソケットレイヤークライアント側認証が必要な場合にのみ許可されることが好ましい。信用取引先108と取引コーディネーター202RPの間の通信は暗号化されることが好ましく、サーバー側セッション認証が必要である。関係先は、他の取引コーディネーターからその取引コーディネーターへ送られた全てのリクエストが署名付きであることを要求する場合もある。その代わりに、関係先は、セキュアソケットレイヤークライアント側セッション証明書を要求とする場合もある。取引コーディネーター202IP、202RP、202Rは、他の取引コーディネーターへ送られる全ての応答に署名することが好ましい。取引コーディネーター202IP、202RP、202Rは、否認防止サービスを提供する。その目的ために、取引コーディネーター202IP、202RP、202Rは、他の取引コーディネーターから受け取ったリクエストに対するリクエストに関する全ての応答を記録することが好ましい。取引コーディネーター202IP、202RP、202Rが受け取った、サービスに対するリクエストを記録できることが好ましい。これによりシステム管理者は、システムに対する潜在的な攻撃を検出でき、また、システム管理者は、鍵漏えいが発生した後でサービスに対するリクエストを受け取ったか否かを確認できる。また、リクエスト検査は、起こり得るどんな請求書発行係争をもサポートするのに利用できる。取引コーディネーターの好適なアーキテクチャコンポーネントを以下に詳細に説明する。取引コーディネーターのコンポーネントは、専用のソフトウェアコードとして実現するのが好ましいが、他のソフトウェア製品も本明細書で説明するように利用できる。このコードに加えて、関係先は、前述の証明書ステータス照合サービスに関する彼ら自身のビジネス仕様ルールや、4コーナーモデルによりもたらされる他のサービスを書き込んで実行できる。好適な実施形態において、取引先ソフトウェア開発キットをツールセットとして利用して、取引コーディネーター202と取引先又は他の取引コーディネーターとの間のインターフェイスを容易にする。ソフトウェア開発キットは、転送サービスコンポーネント306と一体であることが好ましい。ソフトウェア開発キットは、信用取引先108が保有するウェブサイトにおける、アプリケーションのオリジナルウェブサーバー用の全てのハイパーテキスト転送プロトコル要求を遮断するようになっていることが好ましい。ソフトウェア開発キットは、メッセージが、定義ルールセットに基づいた署名を必要とするか否かを確認することが好ましい。また、ソフトウェア開発キットは、署名及び公開鍵証明書をハードウェアセキュリティモジュール230の助けを借りて認証する。このようなSDKの好適な実施形態は、本出願と同時出願の係属中の米国特許出願番号09/657,604号SystemandMethodforFacilitatingAccessBySellerstoCertificate-RelatedandOtherServicesに説明されており、その開示内容は、引用により本明細書に組み込まれている。ソフトウェア開発キットによりもたらされる機能の広がりに応じて、この使用法は、取引コーディネーター操作の他の領域に拡張できることが好ましい。典型的に、ソフトウェア開発キットを取引コーディネーターで使用できるようにするには、特定の変更及び機能性の追加が必要である。Microsoft登録商標SQLサーバーは、請求書発行データを格納するためのデータベースとして使用できる。取引コーディネーター202は、データベースライブラリを介してサーバーと相互作用するようになっていることが好ましい。もしくは、サーバーとの相互作用は、取引コーディネーターの開発がJAVA登録商標上で行われる場合には、JAVA登録商標DatabaseConnectivityを用いて行ってもよい。更に、データベースライブラリは、他のサーバーに書き込まれていてもよく、これにより取引コーディネーター202に影響を与えることなくMicrosoftSQLサーバーを他のデータベースで置き換えることが可能になる。MicrosoftSQLサーバーは、以下の機能を備えることが好ましい。1レポート、データ分析、意志決定、及びデータモデル化に不可欠な複数の情報を有効に分析するためのオンライン分析処理OLAP2ディスク格納アーキテクチャ3マルチフェーズクエリオプチマイザー4クエリオプチマイザーが最新情報を利用してクエリ効率を高めるようにできる自動統計5運用システムへの影響を最低限にした状態で高性能オンラインバックアップをもたらすアクティブバックアップ6ユーザが単独で作業して後で結合することを可能にするマージ複製7マージ競合を解決するための組み込み優先順位ベース競合解決8ウェブへのデータ公開能力9複数の異質のソースからのデータを取り込んで変換するデータ変換サービス10物理的及び論理的データベース一貫性照合能力11動的列レベル固定12統計的収集を管理し効率的方法を保証するクエリオプチマイザー13性能を高めるための、単一クエリの各々のステップが並行実行されて最適な応答時間をもたらす、複数のプロセッサを横切る単一クエリのクエリ内並行実行14意志決定サポート、データウェアハウス、及びオンライン分析処理アプリケーションに見られる、大きなデータベース及び複雑なクエリを上手くサポートする、再設計されたクエリプロセッサ15ソート速度16テーブル毎の複数トリガー及びトリガーの直接反復17最適なメモリ割り当て及び使用のための動的メモリ、及び動的メモリ管理18並行バックアップ及び素子速度でのユーティリティスケールの修復19性能向上及び手動調整の必要のないスマート先読みロジック20重要な構成のランタイムチェック好ましくは、トランザクションコーディネータを維持するエンティティが、トランザクションごとに請求書を生成することができるようにするために、十分なデータが収集され、および記憶される。この目的のために、好ましい実施形態において、トランザクションコーディネータによって生成された、どの入および出メッセージも、そのすべてが、データベースにおける連続したレコードに記憶される。そのようなメッセージは、受信されたすべての要求、作られたすべての要求、生成されたすべての応答、および受信されたすべての応答を含む。これによって、トランザクションごとの請求書を生成するのに必要なデータすべてのアベイラビリティavailabilityを確証する。好ましくは、トランザクションコーディネータ202は、集中化された一般的な方法で、請求書データを記録する。関係先は、集中請求書データから、関係先に関連する請求書データを抜き出すために、自らのルーチンを書き込むことによって、記録を入手してもよい。データベースにデータを供給することに加えて、データは、EXCEL登録商標のスプレッドシートspreadsheetsで供給されてもよい。好ましい実施形態において、トランザクションコーディネータの、タイムスタンプコンポーネントとして、DatumInc.のTymeServeNetworkTimeServerTYMSYNC登録商標が使用されている。TYMSYNCは、米国海軍天文台によって管理されている、協定世界時間に対する最も近いマイクロ秒まで、完全な正確性をもって、ナブスター全地球位置把握システムの衛星の配置から時間を読み取る、時間同期パッケージである。この製品は、ワークステーションを、TCP/IPtransmissioncontrolprotocoloverinternetprotocolおよびLANlocalareanetworkネットワークで同期させるように適応していてもよい。好ましくは、ネットワークタイムプロトコルNetworkTimeProtocolを用いて、ネットワーク内で時間を配分する。TYMSYNCは、コンピュータシステムのクロックを、継続的に、協定世界時間に同期させるように構成されてもよい。要求ならびに応答が生成され、およびメッセージが受信され、ならびに送信される時間は、好ましくは、否認防止目的、および監査目的で記憶される。好ましい実施形態において、トランクザクションコーディネータ202とのすべての通信は、安全接続secureconnectionsで実行される。好ましくは、同期通信のための、安全ソケットレイヤ暗号化体系securesocketlayerencryptionschemeが使用される。安全ソケットレイヤは、コマーシャル/ウェブサーバ実装と適合する方法で使用され、およびインターネット等の電子ネットワークを介して、セキュリティとプライバシーを提供する。安全ソケットレイヤは、アプリケーション独立であり、そのために、プロトコルは、それらの最上部に、透過的に重ねられる。安全ソケットレイヤは、すべてのネットワーク通信に関する機密性、データ完全性、および認証authenticationを与える。安全ソケットレイヤは、通常、通信エンティティ間を通るすべてのデータを暗号化することによって、機密性を確証する。安全ソケットレイヤイネーブルドクライアント95およびサーバ90が最初に通信するときに、プロトコルのバージョンに関して同意し、および暗号化アルゴリズムを選択する。好ましくは、ネットワーク承認暗号化アルゴリズムおよびキー長が、ルートエンティティrootentity110によって特定される。安全ソケットレイヤはまた、通常、暗号の使用によって、データ完全性を確証する。メッセージが正しく解読されない場合、レシピエントrecipientは、誰かがそのメッセージに干渉したことを告げることができる。安全ソケットレイヤはまた、サーバおよびクライアント認証をサポートし、暗号化キーを取り決め、およびデータが、より高いレベルのアプリケーションによって交換される前に、サーバを認証する。認証は、好ましくは、デジタル署名およびパブリックキー証明書の使用を通して与えられ、それは電子通信セッションが最初に確立されたときに交換される。好ましい実施形態において、各トランザクションコーディネータは、S/MIMEメッセージを送信するためのSMTPを用いて、およびSSLv3接続HTTPSを介してHTTPプロトコルを通して通信し、パブリックインターネットでメッセージを受信し、および送信することができる。すなわち、各トランザクションコーディネータは、好ましくは、以下の二つの通信モードをサポートするように適応する:安全ソケットレイヤSSLv3を介したHTTP-同期通信すなわちHTTPSのためのものである。HTTPSは、ウェブページを安全に転送するために、ウェブサーバとウェブブラウザとの間の、安全ソケットレイヤを統合する、ハイパーテキスト転送プロトコルである。HTTPキープアライブHTTPkeepaliveの使用が推奨される。S/MIMEv2-SMTPを使用した非同期通信のためのものである。好ましい実施形態において、各トランザクションコーディネータは、信用取引先relyingcustomerとの通信中はHTTPSサーバとして、および他の金融機関におけるトランザクションコーディネータへの要求をするときは、HTTPSクライアントとして振舞う。どちらの方法でも、証明書ステータスチェックcredentialstatuscheckingのための、すべてのSSL通信は、たった一つのサーバ認証のみを採用してもよい。好ましい実施形態において、各トランザクションコーディネータは、ルートエンティティ110によって承認される他のトランスポートプロトコルtransportprotocol例えば、IIOPを介して届けられるメッセージを受信してもよい。さらに、関係先は、構成により、局所的に他のトランスポートプロトコルを実行してもよい。しかしながら、前もっての合意がない場合、HTTPSサポートのみが、任務を負うべきである。好ましい実施形態において、証明書ステータスチェックサービス312のために、Valicert登録商標のOCSPレスポンダが使用される。しかしながら、OCSPレスポンダ204へのアクセスは、ライブラリを用いて達成されてもよい。このように、新しいライブラリを書き込むことによって、新しいOCSPレスポンダベンダが実装されてもよい。好ましくは、OCSPレスポンダ204は、証明書取り消しリストを使用せずに、証明書ステータスを決定する。OCSPレスポンダ204は、認証局、および証明書を発行し、確認し、ならびに無効にするコンポーネントに関わる処理のほとんどを動かし、および潜在的に大きな証明書取り消しリストをダウンロードする必要性を排除するかもしれない。代替的に、これら機能は、個別の署名キーを与えられてもよい様々なコンポーネントの間で配分されてもよい。例えば、証明書を発行する機能は、取り消し機能から分離されてもよく、およびこれらの機能を実行するコンポーネントは、別個の署名キーを備えてもよい。好ましい実施形態において、署名コンポーネントとして、ハードウェアセキュリティモジュールが使用される。ハードウェアセキュリティモジュールは、好ましくは、署名をし、および署名を確認するための、高速装置である。ハードウェアセキュリティモジュールは、通常、暗号サービスを、認証されたエンティティに供給する、ネットワーク化されたハードウェア装置である。適切なハードウェアセキュリティモジュールは、NCipherによって製造される。好ましい実施形態において、トランザクションコーディネータ202は常に、その通常の動作時間中、要求を処理するために利用可能であり、その時間は、一週間7日一日24時間でもよい。本システムが、確実にアベイラビリティの要件に適合するために、システムアベイラビリティの、詳細な要件解析が実行されるべきである。様々な関係先が様々な要件を有するかもしれないので、多くの異なる種類の故障が生じるかもしれない。公知のとおり、多くの様々なハードウェアおよびソフトウェアベンダが、高アベイラビリティなシステムに関して、様々なオプションを提供する。しかしながら、これらのオプションは、一定の金融機関によって選択されるハードウェアおよびソフトウェアに関して利用可能であるかもしれないし、利用可能ではないかもしれない。トランザクションコーディネータに影響を与えるかもしれない、数多くの、公知の、潜在的なハードウェア故障がある。例えば、サーバへの電力供給が故障するかもしれない。好ましくは、複数の冗長ホットスワップ電力供給hotswappowersupplyは、自動的に、冗長な電力供給に転換する。サーバが故障し、またはクラッシュした場合、トランザクションコーディネータは、好ましくは、自動フェイルオーバーautomaticfailoverのための、高アベイラビリティクラスタリングを備える。さらに、トランザクションコーディネータは、好ましくは、ネットワークオペレーティングシステムNOSハングの場合に、自動的にサーバをリブートするための、セルフ再スタート機能を具備する。トランザクションコーディネータはまた、好ましくは、ディスク故障またはクラッシュを扱うための、複数の冗長ホットスワップディスクドライブおよびディスクアレイコントローラも具備する。トランザクションコーディネータはまた、NIC故障の場合の、冗長ネットワークインターフェースカードNICsのためのサポートを供給するための、ネットワークインターフェースも具備する。クーリングシステム故障の場合には、トランザクションコーディネータは、好ましくは、個別に取り外すことができるホットスワッパブル冗長ファンhotswappableredundantfansを具備する、冗長ホットスワップクーリングシステムを使用する。トランザクションコーディネータはまた、好ましくは、ハードウェアおよびソフトウェア故障を検出するために、インテリジェントプラットフォームマネージメントインターフェースIntelligentPlatformManagementInterfaceも具備する。インテリジェントプラットフォームマネージメントインターフェースは、装置管理のための通信を単純化し、および標準化する、オープンスペックopenspecificationである。メモリ破損の場合、トランザクションは、好ましくは、自己修正メモリを使用する。自己修正メモリは、好ましくは、管理されたエラーチェックならびに修正システムメモリおよびキャッシュメモリである。アプリケーションクラッシュの場合、トランザクションコーディネータ202は、好ましくは、アプリケーションを再スタートするための、トランザクション処理モニタリングを使用する。トランザクションコーディネータはまた、アプリケーションの冗長なコピーをランさせてもよく、およびトランザクション処理モニタは、トランザクションを冗長コピーに転送してもよい。一定のアプリケーションアベイラビリティ特性は、アドレスアプリケーションクラッシュも支援するかもしれない特定の方法で、アプリケーションがコード化されることを求めるかもしれない。オペレーティングシステムのクラッシュの場合、トランザクションは、好ましくは、ネットワークによってサポートされている待機マシンに転送される。CORBA等のミドルウェアを含むディレクトリサービスはまた、新しいトランザクション要求を、新しいマシンに再ディレクトするためにも使用されてもよい。ハードウェアおよびソフトウェアアベイラビリティ製品に加えて、アプリケーションおよびネットワークを監視するために、好ましくは、モニタリングインフラストラクチャが使用される。好ましい実施形態において、アプリケーションを監視するために、ソフトウェアモニタリングツールTrivoli等が使用される。このツールは、好ましくは、アプリケーション故障の場合に、管理者を呼び出すように構成される。NetViewで作られるもの等のネットワークモニタリングシステムはまた、管理者が、ネットワークを監視することができるようにするためにも、使用されてよい。好ましくは、トランザクションをシミュレートするために、カスタムリトンアプリケーションデーモンcustomwrittenapplicationdaemonsが使用される。これらのトランザクションが故障すると、システム管理者に知らされてもよい。また、データベース監視のために、データベースベンダツールが使用されてもよい。ほとんどのデータベースは、デッドロックdeadlocksおよび他のデータベース問題を検出する、データベースモニタリングツールを供給する。トランザクションコーディネータのための配分アプローチは、好ましくは、ルートエンティティ110が、関係先に配分したいものの機能であると定義される。アプリケーション配分は、通常、ルートエンティティ110からのウェブダウンロードを介して実行されてもよい。ウェブダウンロードメカニズムは、選択的ダウンロード、認証、およびトラッキングを備えてもよい。好ましい実施形態において、トランザクションコーディネータは、CICS、IMS、および他のレガシーシステム等、現存のオペレーショナルシステムとの統合をサポートするように適応してもよい。関係先は、上述の、トランザクションコーディネータアーキテクチャおよび機能全体を使用することを選択してもよく、または代わりに、トランザクションコーディネータのコンポーネントを使用し、ならびに自分の実装を、前記コンポーネントに追加することを選択してもよい。ウェブダウンロードアプローチは、好ましくは、関係先の様々な要件を満足するように構成される。ダウンロードメカニズムは、好ましくは、少なくとも三つのダウンロードオプション:1ダウンロードトランザクションコーディネータエグゼクタブルdownloadtransactioncoordinatorexecutableオプション2トランザクションコーディネータのソースコードおよびバイナリオプションおよび3トランザクションコーディネータクラスのソースコードオプションを、供給する。第一のオプションは、好ましくは、トランザクションコーディネータ全体を使用することを選択する関係先の対応をする。このオプションは、異なるプラットフォームに対するオプションを供給する。第二のオプションは、好ましくは、上述のトランザクションコーディネータのコンポーネントを、自らの実装に差し込むことを選択する関係先の対応をする。このダウンロードメカニズムも、異なるプラットフォームに対するオプションを供給する。第三のオプションは、好ましくは、高耐久性開発を選択し、および上述のトランザクションコーディネータの実装の、一定の部分を使用することのみを選択する金融機関の対応をする。好ましくは、ダウンロードメカニズムによって、金融機関は、エグゼクタブルだけでなく、ソースコードもダウンロードすることができる。ダウンロードされたエグゼクタブルは、自らにおいて使用されてもよく、およびソースコードは、他のカスタムアプリケーションを開発するために使用されてもよいので、ルートエンティティ110は、好ましくは、ルートエンティティ110との、信頼されたパートナーであり、よってトランザクションコーディネータを使用する権限を与えられている機関にのみ、ダウンロードアクセスを供給する。好ましくは、これは、認証/承認処理を介して達成される。ルートエンティティ110は、好ましくは、どの関係先が、トランザクションコーディネータの特定のコンポーネントをダウンロードするか追跡してもよい。このように、ルートエンティティ110は、ある時間において使用されているトランザクションコーディネータおよび/またはそのコンポーネントのバージョンを決定してもよい。ルートエンティティ110は、1ダウンロードされたコンポーネントに対して、金融機関から料金を請求するため、および2メンテナンスの目的で、トランザクションコーディネータのバージョンを追跡するために、この情報を使用してもよい。好ましくは、トランザクションコーディネータは、顕著に性能を低下させることなく、増加するユーザに対処するために、スケーラブルscalableになるよう適応している。アプリケーションに対するスケーラビリティの要件を満足させる際の一つのステップは、ユーザベースの潜在的な成長を予測することである。一般的に、分配されたアーキテクチャを有するアプリケーションは、高負荷のコンポーネントの、配分された複数のインスタンスが、ある時間においてランすることを可能にすることによって、より高いスケーラビリティを容易にする。トランザクションコーディネータアーキテクチャは、好ましくは、配分されたものであり、それゆえに、スケーラビリティをサポートする。さらに、トランザクションコーディネータのロードキャパシティは、好ましくは、選択された開発マシンに合わせて、揃っている。この情報は、予想された数のトランザクションをサポートするために、適切なハードウェアを選択するために使用される。好ましくは、トランザクションコーディネータおよび、OCSPレスポンダは、毎分、1000までの確認トランザクションを、信頼性高く扱うように適応している。上述の通り、OCSPチェックは、通常、ユーティリティ証明書に関しては実行されない。署名が、要求において求められない場合、安全ソケットレイヤの、クライアント側の証明書が取り消されなかったことを確証するための、適切なメカニズムはない。好ましくは、安全ソケットレイヤ証明書が取り消された場合、金融機関は、バンド外例えば、ブロードキャストメッセージで知らされ、および影響が及んだユーザは、関係先の取引先データベースから削除される。各トランザクションコーディネータは、通常、そのハードウェアセキュリティモジュールに記憶されるいくつかの証明書のセットを信用する。これらの証明書について、OCSPチェックは実行されない。取り消された証明書が、ハードウェアセキュリティモジュールに存在する場合、オンライン処理中には、それは検出されないであろう。好ましくは、金融機関は、それらが、ハードウェアセキュリティモジュールから証明書を削除することができるように、ハードウェアセキュリティモジュールに記憶された証明書が取り消されたか、通知される。トランザクションコーディネータは、クライアントとして振舞うとき、自らが通信しているサーバを認証する。しかし、このチェックは通常、サーバが、トランザクションコーディネータが信頼する認証局によって発行された証明書であることを保証するにすぎない。サーバ自身の同一性およびステータスに関するチェックはない。好ましい実施形態において、トランザクションコーディネータは、サーバを、信頼されたサーバのリストと照合し、およびサーバの証明書のOCSPチェックを実行する。しかしながら、サーバインターセプトserverintercepting要求によって得られるものはほとんどないので、これらの追加チェックに起因する性能の低下は通常正当化されない。通常、トランザクションコーディネータは、潜在的なアタックattacksを検出するための自動化処理を有していない。好ましくは、システムおよびアセキュリティ管理者検査監査は、そのような潜在的なアタックを識別するために、周期的にログする。通常、安全ソケットレイヤの、クライアント側認証チェックを通過しない要求は、ログされない。アタック例えば、サービスアタックの否定がこのレベルで生じた場合、参照するログはない。好ましい実施形態において、トランザクションコーディネータは、ファイアウォールによって保護されている。好ましくは、ファイアウォールコンポーネントは、入ってくる要求のログを維持する。トランザクションコーディネータは、好ましくは自動侵入検出メカニズムを備える。これらの処理は通常、入トラヒックを監視し、または疑わしい動作を探して、監査ログを走査し、および必要な場合には、適切な行動をとる。トランザクションコーディネータは、通常、否認防止目的でログを維持する。しかしながら、しばしば前記システムは、ユーザが、否認防止をサポートするために必要なデータを検索するのを支援する機能を含まない。ユーザは手動で、すべてのサポートしているデータを見つけるために、ログを通してサーチする。他の実施形態においては、自動否認防止ツールが、この処理において、ユーザを支援するために使用されてもよい。好ましい実施形態において、トランザクションコーディネータおよびOCSPレスポンダは、証明書ステータスチェック要求に関して、通常のインターネットタイムアウト値を採用する。他のサービスに関しては、タイムアウト値は、そのサービスに適切なように設定されてもよい。好ましい実施形態において、タイムアウト値は、トランザクションコーディネータにおいて構成することができる。以下の説明は、トランザクションコーディネータのための、可能なハードウェアおよびソフトウェア実装を略述している。トランザクションコーディネータのために使用されるメインサーバは、HewlettPackardNetserverLH4でもよい。好ましくは、サーバは以下の仕様を有する:4P2-450MHZプロセッサ、512-768MBRAM、40-60GBHDでRaid5アレイ、UPS、およびテープバックアップのための外部DLT40EDLT4000テープドライブである。好ましくは、少なくとも5つのワークステーションが使用され、その各々は、以下の使用を有する:P2400MHzプロセッサ、128MBRAM、および6GBHDである。トランザクションコーディネータは、好ましくは、MicrosoftWindowsNT登録商標4.0/2000,SunSolaris,およびHewlettPackardHP-UXに基づいて、サーバ上でサポートされることができるように、プラットフォーム独立である。実装は、好ましくはJAVA登録商標でなされるが、コード化は、同様にC/Cでなされてもよいものもある。WindowsNTServerw/ServicePack3が、オペレーティングシステムとして使用されてもよい。MicrosoftVisualSourceSafe6.0は、ソースコントロールのために使用されてもよい。SymantecのVisualCafeProfessionalEdition3.0Java登録商標Version1.2が、開発のために使用されてもよい。RSASecuritySystemsのSSL/JSDKは、安全ソケットレイヤ実装のために使用されてもよく、XETIのJKIXによっても求められる。署名確認に関して、nCipherのハードウェアセキュリティモジュールが使用されてもよい。署名取引先からの署名に関して、Datakeyスマートカードが使用されてもよい。好ましくは、OCSPレスポンダは、暗号機能に、およびASN.1通信のためにインターフェースを供給するツールキットを備える。好ましい実施形態において、XETIのJKIXが、この目的で使用されてもよい。デジタルタイムスタンプに関して、DatumのTYMSYNCまたは他の信頼できるタイムソースが使用されてもよい。MSSQLサーバが、上述のデータベースに関して使用されてもよい。MetroWorksのCodeWarrierは、ポータブルC/C開発の、開発のために使用されてもよい。コードポータビリティcodeportabilityを検査するためのコード完全性チェックを実行するために、CodeIntegrityが使用されてもよい。通常、様々なエンティティの間を通過するデータのサイズは、パブリックキーインフラストラクチャシステムの性能に関して、手助けとなる。エンティティ間で提出されるメッセージは、それゆえに、好ましくは、送信されるデータのサイズを推定するように解析される。前記解析は、特定のルート拡張とともに、RFC2459で定義された、証明書フィールドに基づいて実行されてもよい。証明書フィールドの正確なデータ長は、固定された長さを有し、好ましくは、推定中に考慮される。しかしながら、長さが様々である多くのフィールドがある。これらのフィールドに関して、好ましくは、サイズに関する自由な推定がなされるすなわち、小さいよりも、大きい。また、すべてのメッセージサイズの推定は、好ましくは、すべての拡張に関するサイズを含む。すなわち、メッセージが5つの異なる拡張を許可する場合、前記サイズは、好ましくは、5つすべての拡張が要求とともに送信されているという前提で、算出される。図13は、好ましい実施形態における、システムエンティティ間を通過する様々なメッセージ推定サイズを表している。図13に記載の通り、署名取引先subscribingcustomer106から信用取引先relyingcustomer108に渡されるメッセージの、全体の推定メッセージサイズは、2610バイトである。前記メッセージは、通常、二つの証明書を具備し、各々が1146バイトであり、ルートエンティティによって署名された、発行関係先issuingparticipantの証明書は、128バイト、発行関係先の署名は、128バイト、およびHTTPヘッダは62バイトである。信用取引先108から信用関係先104へ渡されるメッセージの、全体の推定メッセージサイズは、2022バイトである。前記メッセージは、通常、二つの要求を具備し、一つは署名取引先の証明書に関し、一つは発行関係先の証明書に関し、各々は55バイトであり、メッセージ拡張は210バイトであり、バージョンナンバversionnumberは4バイトであり、信用関係先の名は132バイトであり、信用関係先の署名は128バイトであり、信用関係先の証明書は1146バイトであり、HTTPヘッダは62バイトである。信用関係先104から発行関係先102へ渡されるメッセージの、全体の推定メッセージサイズは、1601バイトである。前記メッセージは、通常、署名取引先の証明書または発行関係先の証明書に関する要求を具備し、それは55バイトであり、メッセージ拡張は210バイト、信用関係先のトランザクションコーディネータ証明書におけるルートエンティティの署名は128バイト、信用関係先のトランザクションコーディネータ証明書は1146バイト、およびHTTPヘッダは62バイトである。発行関係先102から信用関係先104へ渡されるメッセージの、全体の推定メッセージサイズは、2086バイトである。前記メッセージは、通常、署名取引先の証明書か、または発行関係先の証明書のいずれかに関する応答を具備し、それは456バイトであり、メッセージ拡張は294バイト、発行関係先の証明書は1146バイト、ルートエンティティの署名は128バイト、およびHTTPヘッダは62バイトである。信用関係先104から信用取引先108へ渡されるメッセージの、全体の推定メッセージサイズは、2213バイトである。前記メッセージは、通常、署名取引先の証明書または発行関係先の証明書に関する応答を具備し、それは55バイトであり、メッセージ拡張は210バイト、信用関係先のトランザクションコーディネータからの応答は127バイト、信用関係先のトランザクションコーディネータ証明書は1146バイト、信用関係先トランザクションコーディネータの証明書への、ルートエンティティの署名は128バイト、およびHTTPヘッダは62バイトである。異なるフィールドの、メッセージサイズ推定の詳細は、以下の表に記載されている。通常、エンティティ間で渡されるメッセージのサイズは、2Kから3Kの間である。トランザクションボリュームが算出されると、この情報は、好ましくは、ネットワークロードnetworkloadを推定するために使用される。証明書サイズ―拡張無しまたはルート特化命令証明書拡張―ルート命令および拡張を伴うOCSP要求―ルート命令および拡張を伴うOCSP応答―ルート命令および拡張を伴うOCSPトランザクションおよび保証トランザクションに関する有効要求および応答時間、およびすべてのトランザクションに関する確認時間は、好ましくは、ルートエンティティ110によって特定される。以下の節は、トランザクションコーディネータに対する、好ましいパフォーマンスターゲットを記述している。記述された応答時間は、特定的に、システム応答時間を表す。好ましくは、手動処理確認に対する必要性に言及し、それを要求し、クレームをファイルする等が完了する、経過した時間フレームも確立される。好ましくは、有効要求および応答時間すなわち、OCSPは、ルート制御インフラストラクチャ内での、すべての応答時間トランザクションに関して、10秒以下である。取引先から取引先へ、または取引先からルートへのルートインフラストラクチャ外の認可は、好ましくは60秒を超えない。合計の往復時間は、好ましくは70秒を超えない。好ましくは、応答時間は、インターネット上での待ち時間を含む。エンドツーエンドendtoend応答時間は、好ましくは、最長の有効パスすなわち、署名取引先から信用取引先へ、信用関係先へ、発行関係先へ、そしてルートエンティティへを含む。例示的なパフォーマンス要件は、以下のとおりであろう:信用関係先のトランザクションコーディネータへの、証明書ステータスチェックの通知と、応答の受信との間はたった6秒であり、およびキャッシングが有効で、新しさの証明すなわち、関係先によって送信されるメッセージにおける、関係先証明書のステータスを含むが有効で、二つの証明書の証明書チェーンcertificatechainが認可されており、トランザクションが四角トランザクションfourcornertransactionであり、ならびにシステムエンティティは、インターネットではなく10MbpsLANに接続されている場合に、応答に関するデータが局所的に利用可能である証明書ステータスチェックへ、応答を向かわせるのにたった3秒である。保証要求応答時間は、オフライントランザクションを含む。好ましくは、これらのオフライントランザクションは、営業日の終わりに開始する8時間の時間帯を超えない。損失した、傷ついた、または無効な証明書の通知に対する応答のための応答時間は、好ましくは、オフライントランザクションを含む。好ましくは、これらのオフライントランザクションは、1時間を超えない。証明書の取り消しも、好ましくは、オフライントランザクションを含む。好ましくは、これらのオフライントランザクションは1時間を超えない。トランザクションコーディネータはまた、好ましくは、トランザクションの確認を供給する。オンライントランザクション要求は、好ましくは、不完全な要求または応答を含むステータス確認を、70秒以内で受信する。トランザクションコーディネータはまた、好ましくは、不完全なトランザクション要求または応答の検索のために、要求ステータス、不完全な要求応答、ならびに不完全なトランザクションのためのトランザクションキューイングtransactionqueuingの受信を記憶するための方法を供給する。トランザクションコーディネータはまた、好ましくは、トランザクション回復要件を具備する。適切なシステムリソース割り当ては、好ましくはトランザクションロールバックtransactionrollbackを考慮する。トランザクションコーディネータはまた、好ましくは、フェイルオーバー要件を与える。好ましい実施形態において、トランザクションコーディネータは、システム冗長性、システム/ホットバックアップ、およびパブリックインターネット内での冗長性を備える。トランザクションコーディネータの開発中、開発環境におけるパフォーマンスベースラインperformancebaselineが、好ましくは確立される。このベースライン情報は、開発マシン自身でのアプリケーションコンポーネントのパフォーマンスを向上させるために使用される。しかしながら、好ましいターゲットパフォーマンスを達成するために、予測される数のトランザクションをサポートすることができる適切な生産ハードウェアと、および適切な帯域幅のネットワークが、通常、正しい位置に配置される。以下の節では、トランザクションコーディネータのより高いパフォーマンスのための、好ましいチューニング方法を述べる。エンティティ間を通過しているメッセージのサイズは、各メッセージとともに送信される証明書の一部またはすべてを排除することによって減らすことが可能であるかもしれない。通常、メッセージのレシピエントは、センダーの身元すなわち、保証証明書に現れるセンダーの識別名前を知っており、自らの完全な証明パスへアクセスする。必要とされる証明書の多くも、ローカルレポジトリから入手可能である。認証処理の一部として実行されるOCSPチェックは、取引先データベースが、取り消された証明書を反映させるように設計され、および認証チェックが、その識別名とは対照的に、ユーザの識別名ならびに証明書と照合される場合、省略される。上述の好ましい実施形態において、トランザクションコーディネータは、未処理のトランザクションデータを記憶し、それから請求の目的で、データのサブセットを個別に記憶するために、前記データをパースする。しかしながら、代替的に、この機能は、未処理トランザクションデータベースを監視し、およびデータベースに記憶されたデータから、関連する請求データを抽出するオフライン処理に、オフロードされてもよい。トランザクションコーディネータとOCSPレスポンダを同じ場所に配置することによって、署名し、ならびに要求を確認する必要性、およびこれらのコンポーネント間での安全ソケットレイヤ接続を確立する必要性を排除する。金融機関間で、およびルートエンティティ110との通信中に、安全ソケットレイヤを使用することによって、通常、各要求メッセージをデジタル署名する必要性を排除する。しかしながら、デジタル署名された要求は、より高い安全性を供給する。各関係先は、好ましくは、パフォーマンスと安全性を引き換えることに伴うリスクを評価する。OCSP応答をキャッシングすることは、通常、ルートエンティティへのOCSP要求を送信し、および受信するのにかかる時間を減らすことによって、往復時間を改善する。好ましい実施形態において、OCSP応答の確認は、オンライントランザクション処理の一部として確認を実行するのとは対照的に、データをキャッシュに入れるときに実行される。好ましい実施形態において、トランザクションコーディネータは、有効性応答をキャッシュし、および証明書を発効させるために、キャッシュされた応答を用いてもよい。応答がキャッシュされる期間は、好ましくは、ルートエンティティ110によって、ポリシー事項policymatterとして設定される。この期間は、好ましくは4乃至5分の範囲内であろう。トランザクションコーディネータが、キャッシュされた応答を使用する性能を実装する場合、好ましくは、否認防止の目的と同様に、請求および監査のための、それらの使用をログするように適応する。ログされた情報は、好ましくは、キャッシュされた応答が、新しく得られた応答よりもむしろ証明書を認可するために使用されたことを示す。高い値のトランザクションに関して、クライアントアプリケーションは、キャッシュされた応答よりも、新しい応答の使用を好むかもしれない。したがって、好ましい実施形態においては、トランザクションコーディネータは、好ましくは、キャッシュされた応答よりも、新しい応答を使用する明確な要求に対する、新たに得られた有効性応答を入手し、および使用する。好ましい実施形態において、応答のレシピエントは、レスポンダの証明書のステータスを調べる。代替的に、この第二の要求を排除するために、トランザクションコーディネータは、信用取引先か、または他のトランザクションコーディネータへの応答を送信するときはいつも、ルートによって署名されたその証明書のステータスを自動的に含んでもよい。以下の節では、トランザクションコーディネータのテストを記述する。好ましくは、トランザクションコーディネータは、本節において列挙された項目に関してテストされる。構造的な柔軟性を与えるために、トランザクションコーディネータは、好ましくは、一つ以上のハードウェアプラットフォーム例えば、MicrosoftWindowsNT登録商標4.0/2000、SunSolarisおよびHewlettPackardHP-UXにポートされる。これによって関係先は、サポートされたプラットフォームのリストから、自らのハードウェアプラットフォームを選択することができる。好ましくは、トランザクションコーディネータが、サポートされたプラットフォームの各々に、円滑にインストールされることを確証するためのテストが実行される。そのような、適切なハードウェアをテストすることを可能にすることが、通常求められる。好ましくは、トランザクションコーディネータが、クリーンなcleanWindowsNT登録商標マシンにインストールされ、およびアンインストールされることを確証するためのテストが実行される。トランザクションコーディネータが、他のオペレーティングシステムをサポートするために拡張される場合、好ましくは、同じソースコードに由来するエグゼクタブルが、サポートされたオペレーティングシステムのすべてにインストールすることができることを確証するためのテストが実行される。適切なオペレーティングシステムを有する適切なハードウェアは、これらのテストを実行することを求められてもよい。好ましくは、トランザクションコーディネータは、他のサードパーティベンダのソフトウェアツールと連携する。これらのソフトウェアツールへのインターフェースは、好ましくは、開発およびシステムテスト段階中、開発サイトでテストされる。さらに、これらのツールとの、トランザクションコーディネータインターフェースが安定していることを確証するために、通常、取引先サイトで複雑なテストが実行される。これは、後述のとおり、取引先/機能テスト中に行われる。トランザクションコーディネータの機能は、好ましくは、開発およびシステムテスト段階中に、テストされる。これらのテスト中、カスタムリトンコードのすべてが、少なくとも一回実行されることを確証するために、適切なツールが使用される。他の好ましいテスト段階においては、取引先は、トランザクションコーディネータの機能をテストする。セキュリティは、トランザクションコーディネータの重要な部分である。好ましくは、データが、ある点から他の点に安全に転送されることを確証するためのテストが実行される。好ましくは、パブリックキーインフラストラクチャの安全面を総括的にテストするためのテストケースが、作成される。システム200内で送信されるメッセージに関するメッセージングプロトコル定義およびシステム200に関する証明書ステータスプロトコル定義は、係属アメリカ合衆国特許仮出願第60/231,319号、本出願と同日に出願された、トランザクションコーディネータ証明書ステータスチェックCSCプロトコル定義、トランザクションコーディネータメッセージングプロトコル定義、およびトランザクションコーディネータ要件と題された前記出願に記述されており、それは、参照のためにここに統合されている。好ましい実施形態において、各トランザクションコーディネータは、このメッセージングプロトコル定義をサポートする。特定的には、各トランザクションコーディネータは、メッセージングプロトコル定義で定義されたとおり、すべての有効なXMLメッセージを受信ならびに送信し、誤った形式のメッセージをログしならびに報告し、および要求に応答して、有効なXMLメッセージを生成することができる。代替的な実施形態において、前記システムは、代わりに、トランザクションコーディネータ202を採用しないOCSP中心モデルとして実装される。この代替的実施形態は、通常に、典型的なOCSPレスポンダによって供給されるよりも、明らかに多くの機能を供給するように適応した、向上したOCSPレスポンダを採用する。特に、向上したOCSPレスポンダは、以下の追加的機能を供給するように適応している:SSLを使用した暗号通信要求と応答の両方のための、未処理トランザクションのロギング応答を伴う証明書チェーンの供給好ましくは、HSMを使用した、要求への署名の確認要求を伴う証明書チェーンの認可その一部は、ローカルデータベースまたはHSMに記憶されていてもよい次のものに基づいた新しい要求の作成受信された要求の、サービスロケータservicelacator要求拡張における値応答を伴う証明書における、オーソリティ情報アクセス拡張応答が、これらの他の新しく作成された要求において受信されるまでの、要求での処理の延期。すなわち、要求への応答を同期させる機能。適切なときの、転送の応答この代替的実施形態は、新しいサービスを追加する柔軟性を与えることなく、証明書ステータスチェックサービスの一部のみを供給する。また、請求は、この代替的実施形態においては実行されない。さらに、この代替的実施形態は、ベンダロッキングvendorlockingを生じさせるかもしれない。この代替的実施形態の賛否両論の詳細が以下に列挙されている。図14は、この代替的実施形態のためのトランザクションの流れを示す。図14におけるメッセージの流れは、以下の表に要約されている:1署名取引先subscribingcustomerSCは、署名されたデータ、署名、SCおよびIP証明書任意でCSSDを、信用取引先relyingcustomerRCに送信する。2RCは、SCによって送信されたデータの署名を確認し、SCの証明書チェーンを認可し、それからSC証明書番号を含むOCSP要求を作成する。このデータは、署名のために、HSMに送信される。3RCによって署名された、SCの証明書に対するOCSP要求は、RCの証明書チェーンとともに、信用関係先relyingparticipantRPOCSPレスポンダORに送信される。証明書チェーン全体が、メッセージとともに渡されなければならない。4RPOCSPレスポンダは、そのOCSPログに、要求をログする。RPOCSPレスポンダは、要求における署名を確認し、およびRCの証明書チェーンを認可する。すべての確認はソフトウェアで実行される。チェーン全体ルートを含むは、署名/証明書チェーンの確認が実行されるように、メッセージとともに渡されなければならない。RCの証明書が取り消されなかったことを確証するためのチェックは、実行されない。5RPOCSPレスポンダは、RCから受信された単一の要求を含む、新しい要求を作成し、そのHSMを用いてそれに署名する。金融機関の間での、署名された要求は、必要とされない。その代わり、ルートエンティティROOTは、確認/認可/取引先検索が、SSL接続と関連する証明書に基づいているような場合である、SSLクライアント側認証を要求してもよい。6RPOCSPレスポンダは、受信された要求の、サービスロケータ要求拡張における値に基づいて、署名されたOCSP要求を、適切な発行関係先のOCSPレスポンダに送信する。7IPOCSPレスポンダは、そのOCSPログに、要求をログする。IPOCSPレスポンダは、要求における署名を検査し、RPORの証明書チェーンを認可する。すべての検査はソフトウェアで実行される。チェーン全体ルートを含むは、署名/証明書チェーンの検査が実行されるようにするために、メッセージとともに渡されなければならない。8IPOCSPレスポンダは、RPOCSPレスポンダの証明書番号を含むOCSP要求を作成し、およびそのHSMを用いてそれに署名する。9IPOCSPレスポンダはそれから、ステップ4において受信された要求における署名に関連した証明書におけるオーソリティ情報アクセス拡張に基づいて、ROOTOCSPレスポンダに要求を送信する。IPOCSPレスポンダは、SCの証明書における応答を発行する前に、RPOCSPレスポンダの証明書に関するROOTからの応答を待つ。IPがSSLクライアント側認証のみを要求し、署名されたOCSP要求を求めない場合、このステップは必要ではないかもしれない。10ROOTOCSPレスポンダは、そのOCSPログに、要求をログする。ROOTOCSPレスポンダは、要求における署名を確認し、IPOCSPレスポンダの証明書チェーンを認可する。金融機関の間で署名された要求は求められない。その代わり、ROOTは、確認/認可/取引先検索が、SSL接続に関連する証明書に基づいている場合である、SSLクライアント側認証を求めるかもしれない。11ROOTOCSPレスポンダは、RPOCSPレスポンダの証明書のステータスを決めるために、そのローカルデータベースを調べ、それから応答を生成し、およびそのHSMを用いてそれに署名をする。12ROOTOCSPレスポンダは、それから応答をIPOCSPレスポンダに返す。13IPOCSPレスポンダは、そのOCSPログに、応答をログする。IPOCSPレスポンダは、要求における署名を確認し、およびルートのOCSPレスポンダ証明書チェーンを認可する。しかしながら、否認防止をサポートするのに十分な情報が、ログに維持されていないかもしれないことが注目される。証明書チェーン全体は、メッセージとともに渡されなければならない。14IPOCSPレスポンダは、それから、SCの証明書のステータスを決めるために、そのローカルデータベースを調べる。IPOCSPレスポンダは、応答を生成し、およびそのHSMを用いてそれに署名をする。15IPOCSPレスポンダは、署名された応答を、RPOCSPレスポンダに送信する。16RPOCSPレスポンダは、OCSPログに、OCSP応答をログする。RPOCSPレスポンダは、応答における署名を確認し、およびIPのOCSPレスポンダ証明書チェーンを認可する。証明書チェーン全体は、メッセージとともに渡されなければならない。17RPOCSPレスポンダは、IPOCSPレスポンダの証明書の番号を含むOCSP要求を作成し、およびそのHSMを用いてそれに署名をする。18RPOCSPレスポンダはそれから、ステップ14で受信された応答における署名に関連する証明書におけるオーソリティ情報アクセス拡張に基づいて、ROOTOCSPレスポンダに要求を送信する。19ROOTOCSPレスポンダは、そのOCSPログに、未処理要求をログする。ROOTOCSPレスポンダは、要求における署名を確認し、およびRPOCSPレスポンダの証明書チェーン全体を認可する。証明書チェーン全体は、メッセージとともに渡されなければならない。20ROOTOCSPレスポンダは、IPOCSPレスポンダの証明書のステータスを決めるために、そのローカルデータベースを調べ、それから応答を生成し、およびそのHSMを用いてそれに署名をする。21ROOTOCSPレスポンダは、署名された応答を、OCSPレスポンダに送信する。22RPOCSPレスポンダは、そのOCSPログに、応答をログする。RPOCSPレスポンダは、応答における署名を確認し、およびルートのOCSPレスポンダ証明書チェーンを認可する。証明書チェーンは、メッセージとともに送信されてもよく、またはチェーンの一部は、HSMか、または証明書確認データベースにあってもよい。23RPOCSPレスポンダは、それがステップ2において例えば、一回だけ受信した情報、およびステップ14においてそれが受信したSCの証明書に関するステータス情報を含むRCに関する応答を作成し、およびそのHSMを用いてそれに署名をする。24RPOCSPレスポンダは、RCに応答を返す。25RCは、応答における署名を確認するため、およびRPのOCSPレスポンダ証明書チェーンを認可するために、そのHSMを使用する。証明書チェーンは、メッセージとともに渡されてもよく、またはチェーンの一部がHSMにあってもよい。26RCは、IPの証明書番号を含むOCSP要求を作成する。このデータは、署名のために、HSMに送信される。27RCによって署名された、IPの証明書に対するOCSP要求は、RCの証明書チェーンとともに、信用関係先RPOCSPレスポンダORに送信される。証明書チェーン全体は、メッセージとともに渡される必要がある。28RPOCSPレスポンダは、そのOCSPログに、要求をログする。RPOCSPレスポンダは、要求における署名を確認し、およびRCの証明書チェーンを認可する。すべての確認はソフトウェアで実行される。チェーン全体ルートを含むは、署名/証明書チェーンの確認が実行されるようにするために、メッセージとともに渡されなければならない。RCの証明書が取り消されなかったことを確証するためのチェックは実行されない。29RPOCSPレスポンダは、RCから受信された単一の要求を含む、新しい要求を作成し、およびそのHSMを用いてそれに署名をする。金融機関の間で署名された要求は、必要とされない。その代わり、ROOTは、確認/認可/取引先検索が、SSL接続に関連する証明書に基づいている場合である、SSLクライアント側認証を求めてもよい。30RPOCSPレスポンダは、受信された要求のサービスロケータ要求拡張における値に基づいて、署名されたOCSP要求を、ROOTOCSPレスポンダに送信する。31ROOTOCSPレスポンダは、そのOCSPログに、要求をログする。ROOTOCSPレスポンダは、要求における署名を確認し、およびRPORの証明書チェーンを認可する。すべての確認は、ソフトウェアで実行される。チェーン全体ルートを含むは、署名/証明書チェーンの確認が実行されるようにするために、メッセージとともに渡されなければならない。32ROOTOCSPレスポンダは、RPOCSPレスポンダの証明書のステータスを決めるために、そのローカルデータベースを調べ、それから応答を生成し、およびそのHSMを用いて、それに署名する。33ROOTOCSPレスポンダはそれから、RPOCSPレスポンダに応答を返す。34RPOCSPレスポンダは、そのOCSPログに、応答をログする。RPOCSPレスポンダは、応答における署名を確認し、およびROOTのOCSPレスポンダ証明書チェーンを認可する。否認防止をサポートするのに十分な情報が、ログにないかもしれないことが注目される。証明書チェーン全体は、メッセージとともに渡されなければならない。このOCSP代理中心モデルは、上述のトランザクションコーディネータモデルと比較すると、長所と短所がある。この代替的実施形態の賛否両論は、以下の表に要約されている:OCSPレスポンダ204に対する技術的およびセキュリティの要件は、好ましくは、ルートエンティティ110によって特定される。要件の、例示的な一例が、後述されている。技術的要件好ましい実施形態において、各OCSPレスポンダ204は、オンライン証明書ステータスプロトコルOnlineCertificateStatusProtocolOCSPにしたがって動作する。好ましい実施形態において、OCSPレスポンダ204がOCSP要求を受信するとき、リクエスタの証明書を認可し、リクエスタを認証し、およびリクエスタは、リクエスタの証明書にローカルステータスチェックを実行することによって、要求を受信した関係先との、契約したシステムユーザであるか確認する。リクエスタの認証は、機関間の要求の場合は、署名したOCSP要求を用いて、または、取引先要求の場合は、安全ソケットレイヤクライアント認証を通して達成されてもよい。さらに、安全ソケットレイヤは、すべての要求の機密性を確証することを求められてもよい。好ましい実施形態において、各OCSPレスポンダ204は、要求されたサービスのロケータ拡張およびローカルテーブルに基づいて機関間要求をする時、ピアサーバpeerserverを選択する。代替的実施形態において、この情報は、軽量ディレクトリアクセスプロトコルLDAP検索によって得られてもよい。好ましい実施形態において、各OCSPレスポンダ204は、ルートエンティティ110によって特定された規則に従った証明書をキャッシュしてもよい。好ましい実施形態において、各OCSPレスポンダ204は、機関間応答が、承認されたレスポンダ証明書によって署名されたか確認する。機関間OCSP要求に関して、信用関係先204のOCSPレスポンダは、好ましくは、例えば発行関係先102からの応答を、それをリクエスタに送信する前に、再署名する。好ましい実施形態において、各OCSPレスポンダは、以下の応答:取り消し、良、および不明をサポートする。クライアントOCSPレスポンダが、時間tにおいて作られた特定の証明書に関する取り消された応答を受信した場合、クライアントOCSPレスポンダは、前記証明書、または前記証明書の証明書チェーンにおけるある証明書が、時間tより前に取り消されたとみなす。そのようなものとして、クライアントOCSPレスポンダは、チェックされた証明書に対応するプライベートキーを用いて、時間tの後にデジタル署名されたドキュメントに対する責任を、サーバOCSPレスポンダに移すための、十分な根拠を有しない。クライアントOCSPレスポンダが、時間tにおいて作られた特定の証明書に関する良い応答を受信する場合、クライアントOCSPレスポンダは、前記証明書およびその証明書チェーンにおける一つおきの証明書が、時間tにおいて、すべて支払済みingoodstandingであったとみなす。そのようなものとして、クライアントOCSPレスポンダは、時間tの前にデジタル署名されたドキュメントに関する責任を、サーバOCSPレスポンダに移すのに十分な根拠を有する。クライアントOCSPレスポンダは、時間tにおいて作られた特定の証明書に関する不明応答を受信した場合、クライアントOCSPレスポンダは、前記証明書、または前記証明書の証明書チェーンにおける一つの証明書が、すべて支払済みであるか、不明であるとみなす。そのようなものとして、クライアントOCSPレスポンダは、チェックされた証明書に対応するプライベートキーを用いてデジタル署名されたドキュメントに関する責任を、サーバOCSPレスポンダに移すのに十分な根拠を有していない。セキュリティ要件好ましい実施形態において、各OCSPレスポンダ204は、そのプライベートキーを、ルートエンティティ110によって確立された要件に適合するハードウェアセキュリティモジュールに記憶する。好ましい実施形態において、各OCSPレスポンダ204は、サーバ安全ソケットレイヤ、クライアント安全ソケットレイヤおよびOCSP応答に対して別個のキーを使用する。好ましい実施形態において、各OCSPレスポンダ204は、機関によって強くなったプラットフォームコンフィギュレーションで動作することができる。機関が強化したプラットフォームは、機関のファイアウォール内の使用に関して承認された、試験をし、およびテストをしたプラットフォームである。好ましい実施形態において、各OCSPレスポンダ204は、すべての署名された要求および応答、すべての例外またはエラー、およびすべての管理およびコンフィギュレーション動作の詳細なログを維持する。好ましい実施形態において、各OCSPレスポンダ204は、すべての管理トランザクションに対してエンティティを認証するために、安全ソケットレイヤクライアント認証等、強い認証を使用する。好ましい実施形態において、各OCSPレスポンダ204は、ルートエンティティ110によって確立された、最小限のセキュリティ要件に適合する。さらに、OCSPレスポンダを維持する機関は、追加のOCSPレスポンダセキュリティ規則を特定してもよい。好ましい実施形態において、各OCSPレスポンダ204は、反復した方法で、高度に利用可能で、および採用可能になるように構成される。さらに、各OCSPレスポンダは、好ましくは、1秒より少ない時間で、すべての要求に応答する。OCSPレスポンダは、通常、ユーティリティ証明書のチェックを実行することを求められない。しかしながら、OCSPレスポンダは、リクエスタに、ユーティリティ証明書のステータスへの、認証されていないアクセスを許可するように構成されているかもしれない。好ましい実施形態において、各OCSPレスポンダは、機関のレポジトリへの認証されたインターフェースとして機能するように求められるかもしれない。この好ましい実施形態の実装の詳細は、OCSPレスポンダを維持するエンティティに委ねられてもよい。好ましい実施形態において、各OCSPレスポンダは、追加機能をサポートするための追加インターフェースを具備する。特に、各OCSPレスポンダは、好ましくは、情報を、関係先の顧客サービス要件をサポートするために利用可能にするための、追加インターフェースを具備する。さらに、各OCSPレスポンダは、好ましくは、システムおよびイベントログを外部に出すための、機関によって定義された標準インターフェースを具備してもよい。各OCSPレスポンダはまた、請求アプリケーションのための情報を外部に出すためのインターフェースを具備してもよい。請求データは、ログを含むあらゆる形式で外部に出されも良いが、好ましくは、リクエスタが、要求の種類およびボリュームを決定することができるようにする。好ましい実施形態において、図1に記載の関係先102、104は、ルートエンティティ110によって直接デジタル証明書を発行されるので、レベル1関係先と称される。従って、各関係先の証明書チェーンは、ルートエンティティ110から開始する。各レベル1関係先は、他のレベル1関係先の証明書のステータスを入手するため、ルートエンティティ110に依存する。さらなる好ましい実施形態において、本システムは、レベル2関係先と呼ばれる、追加的関係先を含んでもよい。各レベル2関係先は、好ましくは、それと関連するレベル1関係先によって、デジタル証明書を発行される。これらレベル2関係先は、それらの別個の取引先に対する認証局として機能し、および前記取引先にシステムサービスを供給してもよい。レベル1関係先は、好ましくは、レベル2関係先に対して最高点の信頼を与える。そのようなものとして、レベル2関係先は、好ましくは、彼らの保証となるレベル1関係先に直接報告する。レベル2関係先はまた、他の関係先の証明書のステータスを入手するために、彼らの保証となるレベル1関係先に依存しなければならない。レベル1およびレベル2関係先を含む好ましい実施形態はさらに、係属アメリカ合衆国特許出願第09/502,450号、2000年2月11日提出、証明関連および他のサービスを供給するためのシステムおよび方法と題した前記出願に記述されており、それは、参照のためにここに統合されている。好ましい実施形態において、各関係先は、各関係先のハードウェアならびにソフトウェアコンポーネントの動作環境を識別する、ハードウェアならびにソフトウェアコンフィギュレーションベースラインを集合的に実装しおよび維持する。そのようなものとして、コンフィギュレーションベースラインは、システムの日々の動作および管理を容易にするコンフィギュレーションリファレンスconfigurationreferenceとして機能する。前記ベースラインは、システムワイドなレベルで、一以上の関係先によってなされるコンフィギュレーション変更の統括を容易にする。さらに、ベースラインは、一つ以上の認証局のハードウェアまたはソフトウェア故障の場合に、システムワイドなサービスリカバリを容易にする。好ましい実施形態において、本システムの、コンフィギュレーションベースラインのマスタコピーは、ルートエンティティ110によって維持される。通常、マスタコピーは、事業の副社長等、ルートエンティティ110の役員が保持する。好ましい実施形態において、ルートエンティティ110は、ルートエンティティ110のハードウェアおよびソフトウェアコンフィギュレーションの、真実の、および正確な記録を保持する。ルート認証局のコンフィギュレーションベースラインの少なくとも3のコピーが、以下の三つのロケーションに、ルートエンティティ110によって保持される:1ルート認証局と同じ物理的ロケーションであり、それによって動作上の変更が生じたときに、それらが記録されるようにする;2ルート認証局の物理的ロケーションの外部にある安全ロケーションであるが、制御されたコンテナである;および3ルートエンティティ110のバックアップおよびアーカイブ記録を伴うオフサイトoffsiteロケーションである。このハードウェアおよびソフトウェアコンフィギュレーションの他のコピーは、ルートエンティティ110の判断で、レベル1認証局に供給されてもよい。好ましい実施形態において、各レベル1関係先は、その認証局アーキテクチャのハードウェアおよびソフトウェアコンフィギュレーションの、真実であり、かつ正確な記録を維持する。各レベル1関係先は、好ましくは、以下の三つのロケーションに、そのコンフィギュレーションベースラインドキュメントの少なくとも3のコピーを準備し、保持し、および維持する:1レベル1認証局の同じ物理的ロケーションであり、それによって動作上の変更は、それらが生じると記録されるようにする;2レベル1認証局の物理的ロケーションの外部である安全ロケーションであるが、制御されたコンテナである;および3レベル1認証局のバックアップおよびアーカイブ記録を伴うオフサイトロケーションである。さらに、各レベル1関係先は、好ましくは、そのコンフィギュレーションベースラインのコピーを、ルートエンティティ110に供給する。好ましい実施形態において、レベル2関係先も、それらの認証局アーキテクチャのハードウェアおよびソフトウェアコンフィギュレーションの真実の、および正確な記録を維持する。各レベル2関係先は、以下の三つのロケーションにおいて、そのコンフィギュレーションドキュメントの、少なくとも三つのコピーを準備し、保持し、および維持する:1レベル2認証局と同じ物理的ロケーションであり、それによって、動作上の変更が生じたときに、それらが記録されるようにする;2レベル2認証局の物理的ロケーションの外部にある安全ロケーションであるが、制御されたコンテナである;および3レベル2認証局のバックアップおよびアーカイブ記録を伴うオフサイトロケーションである。さらに、各レベル2関係先は、好ましくは、そのコンフィギュレーションベースラインを、その保証しているレベル1認証局に供給する。ハードウェアおよびソフトウェアコンフィギュレーションの文書化を容易にするための形式が供給されてもよい。好ましい実施形態において、ルートエンティティ110の、ならびに各関係先の認証局ディレクトリ、OCSPレスポンダ、およびインターネットファイアウォールのハードウェアならびにソフトウェアコンフィギュレーションも、文書化される。好ましい実施形態において、ルートエンティティ110は、システムワイドレベルでの、コンフィギュレーション管理に対する重要な責任を有する。この責任は通常、事業の副社長等、ルートエンティティ110の役員に委任される。各認証局は、好ましくは、認証局のハードウェアおよびソフトウェアコンフィギュレーションの正確な記録を維持することに対する、操作上の責任を有する技術操作スタッフを有する。好ましい実施形態において、各認証局の初期コンフィギュレーションベースラインは、各下位認証局のコンフィギュレーションベースラインを託すことによって、作られる。好ましい実施形態において、コンフィギュレーション変更は、以下の基準に従わなければならない:1コンフィギュレーション変更は、定義されたシステム要件に取り組むことを求められなければならない;2コンフィギュレーション変更は、認証局のオペレーションスタッフによって推奨されなければならない;3オペレーショナルプラットフォームのコンフィギュレーション変更は、ルートエンティティの場合には、事業の副社長等、役員によって、およびレベル1またはレベル2認証局の場合には、認証局の完全性に対して責任がある最高幹部によって承認されなければならない;4コンフィギュレーション変更の通知は、影響のある当事者に対して行われなければならない;5コンフィギュレーション変更は、統治または基準設定機関によって示される、関連するコンフィギュレーション変更基準を考慮しなければならない;および6コンフィギュレーション変更は、変更日および前のコンフィギュレーションの各々の期間を公表することによって、記録されなければならない。各認証局は、通常、バックアップテープ等、他の保管された素材とともに、コンフィギュレーション変更を保管する。好ましい実施形態において、コンフィギュレーションベースラインは、ルートエンティティのシステムセキュリティポリシーと関連して実装され、および各認証局の監査されたコンポーネントである。本発明は、特定の実施形態との関係において記述されてきたが、数多くの代替例、変更および変形が、前述の説明に照らして、当業者には明らかであることが明白である。"