複数の信頼ドメインへのデジタル証明書のバインディング
公開鍵基盤は、デジタル証明書を発行する関与者を含む。各デジタル証明書は、少なくとも２つの異なる信頼ドメインにおいて信用される。この公開鍵基盤は、信頼ドメインの間でのポリシーマッピングを使用しない。さらに、この公開鍵基盤は、信頼ドメインの如何なる対も相互証明書を介してリンクしない。１つの信頼ドメインのみが、任意の所定の時点でデジタル証明書にバインドされる。デジタル証明書にバインドされるべき現在の信頼ドメインは、依存者により選択された特定の証明書検証方法に基づいて、信用の時点で依存者により選択される。
【発明の詳細な説明】
【関連出願】
【０００１】
本特許出願は、２００８年１月１８日に出願された「Ｂｉｎｄｉｎｇ ａ Ｄｉｇｉｔａｌ Ｃｅｒｔｉｆｉｃａｔｅ ｔｏ Ｍｕｌｔｉｐｌｅ Ｔｒｕｓｔ Ｄｏｍａｉｎｓ」と題する米国仮特許出願第６１／０１１，６６８号の利益を主張しており、この米国仮特許出願を参照することにより援用するものである。
【技術分野】
【０００２】
本発明は、公開鍵基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｅｒ）、デジタル証明書、及び公開鍵暗号の分野に関するものである。
【背景技術】
【０００３】
伝統的に、デジタル証明書は、統一されているものと推定される法的レジーム（ｒｅｇｉｍｅ）により統制された信頼ドメイン「サイロ（ｓｉｌｏ）」内で発行される。ポリシーマッピングの使用及びブリッジ認証局を介したこのような信頼ドメイン間の相互認証を伴う方法により、１つの信頼ドメインで発行された証明書が別の信頼ドメインにおいても信用することが可能となっている。
【０００４】
別の方法は、階層型の公開鍵基盤（ＰＫＩ）を設計するものである。階層型の公開鍵基盤では、下位認証局（「サブＣＡ」）がエンドエンティティ証明書を発行することを、ルート認証局（「ルートＣＡ」）が許可する。エンドエンティティ証明書は、ルートのサブＣＡにより許可された他の任意のエンドエンティティにより信頼され得る。階層型ＰＫＩの一実施形態は、アイデントラストシステム（ＩｄｅｎＴｒｕｓｔ Ｓｙｓｔｅｍ）であり、このアイデントラストシステムによれば、全てが統一された標準、ポリシー、手順及び規則の下で運用されるアイデントラストルートＣＡのサブＣＡのグローバルネットワークにより発行されるエンドエンティティ証明書を用いて、単一の統一された信頼ドメインが構成される。
【０００５】
本発明の動機付けは、アイデントラストシステム内で使用するために作成されたエンドエンティティ証明書が、そのシステムの外で別の信頼ドメインにおいても使用できるようにすることにあった。これについては、以下でより詳細に説明する。
【０００６】
ほとんどのＰＫＩシステムは、それらが、（１）デジタル署名の作成及び当該デジタル署名への信頼、並びに当該デジタル署名を認証するのに使用されるデジタル証明書の有効性を統制するローカルのパブリック法に依拠すること、（２）ソフトウェアの世界における「シュリンクラップライセンス」と同様に、依存者を、通常は証明書に埋め込まれたＵＲＬによって示されるウェブサイトに掲載された証明書ポリシー（「ＣＰ」）及び／又は認証局運用規定（「ＣＰＳ」）を介して、証明書を信用していることの事実により依存者が許容しているものとする、ローカル法の利用規約よりも実質的により特定の利用規約にバインドすること、及び、（３）任意のパブリックメンバーによって実行され得る証明書の検証方法に依拠すること、において、「オープン」なものである。このようなオープンシステムは、パブリックのローカル法に部分的に依拠しており、また、実際には契約でそれらに拘束されていない依存者に対するＣＰ又はＣＰＳの推定される強制力に部分的に依拠している。
【０００７】
アイデントラストシステムは、閉じた契約システムであり、同システムでは、全ての加入者及び依存者が、顧客同意書にバインドされている。顧客同意書は、その下でデジタル署名が作成され信頼されることに合意し、当該デジタル証明書が有効であることに合意する規則を契約により特定している。任意の特定の管轄区においてデジタル署名及びデジタル証明書の絶対的な認知を統制する法律のような、ローカルの外部的なパブリック法は、顧客同意書がローカルに強制力を有する限り、その閉じた契約システムに対しては無関係なものであると見られる。この顧客同意書は、証明書が新しい管轄区において提供されるときに法律的分析を通じて決定される。このシステムの証明書アーキテクチャーは、その契約構造を補強する。即ち、そのシステム内で発行される証明書を信用しようとする者は、信用しようとする当事者が関与者との顧客同意書にバインドされるだけで所有する秘密鍵を用いてデジタル署名された証明書検証要求への積極的な応答を受けた後にのみ、そのようなことを行うことができる。
【０００８】
このアイデントラストシステムは、階層型のＰＫＩであり、同システムでは、アイデントラストルートＣＡが、関与者金融機構に対して均一なポリシー、手順及び技術的仕様の使用許可を行い、当該機構を統一された規則にバインドし、それらの顧客同意書が統一された規約を含むことを要求する。アイデントラストルートＣＡは、関与者金融機関（各「関与者」）に対して証明書を発行し、ルートのサブＣＡは、関与者の顧客により使用される個々の証明書ホルダーに対してエンドエンティティ証明書を発行する。このシステムを通した規則及び手順の統一により、任意の関与者のサブＣＡにより発行された如何なる証明書も、関与者又は顧客が異なる法律により統制される異なる国にいるとしても、任意の他の関与者のサブＣＡにより発行された任意の他の証明書と同じように信用でき信頼できるものとなる。
【０００９】
しかしながら、ローカルの顧客は、あるローカルのポリシーレジームの下で発行された証明書を所有し又はそれを信用することを望むことが多い。例えば、ＥＵデジタル署名通達に遵守した欧州国家の法律の下で「認可された」証明書は、当該国において特定の目的のためには商業的に好ましいことが多い。このような証明書は、ＣＡにより生成され、当該ＣＡのウェブサイトにおいて掲載され、又は証明書において特定された配布ポイントを通してアクセスすることができる証明書失効リストを参照するように、公開された方法により検証されることが多い。従って、ＣＡが、アイデントラストシステムのような契約によるグローバルシステム内、及び、適用され得るローカルの法の下で当該システムの外部の双方で、使用可能な証明書を発行できることが有効である。このような二重の使用は、ある時点での信用においては閉じたアイデントラストシステムに対して内部的な使用と、別の時点での信用においては別の信頼ドメインの下での「外部的使用」との双方である。
【００１０】
特定の目的のために使用される証明書は、典型的には、ある指定された信頼ドメイン内で発行される。一導入態様では、例えば、特定の国家公務員へ発行される証明書は、その信頼ドメインに適用可能な証明書ポリシーの下で発行される必要があった。本発明を使用すれば、政府建物へのアクセス及び電子バンキング用の双方のような二重の目的で使用できるアイデントラスト証明書を公務員へ発行することができる。
【００１１】
ＰＫＩの運用、及びデジタル認証情報、リーダー及び関連するソフトウェア及びハードウエアの配布は、費用の掛かるものである。証明書が単一プラットフォームから単一トークンにて発行され、しかも、複数の信頼ドメインにて使用でき、又は、信用できるものとされることは、ＣＡにとっても、その加入者及び依存者にとっても非常に効果的である。これにより、基盤投資のコストが、信頼ドメインの全て及びそれら信頼ドメインの各々に特定なものであり得るアプリケーションに分散される。
【００１２】
従って、信用時点での依存者の選択で、異なる信頼ドメインにおける１つより多いポリシーレジーム（即ち、法的、規定又は契約構造）に対して、所与の証明書が代替的にバインドされるような方法を開発する必要が生じている。この方法は、任意の代替の信頼ドメインに対して一般化することができる。
【００１３】
任意の所定の信用の時点で、証明書に対してどの信頼ドメインがバインドされているかについて、全く疑いがないことが必須である。このようなドメインは、責任、償還請求、及び紛争解決を統制する種々な規則を有することが多く、任意の時点でのマルチドメイン証明書への信用をどの規則が統制するかについての曖昧さは、その信頼ドメインにおける証明書の相互運用性にとって致命的である。本発明は、信用の時点で依存者が信頼ドメインに固有の証明書検証メカニズムを使用し、それにより、関連付けられたポリシーレジームの選択を明示することを必要することにより、任意の所定の時点で１つ及び１つのみの信頼ドメインが１つの証明書にバインドされることを保証する。
【００１４】
従来技術において広く展開されている複数の信頼ドメインにおいて証明書を使用する代替的手段は、ブリッジの使用である。ブリッジは、島々を接続する公道のように、複数の信頼ドメインのサイロを接続しようとするものである。ブリッジは、他のＣＡへ「相互証明書」を発行し、当該ＣＡから対応する相互証明書を受け取る認証局を含み、１つの信頼ドメインにおける依存者が別の信頼ドメインにおけるＣＡにより発行された証明書を信用することができるようにする。従って、依存者がその信用点（トラストアンカー）としてＣＡ＃１を有しており、ＣＡ＃２により発行された証明書を信用することを望み、ブリッジＣＡがＣＡ＃１及びＣＡ＃２と相互証明書を交換している場合には、その信用点がＣＡ＃１である依存者は、ＣＡ＃２を代替の信用点として信用することができ、その逆の場合もある。証明書パス発見及び検証に依存するアーキテクチャーにおいては、相互証明書により、問題の依存者が、加入者の証明書（ＣＡ＃２により発行される）とその依存者の最終の信用点であるＣＡ＃１との間の証明書パスを発見することができる。相互認証処理は、通常、相互認証されるＣＡの各々の証明書ポリシーのブリッジＣＡのポリシーへの綿密な、従って、費用の掛かるマッピングを必要とし（それらが共通の標準を満足するかを決定するため）、特定の共通の理解を確立する各ＣＡとブリッジＣＡとの間の契約を必要とする。相互認証の問題点として、証明書を信用する機会が意図していない依存者にも及んでしまうというような「遷移的な信用」がある。例えば、Ｆｉｓｈｅｒ， Ｊａｍｅｓ Ｌ．による「Ｓｉｄｅ−Ｅｆｆｅｃｔｓ ｏｆ Ｃｒｏｓｓ−Ｃｅｒｔｉｆｉｃａｔｉｏｎ」、http://middleware.internet2.edu/pki05/proceedings/fisher-cross_cert.pdfを参照されたい。本発明によれば、ポリシーマッピング又は相互証明書を用いずに、単一の証明書を複数の信頼ドメインにおいて信用できるものとすることができ、且つ、閉じたシステムを、当該システムの外で同じマルチドメイン証明書を信用するか否かに関係なく、閉じたままとすることができる。
【発明の開示】
【００１５】
本発明は、デジタル証明書を発行する関与者を含む公開鍵基盤を含む。各デジタル証明書は、少なくとも２つの異なる信頼ドメインにおいて信用され得る。この公開鍵基盤は、信頼ドメイン間でのポリシーマッピングを使用しない。さらに、この公開鍵基盤は、如何なるペアの信頼ドメインも相互証明書を介してリンクしない。
【００１６】
本発明のこれらの目的、及び他のより詳細な目的、及び特定の目的及び特徴について、添付図面を参照して、以下により十分に説明する。
【図面の簡単な説明】
【００１７】
【図１Ａ】本発明に使用される典型的なデジタル証明書を示す図である。
【図１Ｂ】本発明に使用される典型的なデジタル証明書を示す図である。
【図１Ｃ】本発明に使用される典型的なデジタル証明書を示す図である。
【図２】本発明を実施するための第１の実施形態のシステムレベルの図である。
【図３】本発明を実施するための第２の実施形態のシステムレベルの図である。
【図４】本発明を実施するための第３の実施形態のシステムレベルの図である。
【発明を実施するための形態】
【００１８】
本発明は、次の要素からなる。
【００１９】
・２つの異なるポリシーレジーム
２つの信頼ドメインの何れかにおいて代替的に証明書を使用する。これらドメインの各々は、一方では、アイデントラスト規則のように独自のポリシーレジームを有し、他方では、特定の管轄区においてデジタル署名を認証するためのデジタル証明書の使用を統制するローカル包括法のような代替的レジームを有する。この代替的レジームは、別の閉じたシステムの規則と同じものであり得る。このようなレジームは、依存者の償還請求、ＣＡの潜在的責任、回復可能な損害の種類及び最大額、及び苦情の申し出の及び異議の解決のための手順、並びに、加入者を識別する手順、鍵及びトークンのセキュリティー等のような重要事項を統制する必須規則を含む。
【００２０】
・２つのポリシーＯＩＤ
エンドエンティティ証明書が代替的にバインドされる２つのポリシーレジームの各々は、それらのうちの１つを指すオブジェクト識別子（「ＯＩＤ」）によって一意に識別されなければならない。アイデントラストレジームの場合には、ＯＩＤは、適用可能な顧客同意書、参照によりそこに組み込まれる全ての文書、及び当該同意書がその下で施行されるパブリック法を含む。代替的レジームの場合には、ＯＩＤは、ＣＰ、ＣＰＳ、及び、その下でデジタル署名がローカルに強制力を有し且つデジタル証明書がローカルに有効であるパブリック法を含むことができる。
【００２１】
・相互運用できる証明書
アイデントラスト及び多くの他のＰＫＩは、Ｘ.５０９証明書を使用するが、このような証明書プロファイルの多くの実施形態がある。２つの信頼ドメインにより必要とされる個々のエンドエンティティ証明書プロファイルは、両者のプロファイルを実装する証明書が各ドメインにおいて正しく相互運用できるようなものでなければならず、このことは、アプリケーション又は検証ユーティリティによる証明書処理が、同一の証明書のために使用される２つの検証メカニズムのいずれにおいても失敗しないことを意味している。ポリシーオブジェクト識別子（「ＯＩＤ」）又は認証局情報アクセス（「ＡＩＡ」）拡張機能のような１つのデータ要素のみを慣例的に含む処理された証明書フィールドが、代替的証明書処理能力を可能とするため２つのこのような要素を含む場合には、全ての必要とされる代替的要素を失敗無く処理できるようにするために、それら証明書をテストし、証明書処理ソフトウェアを設定しなければならない。
【００２２】
・２つの異なる検証メカニズム
ある証明書が２つの異なる方法により検証されるときには、証明書処理ソフトウェアが、信用の特定のイベントに対して証明書検証処理のためのこのような方法の１つのみを選択するのに一意に依存者により指示されねばならない。重要なことは、各メカニズムによる検証が可能でなければならいが、どの特定のケースにおいても、それらの１つのみが選択され、使用されるということである。例えば、あるマルチドメイン証明書が、オンライン証明書状態プロトコル（「ＯＣＳＰ」）を介してなされる署名された検証要求を介して検証され、或いは、ＣＡにより発行された、公に掲載された証明書失効リスト（「ＣＲＬ」）を参照することにより検証される。各信頼ドメインに対して異なる検証メカニズムを使用することにより、どの証明書検証方法を使用するかを信用の時点で依存者が選択することで、証明書処理が成功することが保証される。証明書処理方法の依存者の選択は、信頼ドメインの選択、従って、信用のイベントを統制するためにどのポリシーレジーム及びどの規則を選択するかを示している。
【００２３】
・２つの発行者証明書
エンドエンティティ証明書の各々は、そのＣＡが証明書を発行した関与者を示す発行者名フィールドを含む。これら証明書の各々は、２つの発行者証明書に連結しており、各々、発行者名フィールドにおいて関与者のそれと同じ名を有し、各々がエンドエンティティ証明書に署名するためにＣＡにより使用されるプライベート証明書署名鍵に対応する同じ公開鍵を含んでいる。これら発行者証明書のうちの一方は、閉じたアイデントラストシステム内で使用され、他方は、代替的信頼ドメインにおける外部的使用のために使用される。このような発行者証明書は、共に、同じ公開鍵を含み、同じ秘密鍵により署名される。
【００２４】
・２つの信用点
ＣＲＬを使用する方法のように多くの証明書処理方法は、依存者の信用点と、信用される証明書を発行したＣＡの信用点との間の証明書パスを先ず見出し、次いで、当該パスにおいて証明書の各々を検証する処理に依存している。本発明の方法が双方のポリシーレジームに対するパス発見に依存するシステムにおいて使用される場合には、それらの各々のために、別々の信用点が必要である。
【００２５】
・代替的信頼ドメインのポリシーレジームにより生ずるリスクは、ＣＡにとって許容できるものでなければならない。
単に、ＣＡは、そのＣＡの主信頼ドメインに対して代替的であるポリシーレジームの下で証明書を発行するのに伴う如何なるリスクも許容しようとしなければならない。閉じた契約アイデントラストシステムの関与者の場合には、このことは、典型的には、依存者が依存者同意書に強制的にバインドされないというリスク、従って、官用車が代替的信頼ドメインのポリシーレジームに適用できる法の下で依存者に対する責任を強制的に制限することができないこともあるというリスクを許容することを意味している。
【００２６】
・上に概説した要素は、２つの異なる代替的信頼ドメインについて述べている。
２つより多い信頼ドメインにおいて相互運用可能な単一の証明書を発行することは、理論的には可能である。証明書処理の現在の実体（証明書フィールドにおける複数のＯＩＤ及びＡＩＡの処理を含む）及び単一の証明書での数個より多い信頼ドメインとすることに対する明白な実際的需要が現在では無いということからすれば、「両面コイン」を「ピンザテールオンザドンキー」ゲームに変えようとすることに対する反論があるであろう。アイデントラストシステムの１つの目的は、このアイデントラストシステムにおいてワールドワイドなアイデンティティ認証情報のための共通の相互運用可能な標準を作成することにより、「バベルの塔」のようなアイデンティティの必要を無くすることである。本発明によれば、その統一されたグローバルな閉じたシステム内で発行された認証情報が、依存者が置かれ得るローカルの法的レジームの下でローカルに信用されることを可能とする。
【００２７】
このような方法の３つの実施形態がこれまでに実施されている。これらについて、基本的方法として以下に説明し、それに加えて、２つの変形についても説明する。
【００２８】
本発明の一実施形態において、図１は、アイデントラストシステムの両信頼ドメインの下で相互運用可能なように構成されており、且つ欧州議会の及びその下で公布された電子署名（「電子署名通達」）規定及び国家実施法についての共同体フレームワークに関する１９９９年１２月の会議の通達１９９９／９３／ＥＣの信頼ドメインの下で「認可された証明書」に適用できる証明書プロファイルである。
【００２９】
本発明の方法によれば、図１のフィールド２．４．１は、２つのポリシーＯＩＤを特定しており、その一方のポリシーＯＩＤは、明確なものであり、他方は、記述によっている。最初のものは、一連の数により表されており、アイデントラスト関与者のアイデンティティ証明書ポリシーを識別するＯＩＤである。このＯＩＤは、アイデントラストシステム内の証明書の信用に適用可能なポリシーレジーム、即ち、適用可能な顧客同意書、その下で顧客同意書がそれを信用する顧客に対して強制される外部法、及びアイデントラストシステム内において証明書が信用されるときに証明書を検証するのに必要とされる方法を統制する仕様（顧客同意書へ参照により組み込まれている）の間のバランスを組み入れている。
【００３０】
フィールド２．４．１における残りの語、「プラス任意の銀行ｘｙｚポリシー識別子」は、そのＣＡが証明書を発行するアイデントラスト関与者によって証明書へ挿入される別のＯＩＤを記述しており、これは、証明書が他の信頼ドメインにおいて信用されるときに、その証明書を統制する代替的ポリシーレジーム、この場合においては、アイデントラストシステムの外での信用を統制する関与者のＣＰ及びＣＰＳ、及びそのローカルな国の適用できる法律及び規定を示している。
【００３１】
産業的実施に従って、アイデントラストは、潜在的依存者が注意すべき情報を特定するユーザーノーティスをその関与者がエンドエンティティ証明書に含ませることを要求している。それは、フィールド２．４．２．１に表されており、「この証明書は、（１）アイデントラスト関与者の依存顧客、又は（２）この証明書におけるどこかで特定される代替的ポリシーレジームにバインドされる当事者、のいずれかによってのみ信頼されることができる」と記述している。その第１の節は、アイデントラストシステム内の証明書の使用を統制しており、第２の節は、その句「この証明書におけるどこかで」の参照がフィールド２．４．１における句「任意の銀行ｘｙｚポリシー識別子」である代替的ポリシーレジームの下でのその使用を統制している。
【００３２】
アイデントラスト仕様は、デジタル署名を検証し又はシステム又は店舗へのアクセスを制御するように、アイデントラスト証明書を信用したい関与者の顧客が、アイデントラスト仕様に従って署名を検証し、証明書を検証することを必要としている。アイデントラスト仕様は、そのアイデントラストシステム内で証明書を使用するときに適用できる以下の特定の、必須の要件を含む。
１．署名は、その署名者のアイデントラスト証明書及び私有のアイデントラスト要件に従った依存顧客のソフトウェアを使用して検証されなければならい。
２．証明書は、私有のアイデントラスト要件に準拠したソフトウェアを用いて依存顧客によって生成された署名されたメッセージを介して検証されなければならず、ＯＣＳＰを介して関与者に暗号化形態で送信されなければならない。このＯＣＳＰを用いて、依存顧客は自信の証明書（検証要求時に依存顧客の署名を検証するのに使用される）を得ることを契約している。
３．ＯＣＳＰ検証要求及び応答のメッセージングフローは、ＩＥＴＦ ＲＦＣ３２８０に準拠しない私有のアイデントラスト要件に従って指令される。
【００３３】
本願により表される開示の目的で、必須な点は、証明書検証を統制するアイデントラスト仕様により必要とされる手順が非常に特定的であり、独特であるということである。これらは、依存者が、当該依存者の鍵ペアの全ての使用を統制するその顧客同意書にバインドされたアイデントラスト関与者の顧客でなければならないことを保証し、依存者が依存顧客であり、侵害者でないことを保証するように設計されている。アイデントラスト規則及び仕様により必要とされる形式での署名者のアイデントラスト証明書の検証は、その署名者が署名にバインドされるべきことが顧客同意書により契約で必要とされており、どのような他の方法による検証も、アイデントラストシステム内で使用することは認可されていないが、後者の必要条件が信用時に満足されるならば、代替的信頼ドメインの下で認可され、法律的に有効とされる。
【００３４】
アイデントラスト要件によれば、関与者は、「ハードコード化」ＩＰアドレス、又は、認証局情報アクセス「ＡＩＡ」拡張機能を介して、そのＯＣＳＰ応答者のアドレスを特定することができる。図１におけるフィールド２．７及びその次を参照されたい。フィールド２．７．１．１は、そのアクセス方法がＯＣＳＰを介しているべきことを特定しており、フィールド２．７．１．２は、ＵＲＬとしてその名を記載している。これらの２つのフィールドは、一緒になって、閉じたドアイデントラストシステム内で使用する証明書を発行した関与者のＣＡに対してＯＣＳＰ証明書検証要求を宛てる方法を一意に特定している。２．７．２の下のフィールドにおけるデータは、私有であり、現在では使用されておらず、これらフィールドは、アイデントラストトランザクションコーディネータとの通信を特定している。
【００３５】
フィールド２．８は、証明書の外部的使用を認めたい関与者が証明書失効リストのための配布ポイントのアドレスを入力するフィールドである。このＣＲＬは、他の信頼ドメインの代替的ポリシーレジーム、この場合には、システムの外での信用を統制する関与者のＣＰ及びＣＰＳ、及びそのローカルな国の適用可能な法律及び規定の下で、その証明書を信用したい依存者による当該署名書の検証のために使用される。
【００３６】
アイデントラスト規則は、アイデントラストシステム内でのみ使用されるよう意図された証明書におけるＣＲＬ配布ポイントの使用を禁止していることに留意することが重要である。これは、このような証明書が、アイデントラスト顧客同意書に拘束されたアイデントラスト鍵ペアを欠いている当事者がそれらの検証状態を得ないようにする、署名されたＯＣＳＰを介してのみ検証されることが許されているためである。
【００３７】
前述した２つの証明書検証メカニズムは、信用の時点で依存者によってなされるべき選択を表している。この実施形態では、検証がアイデントラスト規則の下で必要とされるように特定されたＡＩＡ拡張機能に対して、署名されたＯＣＳＰを介してなされる場合には、証明書は、その時点では、そのアイデントラストの信頼ドメインのポリシーレジームにバインドされる。検証がパブリックＣＲＬへの参照を介し、また、通常のパス発見及び検証を介してなされる場合には、証明書は、その時点では、代替的信頼ドメインのポリシーレジームにバインドされる。
【００３８】
２つの異なる信頼ドメインへ代替的にバインディングされるべき証明書は、それらの各々において正常に検証され得ることが重要である。代替的ドメインにおける検証が成功することを保証するためには、そのドメイン内の検証の成功に必要とされる要素及びステップの全てが可能でなければならない。従って、例えば、外部の信用点に対する証明書パス発見及びそれが掲載したＣＲＬに対するパス検証を必要とする信頼ドメインにおいては、外部の信用点がその検証パスの末端として作用することが必要であり、さもなければ検証は失敗する。
【００３９】
＜第１の実施形態： 自己署名された発行者証明書 （図２）＞
関与者のＣＡは、公開鍵に対応する証明書署名秘密鍵を所有する。アイデントラストシステム内の標準構成においては、アイデントラストルートＣＡは、その関与者の公開鍵を含み且つその関与者をサブジェクト名フィールドにおいて指定する発行者証明書を発行する。関与者のＣＡがエンドエンティティ証明書を発行する場合には、これら証明書は、それらの発行者名フィールドにおいて関与者を指定し、それらのサブジェクト名フィールドにおいて加入者を指定する（それぞれ、図１におけるフィールド１．４．２及び１．６．２を参照されたい）。このような証明書のための信用点は、アイデントラストルートＣＡ証明書である。前述したように、アイデントラストシステム内でこのようなエンドエンティティ証明書を信用したい当事者は、アイデントラスト関与者の顧客でなければならならず、当該顧客は、その関与者とのアイデントラスト顧客同意書にバインドされるだけで鍵ペアを所有し、署名するのにその秘密鍵を使用し、加入者の証明書を検証するため署名されたＯＣＳＰを介してその関与者へ送らなければならない証明書状態要求を認可するのにそれ自身のエンドエンティティ証明書を使用しなければならない。
【００４０】
第１の実施形態では、アイデントラスト加入者に対して発行されたエンドエンティティ証明書がアイデントラストシステムの外で、外部的使用のためにも使用される場合には、関与者のＣＡは、第２の「自己署名された」発行者証明書を自身に対して発行し、発行者及びサブジェクト名フィールドの双方において当該関与者を指定し、前の段落において説明した発行者証明書に含まれる同じ公開鍵を含める。関与者の秘密証明書署名鍵により署名されたエンドエンティティ証明書は、双方の発行者証明書において公開鍵により検証され得る。エンドエンティティ証明書を信用したい当事者がアイデントラスト顧客である場合には、それは、前の段落において説明した方法でその証明書を検証する。当事者がローカル法の下で与えられたもののような代替的ポリシーレジームの下で外部的使用を通じてエンドエンティティ証明書を信用したい場合には、それは、通常のパス発見及び検証を介して証明書を検証することができる。このような場合において、自己署名された発行者証明書は、信用点として作用し、依存者は、図１のフィールド２．８において特定されたＣＲＬ配布ポイントを参照することによるように、関与者のＣＡにより発行されたパブリックＣＲＬを参照することにより、加入者のエンドエンティティ証明書の有効性を決定することができる。
【００４１】
関与者のアイデントラスト顧客同意書は、依存者がアイデントラストシステム内で証明書を使用し、従って、信用の任意の所定の時点にて証明書を関与者のアイデントラストポリシーレジームにバインドしたい場合には、それが同意書により必要とされる方法にて、即ち、署名されたＯＣＳＰ検証要求を介してその証明書を検証しなければならないことを必要としている。証明書の外部的使用の場合には、このような使用を統制する関与者によって発行されたＣＰＳに特定されたもののように、適用可能なポリシーレジームが、どのような検証の方法が許容できるかを特定する。従って、証明書の検証の方法の依存者による選択は、信用の所定の時点で証明書にどのポリシーレジームがバインドされるかの選択を明示する。依存者がアイデントラスト関与者の顧客である場合には、従って、それは、いずれの手段でも同じ証明書を検証することが潜在的に可能であり、その選択は、証明書が、その時点で、アイデントラストグローバル規則又はローカル法の下で統制されるか否かを明示している。
【００４２】
＜第２の実施形態： 第２のルートＣＡ検証 （図３）＞
別の実施形態では、代替的信用ドメインは、階層型であり、それ自身のルートＣＡを有し得る。このような場合においては、関与者は、当該関与者の証明書署名秘密鍵に対応する公開鍵を含む証明書にて他のルートＣＡの署名を得る。このような形式では、外部的使用中のパス発見及び検証は、その代替的信頼ドメインの信用点、この場合においては、そのルートＣＡへと進められる。換言すると、このような構成においては、関与者は、加入者証明書に署名し検証するための共通の鍵ペアを共用するアイデントラストルートＣＡのサブＣＡと他のルートＣＡのサブＣＡとの両者であるＣＡを運用する。これら２つのサブＣＡは、それらの基盤の相当の部分を共用するように構成され、両者を運用するコストを実質的に削減することができる。
【００４３】
＜第３の実施形態： ブリッジへの接続 （図４）＞
更に別の実施形態では、代替的信頼ドメインは、ブリッジへ接続され得る。要するに、ブリッジＣＡは、一方の信頼ドメイン内の加入者が他方の信頼ドメイン内で発行された証明書を信用できるように、他のＣＡと相互証明書を交換する。第３の実施形態では、関与者の秘密鍵は、代替的信頼ドメインの自己署名された発行者証明書に対して検証され得るブリッジへ発行された相互証明書に署名する。必要な場合には、ブリッジは、関与者へ相互証明書を発行することもでき、関与者の加入者もブリッジを介してそれに接続された他のＣＡにより発行された証明書を信用することができるようにする。
【００４４】
本発明の方法は、証明書検証の任意の他の方法に対して一般化することができる。可能な変形のマトリックスを以下のように構成することができる。例えば：
・署名対非署名ＯＣＳＰ
・ＯＣＳＰ通信が、安全なＳＳＬセッションを介してなされるか、又はなされないか（https対http）
・ＳＳＬの場合に、使用される証明書は、低セキュリティー又は高セキュリティーか（アイデントラストルートＣＡに連結する関与者のＣＡにより発行されたアイデントラストユーティリティ証明書のように）
・異なるアドレスに対するＯＣＳＰ（ハードコード化ＩＰアドレスか、ＵＲＬ ＡＩＡか、又は複数の位置を有する単一ＡＩＡか）
・ＯＣＳＰ対ＳＣＶＰ（「簡易証明書検証プロトコル」）（又は任意の他のプロトコル）
・ＲＦＣ３２８０に準拠した検証及び準拠していない検証
・ＯＣＳＰ対パス発見及び検証
・異なる信用点に対するＲＦＣ３２８０の下でのパス発見及び検証以外のほとんど任意のもの（これは、２つの矛盾した検証パスを辿るもので、従って、検証方法の間の実際の依存者選択を明示するのに失敗するであろう）
【００４５】
これに加えて、この方法は、２つの信頼ドメインを区別する任意の手段に対しても更に一般化することができる。ポリシー識別子及び検証メカニズムを参照することによる信頼ドメイン間の区別に限定される必要はない。規則又は契約により、所与の発行者が１つ以上の特定されたフィールドのうちの任意のものにおいて代替的発行者名を有することができるか、又は、その存在により代替的ポリシーレジームに関連付けられる代替的証明書処理パスが作り出されるようにするフィールドを含むようにすることができる。
【００４６】
最後に、前述したように、単一エンドエンティティ証明書によりリンクされる代替的信頼ドメインは、２つに限定される必要はない。所定のエンドエンティティ証明書が信用される信頼ドメインの数に制限はない。唯一の制限は、使用できる証明書処理ソフトウェアが全ての変形を、信頼性をもって処理することができるかということである。
【００４７】
前述の説明は、好ましい実施形態の運用を例示するためになされたものであり、本発明の範囲を限定しようとしているものではない。本発明の範囲は、特許請求の範囲の記載によってのみ限定される。前述の説明からすれば、当業者には、本発明の精神及び範囲により包含され得るような更なる多くの変形例が明らかとなろう。
【関連出願】
【０００１】
本特許出願は、２００８年１月１８日に出願された「Ｂｉｎｄｉｎｇ ａ Ｄｉｇｉｔａｌ Ｃｅｒｔｉｆｉｃａｔｅ ｔｏ Ｍｕｌｔｉｐｌｅ Ｔｒｕｓｔ Ｄｏｍａｉｎｓ」と題する米国仮特許出願第６１／０１１，６６８号の利益を主張しており、この米国仮特許出願を参照することにより援用するものである。
【技術分野】
【０００２】
本発明は、公開鍵基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｅｒ）、デジタル証明書、及び公開鍵暗号の分野に関するものである。
【背景技術】
【０００３】
伝統的に、デジタル証明書は、統一されているものと推定される法的レジーム（ｒｅｇｉｍｅ）により統制された信頼ドメイン「サイロ（ｓｉｌｏ）」内で発行される。ポリシーマッピングの使用及びブリッジ認証局を介したこのような信頼ドメイン間の相互認証を伴う方法により、１つの信頼ドメインで発行された証明書が別の信頼ドメインにおいても信用することが可能となっている。
【０００４】
別の方法は、階層型の公開鍵基盤（ＰＫＩ）を設計するものである。階層型の公開鍵基盤では、下位認証局（「サブＣＡ」）がエンドエンティティ証明書を発行することを、ルート認証局（「ルートＣＡ」）が許可する。エンドエンティティ証明書は、ルートのサブＣＡにより許可された他の任意のエンドエンティティにより信頼され得る。階層型ＰＫＩの一実施形態は、アイデントラストシステム（ＩｄｅｎＴｒｕｓｔ Ｓｙｓｔｅｍ）であり、このアイデントラストシステムによれば、全てが統一された標準、ポリシー、手順及び規則の下で運用されるアイデントラストルートＣＡのサブＣＡのグローバルネットワークにより発行されるエンドエンティティ証明書を用いて、単一の統一された信頼ドメインが構成される。
【０００５】
本発明の動機付けは、アイデントラストシステム内で使用するために作成されたエンドエンティティ証明書が、そのシステムの外で別の信頼ドメインにおいても使用できるようにすることにあった。これについては、以下でより詳細に説明する。
【０００６】
ほとんどのＰＫＩシステムは、それらが、（１）デジタル署名の作成及び当該デジタル署名への信頼、並びに当該デジタル署名を認証するのに使用されるデジタル証明書の有効性を統制するローカルのパブリック法に依拠すること、（２）ソフトウェアの世界における「シュリンクラップライセンス」と同様に、依存者を、通常は証明書に埋め込まれたＵＲＬによって示されるウェブサイトに掲載された証明書ポリシー（「ＣＰ」）及び／又は認証局運用規定（「ＣＰＳ」）を介して、証明書を信用していることの事実により依存者が許容しているものとする、ローカル法の利用規約よりも実質的により特定の利用規約にバインドすること、及び、（３）任意のパブリックメンバーによって実行され得る証明書の検証方法に依拠すること、において、「オープン」なものである。このようなオープンシステムは、パブリックのローカル法に部分的に依拠しており、また、実際には契約でそれらに拘束されていない依存者に対するＣＰ又はＣＰＳの推定される強制力に部分的に依拠している。
【０００７】
アイデントラストシステムは、閉じた契約システムであり、同システムでは、全ての加入者及び依存者が、顧客同意書にバインドされている。顧客同意書は、その下でデジタル署名が作成され信頼されることに合意し、当該デジタル証明書が有効であることに合意する規則を契約により特定している。任意の特定の管轄区においてデジタル署名及びデジタル証明書の絶対的な認知を統制する法律のような、ローカルの外部的なパブリック法は、顧客同意書がローカルに強制力を有する限り、その閉じた契約システムに対しては無関係なものであると見られる。この顧客同意書は、証明書が新しい管轄区において提供されるときに法律的分析を通じて決定される。このシステムの証明書アーキテクチャーは、その契約構造を補強する。即ち、そのシステム内で発行される証明書を信用しようとする者は、信用しようとする当事者が関与者との顧客同意書にバインドされるだけで所有する秘密鍵を用いてデジタル署名された証明書検証要求への積極的な応答を受けた後にのみ、そのようなことを行うことができる。
【０００８】
このアイデントラストシステムは、階層型のＰＫＩであり、同システムでは、アイデントラストルートＣＡが、関与者金融機構に対して均一なポリシー、手順及び技術的仕様の使用許可を行い、当該機構を統一された規則にバインドし、それらの顧客同意書が統一された規約を含むことを要求する。アイデントラストルートＣＡは、関与者金融機関（各「関与者」）に対して証明書を発行し、ルートのサブＣＡは、関与者の顧客により使用される個々の証明書ホルダーに対してエンドエンティティ証明書を発行する。このシステムを通した規則及び手順の統一により、任意の関与者のサブＣＡにより発行された如何なる証明書も、関与者又は顧客が異なる法律により統制される異なる国にいるとしても、任意の他の関与者のサブＣＡにより発行された任意の他の証明書と同じように信用でき信頼できるものとなる。
【０００９】
しかしながら、ローカルの顧客は、あるローカルのポリシーレジームの下で発行された証明書を所有し又はそれを信用することを望むことが多い。例えば、ＥＵデジタル署名通達に遵守した欧州国家の法律の下で「認可された」証明書は、当該国において特定の目的のためには商業的に好ましいことが多い。このような証明書は、ＣＡにより生成され、当該ＣＡのウェブサイトにおいて掲載され、又は証明書において特定された配布ポイントを通してアクセスすることができる証明書失効リストを参照するように、公開された方法により検証されることが多い。従って、ＣＡが、アイデントラストシステムのような契約によるグローバルシステム内、及び、適用され得るローカルの法の下で当該システムの外部の双方で、使用可能な証明書を発行できることが有効である。このような二重の使用は、ある時点での信用においては閉じたアイデントラストシステムに対して内部的な使用と、別の時点での信用においては別の信頼ドメインの下での「外部的使用」との双方である。
【００１０】
特定の目的のために使用される証明書は、典型的には、ある指定された信頼ドメイン内で発行される。一導入態様では、例えば、特定の国家公務員へ発行される証明書は、その信頼ドメインに適用可能な証明書ポリシーの下で発行される必要があった。本発明を使用すれば、政府建物へのアクセス及び電子バンキング用の双方のような二重の目的で使用できるアイデントラスト証明書を公務員へ発行することができる。
【００１１】
ＰＫＩの運用、及びデジタル認証情報、リーダー及び関連するソフトウェア及びハードウエアの配布は、費用の掛かるものである。証明書が単一プラットフォームから単一トークンにて発行され、しかも、複数の信頼ドメインにて使用でき、又は、信用できるものとされることは、ＣＡにとっても、その加入者及び依存者にとっても非常に効果的である。これにより、基盤投資のコストが、信頼ドメインの全て及びそれら信頼ドメインの各々に特定なものであり得るアプリケーションに分散される。
【００１２】
従って、信用時点での依存者の選択で、異なる信頼ドメインにおける１つより多いポリシーレジーム（即ち、法的、規定又は契約構造）に対して、所与の証明書が代替的にバインドされるような方法を開発する必要が生じている。この方法は、任意の代替の信頼ドメインに対して一般化することができる。
【００１３】
任意の所定の信用の時点で、証明書に対してどの信頼ドメインがバインドされているかについて、全く疑いがないことが必須である。このようなドメインは、責任、償還請求、及び紛争解決を統制する種々な規則を有することが多く、任意の時点でのマルチドメイン証明書への信用をどの規則が統制するかについての曖昧さは、その信頼ドメインにおける証明書の相互運用性にとって致命的である。本発明は、信用の時点で依存者が信頼ドメインに固有の証明書検証メカニズムを使用し、それにより、関連付けられたポリシーレジームの選択を明示することを必要することにより、任意の所定の時点で１つ及び１つのみの信頼ドメインが１つの証明書にバインドされることを保証する。
【００１４】
従来技術において広く展開されている複数の信頼ドメインにおいて証明書を使用する代替的手段は、ブリッジの使用である。ブリッジは、島々を接続する公道のように、複数の信頼ドメインのサイロを接続しようとするものである。ブリッジは、他のＣＡへ「相互証明書」を発行し、当該ＣＡから対応する相互証明書を受け取る認証局を含み、１つの信頼ドメインにおける依存者が別の信頼ドメインにおけるＣＡにより発行された証明書を信用することができるようにする。従って、依存者がその信用点（トラストアンカー）としてＣＡ＃１を有しており、ＣＡ＃２により発行された証明書を信用することを望み、ブリッジＣＡがＣＡ＃１及びＣＡ＃２と相互証明書を交換している場合には、その信用点がＣＡ＃１である依存者は、ＣＡ＃２を代替の信用点として信用することができ、その逆の場合もある。証明書パス発見及び検証に依存するアーキテクチャーにおいては、相互証明書により、問題の依存者が、加入者の証明書（ＣＡ＃２により発行される）とその依存者の最終の信用点であるＣＡ＃１との間の証明書パスを発見することができる。相互認証処理は、通常、相互認証されるＣＡの各々の証明書ポリシーのブリッジＣＡのポリシーへの綿密な、従って、費用の掛かるマッピングを必要とし（それらが共通の標準を満足するかを決定するため）、特定の共通の理解を確立する各ＣＡとブリッジＣＡとの間の契約を必要とする。相互認証の問題点として、証明書を信用する機会が意図していない依存者にも及んでしまうというような「遷移的な信用」がある。例えば、Ｆｉｓｈｅｒ， Ｊａｍｅｓ Ｌ．による「Ｓｉｄｅ−Ｅｆｆｅｃｔｓ ｏｆ Ｃｒｏｓｓ−Ｃｅｒｔｉｆｉｃａｔｉｏｎ」、http://middleware.internet2.edu/pki05/proceedings/fisher-cross_cert.pdfを参照されたい。本発明によれば、ポリシーマッピング又は相互証明書を用いずに、単一の証明書を複数の信頼ドメインにおいて信用できるものとすることができ、且つ、閉じたシステムを、当該システムの外で同じマルチドメイン証明書を信用するか否かに関係なく、閉じたままとすることができる。
【発明の開示】
【００１５】
本発明は、デジタル証明書を発行する関与者を含む公開鍵基盤を含む。各デジタル証明書は、少なくとも２つの異なる信頼ドメインにおいて信用され得る。この公開鍵基盤は、信頼ドメイン間でのポリシーマッピングを使用しない。さらに、この公開鍵基盤は、如何なるペアの信頼ドメインも相互証明書を介してリンクしない。
【００１６】
本発明のこれらの目的、及び他のより詳細な目的、及び特定の目的及び特徴について、添付図面を参照して、以下により十分に説明する。
【図面の簡単な説明】
【００１７】
【図１Ａ】本発明に使用される典型的なデジタル証明書を示す図である。
【図１Ｂ】本発明に使用される典型的なデジタル証明書を示す図である。
【図１Ｃ】本発明に使用される典型的なデジタル証明書を示す図である。
【図２】本発明を実施するための第１の実施形態のシステムレベルの図である。
【図３】本発明を実施するための第２の実施形態のシステムレベルの図である。
【図４】本発明を実施するための第３の実施形態のシステムレベルの図である。
【発明を実施するための形態】
【００１８】
本発明は、次の要素からなる。
【００１９】
・２つの異なるポリシーレジーム
２つの信頼ドメインの何れかにおいて代替的に証明書を使用する。これらドメインの各々は、一方では、アイデントラスト規則のように独自のポリシーレジームを有し、他方では、特定の管轄区においてデジタル署名を認証するためのデジタル証明書の使用を統制するローカル包括法のような代替的レジームを有する。この代替的レジームは、別の閉じたシステムの規則と同じものであり得る。このようなレジームは、依存者の償還請求、ＣＡの潜在的責任、回復可能な損害の種類及び最大額、及び苦情の申し出の及び異議の解決のための手順、並びに、加入者を識別する手順、鍵及びトークンのセキュリティー等のような重要事項を統制する必須規則を含む。
【００２０】
・２つのポリシーＯＩＤ
エンドエンティティ証明書が代替的にバインドされる２つのポリシーレジームの各々は、それらのうちの１つを指すオブジェクト識別子（「ＯＩＤ」）によって一意に識別されなければならない。アイデントラストレジームの場合には、ＯＩＤは、適用可能な顧客同意書、参照によりそこに組み込まれる全ての文書、及び当該同意書がその下で施行されるパブリック法を含む。代替的レジームの場合には、ＯＩＤは、ＣＰ、ＣＰＳ、及び、その下でデジタル署名がローカルに強制力を有し且つデジタル証明書がローカルに有効であるパブリック法を含むことができる。
【００２１】
・相互運用できる証明書
アイデントラスト及び多くの他のＰＫＩは、Ｘ.５０９証明書を使用するが、このような証明書プロファイルの多くの実施形態がある。２つの信頼ドメインにより必要とされる個々のエンドエンティティ証明書プロファイルは、両者のプロファイルを実装する証明書が各ドメインにおいて正しく相互運用できるようなものでなければならず、このことは、アプリケーション又は検証ユーティリティによる証明書処理が、同一の証明書のために使用される２つの検証メカニズムのいずれにおいても失敗しないことを意味している。ポリシーオブジェクト識別子（「ＯＩＤ」）又は認証局情報アクセス（「ＡＩＡ」）拡張機能のような１つのデータ要素のみを慣例的に含む処理された証明書フィールドが、代替的証明書処理能力を可能とするため２つのこのような要素を含む場合には、全ての必要とされる代替的要素を失敗無く処理できるようにするために、それら証明書をテストし、証明書処理ソフトウェアを設定しなければならない。
【００２２】
・２つの異なる検証メカニズム
ある証明書が２つの異なる方法により検証されるときには、証明書処理ソフトウェアが、信用の特定のイベントに対して証明書検証処理のためのこのような方法の１つのみを選択するのに一意に依存者により指示されねばならない。重要なことは、各メカニズムによる検証が可能でなければならいが、どの特定のケースにおいても、それらの１つのみが選択され、使用されるということである。例えば、あるマルチドメイン証明書が、オンライン証明書状態プロトコル（「ＯＣＳＰ」）を介してなされる署名された検証要求を介して検証され、或いは、ＣＡにより発行された、公に掲載された証明書失効リスト（「ＣＲＬ」）を参照することにより検証される。各信頼ドメインに対して異なる検証メカニズムを使用することにより、どの証明書検証方法を使用するかを信用の時点で依存者が選択することで、証明書処理が成功することが保証される。証明書処理方法の依存者の選択は、信頼ドメインの選択、従って、信用のイベントを統制するためにどのポリシーレジーム及びどの規則を選択するかを示している。
【００２３】
・２つの発行者証明書
エンドエンティティ証明書の各々は、そのＣＡが証明書を発行した関与者を示す発行者名フィールドを含む。これら証明書の各々は、２つの発行者証明書に連結しており、各々、発行者名フィールドにおいて関与者のそれと同じ名を有し、各々がエンドエンティティ証明書に署名するためにＣＡにより使用されるプライベート証明書署名鍵に対応する同じ公開鍵を含んでいる。これら発行者証明書のうちの一方は、閉じたアイデントラストシステム内で使用され、他方は、代替的信頼ドメインにおける外部的使用のために使用される。このような発行者証明書は、共に、同じ公開鍵を含み、同じ秘密鍵により署名される。
【００２４】
・２つの信用点
ＣＲＬを使用する方法のように多くの証明書処理方法は、依存者の信用点と、信用される証明書を発行したＣＡの信用点との間の証明書パスを先ず見出し、次いで、当該パスにおいて証明書の各々を検証する処理に依存している。本発明の方法が双方のポリシーレジームに対するパス発見に依存するシステムにおいて使用される場合には、それらの各々のために、別々の信用点が必要である。
【００２５】
・代替的信頼ドメインのポリシーレジームにより生ずるリスクは、ＣＡにとって許容できるものでなければならない。
単に、ＣＡは、そのＣＡの主信頼ドメインに対して代替的であるポリシーレジームの下で証明書を発行するのに伴う如何なるリスクも許容しようとしなければならない。閉じた契約アイデントラストシステムの関与者の場合には、このことは、典型的には、依存者が依存者同意書に強制的にバインドされないというリスク、従って、官用車が代替的信頼ドメインのポリシーレジームに適用できる法の下で依存者に対する責任を強制的に制限することができないこともあるというリスクを許容することを意味している。
【００２６】
・上に概説した要素は、２つの異なる代替的信頼ドメインについて述べている。
２つより多い信頼ドメインにおいて相互運用可能な単一の証明書を発行することは、理論的には可能である。証明書処理の現在の実体（証明書フィールドにおける複数のＯＩＤ及びＡＩＡの処理を含む）及び単一の証明書での数個より多い信頼ドメインとすることに対する明白な実際的需要が現在では無いということからすれば、「両面コイン」を「ピンザテールオンザドンキー」ゲームに変えようとすることに対する反論があるであろう。アイデントラストシステムの１つの目的は、このアイデントラストシステムにおいてワールドワイドなアイデンティティ認証情報のための共通の相互運用可能な標準を作成することにより、「バベルの塔」のようなアイデンティティの必要を無くすることである。本発明によれば、その統一されたグローバルな閉じたシステム内で発行された認証情報が、依存者が置かれ得るローカルの法的レジームの下でローカルに信用されることを可能とする。
【００２７】
このような方法の３つの実施形態がこれまでに実施されている。これらについて、基本的方法として以下に説明し、それに加えて、２つの変形についても説明する。
【００２８】
本発明の一実施形態において、図１は、アイデントラストシステムの両信頼ドメインの下で相互運用可能なように構成されており、且つ欧州議会の及びその下で公布された電子署名（「電子署名通達」）規定及び国家実施法についての共同体フレームワークに関する１９９９年１２月の会議の通達１９９９／９３／ＥＣの信頼ドメインの下で「認可された証明書」に適用できる証明書プロファイルである。
【００２９】
本発明の方法によれば、図１のフィールド２．４．１は、２つのポリシーＯＩＤを特定しており、その一方のポリシーＯＩＤは、明確なものであり、他方は、記述によっている。最初のものは、一連の数により表されており、アイデントラスト関与者のアイデンティティ証明書ポリシーを識別するＯＩＤである。このＯＩＤは、アイデントラストシステム内の証明書の信用に適用可能なポリシーレジーム、即ち、適用可能な顧客同意書、その下で顧客同意書がそれを信用する顧客に対して強制される外部法、及びアイデントラストシステム内において証明書が信用されるときに証明書を検証するのに必要とされる方法を統制する仕様（顧客同意書へ参照により組み込まれている）の間のバランスを組み入れている。
【００３０】
フィールド２．４．１における残りの語、「プラス任意の銀行ｘｙｚポリシー識別子」は、そのＣＡが証明書を発行するアイデントラスト関与者によって証明書へ挿入される別のＯＩＤを記述しており、これは、証明書が他の信頼ドメインにおいて信用されるときに、その証明書を統制する代替的ポリシーレジーム、この場合においては、アイデントラストシステムの外での信用を統制する関与者のＣＰ及びＣＰＳ、及びそのローカルな国の適用できる法律及び規定を示している。
【００３１】
産業的実施に従って、アイデントラストは、潜在的依存者が注意すべき情報を特定するユーザーノーティスをその関与者がエンドエンティティ証明書に含ませることを要求している。それは、フィールド２．４．２．１に表されており、「この証明書は、（１）アイデントラスト関与者の依存顧客、又は（２）この証明書におけるどこかで特定される代替的ポリシーレジームにバインドされる当事者、のいずれかによってのみ信頼されることができる」と記述している。その第１の節は、アイデントラストシステム内の証明書の使用を統制しており、第２の節は、その句「この証明書におけるどこかで」の参照がフィールド２．４．１における句「任意の銀行ｘｙｚポリシー識別子」である代替的ポリシーレジームの下でのその使用を統制している。
【００３２】
アイデントラスト仕様は、デジタル署名を検証し又はシステム又は店舗へのアクセスを制御するように、アイデントラスト証明書を信用したい関与者の顧客が、アイデントラスト仕様に従って署名を検証し、証明書を検証することを必要としている。アイデントラスト仕様は、そのアイデントラストシステム内で証明書を使用するときに適用できる以下の特定の、必須の要件を含む。
１．署名は、その署名者のアイデントラスト証明書及び私有のアイデントラスト要件に従った依存顧客のソフトウェアを使用して検証されなければならい。
２．証明書は、私有のアイデントラスト要件に準拠したソフトウェアを用いて依存顧客によって生成された署名されたメッセージを介して検証されなければならず、ＯＣＳＰを介して関与者に暗号化形態で送信されなければならない。このＯＣＳＰを用いて、依存顧客は自信の証明書（検証要求時に依存顧客の署名を検証するのに使用される）を得ることを契約している。
３．ＯＣＳＰ検証要求及び応答のメッセージングフローは、ＩＥＴＦ ＲＦＣ３２８０に準拠しない私有のアイデントラスト要件に従って指令される。
【００３３】
本願により表される開示の目的で、必須な点は、証明書検証を統制するアイデントラスト仕様により必要とされる手順が非常に特定的であり、独特であるということである。これらは、依存者が、当該依存者の鍵ペアの全ての使用を統制するその顧客同意書にバインドされたアイデントラスト関与者の顧客でなければならないことを保証し、依存者が依存顧客であり、侵害者でないことを保証するように設計されている。アイデントラスト規則及び仕様により必要とされる形式での署名者のアイデントラスト証明書の検証は、その署名者が署名にバインドされるべきことが顧客同意書により契約で必要とされており、どのような他の方法による検証も、アイデントラストシステム内で使用することは認可されていないが、後者の必要条件が信用時に満足されるならば、代替的信頼ドメインの下で認可され、法律的に有効とされる。
【００３４】
アイデントラスト要件によれば、関与者は、「ハードコード化」ＩＰアドレス、又は、認証局情報アクセス「ＡＩＡ」拡張機能を介して、そのＯＣＳＰ応答者のアドレスを特定することができる。図１におけるフィールド２．７及びその次を参照されたい。フィールド２．７．１．１は、そのアクセス方法がＯＣＳＰを介しているべきことを特定しており、フィールド２．７．１．２は、ＵＲＬとしてその名を記載している。これらの２つのフィールドは、一緒になって、閉じたドアイデントラストシステム内で使用する証明書を発行した関与者のＣＡに対してＯＣＳＰ証明書検証要求を宛てる方法を一意に特定している。２．７．２の下のフィールドにおけるデータは、私有であり、現在では使用されておらず、これらフィールドは、アイデントラストトランザクションコーディネータとの通信を特定している。
【００３５】
フィールド２．８は、証明書の外部的使用を認めたい関与者が証明書失効リストのための配布ポイントのアドレスを入力するフィールドである。このＣＲＬは、他の信頼ドメインの代替的ポリシーレジーム、この場合には、システムの外での信用を統制する関与者のＣＰ及びＣＰＳ、及びそのローカルな国の適用可能な法律及び規定の下で、その証明書を信用したい依存者による当該署名書の検証のために使用される。
【００３６】
アイデントラスト規則は、アイデントラストシステム内でのみ使用されるよう意図された証明書におけるＣＲＬ配布ポイントの使用を禁止していることに留意することが重要である。これは、このような証明書が、アイデントラスト顧客同意書に拘束されたアイデントラスト鍵ペアを欠いている当事者がそれらの検証状態を得ないようにする、署名されたＯＣＳＰを介してのみ検証されることが許されているためである。
【００３７】
前述した２つの証明書検証メカニズムは、信用の時点で依存者によってなされるべき選択を表している。この実施形態では、検証がアイデントラスト規則の下で必要とされるように特定されたＡＩＡ拡張機能に対して、署名されたＯＣＳＰを介してなされる場合には、証明書は、その時点では、そのアイデントラストの信頼ドメインのポリシーレジームにバインドされる。検証がパブリックＣＲＬへの参照を介し、また、通常のパス発見及び検証を介してなされる場合には、証明書は、その時点では、代替的信頼ドメインのポリシーレジームにバインドされる。
【００３８】
２つの異なる信頼ドメインへ代替的にバインディングされるべき証明書は、それらの各々において正常に検証され得ることが重要である。代替的ドメインにおける検証が成功することを保証するためには、そのドメイン内の検証の成功に必要とされる要素及びステップの全てが可能でなければならない。従って、例えば、外部の信用点に対する証明書パス発見及びそれが掲載したＣＲＬに対するパス検証を必要とする信頼ドメインにおいては、外部の信用点がその検証パスの末端として作用することが必要であり、さもなければ検証は失敗する。
【００３９】
＜第１の実施形態： 自己署名された発行者証明書 （図２）＞
関与者のＣＡは、公開鍵に対応する証明書署名秘密鍵を所有する。アイデントラストシステム内の標準構成においては、アイデントラストルートＣＡは、その関与者の公開鍵を含み且つその関与者をサブジェクト名フィールドにおいて指定する発行者証明書を発行する。関与者のＣＡがエンドエンティティ証明書を発行する場合には、これら証明書は、それらの発行者名フィールドにおいて関与者を指定し、それらのサブジェクト名フィールドにおいて加入者を指定する（それぞれ、図１におけるフィールド１．４．２及び１．６．２を参照されたい）。このような証明書のための信用点は、アイデントラストルートＣＡ証明書である。前述したように、アイデントラストシステム内でこのようなエンドエンティティ証明書を信用したい当事者は、アイデントラスト関与者の顧客でなければならならず、当該顧客は、その関与者とのアイデントラスト顧客同意書にバインドされるだけで鍵ペアを所有し、署名するのにその秘密鍵を使用し、加入者の証明書を検証するため署名されたＯＣＳＰを介してその関与者へ送らなければならない証明書状態要求を認可するのにそれ自身のエンドエンティティ証明書を使用しなければならない。
【００４０】
第１の実施形態では、アイデントラスト加入者に対して発行されたエンドエンティティ証明書がアイデントラストシステムの外で、外部的使用のためにも使用される場合には、関与者のＣＡは、第２の「自己署名された」発行者証明書を自身に対して発行し、発行者及びサブジェクト名フィールドの双方において当該関与者を指定し、前の段落において説明した発行者証明書に含まれる同じ公開鍵を含める。関与者の秘密証明書署名鍵により署名されたエンドエンティティ証明書は、双方の発行者証明書において公開鍵により検証され得る。エンドエンティティ証明書を信用したい当事者がアイデントラスト顧客である場合には、それは、前の段落において説明した方法でその証明書を検証する。当事者がローカル法の下で与えられたもののような代替的ポリシーレジームの下で外部的使用を通じてエンドエンティティ証明書を信用したい場合には、それは、通常のパス発見及び検証を介して証明書を検証することができる。このような場合において、自己署名された発行者証明書は、信用点として作用し、依存者は、図１のフィールド２．８において特定されたＣＲＬ配布ポイントを参照することによるように、関与者のＣＡにより発行されたパブリックＣＲＬを参照することにより、加入者のエンドエンティティ証明書の有効性を決定することができる。
【００４１】
関与者のアイデントラスト顧客同意書は、依存者がアイデントラストシステム内で証明書を使用し、従って、信用の任意の所定の時点にて証明書を関与者のアイデントラストポリシーレジームにバインドしたい場合には、それが同意書により必要とされる方法にて、即ち、署名されたＯＣＳＰ検証要求を介してその証明書を検証しなければならないことを必要としている。証明書の外部的使用の場合には、このような使用を統制する関与者によって発行されたＣＰＳに特定されたもののように、適用可能なポリシーレジームが、どのような検証の方法が許容できるかを特定する。従って、証明書の検証の方法の依存者による選択は、信用の所定の時点で証明書にどのポリシーレジームがバインドされるかの選択を明示する。依存者がアイデントラスト関与者の顧客である場合には、従って、それは、いずれの手段でも同じ証明書を検証することが潜在的に可能であり、その選択は、証明書が、その時点で、アイデントラストグローバル規則又はローカル法の下で統制されるか否かを明示している。
【００４２】
＜第２の実施形態： 第２のルートＣＡ検証 （図３）＞
別の実施形態では、代替的信用ドメインは、階層型であり、それ自身のルートＣＡを有し得る。このような場合においては、関与者は、当該関与者の証明書署名秘密鍵に対応する公開鍵を含む証明書にて他のルートＣＡの署名を得る。このような形式では、外部的使用中のパス発見及び検証は、その代替的信頼ドメインの信用点、この場合においては、そのルートＣＡへと進められる。換言すると、このような構成においては、関与者は、加入者証明書に署名し検証するための共通の鍵ペアを共用するアイデントラストルートＣＡのサブＣＡと他のルートＣＡのサブＣＡとの両者であるＣＡを運用する。これら２つのサブＣＡは、それらの基盤の相当の部分を共用するように構成され、両者を運用するコストを実質的に削減することができる。
【００４３】
＜第３の実施形態： ブリッジへの接続 （図４）＞
更に別の実施形態では、代替的信頼ドメインは、ブリッジへ接続され得る。要するに、ブリッジＣＡは、一方の信頼ドメイン内の加入者が他方の信頼ドメイン内で発行された証明書を信用できるように、他のＣＡと相互証明書を交換する。第３の実施形態では、関与者の秘密鍵は、代替的信頼ドメインの自己署名された発行者証明書に対して検証され得るブリッジへ発行された相互証明書に署名する。必要な場合には、ブリッジは、関与者へ相互証明書を発行することもでき、関与者の加入者もブリッジを介してそれに接続された他のＣＡにより発行された証明書を信用することができるようにする。
【００４４】
本発明の方法は、証明書検証の任意の他の方法に対して一般化することができる。可能な変形のマトリックスを以下のように構成することができる。例えば：
・署名対非署名ＯＣＳＰ
・ＯＣＳＰ通信が、安全なＳＳＬセッションを介してなされるか、又はなされないか（https対http）
・ＳＳＬの場合に、使用される証明書は、低セキュリティー又は高セキュリティーか（アイデントラストルートＣＡに連結する関与者のＣＡにより発行されたアイデントラストユーティリティ証明書のように）
・異なるアドレスに対するＯＣＳＰ（ハードコード化ＩＰアドレスか、ＵＲＬ ＡＩＡか、又は複数の位置を有する単一ＡＩＡか）
・ＯＣＳＰ対ＳＣＶＰ（「簡易証明書検証プロトコル」）（又は任意の他のプロトコル）
・ＲＦＣ３２８０に準拠した検証及び準拠していない検証
・ＯＣＳＰ対パス発見及び検証
・異なる信用点に対するＲＦＣ３２８０の下でのパス発見及び検証以外のほとんど任意のもの（これは、２つの矛盾した検証パスを辿るもので、従って、検証方法の間の実際の依存者選択を明示するのに失敗するであろう）
【００４５】
これに加えて、この方法は、２つの信頼ドメインを区別する任意の手段に対しても更に一般化することができる。ポリシー識別子及び検証メカニズムを参照することによる信頼ドメイン間の区別に限定される必要はない。規則又は契約により、所与の発行者が１つ以上の特定されたフィールドのうちの任意のものにおいて代替的発行者名を有することができるか、又は、その存在により代替的ポリシーレジームに関連付けられる代替的証明書処理パスが作り出されるようにするフィールドを含むようにすることができる。
【００４６】
最後に、前述したように、単一エンドエンティティ証明書によりリンクされる代替的信頼ドメインは、２つに限定される必要はない。所定のエンドエンティティ証明書が信用される信頼ドメインの数に制限はない。唯一の制限は、使用できる証明書処理ソフトウェアが全ての変形を、信頼性をもって処理することができるかということである。
【００４７】
前述の説明は、好ましい実施形態の運用を例示するためになされたものであり、本発明の範囲を限定しようとしているものではない。本発明の範囲は、特許請求の範囲の記載によってのみ限定される。前述の説明からすれば、当業者には、本発明の精神及び範囲により包含され得るような更なる多くの変形例が明らかとなろう。
【特許請求の範囲】
【請求項１】
少なくとも２つの異なる信頼ドメインにおいて信用され得るデジタル証明書を発行する関与者を含む公開鍵基盤であって、
該公開鍵基盤は、前記信頼ドメイン間でポリシーマッピングを使用せず、
該公開鍵基盤は、信頼ドメインの如何なる対も相互証明書を介してリンクしない、
公開鍵基盤。
【請求項２】
少なくとも１つの信頼ドメインが、閉じた契約ドメインである、請求項１に記載の公開鍵基盤。
【請求項３】
少なくとも１つの信頼ドメインが、オープン信頼ドメインである、請求項１に記載の公開鍵基盤。
【請求項４】
前記デジタル証明書は、欧州デジタル署名通達に従った欧州の国の法律の下で認可されたものである、請求項３に記載の公開鍵基盤。
【請求項５】
１つの信頼ドメインのみが、任意の所定の時点で前記デジタル証明書にバインドされる、請求項１に記載の公開鍵基盤。
【請求項６】
前記デジタル証明書は、依存者により信用され、
前記デジタル証明書にバインドされる現在の信頼ドメインが、前記依存者により選択された特定の証明書検証方法に基づいて、信用の時点で前記依存者により選択される、
請求項１に記載の公開鍵基盤。
【請求項７】
前記証明書検証方法は、
オンライン証明書状態プロトコルを介してなされる署名された検証要求、及び
公に掲載された証明書失効リストであって前記関与者により発行された証明書失効リストの参照、
からなる方法の群からの方法である、請求項６に記載の公開鍵基盤。
【請求項８】
異なる信頼ドメインが、責任、償還請求、及び紛争解決を統制する異なる規則を有する、請求項１に記載の公開鍵基盤。
【請求項９】
各信頼ドメインが、オブジェクト識別子により一意に識別されるポリシーを含む、請求項１に記載の公開鍵基盤。
【請求項１０】
各オブジェクト識別子は、
顧客同意書、
顧客同意書において参照により組み込まれる文書、
その下でポリシーが施行されるパブリック法、
証明書ポリシー、
認証局運用規定、
その下でデジタル署名がローカルに強制力をもち且つデジタル証明書がローカルに有効とされるパブリック法、
のうちの少なくとも１つを含む、請求項９に記載の公開鍵基盤。
【請求項１１】
第１の信頼ドメインが、前記関与者へ発行されたルートデジタル証明書により信頼点となり、第２の信頼ドメインが、前記関与者の認証局により自己署名されたデジタル証明書により信頼点となる、請求項１に記載の公開鍵基盤。
【請求項１２】
第１の信頼ドメインが、第１のルート認証局により前記関与者へ発行される第１のデジタル証明書により信用点となり、第２の信頼ドメインが、第２のルート認証局により前記関与者へ発行される第２のデジタル証明書により信用点となる、請求項１に記載の公開鍵基盤。
【請求項１３】
第１の信頼ドメインが、第１のルート認証局により前記関与者へ発行された第１のデジタル証明書により信用点となり、第２の信頼ドメインが、ブリッジ認証局デジタル証明書により前記関与者へ結合される第２のデジタル証明書により信用点となる、請求項１に記載の公開鍵基盤。
【請求項１】
少なくとも２つの異なる信頼ドメインにおいて信用され得るデジタル証明書を発行する関与者を含む公開鍵基盤であって、
該公開鍵基盤は、前記信頼ドメイン間でポリシーマッピングを使用せず、
該公開鍵基盤は、信頼ドメインの如何なる対も相互証明書を介してリンクしない、
公開鍵基盤。
【請求項２】
少なくとも１つの信頼ドメインが、閉じた契約ドメインである、請求項１に記載の公開鍵基盤。
【請求項３】
少なくとも１つの信頼ドメインが、オープン信頼ドメインである、請求項１に記載の公開鍵基盤。
【請求項４】
前記デジタル証明書は、欧州デジタル署名通達に従った欧州の国の法律の下で認可されたものである、請求項３に記載の公開鍵基盤。
【請求項５】
１つの信頼ドメインのみが、任意の所定の時点で前記デジタル証明書にバインドされる、請求項１に記載の公開鍵基盤。
【請求項６】
前記デジタル証明書は、依存者により信用され、
前記デジタル証明書にバインドされる現在の信頼ドメインが、前記依存者により選択された特定の証明書検証方法に基づいて、信用の時点で前記依存者により選択される、
請求項１に記載の公開鍵基盤。
【請求項７】
前記証明書検証方法は、
オンライン証明書状態プロトコルを介してなされる署名された検証要求、及び
公に掲載された証明書失効リストであって前記関与者により発行された証明書失効リストの参照、
からなる方法の群からの方法である、請求項６に記載の公開鍵基盤。
【請求項８】
異なる信頼ドメインが、責任、償還請求、及び紛争解決を統制する異なる規則を有する、請求項１に記載の公開鍵基盤。
【請求項９】
各信頼ドメインが、オブジェクト識別子により一意に識別されるポリシーを含む、請求項１に記載の公開鍵基盤。
【請求項１０】
各オブジェクト識別子は、
顧客同意書、
顧客同意書において参照により組み込まれる文書、
その下でポリシーが施行されるパブリック法、
証明書ポリシー、
認証局運用規定、
その下でデジタル署名がローカルに強制力をもち且つデジタル証明書がローカルに有効とされるパブリック法、
のうちの少なくとも１つを含む、請求項９に記載の公開鍵基盤。
【請求項１１】
第１の信頼ドメインが、前記関与者へ発行されたルートデジタル証明書により信頼点となり、第２の信頼ドメインが、前記関与者の認証局により自己署名されたデジタル証明書により信頼点となる、請求項１に記載の公開鍵基盤。
【請求項１２】
第１の信頼ドメインが、第１のルート認証局により前記関与者へ発行される第１のデジタル証明書により信用点となり、第２の信頼ドメインが、第２のルート認証局により前記関与者へ発行される第２のデジタル証明書により信用点となる、請求項１に記載の公開鍵基盤。
【請求項１３】
第１の信頼ドメインが、第１のルート認証局により前記関与者へ発行された第１のデジタル証明書により信用点となり、第２の信頼ドメインが、ブリッジ認証局デジタル証明書により前記関与者へ結合される第２のデジタル証明書により信用点となる、請求項１に記載の公開鍵基盤。
【図１Ａ】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【図１Ｂ】
【図１Ｃ】
【図２】
【図３】
【図４】
【公表番号】特表２０１１−５１０５６５（Ｐ２０１１−５１０５６５Ａ）
【公表日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【出願番号】特願２０１０−５４３１５１（Ｐ２０１０−５４３１５１）
【出願日】平成２１年１月１６日（２００９．１．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０００３５７
【国際公開番号】ＷＯ２００９／０９１６１１
【国際公開日】平成２１年７月２３日（２００９．７．２３）
【出願人】（５１０１９４２７５）アイデントラスト， インコーポレイテッド (1)
【Ｆターム（参考）】
【公表日】平成２３年３月３１日（２０１１．３．３１）
【国際特許分類】
【出願日】平成２１年１月１６日（２００９．１．１６）
【国際出願番号】ＰＣＴ／ＵＳ２００９／０００３５７
【国際公開番号】ＷＯ２００９／０９１６１１
【国際公開日】平成２１年７月２３日（２００９．７．２３）
【出願人】（５１０１９４２７５）アイデントラスト， インコーポレイテッド (1)
【Ｆターム（参考）】
[ Back to top ]