JP2006252564A - フォーマットにとらわれない証明書発行のためのシステムおよび方法 - Google Patents

Abstract

【課題】デジタル証明書の修正を可能とするシステムおよび方法を提供すること。
【解決手段】改良された証明書発行システムは、入力証明書および証明書要求を第１のフォーマットから第２のフォーマットに翻訳するための証明書翻訳エンジンを含む。証明書発行エンジンは、共通フォーマットでの入力要求上で動作する。発行エンジンは、その証明書発行ポリシーに従って証明書をクライアントに発行する。このポリシーは、実行時に使用することができるポリシー表現言語でのデータとして表現し、それによって、発行ポリシーの柔軟で効率的な変更がもたらされる。発行された証明書は、要求しているクライアントによって使用されるフォーマットに翻訳し直す。こうした翻訳は、要求しているクライアントへの証明書の引渡しに先立って、翻訳エンジンによって実行する。
【選択図】図３Ａ

Description

本発明は、コンピューティングセキュリティに関し、より詳細には、サーバに対してクライアントを認証し、クライアント許可を決定するためのデジタル証明書の使用に関し、より詳細には、証明書発行システム（ｃｅｒｔｉｆｉｃａｔｅ ｉｓｓｕｉｎｇ ｓｙｓｔｅｍ）での共通フォーマットとの間でのこうした証明書の翻訳に関する。

証明書は、なにがしかの真理またはなにがしかの所有権を証明する文書である。コンピューティングの世界では、デジタル証明書は様々な機能を供する。たとえば、デジタル証明書は、何らかの実体（ｅｎｔｉｔｙ、たとえば、データの集合やハードウェアなど実体のあるもののこと）が、実際にそれが主張するものであることを確認することによって、その実体を認証することができる。デジタル証明書は、制限された資源に実体がアクセスする資格があることを確認することによって、その実体を許可することができる。デジタル証明書を使用して、改ざん防止の方法で、「ポリシー（ｐｏｌｉｃｙ）」、たとえば許可ポリシー、信頼ポリシーなどを取り込むこともできる。

証明書は非常に有用であり、現在のところ使用が増大している。セキュリティポリシーの表明および実施は、ますます重要な企業の能力となっている。証明書フォーマットの数も増えている。今日使用可能なより普及している証明書フォーマットのいくつかとして、Ｘ．５０９、セキュリティ表明マーク付け言語（ＳＡＭＬ：Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）セキュリティトークン、ＸｒＭＬ１．２、およびＭＰＥＧ−ＲＥＬがある。ＭＰＥＧ−ＲＥＬにはいくつかの変形があり、ＸｒＭＬ２．ｘ、ＭＰＥＧ ＩＳＯ−ＲＥＬ、およびＩＳＯ−ＲＥＬを含むいくつかの名前がついていることに留意されたい。頭辞語ＭＰＥＧ−ＲＥＬは、本明細書で使用されているように、これら上に記載された変形の少なくともすべてを指す。

上記の例示的な証明書の様々な機能およびフォーマットを説明するために、Ｘ．５０９の証明書は、それら自体のフォーマットに従い、通常は識別情報を表す。ＳＡＭＬ証明書は、それら自体のＸＭＬスキーマに従い、連合した識別情報ソリューションで広く使用される。ＸｒＭＬ１．２およびＭＰＥＧ−ＲＥＬは、資源に対しての使用ポリシーを表現し、それら自体のＸＭＬスキーマに従う。

今日、証明書を作成し使用するサービスおよび製品が存在する。しかし、新しいタイプの証明書が普及するとき、問題が起きる。現在、特定のフォーマットの証明書を使用する証明書発行システムは、他のフォーマットの証明書と互換性がないことがある。この結果、よくても、クライアントが適切にフォーマット化された証明書を得ようとするとき、またはどの証明書フォーマットがサーバによって要求されるのか、あらかじめ決定するようにクライアントに要求することによって非能率になる。最悪の場合、その結果、相互運用性を損なうことになる。

実施することができる１つの可能なソリューションは、様々なフォーマットの証明書を扱うことができる複数の並列の証明書発行サーバを維持することである。遺憾ながら、このソリューションは、証明書発行システムの実装および更新をより難しくする。複数のシステムを実装し維持するために必要となる努力は、使用されている各追加証明書発行者とともに増加する。

現行の証明書発行システムの他の弱点は、証明書を発行することができる環境、すなわち「証明書発行ポリシー（ｃｅｒｔｉｆｉｃａｔｅ ｉｓｓｕｉｎｇ ｐｏｌｉｃｙ）」を修正することが難しいことである。現行のシステムでは、ポリシーは、証明書発行システムの２進コード中のコンパイルされたアルゴリズムとして、または具体的にモデル化された構成パラメータの「脆弱な（ｂｒｉｔｔｌｅ）」セットとして表現される。実施ポリシーを変更するには、新しい証明書発行システムの再符号化、再コンパイリング、および配置転換が必要となる。したがって、実際問題として、証明書発行ポリシーは、証明書発行システムのプログラマによって予想されるポリシーに制限される。ポリシーを変更するためには、証明書発行システムを完全に再符号化しなければならないことがある。これにより、製品開発チームは、完遂するためにかなりの量の時間および努力を費やすことがある。

したがって、証明書発行においてさらなる相互運用性を提供するため、ならびに証明書発行ポリシーの変更をうまく進めるために、当業界には、まだ取り組むべきニーズがある。

当技術分野での上記識別された欠点を考慮して、本発明は、改善された証明書発行システム、およびこうした改善されたシステムによって実行すべき方法を提供する。

本明細書において提供される証明書発行システムは、入力証明書を共通フォーマットに翻訳するため、また生成された出力証明書をサポートされているどんなフォーマットにも翻訳するための、翻訳構成部品（構成部品：ｃｏｍｐｏｎｅｎｔ）を含むことができる。したがって、システムは、フォーマットにとらわれないものとして説明することができる。共通の証明書発行ポリシーを実施する単一の証明書発行構成部品（ｉｓｓｕｉｎｇ ｃｏｍｐｏｎｅｎｔ）は、様々なフォーマットになる証明書上で動作することができる。発行構成部品によって発行される証明書はまた、要求しているクライアント向けのこうした証明書の引渡しに先立って、様々なフォーマットに翻訳することができる。

システムはまた、証明書発行ポリシーを表現するための新規な構成を含むことができる。このポリシーは、マーク付けポリシー表現言語で表現することができ、たとえば、実行時に証明書発行システムによって使用されるファイル中に記憶することができる。したがって、ポリシーは、ファイルを変更することによって容易に変更することができる。新しい発行ポリシーを適用し実施することができるように証明書発行システムの能力を拡張するために、ある種の技法も提供される。

本発明の他の利点および特徴は後述する。

本発明に従って証明書を発行するためのシステムおよび方法を、添付図を参照しながらさらに説明する。

本発明の様々な実施形態を完全に理解するために、以下の記述および各図で、ある具体的な詳細を説明する。しかし、本発明の様々な実施形態を不必要に分かりにくくするのを避けるために、しばしばコンピューティングおよびソフトウェアの技術に関連したある種のよく知られた詳細は、以下の開示では説明しない。さらに、後述する詳細のうちの１つまたは複数がなくても、本発明の他の実施形態を実施することができることが、当業者には理解されよう。最後に、以下の開示でのステップおよび順番を参照しながら様々な方法を説明するが、説明それ自体は本発明の実施形態の明白な実装形態を提供するためであり、各ステップおよびステップの順番は、本発明を実施するのに必要であると解釈すべきではない。

