JP2007511983A

JP2007511983A - 分散委任されたパス発見及び検証

Info

Publication number: JP2007511983A
Application number: JP2006541603A
Authority: JP
Inventors: エングバーグ、デヴィッド
Original assignee: Corestreet Ltd
Current assignee: Corestreet Ltd
Priority date: 2003-11-19
Filing date: 2004-11-19
Publication date: 2007-05-10
Also published as: ES2572810T3; WO2005052752A3; AU2004294164B2; EP1692596A2; EP1692596B1; CN101124765B; CA2544273C; WO2005052752A2; AU2004294164A1; KR20060097131A; EP1692596A4; US8707030B2; US20050154918A1; CA2544273A1; CN101124765A

Abstract

システムに対するパス検証情報を提供することは、前記システムの証明書のサブセットと少なくとも１つの信頼ルートとの間のパスを決定することと、パス検証情報に対するリスエストに先立って前記パスそれぞれをテーブルに保存することと、パス検証情報のリクエストに応答して、前記テーブルに保存されている前記検証情報を取り出すことと、を含む。また、パス検証情報を提供することは、前記検証情報にデジタル署名することを含んでもよい。また、パス検証情報を提供することは、前記検証情報に制約を適用し、その制約に合致する検証情報のみを提供すること、を含んでもよい。パスを決定することは、信頼ルート及び前記証明書のサブセットの有向グラフを作図することと、そのグラフについて非循環式の深さ優先探索を実行すること、とを含んでもよい。

Description

関連出願の相互参照
この出願は、２００３年１１月１９日に出願された米国仮出願第６０／５２３，３９８号の優先権を主張し、この米国仮出願は、本書の記載に参照により組み込まれる。

技術分野
この出願は、データのセキュリティ及び検証の分野に関し、特に、デジタル証明書及びその他の情報に対する検証及び有効性確認の分野に関する。

関連技術の説明
デジタル証明書が有効に発行されたか否かの判断、及び／又は、デジタル証明書が有効期限満了前に失効しているか否かの判断を含め、デジタル証明書の状態を判断できることは有用である。デジタル証明書の個々の状態を判断する多数の技術がある。例えば、米国特許第５，６６６，４１６号及び第５，７１７，７５８号には、個々の証明書の状態を提供する技術が記述されている。また、失効した証明書のデジタル署名されたリストである証明書失効リスト（ＣＲＬ）等の、証明書の状態を配布して確認するための他の技術も知られている。

デジタル証明書の検証には、そのデジタル証明書の発行者を信頼すること、及び／又は、失効情報の署名者を信頼することが必要となる。これらの発行者及び署名者は、同一のエンティティの場合もあるし、同一のエンティティでない場合もある。デジタル証明書の場合、発行者及び／又は失効情報の署名者を「信頼する」ということは、その発行者及び／又は署名者が、証明書及び／又は失効情報への署名に用いられた秘密鍵に対応する有効な公開鍵を有する既知の機関である、という事実を指す。例えば、ユーザは、ある機関Ａによってデジタル署名されたデジタル証明書を受け取る場合もあるし、また、他の異なる機関Ａ’によって署名された（デジタル証明書を含まない）最新のＣＲＬを受け取る場合もある。しかしながら、ユーザは、上記証明書を有効なものとして受け入れるために、（上記証明書及びＣＲＬに署名するために使用された秘密鍵に対応する）Ａ及びＡ’の公開鍵を信頼できるとともに、それらのＡ及びＡ’の両者を信頼できることを希望するであろう。

証明書及び失効情報を発行する他の未知の機関を配布したり信頼したりすることを容易にする方法がある。ある例では、他の未知の機関を検証するために、情報へのデジタル署名（又はその情報の有効化）を信頼済みの機関に行わせることができる。その後は、それまで未知であった機関は、その機関の公開鍵を用いて検証可能なデジタル署名済みの情報（例えばデジタル証明書及び／又は失効情報）を提供できるようになる。例えば、ユーザが機関Ａ１及びＡ２のデジタル署名を知らない又は信頼していない場合であって、そのユーザが機関Ａ３を知っており信頼している場合には、そのユーザは、Ａ１及びＡ２が信頼できる機関であることを示す、Ａ３によってデジタル署名された（すなわちＡ３によって保証された）情報を取得できる（又は提供を受けることができる）。従って、そのようなユーザが、Ａ１によって署名されたデジタル証明書及びＡ２によって署名された（デジタル証明書を列挙したものではない）ＣＲＬを受け取った場合は、ユーザは、その提供された証明書の有効性を確認するために、Ａ３によって保証された情報を使用することができる。

また、ある機関が他の機関を保証する場合に用いることができるネスティングの方法もある。例えば、本書に参照により組み込まれる米国特許第５，７１７，７５９号には、第１の機関Ａ１が第２の機関Ａ２を保証し、その第２の機関Ａ２が第３の機関Ａ３を保証していくようなネスティングを、見込みユーザによって信頼されている機関に到達するまで行う技術が開示されている。ある例では、「保証する」ということには、その保証する機関のデジタル署名を提供することが含まれる。

ネスティング及びその他の方法は有用である。しかしながら、デジタル証明書及び／又は失効情報及び／又はその他の情報の提供をユーザが受け、それらの証明書／失効情報／その他の情報の署名者が信頼されているか否かのを判断する直接的な方法がなく、そのため、デジタル証明書が現在有効であるか否かをユーザが判断できない場合がある。従って、この問題を解決することは有益である。

発明の概要
本発明によれば、システムに対するパス検証情報を提供することは、そのシステムの証明書のサブセットと少なくとも１つの信頼ルートとの間のパスを決定することと、パス検証情報の要求に先立って前記パスそれぞれをテーブルに保存することと、パス検証情報の要求に応答して、前記テーブルに保存されている前記検証情報を読み出すことと、を含む。また、前記パス検証情報を提供することは、その検証情報にデジタル署名することを含んでもよい。また、前記パス検証情報を提供することは、その検証情報に対して制約を適用することと、その制約に合致する検証情報のみを提供することと、を含んでもよい。パスの決定は、信頼ルート及び前記証明書のサブセットの有向グラフを作図することと、そのグラフについて非循環式の深さ優先探索を実行することと、を含んでもよい。前記テーブルには、前記信頼ルート又は前記証明書を用いて索引をつけてもよい。また、パス検証情報を提供することは、前記証明書のサブセットに対する失効状態のプルーフを受け取ることと、パス検証情報の要求に先だって前記プルーフを保存することと、パス検証情報の要求に応答して、前記検証情報とともに前記プルーフを取り出すことと、を含んでもよい。また、パス検証情報を提供することは、その検証情報に制約を適用することと、その制約に合致する検証情報のみ提供することと、を含んでもよい。また、パスの決定は、信頼ルート及び前記証明書のサブセットの有向グラフを作図することと、そのグラフについて非循環式の深さ優先探索を実行することと、を含んでもよい。前記プルーフは、前記検証情報を含む前記テーブルに保存してもよい。前記テーブルには、前記信頼ルートを用いて索引をつけてもよい。前記テーブルには、前記証明書を用いて索引をつけてもよい。前記プルーフは、前記検証情報を含むテーブルとは別の他のテーブルに保存してもよい。前記他のテーブルは、前記信頼ルート又は前記証明書を用いて索引をつけてもよい。前記証明書のサブセットは、信頼ルートと、エンドユーザ証明書を発行する機関と、他の機関を保証する機関と、を含んでもよい。また、前記証明書のサブセットは、エンドユーザ証明書を含んでもよい。

