JP2007518369A - Ｏｃｓｐ及び分散型ｏｃｓｐのための効率的に署名可能なリアルタイム・クレデンシャル - Google Patents

Abstract

デジタル証明書の有効性についての情報提供は、デジタル証明書セット内の複数のデジタル証明書それぞれのデジタル証明書有効性ステータスの確認と、複数のデジタル証明書のデジタル証明書セットの少なくともサブセットの有効性ステータスについての複数の人工的に事前計算されたメッセージの生成（メッセージの少なくとも一つは二つ以上のデジタル証明書有効性ステータスを示す）と、デジタル証明書セット内の特定のデジタル証明書についてのＯＣＳＰ問合に応答するＯＣＳＰ形式の応答を提供するための前記事前計算のメッセージへのデジタル署名（少なくとも一つのデジタル証明書は二つ以上のデジタル証明書に対するＯＣＳＰ形式の応答に関連付けて使用される）とを含む。生成及びデジタル署名はＯＣＳＰ形式の応答で答えられるＯＣＳＰ問合よりも先に行われる。デジタル証明書有効性ステータスの確認はデジタル証明書についての認証情報の取得を含む。

Description

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

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

関連技術の説明
デジタル証明書は、インターネット認証の効果的な方法を提供する。従来のパスワードやＰＩＮとは異なり、デジタル証明書は広く一般的な検証方法でトランザクションを認証する。このため、デジタル署名されたトランザクションを拒否することは、可能であったとしても非常に難しい。デジタル証明書は、署名鍵ＳＫによって生成され、マッチング検証鍵によって検証される。ユーザＵは、そのＵだけが自分自身のために署名できるように、自分のＳＫを秘密にしておく。幸いにも、鍵ＰＫがマッチング鍵ＳＫを裏切るということはなく、すなわち、ＰＫを知っていることが、ＳＫを計算する上でいかなる実際上の利益をもたらすことはない。従って、ユーザＵは、そのＵの署名をみんなが検証できるように自分自身のＰＫをできる限り公にする。このため、ＰＫは公開鍵と呼ばれる。

デジタル証明書は、所与の鍵ＰＫが本当にユーザＵの公開鍵であることの保証を提供することによってデジタル署名を可能にする英数字の文字列である。認証機関（ＣＡ）は、証明書を生成してユーザに発行するが、そのような証明書の発行は、多くの場合、そのユーザの身元が確認された後にだけ行われる。このため、証明書は、その所有者の身元及び可能な場合は他の属性がＣＡによって検証済みであることを証明する。証明書は、指定期間が経過した後に、公的な認証機関の場合はたいてい１年後に、有効期限が満了する。

本質的には、デジタル証明書Ｃは、いくつかの量、すなわち、その証明書に一意のシリアル番号ＳＮと、ユーザの公開鍵ＰＫと、ユーザの名前Ｕと、発効日Ｄ_１と、有効期限満了日Ｄ_２と、付加データと、を一緒に安全に結び付けるＣＡのデジタル署名よりなる。記号で表すと、
C=SIG_CA(SN, PK, U, D₁, D₂, ...)
である。

デジタル証明書が有効に発行されたか否かの判断、及び／又は、デジタル証明書が有効期限満了前に失効しているか否かの判断を含め、デジタル証明書のステータスを判断できることは有用である。デジタル証明書の個々のステータスを判断する多数の技術がある。例えば、米国特許第５，６６６，４１６号及び第５，７１７，７５８号には、個々の証明書のステータスを提供する技術が記述されている。また、失効した証明書のデジタル署名されたリストである証明書失効リスト（ＣＲＬ）や、ある特定の証明書のステータスについて問い合わせる方法を指定するオンライン証明書ステータスプロトコル（ＯＣＳＰ）等の、証明書のステータスを配布して確認するための他の技術も知られている。

ＣＲＬは、失効した証明書のシリアル番号を含む適切に日付が付けられてデジタル署名されたリスト（ＣＲＬ）を各ＣＡが定期的に発行することによって機能する。ある実装では、ＣＲＬは、所与の証明書セットの失効したすべての証明書を含む。このように、デジタル証明書は、最新のＣＲＬと比較される電子的なトランザクションで提供される。上記所与の証明書が有効期限満了になっていないのに失効しているとしてリストにある場合は、その証明書が有効ではなく証明書の所有者がデジタル証明書によって可能になるトランザクションを実行する権限をもはや与えられていないことを、ＣＲＬから知ることができる。一方、証明書がＣＲＬに見当たらない場合は、その証明書は有効であると考えられる。いずれの場合も、ＣＲＬは、将来におけるトランザクションの有効性を証明できるように、あるいは失効した証明書の場合にサービスの拒否を正当化できるように、各トランザクションの他の記録とともに保管される。

１０％の失効率を仮定すると、平均して、１０のデジタル証明書のうちの一つが有効期限満了前に失効する。そのような失効率によれば、１０００万の証明書を有しているシステムは、１００万のシリアル番号を含むＣＲＬを生成し、そのことはＣＲＬを扱いにくいものとしている。この問題は、ごく最近導入されたＣＲＬ区切り技術によって小さくなってきたが、多くの証明書の失効情報を一緒にまとめるという基本的な方法はまだ不便さとコストを生じさせているようである。シリアル番号が（数１００万の証明書を扱えるように）２４ビット長の場合、１０００の証明書のサブＣＲＬは、依然として２４０００ビット（３０００バイト）もの長さになる。ある配備では、各証明書に対するＣＲＬの入力は、オーバヘッドを入れて２２バイト程度になり、１０００の証明書のサブＣＲＬは２２０００バイトの長さになる。これは、たとえば無線トランザクションのような状況では受け入れがたく、（将来の紛争や可能性のある法的なクレームに対する保護のために）、このような多数のビットを送信しなければならないということは非現実的であろう。

ＣＲＬは、ひとまとめに扱われる多くの証明書について失効の（そして、間接的に有効性の）プルーフを提供するので、大きくなっていく。これと対照的に、ＯＣＳＰは、個々の証明書の有効性のプルーフを提供する。従来のＯＣＳＰサービスはＯＣＳＰレスポンダを使用し、このＯＣＳＰレスポンダは、所与のＣＡによって発行された所与の証明書の有効性について顧客（例えば、信頼パーティ）からの問い合わせを受け、そして、その問い合わせに対する応答で、証明書のステータス及び時間情報の両方を示すデジタル署名された回答を提供する。

ＯＣＳＰサービスを提供するために、従来のＯＣＳＰレスポンダは、ＣＡの証明書のすべてのステータスについての情報の提供を受ける。多くの場合、自分自身の証明書のステータスを決めることはＣＡ次第であるので、ＯＣＳＰレスポンダがＣＡ自身である場合は、そのＯＣＳＰレスポンダ／ＣＡは、証明書の失効ステータスについての情報をすでに所有している。これに対し、ＯＣＳＰレスポンダがＣＡでない場合は、そのＯＣＳＰレスポンダはＣＡの証明書のステータスについて更新され続けられる。例えば、米国特許第５，７１７，７５８号「証人に基づく証明書失効システム（Witness-Based Certificate Revocation System）」を参照されたい。

ＣＡは、最新のＣＲＬを送ることによってＯＣＳＰレスポンダを更新する。ＯＣＳＰレスポンダは、現在のＣＲＬの時間、次の更新の時間および実際の処理の時間を示す署名された応答を、そのＯＣＳＰレスポンダから信頼パーティ（relying party）に提供できるように、ある注目している特定の証明書が現在有効であるかそれとも失効しているかを推論するための相談をＣＡに対して行う。

もちろん、悪意のある／十分な性能を有しないＯＣＳＰレスポンダは、ＣＡの相談の有無にかかわらず、所与のＣＡの証明書についての任意の署名された回答を提供することができる。従って、所与のＣＡの証明書に関するＯＣＳＰレスポンダのデジタル署名された回答を信頼パーティが安全に信頼できるように、ＯＣＳＰは、ＣＡがＯＣＳＰレスポンダにレスポンダ証明書を提供する仕組みを有し、そのレスポンダ証明書は、ＣＡによって署名され、基本的にＣＡの証明書に関する正確なプルーフを提供しているＯＣＳＰレスポンダをＣＡが信頼していること他者に保証するものである。この処理が適切に行われるように、（すべてのＣＡだけでなく）各ＯＣＳＰレスポンダは秘密の署名鍵を所有し、この鍵が（例えば、記憶装置にレスポンダを実装したサーバを設置することによって）保護されなければならないことに留意されたい。

図１を参照すると、ダイアグラム４０は、従来のＯＣＳＰ環境における情報の流れを図示している。ダイアグラム４０は、ＣＡ４２、従来のＯＣＳＰレスポンダ４４、および信頼パーティ４６を含んでいる。ＣＡ４２およびＯＣＳＰレスポンダ４４に使用されている太線は、システムが信頼性よく機能するように保護されなければならない秘密鍵の存在を示している。ＣＡ４２は、有効性情報（例えばＣＲＬ）をＯＣＳＰレスポンダ４４に提供する。信頼パーティ４６は、ＯＣＳＰ要求５２をＯＣＳＰレスポンダ４４に提供する。ＯＣＳＰレスポンダ４４は、（例えばＣＲＬの形式で）ＣＡ４２によって提供された有効性情報を検査し、問い合わせがあった証明書の有効性ステータスを決定する。そして、ＯＣＳＰレスポンダ４４は、対応する応答を準備し、その応答にデジタル署名し、その結果をＯＣＳＰ応答５４として信頼パーティ４６に提供する。ある場合には、ＯＣＳＰレスポンダ４４は、そのＯＣＳＰレスポンダ４４がＣＡ４２によって権限が与えられ信頼されているレスポンダ証明書５６も、信頼パーティ４６に提供する。

ＯＣＳＰには重大な欠点がある。まず、デジタル署名は、計算が集中する処理である。従来のＯＣＳＰレスポンダによって各ＯＣＳＰ応答上に作られるデジタル署名は、要求があったときに生成され、有効性検証処理における最も計算が集中する部分である。例えば、デジタル署名を生成することにより、トランザクション時間に５０ミリ秒から１秒までの時間が追加される。従来のＯＣＳＰレスポンダが、デジタル証明書Ｃについて最初に問い合わせがあった後、そのデジタル証明書についてデジタル署名をキャッシュし、その後にＣについて問い合わせがあったときにそのキャッシュした署名を送る場合でさえ、Ｃについて問い合わせた最初のユーザに対する回答は、最初のデジタル署名の生成によってかなり遅れる。

更に、単一のＯＣＳＰレスポンダの場合は、証明書の有効性の問い合わせが結局、その単一のＯＣＳＰレスポンダに送られ、主要なネットワーク隘路（ボトルネック）になるとともにかなりの混雑と遅延を引き起こす。ものすごい数の正直なユーザがこのＯＣＳＰレスポンダに突然問い合わせをしたとしたら、混乱をもたらすサービスの拒否という状況がおそらく続いて起こるであろう。

一方、ＯＣＳＰの集中化された実装の隘路の問題を防止するために、組織は、（証明書の有効性についての）要求の負荷を、いくつかの適切に認証された従来のＯＣＳＰレスポンダに分散することを検討する場合がある。一般に、単一のサーバの負荷を、（伝送隘路を回避するために）世界中に戦略的に配置されているいくつかの（例えば１００の）サーバに分散すると、ネットワークの混雑が緩和される。しかし、ＯＣＳＰの場合、証明書の有効性の問い合わせに対して署名された応答を提供するために、１００の分散された従来のＯＣＳＰレスポンダはそれぞれ自分自身の秘密証明鍵を持つので、負荷分散は付加的な問題をもたらす。すなわち、上記１００のサーバのいずれかの能力が低下することは、事実上全体の組織の能力が低下することになる。実際に、もし従来のＯＣＳＰレスポンダの能力が低下した場合には、攻撃者は、（１）有効な証明書が失効している、または（２）失効した証明書が依然として有効である、ということを誤って示す応答に署名するために、発見された秘密署名鍵を使用するであろう。上記後者の誤った肯定的な応答は、例えば解雇された従業員が再びシステムへアクセスすることを許容してしまうことになる。

レスポンダの能力低下を回避する一方法は、２４ｘ７監視で、安全な保管庫（secure vault）から実行することである。残念ながら、この方法はコストのかかるオプションになっている。例えば金融関係のＣＡの要求すべてを満たす真の安全な保管庫は、最初に構築するのに１００万ドルを超えるコストがかかり、それを操作するのに１年あたり１００万ドルを超えるコストがかかる。更に、組織がそのような経費を獲得したとしても、保管庫を一晩で構築することはできない。従って、ＣＡが現在ある従来のＯＣＳＰレスポンダの負荷を減少させるために更にいくつかの保管庫を必要とする場合には、適切に保管された新規のＯＣＳＰレスポンダが構築される前に数ヶ月の遅れが生じてしまう。

更に、複数の保管庫にコストをかけることでは、ＯＣＳＰのセキュリティ問題を解決できない。これは、従来のＯＣＳＰレスポンダが信頼できないソース（信頼パーティ）からきた要求を受け、そのレスポンダの秘密署名鍵を用いて上記要求に対するサービスを提供することを、上記ＯＣＳＰのメカニズムが必要とするからである。悪意のある信頼パーティ（または信頼パーティのふりをする悪意のあるエージェント）は、基礎になっているオペレーティングシステムにおいて考えられる弱点につけこむことによってＯＣＳＰレスポンダが署名した鍵を暴露しようとする。

更に、互いに相違するセキュリティドメインに起因してＯＣＳＰが証明書有効性の要求に対するサービスを提供できないということがある。例えば、組織Ａによって運営されている従来のＯＣＳＰレスポンダは、その組織ＡのＣＡの証明書ステータスについて応答を容易に提供できるが、他の組織によって運営されているＯＣＳＰレスポンダは、「外部の（foreign）」証明書について応答を提供できるだけの十分な情報を有していない。

この特定の知識がないことによって生じる問題は、二つの方法のいずれか一つによって解決できる。第一の方法では、組織Ｂの信頼パーティは、組織Ａのレスポンダから、組織ＡのＣＡから発行された証明書のステータスを取得することができる。しかし、この方法では、組織ＡのＯＣＳＰレスポンダは組織Ｂの信頼パーティから地理的に離れているので、ネットワーク時間が検証処理全体にわたってかなり遅くなるという、性能の限界がある。第二の代替方法は、組織Ａから外部レスポンダへのＣＲＬの転送を組織ＡのＣＡに行わせることにより、組織Ｂのレスポンダが組織Ａの証明書について応答できるようにすることである。実際にはＣＲＬはデジタル署名され秘密にしておく必要がなく、組織ＡのＣＡはおそらく、組織Ａの証明書の有効性ステータスを最も多くの人々に知らせようとするであろう。この第２の代替方法は、組織ＢのＯＣＳＰレスポンダに、組織Ｂの証明書についての信頼パーティからの要求に対して回答するために十分な情報を提供する。しかし、信頼パーティが、組織ＢのＯＣＳＰレスポンダのデジタル署名された回答を本当に取得しようとするためには、組織ＡのＣＡはまた、組織Ａの証明書についての有効性の問い合わせに回答するために、外部のレスポンダを認証しなければならない。

図２を参照すると、ダイアグラム６０は、図１のダイアグラム４０に示されているＣＡ４２、従来のＯＣＳＰレスポンダ４４及び信頼パーティ４６を図示している。しかし、ダイアグラム６０によって図示されている状況では、信頼パーティ４６は、ＣＡ４２によって管理されていないが代わりに他のＣＡ６４によって発行され管理されている証明書についてのＯＣＳＰ要求６２を提供する。このような場合には、ＯＣＳＰレスポンダ４４は、ＣＡ４２からＯＣＳＰレスポンダ４４に提供されたＣＲＬ４８内の情報のみに基づいてＯＣＳＰ応答を提供しない。その代わりに、ＣＡ６４は、別のＣＲＬ６６及び別のレスポンダ証明書６８をＯＣＳＰレスポンダ４４に提供する。ＯＣＳＰレスポンダ４４は、外部の証明書についてのＯＣＳＰレスポンス７２を定式化するために、上記別のＣＲＬ６６を使用する。ある場合には、ＯＣＳＰレスポンダ４４は、信頼パーティ４６にレスポンダ証明書６８も提供する。

この第２の代替方法は、より優れた拡張性及び性能を提供できるが、二つの組織間のセキュリティ及び信頼フローを混乱させる。ダイアグラム６０において、ＯＣＳＰレスポンダ４４は、ＣＡ６４の証明書がまだ有効である信頼パーティに対して権限のある応答を行っている。もし、ＯＣＳＰレスポンダ４４が、（間違った構成、敵からの攻撃または直接的な不正行為等の）何らかの理由のために間違った応答をした場合は、ＯＣＳＰレスポンダ４４は、ＣＡ６４の組織に悪影響を及ぼす。ＣＡ６４の証明書について権限のある主張をＯＣＳＰレスポンダ４４に許可することにより、ＣＡ６４の組織は、従来から所有していた信頼のいくらかを放棄している。

一例として、上記組織がクレジットカード発行者である場合を考える。組織Ａの銀行は、ユーザに対する証明書を失効させ、組織Ａの従来のＯＣＳＰレスポンダが安全であって信頼できるものであることを保証するために支払う。仮に組織ＢのＯＣＳＰレスポンダが間違って構築されたとすると、組織Ｂの取引先の信頼パーティがユーザの有効性について問い合わせたとき、組織Ｂのレスポンダは、ユーザが有効であるという間違った応答をしてしまう。上記取引先は、この回答を受け入れ、上記失効したユーザに対する手続きを進めるトランザクションを許可する。このタイプの組織間の信頼の委任は、ある場合には受け入れることができるが、従来のＯＣＳＰの大規模な異種混在の配置のための一般的に有用な代替方法ではない。

上述の問題を解決するシステムを提供することが望まれている。