本明細書において説明される各装置および各方法は、全般的にデジタル証明書の発行に関係する。用語「証明書」は、本明細書においては「デジタル証明書」の短縮形態として使用されている。背景で述べたように、証明書は、なにがしかの真理またはなにがしかの所有権を証明する文書である。用語「証明」は、正しく、真実で、または真正であると確認することを意味する。したがって、本明細書においてクライアントと称される第１の構成要素（実体、エンインティティ）は、証明書を使用して、それ自体についての何らかの事実を、第２の構成要素、サーバに確認することができる。証明書は通常、必ずではないが、信頼される第３者によって発行される。本明細書で使用されているように、証明書は、自己生成した文書またはトークンから、１つまたは複数の公開／秘密鍵の技法などによる暗号化などの多くのセキュリティ機能を用いて、信頼される第３者によって発行される非常に信頼されるデジタルファイルまで、多岐にわたることがある。証明書によって証明される「なにがしか」は、どんなものでもよい。通常は、クライアントの識別情報および／または、何らかの資源の取得またはそれへのアクセスのためのクライアントの許可を証明することができるが、他のどんなものも証明することができる。

信頼される第３者は、本明細書において証明書発行システムと呼ばれる。用語「証明書発行システム」はまた、本明細書および当業界において「証明書発行サービス」と呼ばれることもあり、便宜上単に用語「発行者」と呼ばれることもある。証明書発行システムは、特定のクライアントが、証明書を受け取る資格があるかどうか決定する。資格がある場合、クライアントは証明書を発行され、次いで、証明書を使用してサーバに対して証明することができる。

クライアントおよびサーバは、２つの完全なコンピューティング装置として考えることができ、各々はハードドライブ、バス、システムメモリなどを含むが、現在、当業者にはこれらの用語はより広い意味で理解される。クライアントおよびサーバは事実上、単一のコンピューティング装置内、または分散したコンピューティング構成における複数のコンピュータにまたがって存在する２つの構成要素でよい。この点に関しては、証明書発行システムもまた、１つまたは複数のクライアント、および、１つまたは複数のサーバ構成要素を収容するコンピュータ内に存在してもよく、複数の装置にまたがって存在してもよい。

図１を参照しながら、証明書発行システムとともに使用するのに適した例示的なコンピューティング装置１００を広く説明する。そのもっとも基本的な構成において、装置１００は通常、処理ユニット１０２およびメモリ１０３を含む。コンピューティング装置の正確な構成およびタイプに応じて、メモリ１０３は、揮発性メモリ１０３Ａ（ＲＡＭなど）、不揮発性メモリ１０３Ｂ（ＲＯＭ、フラッシュメモリ、など）、またはその２つの何らかの組合せでよい。さらに、装置１００は、磁気的または光学的なディスクあるいはテープなど、大容量記憶装置（取外し可能な記憶装置１０４および／または取外し不可能な記憶装置１０５）を備えることもできる。同様に、装置１００は、キーボードおよびマウスなどの入力装置１０７、ならびに／またはコンピューティング装置１００の各機能にアクセスするグラフィカルな支援としてＧＵＩを提示する表示装置などの出力装置１０６を備えることができる。装置１００の他の態様には、有線または無線の媒体を使用する、他の装置、コンピュータ、ネットワーク、サーバ、などへの通信接続１０８が含まれ得る。

揮発性メモリ１０３Ａ、不揮発性メモリ１０３Ｂ、取外し可能な大容量記憶装置１０４および取外し不可能な大容量記憶装置１０５は、コンピュータ読取り可能な媒体の例である。コンピュータ読取り可能な媒体は、通信媒体ならびにコンピュータ記憶媒体を備えることができる。通信媒体は通常、コンピュータ読取り可能な命令、データ構造、プログラムモジュールあるいは、搬送波または他の輸送機構など変調されたデータ信号中の他のデータを含み、どんな情報引渡し媒体をも含む。用語「変調されたデータ信号」は、その特性のうちの１つまたは複数が、信号に情報を符号化するような方法で設定または変更された信号を意味する。一例として、限定するものではないが、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、および、音響、ＲＦ、赤外線、他の無線媒体などの無線媒体が含まれる。

コンピュータ記憶媒体は、コンピュータ読取り可能な命令、データ構造、プログラムモジュールまたは他のデータなどの情報を記憶するための、どんな方法または技術でも実装することができる。コンピュータ記憶媒体には、それだけには限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは他のどんな媒体も含まれる。

本発明は、少なくとも部分的には、コンピュータ１００によって実行されているプログラムモジュールなどのコンピュータ実行可能な命令を介して、実装することができる。一般的に、プログラムモジュールには、具体的なタスクを実行しまたは具体的な抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、などが含まれる。

コンピュータ実行可能な命令は、一般的に、コンピュータ１００が使用可能な何らかの形態のコンピュータ読取り可能な媒体上のデジタル情報として含まれる。図１では、たとえば、システムメモリ１０３は、オペレーティングシステムおよびアプリケーションプログラム、ならびに、他のプログラムモジュールおよびプログラムデータを記憶することができる。アプリケーションなどは、オペレーティングシステムと一緒にすることもでき、また別々に存在し、オペレーティングシステムサービスに頼って機能することもできる。

本明細書に記載の本発明の各実施形態は、ソフトウェア実装でよいが、本明細書に記載の様々な技法もまた、ハードウェア構成部品を少なくともいくつかのプログラムモジュールで置き換えることによって実装することができることを理解されたい。したがって、本発明の各方法および各装置、あるいは、ある態様またはその各部分は、高水準の手順言語またはオブジェクト指向プログラミング言語でのプログラムコードの形をとることができるが、各プログラムはまた、必要ならば、アセンブリ言語またはマシン言語で実装することもできる。どんな場合でも、言語は、コンパイルまたは翻訳された言語でよく、ハードウェア実装と組み合わせてもよい。

本発明は、数多くの汎用または特殊目的のコンピューティングシステムの環境または構成で動作可能である。本発明とともに使用するのに適した、よく知られたコンピューティングシステム、環境、および／または構成の例には、それだけには限らないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置などのうちのどんなものをも含む分散コンピューティング環境が含まれる。

図２には、例示的なネットワーク化されたコンピューティング環境が示してある。ネットワークは、コンピューティング装置２７１、２７２、２７６、および２７７、ならびにオブジェクト２７３、２７４、および２７５、ならびにデータベース２７８を含む。これらの構成要素２７１、２７２、２７３、２７４、２７５、２７６、２７７および２７８の各々は、プログラム、方法、データ格納、プログラマブルロジックなどを含み、または使用することができる。構成要素２７１、２７２、２７３、２７４、２７５、２７６、２７７および２７８は、携帯型情報端末、オーディオ／ビデオ装置、ＭＰ３プレーヤー、パーソナルコンピュータなど、同じまたは別の装置の各部分にまたがることができる。各構成要素２７１、２７２、２７３、２７４、２７５、２７６、２７７および２７８は、通信ネットワーク２７０を介して、他の構成要素２７１、２７２、２７３、２７４、２７５、２７６、２７７および２７８と通信することができる。

ネットワーク上の装置は、プロトコル層によって提供される機能を使用して互いに通信する。たとえば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）、すなわち「ウェブ」と関連して使用される共通のプロトコルである。通常、インターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレス、またはユニバーサルリソースロケータ（ＵＲＬ）などの他の参照基準を使用して、サーバまたはクライアントコンピュータを互いに識別することができる。ネットワークアドレスは、ＵＲＬアドレスと呼ばれることもある。通信は、通信媒体を介して提供することができる。たとえば、クライアントおよびサーバは、大容量通信のためのＴＣＰ／ＩＰ接続を介して互いに結合することができる。

ネットワークはそれ自体、図２のシステムにサービスを提供する他のコンピューティング構成要素を含み、それ自体、複数の相互接続ネットワークを表すことができる。各構成要素２７１、２７２、２７３、２７４、２７５、２７６、２７７および２７８は、他の構成要素２７１、２７２、２７３、２７４、２７５、２７６、２７７および２７８のうちの、１つまたは複数にサービスを要求するために、ＡＰＩ、または他のオブジェクト、ソフトウェア、ファームウェアおよび／またはハードウェアを使用することがある、個別の機能プログラムモジュールを含むことができる。