更に、本発明によれば、システムに対するパス検証情報を提供するコンピュータ・プログラム・プロダクトは、そのコンピュータ・プログラム・プロダクトのための実行可能なコードが入っている保存メディアと、前記システムの証明書のサブセットと少なくとも１つの信頼ルートとの間のパスを決定する実行可能なコードと、パス検証情報の要求に先立って前記パスそれぞれをテーブルに保存する実行可能なコードと、パス検証情報の要求に応答して、前記テーブルに保存されている検証情報を取り出す実行可能なコードと、を含む。また、前記コンピュータ・プログラム・プロダクトは、前記検証情報にデジタル署名する実行可能なコードを含んでもよい。また、前記コンピュータ・プログラム・プロダクトは、前記検証情報に制約を適用し、その制約に合致する検証情報のみを提供する実行可能なコードを含んでもよい。パスを決定する実行可能なコードは、信頼されたルート及び前記証明書のサブセットの有向グラフを作図し、そのグラフについて非循環式の深さ優先探索を実行してもよい。前記テーブルには、前記信頼ルートを用いて索引をつけてもよい。前記テーブルには、前記証明書を用いて索引をつけてもよい。また、前記コンピュータ・プログラム・プロダクトは、前記証明書のサブセットに対する失効状態のプルーフを受け取る実行可能なコードと、パス検証情報の要求に先だって前記プルーフを保存する実行可能なコードと、パス検証情報の要求に応答して、前記検証情報とともに前記プルーフを読み出す実行可能なコードと、を含んでもよい。また、前記コンピュータ・プログラム・プロダクトは、前記検証情報に制約を適用する実行可能なコードと、その制約に合致する検証情報のみ提供する実行可能なコードと、を含んでもよい。また、パスを決定する実行可能なコードは、信頼ルート及び前記証明書のサブセットの有向グラフを作図し、そのグラフについて非循環式の深さ優先探索を実行してもよい。前記プルーフは、前記検証情報を含む前記テーブルに保存してもよい。前記テーブルには、前記信頼ルートを用いて索引をつけてもよい。前記テーブルには、前記証明書を用いた索引をつけてもよい。前記プルーフは、前記検証情報を含む前記テーブルとは別の他のテーブルに保存してもよい。前記他のテーブルは、前記信頼ルート又は前記証明書を用いて索引をつけてもよい。前記証明書のサブセットは、信頼ルートと、エンドユーザ証明書を発行する機関と、他の機関を保証する機関と、を含んでもよい。また、前記証明書のサブセットは、エンドユーザ証明書を含んでもよい。

更に、本発明によれば、サーバは、プロセッサと、そのプロセッサに結合された内部ストレージと、証明書のサブセットと少なくとも１つの信頼ルートとの間のパスを決定する、前記内部ストレージに提供された実行可能なコードと、パス検証情報の要求に先立って前記パスそれぞれをテーブルに保存する、前記内部ストレージに提供された実行可能なコードと、パス検証情報の要求に応答して、前記テーブルに保存されている検証情報を取り出す、前記内部ストレージに提供された実行可能なコードと、を備える。また、前記サーバは、前記検証情報にデジタル署名する、前記内部ストレージに提供された実行可能なコードを、備えてもよい。また、前記サーバは、前記検証情報に制約を適用し、その制約に合致する検証情報のみを提供する、前記内部ストレージに提供された実行可能なコードを、備えてもよい。パスを決定する実行可能なコードは、信頼されたルート及び前記証明書のサブセットの有向グラフを作図し、そのグラフについて非循環式の深さ優先探索を実行してもよい。前記テーブルには、前記信頼ルート又は前記証明書を用いて索引をつけてもよい。また、前記サーバは、前記証明書のサブセットに対する失効状態のプルーフを受け取る、前記内部ストレージに提供された実行可能なコードと、パス検証情報の要求に先だって前記プルーフを保存する、前記内部ストレージに提供された実行可能なコードと、パス検証情報の要求に応答して前記検証情報とともに前記プルーフを取り出す、前記内部ストレージに提供された実行可能なコードと、を備えてもよい。また、前記サーバは、前記検証情報に制約を適用しその制約に合致する検証情報のみ提供する、前記内部ストレージに提供された実行可能なコード、を備えてもよい。パスを決定する実行可能なコードは、信頼ルート及び前記証明書のサブセットの有向グラフを作図し、そのグラフについて非循環式の深さ優先探索を実行してもよい。前記プルーフは、前記検証情報を含む前記テーブルに保存してもよい。前記テーブルには、前記信頼ルートを用いて索引をつけてもよい。前記テーブルには、前記証明書を用いて索引をつけてもよい。前記プルーフは、前記検証情報を含むテーブルとは別の他のテーブルに保存してもよい。前記他のテーブルには、前記信頼ルート又は前記証明書を用いて索引をつけてもよい。前記証明書のサブセットは、信頼ルートと、エンドユーザ証明書を発行する機関と、他の機関を保証する機関と、を含んでもよい。また、前記証明書のサブセットは、エンドユーザ証明書を含んでもよい。

様々な実施形態の詳細な説明
個々の証明書の状態情報を提供する技術は、証明書の検証及び／又は証明書にデジタル署名する機関の検証を行う技術として知られている。例えば、本記載に参照により組み込まれる、米国特許第５，４２０，９２７号；第５，６０４，８０４号；第５，６１０，９８２号；第６，０９７，８１１号；第６，３０１，６５９号；第５，７９３，８６８号；第５，７１７，７５８号；第５，７１７，７５７号；第６，４８７，６５８号；及び第５，７１７，７５９号において提供されている開示内容を参照されたい。本明細書に記載のシステムは、これらの特許の一つ又は二以上に開示されている技術を、おそらく他の適当な技術の一つ又は二以上と組み合わせて使用することができる。使用可能な技術には、単一の技術又は任意の組み合わせ、フルＣＲＬ、区切られたＣＲＬ、デルタＣＲＬ、ＯＣＳＰ応答（個々の応答及びグループでの応答）、ミニＣＲＬ（ビット単位で圧縮されたＣＲＬ）、Ｖトークン（一方向ハッシュチェーン）、及び、様々なマークル（Merkle）ツリー又は他のツリー・インカーネーション（incarnation）、が含まれる。