発明の概要
本発明によれば、デジタル証明書の有効性に関する情報を提供することは、デジタル証明書セットの中の複数のデジタル証明書それぞれに対してデジタル証明書有効性ステータスを確認することと、前記複数のデジタル証明書からなるデジタル証明書セットの少なくともサブセットの有効性ステータスについて人工的に事前計算された複数のメッセージを生成すること（ここで、前記メッセージの少なくとも一つは、二つ以上のデジタル証明書の有効性ステータスを示す。）と、前記デジタル証明書セット内の特定のデジタル証明書についてのＯＣＳＰ問い合わせに応答するＯＣＳＰ形式の応答を提供するために前記人工的に事前計算されたメッセージにデジタル署名すること（ここで、少なくとも一つのデジタル署名は、二つ以上のデジタル証明書に対するＯＣＳＰ形式の応答に関連付けて使用される。）と、を含む。生成及びデジタル署名は、前記ＯＣＳＰ形式の応答のいずれかによって回答されるすべてのＯＣＳＰ問い合わせに先だって行ってもよい。デジタル証明書有効性ステータスを確認することは、デジタル証明書について認証された情報を取得することを含んでもよい。前記デジタル証明書について認証された情報は、証明書を失効させることもできるエンティティによって生成されてもよい。

更に、本発明によれば、コンピュータ読み取り可能なメディアに保存されデジタル証明書の有効性に関する情報を提供するコンピュータソフトウェアは、デジタル証明書セット内の複数のデジタル証明書それぞれに対してデジタル証明書有効性ステータスを確認する実行可能なコードと、前記複数のデジタル証明書からなるデジタル証明書セットの少なくともサブセットの有効性ステータスについて人工的に事前計算された複数のメッセージを生成する実行可能なコード（ここで、前記メッセージの少なくとも一つは、二つ以上のデジタル証明書有効性ステータスを示す。）と、前記デジタル証明書セット内の特定のデジタル証明書についてのＯＣＳＰ問い合わせに応答するＯＣＳＰ形式の応答を提供するために前記人工的に事前計算されたメッセージにデジタル署名する実行可能なコード（ここで、少なくとも一つのデジタル署名は二つ以上のデジタル証明書に対するＯＣＳＰ形式の応答と関連付けて用いられる。）と、を備える。デジタル証明書有効性ステータスを確認する実行可能なコードは、デジタル証明書について認証された情報を取得する実行可能なコードを備えてもよい。前記デジタル証明書について認証された情報は、証明書を失効させることもできるエンティティによって生成されてもよい。前記デジタル証明書について認証された情報は、ＣＲＬであってもよい。複数の人工的に事前計算された応答を生成する実行可能なコードは、前記デジタル証明書セット内の少なくともすべての失効していないデジタル証明書に対する応答を生成する実行可能なコードを備えてもよい。前記コンピュータソフトウェアは、更に、前記デジタル証明書セット内のデジタル証明書有効性ステータスについて問い合わせる信頼パーティによる要求に対してサービスを提供する複数のレスポンダに、デジタル署名された前記人工的に事前計算されたメッセージを転送する実行可能なコードを備えてもよい。前記コンピュータソフトウェアは、更に、前記人工的に事前計算された応答へのデジタル署名に関連付けたデジタル署名の検証に使用される公開検証鍵を含む特別な証明書を、前記レスポンダが利用できるようにする実行可能なコードを備えてもよい。前記特別なデジタル証明書を発行するエンティティは、更に、前記デジタル証明書セットの証明書を発行してもよい。前記人工的に事前計算された複数の応答を生成しその人工的に事前計算された応答にデジタル署名する実行可能なコードは、前記応答の生成及び前記応答への署名を定期的に行ってもよい。

更に、本発明によれば、デジタル証明書の有効性に関する情報を提供することは、複数の署名鍵／検証鍵ペアーを取得すること（ここで、前記署名鍵はそれぞれデジタル署名を提供し、その署名鍵に対応する前記検証鍵の一つは前記デジタル署名を検証し、前記署名鍵を用いて複数のデータ要素に対して一緒にデジタル署名することは、前記データ要素それぞれに対して個別にデジタル署名することよりも計算処理の上で効率的である。）と、デジタル証明書セット内の複数のデジタル証明書それぞれについてデジタル証明書有効性ステータスを確認することと、前記デジタル証明書セットの少なくともサブセットの有効性ステータスについて人工的に事前計算された複数のメッセージを生成することと、前記ペアの署名鍵を用いて、前記人工的に事前計算されたメッセージに対してデジタル署名を一緒に行うことと、を含む。デジタル証明書有効性ステータスを確認することは、デジタル証明書について認証された情報を取得することを含んでもよい。前記デジタル証明書について認証された情報は、証明書を失効させることもできるエンティティによって生成されてもよい。前記デジタル証明書について認証された情報は、ＣＲＬであってもよい。前記人工的に事前計算された応答は、ＯＣＳＰ形式の応答であってもよい。複数の人工的に事前計算された応答を生成することは、前記デジタル証明書セット内の少なくともすべての失効していないデジタル証明書についての応答を生成することを含んでもよい。デジタル証明書の有効性に関する情報を提供することは、前記人工的に事前計算されたメッセージにデジタル署名した後、前記デジタル証明書セット内のデジタル証明書有効性ステータスについて問い合わせる信頼パーティによる要求に対してサービスを提供する複数のレスポンダに、前記デジタル署名の結果を転送することを含んでもよい。複数の人工的に事前計算された応答の生成及び前記人工的に事前計算された応答のデジタル署名は、定期的に実行してもよい。前記人工的に事前計算された応答は、前記人工的に時算計算された応答が生成された時に対応する時間情報を含んでもよい。デジタル証明書の有効性に関する情報を提供することは、前記検証鍵を認証することを含んでもよい。前記検証鍵を認証することは、単一のデジタル証明書に前記検証を提供することを含んでもよい。前記検証鍵を認証することは、別々に分離されたデジタル証明書に前記検証鍵それぞれ提供することを含んでもよい。

更に、本発明によれば、コンピュータ読み取り可能なメディアに保存されデジタル証明書の有効性に関する情報を提供するコンピュータソフトウェアは、複数の署名鍵／検証鍵ペアーを取得する実行可能なコード（ここで、前記署名鍵はそれぞれデジタル署名を提供し、その署名鍵に対応する前記検証鍵の一つは前記デジタル署名を検証し、前記署名鍵を用いて複数のデータ要素に対して一緒にデジタル署名することは、前記データ要素それぞれに対して個別にデジタル署名することよりも計算処理の上で効率的である。）と、デジタル証明書セット内の複数のデジタル証明書それぞれについてデジタル証明書有効性ステータスを確認する実行可能なコードと、前記デジタル証明書セットの少なくともサブセットの有効性ステータスについて人工的に事前計算された複数のメッセージを生成する実行可能なコードと、前記ペアの署名鍵を用いて、前記人工的に事前計算されたメッセージに対してデジタル署名を一緒に行う実行可能なコードと、を備える。デジタル証明書有効性ステータスを確認する実行可能なコードは、デジタル証明書について認証された情報を取得する実行可能なコードを備えてもよい。前記デジタル証明書について認証された情報は、証明書を失効させることもできるエンティティによって生成されてもよい。前記デジタル証明書について認証された情報は、ＣＲＬであってもよい。前記人工的に事前計算された応答は、ＯＣＳＰ形式の応答であってもよい。複数の人工的に事前計算された応答を生成する実行可能なコードは、前記デジタル証明書セット内の少なくともすべての失効していないデジタル証明書についての応答を生成する実行可能なコードを備えてもよい。前記コンピュータソフトウェアは、前記検証鍵を認証する実行可能なコードを備えてもよい。前記検証鍵を認証する実行可能なコードは、単一のデジタル証明書に前記検証を提供してもいいし、又は別々に分離されたデジタル証明書に前記検証鍵をそれぞれ提供してもよい。

更に、本発明によれば、第１のパーティと第２のパーティとの間のトランザクションを円滑に行うことは、前記トランザクションの初期化に先立って前記パーティの一つが特定のデジタル証明書について人工的に事前計算されたＯＣＳＰ応答を取得すること（ここで、前記人工的に事前計算されたＯＣＳＰ応答は、前記第１のパーティ及び第２のパーティのいずれとも異なるエンティティによって生成される。）と、前記パーティの一つが前記トランザクションを初期化することと、そのトランザクションに関連して前記第１のパーティが前記特定のデジタル証明書を前記第２のパーティに提供することと、前記第２のパーティが前記人工的に事前計算されたＯＣＳＰ応答を用いて前記特定のデジタル証明書を検証することと、を含む。前記第２のパーティは、前記初期化されるトランザクションに先立って前記人工的に事前計算されたＯＣＳＰ応答を取得してもよい。前記第２のパーティは、将来のトランザクションのために前記人工的に事前計算されたＯＣＳＰ応答をキャッシュしてもよい。前記第１のパーティは、前記初期化されるトランザクションに先立って前記人工的に事前計算されたＯＣＳＰ応答を取得してもよい。前記第１のパーティは、将来のトランザクションのために前記人工的に事前計算されたＯＣＳＰ応答をキャッシュしてもよい。第１のパーティと第２のパーティとの間のトランザクションを円滑に行うことは、更に、前記第１のパーティが、初期化されるトランザクションの後に、前記人工的に事前計算されたＯＣＳＰ応答を前記第２のパーティに提供することを含んでもよい。

更に、本発明によれば、デジタル証明書の有効性を確認することは、前記デジタル証明書の有効性に関するデジタル署名されたメッセージを検査すること（ここで、前記メッセージは、前記デジタル証明書を発行するエンティティとは異なる特別のエンティティによってデジタル署名される。）と、前記デジタル証明書及びそのデジタル証明書を発行するエンティティを認証する証明書の少なくとも一つからの情報を用いて前記デジタル署名されたメッセージを検証することと、を含む。前記情報は、前記メッセージのデジタル署名に用いた秘密鍵に対応する公開鍵であってもよい。前記情報は、前記メッセージにデジタル署名する前記特別なエンティティを認証する特別なデジタル証明書に対応するものであってもよい。

更に、本発明によれば、デジタル証明書セット内の個々のデジタル証明書についてデジタル証明書有効性ステータスを確認することは、前記デジタル証明書セットの少なくともサブセットの有効性ステータスについてデジタル署名され人工的に事前計算された複数のメッセージを定期的に生成することと、前記デジタル証明書セット内のデジタル証明書有効性ステータスについて問い合わせる信頼パーティによる要求に対してサービスを提供する複数のレスポンダに、前記デジタル署名された人工的に事前計算されたメッセージを定期的に転送すること（ここで、ある証明書についてのメッセージは、他の証明書についてのメッセージとは異なる頻度で転送される。）と、を含む。失効した証明書についてのメッセージは、有効な証明書についてのメッセージよりも少なく頻度で転送してもよい。

更に、本発明によれば、コンピュータ読み取り可能なメディアに保存されデジタル証明書の有効性を確認するコンピュータソフトウェアは、前記デジタル証明書の有効性に関するデジタル署名されたメッセージを検査する実行可能なコード（ここで、前記メッセージは、前記デジタル証明書を発行するエンティティとは異なる特別のエンティティによってデジタル署名される。）と、前記デジタル証明書及びそのデジタル証明書を発行するエンティティを認証する証明書の少なくとも一つからの情報を用いて前記デジタル署名されたメッセージを検証する実行可能なコードと、を備える。前記情報は、前記メッセージのデジタル署名に用いた秘密鍵に対応する公開鍵であってもよい。前記情報は、前記メッセージにデジタル署名する前記特別なエンティティを認証する特別なデジタル証明書に対応するものであってもよい。

更に、本発明によれば、コンピュータ読み取り可能なメディアに保存されデジタル証明書の有効性に関する情報を提供するコンピュータソフトウェアは、デジタル証明書セット内の個々のデジタル証明書についてデジタル証明書有効性ステータスを確認する実行可能なコードと、前記デジタル証明書セットの少なくともサブセットの有効性ステータスについてデジタル署名され人工的に事前計算された複数のメッセージを定期的に生成する実行可能なコードと、前記デジタル証明書セット内のデジタル証明書有効性ステータスについて問い合わせる信頼パーティによる要求に対してサービスを提供する複数のレスポンダに、前記デジタル署名された人工的に事前計算されたメッセージを定期的に転送する実行可能なコード（ここで、ある証明書についてのメッセージは、他の証明書についてのメッセージとは異なる頻度で転送される。）と、を備える。失効した証明書についてのメッセージは、有効な証明書についてのメッセージよりも少ない頻度で転送してもよい。

本書に記載のシステムは、費用効率が高く、安全で、拡張性が高く、しかも全体的に効率的なクレデンシャル（credential）／特権（privilege）の有効性検証システムであり、従来のＯＣＳＰ類似の方法を飛躍的に改良したものである。本書に記載のシステムは、ＯＣＳＰ標準との互換性を維持するオプションを用いるときでも、定性的に優れたセキュリティ及び拡張性を提供するように、従来のＯＣＳＰよりもかなり優れた効果を奏する。

本書に記載のシステムは、従来のＯＣＳＰとは独立に動作する一般的な独立型のシステムである。しかし、ある実施形態では、本システムはＯＣＳＰに準拠し、信頼パーティがＯＣＳＰフォーマット等によって証明書の有効性の情報を要求して検証できるように、本書に記載のシステムによる有効性のプルーフそれぞれは、構文上正しくデジタル署名されたＯＣＳＰ応答として構造化される。デジタル署名は、計算が集約される処理である。しかし、本書に記載のシステムは、この面倒な処理を単一の専用サーバ又は他の実施形態では少数の専用サーバに集中させている。従って、各更新時に要求されるデジタル署名のすべてを扱うことができる十分な性能を有するコンピュータで、非常に簡易にしかも比較的安価に、前記単一の専用サーバ（少数の専用サーバ）を設けることができる。本書に記載のシステムで使用されるレスポンダは、ちょっとしたデータ読み出しと転送の動作を実行することだけが要求され、複雑なデジタル署名を実行する必要がある従来のＯＣＳＰレスポンダよりも高速に、外部からやってくる信頼パーティの問い合わせに対するサービスを提供できる。

本書に記載のシステムのレスポンダは、ちょっとした普通のハードウェアを採用することができ、セキュアであることが要求されないので、このレスポンダは購入して動作させる上で比較的安価である。その結果、比較的多数のレスポンダを比較的低価格で配置することができる。従って、多数の証明書の有効性ステータス要求が短い時間に生成される場合でも、その負荷は多数のレスポンダにわたって分散され、高いコストをかけることなくサービスの混雑及び悪意のない拒否のリスクが減少される。本書に記載のシステムのデジタル署名の数は、証明書の数に依存し、有効性ステータス要求の数にはあまり依存せずに独立したものであることに留意されたい。よって、デジタル署名された応答を提供する単一のサーバは、比較的多数の有効性要求が予想される場合でも使用することができる。

本書に記載のシステムでは、単一の専用サーバ（又は少数の専用サーバ）のみ、及び（単一の専用サーバとＣＡとが異なる場合は）そのＣＡが、保護／保管される必要がある。実際に、本書に記載の前記システムのレスポンダは、秘密鍵をまったく保存しておらず、そのレスポンダに提供された事前計算された応答のデジタル署名を保存しているだけである。応答のデジタル署名は、一度計算されると、悪意をもって変更することができず、そのため秘密にしておく必要がない。これとは対照的に、従来のＯＣＳＰレスポンダはそれぞれ秘密署名鍵を有しており、その秘密署名鍵の漏洩は全体システムの性能を低下させるので、従来のＯＣＳＰレスポンダはすべて保護が必要である。従って、単一のサイト（又は少数のサイト）を防衛することは、互いに等しく重要な多くのサイトを防衛することよりも好ましく且つ容易であるので、本書に記載のシステムはＯＣＳＰよりも安全である。

更に、ＯＣＳＰとは異なり、信頼パーティは、本書に記載のシステムにソフトウェア攻撃を容易にマウントすることができない。信頼パーティがトロイの木馬のようなものを問い合わせに埋め込むのに成功したとしても、本書に記載のシステムのレスポンダは秘密事項を保持しておらずレスポンダに提供された事前計算されたデジタル署名を保存して返すだけであるので、いかなる秘密事項も公にさらされることはないであろう。悪意のある信頼パーティが公にさらしたいと思うものは、完全で正確なデジタル署名された、有効且つ所与の時間間隔で失効される証明書のアカウントである。しかし、これは、秘密でない情報というだけでなく、実際には、ＣＡによって発行された失効した証明書に信頼パーティが間違って依存するのを回避するためにＣＡが一般に知りたいと思う情報である。

更に、ソフトウェア攻撃は、事前計算された応答にデジタル署名する単一の専用サーバ（又は少数の専用サーバ）に容易にマウントできないことに注目されたい。ある実施形態では、単一の専用サーバ（又は少数の専用サーバ）は、信頼されていないソースからの要求を処理せず、ＣＡからの情報を受け、デジタル署名された情報をレスポンダに提供するだけである。従って、トロイの木馬を注入する能力は、本書に記載のシステムにおいて必ずしも利用できない。

これらの利点に加え、本書に記載のシステムは、複数の組織を含む異種混在の配置の範囲内で自由度がかなり高い。１つの組織のレスポンダは、他の組織に信頼（trust）を分散させることなく、人工的に事前計算された応答を他のもう１つの組織に転送することができる。第１の組織は、その第１の組織の証明書の有効性ステータスに対するコントロールを断念することなく、他のもう１つの組織のレスポンダが有効性について説得力のあるプルーフを第１の組織に提供できるようにする。すなわち、本書に記載のシステムにおいて、信頼（trust）は、セキュリティ又はコントロールのいかなる損失も発生させることなく、１つの組織からもう１つの組織に流れることができる。ある実施形態では、レスポンダは、固定された信頼点（trust point）というよりは、透過的なネットワーク基盤として扱われる。これは、インターネットのＤＮＳ基盤によって提供されるサービスの集まり（service cloud）に類似し、その中では、簡単に相互操作可能なネームサーバの異種混在の集合が問い合わせに対する有効な応答を発見してキャッシュすることができる。

安全な異種混在状態（Secure heterogeneity）は、従来のＯＣＳＰよりも優れた本書に記載のシステムの主要な利点である。安全な異種混在状態により、互いに異なる組織の信頼パーティが安全で信頼おける効率的な方法で他の組織の証明書を相互に検証できるように、広範囲の様々な組織が相互に操作できる。

本書に記載のシステムは、任意の数の保護されていないレスポンダに問い合わせの負荷を分散させながら、すべての有効性検証の信頼（trust）を単一の権限機関（又は少数の権限機関）に提供する。本書に記載のシステムは、レスポンダがたとえ保護されていない場合でも、比較的多数のレスポンダに頼る分散実行においても安全性を低下させない。本書に記載のシステムは、問い合わせに対する応答時間を改善する。本書に記載のシステムは、異種混在の環境における外部のレスポンダに信頼（trust）を委任しない。