「クライアント」は、それが関係していない他のクラスまたはグループのサービスを使用する、クラスまたはグループのメンバーである。コンピューティングにおいては、クライアントは、プロセス、すなわち大ざっぱに言えば他のプログラムによって提供されるサービスを要求する１組の命令またはタスクでよい。こうしたサービスは、たとえば、証明書発行システムによる証明書の発行でもよい。クライアントプロセスは、他のプログラムまたはサービス自体についてのどんな作業詳細も「知る」必要がなく、要求されたサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワーク化されたシステムにおいて、クライアントは通常、他のコンピュータ、たとえばサーバによって提供される共用ネットワーク資源にアクセスするコンピュータである。図２の例では、どんな構成要素２７１、２７２、２７３、２７４、２７５、２７６、２７７および２７８も、環境に応じてクライアント、サーバ、または両者とみなすことができる。

サーバは通常、必ずしもそうではないが、インターネットなどの遠隔またはローカルなネットワークを介してアクセス可能な遠隔コンピュータシステムである。クライアントプロセスは、第１のコンピュータシステムで稼働することができ、サーバプロセスは、第２のコンピュータシステムで稼働することができ、通信媒体を介して互いに通信し、したがって、分散機能を提供し、複数のクライアントがサーバの情報収集能力を利用することができるようにする。どんなソフトウェアオブジェクトも、複数のコンピューティング装置またはオブジェクトをまたがって分散することができる。

したがって、本発明の実施形態は、証明書を要求するクライアント構成要素がネットワーク内の第１のコンピューティング装置、たとえば２７７に常駐する状況に取り組むことができる。クライアント構成要素が必要とする何らかの資源を備えることができるサーバ構成要素は、第２のコンピューティング装置、たとえば２７５に常駐することができる。証明書発行システムは、さらに第３のコンピューティング装置、たとえば２７１に常駐することもできる。

装置２７７のクライアントは、装置２７５のサーバに対していくつかのクライアント資格証明（ｃｌｉｅｎｔ ｃｒｅｄｅｎｔｉａｌ）を証明するための証明書を必要とすることを決定することができる。したがって、２７７のクライアントは、ネットワークバス２７０を横切って、２７１の発行者に要求を出す。要求それ自体は、以前に発行された１つまたは複数の証明書を含むことができる。２７１の発行者はさらに、そのクライアントが、要求した証明書を受け取る資格があるかどうか決定する。２７１の発行者は、証明書発行ポリシーを適用することによってこれを遂行する。２７７のクライアントが、ポリシーによって要求された資格証明を有する場合、要求された証明書は、２７１の発行者によって２７７のクライアントに発行することができる。次いで、クライアントは、２７５のサーバとの通信において、どんな数の他の証明書とも一緒に、発行された証明書を使用することができる。

図３Ａには、証明書発行システムの翻訳構成部品の一部分が示してある。発行構成部品３４は、図４および５により詳細に例示されている。本発明の様々な実施形態において、翻訳構成部品は、入力証明書を受け取るための実質上第１の構成部品、および証明書をクライアントに送達される前に処理するための実質上最後の構成部品にもなることができる。他の実施形態では、翻訳構成部品は、必要に応じて証明書発行システムのどんな場所においても使用することができる。

証明書を求める要求が証明書発行システムに届いた場合、第１のフォーマット３０での第１の証明書などのどんな添付証明書も、翻訳ドライバ３１に送ることができる。翻訳ドライバ３１は、発行構成部品３４の動作のために使用される共通フォーマットとの間で証明書を翻訳するように動作することができる。したがって、第１のフォーマット３０での第１の証明書は、第２のフォーマットに翻訳することができる。こうした翻訳の結果が、第２のフォーマット３３での第１の証明書である。

逆に言えば、発行構成部品３４によって証明書が発行される場合、その証明書は、発行構成部品３４によって生成されるフォーマットからクライアントによって必要とされるどんなフォーマットにも翻訳することができる。したがって、第２のフォーマット３５での第２の証明書は、第３のフォーマットに翻訳することができる。こうした翻訳の結果は、第３のフォーマット３７での第２の証明書である。この第３のフォーマットは、証明書を求めるクライアント要求とともに到達する１つまたは複数の証明書のフォーマット、たとえば３０を含めて、どんな証明書フォーマットでもよい。

証明書翻訳構成部品は、可能な限り多くの証明書フォーマットを翻訳するよう最適に設計されている。この点に関しては、証明書翻訳構成部品は、Ｘ．５０９証明書、セキュリティ表明マーク付け言語（ＳＡＭＬ）のセキュリティトークン証明書、ＸｒＭＬ１．２証明書、およびＭＰＥＧ−ＲＥＬ証明書を翻訳して、いくつかのより普及している例示的な証明書フォーマットを指定することができる。しかし、常にどれもこれも可能性がある証明書タイプすべてについて翻訳装置を設計することは、必ずしも経済的に実現可能ではないことがある。本発明は、翻訳構成部品による翻訳が可能な証明書タイプの数または具体的なフォーマットに限定されない。

新しい証明書フォーマットは当技術分野で絶えず生成されているので、追加の証明書フォーマットに対応するよう拡張することができるように翻訳構成部品を設計することは有益である。ドライバ３１は、具体的な証明書３０の様々な要素を、１つまたは複数のクラス、たとえば３２によって提供される命令に基づく共通フォーマット証明書３３へ変換することを管理することができる。図３Ａの具体的な構成は、新しい証明書フォーマットに対応するために翻訳構成部品を拡張することができるため、有利である。しかし、ドライバ３１および図３Ａでの３２、３６の構成などのクラスは単に例示的であり、証明書をあるフォーマットから他のフォーマットに変換するのに、様々な構成が実行可能であることが当業者には理解されよう。

図３Ａでは、共通フォーマットは第２のフォーマットと呼ばれている。共通フォーマットを選択することで、様々なフォーマットの入力証明書に含まれ得る様々なタイプの情報のすべてに対応するために可能な限り頑強なフォーマットを決定する。どんな証明書も、Ｘ．５０９フォーマット、セキュリティ表明マーク付け言語（ＳＡＭＬ）のセキュリティトークンフォーマット、ＸｒＭＬ１．２証明書、およびＭＰＥＧ−ＲＥＬフォーマットを含む共通フォーマットで働くように選択されて、いくつかのより普及している例示的な証明書フォーマットを指定することができるが、ＭＰＥＧ−ＲＥＬが、本発明の実装形態向けに選択され、この目的には有利であると現在みなされている。ＭＰＥＧ−ＲＥＬは、現在、もっともリッチで、もっとも頑強で、拡張可能な証明書フォーマットであるとみなされている。しかし、技術が進展するにつれ、他のより有利な証明書を開発することができる。

翻訳構成部品を使用することの他の有利な点は、様々な証明書フォーマットの各々が、それ自体の方法でポリシーを表現する事実からきている。特定のどんなフォーマットをも使用することは、発行者に行き渡るカスタムのアルゴリズムを必要とするため、現在の証明書発行者の相互運用性への障壁は、フォーマットの非互換性である。あらゆる既存の証明書作成者に共通フォーマットを採用するよう納得させることは期待できず、したがって、これらフォーマットは長期にわたって存在しつづけることになると仮定しなければならない。したがって、異種の証明書フォーマットおよびそれらの意味を共通の言語にマッピングまたは翻訳するための技法は、複数のフォーマットの体系的な衝撃を低減し、証明書の相互運用性の問題解決の方向の一ステップである。

正しい翻訳は、構文的および意味論的要求を満足させなければならない。前者は、翻訳された証明書が有効なフォーマットであることを要求する。後者は、翻訳された証明書が最初の証明書と同じ情報を運ぶことを要求する。しかし、ソースフォーマットがターゲットフォーマットよりも多くの情報を有する場合があり、それにより、翻訳における情報損失が避けられないものになる。したがって、本発明の実装形態の目標は、最善の努力をして他の情報を保存している間に、確実に情報が正しく翻訳されることである。

証明翻訳アルゴリズム３２、２６は、それらの機能に基づいて、２つのカテゴリに分類することができる。