パス発見は、任意の証明書と、利用者によって信頼された機関に対応するデジタル証明書である利用者の信頼ルートの一つとの間の信頼パス（信頼関係）を見付けるプロセスに関する。信頼パスは、一端にあるターゲット証明書及び他端にある信頼ルートを有する、一つの証明書から他のもう一つの証明書への認証のチェーンである。例えば、証明書Ｃ１が信頼済み機関Ａ１に対応し、そのＡ１が未知の機関Ａ２に対するＣ２に署名し、そして、機関Ａ２が、ターゲット証明書に署名した未知の機関Ａ３に対する証明書Ｃ３に署名した場合は、Ｃ１（信頼ルート）からターゲット証明書までの信頼パスは、Ｃ１からＣ２、Ｃ２からＣ３、Ｃ３からターゲット証明書までである。

ある場合には、パス発見は、信頼パス内の証明書のすべてがローカルで利用可能であればいつでもユーザによってかなり直接的な方法を用いてローカルで実行することができる。しかしながら、相互認証（cross-certification）に基づく連合信頼モデル（federated trust model）を用いるような場合には、ユーザは、ローカルでのパス発見を実行するのに必要なすべての情報を有していない。

また、信頼ルートとターゲット証明書との間に完全な信頼パスが見付けられた場合でも、その信頼パス上の一つ又は二以上の証明書が、その発行後に失効しているおそれがあることに、留意されたい。パス検証は、証明書の使用についてのありとあらゆる規則及び／又は制約（例えばセキュリティポリシーをチェックすること）を考慮するとともに、証明書の有効性（失効状態）等の信頼パスにおけるすべての証明書の最新状態を確認することをいう。信頼パスにおける個々の証明書について失効状態の情報を集めることは、ある状況（例えば公的なネットワークへのアクセスを制限する特別なファイヤーウォールのセッティングがなされている状況）におけるユーザにとっては比較的難しいと思われる。従って、１回のトランザクションで証明書を検証できるサービスを提供できるようにすることは有用である。このサービスの提供には、まず、信頼パスを決定し、その信頼パスにおける証明書について失効情報（及び／又は制約情報）を受け取り、ターゲット証明書を検証するために、上記受け取った情報を処理する。

図１を参照すると、未信頼の委任パス発見・検証（ＵＤＰＤＶ）サーバ３０は、入力として、一つ又は二以上の信頼ルートを特定する情報（信頼された機関に対する証明書）と、ユーザが有効性を検証したいターゲット証明書に対応する識別子（又は、おそらくいくつかの他の情報やデータ）とを受信する。ＵＤＰＤＶサーバ３０は、オプションで、信頼ルートの受信に加えて又はそれに代えて、信頼ルートを予め設定しておくことができる。

もちろん、ユーザがターゲット証明書を発行した機関を既に信頼し、そのターゲット証明書に対する使用可能な失効情報にアクセスできる場合には、その情報を用いてユーザはターゲット証明書を検証することができ、ＵＤＰＤＶサーバ３０を使用する必要がない。従って、ＵＤＰＤＶサーバ３０は、ユーザがターゲット証明書を発行した機関を信頼していない（知らない）場合、及び又は、ユーザがターゲット証明書についての信用できる失効情報を（おそらく、ターゲット証明書を発行した機関の証明書も）所有していない場合であって、そのターゲット証明書の検証をユーザが希望する場合に、有用である。

ＵＤＰＤＶサーバ３０は、ターゲット証明書と信頼ルートとの間の一つ又は二以上のパスを決定するように、上記入力（前述のように、ＵＤＰＤＶサーバ３０へ入力されたもの又は予め設定されたもののいずれか）を処理する。多くの場合、信頼パス内に失効している証明書がないことを確認することもまた有用である点に、留意されたい。そのような場合、認証された失効情報の形式でプルーフ（例えばＣＲＬ又はＯＣＳＰ応答）をＵＤＰＤＶサーバ３０から更に提供させることは、有用である。

このように、図１に開示する実施形態において、ＵＤＰＤＶサーバ３０は、ターゲット証明書に対する信頼パス情報を集め、また、オプションで、パス要素に対する失効情報を集める。ＵＤＰＤＶサーバ３０からユーザへの出力は、独立に認証（例えば署名）されていなくてもよい。その代わりに、ＵＤＰＤＶサーバ３０は、信頼パスの個々の要素（及び、オプションでプルーフ）をすべてユーザに返す。これにより、ユーザは、信頼パスの正しさと、その信頼パスの要素（証明書）の有効性とを、独立に検証することができる。ＵＤＰＤＶサーバ３０の動作については、本書の他のどこかで詳述する。

図２を参照すると、信頼された委任パス発見・検証サーバ４０は、入力として、ユーザの信頼ルートと、ユーザが検証したいターゲット証明書に対応する識別子（又は、おそらくいくつかの他の情報やデータ）とを受信する。上記信頼された委任パス発見・検証サーバ４０は、オプションで、信頼ルートの受信に加えて又はそれに代えて、信頼ルートを予め設定しておくことができる。

上記信頼された委任パス発見・検証サーバ４０は、ターゲット証明書（又は他の情報やデータ）が有効か否かを示す結果を出力する。本書に記載の一実施形態において、サーバ４０は、ユーザへ提供される情報の暗号化によるサーバ自身の認証を実行する。この実施形態では、サーバ４０は、そのサーバによって提供される応答に署名することができる。この署名により、サーバ４０は、少量のデータ（例えば、「はい、あなたは証明書Ｘを信頼できます。」）をユーザに提供できる。しかしながら、そのような実施により、上記信頼された委任パス発見・検証サーバ４０の内部処理の完全性や正しさをユーザが明確に信頼できるようになる。もしサーバ４０がその能力について妥協したものであるならば、サーバ４０は、そのサーバの供給元や現在の状態にかかわらず、証明書を有効にする応答の認証に不適切に使用されることになる。

上記サーバ３０、４０は、プロセッサと実行可能なコードやデータを保存するための内部ストレージとを有するコンピュータ・ワークステーション、汎用コンピュータに用いられる一つ又は二以上のソフトウェアモジュール、専用ハードウェア、又は、本書に記載された機能を提供できるハードウェアとソフトウェアとのすべての組み合わせによって構成することができる。本書に記載のシステムのために、ＵＤＰＤＶサーバ３０は、認証能力（例えばデジタル署名のための秘密鍵）を持つ必要がない一つ又は二以上の軽量サーバで構成してもよい。