様々な実施形態の詳細な説明
本書に記載のシステムは、代替的に分散ＯＣＳＰ（ＤＯＣＳＰ）として参照されるリアルタイム・クレデンシャル（ＲＴＣ）を使用し、ＲＴＣ機関（ＲＴＣＡ）として参照されるエンティティを使用する。ＲＴＣＡは、所与の企業のＣＡと一致する場合もあるし一致しない場合もある。ある実施形態では、各ＣＡは、特別な証明書であるＲＴＣＡ証明書を自己所有のＲＴＣＡに提供する。ＣＡは、そのＣＡがＲＴＣＡを信頼していることとＣＡによって発行された証明書についての証明書有効性情報を提供する権限をＣＡがＲＴＣＡに与えることを示す、ＲＴＣＡ証明書へのデジタル署名を行うことができる。ＲＴＣＡ証明書は、ＲＴＣＡステータスを（例えば、所与の識別子やＯＩＤ番号等によって特定される）所与のエンティティに伝え、（所与のエンティティが対応する秘密署名鍵を所有している）所与の検証鍵ＰＫを所与のエンティティと結び付けることができる。

ＣＡとＲＴＣＡとが同一である事例では、ＲＴＣＡがＣＡとは異なる署名鍵を所有することができるという利点がある。このようにＣＡとＲＴＣＡとが同じエンティティである場合には、そのエンティティのＣＡ要素は本質的に証明書の発行のみを行い、エンティティのＲＴＣＡ要素は、例えば特定の証明書が有効であるか失効しているかを証明することによって証明書の管理のみを行う。従って、ＣＡとＲＴＣＡとが同一である場合でも、ＲＴＣＡ証明書は使用される。

ある実施形態では、各ＣＡは、一つのＲＴＣＡのみに関連付けられる。他の実施形態では、各ＣＡは、二つ以上のＲＴＣＡと関連付けることができ、各ＲＴＣＡは互いに異なる署名鍵を所有するか、又はＲＴＣＡのいくつか若しくはすべては署名鍵を共有する。一つのＣＡに関連付けて複数のＲＴＣＡを持つことは、冗長性という目的のために利益がある。他の実施形態では、複数のＣＡに関連付けて一つ又は二つ以上のＲＴＣＡを持つこともできる。

ＣＡが署名鍵を保護するように、ＲＴＣＡは、例えば保管庫（vault）、安全な設備又は安全なハードウェアによって署名鍵を保護する。ある実施形態では、ＲＴＣＡは、秘密署名鍵を有する二つ以上のサーバを含む保護された設備内に受け入れられる。その設備は、秘密署名鍵の複製を安全に保存することができる。ＲＴＣＡは、ＣＡによって適切に認証された秘密署名鍵をそれぞれ有する二つ以上のサーバを含むことができる。

ＣＡは、例えばＣＲＬを用いたり又は他の適当な方法を用いたりすることにより、ＣＡの証明書の有効性ステータスがＲＴＣＡに通知されるような状態にする。ＣＡは、（１）証明書の有効性の変化があったらできるだけ速やかにその変化をオンライン方式でＲＴＣＡに知らせ、及び／又は、（２）予め決められた固定の時間間隔で及び／又はＣＡが新しいＣＲＬを作成したときはいつでもＣＲＬをＲＴＣＡに送る。ＣＡは、個々の証明書のステータス情報を提供する多数の技術の一つ又は二つ以上を（単独で又は組み合わせて）用いることができる。例えば、本書の記載に参照により組み込まれる、米国特許第５，４２０，９２７号；第５，６０４，８０４号；第５，６１０，９８２号；第６，０９７，８１１号；第６，３０１，６５９号；第５，７９３，８６８号；第５，７１７，７５８号；第５，７１７，７５７号；第６，４８７，６５８号；及び第５，７１７，７５９号において提供されている開示内容を参照されたい。本書に記載のシステムは、これらの特許の一つ又は二つ以上に開示されている技術を、場合によっては他の適当な技術の一つ又は二つ以上と組み合わせて、用いることができる。使用可能な技術には、単一の技術又は任意の組み合わせ、フルＣＲＬ、区切られたＣＲＬ、デルタＣＲＬ、ＯＣＳＰ応答（個々の応答及びグループでの応答）、ミニＣＲＬ（ビット単位で圧縮されたＣＲＬ）、Ｖトークン（一方向ハッシュチェーン）、及び、様々なマークル（Merkle）ツリー又は他のツリー・インカーネーション（incarnation）、が含まれる。

日付列Ｄ1，Ｄ2，...，のいずれかの日付Ｄiにおいて、ＲＴＣＡは、最新の有効性ステータスの知識に基づき（例えば、ＣＡの最新のＣＲＬに基づき）、信頼パーティの要求からは独立して、ＣＡの各未処理の証明書を処理することによって更新を実行し、各証明書のステータスを記述している宣言にデジタル署名する。各証明書のステータスは、例えば有効、失効、又は保留（場合によっては、「不明」）と判断される。署名された宣言は時間間隔Ｔを指定する。ある実施形態では、各更新において、すべての署名済み宣言は、同じ時間間隔Ｔを指定し、またある実施形態では、時間間隔の全体は連続している。例えば、各更新日Ｄiにおいて、時間間隔はＴ＝Ｄi＋１−Ｄiとなり、場合によってはＤi＋１及びＤiのいずれか一方だけがＴの部分になり、他の日付は隣接する時間間隔の部分になる。ある実施形態では、証明書ステータスに関するＲＴＣＡの現在の知識がＣＲＬに基づいているときは、各ＤiはあるＣＲＬの日付と一致し、Ｄi＋１はその次のＣＲＬに一致し、以下同様になる。しかし、そのような厳格な時間依存性が必須ではないは高く評価される。例えば、ＲＴＣＡがその宣言の処理を実行又は開始する日付は、Ｄ1，Ｄ2，等であり、一方、宣言の中で指定された時間間隔は、Ｄ1’，Ｄ2’，等であり、Ｄi及びＤi’は互いに異なり、及び／又は互いに独立である。例えば、Ｄiは、Ｄi’よりも早い日であり、この場合には、ＲＴＣＡ、時間間隔Ｔの先頭までに宣言の処理を終了したいので、宣言の時間間隔の先頭よりも前に宣言の処理を開始する。

ある実施形態では、ＣＲＬがＣＡからのＲＴＣＡ更新に使用される場合には、宣言の時間及びＣＲＬの時間も互いに異なる。処理時間とＣＲＬの時間と宣言の時間との間の同期の予想される欠落は、本書に記載のシステムに対しては重要ではない。実際には、イベントに気付いて適切に反応するにはいくらかの追加の時間が必要となるので、「リアルタイム」は非現実的である。まず、ＣＲＬはＲＴＣＡ処理を行わせるが、そのＣＲＬはリアルタイムに作成されるものではないことに留意されたい。更に、証明書を失効させる処理もリアルタイムではない。例えば、ユーザは自分の秘密鍵が劣化したことを気付き、そして、その劣化が実際に発生してから１日だけ経過してから、自分が所有する証明書を失効させる要求を行う。このようにユーザの証明書は１日遅れで失効するが、この遅れは、ＲＴＣＡの計算によるリアルタイムからのずれと比較して、無視できる程度である。

ＲＴＣＡは、所与の時間間隔Ｔにおける各証明書のステータスを示すデジタル署名を事前に計算する。そのような事前計算は、証明書の有効性についてのパーティの要求とは独立に実行される。ある実施形態では、ＲＴＣＡは、証明書Ｃについてのステータス要求がなされる前、おそらく前記時間間隔がちょうど開始する前に、所与の時間間隔に証明書Ｃのステータスの署名された宣言を事前に計算する。

ある実施形態では、証明書ステータスについてＲＴＣＡが署名した宣言は、標準のＯＣＳＰフォーマットになっている。これは、既存の信頼パーティＯＣＳＰソフトウェアを修正する必要なしにＲＴＣシステムの利益を享受できるようにＯＣＳＰソフトウェアがすでに所定の場所に存在している状況において、有用である。ある実施形態では、ＯＣＳＰの準拠は、関連した量、デジタル署名アルゴリズム、ＯＩＤ等の具体的な選択によって提供される。

多くの場合、ＲＴＣＡは、失効した証明書に対してだけではなく、むしろ全ての発行された証明書に対して応答を生成する必要がある。各発行された証明書のシリアル番号の存在を判断するために、ＲＴＣＡには、ＣＡ又は他のエンティティによって、内部追跡のために全ての証明書の複製が与えられ、又は、ＲＴＣＡには、個々の証明書の送信を含まない他の方法を介して、発行されたシリアル番号が与えられる。ある実施形態において、発行された証明書の情報は、証明書に対するシリアル番号が連続した順番に発行される特別な場合には、ＲＴＣＡに対して明示的に提供される必要がない。連続したシリアル番号が使用されるときは、ＲＴＣＡは、現在のＣＲＬだけを使用して各証明書シリアル番号の存在を推測することを選ぶ。これは、ＣＲＬ内の最下位及び最上位のシリアル番号を判断することによってなされる。上位と下位のシリアル番号の間の範囲内にある中間の番号はＣＡによって発行されていることが分かる。この範囲内の番号がＣＲＬ内に存在している場合は、そのステータスが失効していることが分かる。上記範囲内の中間の番号が存在していない場合には、その対応する証明書は、失効していないと判断され、ＯＣＳＰ標準では「有効」と定義される。

最下位のＣＲＬエントリーよりも小さく又は最上位のＣＲＬエントリーよりも大きいシリアル番号を有するように発行された少数の証明書は存在するが、上述した技術は発行された証明書の大部分を扱う。ＲＴＣＡは、ＣＲＬ内の最初のエントリーの前及びＣＲＬ内の最後のエントリーの後の両方に有効なシリアル番号の固定番号を仮定する構成パラメータを介して、上記追加のシリアル番号を含む。例えば、ＲＴＣＡは、有効な証明書を表すように、最下位ＣＲＬエントリーの前に１００個のシリアル番号を指定し、最上位ＣＲＬエントリーの後に５００個のシリアル番号を指定する。この最適化処理により、ＲＴＣＡは、多数の要素（個々の証明書）の代わりに、１つのデータ要素（ＣＲＬ）を検索できるようになる。最上位端に使用される上位の番号は、下位から上位にかけて連続したシリアル番号とともに証明書が発行される状況で新規に発行される証明書を受け入れる場合に有用である。ある実施形態では、発行された証明書に対する最下位及び最上位のシリアル番号は、ＲＴＣＡに対して明示的に提供され、ある実施形態では、その情報はデジタル署名される。

上記事前に計算された構文上正しいＯＣＳＰ応答は、元の／初期の要求に対する応答として計算されないので、技術的にはＯＣＳＰ応答でないと判断されることに留意されたい。本質的には、ＲＴＣＡは、まだ生成されていないＯＣＳＰ要求に対するＯＣＳＰ準拠の応答を事前に計算する。従って、ＲＴＣＡ応答は、人工的に事前計算された応答であるとみなされる。また、ＯＣＳＰに準拠していない実装においても、デジタル署名されたＲＴＣＡ宣言を表現するために、人工的に事前計算された応答という用語を使用することができる。

人工的に事前計算された応答を生成した後、ＲＴＣＡは、他のパーティに利用可能な応答を作る。特に、ＲＴＣは、有効性ステータス問い合わせに応答するために信頼パーティに応答を戻す。しかし、他の実施形態では、ＲＴＣＡは、ＲＴＣレスポンダに利用可能な人工的に事前計算された応答を作成する。ＲＴＣＡ署名メッセージ（人工的に事前計算された応答）は実際上、不正に修正されたり又は気付かれないやり方で変更されたりすることはないので、ＲＴＣレスポンダを保護する必要がない。このため、ＲＴＣＡは、セキュリティを危うくすることなく外部のレスポンダ（他の組織に属するレスポンダ）に、人工的に事前計算された応答を送ることができる。

ある実施形態では、ＲＴＣＡは、適切に組織化されたやり方で人工的に事前計算された応答をＲＴＣレスポンダに提供することにより、ＲＴＣレスポンダによる処理をやりやすくする。例えば、ＲＴＣＡは、証明書のシリアル番号に従って又は長さなどに従って順序付けられた人工的に事前計算された応答を提供する。すべての関連する人工的に事前計算された応答が受け付けられることを保証するために、すべての更新時に、ＲＴＣＡは、人工的に事前計算された応答の全体に署名し日付を付けることにより、追加の署名を有するＲＴＣレスポンダを提供する。ある実施形態では、デジタル署名の有無にかかわらず、人工的に事前計算された応答の数のカウントであるチェックサム又はそれと同様な仕組みを用いることができる。

更に、ＲＴＣＡは、ＣＡによって発行された証明書についての証明書有効性情報を提供するＲＴＣＡをＣＡが信頼して権限を与えることを証明するために、ＣＡによって生成されたＲＴＣＡ証明書をＲＴＣレスポンダに送ってもよい。ある実施形態では、すべての更新時にこれを実行する必要はない。ある例においては、ＲＴＣＡは、最初だけ、ある固定された期間に、又は要求に応答して、ＲＴＣＡ証明書をＲＴＣレスポンダに送る。

ＲＴＣレスポンダは、受け取った人工的に事前計算されたＲＴＣＡの応答を十分な時間だけ保存することができる。ある実施形態では、ＲＴＣＡの署名が所与の時間間隔Ｔに関連している場合は、ＲＴＣレスポンダは、少なくともＴの終端まで、人工的に事前計算された応答を保存する。ある実施形態では、ＲＴＣＡと同様に同じ組織に属するＲＴＣレスポンダのような少なくともいくつかのＲＴＣレスポンダは、情報が正しく且つ最新であることを保証する手順を定期的に実行する。例えば、ＲＴＣレスポンダは、時間間隔Ｔについて人工的に事前計算された応答がＴの最初までに又はＴに関係した他の適当な時刻までに受けたことを検証したり、受けたすべてのＲＴＣＡ署名（及び、おそらく適切なＲＴＣＡ証明書）を検証したり、すべての署名（例えば、少なくとも予想される証明書の数、発行済みの証明書に対して最近送信された署名以上の署名、など）をＲＴＣレスポンダが受けたかを検証したり、失効したと過去に宣言された証明書に対する有効性を示す情報をＲＴＣレスポンダが受けたかを検証したり、ＲＴＣＡ証明書そのものが（例えばセキュリティの低下によって）失効していないことを検証したりする。問題が見つかった場合は、ＲＴＣレスポンダはＲＴＣＡ又は他の適当なエンティティに知らせる。

上記信頼パーティは、証明書の有効性ステータスをＲＴＣに問い合わせる。ある実施形態では、その要求はＯＣＳＰフォーマットになっている。所与の証明書の有効性について問い合わせたとき、ＲＴＣレスポンダは、ＲＴＣＡが生成した、上記特定の証明書について人工的に事前計算された応答を、メモリから取り出して信頼パーティに返す。ある実施形態では、ＲＴＣレスポンダはまた、上記人工的に事前計算された応答に署名したＲＴＣＡに対して証明書を転送する。ある実施形態では、信頼パーティは（例えば、信頼パーティは複製を既にもっているので、）ＲＴＣＡ証明書の受け取りに興味があることを知らせ、又は、ＲＴＣレスポンダは信頼パーティが上記証明書の複製を既に所有していることを知っているかあるいはそのことを想定する。信頼パーティは、当該証明書の有効性ステータスを確認するために、上記受けた応答を処理する。ある実施形態では、人工的に事前計算された応答がＯＣＳＰフォーマットになっている場合は、信頼パーティは、その処理のためにＯＣＳＰソフトウェアを使用する。ある実施形態では、信頼パーティは、適切なＲＴＣＡ証明書を検証する。ＯＣＳＰに準拠した実装の場合には、信頼パーティは、ＯＣＳＰレスポンダの証明書と同様にＲＴＣＡ証明書を検証する。ある実施形態では、ＲＴＣＡ証明書は構文上、ＯＣＳＰレスポンダ証明書のように構造化されている。

実行可能な最適化処理がある。例えば、Ｕが証明書Ｃｕを有するパーティであると仮定する。パーティＶとのトランザクションとして、Ｕは、（ＶがＣｕを既に有しているのでない場合は）ＶにＣｕを送り、そして場合によっては、（Ｕに属しているとＣｕの中で認証された公開検証鍵に関連するデジタル署名を表示したり、又は、Ｕに属しているとＣｕの中で認証された公開暗号鍵Ｖで暗号化されたランダムなチャレンジを復号化によって特定されたりするような）追加のタスクを実行する。上記トランザクションを安全にするために、Ｖは、Ｃｕの現在の有効性を確認し、ＲＴＣレスポンダに対して有効性の問い合わせを行う。レスポンダは、Ｃｕについての最新のＲＴＣＡ署名宣言（人工的に事前計算された応答）を取り出して戻すことによって上記問い合わせに答える。しかし、ＲＴＣレスポンダへの問い合わせは、他の場合には二つのパーティのトランザクションであるトランザクションに、第三のパーティを追加し、トランザクションの時間及び複雑さを増加させる。

一つの解決策は、パーティＵが、各時間間隔Ｔの最初に又は少なくとも各時間間隔Ｔの間に、Ｔの全体にわたって有効であるＲＴＣＡ署名宣言Ｄｕ（人工的に事前計算された応答）をＣｕが受けることである。Ｕは、ＲＴＣレスポンダに対する要求に応答するＤｕを受ける。他の解決策では、Ｄｕは、例えばＲＴＣレスポンダ又はＲＴＣＡにより、すべての更新時に及び／又は自動バイアス時に、Ｕ又は他者に対してプッシュされる。いずれの場合にも、時間間隔Ｔの間におけるＶとのトランザクションとともに、Ｕは、前記トランザクションを伴う他のすべてのステップ又はタスクに加え、ＤｕをＶに転送する。従って、Ｕの証明書の現在の有効性を確認するためにＶが第３のパーティ（例えばＲＴＣレスポンダ）を呼び出す必要はないので、Ｕ−Ｖトランザクションはかなりスピードアップされる。

