パブリックキーインフラストラクチャー
本発明は、パブリックキーインフラストラクチャー（ＰＫＩ）システムにおける相互証明のための方法、装置、システム及びソフトウェアを提供する。証明当局の階層を有するパブリックキーインフラストラクチャーが設けられる。第１のＣＡは、相互証明書を発行するように構成される。第１の当局より階層的に上位の第２の証明当局は、相互証明書を正常に確認するように使用できる信頼性アンカーを発行しないように構成される。証明組織内の信頼性は、全証明組織へと拡張されず、その所定の部分のみに制限される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パブリックキーインフラストラクチャー（ＰＫＩ）に係る。より詳細には、本発明は、デジタルサイン入り証明書の発行及び検証と、このような証明を容易にするシステム及び関連する態様とに係る。特に、ＰＫＩシステム間の相互証明(cross-certification)に係る。
【背景技術】
【０００２】
パブリックキーインフラストラクチャー（ＰＫＩ）とは、依存当事者間での電子的信頼性の確立をサポートする技術のシステムである。パブリックキー暗号化（ＰＫＣ）の概念に基づいて、この技術は、バンキングネットワークを含むインターネット及び他のネットワーク上での安全な電子商取引を含む安全な通信のための健全なプラットホームであることがこれまでに分っている。
【０００３】
パブリックキー暗号化（ＰＫＣ）は、当事者が、パブリック及びプライベートキー対を使用することにより安全に通信するのを許す技術である。ＰＫＣベースの通信は、たとえパブリックキーが広く知られ利用できるものであっても、確実性及び機密性の両方を備えることができる。この技術は、最初１９７０年代に、通信を希望する当事者間で共有キーを機密保持することが必要な対称キー暗号化（ＳＫＣ）に代わるものとして発明された。
【０００４】
ＰＫＣが大規模に正常に動作するには、通常、パブリックキーインフラストラクチャー（ＰＫＩ）の確立を必要とする。ＰＫＩのコアには、加入者のパブリックキーの有効性を証明する証明当局（ＣＡ）と一般に称される信頼性のあるエージェントがある。これは、これらのキーにサインして、（パブリックキー）証明書として知られているデータ構造体を形成することにより行なわれる。次いで、パブリックキーを電子的に交換し、そして信頼し得る方法で最初に得なければならない証明ＣＡのパブリックキーを使用して完全性についてチェックすることができる。
【０００５】
所与の証明当局は、企業があまり大きくなければ、１つの完全な企業について単一のアプリケーション又は多数のアプリケーションをサポートすることができる。このような企業ＣＡにより発行される証明書は、通常、組織ディレクトリのようなデータ貯蔵所に記憶され、そこで、アプリケーションによりアクセスされる。自動車産業、金融、及び銀行セクター、石油及び防衛の部門を含む多くの企業は、現在、組織的ＣＡを確立しつつある。１つの著名な大きな例は、約１千万の証明書の組織的ＰＫＩを披露した米国国防総省である。
【０００６】
公式に表現すれば、ＰＫＩのユーザの２つのグループを次のように定義することができる。
− 加入者とは、ＣＡにより発行されたプライベートキー及びそれに対応するデジタル証明書を所有し、これを使用して、認証（サイン）されたメッセージを送信するユーザ、サーバー又は暗号化装置である。メッセージは、デジタルサイン入りｅメール、或いはチャレンジ応答認証プロトコルに使用されるメッセージ交換を含むことができる。
− 依存当事者（ＲＰ）とは、ＣＡにより発行された証明書を使用して、加入者がサインしたメッセージの真正性を検証するエージェントである。依存当事者と表現されるのは、ＣＡに依存し、それに代わって、デジタルサイン入りｅメールを送信したり又はチャレンジ応答認証プロトコルに使用されるメッセージ交換を通して対話したりする加入者のアイデンティティを検証するためである。信頼性のある経路の構築をスタートするのに使用されるＣＡ証明書は、信頼性アンカー(Trust Anchor)と称される。信頼性アンカーは、常時ではないが、しばしば、階層のルート（根）となる。
【０００７】
単一のＣＡが企業内の全てのアプリケーションに対して全てのユーザにサービスするのではなく、ルート及び多数の従属体を伴うＣＡの階層を確立することができる。階層は、ユーザにより近い組織にわたって証明書管理機能を分布させるのを許す。これは、弾力性及び機密性に関して利益をもたらす。弾力性が高められるのは、ＣＡが、証明書及び取り消しリストの発行についてサービスするユーザに接近して動作できるからである。機密性が高められるのは、接近性によりＰＫＩ要素とユーザコミュニティとの間の帯域外通信を容易にするからである。
【０００８】
図１を参照すれば、信頼性は、常に、ＣＡの厳格な階層におけるルートから出発する。これは、自己サイン入り（又は自己発行）証明書を表わす階層のルート（ルートＡ）におけるループ矢印によりグラフ的に表わされている。
【０００９】
注目すべき重要なポイントは、階層のルートが、組織Ａ内の全ての依存当事者（ＲＰ）に対する共有信頼性アンカーであるという点である。これは、ＣＡの厳格な階層を定義付ける特性である。その結果、全てのＲＰが全く同じやり方で信頼性を決定する。これは、最初、反直観的であると思われる。というのは、初めに（間違ったことであるが）、最もローカルなＣＡが、安全な通信を送信及び受信するためのスタートポイントであると仮定するからである。しかしながら、厳格な階層における信頼性のある管理は、非対称的である。
− サイン入り通信を送信するために、信頼性チェーンがルートからローカルＣＡを通して加入者の証明書へと延びる。
− サイン入り通信を受信するために、信頼性は、ここでも、ルートで始まり、必要に応じて従属ＣＡ（又は他のどこか）の各々まで延びる。ローカルＣＡは、このプロセスには何の関係もない。
【００１０】
しかしながら、厳格な階層は、幾つかの欠点で悩まされている。
− ルートＣＡは、企業にとって重大な１つの欠陥ポイントである。何らかの理由で、企業のルートＣＡがある時間周期中サービスを停止した場合には、証明書取り消し情報を発行できなくなり、企業（ローカル領域を含む）にわたるサービス権利の潜在的な拒否を招く。更に重大なことに、ルートが永久的なダメージを受けるか、又は妥協された場合には、企業全体を施錠し直さねばならず、これは、潜在的に、非常に時間浪費であり且つコストのかかるプロセスとなる。
− 厳格な階層は、しばしば、実際のビジネス要件を反映しない。例えば、共同事業体や、多数の小さな部署を所有する大きな会社では、より連合した解決策が、より適切となる。
− 証明書及びキーの更改は、非常に複雑である。というのは、従属ＣＡにより発行される証明書の寿命が、一般的に、上位証明書の寿命を越えないからである。
− 従属体が外部のパートナーとの相互証明を試みる場合には、予期せぬ信頼性の問題が生じ得る。これは、以下で更に述べる。
【００１１】
セキュリティ管理境界（ＰＫＩ境界を含む）を横断することも通常含む組織的境界を横切って安全に通信することがしばしば要求される。パブリックキーの信頼性を拡張する多数の技術が存在するが、今日使用される最も一般的なものは、相互証明である。
【００１２】
ピア対ピア相互証明（以下、単に相互証明と称する）は、ＰＫＩ技術の多数の売主によりサポートされるプロセスである。相互証明は、２つの別々のＰＫＩシステムが互いに信頼性のある関係を確立するのを許す。この信頼関係は、ある制約又は条件が課せられた状態で確立することができ、各ＰＫＩは、パートナーのＰＫＩシステムを無条件で信頼する必要がなく、制御された条件のもとで信頼することができる。
【００１３】
２つの組織は、ルートレベルにおいてそれらの個々のＰＫＩを相互証明することができる。この解決策は、各組織が他の組織の全ＰＫＩを信頼しようとする場合には理想的である。しかしながら、ある組織が、従属レベルにおいてのみ別の組織へ信頼性を拡張することを好み、例えば、選択された部門間のみで信頼できることを好むこともある。このように信頼性を局所化する必要性は、種々の理由で生じ得る。例えば、ある部門は、商業的に敏感なエリアで機能し、外部当事者への信頼性を排除することを希望するが、調達部門は、よりオープンなポリシーを有し、多数の外部供給者との信頼関係を確立する必要がある。
【００１４】
“Planning and Implementing Cross-certification and Qualified Subordination Using WindowsTM Server 2003”と題するＭｉｃｒｏｓｏｆｔTMドキュメントから、既知の相互証明方法を使用して、信頼性の範囲を外部（相互証明された）パートナー組織に制限することが知られている。しかしながら、外部（相互証明された）組織への相互証明書の発行により確立された信頼関係は、相互証明組織内の全ての依存当事者により均一に引き継がれる。
【００１５】
従属ＣＡが相互証明するのを許す状況にこの解決策を適用したときの問題は、それにより得られる信頼関係が非対称的であり、即ち外部エンティティは、それら自体を組織規模で認証できるが、相互証明ＣＡにおける又はその下にある相互証明組織内のエンティティでなければ、それら自体を外部組織に対して認証することができない。この非対称性により、ある通信プロトコルは正しく動作しないことがある。従って、従属ＣＡ間で信頼関係を作り出すことは一般的に推奨されず、このようなプロトコルが正しく動作するよう保証するには常にそれをルートレベルで行うのが好ましい。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
それ故、既知のシステムに関連した１つ以上の問題を軽減する改良されたＰＫＩシステム、装置、方法等を提供することが要望される。
【課題を解決するための手段】
【００１７】
本発明は、ＩＴＵ推奨勧告Ｘ．５０９及びその関連規格に基づくものを含むＰＫＩ又は同様のシステムにより証明書の発行及び／又は使用に制約を課する方法、装置、システム及びコンピュータ用のプログラム（任意であるが、マシン読み取り可能な媒体上にある）を提供する。
【００１８】
特に、本発明の第１の態様によれば、証明当局の階層を含むパブリックキーインフラストラクチャーであって、第１証明当局が相互証明書を発行するように構成され、そして第１当局より階層的に上位の第２証明当局が、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成されたパブリックキーインフラストラクチャーが提供される。
【００１９】
第２証明当局は、実際に、信頼性アンカー及び他の証明書を発行できるが、それらは、単独にせよ、組み合せにせよ、第１当局により発行された相互証明書の正常な確認を許さないことを保証しなければならない。
【００２０】
ある実施形態では、証明書は、信頼性アンカーを含む。
【００２１】
ある実施形態では、第１当局より階層的に上位の各証明当局は、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成される。
【００２２】
ある実施形態では、第２証明当局は、その従属証明当局に、相互証明書の正常な確認に使用するのを除外する制約を含む証明書を発行する。
【００２３】
ある実施形態では、前記制約は、経路長さ制約、ネームスペース制約、ポリシーマッピング制約、及びアプリケーション制約の１つを含む。
【００２４】
ある実施形態では、前記制約は、ポリシーマッピング制約を含む。
【００２５】
ある実施形態では、前記制約は、ポリシーマッピングを禁止する。
【００２６】
ある実施形態では、前記信頼性アンカーは、「inhibitPolicyMapping」フィールドを備え、そして前記制約は、この「inhibitPolicyMapping」フィールドを所定値にセットすることを含む。
【００２７】
ある好ましい実施形態では、前記「inhibitPolicyMapping」フィールドの所定値はゼロである。
【００２８】
前記パブリックキーインフラストラクチャーは、実質的にＩＴＵ推奨勧告Ｘ．５０９に基づいて動作される。
【００２９】
この点に関して、基本的Ｘ．５０９推奨勧告の派生物が既に多数あり、これらは、時間と共に必然的に進化する。それ故、当業者であれば、本発明は、Ｘ．５０９自体の文字通りの表現に関してこれら派生物を等しく適用し、ここでは、文字通りというよりは実質的にＸ．５０９に従ってアプリケーションインフラストラクチャーを適用することが容易に理解されよう。
【００３０】
本発明の更に別の態様によれば、第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーのための証明当局であって、この証明当局は、前記第１証明当局より階層的に上位であるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成された証明当局が提供される。
【００３１】
又、本発明は、インフラストラクチャーを動作する方法であって、装置の各関連要素断片に対応する方法ステップを備えた方法にも向けられる。
【００３２】
特に、本発明の更に別の態様によれば、パブリックキーインフラストラクチャーを動作する方法において、証明当局の階層を含むパブリックキーインフラストラクチャーを用意するステップであって、その階層は、第１証明当局と、それより階層的に上位の第２証明当局とを含むものであるステップと、相互証明書を発行するように第１証明当局を構成するステップと、第１証明当局により発行された相互証明書の正常な確認を単独でも組み合せでも許さないような証明書を発行するように第２証明当局を構成するステップと、を備えた方法が提供される。
【００３３】
又、本発明は、本発明の方法を実行するためのコンピュータ用のプログラム（任意にマシン読み取り可能なキャリア又は媒体上のソフトウェアであるか、ファームウェアであるか、チップレイアウトソフトウェアであるか、或いはソースコード又はオブジェクトコードであるかに関わらず）にも向けられ、又、本発明は、このようなプログラムによりプログラムされるコンピュータであって、本発明の他の観点という意味で装置も形成するようなコンピュータにも向けられる。
【００３４】
より詳細には、本発明の更に別の態様によれば、第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーにおいて証明当局として動作するように構成されたコンポーネントコード部分を有するコンピュータ用のプログラムにおいて、前記証明当局は、前記第１証明当局に対して階層的に上位となるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成されたコンピュータ用のプログラムが提供される。
【００３５】
本発明の更に別の態様によれば、従属証明書又は信頼性アンカーを各々通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む従属証明書又は信頼性アンカーを発行するように構成された証明当局を備えたパブリックキーインフラストラクチャーが提供される。
【００３６】
従属証明書又は信頼性アンカーを各々通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む従属証明書又は信頼性アンカーにおける制約に応答して相互証明書を確認するように構成された証明書確認機能を備えたパブリックキーインフラストラクチャーが提供される。
【００３７】
好ましい特徴は、当業者に明らかなように、適宜組み合せることができ、且つ本発明のいずれかの態様と組み合せることができる。上述した例を越えた本発明の他の効果も、当業者に明らかであろう。
【００３８】
本発明をいかに実施するか示すために、添付図面を参照して、本発明の実施形態を一例として以下に詳細に説明する。
【発明を実施するための最良の形態】
【００３９】
図１を参照すれば、相互証明の程度を制御するための１つの考えられる解決策は、従属部門レベルにおいて相互証明を遂行することである。これは、２つの従属レベルＣＡ、即ちファイナンスＡとファイナンスＢとの間の信頼関係を示す。明らかに、ここでは、信頼関係を２つの組織のファイナンス部門に制限することが意図される。この要件を満足させるために、ルートＣＡレベルで相互証明するときに使用された従来知られた解決策は、証明書制約の良く知られた技術を使用することである。不都合なことに、これは、以下に述べるように、従属ＣＡレベルで相互証明するときには不充分である。
【００４０】
Ｘ．５０９規格は、証明書制約の使用を許す（例えば、“RFC 2459-InternetX.509 Public Key Infrastructure Certificate and CRL Profile”(http://www.faqs.org/rfcs/rfc2459.html)に定義されたように）。このような制約は、ネームスペース、ポリシーマッピング、経路長さ、又はアプリケーションポリシー制約を含んでもよい。このような制約は、相互証明書に入れられ、信頼性をパートナー組織へ拡張する程度を制限するように作用する。説明上、図１を再び参照すれば、制約は、ＣＡファイナンスＡにより次のように使用することができる。
【００４１】
− 経路長さ制約は、ファイナンスＢが相互証明するところの他のＣＡまで信頼性が拡張するのを防止するのに使用できる。例えば、ファイナンスＡにより発行される相互証明書において経路長さをゼロにセットすると、信頼性がファイナンスＢを越えて他のＣＡへ拡張しないよう保証する。
【００４２】
− ファイナンスＡからファイナンスＢへ発行される相互証明書におけるネームスペース制約は、許可されたネームスペースの外側の証明書へ信頼性が拡張するのを防止するのに使用でき、この例では、相互証明書は、“xxx.Organisation-B.com”の形式のネームスペースだけを許し、これは、証明書の使用を組織Ｂ内のエンティティ“xxx”内に制限する（この場合、“xxx”は、ファイナンスＢ関連のネームスペースである）。
【００４３】
− ファイナンスＡにより発行される相互証明書におけるポリシーマッピング制約は、許可されたポリシー形式の１つを使用しないＣＡへ信頼性が拡張するのを防止するのに使用できる。
− ファイナンスＡにより発行される相互証明書におけるアプリケーションポリシー制約は、安全通信を、定義された１組のアプリケーションに制約するのに使用できる。
【００４４】
ＲＦＣ２４５９は、種々の形式の証明書制約、それらのシンタックス、及びそれらをいかに使用するか、の詳細な説明を含む。
【００４５】
制約について察知すべき重要なポイントは、それらが相互証明組織（この例では組織Ｂ）内の加入者１０に適用されるが、相互証明組織（組織Ａ）内の依存当事者１１−１３には選択的に適用されないことである。むしろ、証明書に含まれた制約は、特定の信頼性アンカーで信頼性の構築を開始した全ての依存当事者に全体的に適用される。それ故、この例では、組織Ａにおける全ての当事者は、ファイナンス部門の中であろうと外であろうと、相互証明書を同様に処理する。
【００４６】
各加入者又は依存当事者は、１組の証明書２０−２３を保持し、又はそれにアクセスすることができる。各ユーザが証明書をローカルに保持するかのように示されているが、証明書は、各組織内の共通にアクセス可能な貯蔵所に保持されてもよい。
【００４７】
しかしながら、本発明者は、この構成の望ましからぬ結果として、相互証明組織において信頼性経路が予期せずに発生し、これらの予期しない信頼性経路の存在を実験で確認したことを示している。
【００４８】
更に、図１を参照すれば、組織Ｂのファイナンス部門からの加入者１０は、組織Ａのマーケット部門からのユーザ１２へサイン入りｅメールを送信する。２つのファイナンスＣＡ間で相互証明が実施されても、ルートＡから送信ユーザの証明書への信頼性チェーンが存在する。受信ユーザの信頼性アンカー２４がルートＡにより発行され、ファイナンスＣＡにより形成された相互証明書２５は組織Ａのディレクトリ内で自由に配布されるので、受信者のｅメールアプリケーションは、ファイナンスＡにより確立された相互証明により課せられた同じ制約を遵守して、サイン入りｅメールを全く同じやり方で処理する。
【００４９】
このような意図されない、ひいては、予期しない信頼性経路の存在は、「予期しない信頼性」と称される。この予期しない信頼性は、潜在的に、組織に対して著しい、ある場合には、重大な衝撃を及ぼすことがある。これは、組織Ｂのユーザが、例えば、サイン入りｅメール２６−２８をどこかで組織Ａに送信しそしてそれを受け入れできることを意味する。又、それらは、ウェブサーバー又はファイルサーバーに安全に接続されるか、或いはシステムにリモートでログオンされるか、等々である。
【００５０】
この問題の影響を軽減する手段を適宜に配することができる。これらは、あるアプリケーションしか許さないように組織境界におけるファイアウオールをロックダウンするか、或いはネーム制約又は信頼性アンカーからの最大経路長さのように、証明書経路の付加的な観点をチェックするようにアプリケーションを制限することを含むことができる。しかしながら、これらは、問題に部分的に対処するだけで、付加的な複雑さを招く。組織が欠陥登録手順を有する場合には、悪意をもつ者がパートナー組織の別のユーザのふりをして、アプリケーションにより使用されるネーム制約を回避する可能性が高い。
【００５１】
上述した簡単な形態で従属ＣＡレベルにおいてシステムが相互証明する際の予期せぬ信頼性の存在を示したが、本発明者は、特定の仕方で構成されたＣＡの階層を使用して改善型ＰＫＩ構成の開発を続けた。要約すれば、ルートＣＡは、組織内の信頼性をサポートし、そして従属ＣＡは、多ルート階層と称されるものにおいてローカルユーザに対する信頼性ポイントとしても働く。又、従属ＣＡは、ローカルビジネス要件をサポートするようにパートナーと相互証明することもできる。しかしながら、ルートＣＡからの制約は、この信頼性が他の望ましからぬ組織部分へ伝播するのを防止し、これにより、予期せぬ信頼性の問題を回避する。
【００５２】
図２を参照すれば、組織Ａのための改良された証明当局構造体は、上述した自己証明ＣＡ、ルートＡと、エンジニアリング、マーケッティング及びファイナンス部門に各々組織的に対応する従属ＣＡのエンジニアリングＡ、マーケッティングＡ及びファイナンスＡとを備えている。しかしながら、この場合、ファイナンスＡ ＣＡは、従属ＣＡのユーザに対する信頼性アンカーを形成する自己証明２９でもある。組織Ｂの組織構造体は、正確な構造が重要でないので、上述した通りである。
【００５３】
この場合に、ルートＡが、それ自身又はその従属ＣＡのいずれかに基づいて依存ユーザ１１−１３へ信頼性アンカーを発行するのに加えて、ファイナンスＡも、それ自身の依存ユーザ１３へ信頼性アンカーを発行するが、他のピアＣＡ（例えば、マーケッティングＡ）から従属する従属ユーザ１１−１２へは発行しない。
【００５４】
しかしながら、ファイナンスＡがそれ自身の信頼性アンカーを発行できるのに加えて、上位のルートＡ ＣＡは、このポイントにおいてスタートするときに確認できる証明書に制約３１を課する。特に、これらの証明書は、従属ＣＡのファイナンスＡにより発行された相互証明書を確認する際にこれを使用することが防止されるよう制約される。これは、多数の方法で達成できるが、従属物へ発行される証明書の「inhibitPolicyMapping」フィールドをゼロにセットすることにより最も容易に且つ有効に達成できる。これは、ルートＡにより発行される証明書３０は、組織Ａ内で発行される証明書を確認するのに使用できるが、従属ＣＡにより他の組織へ発行される相互証明書２５を確認するには使用できないことを意味する。
【００５５】
ファイナンスＡが相互証明書２５をファイナンスＢへ発行し、ファイナンスＢが、次いで、ファイナンスＢの加入者１０を証明する場合には、この証明書チェーンを、見返りに、ファイナンスＡの依存ユーザ１３へ確認のために与えることができる。この場合に、証明書は、証明書内にポリシーマッピングフィールドを設けてチェックするという簡単なメカニズムにより、相互証明書として識別可能である。ファイナンスＡの依存ユーザは、ルートＡからの信頼性アンカーを保持できるが、ルートＡにより発行される証明書におけるポリシーマッピングを長さゼロの経路に抑制することは、ルートＡの証明書を使用して相互証明書を正常に確認できないことを意味する。しかしながら、ファイナンスＡの依存ユーザは、ファイナンスＡからの信頼性アンカー２９も保持し、これを使用して相互証明書を正常に確認することができ、これにより、必要な相互作用を進めることが許される。
【００５６】
対照的に、ファイナンスＢの加入者１０が、相互証明書２５を含む同じ証明書チェーンを、ファイナンスＡからの信頼性アンカーを保持しない組織Ａの一部分の依存ユーザ１１−１２へ与える場合には、確認が失敗となる。例えば、ファイナンスＢの加入者がその証明書をマーケッティングＡの依存ユーザ１２へ与える場合には、ルートＡからの信頼性アンカー２４を使用して証明書を確認する試みは失敗となる。というのは、その信頼性アンカーは、発行側のルートＡ ＣＡからゼロより大きなステップで発行された相互証明書を確認するのに使用できないからである。これは、前記制約の使用により達成される。更に、マーケッティングＡの依存ユーザ１２は、ファイナンスＡには従属しないので、ファイナンスＡからの信頼性アンカーを保持せず、これは、ファイナンスＡにより発行された相互証明書を確認する唯一の他の方法となる。その結果、マーケッティングＡの依存ユーザは、ファイナンスＢの加入者により与えられた相互証明書を確認できず、従って、要求された相互作用が拒絶される。相互証明書がエンジニアリングＡの依存ユーザへ与えられた場合にも、同様の状態が生じ、従って、上述した予期しない信頼性が防止される。
【００５７】
本発明者は、証明書の発行について制約を伴う多ルート階層が企業の外部で信頼性をコントロールする改良された手段を与えることが分った。
【００５８】
制約は、ルートにより従属ＣＡへ発行される証明書に課せられる。これらは、ルートにおいて信頼性を開始できる組織の外側へ信頼性が拡張するのを防止する。制約は、上述したもの、即ちネームスペース、ポリシーマッピング、経路長さ及びアプリケーションポリシーのいずれかを含むことができる。その一例は、ルートが、「inhibitPolicyMapping」制約を伴う従属ＣＡ証明書を発行するものである。これは、依存当事者が、ポリシーマッピングフィールドを有する証明書を使用してルートから信頼性経路を構築するのを防止する。
【００５９】
従属ＣＡが相互証明書の発行を希望し、且つ証明書がポリシーマッピングを含む場合には、このマッピングは、ルートからの制約を無効にするが、ルート以外からの経路構築を開始する依存当事者のみに適用される。ここに示す多ルート階層の場合には、これは、従属ＣＡのローカル加入者１３となる。
【００６０】
このシナリオにおけるユーザは、次の２つの信頼性アンカーを保持する。
− 部門／ローカルＣＡ（即ち、自己サイン入り従属ＣＡ）：これは、それ自身のポリシーを実施できると共に、ローカルＣＡ証明書を信頼性アンカーとして保持するものだけに適用される。
− ルートＣＡ：これを通してローカルユーザは、それ自身の組織の他の部分を信頼することができる。ルートＣＡは、相互証明ＣＡへ信頼性が拡張されるのを禁止する作用を有する全体的ポリシーを実施する。
【００６１】
その結果、ユーザは、ルートＣＡから従属ＣＡへ発行される証明書を通してそれら自身の組織の他の部分を信頼する。証明書には制約があることにより、ローカルＣＡからの信頼性は、組織の他部分へと伝播しない。
【００６２】
この技術を採用し、図２を更に参照すれば、それにより得られる信頼関係が以下のテーブル１に要約される。
【００６３】
テーブル１：信頼関係
【００６４】
テーブルを検査することにより、希望の信頼性要求が完全に満足されたことが明らかである。
− ファイナンスＡのユーザは、左側の列において、誰でも信頼する。
− 外部（組織Ｂ）のユーザは、中央の列において、ファイナンスユーザ及びそれら自身の組織のユーザしか信頼しない。彼等は、マーケッティングＡのユーザもエンジニアリングＡのユーザも信頼しない。というのは、当事者間に有効な証明書経路が存在しないからである。
− マーケッティングＡ又はエンジニアリングＡのユーザは、右側の列において、ファイナンスＡのユーザ及びそれら自身のローカルユーザを信頼する。彼等は、外部ＣＡのユーザを信頼しない。というのは、ルートからのポリシー制約が、依存アプリケーションの観点から、経路を不法なものにするからである。
【００６５】
この目的で使用することのできる簡単で且つ有効な制約は、「inhibitPolicyMapping」（ＲＦＣ２４５６に記載された）特性をゼロにセットし、従って、ポリシーマッピングを許さず、ひいては、相互証明を禁止することである。これは、組織ＰＫＩを必要に応じて深くすることを許す。或いは、ネーム制約を使用してもよいが、それらの使用は、外部パートナー組織における登録の正しい実施及び動作に依存し、一方、ポリシーマッピング制約の使用は、相互証明書を発行する組織の手中において信頼性伝播の完全な制御を保持する。又、ポリシーマッピング制約の使用は、ローカル組織ＣＡの深さを禁止することになる経路長さ制約より良好である。
【００６６】
この解決策では、一方では、従属物に対してポリシーマッピングを禁止するルート（又は他の階層的に上位の）ＣＡと、他方では、ポリシーマッピングを含む証明書を実際に発行する従属ＣＡとの間に、見かけ上の矛盾があることが明らかである。それ故、ここに提案する構成は、これらのポリシーを根拠に反対されることがある。しかしながら、組織のポリシーを定義するのは階層のルートＣＡではなく、組織のポリシーに従ってそれらのある部分を実施するという役割を果たすだけであることが更に観察される。その結果、組織のＰＫＩポリシーは、ルート（又は他の階層的に上位の）ＣＡを、内部通信のみのような、その安全な通信の幾つかの観点のみについて役割を果たすものとして指定するよう選択することができる。次いで、従属ＣＡは、ポリシーにより、相互証明のような、組織の安全通信要求の他の観点について役割を果たすことが許される。但し、これは、その従属物が、相互証明書の発行に関連して要求される必要な制約を実施する場合である。それ故、ルートＣＡ及び従属ＣＡは、両方とも、組織のＰＫＩポリシーに従って動作する。
【００６７】
推奨勧告Ｘ．５０９に基づく既知のＰＫＩでは、制約が、上位のＣＡから下位のＣＡへ発行される証明書において実施されるが、自己証明ＣＡにより発行される信頼性アンカー内に制約を埋設できることを示すこともできる。この実施形態では、制約を、ＣＡによりその信頼性アンカーに含ませるだけでよいが、他の実施形態では、上位のＣＡによりその従属物の各々へ発行される各証明書に含ませねばならない。制約を信頼性アンカーに含ませるという単一ポイント実施は、信頼性アンカーのデータ構造体を簡単に変更すると共に、これらデータ構造体を読み取って解釈するシステム（通常、コンピュータ用のプログラムを経て実施される）を対応的に変更することで達成できる。
【００６８】
この構成は、ＣＡの２レベル階層に関して上述したが、当業者であれば、この構成は、３レベル以上の階層へと容易に一般化できることが明らかであろう。特に、図３を参照すれば、多レベル階層は、３つ以上のレベルのＣＡを含むことができる。この例では、全体的な構成は、ルートＡのＣＡと、エンジニアリングＡ、マーケッティングＡ、及びファイナンスＡのＣＡとの間に付加的なレベルが介在されることを除いて、図２に類似している。より詳細には、エンジニアリングＣＡは、Ｒ＆Ｄ Ａ ＣＡに対する従属物とされ、そしてマーケッティングＡ及びファイナンスＡの両ＣＡは、ヘッドオフィスＡ ＣＡに対する従属物とされる。いずれか又は全てのレベルにおけるＣＡは、信頼性アンカーを発行するように配列され（３５−３６）、そしてここに示す例では、証明当局ヘッドオフィスＡ及びエンジニアリングＡは、これを行うことができるとして示されているが、証明当局Ｒ＆Ｄ Ａは、これを行うことができない。
【００６９】
上述したように、自己証明ＣＡは、相互証明書を発行することができる。しかしながら、所与の相互証明書を発行するものより階層的に上位のＣＡにより発行される信頼性アンカー内に課せられる制約の性質は、前記例の場合より複雑である。一般に、所与の相互証明書の発行者より階層的に上位のＣＡにより発行される信頼性アンカーを使用して、その発行された相互証明を正常に確認することはできない。これを達成するための簡単な方法は、証明書の経路長さ制約か、又は禁止ポリシーマッピング制約の「スキップサート(skip certs)」サブフィールドを使用することにより、発行された信頼性アンカーからの確認経路長さを制限することである。従って、ここに示す例では、最低レベルのＣＡ（即ち、エンジニアリングＡ、マーケッティングＡ、及びファイナンスＡ）により発行される相互証明書２５に関して予期せぬ信頼性が生じるのを防止することが望まれる場合には、ルートＡのＣＡが「inhibitPolicyMapping」を１以下の値にセットする一方、ヘッドオフィスＡのＣＡは、「inhibitPolicyMapping」を０以下の値にセットする。このように、ルートＡからの信頼性アンカー２４も、ヘッドオフィスＡからの信頼性アンカー２５も、エンジニアリングＡ、マーケッティングＡ、又はファイナンスＡにより発行された相互証明書２５を確認するように正常に使用することができない。（既存のＸ．５０９ベースのシステムでは、この特定の実施形態が機能するためには、相互証明書が、常に、ポリシーマッピングフィールドをもつことが必要となる。）
【００７０】
しかしながら、ルートＡが「inhibitPolicyMapping」を１にセットした（０ではなく）状況においてヘッドオフィスＡが相互証明書３６を発行すべき場合には、ルートＡの信頼性アンカーを使用して、ヘッドオフィスＡにより発行された相互証明書３６を確認する結果として、予期せぬ信頼性が依然として発生し得ることに注意されたい。従って、これも防止すべき場合には、ルートＡの信頼性アンカーは、その経路長さをゼロに（又は一般的には従属ＣＡにより発行された相互証明書の確認に使用するのを防止する長さに）制限しなければならない。これは、「inhibitPolicyMapping」を、ここでも、上述したようにゼロにセットすることにより達成できる。
【００７１】
逆に、ルートＡにより適用される制約が「inhibitPolicyMapping」をゼロにセットするが、それに対応する制約が、ヘッドオフィスＡにより発行された信頼性アンカーに適用されない場合には、従属ＣＡによりヘッドオフィスＡに発行される相互証明書がヘッドオフィスＡの全ての依存ユーザ１２−１３にわたって信頼性を効果的に拡張させる。それ故、このように、信頼性アンカーを選択的に制約する能力は、複雑な信頼性構造の生成を許す。
【００７２】
２つの相互作用組織の一方についてしか示されないが、ここに提案する構成は、多数の相互接続組織の各々が、予期せぬ信頼性をそれらの各組織内の選択された程度まで禁止するように、それら相互接続組織の各々に適用できることが明らかである。
【００７３】
更に図３を参照すれば、ローカルＣＡ（例えば、ファイナンスＡ）は、そのＣＡの加入者１３に対する付加的な信頼性アンカーを形成する。従って、各ユーザは、証明書チェーンを検証できるところの多数の信頼性アンカーを有し、即ち前記例では、ユーザは、ルートから１つの信頼性アンカーを、ローカルＣＡから別の信頼性アンカーを有し、そしてあるユーザ１２−１３は、ヘッドオフィスＡから更に別の信頼性アンカーを有する。従属ＣＡからの付加的な信頼性アンカーは、たとえ企業のルートが何らかの理由でサービスを停止した場合でも、ローカル通信を継続するのを許す。
【００７４】
多ルート階層（即ち、従属ＣＡが信頼性アンカーを発行できるもの）は、上述した厳格な階層の問題の多くを克服する。これは、ルートＣＡが企業に対する単一の欠陥ポイントであるという問題を排除する。又、ローカルＣＡのキー及び証明書をルートのキー及び証明書からデカップルできるので、証明書及びキーの寿命管理を簡単化する。それ故、一般に、多ルート解決策は、多くの状況に対して厳密な階層より好ましい。
【００７５】
要約すれば、そして更に図３を参照すれば、信頼性の伝播を証明書発行組織内に制限するための手段が設けられる。信頼性の範囲は、第１の階層的に上位のＣＡ（ルートＣＡ）と、第２の相互証明書発行ＣＡ（ファイナンスＡ）との間に、この第２の相互証明書発行ＣＡにより発行された相互証明書２５を確認できるそれ自身の信頼性アンカー３５を有する第３のＣＡ（ヘッドオフィスＡ）を配置することにより制限される。第１の階層的に上位のＣＡ（ルートＣＡ）により発行される証明書に適当な制約を含ませることにより、第２のＣＡ（ファイナンスＡ）により発行された相互証明書２５は、第３のＣＡ（ヘッドオフィスＡ）又は階層的にそれより低いところでしか確認できない。これは、証明書発行組織（組織Ａ）内の信頼関係の範囲を、全体として、第３のＣＡ（ヘッドオフィスＡ）又はそれより低い組織的ユニットに制限する。又、以上の説明から明らかなように、第３のＣＡ及び第２のＣＡは、ある場合には、１つのそして同じＣＡ（例えば、ファイナンスＡ）でよく、従って、発行組織における信頼性は、相互証明書発行組織的ユニット（ファイナンスＡ）内のみを伝播するように制限される。
【００７６】
従って、既知のシステムでは、外部組織（組織Ｂ）における信頼性の程度は、その外部組織へ発行される相互証明書に適用される制約によりその組織の構造のサブセットに制限されるが、本発明は、発行組織（組織Ａ）内の信頼性の範囲に対応的に制約を課するのを許す。これは、信頼性を、相互に証明する組織及び相互に証明される組織のサブセット間に確立し且つそれらに制限するのを許す。
【００７７】
ここに示した範囲や装置の値は、ここに述べた技術を理解するためのもので、求められる効果を失うことなく拡張又は変更できることが当業者に明らかであろう。
【図面の簡単な説明】
【００７８】
【図１】本発明による第１システムを示す図である。
【図２】本発明による第１のＰＫＩシステムを示す図である。
【図３】本発明による第２のＰＫＩシステムを示す図である。
【技術分野】
【０００１】
本発明は、パブリックキーインフラストラクチャー（ＰＫＩ）に係る。より詳細には、本発明は、デジタルサイン入り証明書の発行及び検証と、このような証明を容易にするシステム及び関連する態様とに係る。特に、ＰＫＩシステム間の相互証明(cross-certification)に係る。
【背景技術】
【０００２】
パブリックキーインフラストラクチャー（ＰＫＩ）とは、依存当事者間での電子的信頼性の確立をサポートする技術のシステムである。パブリックキー暗号化（ＰＫＣ）の概念に基づいて、この技術は、バンキングネットワークを含むインターネット及び他のネットワーク上での安全な電子商取引を含む安全な通信のための健全なプラットホームであることがこれまでに分っている。
【０００３】
パブリックキー暗号化（ＰＫＣ）は、当事者が、パブリック及びプライベートキー対を使用することにより安全に通信するのを許す技術である。ＰＫＣベースの通信は、たとえパブリックキーが広く知られ利用できるものであっても、確実性及び機密性の両方を備えることができる。この技術は、最初１９７０年代に、通信を希望する当事者間で共有キーを機密保持することが必要な対称キー暗号化（ＳＫＣ）に代わるものとして発明された。
【０００４】
ＰＫＣが大規模に正常に動作するには、通常、パブリックキーインフラストラクチャー（ＰＫＩ）の確立を必要とする。ＰＫＩのコアには、加入者のパブリックキーの有効性を証明する証明当局（ＣＡ）と一般に称される信頼性のあるエージェントがある。これは、これらのキーにサインして、（パブリックキー）証明書として知られているデータ構造体を形成することにより行なわれる。次いで、パブリックキーを電子的に交換し、そして信頼し得る方法で最初に得なければならない証明ＣＡのパブリックキーを使用して完全性についてチェックすることができる。
【０００５】
所与の証明当局は、企業があまり大きくなければ、１つの完全な企業について単一のアプリケーション又は多数のアプリケーションをサポートすることができる。このような企業ＣＡにより発行される証明書は、通常、組織ディレクトリのようなデータ貯蔵所に記憶され、そこで、アプリケーションによりアクセスされる。自動車産業、金融、及び銀行セクター、石油及び防衛の部門を含む多くの企業は、現在、組織的ＣＡを確立しつつある。１つの著名な大きな例は、約１千万の証明書の組織的ＰＫＩを披露した米国国防総省である。
【０００６】
公式に表現すれば、ＰＫＩのユーザの２つのグループを次のように定義することができる。
− 加入者とは、ＣＡにより発行されたプライベートキー及びそれに対応するデジタル証明書を所有し、これを使用して、認証（サイン）されたメッセージを送信するユーザ、サーバー又は暗号化装置である。メッセージは、デジタルサイン入りｅメール、或いはチャレンジ応答認証プロトコルに使用されるメッセージ交換を含むことができる。
− 依存当事者（ＲＰ）とは、ＣＡにより発行された証明書を使用して、加入者がサインしたメッセージの真正性を検証するエージェントである。依存当事者と表現されるのは、ＣＡに依存し、それに代わって、デジタルサイン入りｅメールを送信したり又はチャレンジ応答認証プロトコルに使用されるメッセージ交換を通して対話したりする加入者のアイデンティティを検証するためである。信頼性のある経路の構築をスタートするのに使用されるＣＡ証明書は、信頼性アンカー(Trust Anchor)と称される。信頼性アンカーは、常時ではないが、しばしば、階層のルート（根）となる。
【０００７】
単一のＣＡが企業内の全てのアプリケーションに対して全てのユーザにサービスするのではなく、ルート及び多数の従属体を伴うＣＡの階層を確立することができる。階層は、ユーザにより近い組織にわたって証明書管理機能を分布させるのを許す。これは、弾力性及び機密性に関して利益をもたらす。弾力性が高められるのは、ＣＡが、証明書及び取り消しリストの発行についてサービスするユーザに接近して動作できるからである。機密性が高められるのは、接近性によりＰＫＩ要素とユーザコミュニティとの間の帯域外通信を容易にするからである。
【０００８】
図１を参照すれば、信頼性は、常に、ＣＡの厳格な階層におけるルートから出発する。これは、自己サイン入り（又は自己発行）証明書を表わす階層のルート（ルートＡ）におけるループ矢印によりグラフ的に表わされている。
【０００９】
注目すべき重要なポイントは、階層のルートが、組織Ａ内の全ての依存当事者（ＲＰ）に対する共有信頼性アンカーであるという点である。これは、ＣＡの厳格な階層を定義付ける特性である。その結果、全てのＲＰが全く同じやり方で信頼性を決定する。これは、最初、反直観的であると思われる。というのは、初めに（間違ったことであるが）、最もローカルなＣＡが、安全な通信を送信及び受信するためのスタートポイントであると仮定するからである。しかしながら、厳格な階層における信頼性のある管理は、非対称的である。
− サイン入り通信を送信するために、信頼性チェーンがルートからローカルＣＡを通して加入者の証明書へと延びる。
− サイン入り通信を受信するために、信頼性は、ここでも、ルートで始まり、必要に応じて従属ＣＡ（又は他のどこか）の各々まで延びる。ローカルＣＡは、このプロセスには何の関係もない。
【００１０】
しかしながら、厳格な階層は、幾つかの欠点で悩まされている。
− ルートＣＡは、企業にとって重大な１つの欠陥ポイントである。何らかの理由で、企業のルートＣＡがある時間周期中サービスを停止した場合には、証明書取り消し情報を発行できなくなり、企業（ローカル領域を含む）にわたるサービス権利の潜在的な拒否を招く。更に重大なことに、ルートが永久的なダメージを受けるか、又は妥協された場合には、企業全体を施錠し直さねばならず、これは、潜在的に、非常に時間浪費であり且つコストのかかるプロセスとなる。
− 厳格な階層は、しばしば、実際のビジネス要件を反映しない。例えば、共同事業体や、多数の小さな部署を所有する大きな会社では、より連合した解決策が、より適切となる。
− 証明書及びキーの更改は、非常に複雑である。というのは、従属ＣＡにより発行される証明書の寿命が、一般的に、上位証明書の寿命を越えないからである。
− 従属体が外部のパートナーとの相互証明を試みる場合には、予期せぬ信頼性の問題が生じ得る。これは、以下で更に述べる。
【００１１】
セキュリティ管理境界（ＰＫＩ境界を含む）を横断することも通常含む組織的境界を横切って安全に通信することがしばしば要求される。パブリックキーの信頼性を拡張する多数の技術が存在するが、今日使用される最も一般的なものは、相互証明である。
【００１２】
ピア対ピア相互証明（以下、単に相互証明と称する）は、ＰＫＩ技術の多数の売主によりサポートされるプロセスである。相互証明は、２つの別々のＰＫＩシステムが互いに信頼性のある関係を確立するのを許す。この信頼関係は、ある制約又は条件が課せられた状態で確立することができ、各ＰＫＩは、パートナーのＰＫＩシステムを無条件で信頼する必要がなく、制御された条件のもとで信頼することができる。
【００１３】
２つの組織は、ルートレベルにおいてそれらの個々のＰＫＩを相互証明することができる。この解決策は、各組織が他の組織の全ＰＫＩを信頼しようとする場合には理想的である。しかしながら、ある組織が、従属レベルにおいてのみ別の組織へ信頼性を拡張することを好み、例えば、選択された部門間のみで信頼できることを好むこともある。このように信頼性を局所化する必要性は、種々の理由で生じ得る。例えば、ある部門は、商業的に敏感なエリアで機能し、外部当事者への信頼性を排除することを希望するが、調達部門は、よりオープンなポリシーを有し、多数の外部供給者との信頼関係を確立する必要がある。
【００１４】
“Planning and Implementing Cross-certification and Qualified Subordination Using WindowsTM Server 2003”と題するＭｉｃｒｏｓｏｆｔTMドキュメントから、既知の相互証明方法を使用して、信頼性の範囲を外部（相互証明された）パートナー組織に制限することが知られている。しかしながら、外部（相互証明された）組織への相互証明書の発行により確立された信頼関係は、相互証明組織内の全ての依存当事者により均一に引き継がれる。
【００１５】
従属ＣＡが相互証明するのを許す状況にこの解決策を適用したときの問題は、それにより得られる信頼関係が非対称的であり、即ち外部エンティティは、それら自体を組織規模で認証できるが、相互証明ＣＡにおける又はその下にある相互証明組織内のエンティティでなければ、それら自体を外部組織に対して認証することができない。この非対称性により、ある通信プロトコルは正しく動作しないことがある。従って、従属ＣＡ間で信頼関係を作り出すことは一般的に推奨されず、このようなプロトコルが正しく動作するよう保証するには常にそれをルートレベルで行うのが好ましい。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
それ故、既知のシステムに関連した１つ以上の問題を軽減する改良されたＰＫＩシステム、装置、方法等を提供することが要望される。
【課題を解決するための手段】
【００１７】
本発明は、ＩＴＵ推奨勧告Ｘ．５０９及びその関連規格に基づくものを含むＰＫＩ又は同様のシステムにより証明書の発行及び／又は使用に制約を課する方法、装置、システム及びコンピュータ用のプログラム（任意であるが、マシン読み取り可能な媒体上にある）を提供する。
【００１８】
特に、本発明の第１の態様によれば、証明当局の階層を含むパブリックキーインフラストラクチャーであって、第１証明当局が相互証明書を発行するように構成され、そして第１当局より階層的に上位の第２証明当局が、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成されたパブリックキーインフラストラクチャーが提供される。
【００１９】
第２証明当局は、実際に、信頼性アンカー及び他の証明書を発行できるが、それらは、単独にせよ、組み合せにせよ、第１当局により発行された相互証明書の正常な確認を許さないことを保証しなければならない。
【００２０】
ある実施形態では、証明書は、信頼性アンカーを含む。
【００２１】
ある実施形態では、第１当局より階層的に上位の各証明当局は、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成される。
【００２２】
ある実施形態では、第２証明当局は、その従属証明当局に、相互証明書の正常な確認に使用するのを除外する制約を含む証明書を発行する。
【００２３】
ある実施形態では、前記制約は、経路長さ制約、ネームスペース制約、ポリシーマッピング制約、及びアプリケーション制約の１つを含む。
【００２４】
ある実施形態では、前記制約は、ポリシーマッピング制約を含む。
【００２５】
ある実施形態では、前記制約は、ポリシーマッピングを禁止する。
【００２６】
ある実施形態では、前記信頼性アンカーは、「inhibitPolicyMapping」フィールドを備え、そして前記制約は、この「inhibitPolicyMapping」フィールドを所定値にセットすることを含む。
【００２７】
ある好ましい実施形態では、前記「inhibitPolicyMapping」フィールドの所定値はゼロである。
【００２８】
前記パブリックキーインフラストラクチャーは、実質的にＩＴＵ推奨勧告Ｘ．５０９に基づいて動作される。
【００２９】
この点に関して、基本的Ｘ．５０９推奨勧告の派生物が既に多数あり、これらは、時間と共に必然的に進化する。それ故、当業者であれば、本発明は、Ｘ．５０９自体の文字通りの表現に関してこれら派生物を等しく適用し、ここでは、文字通りというよりは実質的にＸ．５０９に従ってアプリケーションインフラストラクチャーを適用することが容易に理解されよう。
【００３０】
本発明の更に別の態様によれば、第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーのための証明当局であって、この証明当局は、前記第１証明当局より階層的に上位であるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成された証明当局が提供される。
【００３１】
又、本発明は、インフラストラクチャーを動作する方法であって、装置の各関連要素断片に対応する方法ステップを備えた方法にも向けられる。
【００３２】
特に、本発明の更に別の態様によれば、パブリックキーインフラストラクチャーを動作する方法において、証明当局の階層を含むパブリックキーインフラストラクチャーを用意するステップであって、その階層は、第１証明当局と、それより階層的に上位の第２証明当局とを含むものであるステップと、相互証明書を発行するように第１証明当局を構成するステップと、第１証明当局により発行された相互証明書の正常な確認を単独でも組み合せでも許さないような証明書を発行するように第２証明当局を構成するステップと、を備えた方法が提供される。
【００３３】
又、本発明は、本発明の方法を実行するためのコンピュータ用のプログラム（任意にマシン読み取り可能なキャリア又は媒体上のソフトウェアであるか、ファームウェアであるか、チップレイアウトソフトウェアであるか、或いはソースコード又はオブジェクトコードであるかに関わらず）にも向けられ、又、本発明は、このようなプログラムによりプログラムされるコンピュータであって、本発明の他の観点という意味で装置も形成するようなコンピュータにも向けられる。
【００３４】
より詳細には、本発明の更に別の態様によれば、第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーにおいて証明当局として動作するように構成されたコンポーネントコード部分を有するコンピュータ用のプログラムにおいて、前記証明当局は、前記第１証明当局に対して階層的に上位となるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成されたコンピュータ用のプログラムが提供される。
【００３５】
本発明の更に別の態様によれば、従属証明書又は信頼性アンカーを各々通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む従属証明書又は信頼性アンカーを発行するように構成された証明当局を備えたパブリックキーインフラストラクチャーが提供される。
【００３６】
従属証明書又は信頼性アンカーを各々通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む従属証明書又は信頼性アンカーにおける制約に応答して相互証明書を確認するように構成された証明書確認機能を備えたパブリックキーインフラストラクチャーが提供される。
【００３７】
好ましい特徴は、当業者に明らかなように、適宜組み合せることができ、且つ本発明のいずれかの態様と組み合せることができる。上述した例を越えた本発明の他の効果も、当業者に明らかであろう。
【００３８】
本発明をいかに実施するか示すために、添付図面を参照して、本発明の実施形態を一例として以下に詳細に説明する。
【発明を実施するための最良の形態】
【００３９】
図１を参照すれば、相互証明の程度を制御するための１つの考えられる解決策は、従属部門レベルにおいて相互証明を遂行することである。これは、２つの従属レベルＣＡ、即ちファイナンスＡとファイナンスＢとの間の信頼関係を示す。明らかに、ここでは、信頼関係を２つの組織のファイナンス部門に制限することが意図される。この要件を満足させるために、ルートＣＡレベルで相互証明するときに使用された従来知られた解決策は、証明書制約の良く知られた技術を使用することである。不都合なことに、これは、以下に述べるように、従属ＣＡレベルで相互証明するときには不充分である。
【００４０】
Ｘ．５０９規格は、証明書制約の使用を許す（例えば、“RFC 2459-InternetX.509 Public Key Infrastructure Certificate and CRL Profile”(http://www.faqs.org/rfcs/rfc2459.html)に定義されたように）。このような制約は、ネームスペース、ポリシーマッピング、経路長さ、又はアプリケーションポリシー制約を含んでもよい。このような制約は、相互証明書に入れられ、信頼性をパートナー組織へ拡張する程度を制限するように作用する。説明上、図１を再び参照すれば、制約は、ＣＡファイナンスＡにより次のように使用することができる。
【００４１】
− 経路長さ制約は、ファイナンスＢが相互証明するところの他のＣＡまで信頼性が拡張するのを防止するのに使用できる。例えば、ファイナンスＡにより発行される相互証明書において経路長さをゼロにセットすると、信頼性がファイナンスＢを越えて他のＣＡへ拡張しないよう保証する。
【００４２】
− ファイナンスＡからファイナンスＢへ発行される相互証明書におけるネームスペース制約は、許可されたネームスペースの外側の証明書へ信頼性が拡張するのを防止するのに使用でき、この例では、相互証明書は、“xxx.Organisation-B.com”の形式のネームスペースだけを許し、これは、証明書の使用を組織Ｂ内のエンティティ“xxx”内に制限する（この場合、“xxx”は、ファイナンスＢ関連のネームスペースである）。
【００４３】
− ファイナンスＡにより発行される相互証明書におけるポリシーマッピング制約は、許可されたポリシー形式の１つを使用しないＣＡへ信頼性が拡張するのを防止するのに使用できる。
− ファイナンスＡにより発行される相互証明書におけるアプリケーションポリシー制約は、安全通信を、定義された１組のアプリケーションに制約するのに使用できる。
【００４４】
ＲＦＣ２４５９は、種々の形式の証明書制約、それらのシンタックス、及びそれらをいかに使用するか、の詳細な説明を含む。
【００４５】
制約について察知すべき重要なポイントは、それらが相互証明組織（この例では組織Ｂ）内の加入者１０に適用されるが、相互証明組織（組織Ａ）内の依存当事者１１−１３には選択的に適用されないことである。むしろ、証明書に含まれた制約は、特定の信頼性アンカーで信頼性の構築を開始した全ての依存当事者に全体的に適用される。それ故、この例では、組織Ａにおける全ての当事者は、ファイナンス部門の中であろうと外であろうと、相互証明書を同様に処理する。
【００４６】
各加入者又は依存当事者は、１組の証明書２０−２３を保持し、又はそれにアクセスすることができる。各ユーザが証明書をローカルに保持するかのように示されているが、証明書は、各組織内の共通にアクセス可能な貯蔵所に保持されてもよい。
【００４７】
しかしながら、本発明者は、この構成の望ましからぬ結果として、相互証明組織において信頼性経路が予期せずに発生し、これらの予期しない信頼性経路の存在を実験で確認したことを示している。
【００４８】
更に、図１を参照すれば、組織Ｂのファイナンス部門からの加入者１０は、組織Ａのマーケット部門からのユーザ１２へサイン入りｅメールを送信する。２つのファイナンスＣＡ間で相互証明が実施されても、ルートＡから送信ユーザの証明書への信頼性チェーンが存在する。受信ユーザの信頼性アンカー２４がルートＡにより発行され、ファイナンスＣＡにより形成された相互証明書２５は組織Ａのディレクトリ内で自由に配布されるので、受信者のｅメールアプリケーションは、ファイナンスＡにより確立された相互証明により課せられた同じ制約を遵守して、サイン入りｅメールを全く同じやり方で処理する。
【００４９】
このような意図されない、ひいては、予期しない信頼性経路の存在は、「予期しない信頼性」と称される。この予期しない信頼性は、潜在的に、組織に対して著しい、ある場合には、重大な衝撃を及ぼすことがある。これは、組織Ｂのユーザが、例えば、サイン入りｅメール２６−２８をどこかで組織Ａに送信しそしてそれを受け入れできることを意味する。又、それらは、ウェブサーバー又はファイルサーバーに安全に接続されるか、或いはシステムにリモートでログオンされるか、等々である。
【００５０】
この問題の影響を軽減する手段を適宜に配することができる。これらは、あるアプリケーションしか許さないように組織境界におけるファイアウオールをロックダウンするか、或いはネーム制約又は信頼性アンカーからの最大経路長さのように、証明書経路の付加的な観点をチェックするようにアプリケーションを制限することを含むことができる。しかしながら、これらは、問題に部分的に対処するだけで、付加的な複雑さを招く。組織が欠陥登録手順を有する場合には、悪意をもつ者がパートナー組織の別のユーザのふりをして、アプリケーションにより使用されるネーム制約を回避する可能性が高い。
【００５１】
上述した簡単な形態で従属ＣＡレベルにおいてシステムが相互証明する際の予期せぬ信頼性の存在を示したが、本発明者は、特定の仕方で構成されたＣＡの階層を使用して改善型ＰＫＩ構成の開発を続けた。要約すれば、ルートＣＡは、組織内の信頼性をサポートし、そして従属ＣＡは、多ルート階層と称されるものにおいてローカルユーザに対する信頼性ポイントとしても働く。又、従属ＣＡは、ローカルビジネス要件をサポートするようにパートナーと相互証明することもできる。しかしながら、ルートＣＡからの制約は、この信頼性が他の望ましからぬ組織部分へ伝播するのを防止し、これにより、予期せぬ信頼性の問題を回避する。
【００５２】
図２を参照すれば、組織Ａのための改良された証明当局構造体は、上述した自己証明ＣＡ、ルートＡと、エンジニアリング、マーケッティング及びファイナンス部門に各々組織的に対応する従属ＣＡのエンジニアリングＡ、マーケッティングＡ及びファイナンスＡとを備えている。しかしながら、この場合、ファイナンスＡ ＣＡは、従属ＣＡのユーザに対する信頼性アンカーを形成する自己証明２９でもある。組織Ｂの組織構造体は、正確な構造が重要でないので、上述した通りである。
【００５３】
この場合に、ルートＡが、それ自身又はその従属ＣＡのいずれかに基づいて依存ユーザ１１−１３へ信頼性アンカーを発行するのに加えて、ファイナンスＡも、それ自身の依存ユーザ１３へ信頼性アンカーを発行するが、他のピアＣＡ（例えば、マーケッティングＡ）から従属する従属ユーザ１１−１２へは発行しない。
【００５４】
しかしながら、ファイナンスＡがそれ自身の信頼性アンカーを発行できるのに加えて、上位のルートＡ ＣＡは、このポイントにおいてスタートするときに確認できる証明書に制約３１を課する。特に、これらの証明書は、従属ＣＡのファイナンスＡにより発行された相互証明書を確認する際にこれを使用することが防止されるよう制約される。これは、多数の方法で達成できるが、従属物へ発行される証明書の「inhibitPolicyMapping」フィールドをゼロにセットすることにより最も容易に且つ有効に達成できる。これは、ルートＡにより発行される証明書３０は、組織Ａ内で発行される証明書を確認するのに使用できるが、従属ＣＡにより他の組織へ発行される相互証明書２５を確認するには使用できないことを意味する。
【００５５】
ファイナンスＡが相互証明書２５をファイナンスＢへ発行し、ファイナンスＢが、次いで、ファイナンスＢの加入者１０を証明する場合には、この証明書チェーンを、見返りに、ファイナンスＡの依存ユーザ１３へ確認のために与えることができる。この場合に、証明書は、証明書内にポリシーマッピングフィールドを設けてチェックするという簡単なメカニズムにより、相互証明書として識別可能である。ファイナンスＡの依存ユーザは、ルートＡからの信頼性アンカーを保持できるが、ルートＡにより発行される証明書におけるポリシーマッピングを長さゼロの経路に抑制することは、ルートＡの証明書を使用して相互証明書を正常に確認できないことを意味する。しかしながら、ファイナンスＡの依存ユーザは、ファイナンスＡからの信頼性アンカー２９も保持し、これを使用して相互証明書を正常に確認することができ、これにより、必要な相互作用を進めることが許される。
【００５６】
対照的に、ファイナンスＢの加入者１０が、相互証明書２５を含む同じ証明書チェーンを、ファイナンスＡからの信頼性アンカーを保持しない組織Ａの一部分の依存ユーザ１１−１２へ与える場合には、確認が失敗となる。例えば、ファイナンスＢの加入者がその証明書をマーケッティングＡの依存ユーザ１２へ与える場合には、ルートＡからの信頼性アンカー２４を使用して証明書を確認する試みは失敗となる。というのは、その信頼性アンカーは、発行側のルートＡ ＣＡからゼロより大きなステップで発行された相互証明書を確認するのに使用できないからである。これは、前記制約の使用により達成される。更に、マーケッティングＡの依存ユーザ１２は、ファイナンスＡには従属しないので、ファイナンスＡからの信頼性アンカーを保持せず、これは、ファイナンスＡにより発行された相互証明書を確認する唯一の他の方法となる。その結果、マーケッティングＡの依存ユーザは、ファイナンスＢの加入者により与えられた相互証明書を確認できず、従って、要求された相互作用が拒絶される。相互証明書がエンジニアリングＡの依存ユーザへ与えられた場合にも、同様の状態が生じ、従って、上述した予期しない信頼性が防止される。
【００５７】
本発明者は、証明書の発行について制約を伴う多ルート階層が企業の外部で信頼性をコントロールする改良された手段を与えることが分った。
【００５８】
制約は、ルートにより従属ＣＡへ発行される証明書に課せられる。これらは、ルートにおいて信頼性を開始できる組織の外側へ信頼性が拡張するのを防止する。制約は、上述したもの、即ちネームスペース、ポリシーマッピング、経路長さ及びアプリケーションポリシーのいずれかを含むことができる。その一例は、ルートが、「inhibitPolicyMapping」制約を伴う従属ＣＡ証明書を発行するものである。これは、依存当事者が、ポリシーマッピングフィールドを有する証明書を使用してルートから信頼性経路を構築するのを防止する。
【００５９】
従属ＣＡが相互証明書の発行を希望し、且つ証明書がポリシーマッピングを含む場合には、このマッピングは、ルートからの制約を無効にするが、ルート以外からの経路構築を開始する依存当事者のみに適用される。ここに示す多ルート階層の場合には、これは、従属ＣＡのローカル加入者１３となる。
【００６０】
このシナリオにおけるユーザは、次の２つの信頼性アンカーを保持する。
− 部門／ローカルＣＡ（即ち、自己サイン入り従属ＣＡ）：これは、それ自身のポリシーを実施できると共に、ローカルＣＡ証明書を信頼性アンカーとして保持するものだけに適用される。
− ルートＣＡ：これを通してローカルユーザは、それ自身の組織の他の部分を信頼することができる。ルートＣＡは、相互証明ＣＡへ信頼性が拡張されるのを禁止する作用を有する全体的ポリシーを実施する。
【００６１】
その結果、ユーザは、ルートＣＡから従属ＣＡへ発行される証明書を通してそれら自身の組織の他の部分を信頼する。証明書には制約があることにより、ローカルＣＡからの信頼性は、組織の他部分へと伝播しない。
【００６２】
この技術を採用し、図２を更に参照すれば、それにより得られる信頼関係が以下のテーブル１に要約される。
【００６３】
テーブル１：信頼関係
【００６４】
テーブルを検査することにより、希望の信頼性要求が完全に満足されたことが明らかである。
− ファイナンスＡのユーザは、左側の列において、誰でも信頼する。
− 外部（組織Ｂ）のユーザは、中央の列において、ファイナンスユーザ及びそれら自身の組織のユーザしか信頼しない。彼等は、マーケッティングＡのユーザもエンジニアリングＡのユーザも信頼しない。というのは、当事者間に有効な証明書経路が存在しないからである。
− マーケッティングＡ又はエンジニアリングＡのユーザは、右側の列において、ファイナンスＡのユーザ及びそれら自身のローカルユーザを信頼する。彼等は、外部ＣＡのユーザを信頼しない。というのは、ルートからのポリシー制約が、依存アプリケーションの観点から、経路を不法なものにするからである。
【００６５】
この目的で使用することのできる簡単で且つ有効な制約は、「inhibitPolicyMapping」（ＲＦＣ２４５６に記載された）特性をゼロにセットし、従って、ポリシーマッピングを許さず、ひいては、相互証明を禁止することである。これは、組織ＰＫＩを必要に応じて深くすることを許す。或いは、ネーム制約を使用してもよいが、それらの使用は、外部パートナー組織における登録の正しい実施及び動作に依存し、一方、ポリシーマッピング制約の使用は、相互証明書を発行する組織の手中において信頼性伝播の完全な制御を保持する。又、ポリシーマッピング制約の使用は、ローカル組織ＣＡの深さを禁止することになる経路長さ制約より良好である。
【００６６】
この解決策では、一方では、従属物に対してポリシーマッピングを禁止するルート（又は他の階層的に上位の）ＣＡと、他方では、ポリシーマッピングを含む証明書を実際に発行する従属ＣＡとの間に、見かけ上の矛盾があることが明らかである。それ故、ここに提案する構成は、これらのポリシーを根拠に反対されることがある。しかしながら、組織のポリシーを定義するのは階層のルートＣＡではなく、組織のポリシーに従ってそれらのある部分を実施するという役割を果たすだけであることが更に観察される。その結果、組織のＰＫＩポリシーは、ルート（又は他の階層的に上位の）ＣＡを、内部通信のみのような、その安全な通信の幾つかの観点のみについて役割を果たすものとして指定するよう選択することができる。次いで、従属ＣＡは、ポリシーにより、相互証明のような、組織の安全通信要求の他の観点について役割を果たすことが許される。但し、これは、その従属物が、相互証明書の発行に関連して要求される必要な制約を実施する場合である。それ故、ルートＣＡ及び従属ＣＡは、両方とも、組織のＰＫＩポリシーに従って動作する。
【００６７】
推奨勧告Ｘ．５０９に基づく既知のＰＫＩでは、制約が、上位のＣＡから下位のＣＡへ発行される証明書において実施されるが、自己証明ＣＡにより発行される信頼性アンカー内に制約を埋設できることを示すこともできる。この実施形態では、制約を、ＣＡによりその信頼性アンカーに含ませるだけでよいが、他の実施形態では、上位のＣＡによりその従属物の各々へ発行される各証明書に含ませねばならない。制約を信頼性アンカーに含ませるという単一ポイント実施は、信頼性アンカーのデータ構造体を簡単に変更すると共に、これらデータ構造体を読み取って解釈するシステム（通常、コンピュータ用のプログラムを経て実施される）を対応的に変更することで達成できる。
【００６８】
この構成は、ＣＡの２レベル階層に関して上述したが、当業者であれば、この構成は、３レベル以上の階層へと容易に一般化できることが明らかであろう。特に、図３を参照すれば、多レベル階層は、３つ以上のレベルのＣＡを含むことができる。この例では、全体的な構成は、ルートＡのＣＡと、エンジニアリングＡ、マーケッティングＡ、及びファイナンスＡのＣＡとの間に付加的なレベルが介在されることを除いて、図２に類似している。より詳細には、エンジニアリングＣＡは、Ｒ＆Ｄ Ａ ＣＡに対する従属物とされ、そしてマーケッティングＡ及びファイナンスＡの両ＣＡは、ヘッドオフィスＡ ＣＡに対する従属物とされる。いずれか又は全てのレベルにおけるＣＡは、信頼性アンカーを発行するように配列され（３５−３６）、そしてここに示す例では、証明当局ヘッドオフィスＡ及びエンジニアリングＡは、これを行うことができるとして示されているが、証明当局Ｒ＆Ｄ Ａは、これを行うことができない。
【００６９】
上述したように、自己証明ＣＡは、相互証明書を発行することができる。しかしながら、所与の相互証明書を発行するものより階層的に上位のＣＡにより発行される信頼性アンカー内に課せられる制約の性質は、前記例の場合より複雑である。一般に、所与の相互証明書の発行者より階層的に上位のＣＡにより発行される信頼性アンカーを使用して、その発行された相互証明を正常に確認することはできない。これを達成するための簡単な方法は、証明書の経路長さ制約か、又は禁止ポリシーマッピング制約の「スキップサート(skip certs)」サブフィールドを使用することにより、発行された信頼性アンカーからの確認経路長さを制限することである。従って、ここに示す例では、最低レベルのＣＡ（即ち、エンジニアリングＡ、マーケッティングＡ、及びファイナンスＡ）により発行される相互証明書２５に関して予期せぬ信頼性が生じるのを防止することが望まれる場合には、ルートＡのＣＡが「inhibitPolicyMapping」を１以下の値にセットする一方、ヘッドオフィスＡのＣＡは、「inhibitPolicyMapping」を０以下の値にセットする。このように、ルートＡからの信頼性アンカー２４も、ヘッドオフィスＡからの信頼性アンカー２５も、エンジニアリングＡ、マーケッティングＡ、又はファイナンスＡにより発行された相互証明書２５を確認するように正常に使用することができない。（既存のＸ．５０９ベースのシステムでは、この特定の実施形態が機能するためには、相互証明書が、常に、ポリシーマッピングフィールドをもつことが必要となる。）
【００７０】
しかしながら、ルートＡが「inhibitPolicyMapping」を１にセットした（０ではなく）状況においてヘッドオフィスＡが相互証明書３６を発行すべき場合には、ルートＡの信頼性アンカーを使用して、ヘッドオフィスＡにより発行された相互証明書３６を確認する結果として、予期せぬ信頼性が依然として発生し得ることに注意されたい。従って、これも防止すべき場合には、ルートＡの信頼性アンカーは、その経路長さをゼロに（又は一般的には従属ＣＡにより発行された相互証明書の確認に使用するのを防止する長さに）制限しなければならない。これは、「inhibitPolicyMapping」を、ここでも、上述したようにゼロにセットすることにより達成できる。
【００７１】
逆に、ルートＡにより適用される制約が「inhibitPolicyMapping」をゼロにセットするが、それに対応する制約が、ヘッドオフィスＡにより発行された信頼性アンカーに適用されない場合には、従属ＣＡによりヘッドオフィスＡに発行される相互証明書がヘッドオフィスＡの全ての依存ユーザ１２−１３にわたって信頼性を効果的に拡張させる。それ故、このように、信頼性アンカーを選択的に制約する能力は、複雑な信頼性構造の生成を許す。
【００７２】
２つの相互作用組織の一方についてしか示されないが、ここに提案する構成は、多数の相互接続組織の各々が、予期せぬ信頼性をそれらの各組織内の選択された程度まで禁止するように、それら相互接続組織の各々に適用できることが明らかである。
【００７３】
更に図３を参照すれば、ローカルＣＡ（例えば、ファイナンスＡ）は、そのＣＡの加入者１３に対する付加的な信頼性アンカーを形成する。従って、各ユーザは、証明書チェーンを検証できるところの多数の信頼性アンカーを有し、即ち前記例では、ユーザは、ルートから１つの信頼性アンカーを、ローカルＣＡから別の信頼性アンカーを有し、そしてあるユーザ１２−１３は、ヘッドオフィスＡから更に別の信頼性アンカーを有する。従属ＣＡからの付加的な信頼性アンカーは、たとえ企業のルートが何らかの理由でサービスを停止した場合でも、ローカル通信を継続するのを許す。
【００７４】
多ルート階層（即ち、従属ＣＡが信頼性アンカーを発行できるもの）は、上述した厳格な階層の問題の多くを克服する。これは、ルートＣＡが企業に対する単一の欠陥ポイントであるという問題を排除する。又、ローカルＣＡのキー及び証明書をルートのキー及び証明書からデカップルできるので、証明書及びキーの寿命管理を簡単化する。それ故、一般に、多ルート解決策は、多くの状況に対して厳密な階層より好ましい。
【００７５】
要約すれば、そして更に図３を参照すれば、信頼性の伝播を証明書発行組織内に制限するための手段が設けられる。信頼性の範囲は、第１の階層的に上位のＣＡ（ルートＣＡ）と、第２の相互証明書発行ＣＡ（ファイナンスＡ）との間に、この第２の相互証明書発行ＣＡにより発行された相互証明書２５を確認できるそれ自身の信頼性アンカー３５を有する第３のＣＡ（ヘッドオフィスＡ）を配置することにより制限される。第１の階層的に上位のＣＡ（ルートＣＡ）により発行される証明書に適当な制約を含ませることにより、第２のＣＡ（ファイナンスＡ）により発行された相互証明書２５は、第３のＣＡ（ヘッドオフィスＡ）又は階層的にそれより低いところでしか確認できない。これは、証明書発行組織（組織Ａ）内の信頼関係の範囲を、全体として、第３のＣＡ（ヘッドオフィスＡ）又はそれより低い組織的ユニットに制限する。又、以上の説明から明らかなように、第３のＣＡ及び第２のＣＡは、ある場合には、１つのそして同じＣＡ（例えば、ファイナンスＡ）でよく、従って、発行組織における信頼性は、相互証明書発行組織的ユニット（ファイナンスＡ）内のみを伝播するように制限される。
【００７６】
従って、既知のシステムでは、外部組織（組織Ｂ）における信頼性の程度は、その外部組織へ発行される相互証明書に適用される制約によりその組織の構造のサブセットに制限されるが、本発明は、発行組織（組織Ａ）内の信頼性の範囲に対応的に制約を課するのを許す。これは、信頼性を、相互に証明する組織及び相互に証明される組織のサブセット間に確立し且つそれらに制限するのを許す。
【００７７】
ここに示した範囲や装置の値は、ここに述べた技術を理解するためのもので、求められる効果を失うことなく拡張又は変更できることが当業者に明らかであろう。
【図面の簡単な説明】
【００７８】
【図１】本発明による第１システムを示す図である。
【図２】本発明による第１のＰＫＩシステムを示す図である。
【図３】本発明による第２のＰＫＩシステムを示す図である。
【特許請求の範囲】
【請求項１】
証明当局の階層を含むパブリックキーインフラストラクチャーにおいて、第１証明当局が相互証明書を発行するように構成され、そしてその第１当局より階層的に上位の第２証明当局が、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成された、パブリックキーインフラストラクチャー。
【請求項２】
前記証明書は、信頼性アンカーを含む、請求項１に記載のパブリックキーインフラストラクチャー。
【請求項３】
前記第１当局より階層的に上位の各証明当局は、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成される、請求項１又は２に記載のパブリックキーインフラストラクチャー。
【請求項４】
前記第２証明当局は、その従属証明当局に、前記相互証明書の正常な確認に使用するのを除外する制約を含む証明書を発行する、請求項１から３のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項５】
前記制約は、経路長さ制約、ネームスペース制約、ポリシーマッピング制約、及びアプリケーション制約の１つを含む、請求項１から４のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項６】
前記制約は、ポリシーマッピング制約を含む、請求項１から５のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項７】
前記制約は、ポリシーマッピングを禁止する、請求項１から６のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項８】
前記信頼性アンカーは、「inhibitPolicyMapping」フィールドを備え、そして前記制約は、この「inhibitPolicyMapping」フィールドを所定値にセットすることを含む、請求項１から７のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項９】
前記所定値はゼロである、請求項８に記載のパブリックキーインフラストラクチャー。
【請求項１０】
実質的にＩＴＵ推奨勧告Ｘ．５０９に従って動作される、請求項１から９のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項１１】
第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーのための証明当局であって、この証明当局は、前記第１証明当局より階層的に上位であるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成された証明当局。
【請求項１２】
パブリックキーインフラストラクチャーを動作する方法において、
証明当局の階層を含むパブリックキーインフラストラクチャーを用意するステップであって、その階層は、第１証明当局と、それより階層的に上位の第２証明当局とを含むものであるステップと、
相互証明書を発行するように前記第１証明当局を構成するステップと、
前記第１証明当局により発行された相互証明書の正常な確認を単独でも組み合せでも許さないような証明書を発行するように前記第２証明当局を構成するステップと、
を備えた方法。
【請求項１３】
第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーにおいて証明当局として動作するように構成されたコンポーネントコード部分を有するコンピュータ用のプログラムにおいて、前記証明当局は、前記第１証明当局に対して階層的に上位となるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成されたコンピュータ用のプログラム。
【請求項１４】
信頼性アンカーを、通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む信頼性アンカーを発行するように構成された証明当局を備えたパブリックキーインフラストラクチャー。
【請求項１５】
信頼性アンカーを、通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む信頼性アンカーにおける制約に応答して相互証明書を確認するように構成された証明書確認機能を備えたパブリックキーインフラストラクチャー。
【請求項１６】
ルートの証明当局と、このルート証明当局に従属する第２の証明当局とを備え、この第２の証明当局が信頼性アンカーを発行できるパブリックキーインフラストラクチャー。
【請求項１７】
前記第２の証明当局は、相互証明書も発行できる、請求項１６に記載のパブリックキーインフラストラクチャー。
【請求項１８】
実質的に添付図面を参照して説明された、マシン読み取り可能な媒体上に任意に設けられるパブリックキーインフラストラクチャー方法、装置、システム及びコンピュータ用のプログラム。
【請求項１】
証明当局の階層を含むパブリックキーインフラストラクチャーにおいて、第１証明当局が相互証明書を発行するように構成され、そしてその第１当局より階層的に上位の第２証明当局が、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成された、パブリックキーインフラストラクチャー。
【請求項２】
前記証明書は、信頼性アンカーを含む、請求項１に記載のパブリックキーインフラストラクチャー。
【請求項３】
前記第１当局より階層的に上位の各証明当局は、単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成される、請求項１又は２に記載のパブリックキーインフラストラクチャー。
【請求項４】
前記第２証明当局は、その従属証明当局に、前記相互証明書の正常な確認に使用するのを除外する制約を含む証明書を発行する、請求項１から３のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項５】
前記制約は、経路長さ制約、ネームスペース制約、ポリシーマッピング制約、及びアプリケーション制約の１つを含む、請求項１から４のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項６】
前記制約は、ポリシーマッピング制約を含む、請求項１から５のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項７】
前記制約は、ポリシーマッピングを禁止する、請求項１から６のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項８】
前記信頼性アンカーは、「inhibitPolicyMapping」フィールドを備え、そして前記制約は、この「inhibitPolicyMapping」フィールドを所定値にセットすることを含む、請求項１から７のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項９】
前記所定値はゼロである、請求項８に記載のパブリックキーインフラストラクチャー。
【請求項１０】
実質的にＩＴＵ推奨勧告Ｘ．５０９に従って動作される、請求項１から９のいずれかに記載のパブリックキーインフラストラクチャー。
【請求項１１】
第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーのための証明当局であって、この証明当局は、前記第１証明当局より階層的に上位であるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成された証明当局。
【請求項１２】
パブリックキーインフラストラクチャーを動作する方法において、
証明当局の階層を含むパブリックキーインフラストラクチャーを用意するステップであって、その階層は、第１証明当局と、それより階層的に上位の第２証明当局とを含むものであるステップと、
相互証明書を発行するように前記第１証明当局を構成するステップと、
前記第１証明当局により発行された相互証明書の正常な確認を単独でも組み合せでも許さないような証明書を発行するように前記第２証明当局を構成するステップと、
を備えた方法。
【請求項１３】
第１証明当局が相互証明書を発行するように構成された証明当局の階層を含むパブリックキーインフラストラクチャーにおいて証明当局として動作するように構成されたコンポーネントコード部分を有するコンピュータ用のプログラムにおいて、前記証明当局は、前記第１証明当局に対して階層的に上位となるように構成され、且つ単独で使用しても組み合わせて使用しても前記相互証明書を正常に確認できないような証明書しか発行しないように構成されたコンピュータ用のプログラム。
【請求項１４】
信頼性アンカーを、通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む信頼性アンカーを発行するように構成された証明当局を備えたパブリックキーインフラストラクチャー。
【請求項１５】
信頼性アンカーを、通常の動作において、従属証明当局により発行された相互証明書の確認に使用するのを防止するという制約を含む信頼性アンカーにおける制約に応答して相互証明書を確認するように構成された証明書確認機能を備えたパブリックキーインフラストラクチャー。
【請求項１６】
ルートの証明当局と、このルート証明当局に従属する第２の証明当局とを備え、この第２の証明当局が信頼性アンカーを発行できるパブリックキーインフラストラクチャー。
【請求項１７】
前記第２の証明当局は、相互証明書も発行できる、請求項１６に記載のパブリックキーインフラストラクチャー。
【請求項１８】
実質的に添付図面を参照して説明された、マシン読み取り可能な媒体上に任意に設けられるパブリックキーインフラストラクチャー方法、装置、システム及びコンピュータ用のプログラム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００８−５２６０６５（Ｐ２００８−５２６０６５Ａ）
【公表日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【出願番号】特願２００７−５４７６６３（Ｐ２００７−５４７６６３）
【出願日】平成１７年１２月２３日（２００５．１２．２３）
【国際出願番号】ＰＣＴ／ＧＢ２００５／００５０７１
【国際公開番号】ＷＯ２００６／０６７５０３
【国際公開日】平成１８年６月２９日（２００６．６．２９）
【出願人】（５０１２９７５５０）キネティック リミテッド (57)
【Ｆターム（参考）】
【公表日】平成２０年７月１７日（２００８．７．１７）
【国際特許分類】
【出願日】平成１７年１２月２３日（２００５．１２．２３）
【国際出願番号】ＰＣＴ／ＧＢ２００５／００５０７１
【国際公開番号】ＷＯ２００６／０６７５０３
【国際公開日】平成１８年６月２９日（２００６．６．２９）
【出願人】（５０１２９７５５０）キネティック リミテッド (57)
【Ｆターム（参考）】
[ Back to top ]