ＵＤＰＤＶサーバ３０は、二種類のタイプの情報リストを定期的に設定してもよい。第１のタイプのリストは、パス検証に用いることができる証明書のセットを含み、本書に記載の一実施形態では、ＵＤＰＤＶサーバ３０が（例えばネットワークを介して）アクセス可能な証明書のすべて又はそのほとんどすべてを表示する。他の一実施形態では、第１のタイプのリストは、すべてのエンドユーザの証明書あるいはたとえいかなるエンドユーザの証明書を必ずしも含むことなく、証明書及び失効情報を発行する機関やこれらの機関を保証する機関のみに対する証明書を含む。第１のタイプのリストは、信頼点（trust anchor）としての役割をはたす自己署名されたルート証明書（信頼ルート）を含んでもよい。この信頼ルートは、システムのユーザから信頼された機関が署名してもよい。また、第１のタイプのリストは、証明書を発行する機関、失効情報を発行する機関、及び／又は他の機関を保証する機関、に対する発行者（別名、「認証機関」）証明書を含んでもよい。また、一実施形態では、第１のタイプのリストはエンドユーザの証明書を含んでもよく、一方、他の一実施形態では、第１のタイプのリストはエンドユーザの証明書を含まなくてもよい。第１のタイプの証明書リストは、本書に記載しているように、パス発見サービスの提供に使用することができる。

ＵＤＰＤＶサーバに備える第２のタイプのリストは、事前に生成した証明書状態プルーフを含む。各プルーフは、ある固定された時間間隔について（第１のリスト中の）一つ又は二以上の証明書の状態を含み、また、そのプルーフは、例えばデジタル署名を用いて安全に認証することができる。それらのプルーフは、本書の他のどこかに記載されているように、パス検証サービスを提供するために使用することができる。それらのプルーフは、ＣＲＬ、ＯＳＣＰ応答、Ｖトークン等のなんらかの適切な手段によって供給することができる。

信頼ルートとターゲット証明書との間のパスを調べることは、当該技術分野で知られており、証明書の標準規格（例えば、ＲＦＣ３２８０）の中できちんと解説されている。しかしながら、多数の証明書を通して信頼パスを見付けることは、そのプールの中の証明書の数に基づき指数関数的な時間を要するかもしれない。これは、ある状況下において、及び／又は、証明書の小さなコレクションに対しては、受け入れることができるが、連合された複数の機関からなる大きなコミュニティの場合のような他の状況下では受け入れられない。

本書に記載されているシステムは、発見のリクエストがあったときに、各信頼ルート証明書と、証明書の発行及び／又は他の機関の保証を実行する機関に対する他の到達可能なすべての証明書との間の信頼パスをまず事前計算することにより、対数時間又は一定時間内におけるパス発見を実行するように設計されている。ＵＤＰＤＶサーバ３０は、証明書の新しいリストを受信したとき（又は、新しい証明書のソースに結合されたとき）、Ｍを信頼ルートの数としＮを証明書の総数とした場合の行例Ｍ×Ｎを事前に計算することができる。上記行列の各セル（例えばｒ１行及びｃ１列のセル）は、ｒ１行によって指定される特定の信頼ルートからｃ１列によって指定される特定の証明書までの一つ又は二以上の妥当なパスを含んでもいいし、可能なパスがないことを示す空のセットを含んでもよい。オプションとして、各セル（又は、アナログテーブルの各セル）は、有効性を確認するための適当なプルーフを含んでもよい。

ユーザが、届いたターゲット証明書の検証を要求すると、上記ＵＤＰＤＶサーバ３０は、ターゲット証明書と信頼ルートとの間の一つ又は二以上の有効なパスを見付けるべく、上記ユーザに対する信頼ルートをルックアップするとともに上記ターゲット証明書を発行した機関をルックアップするために、更にオプションで、（発行機関が異なるならば）上記ターゲット証明書に対する失効情報を発行した機関をルックアックするために、上記事前計算された行列を使用する。上記パスはＵＤＰＤＶサーバ３０で事前に計算され保存されているので、上記行列の使用は一定時間のルックアップで実行することができる。二つ以上の可能な信頼パスが存在する場合、又は信頼パス内にあるいずれの証明書に対しても何らかの制限を行う、信頼パスに関連した制約（例えば、名称又はポリシーの制約）がある場合には、そのパスのポリシーは、見つかったいずれの信頼パスに対しても適用する必要があることに留意されたい。すべての可能なパスを事前に計算しておくことにより、ＵＤＰＤＶサーバ３０は、大きなコミュニティに対して、比較的高い性能と拡張性でパス発見を提供できる。

また、パス発見に加えて、ＵＤＰＤＶサーバ３０は、信頼パスの要素（証明書）に対する有効性検証情報（プルーフ）を提供することができる。一実施形態においては、ＵＤＰＤＶサーバ３０は、ユーザに提供された信頼パス内の各要素（証明書）に対するプルーフ（例えば、ＣＲＬ又はＯＣＳＰ応答の形式で）をリアルタイムに取得する。プルーフをキャッシュすることによって性能を向上させることができるが、プルーフをリアルタイムに取得する場合には、リクエストがあったときに最適の性能になっていない可能性がある。他の一実施形態においては、信頼パスの生成に関連してＵＤＰＤＶサーバ３０で使用される各証明書に対するきめの細かい状態プルーフを予め生成した規則的な間隔で受信するパス検証メカニズムを、ＵＤＰＤＶサーバ３０に備えることができる。この実施形態では、ＵＤＰＤＶサーバ３０は、有効性検証のための証明書状態情報をリアルタイムに検索するために余計な処理時間を必要とせずに、信頼する団体に提供される必要な有効性検証情報のすべてに、すばやくアクセスすることができる。

上記プルーフがＵＤＰＤＶサーバ３０に（例えば、事前に署名されたＯＣＳＰ応答の形式で）プッシュされる場合には、ＵＤＰＤＶサーバ３０は信頼パス内にあるすべての証明書の状態に対して即座にローカルアクセスできることに、留意されたい。ある実施形態では、ＵＤＰＤＶサーバ３０は、パス委任のために信頼パスを返す前に信頼パスの状態を確認する。また、ＵＤＰＤＶサーバ３０は、オプションで、信頼パスの有効性検証をユーザがローカルで完了できるように、状態プルーフをユーザに返すことができる。この個別的に事前生成されたプルーフ（例えば、事前に生成されたＯＣＳＰ応答）の内容により、信頼されたオンラインサーバに関連したセキュリティ上のリスクを回避しつつ、ネットワーク資源の効率的な利用が可能になる。

図３を参照すると、ダイヤグラム５０は、第１のエリア５２と、それとは別個の第２のエリア５４とを示している。これらのエリア５２，５４は、それらの間で信号を交換できるように適当な手段（例えば、ネットワーク又は直接接続）によって相互の接続されている。第１のエリア５２は、複数の証明書６２−６４を有している。第２のエリア５４は、別の複数の証明書６６−６８を有している。第１のエリア５２は、その中にいるユーザによってローカルで管理されアクセスされる場所を示している。同様に、第２のエリア５４は、その中にいるユーザによってローカルで管理されアクセスされる、第１のエリアとは別の場所を示している。このように、例えば、エリア５２にいるユーザは、証明書６２−６４のいずれか又はすべてにローカルでアクセスすることができる。