ＵがＤｕを取得する時間を含む全体の時間はスピードアップされないが、Ｕ−Ｖトランザクションはスピードアップされる点に留意されたい。しかし、全体の時間を削減することなくＵ−Ｖトランザクションのみをスピードアップするだけでも有用であり効率的である点にも留意されたい。例えば、ＲＴＣＡ宣言（人工的に事前計算された応答）が深夜に計算され時間間隔としてまる１日を指定していると仮定した場合は、Ｕは、（比較的少ないトランザクションしかないときは）その日の初期にＤｕを取得し、より多くのトランザクションがあるとき及び時間の節約が有用であるとき時間に敏感なＵ−Ｖトランザクションが実行されている間にＤｕをＶに転送する。また、ＵがＤｕを取得してキャッシュした後、他のパーティとトランザクションを行うときにその日の間中Ｄｕを転送することにより、更に効率が高められる。このように、例えば、（Ｕ自身の、おそらく忙しくない時間に作られた）単一の信頼パーティの問い合わせは、（おそらくより忙しい時間に）多くの信頼パーティの要求をうまく入れ換えることができる。

上述の最適化処理はパーティＶによって実現することもできる。パーティＵの証明書Ｃｕの有効性についての問い合わせに対するリターンとしてＲＴＣレスポンダからＤｕを取得した後、パーティＶは、ＤｕをＵに与えたり、又は他者が利用できるＤｕを作成したりすることができる。

本書に記載の最適化処理は、本書に記載のシステムのＯＣＳＰ準拠実装を使用する実施形態に適用することができることに留意されたい。また、同様な最適化処理は従来のＯＣＳＰ実装にも適用できる点に留意されたい。そのような実装において、ユーザは、自分自身の証明書についてのＯＣＳＰ応答を要求して取得し、このＯＣＳＰ応答を、ユーザのトランザクションの一部として、適切な時間間隔でのトランザクションの他のパーティに転送する。あるいは、パーティＵの証明書Ｃｕの有効性について信頼パーティから初めて問い合わせがあったとき、ＯＣＳＰレスポンダは、応答Ｒｕを計算し、問い合わせをしてきた信頼パーティにＲｕを返し、また、Ｕが（次の更新まで）しばらくの間ＲｕをキャッシュしてＣｕに基づくトランザクションの一部としてＲｕを転送できるように、ＲｕをＵに転送する。

ある実施形態では、本書に記載のシステムは、個々の証明書内で見付けられたデータを用い、それによって追加の証明書及び／又は応答長を保存して実装される。上述のように、ＣＡは、ＣＡによって発行された証明書の有効性について信頼できる回答を提供する権限を所与のＲＴＣＡに与えるＲＴＣＡ証明書を発行する。そのようなＲＴＣＡ証明書は、ＲＴＣＡ署名応答（人工的に事前計算された応答）の検証に使用される公開鍵を指定する。しかし、ある実施形態では、ＣＡは、そのＣＡによって発行される証明書内にＲＴＣＡ公開鍵を埋め込み、あるいは、その情報は、ＣＡ証明書そのものの中に埋め込まれる。すなわち、ＣＡは（適当なフォーマット、ＯＩＤ等で）、Ｃｕの有効性についてのデジタル署名された応答の検証に用いる公開鍵ＰＫを、証明書Ｃｕ内に含める。これらの実施形態において、信頼パーティは、別々に分離されたＲＴＣＡ証明書を受け取る必要がない。ＲＴＣレスポンダに最新のＣｕに対する有効性のプルーフを問い合わせるとき、信頼パーティは、（例えば、信頼パーティはそのように問い合わせているので、）ＲＴＣＡ署名応答（人工的に事前計算された応答）を取得する。実際に、Ｃｕは、信頼パーティがＣｕに対する有効性のプルーフの検証に使用する公開検証鍵を指定する。他の実施形態では、全体のＲＴＣＡ証明書（又はそれらのポインター）は、ユーザ証明書内に及び／又はＣＡ証明書内に埋め込まれる。これらの埋め込みは、（ＲＴＣレスポンダは個々の分離されたＲＴＣＡ証明書を送る必要がなく、そのＲＴＣＡ証明書はＲＴＣＡ応答よりもかなり長いので、）送信のかなりの節約をもたらし、また、（信頼パーティは、Ｃｕを信頼するための将来のクレームに対する保護として、ＲＴＣＡ応答と一緒にＲＴＣＡ証明書を保存する必要がないので、）保存にもかなりの節約をもたらす。

同様に、証明書Ｃｕは、そのＣｕに対する時間間隔を指定する。これらの実施形態において、ＲＴＣＡ応答は、時間間隔Ｔの始まり及び終わりの両方を指定する必要はない。ある実施形態では、Ｔの始まりだけ（又は他のより簡単な指定子）が適切にＴを指定する。例えば、Ｃｕが毎日、更新を指定する場合は、所与の日の中の任意の時刻は、応答が参照する日の全体を指定するのに十分である。あるいは、証明書がまる一日からなる有効性の間隔を有していると理解される場合は、証明書内で指定されるような情報はなく、ＲＴＣＡ応答への保存が適用される。

所与の証明書Ｃに対する有効又は一時停止のＲＴＣＡプルーフが、そのプルーフが参照する時間間隔を指定し、その一方で、失効のプルーフはいかなる時間間隔も指定する必要がない。むしろ、有効及び一時停止とは異なり失効はしばしば取り返しがつかない処理であるので、そのようなプルーフは時間（例えば失効時間）中の一点を指定するだけで十分である。このように、単一の失効時間ｒｔは、失効した証明書を証明するのに十分である。ｒｔは時間間隔Ｔの始まりである必要はないがいかなる時刻をも指定できることに留意されたい。従って、証明書Ｃの永久失効の場合は、ＲＴＣＡは、すべの更新日（例えば、Ｄ1，Ｄ2等）にＣの失効プルーフを送る必要がない。その代わりに、失効プルーフは、１回だけ（又は冗長性のために少数回だけ）送られ、Ｃについての信頼パーティの問い合わせがなされたときにいつでも返すことができるようにＲＴＣレスポンダによってキャッシュされる。

証明書Ｃが失効されたことがＲＴＣＡに速やかに知らされることに留意されたい。例えば、Ｃが失効したという情報は、ＲＴＣＡがＣに対する有効プルーフを生成してＲＴＣレスポンダに転送した時間間隔Ｔの途中で転送される。そのような場合には、次の更新までに、有効プルーフはＣに対して計算されない。しかし、そのときまで（すなわちＴの終端まで）、間違ってはいるが見かけ上正しく見える有効プルーフが、ＲＴＣレスポンダによって保持される。取り得る対策は、失効プルーフを有効のプルーフよりも先行させることを含む。そのような場合には、ある時間間隔ＴにおけるＣに対する有効プルーフと（任意の時刻ｔにおける）Ｃに対する失効プルーフの両方をみる正直な信頼パーティは、（時刻ｔの後）Ｃを失効しているものとみなす。

ある状況では、信頼パーティは失効プルーフをまったくみることがなく、従ってＣが失効しているにもかかわらず、そのＣはＴの終端まで有効であると考えられてしまう。ＲＴＣＡが（予めスケジュールされた日付Ｄ1，Ｄ2，等、又はＤ1’，Ｄ2’，等とは独立に）、Ｃが失効したことを（例えば、次のＣＲＬ更新を待たずにＣＡから直接的に）知ったらすぐに、ＲＴＣＡがＣの失効プルーフを計算してすべてのＲＴＣレスポンダに送ることによって、そのような問題は低減する。すべての適切に機能するＲＴＣレスポンダは、Ｃのプルーフをメモリから消去し、それを新しく受けた失効プルーフで置き換える。そのような場合には、ＲＴＣレスポンダがＣの有効性についての正確なプルーフを信頼パーティに提供する可能性がより高い。

図３を参照すれば、ダイアグラム８０は、本書に記載のシステムを実装するアーキテクチャを図示している。ＣＡ８２は、ＲＴＣＡ８４に結合され、それに検証情報（例えばＣＲＬ）を提供する。ＲＴＣ８４は、ＲＴＣＡ８４から人工的に事前計算された応答を受ける複数のＲＴＣレスポンダ８６−８８に結合されている。本書の他のどこかで説明しているように、ＣＡ８２及びＲＴＣＡ８４の両方はそれぞれ秘密署名鍵を使用する。ある実施形態では、ボックス８５で図示されているように、ＣＡ８２及びＲＴＣＡ８４は同じエンティティである。

ＲＴＣＡ８４は、人工的に事前計算された応答をＲＴＣレスポンダ８６−８８に提供する。本書の他のどこかで説明しているように、ＲＴＣレスポンダ８６−８８は、自分自身の秘密署名鍵を必要とせず、また、ＲＴＣレスポンダ８６−８８の１つによって信頼パーティへ提供される情報はＲＴＣＡ８４及び公開されている情報によってデジタル署名されているので、ＲＴＣレスポンダ８６−８８は保護される必要もない。

他の実施形態では、二つ以上のＲＴＣＡは使用され、そのＲＴＣＡは、複数の追加ＲＴＣを表しているＲＴＣＡ９２及びＲＴＣＡ９４によって図示されている。追加のＲＴＣＡ９２、９４はそれぞれ、ＲＴＣＡ８４によって用いられるレスポンダ８６−８８に結合されている。あるいは、一つ又は二つ以上の追加のＲＴＣＡ９２，９４が追加の異なる複数のレスポンダ９６−９８に結合されている。

図４を参照すると、フローチャート１００は、ＲＴＣＡの初期化に関連してＣＡによって実行されるステップを図示している。古いＲＴＣＡ証明書は有効期限が切れているので、又はＲＴＣＡのセキュリティ／秘密鍵は劣化しているので、フローチャート１００のステップは、システムに追加された新しいＲＴＣＡに関して、又は、新しい証明書を発行する従来のＲＴＣＡに関して、実行される。

処理は、ＣＡがＲＴＣＡを検証する最初のステップ１０２で始まる。ステップ１０２でのＲＴＣＡの検証は、システムのトポロジー及びセキュリティの条件に依存し、例えばＲＴＣＡを物理的に検査してＲＴＣＡが所定の位置にあって安全であるとを検証する管理者を必要とする。もちろん、ＲＴＣＡが安全であることを検証するためにステップ１０２で実行される他の適切な処理はある。ステップ１０２の次はステップ１０４であり、ここではＣＡがＲＴＣＡに対する鍵を生成する。このステップでは、ＣＡは、ＲＴＣＡに対する秘密鍵及びＲＴＣＡに対する公開鍵の両方を生成する。

ステップ１０４の次はステップ１０６であり、ここではＣＡがステップ１０４で生成した鍵に基づいてＲＴＣＡに対する証明書を生成する。ステップ１０６で生成された証明書はＲＴＣＡ証明書である。ステップ１０６の次はステップ１０８であり、ここでは秘密鍵がＲＴＣＡに提供される。ある実施形態では、セキュリティの目的のためにオフライン方式で（例えば、ユーザが紙の上に秘密鍵を書き、その秘密鍵を物理的にＲＴＣＡに入力して）秘密鍵をＲＴＣＡに提供することが有用である。

ステップ１０８の次はステップ１１２であり、ここではステップ１０６で生成された証明書がＲＴＣＡに提供される。ＲＴＣＡ証明書は、その後に公にされ、すべての実際上の目的のために、（通常はステップ１０４で生成された秘密鍵とは異なる）ＣＡの秘密鍵の知識なしに改ざんすることはできないので、ステップ１１２では、（安全ではないが）オンライン方式で証明書をＲＴＣＡに提供することができる。ステップ１１２の次はステップ１１４であり、ここではＣＡによって管理されている証明書についての初期の証明書データが、ＣＡからＲＴＣＡに提供される。更に、本書に他のいずれかに記載されているように、有効期間が満了していない有効な証明書に対する適切な応答をＲＴＣＡが提供できるように、ステップ１１４で提供された初期データはまた、有効期間が満了していない有効な証明書についての情報を含む。
ステップ１１４の後、処理は終了する。

ある実施形態では、ＲＴＣＡが秘密鍵の知識を有する唯一のエンティティになるように、上記ステップ１０４はＲＴＣＡによって実行される。その場合には、（オンライン又はオフラインのいずれかの方式で）ＣＡがステップ１０６で証明書を生成できるように、ＲＴＣＡは、対応する公開鍵をＣＡに提供する。もちろん、そのような場合、上述のステップ１０８の実行は不要である。これは、フローチャート１００においてステップ１０６からステップ１１２への代替のフローパス１１６で図示されている。

フローチャート１００のステップはＣＡ及びＲＴＣＡが同じエンティティの場合でも実行されることに留意されたい。もちろん、そのような場合には、ステップ１０２でのＲＴＣＡの検証はどうでもよい。更に、ＣＡの機能及びＲＴＣＡ機能の両方に対する同じ公開鍵と秘密鍵のペアをＲＴＣＡ／ＣＡが使用する実施形態では、ＲＴＣＡ証明書がＣＡの証明書になるので、上記ステップ１０４，１０６，１０８及び１１２は実行する必要がない。しかし、ＲＴＣＡ証明書がＣＡ証明書と異なるフォーマット（例えば、ＯＣＳＰレスポンダ証明書のフォーマット）を有する場合には、上記ステップ１０６は、ＲＴＣＡ証明書に対する異なるフォーマットの証明書の生成に関して実行される。

図５を参照すると、フローチャート１２０は、ＣＡからＲＴＣＡへの証明書の有効性データの定期的な転送に関して実行されるステップを図示している。このフローチャート１２０のステップは、定期的に、又はＲＴＣＡによる特定の要求に応答して実行される。処理は、証明書が（例えばすぐ前の反復処理の後、）最近失効したかについて判断する最初のステップ１２２で始まる。失効している場合は、制御はテストステップ１２２からステップ１２４に移行し、ここでは失効情報がレスポンダに送られる。本書の他のどこかで説明しているように、ある実施形態では、失効情報はすぐに（又は可能なかぎりほぼすぐに）ＣＡからＲＴＣＡへ送信される。ある実施形態では、ステップ１２４でＣＡからＲＴＣＡに送られた失効情報は、デジタル署名されるか、あるいは認証される。

ステップ１２４の次、又はテストステップ１２２で最新失効した証明書がない場合は、現在の時間が証明書情報を更新するための新しい時間間隔に対応しているかを判断するテストステップ１２６である。本書の他のどこかで説明しているように、ある実施形態では、ＣＡは周期的な間隔で新しい有効性情報をＲＴＣＡにプッシュする。従って、テストステップ１２６で現在の時間が新しい時間間隔に対応していない場合は、制御はテストステップ１２６からステップ１２２に戻るように移行する。そうではなく、テストステップ１２６で現在の時間が新しい時間間隔に対応している場合は、制御はテストステップ１２６からステップ１２８に移行し、ここでは、新しい有効性情報がＣＡによって生成され、ある実施形態ではデジタル署名あるいはその情報の認証を含む。本書の他のどこかで説明しているように、上記新しい有効性情報は、ＣＲＬなどの各種フォームのいずれか１つになっている。

ステップ１２８の次はステップ１３２であり、ここでは上記ステップ１２８で生成された新しい有効性情報がＲＴＣＡに提供される。ステップ１３２の次は、ＲＴＣＡがステップ１３２で送られた情報の受領確認をしたかを判断するテストステップ１３４である。上記受領確認をしていない場合は、制御はステップ１３４からエラー処理が実行されるステップ１３６に移行する。ステップ１３６で実行されるエラー処理は、例えばシステム管理者への通知を含む。悪意のある攻撃者は最近失効した証明書に関連した情報を広めるのを防止する手段としてのＲＴＣＡを無効にするので、ステップ１３４でＲＴＣＡが新しい有効性情報を受けたかを判断することが有用であることに留意されたい。ステップ１３６の後、処理は終了する。

ＲＴＣＡがステップ１３４で送られた情報の受領確認をしたと判断された場合は、制御は次の反復処理を行うためにステップ１３４からステップ１２２に戻るように移行する。ある実施形態では、ＲＴＣＡがデータの受領確認をしたか否かを考慮することなく、データが定期的にＣＡからＲＴＣＡへ提供される。これは代替のパス１３７で図示されている。

ある実施形態では、フローチャート１２０のステップは、定期的に実行されず、その代わりに、ＲＴＣＡによるデータに対する特定の要求に応答して実行される。これは、制御がステップ１２２又はステップ１２４からステップ１２８へ直接移行する代替のパス１３８で図示されている。ステップ１３４での受領確認の受信に対応する代替パス１４２にも留意されたい。フローチャート１２０のステップが定期的に実行されない実施形態では、ステップ１３４でＲＴＣＡがステップ１３２で送られた情報の受領確認をしたとき、パス１４２は処理の終了を示す。もちろん、ＲＴＣＡがＣＡからの情報の受領確認を行わない実施形態も可能である。これは代替パス１４４によって図示されている。

図６を参照すると、フローチャート１５０は、ＲＴＣＡからＲＴＣにデータが定期的にプッシュされる実施形態で実行される処理を図示している。処理は最初のステップ１５２で始まり、ここではＲＴＣＡが前回のプッシュの後新しいデータを受けたかどうかを判断する。上記新しいデータを受けていない場合は、制御は、新しいデータを受けるまでループとポーリングを続けるためにステップ１５２に戻るように移行する。テストステップ１５２で新しいデータを受けると、制御はステップ１５２からステップ１５４に移行し、ここではデータがＲＴＣＡからＲＴＣレスポンダに転送される。ステップ１５４の後、制御は新しいデータを待つポーリングを続けるためにステップ１５２に戻るように移行する。

図７を参照すると、フローチャート１６０は、ＲＴＣレスポンダによる要求に応答してデータがＲＴＣＡからＲＴＣレスポンダに提供される実施形態においてＲＴＣＡによって実行されるステップを図示している。本書の他のどこかで説明しているように、ＲＴＣレスポンダは、ＲＴＣＡからＲＴＣレスポンダにデータが定期的にプッシュされることに頼るのではなく、ＲＴＣＡからのデータをＲＴＣレスポンダ自ら定期的に要求する。

処理は最初のステップ１６２で始まり、ここでＲＴＣＡはＲＴＣレスポンダからの問い合わせ（データに対する要求）を受ける。ステップ１６２の次は、ＲＴＣＡ証明書がＲＴＣレスポンダによって要求されたか否かを判断するテストステップ１６４である。本書の他のどこかで説明しているように、ＲＴＣＡ証明書は、ＣＡがＲＴＣＡを信頼し有効性情報を提供する権限をＲＴＣＡに与えることを示すために使用される。ある実施形態では、各ＲＴＣレスポンダは、（要求されたとき及び／又は必要なときに信頼パーティに提供される）ＲＴＣＡ証明書をキャッシュし、この場合にはＲＴＣＡ証明書を一度だけ要求することが必要となる。他の実施形態では、ＲＴＣレスポンダは、定期的にＲＴＣＡ証明書を要求するか、ある場合にはＲＴＣＡ証明をいつも要求する。