構文レベル：コンストラクト間のマッピング
意味レベル：証明書間の翻訳
一実施形態では、このアルゴリズムの収集は、１組のクラスとして実装される。そのクラスのセットは、図３Ａに証明書翻訳ドライバ３１として示してある。翻訳ドライバ３１の実施形態は、３つの構成部品、ドライバクラス、証明翻訳クラス、および構成クラスを含むことができる。ドライバクラスは、翻訳プロセスの総合的な協調を実行することができ、翻訳クラスを呼び出す。翻訳クラスは、実際の翻訳プロセスを実行することができ、構成クラスは、翻訳ドライバ３１が動作するための必要な構成データを含むことができる。

第１の証明書フォーマットＸｒＭＬ１．２から第２の証明書フォーマットＸｒＭＬ２．０への翻訳の例示的な動作を示すために、以下の簡潔な例が含まれる。当業者には分かるように、ＭＩＣＲＯＳＯＦＴ（登録商標）権利管理サーバ製品の第１バージョンは、そのポリシー評価を行うためにＸｒＭＬ１．２フォーマットでの証明書を使用した。しかし、権利管理サーバ製品の将来予定されているリリース版は、ＸｒＭＬ２．０フォーマットでの証明書を使用することになる。したがって、以下は、翻訳構成部品の動作、および本明細書で提供される本発明がますます必要になることの両方の良好な例である。状況は以下の通りである。クライアントは、本発明を実装する仮想の権利管理サーバ製品に証明書要求を送る。要求それ自体は、証明書、たとえば図３Ａでの証明書３０をＸｒＭＬ１．２フォーマットで含む。ＸｒＭＬ２．０は、証明書発行システム３４によって使用される共通フォーマットである。

両方のフォーマットでの証明書を受け取り理解するために、１組の翻訳クラスが実装されている。ＸｒＭＬ１．２フォーマットでの証明書３０を用いて、要求をクライアントから受け取ったときに、これが遂行されると仮定すると、翻訳ドライバ３１は、対応する証明書翻訳クラス３２を作成し、構成データをそれに渡し、翻訳方法を呼び出す。証明書翻訳クラス３２は、ＸｒＭＬ１．２の証明書３０の署名および妥当性時間間隔を妥当性検査し、それを翻訳してＸｒＭＬ２．０の相手方３３に渡し、翻訳特有の情報を翻訳ドライバ３１に返す。次いで、翻訳ドライバ３１は、ＸｒＭＬ２．０フォーマットでの証明書３３を使用して権利管理サーバ３４を呼び出す。この例では、権利管理サーバ３４は、元々ＸｒＭＬ２．０証明書を理解し、証明書発行動作を実行し、その結果を翻訳ドライバ３１に送り返す。権利管理サーバ３４によって発行されたＸｒＭＬ２．０証明書３５を受け取った後、翻訳ドライバ３１は、ＸｒＭＬ２．０の証明書３５を翻訳してＸｒＭＬ１．２の相手方３７にする証明書翻訳クラス３６を作成する。

図３Ｂは、入力証明書要求が発行者によってどのように扱われるかを示す。まず、要求はサーバ入口点３０１に届く。その最初のフォーマットでの証明書または他の要求情報、たとえば３０２は、翻訳層３０３と呼ばれる翻訳構成要素に渡される。証明書は必ずしも証明書要求を添付しなくてよいことに留意されたい。通常、何らかの形態で証明が行われ、証明書は証明すべき事実を確認検査するための有益な方法ではあるが、あらゆる証明書要求を添付する必要はない。様々なタイプの他の情報もまた、要求に含まれ得る。他の何らかの情報が使用される場合、証明書フォーマットが異なるのとやや同じように、情報の具体的なデータタイプも異なることがある。したがって、証明書翻訳層３０３は、３０２などの証明書をあるフォーマットから他のフォーマットに、または様々なフォーマットから単一のフォーマットに翻訳するように構成することができるが、証明書要求を添付することができるどんなデータも処理するように構成することもできる。こうしたデータは、入力証明書のように、単一の発行構成部品すなわち本明細書では証明書エンジン３０５によって使用することができる共通フォーマットに翻訳することができる。

図３Ｂでの入力情報は、第２のフォーマット３０４に変換することができる。入力情報がすでに第２のフォーマットである場合、もちろん翻訳は必要ない。次いで、要求３０４に関連した証明書および／または他の情報は、サーバ証明書エンジン３０５によって取り扱うことができる。

図３Ｃは、クライアント３１０が証明書を求める要求をサーバ３１３に送る、本発明の他の観点を示す。タイプ１の証明書は、クライアント３１０要求に関連している。タイプ１の証明書は、証明書翻訳エンジン（ＣＴＥ）３１１によって、タイプ２の証明書など、発行者３１２によって使用される何らかの他のフォーマットに翻訳することができる。タイプ２の証明書は、発行エンジン３１２によって使用されて、クライアント３１０の要求を許可すべきかどうか決定する。発行エンジン３１２が第２のフォーマットでの証明書を発行する場合、ＣＴＥ３１１は、それをクライアント３１０向けの第１のフォーマットに翻訳することができる。あるいは、発行エンジン３１２は、ＣＴＥ３１１を再使用して第２のフォーマットの証明書から第１のフォーマットの証明書に翻訳することなしに、単にクライアント３１０向けの適切なフォーマットでの証明書を生成することができる。本発明の多くの実施形態では、ＣＴＥ３１１は、複数の入力証明書タイプを扱うように構成することができることに留意されたい。こうした各タイプは、発行者３１２の操作のために共通のタイプに翻訳されることが好ましい。逆に言えば、クライアント３１０によって要求されるように、ＣＴＥ３１１は、発行エンジン３１２からの第２のフォーマットの証明書を様々な証明書タイプのどんなものにも変換するように構成されることが好ましい。

システムを使用することによって利益を得ることができる例示的な状況の中で、図３Ｃに例示されたものは、クライアント装置および／またはプロセスの証明、クライアントライセンサ証明書（ＣＬＣ：Ｃｌｉｅｎｔ Ｌｉｃｅｎｓｏｒ Ｃｅｒｔｉｆｉｃａｔｅ）要求の認可、およびデジタルコンテンツの権利のライセンシングである。

第１のフォーマットの証明書を用いて動作するクライアント（「ｖ１クライアント」）を使用するユーザが、権利管理システムによって保護されたｅメールを初めて開けようとする場合、例示的な証明の状況が生じる。この状況では、ｖ１クライアントは、たとえば、現在クライアントマシンの識別情報を表すＸｒＭＬ１．２証明書であるｖ１マシンアカウント証明書（ＭＡＣ：Ｍａｃｈｉｎｅ Ａｃｃｏｕｎｔ Ｃｅｒｔｉｆｉｃａｔｅ）、およびＷＩＮＤＯＷＳ（登録商標）ドメイン資格証明を証明書発行システム３１３に送ることがある。ＣＴＥ３１１は、ＭＡＣを翻訳して、現在クライアントマシンの識別情報を表すＭＰＥＧ−ＲＥＬ証明書であるセキュリティプロセッサ証明書（ＳＰＣ：Ｓｅｃｕｒｉｔｙ Ｐｒｏｃｅｓｓｏｒ Ｃｅｒｔｉｆｉｃａｔｅ）にすることができ、そのＳＰＣを発行エンジン３１２に与える。次いで、発行エンジンは、第２のフォーマット証明書、たとえば権利アカウント証明書（ＲＡＣ：Ｒｉｇｈｔｓ Ａｃｃｏｕｎｔ Ｃｅｒｔｉｆｉｃａｔｅ）、これまでのところではクライアントマシン上のユーザの識別情報を表すＭＰＥＧ−ＲＥＬ証明書を発行し、そのＲＡＣをＣＴＥ３１１に送ることがある。次いで、ＣＴＥ３１１は、ＲＡＣを翻訳して、第１のフォーマットの証明書、たとえばグループ識別情報証明書（ＧＩＣ：Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ Ｃｅｒｔｉｆｉｃａｔｅ）、これまでのところではクライアントマシン上のユーザの識別情報を表すＸｒＭＬ１．２証明書にすることができる。次いで、発行システム３１３は、ＧＩＣを用いてクライアント３１０に応答を返す。