上記エリア５２において、証明書６２は、機関Ａ１に対する自己証明ルート証明書（信頼ルート）である。また、証明書６２は、例えばＡ１が証明書６３に署名することにより、機関Ａ２に対する証明書６３を証明する。証明書６３は、機関Ａ３に対する証明書６４を証明する。この例において、ユーザがＡ１を信頼すると、そのユーザはまた（Ａ１によって保証された）Ａ２も信頼するとともに（Ａ２によって保証された）Ａ３も信頼することになることに、留意されたい。上記エリア５４において、証明書６６は、機関Ａ１’に対する自己証明ルート証明書（信頼ルート）である。また、証明書６６は、機関Ａ２’に対する証明書６７を証明し、証明書６７は、機関Ａ３’に対する証明書６８を証明する。証明書６２は、証明書６２，６６それぞれが証明書６２，６６の他の一方を証明するように、証明書６６との間で相互に証明する。

上記エリア５２にいるユーザは、Ａ３’によって署名されたターゲット証明書を受け取った場合、そのユーザが当初Ａ１，Ａ２及びＡ３についてのみ知っている（そして、信頼している）ならば、ターゲット証明書が有効であることを即座に検証することができない。しかしながら、機関Ａ２’が機関Ａ３’を保証し、機関Ａ１’が機関Ａ２’を保証していることに留意されたい。また、機関Ａ１が機関Ａ１’を保証していることにも留意されたい。従って、エリア５２にいるローカルユーザがＡ１を信頼していると仮定すると、証明書６２から証明書６６、証明書６７、証明書６８、そして、Ａ３’によって署名されているターゲット証明書に至るまでの、上記ユーザに対する信頼パスが存在する。よって、ユーザは、ターゲット証明書から、信頼された機関Ａ１によって署名された証明書までの信頼パスにより、機関Ａ３’によって署名されたターゲット証明書を受け入れることができる。また、本書の他のどこかで説明しているように、本例において信頼パスを受け取ったユーザが証明書６２，６６−６８についての最新の失効情報も受け取ることができるように、（発行機関が異なる場合の）失効情報を発行した機関についてだけでなく、信頼パスに沿った証明書それぞれについても、有効性検証情報（有効性のプルーフ）を提供することもできる。

図４を参照すると、ダイヤグラム８０は、ネットワーク８８によってユーザ８２につながった複数のデータストレージ装置８４−８６の一つ又は二以上から証明書情報（信頼パス情報と、場合によっては有効性検証情報とを含む）を受け取るユーザ８２を図示している。この実施形態において、ユーザとデータストレージ装置８４−８６との間の直接的な接続を提供するネットワーク等のインターネット以外の他の好適なネットワークを使用することができるが、ネットワーク８８はインターネットであってもよい。ユーザ８２が証明書情報をローカルに保存することができることにも留意されたい。この実施形態において、ユーザ８２は、そのユーザが有効性を判断したい一つ又は二以上の証明書が提示される。ある場合には、ユーザ８２は、ローカルデータを使って証明書の有効性を判断する。しかしながら、本書の他のどこかで記載しているように、他の場合には、ユーザ８２はデータストレージ装置８４−８６のような他のソースから証明書情報を取得する必要がある。そのような場合、証明書情報及びその取得のためのリクエストは、ネットワーク８８においてユーザとストレージ装置８４−８６との間で直接的に通信される。もちろん、ここに記載している機能を提供するために、適切な接続や情報リクエスト／伝送の技術を使用することができる。

図５を参照すると、フローチャート１００は、信頼ルート（信頼機関に対するルート証明書）と、証明書の発行及び／又は他の機関の保証を行う一つ又は二以上の他の証明書との間のすべてのパスを持つようにする、ＵＤＰＤＶサーバ３０の初期化を図示している。本書の他のどこかで説明しているように、ユーザがターゲット証明書を提示したときに、ＵＤＰＤＶサーバがテーブルを調べ、ターゲット証明書を発行した機関をルックアップし（又はターゲット証明書そのものをルックアップし）、ターゲット証明書から信頼ルートまでの事前計算された信頼パスを提供できるように、各信頼パスは事前に計算しておく。また、本書の他のどこかで説明しているように、ＵＤＰＤＶサーバ３０は、オプションで、信頼パス内の証明書について、証明書が失効していないことを示すプルーフを提供することができる。

フローチャート１００の処理は最初のステップ１０２で始まり、ここでは、情報が保存されるすべての証明書について有向グラフが作図される。有向グラフは、当該技術分野でよく知られている数学的な作図である。本実施形態では、エンドユーザの証明書を含めたシステム内のすべての証明書が使用される。他の実施形態では、エンドユーザの証明書は含めず、又は、いくつかのエンドユーザの証明書のみが含められる。ステップ１０２において、作図された有向グラフは、証明書間の信頼関係を表し、そのグラフのエッジ（接続ライン）は、（エッジの一端に接続された証明書に対応している）第１の機関が（エッジの他端に接続された証明書に対応している）第２の機関を保証していることを示す。

上記ステップ１０２の次はステップ１０４であり、ここではインデックス変数Ｉに１がセットされる。インデックス変数Ｉは、ＵＤＰＤＶサーバ３０において信頼ルート証明書のそれぞれについて繰り返し処理を行うために用いる。本書の他のどこかで説明しているように、信頼ルート証明書は、ＵＤＰＤＶサーバ３０への入力として提供され、又はＵＤＰＤＶサーバ３０内に予め設定される。

ステップ１０４の次はテストステップ１０６であり、ここではインデックス変数Ｉが信頼ルート証明書の数よりも大きいかが判断される。もしそうである場合は処理が完了する。そうでない場合は、上記有向グラフにおける（インデックス変数Ｉに対応する）信頼ルート証明書から他のすべての証明書までのすべてのパスを判断するために、制御がテストステップ１０６からステップ１０８に移行する。このステップ１０８については、本書の他のどこかでより詳細に説明されている。ステップ１０８の次はステップ１１２であり、ここではインデックス変数Ｉが増分される。ステップ１１２に続いて、制御は、上述のテストステップ１０６に戻るように移行する。

図６を参照すると、フローチャート１２０は、図５のフローチャート１００のステップ１０８に関連して実行される処理をより詳細に図示している。信頼ルートのそれぞれについて、すべての信頼パスを見付けるために上記有向グラフの非循環式の深さ優先探索が実行される。各パスで見つかった証明書のそれぞれについて、その証明書から信頼ルートまでの信頼パスを示すテーブルへのエントリーが行われる。