テストステップ１６４でＲＴＣレスポンダがＲＴＣＡ証明書を要求したと判断された場合には、制御はテストステップ１６４からステップ１６６に移行し、ここではＲＴＣＡはＲＴＣレスポンダにＲＴＣＡ証明書を提供する。ステップ１６６の次、又はテストステップ１６４でＲＴＣＡレスポンダがＲＴＣＡを要求していない場合の次は、他の情報（例えば、人工的に事前計算された応答）が要求されたかどうかを判断するテストステップ１６８である。上記他の情報が要求されていない場合は、処理は終了する。そうでない場合は、制御はテストステップ１６８から、上記他の情報がＲＴＣＡで利用可能かどうかを判断するテストステップ１７２に移行する。ある場合には、ＲＴＣＡによって要求される他の情報はＲＴＣＡで利用できない。例えば、ＲＴＣＡレスポンダが外部の証明書についての情報を要求する場合は、人工的に事前計算された応答はＲＴＣＡで利用できない。

テストステップ１７２で上記要求された情報が利用できないと判断された場合は、制御はテストステップ１７２からステップ１７４に移行し、ここではＲＴＣＡは要求された情報が利用できない旨を示すデータをＲＴＣレスポンダに提供する。ステップ１７４の後、処理は終了する。テストステップ１７２で上記要求された他の情報が利用できると判断された場合は、制御はテストステップ１７２からステップ１７６に移行し、ここでは上記要求された情報はＲＴＣＡによってＲＴＣレスポンダに提供される。ステップ１７６の後、処理は終了する。

図８を参照すると、フローチャート１９０は、人工的に事前計算された応答（例えば、ＯＣＳＰ応答）に対する要求を信頼パーティから受けることに関連してＲＴＣレスポンダによって実行されるステップを図示している。処理は、上記要求を受ける最初のステップ１９２で始まる。ステップ１９２の次はステップ１９４であり、ここではＲＴＣレスポンダは要求に対する適切なＲＴＣＡデータを取得する。ステップ１９４でのＲＴＣＡデータの取得については、本書の他のどこかで詳しく説明されている。ステップ１９４の次は、上記要求されたデータが利用できるか否かを判断するテストステップ１９６である。上記要求されたデータが利用できない場合は、制御はテストステップ１９６からステップ１９８に移行し、ここではＲＴＣレスポンダは、特定の証明書のステータスが知られていないことを示す応答を信頼パーティに提供する。
ステップ１９８の後、処理は終了する。

テストステップ１９６で注目している証明書に対して最新の有効性のデータが利用できる場合は、制御はテストステップ１９６からステップ２０２に移行し、ここでは上記データに対するチェックが実行される。本書の他のどこかで説明しているように、上記ステップ２０２で実行されるチェックは、上記データが最新かどうかを判断すること、及びＲＴＣＡ証明書が改ざんされずに依然として有効であるかどうかを判断することの一つまたは二つ以上を含み、また、ステップ１９４で取得されたデータについて実行される他のチェックの一つまたは二つ以上を含む。

ステップ２０２の次は、ステップ２０２でチェックを行った結果がすべてＯＫであるか動かが判断されるテストステップ２０４である。上記結果がすべてＯＫでない場合は、制御はステップ２０４からステップ２０６に移行し、ここでは信頼パーティは有効性データがＯＫでないことを示す指示が提供される。例えばシステム管理者にエラーを通知すること等の他の適切な処理が、ステップ２０６で実行される。ステップ２０６の後、処理は終了する。

テストステップ２０４で有効性データがＯＫであると判断された場合は、制御はテストステップ２０４から、信頼パーティがＲＴＣＡ証明書を要求したかどうかを判断するテストステップ２０８に移行する。信頼パーティがＲＴＣＡ証明書を要求していなかった場合は、制御はテストステップ２０８からステップ２１２に移行し、ここでは信頼パーティは有効性のデータ（人工的に事前計算された応答）が提供される。ステップ２１２の後、処理は終了する。そうではなく、ステップ２０８でＲＴＣＡ証明書が有効性データとともに要求されていたと判断した場合は、制御はテストステップ２０８からステップ２１４に移行し、ここでは、有効性データ（人工的に事前計算された応答）及びＲＴＣＡ証明書が信頼パーティに提供される。ステップ２１４の後、処理は終了する。

ある実施形態では、信頼パーティはみずから有効性データのチェックを実行し、この場合には、ステップ２０２又はそれに対応するステップ２０４でのチェックを実行する必要はない。これはステップ１９６からステップ２０８までの代替フローパス２１６によって図示されている。

図９を参照すると、フローチャート２３０は、図８のフローチャート１９０のステップ１９４でのＲＴＣＡデータの取得に関連してＲＴＣレスポンダによって実行される更に詳細なステップを図示している。フローチャート２３０は、ＲＴＣＡレスポンダがデータを特に要求することなく、ＲＴＣＡデータがＲＴＣＡによってＲＴＣレスポンダに自動的にプッシュされる実施形態に対応している。これらの実施形態では、レスポンダはいつも自動的に最新の（又はほぼ最新の）ＲＴＣＡデータを所有する。

処理は最初のテストステップ２３２で始まり、ここではＲＴＣレスポンダは上記要求されたデータがＲＴＣレスポンダで利用できるかどうかを判断する。利用でできる場合は、制御はテスト２３２から、上記ＲＴＣレスポンダにおける要求されたデータが最新かどうかを判断するテストステップ２３４に移行する。本書の他のどこかで説明しているように、人工的に事前計算された応答は時間間隔を含み、その時間間隔では上記人工的に事前計算された応答は有効であり、その時間間隔の後は、新しい人工的に事前計算された応答を取得する必要がある。
人工的に事前計算された応答に対する時間間隔を決めるための特別なメカニズムにかかわらず、上記テストステップ２３４で、現在の時間と人工的に事前計算された応答に関連した時間間隔とを比較することにより、信頼パーティによって要求された特定の人工的に事前計算された応答が最新かどうか判断される。

上記データが最新の場合は、制御はテストステップ２３４から、ＲＴＣＡ証明書が有効であるかどうかを判断するステップ２３６に移行する。ある例では、上記ＲＴＣＡによって提供されたデータが信頼できなくなるようにＲＴＣＡを失効させる（又は有効期間満了にする）ことができる。例えば、ＲＴＣＡの秘密鍵が劣化した場合は、ＲＴＣＡ証明書は失効する。上記ステップ２３６でのＲＴＣＡ証明書の有効性の判断は、本書で説明した技術を含む多くの既知の技術のいずれか一つを使って実行される。上記テストステップ２３６でＲＴＣＡ証明書が有効であると判断された場合は、制御はテストステップ２３６からステップ２３８に移行し、ここでは、図８のフローチャート１９０に関連して上述したように、上記要求された人工的に事前計算された応答が将来の処理のために提供される。ステップ２３８の後、処理は終了する。

上記テストステップ２３２で上記データが利用できないと判断された場合、上記テストステップ２３４で上記要求されたデータが最新でないと判断された場合、又は上記テストステップ２３６でＲＴＣＡ証明書が有効でないと判断された場合は、制御は、図８のフローチャート１９０のステップの処理の続きに関連して上記データが利用できないことが示されるステップ２４２に移行する。ある実施形態では、ステップ２４２で提供された情報は、上記要求された情報を利用できない理由を含む。ステップ２４２の後、処理は終了する。

ある実施形態では、各反復処理においてＲＴＣＡ証明書の有効性をチェックしないことが望ましい。この実施形態では、ステップ２３６は省略され、これは代替パス２４４によって図示されている。

ＲＴＣレスポンダがＲＴＣＡからの新しいデータを定期的に要求する実施形態に対するフローチャート２３０によって図示されている処理を使用できることに留意されたい。そのような場合には、上記ＲＴＣＡからのデータはＲＴＣレスポンダによってまだ要求されていないので、そのデータは利用できないかあるいは最新ではない。

図１０を参照すると、ＲＴＣレスポンダがＲＴＣＡからのデータを要求する実施形態に対する図８のフローチャート１９０のステップ１９４でＲＴＣＡデータを取得することに関連して実行されるステップをより詳細に図示している。処理は最初のステップ２６２で始まり、ここでは信頼パーティがＲＴＣＡ証明書を要求したかどうかが判断される。要求した場合は、制御はステップ２６２からステップ２６４に移行し、ここではＲＴＣＡ証明書がＲＴＣレスポンダによってキャッシュされたかどうか判断される。キャッシュされている場合は、制御はステップ２６４からステップ２６６に移行し、ここではＲＴＣレスポンダはＲＴＣＡからのＲＴＣＡ証明書を要求する。

ステップ２６６の次、ＲＴＣＡ証明書が要求されていない場合のステップ２６２の次、又は上記要求された証明書が利用できない場合のステップ２６４の次は、テストステップ２６８であり、ここでは人工的に事前計算された応答が要求されたかどうか判断される。要求されている場合は、制御はテストステップ２６８からテストステップ２７２に移行し、ここでは上記要求された人工的に事前計算された応答がキャッシュされたかどうか（及び、もちろん最新であるかどうか）判断される。キャッシュされていない場合は、制御はテストステップ２７２からテストステップ２７４に移行し、ここではＲＴＣレスポンダはＲＴＣＡからの人工的に事前計算された応答を要求する。ステップ２７４の次、上記人工的に事前計算された応答が要求されていない場合のステップ２６８の次、又は上記要求された人工的に事前計算された応答がキャッシュされた場合のステップ２７２の次は、ステップ２７６であり、ここでは図８のフローチャート１９０のステップに従った処理に続いて行うために、上記要求された情報の取得の結果が提供される。ステップ２７６の後、処理は終了する。

図１１を参照すると、フローチャート３００はユーザ又は信頼パーティによって実行されるステップを図示しており、ここで、上述のように、３つのパーティのトランザクションの余分なステップ及び処理を回避するように２つのパーティのトランザクションがセットアップされた実施形態に関連して、ユーザはその信頼パーティとの間でトランザクションを行う。処理は最初のテストステップ３０２で始まり、ここで上記ユーザ及び／又は信頼パーティがキャッシュした情報（人工的に事前計算された応答）が最新かどうか（又は、ローカルに存在するかどうか）判断される。最新の場合（又は、ローカルに存在する場合）は、制御は、情報が最新でなくなるまでポーリングを続けるために、テストステップ３０２に戻るように移行する。テストステップ３０２で上記キャッシュされた情報が最新でないと判断されたときは、制御はテストステップ３０２からステップ３０４に移行し、ここでは、エンティティ（ユーザ及び／又は信頼パーティ）が、本書の他のどこかで説明しているように最新情報を取得する。ステップ３０４の次はステップ３０６であり、ここではステップ３０４で取得された情報がローカルに保存される（キャッシュされる）。ステップ３０６の後、制御は、キャッシュされた情報がもはや最新でなくなるまでポーリングを続けるために、ステップ３０２に戻るように移行する。

図１２を参照すると、証明書３２０は従来の証明書情報３２２とＲＴＣＡ証明書情報３２４とを含むように示されている。証明書３２０はユーザ証明書又はＣＡ証明書である。上述のように、ある実施形態では、ＲＴＣＡ証明書３２４によって認証された公開鍵を証明書の中に埋め込むことができる。信頼パーティが証明書３２０（ユーザ証明書又はＣＡ証明書のいずれか）を見たとき、ＲＴＣＡ証明書を単独で取得する必要はない。ある実施形態では、ＲＴＣＡ証明書情報３２４はＲＴＣＡ証明書の全体又はそれに対するポインターを含む。

図１３を参照すると、ダイアグラム４００は、ＣＡ４０２と、ＲＴＣＡ４０４と、ＲＴＣレスポンダ４０６と、信頼パーティ４０８との間の情報の流れを図示している。本書の他のどこかで説明しているように、ＣＡ４０２は有効性情報（例えばＣＲＬ）４１２をＲＴＣＡ４０４に提供する。ＲＴＣＡ４０４は、ＲＴＣレスポンダ４０６に提供される複数の人工的に事前計算された応答４１６を生成する。ある例では、ＲＴＣＡ４０４はまた、ＲＴＣＡ証明書４１４をＲＴＣレスポンダ４０６に提供する。しかし、本書の他のどこかで説明しているように、ＲＴＣＡ証明書４１４は一度だけ提供されるか、あるいは、人工的に事前計算された応答４１６をＲＴＣレスポンダ４０６に提供するＲＴＣＡ４０６とは独立に定期的に提供される。

信頼パーティ４０４は、その信頼パーティ４０８がＲＴＣレスポンダ４０６に提供するＯＣＳＰ要求４１８（又は有効性情報に対する他の種類の要求）を生成する。ＲＴＣレスポンダ４０６は、ＲＴＣＡ４０４からＲＴＣレスポンダ４０６に既に提供されている人工的に事前計算されたＯＣＳＰ応答４１６の一つである人工的に事前計算されたＯＣＳＰ応答４２２を提供することによって、ＯＣＳＰ要求４１８に対するサービスを提供する。信頼パーティ４０８は、その後、質問中の証明書の有効性ステータスに基づいて適切な更なる動作をとるために、人工的に事前計算された応答４２２を使用する。本書の他のどこかで説明しているように、ある例では、ＲＴＣレスポンダ４０６はＲＴＣＡ証明書４１４を信頼パーティ４０８に提供する。

図１４を参照すると、ダイアグラム４３０は、二つの独立したデジタル証明書システムの間における有効性情報の通信を図示している。ダイアグラム４３０は、図１３のダイアグラム４００におけるＣＡ４０２と、ＲＴＣＡ４０４と、ＲＴＣレスポンダ４０６と、信頼パーティ４０８とを示している。ダイアグラム４３０は更に、ＣＡ４０２によってＲＴＣＡ４０４に提供される有効性情報４１２を示し、またＲＴＣＡ４０４からＲＴＣレスポンダ４０６に通信されるＲＴＣＡ証明書４１４及び人工的に事前計算された応答４１６を示している。

ダイアグラム４３０はまた、第２のＣＡ４３２と、第２のＲＴＣＡ４３４と、第２のＲＴＣレスポンダ４３６と、第２の信頼パーティ４３８とを図示している。第２のＣＡ４３２は、有効性情報４４２を第２のＲＴＣＡ４３４に提供する。第２のＲＴＣＡ４３４は、人工的に事前計算された応答４４６を第２のＲＴＣレスポンダ４３６に提供する。しかし、ＣＡ４０２及び第２のＣＡ４３２がデジタル証明書の独立したセットを管理すると仮定した場合、ＣＲＬ４１２は、ＣＲＬ４４２とは異なる証明書についての情報を含み、人工的に事前計算された応答４１６は、人工的に事前計算された応答４４６とは異なる証明書についての情報を含む。従って、第２の信頼パーティ４３８が、ＣＡ４０２によって管理されている証明書についてＯＣＳＰ要求４４８を第２のレスポンダ４３６に提供するとき、第２のＲＴＣＡ４３４によって提供される人工的に事前計算された応答４４６のいずれも、ＯＣＳＰ要求４４８を満たす適切なものではない。

上述の問題は、ＲＴＣＡ４０４が人工的に事前計算された応答４１６を第２のＲＴＣレスポンダ４３６に提供するとともにＲＴＣＡ４０４が人工的に事前計算された応答４１４を第２のＲＴＣレスポンダを前もって提供している場合に、第２のＲＴＣレスポンダ４３６がＲＴＣＡ証明書４１４とＲＴＣＡ４０４で生成された人工的に事前計算された応答４２２とを提供することによってＯＣＳＰ要求４４８を満たすことにより、解決できる。本書の他のどこかで説明しているように、ＲＴＣＡ証明書４１４及び人工的に事前計算された応答４３６は第２のレスポンダ４３６への送信に先立って既にデジタル署名されているので、ＲＴＣＡ４０４から第２のＲＴＣレスポンダ４３６への送信がセキュアであることは必要ないことに留意されたい。

図１５を参照すると、ダイアグラム４６０は、図１４のダイアグラム４３０によって図示されているシステムの一般化を図示している。ダイアグラム４６０において、ＲＴＣＡ４０４は、人工的に事前計算された応答４１６をＲＴＣレスポンダの異種混在の集団４６２に提供する。同様に、第２のＲＴＣＡ４３４は、人工的に事前計算された応答４４６をＲＴＣレスポンダの異種混在の集団４６２に提供する。ＲＴＣＡ４０４，４３４はまた、それぞれのＲＴＣＡ証明書（図示無し）をＲＴＣレスポンダの異種混在の集団４６２に提供する。ＲＴＣＡのいくつかは人工的に事前計算された応答及び／又はＲＴＣＡ証明書をＲＴＣレスポンダの異種混在の集団４６２に提供することに留意されたい。従って、信頼パーティ４０８、第２の信頼パーティ４３８、又は他の信頼パーティは、人工的に事前計算された応答の適切な一つを受け、オプションで、人工的に事前計算された応答が異種混在の集団４６２に提供されている証明書についてのＯＣＳＰ要求（又は他の種類の要求）に対する応答としてＲＴＣＡ証明書を受ける。

上述の技術は従来のＯＣＳＰにおける高コストの計算、高い通信量及びセキュアサーバの高価なレプリケーション等の欠点を解決できるが、計算及び通信のコストをさらにもっと低減するさらなる最適化処理が可能である。実際には、ＲＴＣＡとＲＴＣレスポンダとの間の通信量は、後述のように適切な圧縮によって低減できる。後述の技術の組み合わせから結果として得られる節約は、特に標準ＯＣＳＰ構文（syntax）を使用したときにかなり大きくなる。

上述のように、ＲＴＣＡは各ＲＴＣレスポンダに人工的に事前計算された応答を送り、その人工的に事前計算された応答はそれぞれ、例えば応答の種類、応答が計算された時間、デジタル署名アルゴリズム識別子、ＲＴＣＡのｉｄ、証明書の番号、証明書が有効か無効か等と、デジタル署名そのものとからなる、複数のデータ要素で構成されている。例えば、上記応答が計算された時間及びＲＴＣＡのｉｄは、すべての応答について同じである。すべての応答が一緒にＲＴＣＡからＲＴＣレスポンダに送られるときは、共通の要素が１回だけ送られる。ＲＴＣレスポンダは、信頼パーティの要求に答えるときにさらに適切な応答を再構成する。更に、データ項目が似ているが同一でないときは、その類似性をうまく利用して相違部分だけを通信するように適当な圧縮アルゴリズムが使用される。