例示的なＣＬＣ要求状況は、クライアント３１０が要求を発行システム３１３に送って、ユーザがオフラインで保護されたコンテンツのためのライセンスを発行するのを許可する証明書を得る状況である。この場合、ＣＴＥ３１１は、要求に関連した入力ＲＡＣを翻訳して、発行エンジン３１２によって処理することができるＣＬＣにすることができる。あるいは、クライアント３１０は、ＣＴＥ３１１によってＳＰＣに翻訳されたＧＩＣを提出することができ、発行者３１２は、ＣＴＥ３１１によってＣＬＣに翻訳されたＲＡＣを返すことができる。

図３Ｃでのシステムなどがデジタルコンテンツ内の権利のライセンシングのために使用されることがある例示的な状況は、以下の通りである。権利保護されたコンテンツを使用するために、ｖ１クライアント３１０は、ライセンシング要求を発行システム３１３に行うことができる。クライアント３１０は、ｖ１発行ライセンス発行ライセンス（ＩＬ：Ｉｓｓｕａｎｃｅ Ｌｉｃｅｎｓｅ）、たとえば保護コンテンツの具体的な一部分に対する著者が指定した使用権を記述するＸｒＭＬ１．２証明書、およびＧＩＣを発行システム３１３に送ることがある。次いで、ＣＴＥ３１１は、入力ＩＬおよび入力ＲＡＣを翻訳し、それらを発行エンジン３１２に与えることができる。発行エンジン３１２が、使用ライセンス（ＵＬ：Ｕｓｅ Ｌｉｃｅｎｓｅ）、たとえば具体的なユーザが保護されたコンテンツの具体的な一部分にアクセスすることを許可するＭＰＥＧ−ＲＥＬ証明書を、クライアント３１０に認可する場合、ＣＴＥ３１１はまた、発行されたＵＬを翻訳して、具体的なユーザがｖ１クライアント３１０によって使用される保護されたコンテンツの具体的な一部分にアクセスすることを許可するＸｒＭＬ１．２証明書などの、エンドユーザライセンス（ＥＵＬ：Ｅｎｄ Ｕｓｅｒ Ｌｉｃｅｎｓｅ）にすることができる。次いで、発行システム３１３は、ＵＬをクライアント３１０に送り返すことができる。

ＣＴＥ３１１を実装するためにいくつかのソフトウェア設計を使用することができるが、当業者には分かるように、例示的なＣＴＥ設計は、３つの構成部品、ＣＴＥドライバ、証明翻訳クラス、および構成クラスを含むことができる。

この設計では、ＣＴＥドライバは、サーバ入口点３０１およびサーバ証明書エンジン３０５と対話する。証明書要求を受け取ったとき、ドライバは、対応する証明翻訳クラスを作成し、構成データを翻訳クラスに渡し、翻訳方法を呼び出す。次いで、証明翻訳クラスは、たとえばａ）署名妥当性検査、ｂ）証明書妥当性時間間隔満了時間、およびｃ）発行者を１組の信頼される発行者と比較することなどの技法を使用して、それが扱っている署名および妥当性時間間隔証明書を妥当性検査する。証明翻訳クラスはまた、証明書を翻訳して共通フォーマットの証明書の相手方にし、共通フォーマットの証明ストリングを、他の翻訳特有の情報とともに、ＣＴＥドライバに返すことができる。

次に、ＣＴＥドライバは、共通フォーマットの証明書を使用して証明書エンジン３０５を呼び出す。証明書エンジン３０５によって発行された生成された共通フォーマットの証明書を受け取った後、ＣＴＥドライバは、生成された共通フォーマットの証明書を翻訳して第３のフォーマット、たとえば最初の入力証明書のフォーマットでの相手方の証明書にする、証明翻訳クラスを作成する。

したがって、ＣＴＥについての例示的なワークフローは、以下の通り進むことができる。
クライアントから証明書要求を得る。
必要ならば、添付証明書を妥当性検査および復号化する。
復号化された証明書を共通フォーマットの相手方に変換する。
ある情報（Ｋｅｙｓ、ＳＰＣなど）に置き換えることもできる。
共通フォーマットの証明書で表現できないどんな情報も保存する。
証明書発行エンジンを呼び出す。
発行された共通フォーマット証明書を証明書発行エンジンから得る。
必要ならば、発行された共通フォーマットの証明書を復号化する。
復号化された発行済み共通フォーマットの証明書をクライアントフォーマット化された相手方に変換する。
以前のステップで保存された情報を使用することができる。
クライアントフォーマット化された証明書を暗号化および署名する。
クライアントフォーマット化された証明書をクライアントに送る。

図４には、証明書発行システムの発行構成部品の一部分が示してある。図３Ａを参照しながら記述されているように、いったん翻訳が完了すると、翻訳された証明書表現は、図４に例示された様々な機能構成部品を使用して処理することができる。各図を不明瞭にするのを避けるため、翻訳構成部品は、図４または図５には例示されていない。様々な構成部品の例示的な統合については、図３Ａを参照されたい。

クライアント４０は、証明書を求めるその要求とともに１つまたは複数の請求を送る。請求とは、実体が証明書を受け取る資格があるかどうか決定するのに使用するために、その実体によって行われるあらゆる表明である。請求が真であると確認される場合、クライアント構成要素４０は、資格証明を有していることを証明したことになる。証明書をクライアント４０に発行するのに先立って、最終的に１つまたは複数の資格証明が証明書発行ポリシーによって必要とされることがある。こうした資格証明は、それ自体、１つまたは複数の証明書によって証明することができる。

認証４１、許可４２、および資格証明フォーマット化４３は、発行構成部品によって実行することができる例示的な機能である。図４に例示したように、これらの機能は、連続して認証４１、次いで許可４２、次いで資格証明フォーマット化４３の順に実行することができる。この順序は、あらゆる実施形態で必要になるわけではない。クライアント要求を満足させるために必要となるものに応じて、４１、４２、および４３は、各々独立して実行しても、何らかのサブコンビネーションを実行しても、またこうした機能の１つまたは複数を図４に例示されていない他の何らかの機能とともに実行してもよい。

４１、４２、および４３が連続して実行される場合、認証プロセス４１は、まず、証明書要求をサポートするための請求をするクライアント４０が、事実上クライアント４０がその実体であると請求する実体かどうか決定することができる。これが証明されると、許可プロセス４２は、クライアントが、要求された証明書を受け取ることを許可されているかどうか決定することができる。あるいは、許可プロセス４２は、単にクライアント４０の許可レベルを決定し、作成される証明書にそれを記録することができる。最後に、証明書がクライアント４０の代わりに生成される場合、証明書にリストされるクライアント４０の資格証明は、生成された証明書内で４３によってフォーマット化することができる。以下は、証明書発行エンジン４４によって適用することができる例示的なアルゴリズムを示す。

発行証明書（ユーザ入力証明書、サーバ発行ポリシー）
発行ポリシーに基づいて
ユーザ入力証明書を認証する
証明書発行についてサーバに権限を与える
結果として生じる証明書を以下のように構成する
クライアントエンジンが認証する必要があるものを作成する
発行ポリシーによって許可された認可を作成する
認可発行を許可する
必要な場合、許可するための拡張機能を呼び出す
許可を生成する
この許可の一部を生成するための拡張機能を呼び出す
必要な場合
ユーザ権利を許可として構成する
生成された証明書に署名する
証明書を返す

認証４１、許可４２、および資格証明フォーマット化４３の機能を実行する一部分として、汎用のポリシー言語構文解析および実施エンジン４４が証明書発行ポリシー４５を適用することができる。実施すべきポリシーがエンジン４４ではなく、実行時にエンジン４４によって使用される発行ポリシー４５で表されるという意味では、発行構成部品はデータ駆動型である。

