(57)【特許請求の範囲】
【請求項１】
クライアント・データ処理装置が、データ処理要求をサーバ・データ処理装置に送信し、前記サーバ・データ処理装置が、前記要求に基づいてデータ処理を実行し、前記クライアント・データ処理装置に応答を返す、クライアント／サーバ・ネットワークにおいて使用する前記クライアント・データ処理装置及び前記サーバ・データ処理装置のうちの一方のデータ処理装置（以下「ローカル・データ処理装置」という）であって、
複数のローカル・サイト証明書を保管するための記憶手段と、
前記クライアント／サーバ・ネットワークにおける通信相手である前記クライアント・データ処理装置及び前記サーバ・データ処理装置のうちの他方のデータ処理装置（以下「相手サイト・データ処理装置」という）から第１証明書要求を受信するための手段と、
前記第１証明書要求の内容に依存する第２証明書要求を前記相手サイト・データ処理置に送信するための手段とを含み、
前記第１証明書要求は、前記記憶手段に保管された前記ローカル・サイト証明書であって、前記第１証明書要求と共に供給される第１論理式を満足する証明書であるローカル・サイト証明書を要求し、
前記第２証明書要求は、前記第２証明書要求と共に供給される第２論理式を満足する相手サイト証明書を要求する
ローカル・データ処理装置。
【請求項２】
前記記憶手段が、複数の証明書アクセス・ポリシも保管し、各ポリシが、相手サイト証明書に基づいて対応するローカル・サイト証明書へのアクセスを管理する、請求項１に記載のローカル・データ処理装置。
【請求項３】
前記第１証明書要求と共に供給される前記第１論理式が、前記記憶手段に保管されたローカル・サイト証明書の組合せによって満足されるかどうかを判定し、前記第１証明書要求と共に供給される前記第１論理式が、前記記憶手段に保管されたローカル・サイト証明書の組合せによって満足されるという判定が行われる場合に、前記第１証明書要求と共に供給される前記第１論理式を満足するローカル・サイト証明書の前記組合せを管理し、かつ、前記記憶手段に保管される前記証明書アクセス・ポリシが、ローカルに使用可能な相手サイト証明書によって満足されるかどうかを判定するための判定手段と、
前記判定手段が、前記証明書アクセス・ポリシがローカルに使用可能な相手サイト証明書によって満足されると判定する場合に、ローカル・サイト証明書の前記組合せを前記相手サイト・データ処理装置に送信するための送信手段と、
前記判定手段が、前記証明書アクセス・ポリシがローカルに使用可能な相手サイト証明書によって満足されないと判定する場合に、ローカルに使用可能な相手サイト証明書と一緒になって、ローカル・サイト証明書に関する前記第１証明書要求と共に供給される前記第１論理式を満足するローカル・サイト証明書の前記組合せを管理する前記ローカル証明書アクセス・ポリシを満足する、相手サイト証明書に関する第２証明書要求内の第２論理式を導出するために、（ａ）前記受信した第１証明書要求と、（ｂ）前記保管されたローカル・サイト証明書と、（ｃ）前記保管された証明書アクセス・ポリシとを論理的に組み合わせるための論理組合せ手段と
をさらに含む、請求項２に記載のローカル・データ処理装置。
【請求項４】
ローカルに使用可能な相手サイト証明書が、前記記憶手段にキャッシングされる、請求項３に記載のローカル・データ処理装置。
【請求項５】
前記判定手段が、そのような組合せが存在しないことを発見した時に、その発見を伝えるメッセージを前記相手サイト・データ処理装置に送信する、請求項３に記載のローカル・データ処理装置。
【請求項６】
前記クライアント／サーバ・ネットワークが、インターネットである、請求項１に記載のローカル・データ処理装置。
【請求項７】
クライアント・データ処理装置が、データ処理要求をサーバ・データ処理装置に送信し、前記サーバ・データ処理装置が、前記要求に基づいてデータ処理を実行し、前記クライアント・データ処理装置に応答を返す、クライアント／サーバ・ネットワークにおいて使用する前記クライアント・データ処理装置及び前記サーバ・データ処理装置のうちの一方のデータ処理装置（以下「ローカル・データ処理装置」という）を作動させる方法であって、前記ローカル・データ処理装置が、プロセッサ、データ送受信手段及び複数のローカル・サイト証明書を保管するための記憶手段を含み、
前記データ受信手段が、前記クライアント／サーバ・ネットワークにおける前記クライアント・データ処理装置及び前記サーバ・データ処理装置のうちの他方のデータ処理装置（以下「相手サイト・データ処理装置」という）から第１証明書要求を受信するステップであって、前記第１証明書要求によって要求される証明書が、前記第１証明書要求と共に供給される第１論理式を満足する、前記記憶手段に保管されたローカル・サイト証明書である、ステップと、
前記データ送信手段が、前記第１証明書要求の内容に依存する第２証明書要求を前記相手サイト・データ処理装置に送信するステップであって、前記第２証明書要求によって要求される証明書が、前記第２証明書要求と共に供給される第２論理式を満足する相手サイト証明書である、ステップと
を含む方法。
【請求項８】
前記記憶手段が、複数の証明書アクセス・ポリシも保管し、各ポリシが、相手サイト証明書に基づいて対応するローカル・サイト証明書へのアクセスを管理する、請求項７に記載の方法。
【請求項９】
前記プロセッサにおいて、前記第１証明書要求と共に供給される前記第１論理式が、前記記憶手段に保管されたローカル・サイト証明書の組合せによって満足されるかどうかを判定し、前記第１証明書要求と共に供給される前記第１論理式が、前記記憶手段に保管されたローカル・サイト証明書の組合せによって満足されるという判定が行われる場合に、前記プロセッサにおいて、前記第１証明書要求と共に供給される前記第１論理式を満足するローカル・サイト証明書の前記組合せを管理し、かつ、前記記憶手段に保管される前記証明書アクセス・ポリシが、ローカルに使用可能な相手サイト証明書によって満足されるかどうかを判定するステップと、
前記判定ステップが、前記証明書アクセス・ポリシがローカルに使用可能な相手サイト証明書によって満足されると判定する場合に、前記データ送信手段が、ローカル・サイト証明書の前記組合せを前記相手サイト・データ処理装置に送信するステップと、
前記判定ステップが、前記証明書アクセス・ポリシがローカルに使用可能な相手サイト証明書によって満足されないと判定する場合に、ローカルに使用可能な相手サイト証明書と一緒になって、ローカル・サイト証明書に関する前記第１証明書要求と共に供給される前記第１論理式を満足するローカル・サイト証明書の前記組合せを管理する前記ローカル証明書アクセス・ポリシを満足する、相手サイト証明書に関する第２証明書要求内の第２論理式を導出するために、前記プロセッサにおいて、（ａ）前記受信した第１証明書要求と、（ｂ）前記保管されたローカル・サイト証明書と、（ｃ）前記保管された証明書アクセス・ポリシとを論理的に組み合わせるステップと
をさらに含む、請求項８に記載の方法。
【請求項１０】
ローカルに使用可能な相手サイト証明書が、前記記憶手段にキャッシングされる、請求項９に記載の方法。
【請求項１１】
前記クライアント／サーバ・ネットワークが、インターネットである、請求項７に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ある計算装置（「クライアント」）が別の計算装置（「サーバ」）にクライアントの作業の一部を実行するよう要求する、クライアント／サーバ（「分散」とも称する）コンピューティングの分野に関する。
【０００２】
【従来の技術】
クライアント／サーバ・コンピューティングは、過去数年間に、情報技術の世界でますます重要になってきた。この種の分散コンピューティングを用いると、ある計算機で稼動するソフトウェア・プロセス（たとえばクライアント）が、たとえばその作業を実行するのにより適する可能性がある、別の計算機で稼動するソフトウェア・プロセス（たとえばサーバ）にその作業の一部を委任することができるようになる。クライアントおよびサーバは、同一の計算機で稼動する別々のソフトウェア・プロセスとすることもできる。
【０００３】
そのようなクライアント／サーバ・システムでは、クライアントとサーバが、意味のある対話に従事する前に、お互いへの十分なレベルの信頼を築くことが非常に重要である。というのは、クライアントによるサーバ処理の要求中に交換される可能性がある情報またはクライアントに返されるサーバの処理結果もしくはその両方が、非常に重要な情報である可能性があるからである。しばしば、クライアントおよびサーバは、お互いとの前の関係がなく、したがって、潜在的に重要な情報を開示する前に、お互いを信頼できるかどうかを判定するためにある種の最初の会話に入らなければならない。これが特に有用である場合の良い例が、クライアントが、インターネットを介してワールド・ワイド・ウェブ・サーバ・アプリケーションに電子商取引要求を送信するワールド・ワイド・ウェブ・ブラウザ・アプリケーションである時である。これらの当事者間の最初の対話では、ウェブ・クライアントおよびウェブ・サーバが、前の関係を持たず、ウェブ・クライアントが、たとえば、インターネットを介してウェブ・サーバにクレジット・カード番号を提供することを非常にしぶる場合がある。
【０００４】
従来技術で、クライアントとサーバの間で信頼を築くためのクライアントとサーバの間の証明書（credential）（すなわち、証明書所有者に関する、証明書発行者によってディジタル署名された主張）の交換が既知である。証明書は、発行者の秘密鍵を使用することによって署名され、発行者の公開鍵を使用することによって検証することができる。証明書によって、所有者の１つまたは複数の属性が集約され、各属性は、名前／値対からなり、発行者によって主張される所有者のある特性が記述される。各証明書には、証明書所有者の公開鍵も含まれる。所有者は、対応する秘密鍵を使用して、チャレンジに回答するか、他の形で証明書の所有権を実証することができる。所有者は、秘密鍵を使用して、第３の実体によって所有される別の証明書に署名することもできる。
【０００５】
したがって、従来技術で周知のように、証明書を組み合わせてチェーンにすることができ、この場合、ある証明書の所有者が、チェーン内の次の証明書の発行者になる。これらのチェーンをサブミットして、既知の実体（チェーンの最初の証明書の発行者）から、信頼を確立する必要があるサブミットする実体までの信頼の網を追跡することができる。サブミットする実体は、チェーンの最後の証明書の所有者である。サブミットする実体は、証明書に含まれる公開鍵の対である秘密鍵の所有を実証することによって、その証明書の所有権を実証することができる。他のサポートする証明書は、サブミットする実体が直接または間接の関係を有する実体によって所有され、これらの証明書は、サブミットする実体によって所有されないが、サブミットする実体は、それらのコピーを保持し、サブミットする。サポートする証明書のそれぞれに、公開鍵が含まれ、これと対になる秘密鍵が、チェーンの次の証明書の署名に使用されたものである。
【０００６】
サブミットされる証明書のすべてが、サブミットする実体と、チェーン内の最初の証明書を発行した既知の実体との間の（おそらくは間接的な）関係の実証に関係する。その関係の性質は、チェーン内の証明書の属性を検査することによって推論することができる。複数のチェーンをサブミットして、より高い度合の信頼を確立するか、サブミットする実体の追加の特性および既知の実体との関係を実証することができる。
【０００７】
証明書を使用して相互信頼を確立する従来技術の技法は、２つの基本的なアプローチに分類することができる。第１のアプローチは、フライヤ（A. Frier）、カールトン（P. Karlton）、およびコッハー（P. Kocher）共著、「The SSL 3.0 Protocol」、Netscape Communications Corporation、１９９６年１１月１８日と、ディアークス（T. Dierks）およびアレン（C. Allen）共著、「The TLS Protocol Version 1.0」、draft-ietf-tls-protocol-06.txt、１９９８年１１月１２日と、ファレル（S. Farrell）著、「TLS Extensions for Attribute Certificate Based Authorization」、draft-ietf-tls-attr-cert-01.txt、１９９８年８月２０日に記載されている。このアプローチは、ＳＳＬ、ＴＬＳ、および属性証明書ベース認証の拡張を伴うＴＬＳによって使用されるので、ＳＳＬアプローチと称する。ＳＳＬアプローチでは、クライアントおよびサーバが、下記のように証明書を交換することができる。サーバは、事前に選択された証明書を一方的に開示することによってネゴシエーションを開始する。これには、サーバが受け入れることができる証明書のタイプ、および属性証明書の場合に、必要な属性を示すテンプレートを含むクライアント証明書の要求を含めることができる。
【０００８】
第２のアプローチは、チン（N. Ching）、ジョーンズ（V. Jones）、およびウィンズレット（M. Winslett）共著、「Authorization in the Digital Library: Secure Access to Services across Enterprise Boundaries」、Proceedings of ADL '96 --- Forum on Research and Technology Advances in Digital Libraries、米国ワシントン州、１９９６年５月、http://drl.cs.uiuc.edu/security/pubs.htmlで入手可能、およびウィンズレット（M. Winslett）、チン（N. Ching）、ジョーンズ（V. Jones）およびスレプチン（I. Slepchin）共著、「Using Digital Credentials on the World-Wide Web」、Journal of Computer Security、５、１９９７年、２５５〜２６７ページ、http://drl.cs.uiuc.edu/security/pubs.htmlで入手可能に記載されている。この第２のアプローチを、本明細書ではディジタル証明書アプローチと称する。このアプローチでは、クライアントによって、適当な証明書を添付されずにサーバに対するサービスの要求が行われる時に、サーバが、クライアントに、そのサービスを管理するポリシを送信する。ポリシは、証明書式すなわち、必要な証明書と、それに含まれる属性に対する表現された制約の論理組合せである。ポリシは、サブミットする実体の必要な特性およびその既知の実体との関係の特性を表すのに使用することができる。このポリシを証明書の要求として受信することによって、クライアントが、プライベート証明書の中でサービスの許可を得るために送信するものを選択する機会を有する。ポリシをクライアントに送信することによって、サーバが、証明書選択をオフロードする。これを実行することによって、異なるサーバが非常に異なるポリシを有し、異なるクライアント属性を要求し、異なる機関によって発行された証明書を受け入れることもできるようになる。
【０００９】
これら２つの従来技術のアプローチの両方が、サーバが受け入れ可能な証明書の特性を含む証明書の要求をサーバがクライアントに送信することをサポートする。しかし、本発明人は、下記のように、この現況技術の欠点に気付いた。
【００１０】
ＳＳＬアプローチでは、サーバの証明書を開示する前に、サーバがクライアントに関する情報を認証する機会がない。サーバは、その証明書を非常に機密性が高いとみなす場合があり、したがって、クライアントおよびサーバが相互信頼の確立に失敗する場合に、サーバは、非常に重要な（機密の）情報をクライアントに渡している。さらに、サーバによって開示される証明書がクライアントを満足させない場合に、クライアントが、サーバに追加の証明書を要求する機会がない。これは、クライアントおよびサーバが前の関係を有しない時に深刻な問題になる可能性がある。その場合には、単一の証明書発行者が、すべてのクライアントに重要なすべてのサーバ属性に対する許容可能な権威になる見込みがない。
【００１１】
【発明が解決しようとする課題】
ディジタル証明書アプローチに基づく従来のシステムの短所は、クライアントが、ある度合の信頼が既に確立されているサーバだけに開示することを望む証明書に関して生じる。ディジタル証明書アプローチを使用して開発された従来のシステムは、サービスを等価なクラスに区分し、その後、等価クラスごとに、各クライアント証明書を２つのカテゴリの１つに割り当てた、クライアント証明書サブミッション・ポリシをサポートした。第１カテゴリの証明書は、等価クラス内のすべてのサービス要求と共にサブミットすることができる。第２カテゴリの証明書は、認証について対話的にユーザに相談した後に限ってサブミットすることができる。これらの相談によって、ユーザが、証明書を第２カテゴリから第１カテゴリに移動することができ、後続の自動サブミットが可能になった。しかし、この機構は、新しいサービス・クラスに接する時に信頼判断を行うためにユーザの手があいていることを必要とするという点で、完全に自動化されてはいない。
【００１２】
ディジタル証明書アプローチの文脈内で、代替技法がウィンズレット他（上掲）に簡単に記載されており、これによって、クライアントが、それ自体の証明書の開示のロックを解除するために、サーバ証明書を要求することができる。その技法は、各参加者による単一の証明書要求があるネゴシエーションの実施に使用することができる。各サービスには、クライアントがそのサービスを要求する時にサーバによってクライアントに送信されるポリシが関連する。シナリオが逆転される時には、サーバに、クライアントに証明書を提示させることによってどの目的が意図されているかが不明瞭である。１つの可能性は、サーバとの汎用の対話のためにクライアント信頼を確立することである。もう１つの可能性は、特にクライアントがその証明書を開示することを奨励するために信頼を確立することである。後者の場合に、このアプローチを使用して、クライアントがそれ自体の証明書のいずれかをサーバに開示する前に、クライアントがサーバに証明書を要求できるようにすることができる。しかし、その場合、サーバが、それ自体の証明書を開示する前にクライアント証明書を要求することが不可能になる。それを行うことによって、循環依存性が導入され、ネゴシエーションがデッドロックすることになる。というのは、このモデルでは、すべてのクライアント証明書が、同一のポリシによって管理され、したがって、後続のサーバ要求が、クライアントからの同一の要求につながるからである。
【００１３】
【課題を解決するための手段】
第１の態様によれば、本発明は、クライアント・データ処理装置が、データ処理要求をサーバ・データ処理装置に送信し、前記サーバ・データ処理装置が、上記要求に基づいてデータ処理を実行し、前記クライアント・データ処理装置に応答を返す、クライアント／サーバ・ネットワークにおいて使用する前記クライアント・データ処理装置及び前記サーバ・データ処理装置のうちの一方のデータ処理装置（各請求項においては、「ローカル・データ処理装置」と称する）であって、複数のローカル・サイト証明書を保管するための記憶手段と、クライアント／サーバ・ネットワークにおける通信相手である前記クライアント・データ処理装置及び前記サーバ・データ処理装置のうちの他方のデータ処理装置（各請求項においては、「相手サイト・データ処理装置」と称し、【発明の実施の形態】においては、単に「対向サイト・データ処理装置」と称する）から第１証明書要求を受信するための手段と、第１証明書要求の内容に依存する第２証明書要求を前記相手サイト・データ処理置に送信するための手段とを含むローカル・データ処理装置を提供する。ここで、第１証明書要求は、記憶手段に保管されたローカル・サイト証明書であって、第１証明書要求と共に供給される第１論理式を満足するローカル・サイト証明書を要求する。また、第２証明書要求は、第２証明書要求と共に供給される第２論理式を満足する相手サイト証明書（【発明の実施の形態】においては、単に「対向サイト証明書」と称する）を要求する。
【００１４】
第２の態様によれば、本発明は、第１の態様によるデータ処理装置を作動させる方法を提供する。
【００１７】
したがって、本発明は、証明書開示の相互依存型要求のシーケンスをサポートするために、従来技術のディジタル証明書アプローチを拡張する。証明書開示の相互依存型要求のシーケンスを可能にするために、異なる証明書を、異なるポリシによって管理しなければならない。クライアントがサーバから受信する証明書の要求は、個々の証明書に関するものではなく、証明書の特定の組合せに関するものでもない。そうではなくて、その要求は、論理式を満足する任意の証明書に関するものである。本発明では、証明書に関する着信要求が、クライアントによって実際に所有される証明書と、これらの証明書のそれぞれに関連するアクセス制御ポリシと共に論理的に組み合わされて、対向サイト証明書の新しい要求が導出される。したがって、本発明には、応答要求が着信要求から独立である場合を除いて、ローカル証明書アクセス・ポリシおよび証明書に関する着信要求から証明書に関する応答要求を導出することが含まれる。応答要求が着信要求から独立である場合には、上で述べたように、循環依存性のゆえに、増分証明書開示のシーケンスが不可能である。
【００１８】
従来の解決策では、証明書開示を管理する基礎としての証明書の使用が明示的に推奨されていない。証明書の間の相互依存性の問題と、あるデッドロックを回避するための、異なるポリシに関する異なる証明書アクセス・ポリシの要求の必要に関する記述はない。過去に見落とされてきた、証明書をプライベートに保つ見知らぬものの間の信頼確立の自動化の諸態様がある。
【００１９】
信頼確立中に動的に合成される証明書要求に関する従来の記述もない。従来の解決策では、既存のポリシから証明書要求内容が選択された。
【００２０】
したがって、本発明は、その証明書を保護する見知らぬデータ処理装置の間の信頼ネゴシエーションの完全な自動化を提供する。単純なネゴシエーション戦略を、即座に適用することができる。成功裡のネゴシエーションと保持される証明書に関する情報の故意でない開示の回避の問題のバランスをとる、より洗練された技法も、考慮することができる。
【００２１】
本発明によって提供される重要な長所は、本発明によって、関係する当事者が、その証明書の一部を他方の当事者に開示する前に、他方の当事者の多少の知識を必要とする時であっても、信頼を自動的に確立できるようになることである。従来の解決策では、各参加者が、各ネゴシエーション内で証明書を提示する機会を１回だけ有し、参加者の１つが先に行わなければならなかった。従来の解決策と異なり、本発明は、ネゴシエーション参加者のいずれかが、他の参加者の知識なしで、その証明書をすべて１度に開示することを必要としない。非常に重要なサービスを得るために、クライアントが、まず適度に重要なサーバ証明書を得た後に限って開示する非常に重要な証明書をサブミットしなければならない場合がある。このために、サーバが、ある多少重要性の低い証明書を要求する場合がある。
【００２２】
本発明によって、依存証明書交換の任意の長さのシーケンスをネゴシエートすることが可能になる。いくつかの場合に、そのようなシーケンスによって、単一の交換で可能な度合より高い度合の信頼をネゴシエートできるようにすることが可能である。これによって、自動化されたビジネス・ネゴシエーションが、参加者が誠実に取引し、開示された情報を適当に扱う、高い度合の信頼を必要とする、見知らぬものの間のe-business（すなわち電子ビジネス）に関して、新しい解決策が潜在的に非常に重要になる。
【００２３】
本発明は、増分証明書開示の自動ネゴシエーションの基礎を提供する。これは、ローカル・サイトに保持される証明書のそれぞれに、対向サイト証明書に基づいてアクセス・ポリシを関連付けることと、そのポリシと着信証明書要求との論理組合せを提供してネゴシエーション応答を導出することによって行われる。
【００２４】
【発明の実施の形態】
本発明の好ましい実施形態では、複数のデータ処理ユニットが、データ通信ネットワークを介して互いに通信する。図１では、ローカル・サイト１０が、対向サイト１１とネットワーク（図示せず）を介して通信し、これらのサイトの両方が、好ましい実施形態のデータ処理ユニットであることを示す（もう１つの実施形態では、これらを、同一のデータ処理ユニット内で稼動する別のプロセスとすることができる）。上で述べた第２の従来技術のアプローチ［チン他、ウィンズレット他］に従って、データ処理ユニット（すなわちネゴシエーション参加者）が、図１に示されているように、信頼ネゴシエーションにおいて、セキュリティ・エージェント１０１によって表される。各ネゴシエーション参加者は、証明書の要求（図１の着信証明書要求２１）を受信することができる（証明書の要求のそれぞれは、上で述べた第２の従来技術のアプローチの場合のように、証明書式の形をとる）。この要求は、対向サイトへのローカル・サイト証明書の開示に関するものである。この開示の目的は、サービスのロック解除、またはさらなる信頼ネゴシエーションに必要な対向サイト証明書の開示のロック解除のいずれかとすることができる。さらにネゴシエーションを行うことの直接の問題は、ローカル・サイト１０が、要求された証明書を開示するのに十分な、対向サイト１１への信頼を有するかどうかを判定し、そうでない場合に、その信頼を確立することができる対向サイト証明書の要求（発信証明書要求２２）を構成することである。
【００２５】
図１に示されているように、各サイトで、証明書アクセス・ポリシ１０２が、それ自体の証明書１０３のそれぞれと関連付けられる。そのアクセス・ポリシによって、ローカル・サイト証明書の開示のロックを解除する対向サイト証明書が識別される。証明書要求２１を受信する時に、セキュリティ・エージェント１０１が、どのアクションが適当であるかを判定する。その判定を、図１のアーキテクチャ図および図２に示された流れ図のステップ（３１ないし３７）に関して以下の段落で説明する。
【００２６】
セキュリティ・エージェントのアクションは、セキュリティ・エージェントが対向サイトから論理式の形の証明書要求２１を受信する時に、ステップ３１で開始される。ローカル・サイトが、ステップ３２で、要求を満足する証明書を所有しないことを発見する場合（かつ、セキュリティ・エージェントがサーバに属する時など、ある種の応答が要求される場合）に、ステップ３３で拒否を送信することができる。そうでない場合には、セキュリティ・エージェントは、ステップ３４で、要求を満足する証明書の組合せの提供を正当化するのに十分な信頼が、既に対向サイトで確立されているかどうかを判定しなければならない。具体的に言うと、要求２１を伴う対向サイト証明書２３または既にローカルにキャッシングされた対向サイト証明書１０４が、ローカル証明書１０３を管理するアクセス・ポリシ１０２を満足する可能性があり、これによって、着信要求２１が満足される。その場合には、ステップ３５に示されているように、この形でロックを解除され、着信要求２１を満足するローカル証明書の組合せを、対向サイト１１に即座に送信２６することができる。現在の着信要求が、ローカル・サイトによる前の要求に対する応答として受信された時には、送信される証明書と共に、これらの証明書が前の要求の実現のロックを解除するための信頼を生むという前提の下で、前の要求をステップ３５で繰り返すことができる。
【００２７】
その一方で、ステップ３４で、ローカルに使用可能な対向サイト証明書（２３または１０４もしくはその両方）が、着信要求２１を満足するローカルに所有される証明書１０３の組合せのロックを解除するのに十分でないと判定される場合がある。その場合には、ステップ３６で、セキュリティ・エージェント１０１が、着信証明書要求２１をローカル・サイト証明書アクセス・ポリシ１０２と論理的に組み合わせることによって、対向サイト１１へのさらなる発信証明書要求２２を導出する。これらの対向サイト証明書は、対向サイトによって要求されたローカル・サイト証明書のロックを解除する目的のために要求される。したがって、不必要に証明書を要求しないようにするために、導出処理で、ローカル・サイトが要求された証明書１０３のどれを実際に所有するかを考慮し、さらに、蓄積された１０４または着信２３対向サイト証明書によって既にロックを解除されているローカル・サイト証明書のロックを解除するために追加の対向サイト証明書を要求しないことによって、要求を単純化する。
【００２８】
ステップ３７で、セキュリティ・エージェント１０１が、ローカル・サイト証明書のロックを解除するためにさらなる対向サイト証明書要求を送信する時に、セキュリティ・エージェント１０１が、同時に、既にロックを解除されたいくつかのローカル・サイト証明書を提供することを選択することができる。たとえば、着信証明書要求２１で言及されたローカル・サイト証明書をいくつか提供することができる。不要な証明書開示の危険を冒すことにはなるが、このネゴシエーション戦略決定によって、ネゴシエーションが成功する可能性およびその速度を高めることができる。これは、対向サイトが要求された証明書を即座に提供する機会を増やすことと、対向サイトが、２つのサイトの組み合わされた証明書アクセス・ポリシ内に循環依存性があり、したがってネゴシエーションを打ち切ると結論する可能性を減らすことによって行われる。
【００２９】
図１に示されているように、ローカル・サイトがサーバであり、対向サイトがクライアントである時に、クライアントからサーバに着信するメッセージの内容に、サービス要求２４を含めることができる。そのようなサービス要求が、クライアントとサーバの間の証明書開示のネゴシエーションの通常の最初のメッセージである。サービス要求２４の受信時に、サーバのセキュリティ・エージェント１０１が、サービス管理ポリシ（図１には図示せず）を適用して、要求に付随する対向サイト証明書２３が、サービス管理ポリシを満足するのに十分であるかどうかを判定する（これは、上で述べた第２の従来技術のアプローチについても真である）。一部のサーバは、ステートレスであり、したがって、各クライアント要求の後にクライアント証明書を保存しないが、その他のサーバは、クライアントのように、対向サイト証明書１０４をキャッシングすることができる。そのようなサーバは、キャッシングされた対向サイト証明書１０４ならびに要求に付随する対向サイト証明書２３を利用して、そのサービス管理ポリシの満足を試みる。キャッシングされた対向サイト証明書１０４が使用されるか否かにかかわらず、サービス管理ポリシが満足される時には、サービスが許可される２５。そうでない場合には、セキュリティ・エージェント１０１が、発信証明書要求２２の形でサービス管理ポリシを返す。その後、証明書開示が、クライアントとサーバの間でネゴシエートされ、成功の場合には、クライアントが、サービスを許可するのに十分な証明書を付加されたサービス要求を繰り返すことができる。そのような交換の例を、図３に示す。
【００３０】
図３では、ステージ１で、クライアントが、特定のサービスの要求をサーバ・サイトに送信し、サーバがクライアントの代わりに特定の処理タスク（たとえばデータベースに対する読取アクセス）を実行するよう要求する。おそらくはクライアントがそのサービスを管理する証明書ポリシを知らないので、証明書は要求に付加されない。ステージ２で、サーバ・セキュリティ・エージェントが、クライアント・セキュリティ・エージェントにサービス管理ポリシを送信し、これによって、クライアント・セキュリティ・エージェントが、要求されたサービスを実行させるためにサーバ・セキュリティ・エージェントの側の十分な信頼を生むためにサブミットされる証明書に関するオプションについて知らされる。このポリシは、証明書要求を構成し、ステージ３でクライアント・セキュリティ・エージェントによって受信される時に、証明書要求として扱われる。クライアント・セキュリティ・エージェントは、図２の流れ図に関して上で述べたステップに従って応答する。
【００３１】
すなわち、クライアント・セキュリティ・エージェントは、証明書要求を受信する（ステップ３１）（ステージ１で要求されたサービスを許可するために）。クライアント・セキュリティ・エージェントは、クライアントが、要求を満足する証明書の少なくとも１つの組合せを所有すると判定する（ステップ３２）。クライアント・セキュリティ・エージェントは、これらの満足な組合せのいずれかの構成証明書のアクセス制御ポリシを満足するのに十分な、ローカルに使用可能なサーバ証明書がないと判定する（ステップ３４）。したがって、クライアント・セキュリティ・エージェントは、それ自体の証明書のそのような満足な組合せのロックを解除するように設計された新しい要求を導出する（ステップ３６）。最後に、クライアント・セキュリティ・エージェントは、証明書を付加せずにその要求をサーバに送信する（この例の変形では、クライアントが、たとえばアクセス制御ポリシによってサーバの前の知識なしにそれらを開示することが許可される場合に、この時点でステージ２でサーバによって要求された証明書の一部を発信要求に付加することができる）。
【００３２】
ステージ４は、サーバのセキュリティ・エージェントが、ステージ３の終りにクライアントによって送信された証明書要求を受信する時に開始される。この要求は、やはり図２の流れ図に関して上で述べたように処理される。サーバのセキュリティ・エージェントが、クライアント・セキュリティ・エージェントの要求を満足する証明書を有すると判定し（ステップ３２）、それらのすべてがクライアント・セキュリティ・エージェントへの開示に関してロックを解除されていないと判定する（ステップ３４）（サーバ・セキュリティ・エージェントは、まだクライアント・セキュリティ・エージェントから証明書を受信していない）。サーバのセキュリティ・エージェントは、クライアント・セキュリティ・エージェントによって要求された証明書のロックを解除することを意図されたクライアント証明書要求を導出し（ステップ３６）、それを、クライアント・セキュリティ・エージェントが要求した、そのアクセス制御ポリシによってクライアント証明書をまず見ることなしに開示することが許可されるいくつかの証明書と共に、クライアント・セキュリティ・エージェントに送信する（ステップ３７）。
【００３３】
ステージ５は、ステージ４の終りにサーバ・セキュリティ・エージェントによって送信された要求および証明書をクライアントのセキュリティ・エージェントが受信する時に開始される。クライアント・セキュリティ・エージェントは、要求を満足する証明書を有すると判定する（ステップ３２）が、これまでに受信したサーバ証明書によってアクセス制御ポリシがロックを解除された証明書から満足な組合せが構成されないと判定する（ステップ３４）。より多くのそれ自体の証明書のロックを解除するために、クライアント・セキュリティ・エージェントは、下記のようにサーバ証明書に関する新しい要求を導出する（ステップ３６）。クライアント・セキュリティ・エージェントは、それが所有しない証明書への参照を定数偽に置換することによって、着信証明書要求を変更する。その後、それが所有する、証明書の残りの出現のそれぞれを、その証明書のアクセス・ポリシに置換する。これらのアクセス・ポリシなどの結果の式を、対向サイト証明書に関して表す。次に、これを、前にステージ３の終りにクライアントによってサーバに送信された証明書要求（まだサーバから受信した証明書によって完全に満足されてはいない可能性がある）と結合する。セキュリティ・エージェントは、不要な証明書を要求しないようにするために、結果の結合を単純化する。単純化は、クライアント・セキュリティ・エージェントが既に受信している証明書および式で表される属性制約を満足する証明書の出現のそれぞれを式から除去することによって行われる。結果の式を、除去された証明書を定数真（constant true）として扱い、それ相応に論理接続を単純化することによって単純化する（結合での真の出現は、単純に除去される。空の結合は、真に置換される。真を含む離接は、真に置換される）。最後に、クライアント・セキュリティ・エージェントが、この形で導出し、単純化した式を送信し、このステージの始めに受信したサーバ証明書によってアクセス制御ポリシのロックが解除された、着信要求で要求された証明書も送信する。
【００３４】
ステージ６は、ステージ５の終りにクライアント・セキュリティ・エージェントによって送信された要求および証明書をサーバのセキュリティ・エージェントが受信する時に開始される。サーバ・セキュリティ・エージェントは、要求を満足する証明書を有すると判定する（ステップ３２）が、それらのすべてがロックを解除されてはいないと判定する（ステップ３４）。サーバ・セキュリティ・エージェントは、クライアント側のステージ５で示したものとほとんど同一の手順によって、クライアント証明書に関する新しい要求を導出する（ステップ３６）。サーバ側での導出の、クライアント側での導出からの主な相違は、この例で示されるネゴシエーション戦略で、サーバが、前のクライアント証明書要求を再利用しないことである。
【００３５】
ステージ７は、ステージ６の終りにサーバ・セキュリティ・エージェントによって送信された要求および証明書をクライアントのセキュリティ・エージェントが受信する時に開始される。クライアント・セキュリティ・エージェントは、要求を満足する証明書の少なくとも１つの組合せを有すると判定する（ステップ３２）。クライアントは、そのような証明書の組合せのロックを解除するのに十分なサーバ証明書を受信している（ステップ３４）。したがって、クライアントは、ステージ７の終りに、ステージ５の終りにサーバに送信したものと同一の証明書要求と共に、サーバにそのような組合せを送信する。
【００３６】
ステージ８は、ステージ７の終りにクライアントによって送信された繰り返される要求および証明書をサーバのセキュリティ・エージェントが受信する時に開始される。サーバ・セキュリティ・エージェントは、要求を満足する証明書を有すると判定し（ステップ３２）、それらのアクセス制御ポリシが、ステージ７の終りにクライアントによって送信されたクライアント証明書によって満足されるので、それらの証明書がロックを解除されると判定する（ステップ３４）。サーバ・セキュリティ・エージェントは、これらの証明書をクライアントに送信する。
【００３７】
ステージ９は、ステージ８の終りにサーバによって送信された証明書をクライアントのセキュリティ・エージェントが受信する時に開始される。これらの証明書は、ステージ５および７の始めにクライアント・セキュリティ・エージェントによって受信された証明書およびその時以降にクライアント・セキュリティ・エージェントによってキャッシングされた証明書と一緒に、ステージ３にクライアント・セキュリティ・エージェントによって受信されたサービス管理ポリシを満足するクライアント証明書のアクセス制御ポリシを満足する。クライアント・セキュリティ・エージェントは、一緒にサービス管理ポリシを満足するロックを解除された証明書の組合せを送信する。クライアント・セキュリティ・エージェントは、元のサービス要求も繰り返す。
【００３８】
ステージ１０は、ステージ９の終りにクライアントによって送信されたサービス要求および証明書をサーバのセキュリティ・エージェントが受信する時に開始される。これらの証明書は、サービス管理ポリシを満足し、したがって、サービスが許可され、実行され、その結果が返される。結果は、ステージ１１でクライアントによって受信され、ステージ１１でこの例が終了する。
【００３９】
ネゴシエーションの例
ここで提示する例は、図３に概略的に示された仮定のネゴシエーションの１１個のステップを示すものである。本発明の好ましい実施形態によって規定される、式の操作を示すことが意図されている。式は、正式でない形で表される。この例は、例示のみを目的とし、実際のネゴシエーション、証明書、またはポリシの特徴を正確に表すことを意図されたものではない。
【００４０】
仮定の証明書
各証明書の項目は、この例の残りでその証明書に使用される省略語から始まる。
【００４１】
セキュリティ実施証明書−−クライアントとサーバの両方によって保持される
セキュリティ実施標準規格コンサルタントが、それがセキュリティ・インフラストラクチャを評価する実体にセキュリティ実施証明書を発行すると仮定する。この評価は、第三者が、その実体に提供される情報がその実体によって不適切に開示される可能性を推定するのに使用することができる。評価された実体が、満たすことができなかった等級をプライベートに保ちながらある等級の要件を満たすことを実証できるようにするために、等級ごとに別々の証明書が発行され、この証明書は、等級の要件が満たされた時に値真、そうでない場合に値偽を有する、「passed」と称する属性を有する。
【００４２】
この例では、４つのセキュリティ実施等級すなわち、低（low）、中（medium）、高（high）、超高（very high）がある。サーバによって満たされる最大等級が、「高」であり、クライアントによって満たされる最大等級が、「中」である。各実体は、それが失敗した等級に関するそれが有する証明書を保護する。合格した等級に関する証明書も保護されるのでない場合には、保護の差によって、失敗した等級が明瞭になるはずである。したがって、すべての等級（最低を除く）に関する証明書が、所有者が合格したか失敗したかにかかわらずに、保護される。
Very High（超高）  セキュリティ実施等級。高重要度。
High（高）  セキュリティ実施等級。中重要度。
Med（中）  セキュリティ実施等級。低重要度。
Low（低）  セキュリティ実施等級。重要でない。
【００４３】
クライアント証明書
Contract  宛先契約。物品の送達を期待する当事者によって発行される。極めて重要。情報が競合者に漏洩されないことを保証する必要がある。
Credit  信用状。債権者によって所有者に発行される。中−高重要度。
Dock  起点ドックでのウェアハウス契約。ドック管理者によって発行される。中重要度。競合者への散布を防ぐ必要がある。
S-Receipt  前の出荷受領証。過去に物品を搬送する出荷者によって発行される。この例のクライアントは、前の出荷受領証を有しない。
Account  サーバ／出荷者との確立された口座。出荷者によって発行される。この例では、クライアントは、サーバ／出荷者との確立された口座を有しない。
B-Org  商業組織メンバシップ証明書。国際商業会議所などの商業組織によって発行される。重要でない。
【００４４】
サーバ証明書。
Receipt  前の引渡受領証。過去に搬送された物品の所有者によって発行される。重要でない。
Bond  抵当証明書。抵当代理人によって発行される。重要でない。
Ref  製造業者からの参照。前の業務経験に基づいて出荷者を推薦することを望む製造業者によって発行される。低重要性。この例のサーバは、異なる製造業者からの少なくとも２つのこれらの証明書を有する。
B-Org  商業組織メンバシップ証明書。国際商業会議所などの商業組織によって発行される。重要でない。
【００４５】
仮定のポリシ
クライアントまたはサーバの証明書Ｘを管理するポリシを、それぞれXclientまたはXserverによって示す。ここで示すポリシは、完全ではない。具体的に言うと、これらは、必須であるサポートする証明書の要件を表していない。全く完全でも現実的でもないが、「where」によって導入される文節に、証明書属性に対する制約の使用を示す。たとえば、クライアントの宛先契約証明書に関するクライアントのアクセス制御ポリシでは、２つの異なる証明書発行者からの参照が必要である。
【００４６】
クライアントの証明書管理ポリシ
Contractclient = High AND Ref1 AND Ref2 AND (Bond OR (Receipt1 AND
Receipt2)) where High.passed = true AND Ref1.issuer ≠ Ref2.issuer
AND Receipt1.issuer ≠ Receipt2.issuer
Creditclient = Med AND Ref1 AND Ref2 where Med.passed = true AND
Ref1.issuer ≠ Ref2.issuer
Dockclient = Med AND (Bond OR (Receipt1 AND Receipt2)) where Med.passed =
true AND Receipt1.issuer ≠ Receipt2.issuer
Very Highclient = High AND B-Org where High.passed = true
Highclient = Med AND B-Org where Med.passed = true
Medclient = Low AND B-Org where Low.passed = true
Lowclient = 証明書不要
【００４７】
サーバの証明書管理ポリシ
Receiptserver = 証明書不要
Bondserver = 証明書不要
Refserver = Low where Low.passed = true
Very Highserver = High AND B-Org where High.passed = true
Highserver = Med AND B-Org where Med.passed = true
Medserver = Low AND B-Org where Low.passed = true
Lowserver = 証明書不要
【００４８】
サーバの、出荷スケジューリング用のサービス管理ポリシ
Account OR (Dock AND ((S-Receipt1 AND S-Receipt2) OR Contract) AND
Credit) where S-Receipt1.issuer ≠ S-Receipt2.issuer
【００４９】
ネゴシエーション・ステップ
この例は、成功裡のネゴシエーションである。証明書の要求が、ステージ２ないし７の終りに送信される。ステージ２の終りにサーバによって要求されたクライアント証明書は、サービスを許可するために必要である。ネゴシエーションの残りは、クライアントがこれらの証明書をサーバに開示するのに十分な信頼を確立するために働く。ステージ３ないし７で要求される証明書は、成功裡のネゴシエーションに必要な証明書へのアクセスのロックを解除するのに必要である。
【００５０】
サイトが証明書の要求を受信する各ステージで、サイトが、要求を満足する証明書を所有し、図２のステップ３２が成功する。そのようなステージのそれぞれの終りに、動作するセキュリティ・エージェントが、着信要求で要求された、ローカルに使用可能な対向サイト証明書によってアクセス・ポリシのロックを解除された証明書のすべてを対向サイトに送信する。これらに、下では、「ロック解除された要求された証明書」というラベルを付す。この例によって例示されるネゴシエーション戦略では、クライアントのセキュリティ・エージェントが、前の要求をキャッシングし、繰り返すが、サーバはそれを行わない。
【００５１】
ステージ１−−クライアントがサービス要求：出荷日付のスケジュールを送信する。
【００５２】
ステージ２−−サーバが要求を受信し、サービス管理ポリシを返す
サーバは、クライアントが実際に出荷サービスの市場におり、それに対して支払えることの信頼を確立する必要がある。上で示した出荷スケジューリングのサービス管理ポリシを送信する。
【００５３】
ステージ３−−クライアントが、サービスを許可するための証明書の要求を受信する
ローカルに使用可能なサーバ証明書：なし
ロック解除された要求された証明書：なし（ステップ３４が失敗する）
クライアントが所有しない証明書を除去することによって単純化された着信要求：
Dock AND Contract AND Credit
各証明書をその（大括弧で囲まれた）アクセス・ポリシに置換されたこの式：
[Med AND (Bond OR (Receipt1 AND Receipt2)) where Med.passed = true AND
Receipt1.issuer ≠ Receipt2.issuer] AND
[High AND Ref1 AND Ref2 AND (Bond OR (Receipt1 AND Receipt2)) where
High.passed = true AND Ref1.issuer ≠ Ref2.issuer AND Receipt1.issuer
≠ Receipt2.issuer] AND
[Med AND Ref1 AND Ref2 where Med.passed = true AND Ref1.issuer ≠
Ref2.issuer]
ステージ３の終りに証明書要求としてサーバに送信される、単純化された式：
High AND Ref1 AND Ref2 AND (Bond OR (Receipt1 AND Receipt2)) AND Med
where High.passed = true AND Ref1.issuer ≠ Ref2.issuer AND
Receipt1.issuer ≠ Receipt2.issuer AND Med.passed = true
【００５４】
ステージ４−−サーバが証明書の要求を受信する
ローカルに使用可能なクライアント証明書：なし
ロック解除された要求された証明書：Bond（ステップ３４が失敗する）
各証明書をその（大括弧に囲まれた）アクセス・ポリシに置換された着信要求：
[Med AND B-Org where Med.passed = true] AND
[Low where Low.passed = true] AND
[Low where Low.passed = true] AND
([証明書不要] OR ([証明書不要] AND [証明書不要])) AND
[Low AND B-Org where Low.passed = true]
ステージ４の終りにクライアントに送信される、簡略化されたこの式：
Med AND Low AND B-Org where Med.passed = true AND Low.passed = true
【００５５】
ステージ５−−クライアントが、証明書の要求と１つのサーバ証明書を受信する  ローカルに使用可能なサーバ証明書：Bond
ロック解除された要求された証明書：Low、B-Org （ステップ３４が失敗する）
各証明書をその（大括弧で囲まれた）アクセス・ポリシに置換された着信要求：
[Low AND B-Org where Low.passed = true] AND
[証明書不要] AND [証明書不要]
ステージ３の終りにサーバに送信された要求と結合されたこの式：
[[Low AND B-Org where Low.passed = true] AND [証明書不要]
AND [証明書不要]] AND
[High AND Ref1 AND Ref2 AND (Bond OR (Receipt1 AND Receipt2)) AND Med
where High.passed = true AND Ref1.issuer ≠ Ref2.issuer AND
Receipt1.issuer ≠ Receipt2.issuer AND Med.passed = true]
ステージ５の終りにサーバに送信される、ローカルに使用可能なサーバ証明書を除去することによって単純化された要求：
Low AND B-Org AND High AND Ref1 AND Ref2 AND Med where Low.passed =
true AND High.passed = true AND Ref1.issuer ≠ Ref2.issuer AND
Med.passed = true
【００５６】
ステージ６−−サーバが、証明書の要求と２つのクライアント証明書を受信する
ローカルに使用可能なクライアント証明書：Low、B-Org
ロック解除された要求された証明書：Low、B-Org、Med（ステップ３４が失敗する）
各証明書をその（大括弧で囲まれた）アクセス・ポリシに置換された着信要求：
[証明書不要] AND
[証明書不要] AND
[Med AND B-Org where Med.passed = true] AND
[Low where Low.passed = true] AND
[Low where Low.passed = true] AND
[Low AND B-Org where Low.passed = true]
ステージ６の終りにクライアントに送信される、ローカルに使用可能なクライアント証明書を除去することによって単純化された要求：
Med where Med.passed = true
【００５７】
ステージ７−−クライアントが、証明書の要求と３つのサーバ証明書を受信する  ローカルに使用可能なサーバ証明書：Bond（ステージ５以降キャッシングされている）、Low、B-Org、Med
ロック解除された要求された証明書：Med（ステップ３４が成功する）
ステージ５の終りにサーバに送信された要求（ステップ３５を参照されたい）：
Low AND B-Org AND High AND Ref1 AND Ref2 AND Med where Low.passed =
true AND High.passed = true AND Ref1.issuer ≠ Ref2.issuer AND
Med.passed = true
ステージ７の終りにサーバに送信される、ローカルに使用可能なサーバ証明書を除去することによって単純化された要求：
High AND Ref1 AND Ref2 where High.passed = true AND Ref1.issuer ≠
Ref2.issuer
【００５８】
ステージ８−−サーバが、証明書の要求と１つのクライアント証明書を受信する
ローカルに使用可能なクライアント証明書：Low、B-Org（両方がステージ６以降キャッシングされる）、Med
ロック解除された要求された証明書：High, Ref1, Ref2（ステップ３４が成功し、ステップ３５で証明書が送信される）
【００５９】
ステージ９−−クライアントが、サービスを許可するクライアント証明書のロック解除を終了する３つのサーバ証明書を受信する
証明書に関するこれ以上の要求が受信されないので、関連する要求（ステップ３１）が、もう一度、ステージ３の始めに受信したサービス管理ポリシになる。
ローカルに使用可能なサーバ証明書：Bond（ステージ５で受信）、Low、B-Org、Med（ステージ７で受信）、High、Ref1、Ref2（ステージ９で受信）
ロック解除された要求された証明書：Dock、Contract、Credit（ステップ３４が成功する）
最初にステージ１で送信された、サービスすなわち出荷日付のスケジュールの要求が、要求された証明書を付加されて繰り返される。
【００６０】
ステージ１０−−サーバが、サービス要求と３つの付加された証明書を受信し、サービスを許可する
サーバは、付加された証明書がサービス管理ポリシを満足することを確認し、要求されたサービスを許可する。そのサービスの結果が、ステージ１０の終わりに返される。
【００６１】
ステージ１１−−クライアントが、要求したサービスを受信する
【図面の簡単な説明】
【図１】  本発明の好ましい実施形態によるソフトウェア・コンポーネントを示すブロック図である。
【図２】  本発明の好ましい実施形態による、ローカル・サイトによって実行される処理ステップを示す流れ図である。
【図３】  本発明の好ましい実施形態による、要求と応答のシーケンスを示す例示的タイミング図である。
【図１】
0003701871.tif 000002
【図２】
0003701871.tif 000003
【図３】
0003701871.tif 000004