加えて、応答の計算及びレスポンダとの通信のコストを更に低減するために、証明書の全部ではないがそのいくつかの有効性のステータスについてレスポンダを更新することが有益である。例えば、高いプライオリティ（高いセキュリティ）を有する証明書はそのステータスが１分ごとに更新され、その一方、すべての証明書の有効性ステータスは１時間ごとに更新される。その代わりに（又はそれに加えて）、新規に失効した証明書の有効性ステータスは、レスポンダによる不適当な使用の危険性を低減できるように即座に更新されてもよい。もう一つの代替手段として、ＲＴＣＡは、すべての証明書に対する署名された有効性ステータス情報を１日ごとに（又は１時間ごとに）提供する一方で、ステータスが変化した証明書に対する最新の更新をレスポンダに提供してもよい。

（Lempel-Zivのような）標準の一般的な圧縮技術は通信コストを更に低減するために使用できる。この圧縮技術は上述の最適化処理が通信のサイズを既に減少させた後に適用される。

多くの場合には、より少ない署名の計算が必要となるので、上述の最適化処理は、ＲＴＣＡにおける計算負荷及びＲＴＣＡとレスポンダとの間の通信コストを低減させる。実際、上記計算と通信に要する待ち時間を低減することにより、このアプローチはセキュリティを向上させ、レスポンダは、ＲＴＣＡがつねにすべての証明書の有効性ステータスを処理して送る必要がある場合よりもさらに最新の情報を有する。

図１６を参照すると、フローチャート４７０はＲＴＣＡとＲＴＣレスポンダとの間で通信されるデータを圧縮するステップを図示している。処理は最初のステップ４７２で始まり、ここではスケジュールされていない項目が送信から除外される。上述のように、可能な最適処理の一つは、より重要な証明書がより頻繁に更新されるような互いに異なる頻度で証明書に関する情報を更新することである。従って、各更新サイクルで、あまり重要でなくスケジュールがなされていない証明書についての情報は、ＲＴＣＡからＲＴＣレスポンダに送られる情報から除去される。

ステップ４７２の次はステップ４７４であり、ここでは冗長な項目は残ったデータから除去外される。上述のように、冗長な項目は、送信されている情報の全体を通して同じ項目を含む。例えば、ＲＴＣＡ及び更新時間の同一性はＲＴＣＡからＲＴＣレスポンダに転送される情報のすべてについて同じである。ステップ４７４の次はステップ４７６であり、ここでは圧縮アルゴリズムが残っている情報に対して適用される。各種適用可能な圧縮アルゴリズムは上述のとおりである。ステップ４７６の後、処理は終了する。

証明書の有効性を証明することは、ある人がクレームした同一性を証明する上で価値がある。しかし、ある場合には、人がクレームした同一性は、ある特定の物理的な場所、論理的なエンティティ又はサービスにアクセスする特権に関連することが多い。上記同一性と特権との関連性は暗黙的（implicit）であり、同一のユーザに対する複数の独立した特権を制御する必要性を受け入れない。他の別のアプローチは、各独立の特権に対する別々の特権ステータスを採用することである。ＲＴＣＡは、証明書のステータスの証明に加えて、複数の特権に対する明示的な特権ステータスを提供するように拡張される。

特権は権限機関（Authorization Authorities）によってユーザに許可される。これは、権限機関とＣＡとが同じエンティティの場合の暗黙的な処理である。このような場合には、自分の同一性を証明するユーザは、特定の場所、論理的なエンティティ又はサービスにアクセスする権利を確立する。しかし、このアプローチの欠点は、特権のステータスが証明書又は同一性の有効性ステータスと同一であり、このためすべての黙示の特権に対する単一のyes/no回答になることである。これは、後述するように個々のユーザに対する個々の独立した特権ステータスを提供するようにＲＴＣＡを拡張することによって解決できる。

当初、ＣＡはＲＴＣＡを特権管理機関として認証する。これは、例えば、本書の他のどこかで説明しているように一般的なＣＡ認証処理の一部として実行される。ＣＡは、ＣＡがＲＴＣＡを信頼し、証明書の有効性ステータスに加えて複数の独立した特権ステータスを提供する権限をＲＴＣＡに与えることを示す証明書にデジタル署名する。上記権限の付与は暗黙的であるか、又はＲＴＣＡ証明書に明示的に示される。

上記認証に続いて、権限機関はＲＴＣＡに各種の特権ステータスの最新状態を知らせる。権限機関は、その権限機関がコントロールしている各ユーザに対して権限を与える特権の有効性ステータスがＲＴＣＡに通知される状態を維持する。例えば、権限機関は、（１）特権ステータスに変化が発生したら速やかにその特権ステータスの変化をＲＴＣＡに知らせ、又は（２）その変化を示すデジタル署名されたメッセージを掲示したりＲＴＣＡに送ったりする。

権限が付与された権限機関としてエンティティを識別することは、適切に信頼され権限が与えられたＣＡによって発行されたデジタル署名済みの証明書を用いて行われる。各権限機関によってコントロールされた特権は、（ＣＡによって）証明書そのものの中にある権限、ＲＴＣＡに位置するデータベース内にある権限、又は他の適切な手段による権限、と結び付けられる。

ＲＴＣＡが署名された証明書の有効性ステータスメッセージを独立に生成するとき、ＲＴＣＡは、所与の証明書に関連する各特権のステータスを含む。証明書の有効性ステータスを提供する処理の一部として、ＲＴＣＡは、問い合わせられている証明書に関連した各特権の識別子及び最新ステータスを含む。上記特権ステータスに関連した時間間隔は、前記証明書の有効性ステータスに適用されたものと同じである。この状況では、各種の特権ステータスを事前に計算することは、上述した証明書ステータスの有効性確認の技術と同一で同時に共存するものである。特権ステータスは、証明書ステータスの有効性確認のように、同じデジタル署名されたメッセージの中に含まれる。

ＲＴＣＡは、保護されていないＲＴＣレスポンダに、事前に計算された特権の有効性ステータスを送る。各種の特権ステータスを配信する処理は、上述した証明書ステータスの有効性確認で使用されたものと同一で同時に共存するものである。そして、レスポンダは、ＲＴＣＡの事前に計算された特権ステータスを保存する。特権ステータス検証情報が証明書ステータス検証情報の一部として含まれる例では、その特権ステータス情報は、上述のようにレスポンダによって単一の応答として保存され、及び／又は証明書検証情報と一緒に保存される。

信頼パーティがレスポンダに上述の証明書の有効性ステータス情報を問い合わせるとき、ＲＴＣレスポンダは、ＲＴＣＡの事前に計算された応答を提供し、その応答は、証明書の有効性ステータス及びすべての関連した特権ステータスを含む。そして、信頼パーティは、上記事前に計算された応答（及び、適切な場合は、ＲＴＣＡ証明書）を検証する。
信頼パーティによって受けられた応答の処理は、ここでは関連した特権のステータスも利用可能であること以外、上述したものと同じである。特権ステータスは読み出され、要求されたアクセスを許可するかどうかの判断に使用される。複数の明示的な特権ステータスを提供するように拡張されたＲＴＣシステムは、事前に計算されたＯＣＳＰ応答がここでは証明書有効性ステータス情報だけでなく特権有効性ステータスも含むものとして理解されている以外、証明書ステータスを提供するものとして本書の他のどこかで説明されているシステムと類似している。

図１７を参照すると、ダイアグラム４８０は権限機関の実装を図示している。ダイアグラム４８０は、ＲＴＣＡ４８４に結合されたＣＡ４８２を示している。ＣＡ４８２は、本書の他のどこかで説明しているように情報をＲＴＣＡ４８４に提供する。ＲＴＣＡ４８４は、本書の他のどこかで説明しているように、複数のＲＴＣレスポンダ４８６−４８８に情報を提供するようにそれらＲＴＣレスポンダ４８６−４８８に結合されている。

ダイアグラム４８０はまた、権限情報をＲＴＣＡ４８４に提供する権限機関４９２を示している。オプションで、ＣＡ４８２は、例えば初期の権限情報、権限機関の証明書、及びその他の適当な情報を提供するために、権限機関４９２に結合されている。本書の他のどこかで説明しているように、ＣＡ４８２及び権限機関４９２は同じエンティティであり、それは、ＣＡ４８２及び権限機関４９２の周りに描かれたボックス４９６で図示されている。
ダイアグラム４８０には図示されていないが、本書で説明されている権限機関４９２を有するシステムは、本書の他のどこかで説明しているように（例えば、図３及びそれに対応する説明文を参照されたい）、追加のＲＴＣＡ、レスポンダ等を含む。

ある実施形態では、ＣＡ４８２が、そのＣＡ４８２から権限機関４９２に証明書を提供することなく、権限機関の証明書をＲＴＣＡ４８４に直接提供することに留意されたい。また、権限機関の証明書（又は権限付与の他の証拠）が、（図１２で図示されているもの類似し上述されているように）ＣＡ４８２によって発行される証明書に提供されるか、又はＣＡ４８２がＲＴＣＡ４８４に提供する他の情報によって提供されることに留意されたい。

ＲＴＣシステムはＯＣＳＰの欠点の多くを解決するが、更に最適化処理が可能である。特に、ＲＴＣＡの計算コストは、複数のデジタル署名を一度に処理することによって低減することができる。上述のシステムにおいては、ＲＴＣＡは各デジタル証明書のステータスに署名する。これは前もって、おそらくステータスの問い合わせがなされる前に実行されるが、特にデジタル署名は計算上集約されるので、この処理の計算コストを低減することが望まれている。

後でより詳しく説明されているように、効率的に署名可能なＲＴＣＡ（ＳＥＲＴＣＡ）が複数の証明書のステータスを単一のステートメントに合体させ、そのステートメントに署名し日付を付けることによって改良することができ、これにより、時間上の所与のポイントで複数の証明書のステータスを認証するために単一の署名を使用することができる。ステータスがそのように認証される証明書の数は固定されるか（すなわち、すべてのステートメントがいつも同じ数の証明書についてのステータス情報を含む）、又は可変である。単一のステートメントで特定される証明書は他のステートメントでも特定される。例えば、一つのステートメントは、所与の個人に属しているすべての証明書の有効性ステータスを表し、もう一つのステートメントは、ある整数の間隔内のシリアル番号を有するすべての証明書の有効性を表す。同一の証明書は両方のセットに属し、２つの別々の認証ステートメントに属する。

所与の時間間隔におけるすべてのステートメントの認証の後、ＳＥＲＴＣＡは、上記ステートメントを一つ又は二つ以上のＲＴＣレスポンダに送り、そのＲＴＣレスポンダは、信頼パーティの問い合わせに対してサービスを提供するために上記ステートメントを保存する。証明書Ｘについての問い合わせを受けたとき、ＲＴＣレスポンダは、Ｘの有効性ステータスを含むＳＥＲＴＣＡ署名済みのステートメントを検索し、そのステートメントを信頼パーティに返す。信頼パーティは、認証された方法でＸのステータスを知るために、ＳＥＲＴＣＡの署名を検証し、Ｘについての情報に対するステートメントを検索する。

もちろん、ＳＥＲＴＣＡは、単一の証明書のステータスについてのステートメントも発行し、そして、ＳＥＲＴＣＡが単一の証明書についてのみステートメントを発行する場合は、ＳＥＲＴＣＡはＲＴＣＡとして同じ情報を提供する。特定のＳＥＲＴＣＡは、ある時はＲＴＣＡとして振る舞い、他の時は（例えば、ある特定の時間において計算上の制約及びニーズに依存して）ＲＴＣＡとして振る舞わない。システムはＲＴＣＡとＳＥＲＴＣＡとを兼ね備える。

最初に、ＣＡは、上述のようにＲＴＣＡの認証について説明された方法と同様な方法でＳＥＲＴＣＡを認証する。ちょうどＲＴＣＡのように、ＳＥＲＴＣＡは、所与の組織のＣＡと一致するかあるいは一致しないエンティティである。各ＣＡは、自分自身の一つ又は二つ以上のＳＥＲＴＣＡを提供し、各ＳＥＲＴＣＡは特別の証明書、ＳＥＲＴＣＡ証明書を有する。ＣＡは、ＳＥＲＴＣＡを信頼するとともにＣＡの証明書についての証明書有効性情報を提供する権限をＳＥＲＴＣＡに与えることを示すように、ＳＥＲＴＣＡ証明書にデジタル署名を行う。そのような証明書は、ＳＥＲＴＣＡステータスを（例えば所与の識別子やＯＩＤ番号などで特定された）所与のエンティティに伝え、（所与のエンティティが対応する秘密署名鍵を有している）所与の検証鍵ＰＫを上記所与のエンティティに結び付ける。

ちょうどＲＴＣＡのように、ＣＡ及びＳＥＲＴＣＡが一致している場合でも、ＣＡ及びＳＥＲＴＣＡが別個の署名鍵を有するのが都合よい。従って、ＣＡ及びＳＥＲＴＣＡが同じエンティティを表しているか否かに関わらず、ＣＡ（構成要素）は証明書を発行し、ＳＥＲＴＣＡ（構成要素）は証明書を管理する（例えば、証明書が有効／失効／一時停止であることを証明する）。こういう状況であれば、ＣＡ及びＳＥＲＴＣＡが一致している場合でも、別々に分かれたＳＥＲＴＣＡ証明書は使用される。ある実施形態では、各ＣＡは一つのＳＥＲＴＣＡのみ有するが、冗長性の目的あるいは他の目的のためには、同じ署名鍵を使用するか否かに関わらず二つ以上のＳＥＲＴＣＡを有するのが都合よい。複数のＳＥＲＴＣＡがある場合は、そのいくつかは単にＲＴＣＡとして振る舞う。

ちょうどＲＴＣＡのように、ＳＥＲＴＣＡが例えば保管庫（vault）、安全な施設又は安全なハードウェアによって署名鍵を保護することに留意されたい。ＣＡは、ＳＥＲＴＣＡを証明書の有効性ステータスが通知される状態にしておく。例えば、ＣＡは、（１）証明書の有効性に変化が生じたらできるだけ速やかにその変化をオンライン方式でＳＥＲＴＣＡに知らせ、又は（２）ＣＲＬが作成されたときにそのＣＲＬをＳＥＲＴＣＡに送る。日付の列Ｄ1，Ｄ2，...の任意の日付Ｄiにおいて、ＳＥＲＴＣＡは、有効性ステータスの現在の知識に基づいて（例えば、ＣＡの最新ＣＲＬに基づいて）、及び信頼パーティの要求とは独立に、ＣＡの各未処理の（好ましくは有効期間が満了していない）証明書を処理することによって更新を実行し、証明書の有効性ステータスについての情報をセットに合体させ、そしてセットごとに、セット内の各証明書のステータスが記述されている宣言（人工的に事前計算された応答）にデジタル署名する。例えば、そのようなステータスは、有効、失効、又は一時停止（又は、場合によっては、「不明」又は「未発行」又は他のステータス表示）である。上記署名された宣言は時間間隔Ｔを指定する。ある実施形態では、各更新時に、すべての署名された宣言は同一の時間間隔Ｔを指定し、そして、これらの時間間隔の総計は「時刻表（time line）」の全体をカバーする。例えば、各更新日付Ｄiにおいて、時間間隔はＴ＝Ｄi＋１−Ｄiとなり、場合によってはＤi＋１及びＤiのいずれか一方だけがＴの部分になり、他の日付は隣接する時間間隔の部分になる。

一例として、サンプル宣言は書式ＳＩＧ−ＳＥＲＴＣＡ（Ｘ：有効；Ｙ：失効；Ｚ：一時停止；日付：Ｄi；次の日付：Ｄi＋１）を有し、ここで、Ｘ，Ｙ及びＺは特定の証明書を特定する情報（例えばシリアル番号）を表し、「有効」、「失効」、「一時停止」は対応する証明書ステータスのインジケータである。ＳＥＲＴＣＡの証明書ステータスについての最新の知識がＣＡのＣＲＬに基づいている場合は、各ＤiはＣＲＬの日付と一致し、Ｄi＋１は次のＣＲＬの日付と一致する。しかしながら、そのような厳密な時間依存性が必須でないことは高く評価されるべきである。例えば、ＳＥＲＴＣＡがその宣言の処理を実行又は開始する日付は、Ｄ1，Ｄ2，等であり、一方、宣言の中で指定された時間間隔は、Ｄ1’，Ｄ2’，等であり、ここで、Ｄi及びＤi’は互いに異なる。例えば、Ｄiは、Ｄi’よりも早い日であり、この場合には、ＳＥＲＴＣＡは例えば時間間隔Ｔの先頭までに宣言の処理を終了したいので、ＲＴＣＡは宣言の時間間隔の先頭よりも前に宣言の処理を開始する。同様に、ＣＲＬがＳＥＲＴＣＡ更新に使用されている場合には、宣言の時間及びＣＲＬの時間も互いに異なる。

従って、要するに、ＳＥＲＴＣＡは、所与の時間間隔Ｔにおけるすべての証明書のステータスを示すデジタル署名を事前に計算する。そのような事前計算は、証明書の有効性についての信頼パーティの要求とは独立に実行される。ＳＥＲＴＣＡは、上記時間間隔になされるステータスの問い合わせの前、又は上記時間間隔が開始する前に、所与の時間間隔における署名された宣言を事前に計算する。証明書ステータスのＳＥＲＴＣＡ署名の宣言（人工的に事前計算された応答）は、標準ＯＣＳＰフォーマット又は既存の信頼パーティのソフトウェアと互換性のあるフォーマットになっている。これは、ＯＣＳＰソフトウェアが、既存の信頼パーティのソフトウェアに対する修正を最小限にし又は減少させる所定の場所にある場合に有用である。例えば、ＯＣＳＰ準拠を保証するために、すべての関連する量、デジタル署名アルゴリズム、ＯＩＤ等が適切に選択される。

しかし、ＳＥＲＴＣＡ応答は元の／初期の要求に対する応答として計算されないので、ＳＥＲＴＣＡの構文上正しいＯＣＳＰ応答が従来のＯＣＳＰ応答である必要がないことに留意されたい。要するに、ＳＥＲＴＣＡは、まだ生成されずその後も生成されないＯＣＳＰ要求に対するＯＣＳＰ準拠の応答を事前に計算する。ＳＥＲＴＣＡ応答は、ＯＣＳＰフォーマットであるか否かに関わらず、人工的に事前計算された応答である。