従来技術での証明書発行システムは、証明書を生成する場合にポリシーを適用および実施するが、このポリシーは、従来技術の発行者では、証明書発行システム２進コードでのコンパイル済みアルゴリズムとして、または具体的にモデル化された、構成パラメータの「脆弱な」セットとして表される。その結果、従来技術の発行者での実施ポリシーを変更することは、新しい発行者の２進値を再符号化し、再コンパイルし、再配置することを要求する。すなわち、引き渡された発行者は、証明書発行システム著者によって予想されたポリシーのセットを実施することに制限される。

証明書発行エンジン４４は、予想されたポリシー構造を、ほとんどまたは全く含むべきではない。代わりに、エンジン４４は、実行時に遭遇する４５から具体的なポリシーデータを受けるメタデータ駆動型ポリシー実施エンジンを含むべきである。このポリシーデータ４５は、エンジン４４が使用するために設計された汎用の拡張可能なポリシー表現言語を使用して表される。

エンジン４４は、単一で、共通のポリシー表現言語上で動作し、４５での使用可能なポリシーおよびデータに基づく許可決定を行うことが好ましい。この処理を一様なポリシー表現言語フォーマット上で実行することにより、エンジン４４ロジックは、より簡潔で、より効率的になり、選ばれたポリシー表現言語に対して最適化することができる。データ駆動型であることにより、エンジン４４は、新しいポリシー、意味または構造に対応するためにエンジン４４ロジックを変更する必要もなく、広い範囲の表されたポリシーを評価することができる。各図で例示されているエンジン４４は、ポリシー４５を構文解析し実施するための機能構成部品、および証明書を生成するための機能構成部品を両方含む。エンジン４４によって生成される証明書の形態は、発行ポリシーのその他の側面に加えて、ポリシー４５によって管理することができる。

ポリシー４５を表すために使用されるポリシー表現言語は、広範囲な形態のどんなものでもとることができる。使用される言語は、拡張可能なマーク付け言語（ＸＭＬ）、ハイパーテキストマーク付け言語（ＨＴＭＬ）、他の何らかのマーク付け言語などのマーク付け言語でよい。当業者には分かるように、人間が読取り可能な語およびマーキングのセットは、こうした言語で組み合わされて、所望の動作を正確に指定することができる。エンジン４４などのマシンプロセスは、実行時にこの形態でのファイルを使用し、所望の動作を実行するように構成することができる。本発明とともに使用するために設計されるどんなポリシー表現言語も、必要に応じてポリシーの変更および言語意味の追加に対応するために、頑強で、拡張可能で、柔軟性を持つべきである。マーク付けとは、文書の論理構造を記述するために、テキストまたはワード処理ファイルのある場所に挿入される一連の文字または他のシンボルを指す。マーク付けの表示は、しばしば「タグ」と呼ばれる。マーク付けは、直接シンボルをタイプすることによって、またはエディタを使用し、あらかじめ同梱されたマーク付けシンボルを選択することによって（キーストロークを節約するため）、文書作成者によって挿入することができる。

ＨＴＭＬとは違って、マーク付けシンボルは無制限で自己定義であるため、ＸＭＬは「拡張可能」である。ＸＭＬは実際に、より簡潔でより使いやすい標準一般化マーク付け言語（ＳＧＭＬ）の部分集合であり、文書構造をどのように作成するかについての規格である。ＨＴＭＬおよびＸＭＬは、多くのウェブアプリケーションにおいて一緒に使用されることが期待される。たとえば、ＸＭＬマーク付けは、ＨＴＭＬページ内に現れることがある。この点に関しては、本発明のために使用される指定された構文には、マーク付け言語の組合せが含まれ得る。

図４では、エンジン４４は、ポリシー表現言語で表現されデジタルフォーマットで記憶されるポリシー４５を適用する。ポリシー４５は、１つまたは複数のデジタルファイルとしてでも、データベースとしてでも、また他のどんな記憶されたデータフォーマットとしてでも明示することができる。デジタルファイルは、どんな形態にも変換できることが当業者には理解されよう。すなわち、その側面はデータベースのフィールドに挿入することができ、またこのファイルはあるフォーマットから他のフォーマットに変換することができる。したがって、少なくとも最初にポリシーは、一般的なテキスト（．ｔｘｔ）または文書（．ｄｏｃ）フォーマットでのファイルなど、テキストエディタで使用することができるデジタルフォーマットで、人間によって最適に作成されることを企図しているが、こうした初めのデジタルファイルは、４５に記憶するのに先立って、どんな数の形態にも変換することができる。データのフォーマットがどうであれ、そこで表現される発行ポリシー４５は、クライアント４０が要求された証明書を受け取る資格がある場合、クライアント４０に満足しなければならない。ポリシー４５はまた、生成された証明書のフォーマットを管理することができる。すなわち、資格証明フォーマット化のためのポリシーを含むことができる。

発行ポリシー４５は、少なくとも以下のものからなることが好ましい。
クライアント認証要求
クライアント許可要求
サービス許可要求を発行する証明書
許可実施命令
証明書発行システムの一例として、普及しているＭＩＣＲＯＳＯＦＴ ＷＩＮＤＯＷＳ（登録商標）権利管理サーバ発行者をもう一度利用するためには、この発行者は、保護された文書およびｅメールに対する「情報権利管理」機能、たとえばＭＩＣＲＯＳＯＦＴ（登録商標）Ｏｆｆｉｃｅ２００３での情報権利管理機能を実装するために使用することができることが当業者には理解されよう。ソリューションの一部分として、ＷＩＮＤＯＷＳ（登録商標）権利管理サーバの現在使用可能なバージョンでは、予想され、ハードコードされた、脆弱な発行ポリシー定義を含む発行者を採用する。固定され、よく知られた、発行ポリシーのセットだけを実施することができる。たとえば、
信頼されるアプリケーションは何か？
どのユーザが具体的に排除されるのか？
ユーザ識別資格証明を発行するのに、どの実体が信頼されるのか。
ユーザは、権利管理ソフトウェアのどのバージョンをデスクトップ上で走らせなければならないか？
対照的に、ＷＩＮＤＯＷＳ（登録商標）権利管理サーバの現在使用可能なバージョンは、以下のような新しい発行ポリシーを実施することができない。
ユーザ企業の部署にとって信頼されるアプリケーションは何か？
どのクラスのユーザが具体的には排除されるのか（たとえば、７日未満のうちにネットワークパスワードが失効するすべての人）？
どの具体的な資格証明が信頼して生成される証明書発行システムなのか？

本明細書における本発明の各システムおよび方法を実装するために、ＷＩＮＤＯＷＳ（登録商標）権利管理証明書発行サービスの現在使用可能なバージョンを再構築することによって、その製品は、柔軟性があるポリシー表現言語で、ポリシーを理解し実施することもでき、上記に掲載された新しい発行ポリシー、ならびに他のどんな考えられる発行ポリシーも、採用された発行者を変更することなしに、適応することができる。４５での表現されたポリシーだけは、変更する必要があるはずである。

証明書発行システムは、クライアント４０の発見プロセス、検証解析（ｆｏｒｅｎｓｉｃ ａｎａｌｙｓｉｓ）などをうまく進めるために、使用可能な発行された証明書フォーマットのセットとともに、その発行ポリシー４５を発行することができる。以下は、この説明では例示的な発行ポリシーである。

図５には、ポリシー表現言語ならびに／または、ポリシー言語構文解析および実施エンジン５６によって固有にサポートされない新しい発行ポリシーを適用し実施するために発行構成部品を拡張するための、システムおよび方法が示してある。たとえば追加のデータ５９を発行ポリシーデータ５８と組み合わせることによって、ポリシー表現言語構文が拡張される場合、拡張されたポリシー表現言語コンストラクトの意味を扱うプラグインロジック５５を実施エンジン５６に追加することができる。たとえば、ワイルドカード置換えパターンデータ６０を発行ポリシーデータ５８に追加することによって、固有のポリシー言語ワイルドカードが使用される場合、ワイルドカード置換えパターン６０の拡張を扱うプラグインロジック５７を、実施エンジン５６に追加することができる。