処理は、最初のステップ１２２で始まり、ここでは、調べるパスが更にあるかが判断される。ある例では、それ自身へのパスがない信頼ルートを持つ可能性があることに、留意されたい。しかしながら、多くの場合には、信頼ルートはそこへのパスを少なくとも１つ有すると予想される。テストステップ１２２で、調べるべきパスがこれ以上ないと判断した場合は、処理は完了する。そうでない場合には、制御は、テストステップ１２２からステップ１２４へ移行し、ここでは、上記有向グラフの非循環式の深さ優先探索を使って次のパスが決定される。ステップ１２４の次はステップ１２６であり、ここでは、証明書ポインターＣＰが、調べられた（処理された）パスの終端のポイントにセットされる。

ステップ１２６の次はテストステップ１２８であり、このステップでは、ＣＰが信頼ルートを指しているか、すなわちパスの全体が横断されたことを示しているか、が判断される。もし、そうである場合は、次の繰り返し処理を開始すべく、上述のように、制御は、テストステップ１２８からステップ１２２に戻るように移行する。そうでない場合は、制御は、テストステップ１２８からステップ１３２へ移行し、ここでは、ＣＰから信頼ルートへのパスが、証明書及びその証明書への信頼パスが保存されている（本書の他のどこかで説明されている）テーブルに記録される。一実施形態では、ステップ１３２で、ＣＰが指している証明書の索引が付けられた上記テーブルの部分に、ＣＰから信頼ルートへのパスが記録される。ステップ１３２の次はステップ１３４であり、ここでは、上記パスにおける一つ前の証明書を指し示すようにＣＰが設定される。このように、ＣＰは、最初に上記パスの終端を指し、その後、信頼ルートに向かって後ろ向きに作用する上記パスにおける一つ前の証明書を指す。上記ステップ１３４に続いて、制御は、上述のように、テストステップ１２８へ戻るように移行する。

図７Ａを参照すると、テーブル１４０は、システム内の証明書の索引が付けられ要素として各証明書への信頼パスを有する、第１の部分１４２を含んでいる。上記テーブル１４０は、システム内の証明書の索引が付けられた第２の部分１４４を含んでもよい。この第２の部分は、対応する証明書のそれぞれに対する失効状態を示しているプルーフ（例えば、ＯＣＳＰ応答、ＣＲＬ等）を記述する要素を有する。ここで説明する一実施形態においては、例えばＣ２の索引が付けられたテーブルへのエントリーがＣ２に対するプルーフに対応するように、上記第２の部分１４４に有するプルーフは、その索引が付けられた証明書に対応する。他の一実施形態においては、上記第２の部分１４４に有するプルーフは、上記第１の部分１４２における特定のエントリーに対するすべてのパス内にあるすべての証明書に対応する。従って、例えば、証明書Ｃ２に結び付けられた、上記第２の部分１４４に有するプルーフは、上記第１の部分１４２におけるＣ２に対するエントリーにある信頼パス内のすべての証明書に対応する。

ある実施形態においては、上記部分１４２，１４４のいずれか一つを消去することができる。従って、例えば、上記部分１４２のみを用いる実施形態においては、上記ＵＤＰＤＶサーバ３０は、事前に計算された信頼パスを提供し、プルーフを提供しない。そのような実施形態では、ユーザは、まったくプルーフなしで済ませるか、リアルタイムでプルーフを取得するか、あるいはそれらのある組合わせを行う（すなわち、パス内のいくつかの証明書についてプルーフを取得し、他の証明書についてはプルーフを取得しない）。上記部分１４４のみを用いる実施形態では、信頼パスをリアルタイムに決定し、部分１４４から事前に計算されたプルーフをＵＤＰＤＶサーバ３０によって提供することができる。

図７Ｂを参照すると、他の一実施形態では、証明書によって索引が付けられた単一のテーブル１４０’が使用され、信頼パス及びプルーフの両方がテーブル１４０’の要素として提供される。

図７Ｃを参照すると、更に他の一実施形態における上記テーブル１４０’’の他の一構成が図示されている。上記テーブル１４０’’は特定の信頼ルート証明書ＴＲ１，ＴＲ２，・・・ＴＲＮと、他の証明書Ｃ１，Ｃ２，・・・ＣＮとによって索引が付けられている。例えば、信頼ルートＴＲｘ及び証明書Ｃｙに対するエントリーが、ＣｙからＴＲｘへの一つ又は二以上の信頼パス（存在している場合）と、オプションで（一実施形態では）Ｃｙに対する又は（他の一実施形態では）信頼パス内のすべての証明書に対する、一つ又は二以上のプルーフとを含むように、上記テーブル１４０’’のエントリーにおける要素は、信頼パスと（オプションで）プルーフ「Ｐ／Ｐ」とを含む。

図８を参照すると、フローチャート１５０は、信頼パスとオプションでその信頼パスの証明書に対するプルーフとを要求するユーザからのリクエストに対するサービスを提供するＵＤＰＤＶサーバ３０に関連した処理のためのステップを図示する。本書の他のどこかで説明しているように、ＵＤＰＤＶサーバ３０には、特定のターゲット証明書が提示され、このターゲット証明書に対して、ＵＤＰＤＶサーバ３０は、信頼パスとオプションでその信頼パス内の各証明書の状態を示すプルーフとを提供する。一実施形態においては、上記信頼パスは、ターゲット証明書を発行した機関に対する証明書と、オプションで、そのターゲット証明書に対する失効情報を発行した機関（上記発行機関と異なる場合）に対する証明書とについて提供される。他の一実施形態においては、ＵＤＰＤＶサーバ３０は、信頼パスとオプションでターゲット証明書そのものに対する失効情報とを提供する。

処理は最初のステップ１５２で始まり、ここでは、ターゲット証明書又はその発行者に対して少しでも利用可能な信頼パスが存在するかが判断される。存在しない場合は、制御はステップ１５２からステップ１５４に移行し、ここでは特別処理が実行される。このステップ１５４における特別処理には、エラーメッセージを知らせること、及び／又はターゲット証明書に対して信頼パスが見つからなかったことを、何らかの他の方法でユーザに示すこと、を含めることができる。ステップ１５４の後、処理は完了する。

上記テストステップ１５２で使用可能な信頼パスが存在していると判断した場合は、制御は、テストステップ１５２からステップ１５６に移行し、ここでは、処理のために次の信頼パスが選択される。一実施形態においては、システムは、ターゲット証明書（又はその発行者）と一つ又は二以上の信頼ルート証明書との間の適当な信頼パスを見付けるために、（テーブル１４０、テーブル１４０’又はテーブル１４０’’によって提供される）各信頼パスについて繰り返す。ステップ１５６で選択される次の信頼パスは、最短パスや、特定の証明書を含むパス等、多くの利用可能な基準を使って選択される。