上記応答の事前計算の後、ＳＥＲＴＣＡは、その応答を他のパーティが利用できるようにする。ＳＥＲＴＣＡは有効性ステータス問い合わせに応答して信頼パーティに応答を返すが、他の実施形態では、ＳＥＲＴＣＡは、上記事前計算された応答をＲＴＣレスポンダに提供し、ＲＴＣＡと関連させて使用される上述のＲＴＣレスポンダと同様である。

ＳＥＲＴＣＡは、うまく体系づけられた方法で署名をＲＴＣレスポンダに提供することにより、ＲＴＣレスポンダが署名処理しやすいようにする。すべての関連する事前計算された応答を受けることを保証するために、すべての更新時に、ＳＥＲＴＣＡは、ＲＴＣレスポンダから受けた人工的に事前計算された応答の全体に署名して日付を付けることにより追加の署名をＲＴＣレスポンダに供給する。加えて、ＳＥＲＴＣＡは、ＳＥＲＴＣＡ証明書をＲＴＣレスポンダに送る。この送信は、すべての送信時に行う必要がなく、最初だけ又は定期的に実行される。

ＲＴＣレスポンダは、上記受信したＳＥＲＴＣＡの人工的に事前計算された応答を十分な時間保存する。ある実施形態では、署名が所与の時間間隔Ｔに関係している場合、ＲＴＣレスポンダは、少なくともＴの終端まで上記人工的に事前計算された応答を保存する。ある実施形態では、ＲＴＣレスポンダ（特にＳＥＲＴＣＡと同じ組織に属しているもの）は正しい情報を有しているかをチェックする。例えば、ＲＴＣレスポンダは、時間間隔Ｔについての人工的に事前計算された応答がＴの先頭までに（又はＴに関連した他の適当な時間までに）受けられたことを検証したり、すべての受けたＳＥＲＴＣＡ署名（及び場合によっては適切なＳＥＲＴＣＡ証明書）を検証したり、ＲＴＣレスポンダがすべての証明書（例えば、少なくとも予想される数の証明書、発行済みの証明書に対する直前の送信のものと少なくとも同数の証明書、など）についての情報を受けたかどうか検証したり、ＲＴＣレスポンダが、過去に失効の宣言がなされている証明書に対する有効性のＳＥＲＴＣＡ署名済み宣言を受けたかどうかを検証したりする。何らの問題が見つかった場合は、ＲＴＣレスポンダはＳＥＲＴＣＡ又は他の適当なエンティティに知らせる。

信頼パーティはＲＴＣレスポンダに証明書の有効性ステータスを問い合わせる。ある実施形態では、信頼パーティは要求にＯＣＳＰフォーマットを使用する。同じ証明書のステータスについての情報は二つ以上のステートメントの中に現れ、信頼パーティはどのステートメントが信頼パーティに好まれているかをＲＴＣレスポンダに示す。例えば、ＳＥＲＴＣＡが、ある整数間隔内におけるシリアル番号を有するすべての証明書の有効性ステータスを示すステートメントだけでなく、所与の個人に属するすべての証明書の有効性ステータスを示すステートメントを提供し、そして信頼パーティが個人Ｉに属するシリアル番号Ｘを有する証明書の有効性ステータスに主として興味を持っている場合は、信頼パーティは、（ａ）Ｘに近いシリアル番号を有する証明書についての情報を含むＳＥＲＴＣＡ署名済みのステートメント、又は（ｂ）Ｉの他の証明書についての情報を含むＳＥＲＴＣＡ署名済みのステートメント、又は（ｃ）非常に短いＳＥＲＴＣＡ署名済みのステートメント、又は（ｄ）Ｘのステータスについての情報（すなわち、好まないこと）を含むＳＥＲＴＣＡ署名済みのステートメントを受けることを好むことを示すインジケータを提供する。状況に応じて上記選択の一つに利点がある。

所与の証明書の有効性について問い合わせがあったとき、ＲＴＣレスポンダは、その証明書に対する情報を含む人工的に事前計算されたＳＥＲＴＣＡ応答をメモリから取り出す。ＲＴＣレスポンダは、上記人工的に事前計算された応答を返す。また、ＲＴＣレスポンダは、上記人工的に事前計算された応答に署名したＳＥＲＴＣＡに適切な証明書を転送する。信頼パーティが上記ＳＥＲＴＣＡ証明書を受け取らないように指示を提供すること、又は信頼パーティが上記ＳＥＲＴＣＡ証明書の複製を既に所有していることをＲＴＣレスポンダが知っているかあるいはみなすこと、に留意されたい。同一の証明書についての情報を含む複数の事前計算された回答があった場合は、ＲＴＣレスポンダが信頼パーティの好み若しくは予め決められているアルゴリズムに従って、又は、他の基準に従って、どの回答を返すかを選ぶ。

信頼パーティは、上記注目している証明書の有効性ステータスを確認するために上記受けた応答を処理する。ある実施形態では、上記応答がＯＣＳＰフォーマットである場合、ＲＴＣレスポンダは、そのような処理のためにＯＣＳＰソフトウェアを使用する。ＲＴＣレスポンダは上記適切なＳＥＲＴＣＡ証明書を検証する。ＯＣＳＰに準拠した実装の場合、ＲＴＣは、ＳＥＲＴＣＡ証明書をＯＣＳＰレスポンダの証明書として検証する。ある実施形態では、ＳＥＲＴＣＡ証明書は構文上ＯＣＳＰレスポンダの証明書として構造化される。

図１８を参照すると、ダイアグラム５００は、ＣＡ５０２とＳＥＲＴＣＡ５０４とＲＴＣレスポンダ５０６と信頼パーティ５０８との間のデータの流れを図示している。ＣＡ５０２は、ＳＥＲＴＣＡ５０４に有効性情報（例えばＣＲＬ）を提供する。ＳＥＲＴＣＡ５０４は、複数のマルチ証明書の人工的に事前計算された応答５１６を生成するために上記有効性情報を使用する。ＳＥＲＴＣＡ５０４はまた、例えばＣＡ５０２によってＳＥＲＴＣＡ５０４に提供される自分自身の証明書５１４を所有している。

信頼パーティ５０８は、その信頼パーティ５０８がＲＴＣレスポンダ５０６に提供するＯＣＳＰ要求５１８を生成する。それに応答するように、ＲＴＣレスポンダ５０６は、もともとＳＥＲＴＣＡ５０４によってレスポンダ５０６に提供されたマルチ証明書の人工的に事前計算された応答５１６の一つであるマルチ証明書の人工的に事前計算された応答５２２を提供する。加えて、本書の他のどこかで説明しているように、ある例では、レスポンダ５０６はＳＥＲＴＣＡ証明書５１４を信頼パーティ５０８に提供する。

ＲＴＣＡシステムに対する上述の処理は、権限機関をすることを含み、また、図１６に関連して説明した圧縮最適化処理を提供するように、必要に応じて、ＳＥＲＴＣＡシステム及び／又はハイブリッドシステムとともに使用されるように変えることができる点に留意されたい。同様に、ＳＥＲＴＣシステムに対する上述の処理は、必要に応じて、ＲＴＣＡシステム及び／又はハイブリッドシステムとともに使用されるように変えることができる。

他の技術であるバッチＯＣＳＰは、ＲＴＣＡ又はＳＥＲＴＣＡの計算コストを低減するために使用される。バッチＯＣＳＰは、単独で又は本書で説明した他の方法の一つ若しくは二つ以上と組み合わせて使用することができる。

バッチＯＣＳＰは、上記応答の中で使用される特定のデジタル署名がＲＳＡデジタル署名であるときに採用される。ＳＥＲＴＣＡは単独の署名内の複数の証明書のステータスを認証することによって署名の効率を向上させているが、一方、バッチＯＣＳＰは、１回の計算でシングルＯＣＳＰ応答を生成する場合よりも応答一つあたりのコストがかなり低くなるように、１回の計算によってシングル証明書ＯＣＳＰ応答を複数生成することにより、署名の効率を向上させている。例えば、１０個のシングル証明書ＯＣＳＰ応答が互いに独立に生成される場合は、コストはおおよそＲＴＣＡ（又は従来のＯＣＳＰレスポンダ）に対するＲＳＡ署名１０個分のコストになる。上述のＳＥＲＴＣＡの方法は、１０個の証明書についての情報を単一のステートメントに結合することによってＲＳＡ署名１つあたりのコストを低減することができる。しかし、ＳＥＲＴＣＡを使用することの欠点は上記対応するステートメントが大きくなってしまうことである。バッチＯＣＳＰは、１０個のＲＳＡ署名のコスト（ある場合には、おおよそ２つのＲＳＡ署名のコスト）よりも低い総コストで、１０個の別々のシングル証明書の個々に署名されたＯＣＳＰ応答を生成することができる。

バッチＯＣＳＰは、次に説明するようにフィアットのバッチＲＳＡ計算（Fiat's Batch RSA computation）に基づいている。ＲＳＡに対する公開鍵ＰＫは、法（modulus）及び検証指数（verification exponent）としてそれぞれ知られている２つの整数（Ｎ，ｅ）で構成されている。上記法は２つの大きな素数ｐ及びｑの積であり、ＲＳＡのセキュリティは、上記法Ｎから上記構成要素の素数を見付けることの困難性を基礎にしている。上記対応する秘密鍵ＳＫは（Ｎ，ｄ）で構成されており、ここで、ｄは次のような性質：すなわち、Ｎよりも小さなすべての正の整数ｂに対して、ｓがｂのｄ乗のＮを法とした値に等しい場合、ｂはｓのｅ乗のＮを法とした値に等しい、という性質を有する。言い換えると、整数のｅ乗についてＮを法とした値を求める演算は、整数のｄ乗についてＮを法とした値を求める演算の逆である。

ＲＳＡデジタル署名の計算は、ｂを取得するためのメッセージｍの（おそらくランダム化される）フォーマット処理及び／又はハッシュ処理と、ｂをｄ乗してその結果についてＮを法した値を求める署名ｓの計算とを含む。対応する検証手順は、ｓのｅ乗についてＮを法とする値を求めることによってｓからｂを計算し、ｂが本当に正しくｍから生成されているかをチェックする。フィアットのバッチＲＳＡ署名の観測（observation）は次のとおりである。ある人が複数の値ｂ1,...,ｂiと複数の検証指数ｅ1,...,ｅiと対応する署名指数ｄ1,...,ｄiとを有すると仮定されたい。そして、（本書では記載されていないが、従来技術において知られている）数論（number-theoretic）アルゴリズムの使用を通じて、Ｎを法としたｓ1のｄ1乗、ｓ2のｄ2乗、...、ｓiのｄi乗の計算を、（ある他の条件を満たす別々の値ｅ1,...,ｅiを提供する）ｉごとの分離した計算よりも効率的に一緒に実行する。

上述のように、（ＲＴＣＡだけでなく）ＳＥＲＴＣＡも、デジタル証明書の有効性情報を示す事前計算されたＯＣＳＰ応答上の署名についてＳＥＲＴＣＡが使用する公開鍵を認証するＣＡによって発行されたデジタル証明書を有する。また上述のように、ＳＥＲＴＣＡデジタル証明書は、証明書に対して一意のシリアル番号ＳＮ、ＳＥＲＴＣＡの公開鍵ＰＫ、ＳＥＲＴＣＡの識別子ＩＤ、発行日Ｄ₁、有効期間満了日Ｄ₂、及び追加データ等のいくつかの量と一緒に束ねられたＣＡのデジタル署名で構成されている。
記号で表すと、C=SIG_CA(SERTCA,SN, PK, ID, D₁,D₂,...)である。ＲＳＡデジタル署名がＳＥＲＴＣＡによって使用される場合には、ＳＥＲＴＣＡの公開鍵ＰＫは、（ｎ，ｅ）の形式をとり、ここで、ｎは法（modulus）であり、ｅは検証指数であり、証明書は、
C=SIG_CA(SERTCA, SN, (n, e), ID, D₁, D₂,...)
の形式になっている。

ＲＴＣレスポンダ及び信頼パーティは、認証済みの方法によってＳＥＲＴＣＡ証明書からＳＥＲＴＣＡ公開鍵を知ることができる。しかし、従来の証明書は単一の指数だけを含むので、従来の証明書は、複数の別々の指数を一緒に用いるバッチＲＳＡでの使用に適さない。もし検証者（ＲＴＣレスポンダ及び／又は信頼パーティ）がデジタル証明書の有効性情報を認証する特別の署名で使用される検証指数を知らない場合は、その検証者は証明書を検証することができない。この問題は、バッチＯＣＳＰ内のバッチＲＳＡを使用することによって次のように解決できる。

ある一つのアプローチでは、ＳＥＲＴＣＡは、まず従来のＲＳＡ署名の場合と同様に法（modulus）ｎを生成し、そのｎを認証のためにＳＥＲＴＣＡの公開鍵としてＣＡに提供する。ＳＥＲＴＣＡは、素数ｐ及びｑで構成されているその秘密鍵を保護する。次に、ＣＡは、ｎだけで構成された公開鍵に対するデジタル証明書をＳＥＲＴＣＡに発行する。例えば、上記ＳＥＲＴＣＡ証明書は、C=SIG_CA(SN, n, ID, D₁, D₂, ...)の形式になっている。次に、ＣＡは、ＳＥＲＴＣＡのユーザ証明書のステータスをＳＥＲＴＣＡに知らせる。次に、ＳＥＲＴＣＡは、ｉ個の署名指数ｄ1,...,ｄi及び対応する検証指数ｅ1,...,ｅiを生成する。信頼パーティの要求とは独立に、ＳＥＲＴＣＡは、所与の時間間隔における一つ又は二つ以上の証明書の有効性ステータスについてのステートメントを生成し、そのステートメントをサイズｉのバッチ処理の束（batch）に結合し、各バッチ処理内で指数ｄ1,...,ｄiを用いるバッチＲＳＡを使用して、各ステートメントに対するデジタル署名を作成する。次に、ＳＥＲＴＣＡは、各ステートメントについて各ステートメントの検証のために用いる指数ｅjを特定することをレスポンダ及び／又は信頼パーティに許容する情報を追加で含めて、有効性ステータスの事前計算された署名を保護されていないレスポンダに送る。次に、レスポンダは、ＳＥＲＴＣＡの人工的に事前計算された応答を保存する。

信頼パーティがレスポンダにステータス情報を問い合わせると、ＲＴＣレスポンダは、人工的に事前計算された応答で問い合わせに回答する。各応答は、（必要に応じて）ＳＥＲＴＣＡ証明書だけでなく、その応答の検証に必要な検証指数ｅjを含む。次に、信頼パーティは、ＳＥＲＴＣＡ証明書から取得した法（modulus）ｎとＲＴＣレスポンダから取得した検証指数ｅjとを用いるＲＳＡ検証を使い、上記人工的に事前計算された応答を検証する。

このアプローチのバリエーションも可能である。例えば、上記指数が任意である（及び、ＲＳＡ署名の発行に先立って特別なメッセージフォーマットが使用されていない）場合には、敵は、ＳＥＲＴＣＡ証明書からＳＥＲＴＣＡの法ｎを突き止め、その敵がｎ及びｅに関連した偽物のステートメントを生成できるようになる指数ｅを探す。セキュリティを向上させるために、ＳＥＲＴＣＡの指数ｅ1,...,ｅiは前もって固定されている（そして、いつもレスポンダに利用可能にしておく必要はない）。特に、上記指数は、ＣＡによって署名されたＳＥＲＴＣＡ証明書の一部分として指定される。ＳＥＲＴＣＡ証明書は、
C=SIG_CA(SERTCA, SN, (n, e1, ..., ei), ID, D₁, D₂, ...)
の形式になっている。

また、信頼パーティは、レスポンダからでなく、ＳＥＲＴＣＡ証明書又は他のソースから検証指数を取得する。

レスポンダ及び／又は信頼パーティが情報を明確に示すことができるというよりはむしろどの指数ｅjが特定のステートメント対して使用できたかを推測できるようにすることは有利な点である。例えば、そのような推測は、各バッチにおいて有効にされたｊ番目の証明書がいつもｉを法としたｊと合同なシリアル番号を有する場合に行うことができる。次に、レスポンダ及び／又は信頼パーティは、有効性が検証されている証明書のシリアル番号から簡単に上記指数のインデックスｊを論理的に演繹（deduce）することができる。

このアプローチにおいて、ＳＥＲＴＣＡの公開鍵はペア（ｎ，ｅ）として信頼パーティに提供されないので、信頼パーティの検証の実装は標準のＲＳＡ署名検証パラダイムに従わないことに留意されたい。ある応用において既存の信頼パーティＲＳＡ実装のコストはひどく高い。これは、代替のアプローチを従うことによって解決できる。

第２のアプローチにおいて、ＳＥＲＴＣＡは初めに従来のＲＳＡ署名内と同じような法ｎと、ｉ個の検証指数ｅ1, ..., ｅiとを生成し、それらはＳＥＲＴＣＡが認証のためにＣＡに提供する。ＳＥＲＴＣＡがｎの素数の因数分解を保護することには利点がある。次に、ＣＡは、PK1=(n, e1), PK2=(n, e2), ... PKi=(n, ei)だけで構成されている公開鍵に対するＳＥＲＴＣＡのｉ個のデジタル証明書を発行する。例えば、ｉ個のＳＥＲＴＣＡ証明書は、C1=SIG_CA(SERTCA,SN, (n, e1), ID, D₁, D₂, ...), ..., Ci=SIG_CA(SERTCA,SN, (n, ei), ID, D₁, D₂, ...)の形式になっている。次に、ＣＡは、そのユーザ証明書のステータスをＳＥＲＴＣＡに知らせる。それに続いて、信頼パーティの要求とは独立に、ＳＥＲＴＣＡは所与の時間間隔における一つ又は二つ以上の証明書の有効性ステータスについてのステートメントを生成し、そのステートメントをサイズｉのバッチ処理の束（batch）に結合し、各バッチ処理内で指数ｅ1, ..., ｅiを用いるバッチＲＳＡを使用して、各ステートメントに対するデジタル署名を作成する。次に、ＳＥＲＴＣＡは、各ステートメントについて各ステートメントが署名されている指数ｅjを特定することをレスポンダ及び／又は信頼パーティに許容する情報を追加で含めて、有効性ステータスの事前計算された署名を保護されていないレスポンダに送る。次に、レスポンダは、ＳＥＲＴＣＡの人工的に事前計算された応答を保存する。