データ駆動型ポリシー評価エンジン５６は、それが理解しない、または処理することを意図されていない証明書の意味を予想するように設計することができる。これらの証明書の意味に対する拡張性機構が存在することができ、こうした証明書についての５５や５７などのカスタムロジックは、値を提供し、カスタム処理を実行し、さもなければ、知られていない意味を明確な方法で扱うように問合せをされる。この処理の結果は、ポリシー評価エンジン５６にフィードバックされ、場合によっては証明書への資格決定の最終結果に影響を及ぼすこともある。

発行構成部品を拡張するために本明細書において企図された機構が少なくとも２つある。最初に、拡張可能なポリシー表現言語（たとえば、ＸＭＬの拡張性に影響を与える言語）を上に構築することによって、また５５などの適切なプラグイン機構を提供することによって、証明書発行システムは、その顧客にカスタム拡張性をサポートすることができる。第２に、ワイルドカード置換えパターンの概念をそのポリシー表現言語に含めること、および５７などの適切なプラグイン機構を提供することによって、発行者は、その顧客にカスタム拡張性をサポートすることができる。

発行構成部品を拡張するための前述の選択肢のうちの第１の選択肢から始めて、ポリシー表現言語構文は、好ましい実施形態において拡張可能である。ポリシー実施エンジン５６は、ポリシー表現言語の本来の側面の意味論的な意味をどのように引き受けるかを「知る」ように事前に構成することができる。しかし、ポリシー表現言語の意味が拡張される場合、エンジン５６も拡張されなければならない。

ポリシー表現言語の拡張は、エンジン５６によってアクセス可能なデジタルデータ５９で説明することができる。こうした拡張５９は、１つまたは複数のファイルとしてでも、データベースとしてでも、また他のどんな記憶されたデータフォーマットとしてでも明示することができる。拡張は、一般的なテキスト（．ｔｘｔ）または文書（．ｄｏｃ）のフォーマットでのファイルなど、テキストエディタによって使用されるフォーマットで、人間によって最適に作成されるが、こうした初めのファイルは、記憶に先立ってどんな数の形態に変換することもできる。データのフォーマットがどうであれ、そこに表現されている発行ポリシー拡張５９は、カスタムロジック５５によってアクセスされて、拡張されたポリシー表現構文５９を使用して表現されるポリシーを適用し実施することができる。

これを遂行するために、エンジン５６は、５５などの拡張されたロジック（別名「プラグイン」）を登録することができるように構成することができる。プラグイン５５は、ポリシー表現言語のどんな新しい構文上の拡張５９に対しても、意味論的裏付けを提供することができる。したがって、予想されない顧客要求は、エンジン５６それ自体またはポリシー表現言語の最初に使用される構文をオーバホールすることなく、取り組むことができる。ポリシー表現言語は、構文的に拡張をサポートするように、理想的に設計される。

一例によって、プラグイン５５を使用するエンジン５５の拡張性を明確にする助けになることがある。証明書発行システムが、ユーザのＰＫＩ識別情報を表す要素を含むＸＭＬポリシー表現言語とともに使用されるとしよう。おそらく、以下のようになる。

証明書発行システムの顧客は、ユーザ企業の軽量ディレクトリアクセスプロトコル（ＬＤＡＰ：Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）識別情報を含めるために、ユーザの概念を拡張したいと思うこともある。ＬＤＡＰ構文を含むためのポリシー言語拡張は、必要な場合、証明書発行システムデータベース上でＬＤＡＰ問合せを実行するコードを用いてサポートすることができる。この場合、拡張されたポリシー言語コンストラクトは以下のようになることもある。

さらに、ＬＤＡＰ問合せを用いてユーザを確認検査したコード、すなわちプラグイン５５は、コンパイルされ、証明書発行システムに登録されることになる。このプラグイン５５は、拡張されたポリシー表現言語構文に遭遇した場合、エンジン５６によって呼び出されることになる。いくつかの実施形態では、プラグインを登録することなしに拡張された構文を使用することが可能になることがあることに留意されたい。これは、同じ拡張された構文を、入力／出力証明書およびエンジンによって解釈された発行ポリシーデータの両方に追加することによって遂行することができる。

次に、発行構成部品を拡張するための第２の選択肢に移ると、使用されるポリシー表現言語には、ワイルドカード置換えパラメータが含まれ得る。ワイルドカード置換えパターンは、最初の発行ポリシー５８で説明しても、また最初のポリシー５８を補うのに使用可能な追加のデータ６０を作成することによってポリシーに追加してもよい。

ワイルドカード置換えパターン６０は、１つまたは複数のファイルとしてでも、データベースとしてでも、また他のどんな記憶されたデータフォーマットとしてでも明示することができる。初めの置換えパターンは、一般的なテキスト（．ｔｘｔ）または文書（．ｄｏｃ）のフォーマットでのファイルなど、テキストエディタによって使用されるフォーマットで、人間によって最適に作成されるが、こうした初めのファイルは、６０での記憶に先立ってどんな数の形態に変換することもできる。データのフォーマットがどうであれ、そこに表現されているワイルドカード置換えパターン６０は、カスタムロジック５７によってアクセスされて、カスタムロジック５７によって示された方法で、ワイルドカードを適用および実施する。

ポリシー表現言語が、その構文内にワイルドカード定義６０を含み、エンジン５６が、具体的な所望の値を選択するためにカスタムロジック５７を登録する機構を提供する場合、これは、さらに他の拡張性の道を証明書発行システムに提供する。

この場合も、一例が、明確化の助けになることがある。例示的な証明書発行システムは、発行された証明書のフォーマットを定義するポリシーを含むことができる。たとえば、サービスは、「信頼される従業員証明書」をクライアントに発行することができると示す証明書発行ポリシーを含むことができる。発行者は、クライアントの動的な領域に応答しなければならないため、ワイルドカード証明書発行ポリシーが以下のように構築されることがある。

証明書発行システムは、「信頼される従業員証明書」を、それが適切だとみなすどんなクライアントにも発行することができる。

次いで、証明書発行システムの権利者は、「適切とみなす」べきクライアントの明細書を埋めるロジック、たとえば５７を定義し登録することができる。ロジック５７は、具体的なサービスの起動中にどのクライアントが「信頼される従業員証明書」を発行されるべきか決定することができる。このロジック５７は、証明書発行ポリシーでのより一般的なワイルドカード定義文節に遭遇する場合、証明書発行システムによって呼び出すことができる。

図１および２に提供される全般的な枠組みに従って構築することができる様々なコンピューティング環境に照らして、本明細書において提供される各システムおよび方法が、具体的なコンピューティングアーキテクチャに限定されると解釈することは決してできない。代わりに、本発明は、単一のどんな実施形態にも限定されるべきではなく、添付の特許請求の範囲による広さおよび範囲内にあると解釈すべきである。