ステップ１５６の次はテストステップ１５８であり、ここでは、ステップ１５６で選択された特定の信頼パス（その信頼パスの証明書）について制約があるかを判断する。本書の他のどこかで説明しているように、例えば、ある目的のために受け入れられない一つ又は二以上の証明書等のように、特定の信頼パスの使用を制限する一つ又は二以上の制約がある。ステップ１５８で、信頼パスを受け入れ不可にするように検査する制約があると判断した場合には、制御は、上述のように、テストステップ１５８からステップ１５２に戻るように移行する。上記制約がない場合には、制御は、テストステップ１５８からステップ１６２に移行し、ここでは、信頼パス内の証明書に対するプルーフが要求されているかが判断される。要求されていない場合は、制御は、ステップ１６２からステップ１６４に移行し、ここでは、ターゲット証明書（又はその発行者）と信頼ルート証明書との間の信頼パスがユーザに返される。

上記テストステップ１６２でプルーフが要求されていると判断した場合は、制御はテストステップ１６２からステップ１６６に移行し、ここでは、（テーブル１４０、テーブル１４０’又はテーブル１４０’’から）プルーフが取得される。他の実施形態では、プルーフがリアルタイムに取得される。ステップ１６６の次はステップ１６８であり、ここでは、信頼パス及びプルーフが返される。ステップ１６８の後、処理が完了する。

本書の他のどこかで説明しているように、ある例では、ユーザは、特定の証明書が有効か否かを示す署名済みの（又は、そうでなければ、認証済みの）メッセージを返す、信頼された分散委任パス発見・検証サーバ４０の使用を望むかもしれない。このサーバ４０は、特定の証明書が受け入れ可能なものか否かを示すメッセージに署名することができる。ユーザは、パス及び／又は有効性検証情報を直接知ったり調べたりすることなく、上記サーバ４０からの署名済みの応答を信頼することができる。

図９を参照すると、フローチャート１８０は、特定のターゲット証明書が有効か否かを示す署名済みメッセージの作成や返信についてサーバ４０で実行されるステップを図示している。処理は最初のステップ１８２で始まり、ここでは、本書の他の記載に従って信頼パス及びプルーフが取得される。ステップ１８２の次はテストステップ１８４であり、ここでは、ターゲット証明書が有効か否かを判断するために信頼パス及びプルーフが検査される。このステップ１８４での判断は、ステップ１８２で取得された信頼パス及びプルーフを用いて行われる。テストステップ１８４でターゲット証明書が有効であると判断された場合は、制御は、テストステップ１８４からステップ１８６に移行し、ここでは、ターゲット証明書が有効であることを示す肯定的なメッセージが作成される。そうではなく、テストステップ１８４でターゲット証明書が有効でないと判断された場合は、制御は、テストステップ１８４から、否定的なメッセージが作成されるステップ１８８に移行する。

上記ステップ１８６又はステップ１８８の次は、ステップ１９２であり、ここでは、上記メッセージがサーバ４０によってデジタル署名される。ステップ１９２の次は、ステップ１８４であり、ここでは、署名済みの結果がユーザに返される。ステップ１９４の後、処理が完了する。

本書に記載したシステムは、ハードウェア及び／又はソフトウェアの様々な適切な組み合わせを用いて実施することができ、そのソフトウェアには、ストレージ媒体（例えば、ディスク、テープ、ＣＤＲＯＭ、リムーバブルメモリ、等）で提供されるソフトウェアが含まれる。上記ソフトウェアは、特別なハードウェアや汎用コンピュータの上で実行することができ、あるいはそれらの適当な組み合わせて実行することができる。

本発明は様々な実施形態に関連付けて開示されているが、それらに対する修正については当業者により容易に理解されるであろう。従って、本発明の趣旨及び範囲は特許請求の範囲に記載されている。

本書に記載のシステムの一実施形態に係る、未信頼の委任パス検証サーバを図示している。本書に記載のシステムの一実施形態に係る、信頼された委任パス検証サーバを図示している。本書に記載のシステムの一実施形態に係る、ローカル証明書情報をそれぞれ含む２つの相互接続されたエリアを図示している。本書に記載のシステムの一実施形態に係る、ユーザと証明書情報の通信を行うためのネットワークの使用を図示している。本書に記載のシステムの一実施形態に係る、信頼パスの前計算を図示するフローチャートである。本書に記載のシステムの一実施形態に係る、証明書及び信頼パスのテーブルへのデータ取り込み並びに信頼パスを介した反復を図示するフローチャートである。本書に記載のシステムの一実施形態に係る、信頼パス及び／又はプルーフを含むテーブルを図示している。本書に記載のシステムの一実施形態に係る、信頼パス及び／又はプルーフを含むテーブルを図示している。本書に記載のシステムの一実施形態に係る、信頼パス及び／又はプルーフを含むテーブルを図示している。本書に記載のシステムの一実施形態に係る、前計算された信頼パス及び／又はプルーフの返答を図示するフローチャートである。本書に記載のシステムの一実施形態に係る、信頼された委任パス検証サーバによって実行される処理を図示するフローチャートである。

Claims