信頼パーティがレスポンダにステータス情報を問い合わせると、ＲＴＣレスポンダは、人工的に事前計算された応答で問い合わせに回答する。指数ｅjで署名された各応答は、必要に応じて又は要求されて、ｊ番目のＳＥＲＴＣＡ証明書Ｃjを含む。信頼パーティは、ＳＥＲＴＣＡ証明書から取得した公開鍵（ｎ，ｅj）を用いるＲＳＡ検証を使い、上記事前計算された回答を検証する。標準に見えるＲＳＡ公開鍵はＳＥＲＴＣＡ証明書から取得されるので、信頼パーティの検証は標準のＲＳＡ検証と構文上同じであることに留意されたい。このように標準のＲＳＡ実装は信頼パーティのために修正する必要がない。実際に、信頼パーティは、ＳＥＲＴＣＡがバッチＯＣＳＰを使用していることにまったく気付かない。

上述のアプローチのバリエーションも可能である。例えば、上記指数ｅ1, ..., ｅjを選択してＣＡに提供するよりはむしろ、そのような指数はシステムの固定パラメータであるので、例えば推測でき、又はＣＡが前もって知っておくことができる。あるいは、レスポンダ及び信頼パーティは、指数を明確に示すというよりはむしろ、特定のステートメントに対してどの指数ｅjが使用されたかを推測する。例えば、そのような推測は、各バッチにおいて有効にされたｊ番目の証明書がいつもｉを法としたｊと合同なシリアル番号を有する場合に行うことができる。次に、レスポンダ及び／又は信頼パーティは、有効性が検証されている証明書のシリアル番号から簡単に上記指数のインデックスｊを論理的に演繹（deduce）することができる。

図１９を参照すると、フローチャート６００は、ＳＥＲＴＣＡ（又は、必要に応じてＲＴＣＡ若しくはＯＣＳＰレスポンダ）の初期化に関連して実行されるステップを図示している。処理は最初のステップ６０２で始まり、ここではＣＡが法ｎを認証する。ステップ６０２の次はステップ６０４であり、ここではｉ個の指数ペア（検証指数及び署名指数）が生成される。ここの実施形態において、上記指数ペアは、積がｎに等しい秘密の素数のペアを用いてＳＥＲＴＣＡによって生成される。しかし、他の実施形態では、ステップ６０４での上記指数の生成を他のエンティティに行わせ、上記ペアを生成するために他のアルゴリズムを使用することができる。

ある実施形態では、処理はステップ６０４の後、終了する。しかし、他の実施形態は、上述のように、検証指数ｅ1, ｅ2 ...ｅiをＣＡに認証させるなどのＣＡによる追加の認証を含む。ある一実施形態においては、ステップ６０６で図示しているように、ＣＡは上述のように単一の証明書内のｉ個の検証指数を認証する。他の実施形態においては、ステップ６０８で図示しているように、ＣＡは、ＲＳＡスタイルのｎ，ｅkの公開鍵に見えるｉ個の独立した証明書を認証する。ここで、ｅkはｉ個の検証指数の一つである。

図２０を参照すると、フローチャート６２０はＳＥＲＴＣＡ（又は、必要に応じて、ＲＴＣＡ若しくはＯＣＳＰレスポンダ）の人工的に事前計算された応答の生成に関連して実行されるステップを図示している。処理は最初のステップ６２２で始まり、ここでは、本書の他のどこかで説明しているようにＣＡがＳＥＲＴＣＡに検証情報を提供する。ステップ６２２の次はステップ６２４であり、ここではＳＥＲＴＣＡが署名指数ｄ1, ｄ2...ｄiを用いて人工的に事前計算された応答を生成する。ステップ６２４の次はステップ６２６であり、ここではＳＥＲＴＣＡが本書の他のどこかで説明している方法と同様な方法で、人工的に事前計算された応答をＲＴＣレスポンダに提供する。

ある実施形態では、ＳＥＲＴＣＡはＲＴＣレスポンダに追加の指数情報を提供する。これは図２０のフローチャート６２０にオプションのステップ６２８によって図示されている。上記追加の指数情報は、使用された特定の指数の証明書の一つ若しくは二つ以上、及び／又は人工的に事前計算された応答のために使用された特定の指数を示す情報で構成されている。もちろん、本書の他のどこかで説明しているように、上記情報をＳＥＲＴＣＡが独立に提供しなくてもすむように上記人工的に事前計算された応答のために使用された指数を決定する他のメカニズムもある。同様に、指数に対する追加の認証を個別に提供しなくてもすむように、ＲＴＣレスポンダ（最終的には信頼パーティ）と指数の情報を通信するメカニズムがある。

上述のバッチＯＣＳＰ技術はＳＥＲＴＣＡの代わりにＲＴＣＡと一緒の使用にも適用でき、またＯＣＳＰレスポンダが信頼パーティから問い合わせを受けたときにデジタル署名された証明書ステータス情報を計算する場合には従来のＯＣＳＰフレームワークにも適用できることに留意すべきである。特に、ＯＣＳＰレスポンダが一つの孤立した問い合わせを受けた場合には、ＯＣＳＰレスポンダは独立のＲＳＡ署名がなされた応答を作成するが、ＯＣＳＰレスポンダが短い時間に多くの問い合わせを受けた場合には、ＯＣＳＰレスポンダは上述のバッチモードで上記問い合わせのすべて又はいくつかに対して答える。以下、これを説明する。

最初に、ＣＡは、そのユーザ証明書のステータスをＯＣＳＰと矛盾しないやり方でＯＣＳＰレスポンダに知らせる。多数の証明書ステータス問い合わせを受けたとき、レスポンダは、独立した単一の証明書の、指数ｅjにそれぞれ関連した問い合わせのｉ番目に対する従来のＯＣＳＰ応答を計算するためにバッチＲＳＡを用いる。また、ＯＣＳＰレスポンダは、対応する指数を指定し、及び／又はｅj（及び適切なＲＳＡの法（modulus）ｎ）がレスポンダ署名の検証に使用されたことを証明するＣＡ署名のレスポンダ証明書を含む。ＣＡは、バッチＲＳＡ署名のためにレスポンダによって使用されたＲＳＡの法（modulus）だけを指定する単一のＯＣＳＰレスポンダ証明書をＯＣＳＰレスポンダに提供する。例えば、記号で表すと、
C=SIG_CA(responder, SN, n, ID, D₁, D₂, ...)
である。

これは、ＯＣＳＰレスポンダによって使用される指数が固定されている場合に特に適合し安全であることに留意されたい。あるいは、ＣＡは、レスポンダがバッチＲＳＡ署名に使用する多数の指数を指定するレスポンダ証明書をＯＣＳＰレスポンダに提供する。例えば、記号で表すと、
C=SIG_CA(responder, SN, (n, e1,...,ek), ID, D₁, D₂, ...)
である。

あるいは、ＣＡは、特定のＯＣＳＰレスポンダに対してｋ個の別々のレスポンダ証明書を提供し、各指数に対するレスポンダ証明書はレスポンダによってバッチＲＳＡ署名に使用される。例えば、記号で表すと、
C1=SIG_CA(responder, SN, (n, e1), ID, D₁, D₂,...);...;Ck=SIG_CA(responder, SN, (n, ek), ID, D₁, D₂,...)
である。

本書の説明を通して、ＣＡ／ＲＴＣＡ／レスポンダ／パーティ／ユーザは何らかのエンティティ（例えば、人、組織、サーバ、デバイス、コンピュータプログラム、コンピュータファイル）又はエンティティの集合である。証明書は、すべての種類の証明書を含むものと理解される。例えば、本書の記載に参照により組み込まれる米国特許第５，４２０，９２７号を参照されたい。有効性ステータス及び有効性ステータスのプルーフは、階層的な証明書に対する有効性ステータス及び有効性ステータスのプルーフ（例えば、証明書のチェーンにおけるすべの証明書に対する有効性ステータス及び有効性ステータスのプルーフ）を含む。証明書Ｃの有効性を検証することは、Ｃの有効性ステータスについての署名済み応答を提供するＲＴＣＡ／ＳＥＲＴＣＡに対するＲＴＣＡ／ＳＥＲＴＣＡ証明書の有効性だけでなく、Ｃを発行したＣＡに対するＣＡ証明書の有効性を検証することを含む。

適切な例の場合には、デジタル署名をすること及びデジタル署名は情報の適切な証明を含むものであると、本書において理解される。

（本書の記載に参照により組み込まれる）米国特許第５，６６６，４１６号に従うと、証明書は、所与の鍵を所与のユーザに結び付けるデジタル署名されたドキュメントを記述するものであるが、証明書はまた、すべての種類のデジタル署名されたドキュメントであると理解されるべきである。例えば、ＣＡとしてのベンダーは、価格リストに（場合によっては日付情報と一緒に）デジタル署名することによるコントロールの下でその価格リストを認証する。そのような証明書の有効性ステータスを知ることは有用である。例えば、ベンダーは、価格リストが現在有効であることを証明すること（及び、現在の有効性のプルーフが示されていない場合には、価格リスト内の所与の価格の受け入れを拒否すること）を希望する。このため、顧客は、価格リストドキュメントの現在の有効性を確認することを希望する。本書に記載されているシステムは、このために使用することができる。本書に記載されているシステムは、Ｗｅｂページの現在の有効性を証明するために使用することができる。ある実施形態では、ＲＴＣＡ／ＳＥＲＴＣＡが生成した現在の有効性のプルーフは、これらのプルーフとともに（又は、これらプルーフと関連付けて）保存される。この場合には、パーティはコンピュータファイルであるとみなされる。

（パーティＸに）データＤを送ることは、Ｄを利用可能にすること（又は、ＸにＤを受けさせること）を含むと理解される。

本書記載のシステムは、デジタル信号処理ハードウェアのような専用ハードウェアと場合によっては組み合わされ、本書に記載されている機能を提供するようにプログラムされた汎用コンピュータをなんら制限なく含め、ハードウェア、ソフトウェア、又はそれらのある組み合わせを用いて実装されることに留意されたい。

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

ＯＣＳＰ応答を信頼パーティに提供する従来技術のシステムを図示している。 異種混在環境においてＯＣＳＰ応答を提供する従来技術のシステムを図示している。 本書に記載のシステムの一実施形態に係るＲＴＣシステムを図示している。 本書に記載のシステムの一実施形態に係るＲＴＣＡの初期化を図示しているフローチャートである。 本書に記載のシステムの一実施形態に係るＣＡ及びＲＴＣＡの間の通信を図示しているフローチャートである。 本書に記載のシステムの一実施形態に係るＲＴＣＡからＲＴＣレスポンダへのデータのプッシュを図示しているフローチャートである。 本書に記載のシステムの一実施形態に係るＲＴＣレスポンダによるＲＴＣＡからデータ取得を図示しているフローチャートである。 本書に記載のシステムの一実施形態に係るＲＴＣレスポンダによる信頼パーティへの情報の提供を図示しているフローチャートである。 本書に記載のシステムの一実施形態に係るＲＴＣレスポンダによる検証情報の取得を図示しているフローチャートである。 本書に記載のシステムの他の実施形態に係るＲＴＣレスポンダによる検証情報の取得を図示しているフローチャートである。 本書に記載のシステムの一実施形態に係る２つのパーティ間のトランザクションの円滑な実現に伴って実行されるステップを図示しているフローチャートである。 本書に記載のシステムの一実施形態に係るデジタル証明書を図示しているダイアグラムである。 本書に記載のシステムの一実施形態に係るＣＡ、ＲＴＣＡ、ＲＴＣレスポンダ及び信頼パーティの間のデータの流れを図示するダイアグラムである。 本書に記載のシステムの一実施形態に係る、第１のシステムにおけるＣＡ、ＲＴＣＡ、ＲＴＣレスポンダ及び信頼パーティの間のデータの流れと、第２のシステムにおけるＣＡ、ＲＴＣＡ、ＲＴＣレスポンダ及び信頼パーティの間のデータの流れとを図示するダイアグラムである。 本書に記載のシステムの一実施形態に係るＲＴＣレスポンダの異種混在状態の集団を図示するダイアグラムである。 本書に記載のシステムの一実施形態に係る最適化を図示するフローチャートである。 本書に記載のシステムの一実施形態に係る権限委任機関を図示するダイアグラムである。 本書に記載のシステムの一実施形態に係るＣＡ、ＳＥＲＴＣＡ、ＲＴＣレスポンダ及び信頼パーティの間のデータの流れを図示するダイアグラムである。 本書に記載のシステムの一実施形態に係るバッチＯＣＳＰ処理のためのＲＴＣＡ／ＳＥＲＴＣＡ／ＯＣＳＰレスポンダへの情報の提供を図示するフローチャートである。 本書に記載のシステムの一実施形態に係るバッチＯＣＳＰ処理のためのＲＴＣレスポンダへの情報の提供を図示するフローチャートである。

Claims (20)

1. デジタル証明書の有効性についての情報を提供する方法であって、
   デジタル証明書セット内の複数のデジタル証明書それぞれに対するデジタル証明書有効性ステータスを確認することと、
   前記複数のデジタル証明書の前記デジタル証明書セットの少なくともサブセットの前記有効性ステータスについての複数の人工的に事前計算されたメッセージを生成すること（ここで、前記メッセージの少なくとも一つは、二つ以上のデジタル証明書有効性ステータスを示す。）と、
   前記デジタル証明書セット内の特定のデジタル証明書についてのＯＣＳＰ問い合わせに応答するＯＣＳＰ形式の応答を提供するために前記人工的に事前計算されたメッセージにデジタル署名をすること（ここで、少なくとも一つのデジタル証明書は、二つ以上のデジタル証明書に対するＯＣＳＰ形式の応答に関連付けて使用される。）と、を含む。
2. 請求項１の方法において、
   生成すること及びデジタル署名することは、前記ＯＣＳＰ形式の応答のいずれかによって答えられるどのＯＣＳＰ問い合わせよりも先立って行われる。
3. 請求項１の方法において、
   デジタル証明書有効性ステータスを確認することは、デジタル証明書について認証された情報を取得することを含む。
4. 請求項３の方法において、
   前記デジタル証明書について認証された情報は、証明書を失効させることも行うエンティティによって生成される。
5. 請求項３の方法において、
   前記デジタル証明書について認証された情報は、ＣＲＬである。
6. 請求項１の方法において、
   複数の人工的に事前計算された応答を生成することは、前記デジタル証明書セット内の少なくともすべての失効していないデジタル証明書に対する応答を生成することを含む。
7. 請求項１の方法において、
   前記人工的に事前計算されたメッセージにデジタル署名した後に、そのデジタル署名の結果を、前記デジタル証明書セット内のデジタル証明書有効性ステータスについて問い合わせる信頼パーティによる要求に対してサービスを提供する複数のレスポンダに転送すること、を更に含む。
8. 請求項７の方法において、
   前記人工的に事前計算された応答へのデジタル署名に関連付けて提供される前記デジタル署名を検証するための公開検証鍵を含む特別なデジタル証明書を、前記レスポンダが使用できるようにすること、を更に含む。
9. 請求項８の方法において、
   前記特別なデジタル証明書を発行するエンティティは、前記デジタル証明書セットの証明書も発行する。
10. 請求項１の方法において、
    複数の人工的に事前計算された応答を生成すること及び前記人工的に事前計算された応答にデジタル署名することは、定期的に実行される。
11. 請求項１０の方法において、
    前記人工的に事前計算された応答は、前記人工的に事前計算された応答が生成されたときに対応する時間情報を含む。
12. コンピュータ読み取り可能なメディアに保存され、デジタル証明書の有効性についての情報を提供するコンピュータソフトウェアであって、
    デジタル証明書セット内の複数のデジタル証明書それぞれに対するデジタル証明書有効性ステータスを確認する実行可能なコードと、
    前記複数のデジタル証明書の前記デジタル証明書セットの少なくともサブセットの前記有効性ステータスについての複数の人工的に事前計算されたメッセージを生成する実行可能なコード（ここで、前記メッセージの少なくとも一つは、二つ以上のデジタル証明書有効性ステータスを示す。）と、
    前記デジタル証明書セット内の特定のデジタル証明書についてのＯＣＳＰ問い合わせに応答するＯＣＳＰ形式の応答を提供するために前記人工的に事前計算されたメッセージにデジタル署名をする実行可能なコード（ここで、少なくとも一つのデジタル証明書は、二つ以上のデジタル証明書に対するＯＣＳＰ形式の応答に関連付けて使用される。）と、を備える。
13. 請求項１２のコンピュータソフトウェアにおいて、
    デジタル証明書有効性ステータスを確認する実行可能なコードは、デジタル証明書についての認証された情報を取得する実行可能なコードを含む。
14. 請求項１３のコンピュータソフトウェアにおいて、
    前記デジタル証明書について認証された情報は、証明書を失効させることも行うエンティティによって生成される。
15. 請求項１３のコンピュータソフトウェアにおいて、
    前記デジタル証明書について認証された情報は、ＣＲＬである。
16. 請求項１２のコンピュータソフトウェアにおいて、
    複数の人工的に事前計算された応答を生成する実行可能なコードは、前記デジタル証明書セット内の少なくともすべての失効していないデジタル証明書に対する応答を生成する実行可能なコードを含む。
17. 請求項１２のコンピュータソフトウェアにおいて、
    前記デジタル証明書セット内のデジタル証明書有効性ステータスについて問い合わせる信頼パーティによる要求に対してサービスを提供する複数のレスポンダに、デジタル署名された前記人工的に事前計算されたメッセージを転送する実行可能なコードを、更に備える。
18. 請求項１７のコンピュータソフトウェアにおいて、
    前記人工的に事前計算された応答へのデジタル署名に関連付けて提供される前記デジタル署名を検証するための公開検証鍵を含む特別なデジタル証明書を、前記レスポンダが使用できるようにする実行可能なコードを、更に備える。
19. 請求項１８のコンピュータソフトウェアにおいて、
    前記特別なデジタル証明書を発行するエンティティは、前記デジタル証明書セットの証明書も発行する。
20. 請求項１２のコンピュータソフトウェアにおいて、
    複数の人工的に事前計算された応答を生成しその人工的に事前計算された応答にデジタル署名する実行可能なコードは、定期的に、前記応答を生成して署名する。

Images