本発明の様々な態様に関連する使用に適した例示的なコンピューティング装置の基本的な特徴を広く表すブロック図である。コンピューティング装置は、コンピュータ読取り可能な媒体上の命令にアクセスし、証明書発行システムの各機能を実行するために、それらの命令を適切なシーケンスで実行することができる。 証明書発行システムが動作することができる例示的なネットワーク化されたコンピューティング環境を示す図である。発行者は、たとえば装置２７１上に常駐することができる。装置２７７でのクライアントプロセスは、証明書を２７１での発行者から要求し、続いて装置２７５でのサーバプロセスとの通信において、この証明書を使用することができる。 証明書発行システムの翻訳構成部品（ｔｒａｎｓｌａｔｉｏｎ ｃｏｍｐｏｎｅｎｔ）の一部分を示す図である。翻訳構成部品、すなわち翻訳エンジンは、複数のフォーマットの入力証明書を単一の共通フォーマットに移す働きをする。クライアントに引き渡すために発行構成部品３４によって共通フォーマットで生成された証明書は、必要に応じてどんなフォーマットにも翻訳することができる。 入力証明書要求が、発行者によってどのように扱われるかを示す図である。まず、要求がサーバ入口点３０１に届く。その最初のフォーマットたとえば３０２での証明書または他の要求情報が、翻訳層３０３に渡される。これが第２のフォーマット３０４に変換される。次いで、要求３０４と関連した証明書および／または他の情報は、サーバ証明書エンジン３０５によって取り扱われる。 クライアント３１０が証明書を求める要求をサーバ３１３に送る、本発明の他の観点を示す図である。タイプ１の証明書は、クライアント３１０の要求と関連している。タイプ１の証明書は、証明書翻訳エンジン（ＣＴＥ：Ｃｅｒｔｉｆｉｃａｔｅ Ｔｒａｎｓｌａｔｉｏｎ Ｅｎｇｉｎｅ）３１１によってタイプ２の証明書に翻訳することができる。発行エンジン３１２によってタイプ２の証明書を使用して、クライアント３１０の要求を許可するかどうか決定することができる。発行エンジン３１２が証明書を第２のフォーマットで発行する場合、ＣＴＥ３１１は、それをクライアント３１０のための第１のフォーマットに翻訳することができる。 証明書発行システムの発行構成部品の一部分を示す図である。認証４１、許可４２、および資格証明フォーマット化４３は、発行構成部品によって実行することができる例示的な機能である。これらの機能を実行する一環として、汎用のポリシー言語の構文解析および実施エンジン４４は、証明書発行ポリシー４５を適用することができる。したがって、実施すべきポリシーがエンジン４４で表される必要がなく、実行時にエンジン４４によって使用される発行ポリシー４５で表される必要があるという意味では、発行構成部品はデータ駆動型である。 ポリシー表現言語および／または、ポリシー言語の構文解析および実施エンジン５６によって固有にサポートされていない新しい発行ポリシーを適用および実施するための発行構成部品を拡張するためのシステムおよび方法を示す図である。ポリシー言語構文が、たとえば５９で拡張される場合、拡張されたポリシー言語のコントラクト５５の意味を扱うプラグインロジックを、実施エンジン５６に追加することができる。固有のポリシー言語ワイルドカードが使用される場合、拡張ワイルドカード置換えパターン５７を扱うプラグインロジックを実施エンジン５６に追加することができる。

符号の説明

１０２ 処理ユニット
１０３ システムメモリ
１０３Ａ 揮発性
１０３Ｃ 不揮発性
１０４ 取外し可能な記憶装置
１０５ 取外し不可能な記憶装置
１０６ 出力装置
１０７ 入力装置
１０８ 通信接続
２７０ 通信ネットワーク／バス
２７１ コンピューティング装置
２７２ コンピューティング装置
２７３ オブジェクト
２７６ コンピューティング装置
２７７ コンピューティング装置
２７８ データベース

Claims (20)

1. クライアント要求に応答して証明書を生成するための証明書発行システムであって、
   第１のフォーマットでの第１の証明書を受け取り、前記第１の証明書を第２のフォーマットに翻訳するための翻訳構成部品と、
   前記第１の証明書からの情報を証明書発行ポリシーと比較することによって、前記クライアントが第２の証明書を受け取る資格があるかどうか決定するための、また前記証明書発行ポリシーによって要求される少なくとも１つの資格証明を前記クライアントが有することを前記第１の証明書が確認する場合に、前記第２の証明書を発行するための発行構成部品と
   を含むことを特徴とするシステム。
2. 前記第２の証明書が、前記発行構成部品によって前記第２のフォーマットで生成されることを特徴とする請求項１に記載のシステム。
3. 前記発行構成部品は、前記証明書発行ポリシーでの総称的な表現を実施するカスタム構成部品と通信するためのインタフェースを含むことを特徴とする請求項１に記載のシステム。
4. 前記発行構成部品は、前記証明書発行ポリシーの拡張を実施するカスタム構成部品と通信するためのインタフェースを含むことを特徴とする請求項１に記載のシステム。
5. 前記証明書発行ポリシーを前記クライアントに送達するための構成部品をさらに含むことを特徴とする請求項１に記載のシステム。
6. 前記クライアントが前記少なくとも１つの資格証明を有することを前記第１の証明書が確認する場合に、クライアント識別情報が認証されることを特徴とする請求項１に記載のシステム。
7. 前記クライアントが前記少なくとも１つの資格証明を有することを前記第１の証明書が確認する場合に、クライアント許可が確立されることを特徴とする請求項１に記載のシステム。
8. 前記証明書発行ポリシーは、前記第２の証明書の形態を求める要求を含み、前記発行構成部品は、前記形態による前記第２の証明書を生成することを特徴とする請求項１に記載のシステム。
9. セキュリティ証明書をクライアントに発行するための方法であって、
   第１の証明書を第１のフォーマットから第２のフォーマットに翻訳するステップと、
   前記第１の証明書からの情報を証明書発行ポリシーと比較することによって、前記クライアントが第２の証明書を受け取る資格があるかどうか決定するステップと、
   前記証明書発行ポリシーによって要求される少なくとも１つの資格証明を前記クライアントが有することを前記第１の証明書が確認する場合に、前記第２の証明書を生成するステップと
   を含むことを特徴とする方法。
10. 前記第２の証明書が、前記第２のフォーマットで生成されることを特徴とする請求項９に記載の方法。
11. 前記第２の証明書を前記第２のフォーマットから第３のフォーマットに翻訳するステップをさらに含み、前記第３のフォーマットおよび前記第１のフォーマットは同じフォーマットでよいことを特徴とする請求項１０に記載の方法。
12. 前記証明書発行ポリシーの拡張を実施するためのカスタムソフトウェア構成部品と通信するステップをさらに含むことを特徴とする請求項９に記載の方法。
13. 前記少なくとも１つの資格証明を前記クライアントが有することを前記第１の証明書が確認する場合に、クライアント識別情報が認証されることを特徴とする請求項９に記載の方法。
14. 前記第２の証明書を生成するステップは、前記証明書発行ポリシーからの前記第２の証明書の形態を求める少なくとも１つの要求を決定するステップを含むことを特徴とする請求項９に記載の方法。
15. セキュリティ証明書をクライアントに発行するための命令を運ぶコンピュータ読取り可能な媒体であって、
    第１の証明書を第１のフォーマットから第２のフォーマットに翻訳するための命令と、
    前記第１の証明書からの情報を証明書発行ポリシーと比較することによって、前記クライアントが第２の証明書を受け取る資格があるかどうか決定するための命令と、
    前記証明書発行ポリシーによって要求される資格証明を前記クライアントが有することを前記第１の証明書が確認する場合に、前記第２の証明書を生成するための命令と
    を含むことを特徴とするコンピュータ読取り可能な媒体。
16. 前記第２の証明書が、前記第２のフォーマットで生成されることを特徴とする請求項１５に記載のコンピュータ読取り可能な媒体。
17. 前記第２の証明書を前記第２のフォーマットから第３のフォーマットに翻訳するための命令をさらに含み、前記第３のフォーマットおよび前記第１のフォーマットは同じフォーマットでよいことを特徴とする請求項１６に記載のコンピュータ読取り可能な媒体。
18. 前記証明書発行ポリシーの拡張を実施するためのカスタムソフトウェア構成部品と通信するための命令をさらに含むことを特徴とする請求項１５に記載のコンピュータ読取り可能な媒体。
19. 前記少なくとも１つの資格証明を前記クライアントが有することを前記第１の証明書が確認する場合に、クライアント識別情報が認証されることを特徴とする請求項１５に記載のコンピュータ読取り可能な媒体。
20. 前記第２の証明書を生成するための前記命令は、前記証明書発行ポリシーからの前記第２の証明書の形態を求める少なくとも１つの要求を決定するための命令を含むことを特徴とする請求項１５に記載のコンピュータ読取り可能な媒体。
    

Images