システムに対するパス検証情報を提供する方法であって、
前記システムの証明書のサブセットと少なくとも１つの信頼ルートとの間のパスを決定することと、
パス検証情報に対するリスエストに先立って前記パスそれぞれをテーブルに保存することと、
パス検証情報のリクエストに応答して、前記テーブルに保存されている前記検証情報を取り出すことと、を含む。
請求項１の方法において、
前記検証情報にデジタル署名すること、を更に含む。
請求項１の方法において、
前記検証情報に制約を適用し、その制約に合致する検証情報のみを提供すること、を更に含む。
請求項１の方法において、
パスを決定することは、信頼ルート及び前記証明書のサブセットの有向グラフを作図することと、そのグラフについて非循環式の深さ優先探索を実行することと、を含む。
請求項１の方法において、
前記テーブルは、前記信頼ルートを用いて索引がつけられている。
請求項１の方法において、
前記テーブルは、前記証明書を用いて索引がつけられている。
請求項１の方法において、
前記証明書のサブセットに対する失効状態のプルーフを受け取ることと、
パス検証情報のリクエストに先立って前記プルーフを保存することと、
パス検証情報のリクエストに応答して前記検証情報とともに前記プルーフを取り出すことと、を更に含む。
請求項７の方法において、
前記検証情報及び前記プルーフにデジタル署名すること、を更に含む。
請求項７の方法において、
前記検証情報に制約を適用し、前記制約に合致する検証情報のみを提供すること、を更に含む。
請求項７の方法において、
パスを決定することは、信頼ルート及び前記証明書のサブセットの有向グラフを作図することと、そのグラフについて非循環式の深さ優先探索を実行することと、を含む。
請求項７の方法において、
前記プルーフは、前記検証情報を含む前記テーブルに保存される。
請求項１１の方法において、
前記テーブルは、前記信頼ルートを用いて索引がつけられている。
請求項１１の方法において、
前記テーブルは、前記証明書を用いて索引がつけられている。
請求項７の方法において、
前記プルーフは、前記検証情報を含んでいる前記テーブルとは別の他のテーブルに保存される。
請求項１４の方法において、
前記他のテーブルは、前記ルートを用いて索引がつけられている。
請求項１４の方法において、
前記他のテーブルは、前記証明書を用いて索引がつけられている。
請求項１の方法において、
前記証明書のサブセットは、信頼ルートと、エンドユーザ証明書を発行する機関と、他の機関を保証する機関と、を含む。
請求項１７の方法において、
前記証明書のサブセットは、エンドユーザ証明書を更に含む。
システムに対するパス検証情報を提供するコンピュータ・プログラム・プロダクトであって、
前記コンピュータ・プログラム・プロダクトのための実行可能なコードを含むストレージ媒体と、
前記システムの証明書のサブセットと少なくとも１つの信頼ルートとを決定する実行可能なコードと、
パス検証情報のリクエストに先立って前記パスそれぞれをテーブルに保存する実行可能なコードと、
パス検証情報のリクエストに応答して、前記テーブルに保存されている検証情報を取り出す実行可能なコードと、を備える。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
前記検証情報にデジタル署名する実行可能なコードを、更に備える。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
前記検証情報に制約を適用し、その制約に合致する検証情報のみを提供する実行可能なコードを、更に備える。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
パスを決定する実行可能なコードは、信頼ルート及び前記証明書のサブセットの有向グラフを作図し、そのグラフについて非循環式の深さ優先探索を実行する。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
前記テーブルは、前記信頼ルートを用いて索引が付けられている。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
前記テーブルは、前記証明書を用いて索引がつけられている。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
前記証明書のサブセットに対する失効状態のプルーフを受け取る実行可能なコードと、
パス検証情報のリクエストに先立って前記プルーフを保存する実行可能なコードと、
パス検証情報のリクエストに応答して前記検証情報とともに前記プルーフを取り出す実行可能なコードと、を更に備える。
請求項２５のコンピュータ・プログラム・プロダクトにおいて、
前記検証情報及び前記プルーフにデジタル署名する実行可能なコードを、更に備える。
請求項２５のコンピュータ・プログラム・プロダクトにおいて、
前記検証情報に制約を適用し、前記制約に合致する検証情報のみを提供する実行可能なコード、を更に備える。
請求項２５のコンピュータ・プログラム・プロダクトにおいて、
パスを決定する実行可能なコードは、信頼ルート及び前記証明書のサブセットの有向グラフを作図することと、そのグラフについて非循環式の深さ優先探索を実行する。
請求項２５のコンピュータ・プログラム・プロダクトにおいて、
前記プルーフは、前記検証情報を含む前記テーブルに保存される。
請求項２９のコンピュータ・プログラム・プロダクトにおいて、
前記テーブルは、前記信頼ルートを用いて索引がつけられている。
請求項２９のコンピュータ・プログラム・プロダクトにおいて、
前記テーブルは、前記証明書を用いて索引がつけられている。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
前記プルーフは、前記検証情報を含んでいる前記テーブルとは別の他のテーブルに保存される。
請求項３２のコンピュータ・プログラム・プロダクトにおいて、
前記他のテーブルは、前記信頼ルートを用いて索引がつけられている。
請求項３２のコンピュータ・プログラム・プロダクトにおいて、
前記他のテーブルは、前記証明書を用いて索引がつけられている。
請求項１９のコンピュータ・プログラム・プロダクトにおいて、
前記証明書のサブセットは、信頼ルートと、エンドユーザ証明書を発行する機関と、他の機関を保証する機関と、を含む。
請求項３５のコンピュータ・プログラム・プロダクトにおいて、
前記証明書のサブセットは、エンドユーザ証明書を更に含む。
サーバであって、
プロセッサと、
前記プロセッサに結合された内部ストレージと、
システムの証明書のサブセットと少なくとも１つの信頼ルートとの間のパスを決定する、前記内部ストレージに提供された実行可能なコードと、
パス検証情報に対するリスエストに先立って前記パスそれぞれをテーブルに保存する、前記内部ストレージに提供された実行可能なコードと、
パス検証情報のリクエストに応答して、前記テーブルに保存されている前記検証情報を取り出す、前記内部ストレージに提供された実行可能なコードと、を備える。
請求項３７のサーバにおいて、
前記検証情報にデジタル署名する、前記内部ストレージに提供された実行可能なコード、を更に備える。
請求項３７のサーバにおいて、
前記検証情報に制約を適用し、その制約に合致する検証情報のみを提供する、前記内部ストレージに提供された実行可能なコード、を更に備える。
請求項３７のサーバにおいて、
パスを決定する実行可能なコードは、信頼ルート及び前記証明書のサブセットの有向グラフを作図し、そのグラフについて非循環式の深さ優先探索を実行する。
請求項３７のサーバにおいて、
前記テーブルは、前記信頼ルートを用いて索引がつけられている。
請求項３７のサーバにおいて、
前記テーブルは、前記証明書を用いて索引がつけられている。
請求項３７のサーバにおいて、
前記証明書のサブセットに対する失効状態のプルーフを受け取る、前記内部ストレージに提供された実行可能なコードと、
パス検証情報のリクエストに先立って前記プルーフを保存する、前記内部ストレージに提供された実行可能なコードと、
パス検証情報のリクエストに応答して前記検証情報とともに前記プルーフを取り出す、前記内部ストレージに提供された実行可能なコードと、を更に備える。
請求項４３のサーバにおいて、
前記検証情報及び前記プルーフにデジタル署名する、前記内部ストレージに提供された実行可能なコード、を更に備える。
請求項４３のサーバにおいて、
前記検証情報に制約を適用し、前記制約に合致する検証情報のみを提供する、前記内部ストレージに提供された実行可能なコード、を更に備える。
請求項４３のサーバにおいて、
パスを決定する実行可能なコードは、信頼ルート及び前記証明書のサブセットの有向グラフを作図し、そのグラフについて非循環式の深さ優先探索を実行する。
請求項４３のサーバにおいて、
前記プルーフは、前記検証情報を含んでいる前記テーブルに保存される。
請求項４７のサーバにおいて、
前記テーブルは、前記信頼ルートを用いて索引がつけられている。
請求項４７のサーバにおいて、
前記テーブルは、前記証明書を用いて索引がつけられている。
請求項４３のサーバにおいて、
前記プルーフは、前記検証情報を含んでいる前記テーブルとは別の他のテーブルに保存される。
請求項５０のサーバにおいて、
前記他のテーブルは、前記信頼ルートを用いて索引がつけられている。
請求項５０のサーバにおいて、
前記他のテーブルは、前記証明書を用いて索引がつけられている。
請求項３７のサーバにおいて、
前記証明書のサブセットは、信頼ルートと、エンドユーザ証明書を発行する機関と、他の機関を保証する機関と、を含む。
請求項５３のサーバにおいて、
前記証明書のサブセットは、エンドユーザ証明書を更に含む。