JP2015536617A - エンティティ・ネットワーク・トランスレーション（ｅｎｔ） - Google Patents

Abstract

本発明は、証明書権限および証明書チェーン等の公開—非公開キー技術およびＰＫＩ概念を用いて、抽象的アイデンティティを識別し認証するためのエンティティネットワークトランスレーション（ＥＮＴ）スキームを提供する。ＥＮＴは、任意の数の要求元に対し、任意の数の真正、不定、かつ抽象的な識別子を与えることができる。これらの抽象的識別子は各々、ベリニムと呼ばれ、これは「実証された名称」を大まかに意味する。それらによって任意の人またはエンティティは、いかなる目的に対しても、物体の真正アイデンティティを電子的に確立しコントロールすることが可能となり、さらにこれらのアイデンティティ間の関係を確立することが可能となる。いくつかの実施形態によれば、ＥＮＴは、抽象的識別子をリクエストするユーザに対して抽象的識別子を発行することにより従来のＰＫＩ関係確立問題を回避する。それは、これらの抽象的識別子およびその実社会の重要性を定めるエンティティ間に形成された関係を利用することである。【選択図】

Description

関連出願の相互参照
本出願は、２０１２年１１月９日に出願した「エンティティ・ネットワーク・トランスレーション（ＥＮＴ）のためのシステム及び方法（System and Methods for Entity Network Translation (ENT)」と題する米国特許仮出願番号第６１／７２４，７６３号に対する優先権を主張するものであり、その開示全体は、本出願の明細書の一部として参照することにより本明細書に組み込まれる。

本発明は、応用された暗号法に関し、特に、人間、エンティティおよび電子デバイスの抽象的アイデンティティを識別し、認証するためのデジタル証明書に関する。

センシティブかつ／又はコンフィデェンシャルな情報を含むシステムへの安全なアクセスは、周知かつ定着した慣習である。例えば、銀行の顧客は、安全なウェブサイトを介して、自らの銀行口座についての情報にアクセスすることができる。このような安全なアクセスは、一般に公開キーインフラストラクチャ（ＰＫＩ）によって提供され、この公開キーインフラストラクチャは、システムに安全にアクセスする際に使用するデジタル証明書を作成、管理、分散、記憶および無効にするために必要とされるハードウェア、ソフトウェア、人々、ポリシー、プロシージャの組である。デジタル証明書は、公開キーをアイデンティティと結合するためにデジタル署名を使用する電子的なドキュメントである。公開キー暗号は、ユーザがインターネット等のセキュアでない公衆ネットワーク上で安全に通信し、デジタル署名を介してユーザのアイデンティティを確認することを可能にするＰＫＩと共に用いられる暗号技術である。ＰＫＩは、公開キーをエンティティにマッピングするデジタル証明書を作成し、中央リポジトリにこれらの証明書を確実に記憶し、必要に応じてそれらを無効にする。ＰＫＩは一般に、デジタル証明書を発行し且つ確認する認証局（ＣＡ）と、ＣＡからの情報をリクエストするユーザのアイデンティティを確認する登録局と、インデックスキーを記憶するためのセントラルディレクトリと、証明書管理システムとを含む。

従来のＰＫＩシステムでは、発行した証明書が、アイデンティティに直接結合される情報を含む。例えば、証明書が個人に発行される場合、証明書は、電子的な意味における個人のアイデンティティと概念的に交換可能である。

本発明は、エンティティネットワークトランスレーション（ＥＮＴ）のための技術を提供する。ＥＮＴは、証明書権限および証明書チェーン等の公開―非公開キー技術およびＰＫＩ概念を用いて抽象的アイデンティティを識別して認証するためのスキームである。ＥＮＴは、任意の数の要求元に対し、任意の数の真正、不定、かつ抽象的な識別子を与えることができる。これらの抽象的識別子は各々、ベリニムと呼ばれ、これは「実証された名称」を大まかに意味する。それらによって任意の人またはエンティティは、いかなる目的に対しても、物体の真正アイデンティティを電子的に確立しコントロールすることが可能となり、さらにこれらのアイデンティティ間の関係を確立することが可能となる。いくつかの実施形態によれば、ＥＮＴは、抽象的識別子をリクエストするユーザに対して抽象的識別子を発行することにより、従来のＰＫＩ関係確立問題を回避する。それは、これらの抽象的識別子およびその実社会の重要性を定めるエンティティ間に形成された関係を利用することである。

上記のように、従来のＰＫＩシステムにおいては、発行された証明書は、アイデンティティに直接リンクされた情報を含む。例えば証明書が個人に発行された場合、その証明書は、電子的な意味における個人のアイデンティティと概念的に交換可能である。本発明の実施形態によれば、ＥＮＴにおいて、この結合は仮定されない。ベリニムがいかなる特定の使用またはコンテキストにもリンクされる、ということは全く仮定されなくてもよい。代わりに、ベリニムは、信頼のおける関係が、任意の目的のために参加者の間に確立され、かつ安定的に維持されることを可能にする。これは、小さなことであるが、現存のＰＫＩ解決策との重要な違いである。ＥＮＴは、実社会の関係が確立されることを可能にするが、それらが実社会のアイデンティティであることを意味してはいない。関係は、確立のための多くの特定のルールを有することが可能である。銀行は、顧客との関係を確立するために一定の情報を必要とする。ゲームサイトは、他の情報を必要とする可能性がある。ソーシャルネットワークは、さらに異なる基準を有する場合もある。これらの関係の確立のためのプロセスは、問題領域に対して特定的である。しかしながら、本発明の実施形態によれば、ベリニムは抽象的である。

様々な実施形態において、ベリニムの使用は、要求元によって決定される。利用は、個々人に対する例外的なセキュリティを有するオンラインアイデンティティ、コンピュータおよびデバイス、プログラムの識別およびコントロール、会社または個人のグループの識別等を含むことができる。本発明の実施形態によれば、ＥＮＴは、領域に固有の技術を必要とすることなく、その能力を通じて、これらの問題領域の全てに亘って使用され得る価値、又はそれ以上の価値を提供することが出来る。ＥＮＴは、標準化された包括的なソリューションを用いて、これらの領域に特有のソリューションの多くを減少させ、または除去することができる。さらに、ＥＮＴは、問題領域に亘る包括的なＥＮＴインタフェースおよび機構を用いて、情報、アクセス、コマンドおよびコントロール等の共有を可能にすることも出来る。これにより、それが人間、会社、コンピュータプログラム、デバイス、人口知能等のいずれであるかに拘わらず、電子的に接続または相互作用する全てのものを識別することが可能になる。

本発明の一実施形態では、人間、エンティティまたは電子デバイスのための一意識別子を作成するための方法であって、前記方法は、１より大きい数（Ｎ）のルートサーバを含むグループ権限構造内で実現され、第１のルートサーバにおいて、要求元から一意識別子に対するリクエストを受け取るステップと、前記第１のルートサーバにおいて、一意識別子とポリシーと含む第１の証明書を発行するステップであって、前記ポリシーは、１個またはそれ以上の他の一意識別子を含み、該ポリシー内の他の識別子の数が１より大きい場合には少なくとも１個のブール演算子または数学関数をさらに含むステップと、前記第１のルートサーバにおいて、該第１のルートサーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて、前記発行した第１の証明書に署名するステップと、前記第１のルートサーバから他の前記ルートサーバのそれぞれに対して、前記署名した発行済み第１の証明書を送信するステップと、他の前記ルートサーバのそれぞれにおいて、前記署名した発行済み第１の証明書の抽象的一意識別子を検証するステップと、他の前記ルートサーバのそれぞれにおいて、前記一意識別子及び前記ポリシーを含む追加の証明書を発行するステップと、他の前記ルートサーバのそれぞれにおいて、前記それぞれの他のルートサーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて、前記発行済み追加証明書に署名するステップと、データレポジトリにおいて、前記要求元に対する前記署名した発行済み第１の証明書及び前記署名した発行済み追加証明書を記憶するステップとを備える。Ｎは奇数であり、各ルートサーバは、他の全てのルートサーバから独立して署名し動作する。２個のルートコンピュータサーバは、２個の異なる要求元に対して同一の抽象的な一意識別子を発行することはできない。各ルートサーバは、排他的な範囲の一意識別子を発行することを許可されている。前記要求元に対する前記署名した発行済み第１の証明書および前記署名した発行済み追加証明書は、前記要求元のいかなる説明または識別も含まない。前記抽象的一意識別子は、多数（Ｘ）の前記署名した発行済み第１の証明書および前記署名した発行済み追加証明書が有効である時に有効であるとみなされ、Ｘ＝Ｎ／２＋１である。前記リクエストは、前記ポリシーをさらに含む。前記方法は、前記ルートサーバにおいて、前記第１の発行済み証明書内の前記一意識別子の更新のための更新リクエストを受け取るステップであって、前記更新リクエストは、非公開キーを用いて前記他の一意識別子に関連する人、エンティティまたは電子デバイスのそれぞれによって署名されるステップと、各ルートサーバにおいて、前記第１の発行済み証明書内の前記ポリシーの実行を介して前記更新リクエストを検証するステップと、各ルートサーバにおいて、前記第１の発行済み証明書を交換するための交換証明書を発行するステップと、各ルートサーバにおいて、該それぞれのルートサーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて前記交換証明書に署名するステップと、データレポジトリにおいて、前記署名した発行済み交換証明書を記憶するステップとをさらに備える。前記グループ権限は、前記ポリシーの実施を自動化する。前記第１の発行済み証明書は、公開キーまたは前記要求元に関連する公開キーの識別を備える。前記ポリシーは、前記一意識別子を交換孔または更新するためのポリシーを含む。前記ポリシーは、前記一意識別子を認証するためのポリシーを含む。

本発明の他の実施形態では、人間、エンティティまたは電子デバイスのための一意識別子を作成するための方法であって、前記方法は、サーバ上で実現され、前記サーバにおいて、要求元から一意識別子に対するリクエストを受け取るステップと、前記サーバにおいて、一意識別子とポリシーと含む第１の証明書を発行するステップであって、前記ポリシーは、１個またはそれ以上の他の一意識別子を含み、該ポリシー内の他の識別子の数が１より大きい場合には少なくとも１個のブール演算子または数学関数とを含むステップと、前記サーバにおいて、該サーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて、前記発行した第１の証明書に署名するステップと、データレポジトリにおいて、前記署名した発行済み第１の証明書を記憶するステップとを備える。前記署名した発行済み第１の証明書は、前記要求元のいかなる説明または識別も含まない。前記リクエストは、前記ポリシーをさらに含む。

本発明の前記の、ならびに他の特徴および利点は、本発明の好ましい実施形態、添付図面および請求の範囲の以下のより特定的な説明から明らかになるであろう。

本発明、並びに、その目的および利点をより完璧に理解するために、以下で簡単に述べる添付図面と関連付けて、後続の説明を参照する。

本発明の一実施形態によるエンティティおよびエンティティ間の関係を示す。

本発明の一実施形態による自己署名および相互署名証明書を作成するためのプロセスを示す。

本発明の他の実施形態による自己署名および相互署名証明書を作成するためのプロセスを示す。

本発明の一実施形態によるエンティティにアクセスする可能性のある初期の認可グループおよび非認可グループを示す。

本発明の一実施形態による証明書を置換するためのプロセスを示す。

図５．１のプロセスにおいて利用される証明書間の関係を示す。

本発明の実施形態による自己署名および相互署名の証明書を示す。

本発明の実施形態による証明書間の関係を示す。

本発明の実施形態によるエンティティの関係を示す。

本発明の他の実施形態による自己署名および相互署名の証明書を示す。

本発明の他の実施形態による認可グループの相互署名文書を示す。

本発明の他の実施形態による置換認可グループの相互署名文書を示す。

本発明の他の実施形態による、文書を後の文書と置換するために使用する代数学を含む文書を示す。

本発明の一実施形態による、証明書を作成するためのプロセスを示す。

本発明の一実施形態によるエンティティのグループを示す。

本発明の一実施形態によるＪＳＯＮ信任状の例を示す。

本発明の一実施形態による証明書を作成するためのプロセスを示す。

本発明の他の実施形態による、ピア署名者を利用する証明書に対する置換リクエストを示す。

本発明の他の実施形態による、記憶装置内の証明書の、より大きい通し番号を有する他の証明書との置換を示す。

本発明の他の実施形態による、記憶装置内の証明書の、より大きい通し番号を有する他の証明書との置換を示す。

様々な他のシステムにアクセスするためにＥＮＴシステムを使用し得るユーザアクセスターミナルを含む、一実施形態によるエンティティ・ネットワーク・トランスレーション（ＥＮＴ）システムのブロック図である。

本発明の好ましい実施形態およびその利点は、図１ないし図２０を参照して理解することが可能であり、同じ参照符号は同じエレメントを示す。様々な実施形態は、エンティティ・ネットワーク・トランスレーション（ＥＮＴ）のためのシステムおよび方法を提供する。実施形態によれば、ＥＮＴはＰＫＩシステムである。これは、非公開／公開キーと、中央権限と、証明書と、証明書チェイニングとを利用する。ＥＮＴはまた、当業者にとってはその実務が直ちに明らかな、現存の技術インフラ、並びに、トランスポート・レイヤー・セキュリティ（ＴＬＳ）やＸ．５０９のような暗号プロトコル及び規格を活用するように設計されている。これによって、（大抵の場合）現存のシステムを直接変更することなくＥＮＴをそのシステム内で利用することが可能になる。ＥＮＴがこれらの現存の技術を利用することは必要条件ではないが、有益であり得る。

実施形態によるＥＮＴは、典型的なＰＫＩシステムではない。それは、全ての基本ＰＫＩアクティビティの強力な自動化により、例外的なスケーラビリティ、耐性および監査を提供できるように設計されている。実質的なリサーチおよび開発が、これらの目的を達成することに費やされた。より形式的には、実施形態によるＥＮＴの目的は以下の通りである：

１．ベリニム（ｖｅｒｉｎｙｍ）の「キャノピー」を作成する。ＥＮＴは、これらのアイデンティティが、任意の目的のために、第三者間で安全かつ認証された通信のために使用され得ることを確実にすることができる。各々が一つまたはそれ以上のベリニムを所有する全ての第三者の組が、キャノピーを構成する。

２．いずれかの既存の製品ＰＫＩシステムと同等以上の極めて強力な暗号およびＰＫＩサービスを提供する。ＥＮＴは、これらのサービスを分配方式で提供可能であり、システム内のベリニムの一意性を損なうことなく、システムの信頼性および安定性に悪影響を及ぼす可能性のある停止、トランクセキュリティの損失、および他の深刻なイベントを許容する。

３．各ベリニムの直接コントロールを所有者に委託し、いかなる目的のための使用も許可する。一旦ベリニムを作成すると、ＥＮＴシステムはもはや、アイデンティティ所有者による暗号の「所有権の証明」が伴わなければならない所与のベリニムとの関連の定期的更新以外のベリニムの利用に対するコントロールを有しない。

４．これらのサービスを冗長に、しかも出来るだけ安く提供する。現存するほとんどのＰＫＩシステムは、そのコアにおいて１個のルート証明書を有する階層的署名機構に依存する。この単一障害点は、欠陥が破局的となることから、莫大な費用のＰＫＩシステムを生み出す。人材および実環境プロセスを必要とするシステムを通じて、さらなる費用がかかる。ＥＮＴは、技術革新を通じて、安全性を低減することなく、コストの削減を可能にする。実際、多くのディメンションにおいては、ＥＮＴは、かなりコストを削減した既存の設計よりも実質上安全である。ＥＮＴが既存のＰＫＩシステムほど安全でないディメンションは存在しない。

５．ユーザに意識させることなく動作し、ユーザおよび監査人による正常で信頼のおけるチェックを可能にする。これは、システムセキュリティ欠陥、バックドアおよび他の信頼のおけない動きが隠れていられなくなることを確実にする。

６．ベリニムの利用が、デフォルト設定で、抽象的かつ匿名であることを確実にする。プライベートなシステムは、プライベートでないシステムを構築するために利用され得る。その逆は真実ではない。
ＰＫＩ定義：

証明書は、公開／非公開キーペア（ＰＰＫ）に対応する公開キー、および、いくつかの付加的な任意情報を含む、暗号で署名されたメッセージであり、場合によっては、異なるＰＰＫに対応する非公開キーによる署名である。その証明書の「ターゲット」は、そのＰＰＫ、または、その証明書内の非公開キーの所有者である。「署名者」は、そのＰＰＫ、または、その証明書に署名するために使用する非公開キーの所有者である。

ＰＰＫの非公開部分がその証明書に署名するために用いられた場合、証明書は「署名された」とみなされる。さらなる明確性のために、証明書の「ターゲット」は、ＰＰＫ、または、非公開キーが証明書内に存在するＰＰＫの所有者として定義される。その証明書内に見出される公開キーがＰＰＫの公開部分であり、その証明書の署名がそのＰＰＫの整合非公開部分である場合、証明書は「自己署名された」とみなされる。

その証明書に見出される公開キーがＰＰＫの公開部分であり、その証明書の署名がそのＰＰＫの整合非公開部分を用いて作成されたものである場合、証明書は「自己署名された」ものとみなされる。

ここで参照するように、ＰＰＫが行動を遂行することは、証明書がＰＰＫの公開部分を含むこととして参照される。その理由は、両方が同じ所有者に関するものだからである。例えば、証明書ＡがＰＰＫ Ｐのための公開キーを含む場合、「Ａが証明書Ｂに署名した場合」等の文は、ＰがＢに署名する、として読まれるべきである。その理由は、非公開キーは、ＰＰＫ所有者による行動を遂行するために使用される装置であるからである。Ｐの公開キー部分はＡ内に存在するので、このチェイニングおよび関連付けは論理的であり、より容易に読み出される。

さらにここで参照されるように、「ターゲット」の動詞形態は、その「ターゲット化」の主題エンティティまたはＰＰＫが、対象となった証明書内にその公開キーを有することを示す。例えば、証明書ＡがＰＰＫ Ｐを含み、証明書ＢがＰＰＫ Ｑを含む場合、Ａに対応するＰＰＫ（この場合Ｐ）がＱの公開キー部分を含むいずれかの証明書に署名したのであれば、「ＡはＢをターゲットとする」ことになる。Ｂを「ターゲットとする」ものは、Ｑの公開部分を含む証明書に署名した任意のＰＰＫとなる。「ＡがＢをターゲットとする」および「ＢがＡによってターゲットにされる」は、同じ意味を表す。

非対称暗号法は、その識別および実装が当業者にとって明らかであるＥＣＣ、ＲＳＡ等の技術を含む一方、ゼロ知識証明機構も含む。これらの場合、署名は不可能であるが、秘密の所有権を証明するトランザクションは可能である。したがって我々は、署名、トランザクションを介して、または他の機構により、信頼性を証明することが可能ないずれかの技術として、我々の目的のための非対称暗号法について考えることが出来る。これらの技術の機構は、本開示の範囲を超越しており、当業者によって容易に理解される。
グループコマンドおよびコントロール：

従来のＰＫＩシステムには、周知のように、証明書を発行し、証明書関連のタスクを実施する認証局（ＣＡ）と呼ばれるセントラルサーバがある。このセントラルサーバは、ＣＡを表すＰＰＫを含む。このＰＰＫ暗号プリミティブは、証明書、失効または更新に署名し、発行するために用いられる。ＣＡまたはＣＡのＰＰＫが不正にアクセスされると、ＰＫＩシステム全体が不正にアクセスされることになる。ＥＮＴにおいてＣＡの同等物を実装の具体的な実施形態を分析する前に、グループコマンドおよびコントロールと呼ばれる新規な技術の概念化について述べる。

グループコマンドおよびコントロールは、メンバのグループとして定義され、その各々は、１個のキーまたは単一障害点に限定されることなくコマンドを発行し、グループのビジネスを処理する１個の概念エンティティを形成するＰＰＫをコントロールする。グループは、概念的エンティティの情報漏洩なしに閾値までの損害を被る可能性があり、グループメンバを置換可能にすることにより、堅牢な長期間安定性を可能にする。多数のグループメンバがそれぞれ異なるセキュリティプロトコルおよびプロセスと共にＰＰＫを使用するシステムをサポートすることにより、破局的失敗のリスクはさらに減じられる。グループメンバの例は、１人の所有者、グループとして行動する多数のユーザ、またはユーザのグループのグループ等のようなより抽象的な概念を有する多数の装置であってもよい。

この概念の１つの価値は、ノードのグループが１個のエンティティとして作用することが可能となる固有のシステム内における、多数のＰＰＫの利用を介してＰＰＫのコントロールが失われることに起因する損害の低減である。たとえある一定のプリミティブが不正アクセスされるか、または失われたとしても、損害を防止することが可能となる。様々な暗号プリミティブから成る不均一システムを利用することにより、リスクをさらに低減することが可能になる。例えば、あるノードは、ＲＳＡ暗号化プロセスを利用可能である。他のノードは、ＤＳＡを利用可能である。他のノードは、楕円曲線を利用可能である。使用される異種プロセスの上限は、グループ内のノード数の上限である。

図１を参照して、より詳細に説明する。仮想エンティティを表すＧと呼ばれるＮ個のメンバノードを有するグループを定義する。この仮想エンティティはそれ自体の識別子を有することが可能であるか、またはその識別子は、例えば、そのメンバノード名の全てを順序付け、その値をハッシュし、そのハッシュを識別子として利用すること、などのような、そのメンバの照合であり得る。エンティティＧがコマンドおよびコントロールを実施することを可能にする全ての装置またな外部関係者から成るグループＷを定義する。このコントロールは、データへのアクセス、コードの実行またはＷのメンバがＧを認証したいと思う他のいかなるアクションともなり得る。すなわち、Ｗのメンバは、グループＧに対するアクションを可能にし、他のいずれかのグループに対するアクションを防止することを望む。Ｇのｘ番目のメンバとして、ノードＭｘを定義する。Ｍｘノードは、グループＧの目的を達成するために、ＰＰＫを行使する。ＸをＷ内のユーザとして定義する。１つの実装では、Ｎは常に奇数である。これは、もしアタッカがちょうどＮ／２個のノードを占拠し、かつ、Ｎが偶数であった場合におき得るシステムのデッドロックを、アタッカが引き起こすことを妨げる。

一実施形態では、１個のＭｘノードに「タイ・ブレーカ」権限が与えられる。この場合、偶数個のノードが許可される。もし、Ｎが偶数であってアタッカがＮ／２個のノードを占拠した場合、タイ・ブレーカノードはデッドロックを防止する。タイ・ブレーカＭｘノードは、常に同じノードであってもよいか、またはＧのメンバに依って変化してもよい。例えば、Ｇの最も古いメンバは、Ｇに対するタイ・ブレーカとなり得る。代わりに、Ｇの最も新しいメンバには、タイ・ブレーカステータスを与えることが可能である。他の実施形態により、実装は変化可能である。

図１を続けて参照すると、いくつかの実施形態においては、Ｇは技術として非対称暗号法を使用する。例えばＸ５０９のような、ＰＫＩが組み立てる１つの実装においては、証明書が使用可能である。いくつかの実施形態は、その実装が当業者にとって明らかなジャバスクリプト・オブジェクト・ノーテーション（ＪＳＯＮ）または拡張可能マークアップ言語（ＸＭＬ）フォーマット等のより現代的なデータ交換フォーマットを利用することも可能であるが、それに限定されない。

１つの実装においては、図２に示すように、以下のステップが行われる。（１）各Ｍｘが、非対象暗号プリミティブを用いて、非公開キーと、（前記キーを有する）自己署名証明書ＭｘＳｘとを作成する。（２）各Ｍｘ署名が、互いにＭｙの証明書に署名する。これらの証明書の１個をＭｘＳｙとして定義する。例えば、Ｎが３である場合、Ｍ１はＭ２およびＭ３の証明書に署名し（Ｍ１Ｓ２およびＭ１Ｓ３を作成し）、Ｍ２はＭ２Ｓ３およびＭ２Ｓ１を作成し、Ｍ３は証明書Ｍ３Ｓ１およびＭ３Ｓ２を作成する。Ｎ＝３に対しては、Ｇ（ステップ２）に対して、３つの自己署名証明書（ステップ１）および６つの相互署名証明書が存在することになる。（３）ＧＣを、全てのＭｘノードに対して、それぞれの自己署名ＭｘＳｘを含むステップ２からの証明書の全体集合として定義する。したがって、サイズＮの任意のＧに対して、Ｎ個の自己署名証明書、Ｎ個のノード、および（Ｎ−１）＊（Ｎ−１）個の相互署名が存在し、ＧＣの組において合計Ｎ＊Ｎ個の証明書をもたらすことになる。

１つの実装においては、各Ｍｘは「ラウンドロビン」プロセスを使用するＮ−１個の証明書の代わりに、ちょうどＮ／２個の（切り捨てられた）証明書に署名する。この場合、Ｍ１が常にＭ２等の「前」になるように、確定的なオーダプロセスを用いてＭｘにより作成された全ての証明書をリストＬ内に順序付ける。この組はＧＣを含む。Ｍｘによって署名されたＮ／２個の証明書は、次により大きいＮ／２個の（切り上げられた）証明書である。この計算が、リストの最後を通過して拡張された場合、該計算は、Ｌにこれ以上の証明書が存在しない時、リストの最初で継続するべきである。例えば、Ｎ＝４に対して、Ｍ１は、Ｍ２およびＭ３に対する証明書に署名し、Ｍ４は、Ｍ１およびＭ２に対する証明書に署名する。Ｍ３は、Ｍ４およびＭ１に対する証明書に署名する。この組は、ＧＣを含む。図３は、Ｎ＝７の場合における、そのようなラウンドロビン署名技術の一例を示す。

１つの実装において、各ＭｘはＮ−１個の証明書に署名する。すなわち、各Ｍｘは互いに一意のＭｙをターゲットとするＮ−１個の証明書を作成する。１つの実装において、Ｇ内の各Ｍｘは、異なる非対称暗号プロセスを使用することが可能である。例えば、Ｎが３である場合、１個のノードはＲＳＡキーペアを使用可能であり、もう１個はＤＳＡキーペアを使用可能であり、残り１個は楕円曲線暗号法を使用可能である。１つの実装においては、各Ｍｘは、自己署名済み証明書を作成する代わりに、ＣＡにより署名された証明書を使用する。これらの実装の全てにおいて、ＧＣは、Ｇ内の任意のＭｘＳｘに対してＮ／２個よりも多い署名済み証明書が存在するように、自己署名した、または相互署名した証明書のリストから構成される。すなわち、各ノードＭｘに対して、Ｍｘにより使用されるＰＰＫを含むＮ／２＋１個の署名済み証明書が常に存在する。そうすることでＧＣは、Ｇと相互作用する際に、Ｘによる使用のために分析され得ることになる。

Ｘは、ＧＣの最初のローカルコピーを与えられなければならない。Ｘがいずれかのアクションを実施可能になる前に、ローカルストア内にＧＣを有することが重要である。Ｘの記憶済み証明書Ｔの組を呼び出す。ローカルストアまたはコピーは、データを含むＲＡＭまたはディスクメモリ等のコンピュータメモリの一部である。この場合、その記憶装置はＴを含む。

図４を参照すると、１つの実装において、初めにＧがＸからのサービスをリクエストしたとき、ＸはＧＣを受け取る。この時、Ｘは、サービス初期化の一部としてＧＣをリクエスト可能であった。初期化時点では、Ｔ＝ＧＣである。すなわち、信頼のおけるストアは、正確にＧＣを含む。ＧＣの前バージョンが存在せず、ＸがＧの事前知識を有さないので、初期通信上でＧＣからＸへの通過は安全である。Ｘと通信する他のＧ′グループに対して、Ｘは別のＴ′を記憶する。Ｔ′は、Ｇ′に対する一意の識別子と同等であることに注目されたい。これは、アタッカにより初期通信ラウンドにおけるＧＣが汚染されることを防止する。アタッカがＸに対して変更されたＴ′を提示する場合、ＧとＴ′がミスマッチとなる。Ｘは、Ｇの代わりにＧ′に対抗するＴ′を記録するだろう。その後にＧがＴを提示した場合、ＸはＧ′をＧと混同せず、Ｔ′をＴと混同しないだろう。Ｘは、Ｇがコンタクトする際にはＴを使用し、アタッカがコンタクトする際にはＴ′を使用するだろう。

過半数を、Ｎ／２よりも大きいカウント、切り上げとして定義する。または、タイブレーカが存在するケースでは、上記カウントはＮ／２以上であり、タイブレーカはカウントの一部となる。したがって、Ｎ＝３に対して、過半数は２となる。Ｎが３５である場合、過半数は１８となる。

ＡＬＧＯ１と呼ばれる特定の実装について、図５．１および図５．２を参照して以下で述べる。この実装では、Ｘは以下の方法により、Ｔが首尾一貫していることを確認できる。
１）Ｘは、まず、Ｔにおける全ての有効な証明書から構成される集合ＴＶを計算する。Ｔにおける有効な証明書とは、
ａ）自己署名済み証明書（ＭｘＳｘ）であり、または
ｂ）自己署名済み証明書がＴ内にあるＴ内のＭｘ（ＭｘＳｙ）によって相互署名済みであり、および、
ｃ）例えば満了、以前は妥当でなかった、フォーマット等、他の証明書有効性ルールを満たす
証明書である。
２）一意の公開キーを含むＴＶ内の全てのＭｘＳｘ証明書の集合ＴＳＳを定義する。
３）ＴＳＳ内のいずれかの証明書によって署名されたＴＶ内の全ての証明書を含む集合ＴＶ′を定義する。すなわち、ＴＶ′は、ＭｘＳｘがＴＳＳ内にある任意のＭｘＳｙを含む。
４）空集合ＴＶ″を作成する。
５）ＴＳＳ内の各証明書ｙに対して、以下を実施する。
ａ）ＴＶ′内の全てのＭｘＳｙのカウントがＴＳＳ内で見つかった証明書の過半数である場合、ＴＶ′内の全ての証明書ＭｙＳｘをＴＶ″に追加する。これは、全てのＭｙＳｙ（自己署名済み）証明書を含むべきである。他のＭｘノードのうちの過半数の署名を有さないＭｙは、このステップのため、ＴＶ″に加えられない。
６）ＴＶ″内の全ての自己署名済み証明書を含む集合ＴＳＳ′を作成する。
７）ＴＳＳ′内のいずれかの証明書によって署名されたＴＶ″内で見つかった全ての証明書を含む集合ＧＴを作成する。ＧＴに加えられた証明書は、ＴＳＳ´に存在しないＭｘノードをターゲットとする証明書を含まない。
８）ＸはＴをＧＴと置換する。
典型的な実装において、最初はＴ＝ＧＣ＝ＧＴである。

実際、Ｔ内の有効なＭｘＳｘを有するノードによって署名されたＴ内の任意の有効証明書ＭｘＳｐは、ノードｐがＴ内にＭｐＳｐを有しない場合には、破棄されないであろう。その証明書は、以下で述べるＡＬＧ０２と共に後で使用するために取っておく。要点は、ＭｘＳｘが信頼され、ｘによって署名された証明書もまた信頼されているが、使用されていないということである。

ＡＬＧＯ１のステップ８は、ＸがＴから証明書を切り取ることを許可することに注目されたい。すなわち、Ｇ内の過半数のノードの信頼を有さないノードが署名した証明書は、Ｔから破棄される。また、ＡＬＧＯ１はＴを変化させることに注目されたい。これは、Ｔ入力を必要とし、出力として置換Ｔを生成する。いずれかのＴ上で繰り返し動作する場合、ＡＬＧＯ１は、一度反復した後、不変状態に到達する。すなわち、ＡＬＧＯ１がＴを入力として処理し、ＧＴを出力として生成する場合、ＧＴ上におけるＡＬＧＯ１の任意の将来の反復によって、ＧＴが完全に生成される。ＡＬＧＯ１は、冪等元である。

ノードのいくつかの集合に対して、Ｎ／２個以下の相互ターゲット化証明書が存在する場合、ＡＬＧＯ１が空のＴを生成可能であることに注目されたい。Ｘに渡された最初のＧＣが証明書の適切な集合を含むことが極めて重大である。１つの実装において、これは、Ｇ内のノードに対するただ１つの自己署名済み証明書を含むようにＧＣを設定し、その後、ＡＬＧ０２およびＡＬＧ０３（以下で議論する）を用いてＴを「成長させる」ことによって達成可能となる。

１つの実装において、Ｔ内の有効な証明書は、「満了」時間値を含む証明書であり、現在の日時（ＡＬＧＯ１が動作する際に計算される）がその時間値を過ぎていないものである。過去の「満了」時間値を有する証明書は、無効であるとみなされる。

１つの実装において、Ｔ内の有効な証明書は、「以降有効」の時間値を含む証明書を含む証明書であり、現在の日時（ＡＬＧＯ１が動作する際に計算される）がその時間値を過ぎているものである。将来の「以降有効」の時間値を有する証明書は、無効であるとみなされる。

ノードをＧに追加する：１つの実装においては、Ｇ内のノードは、以下の機構を用いて証明書を作成することにより、Ｇに対して追加のノードを作成し追加することができる。これらのノードは、その後、ＡＬＧＯ２を使用し得るＷのメンバに対し、その信頼のおけるストアを更新するために送られ得る。

図６を参照して、ＡＬＧＯ３と呼ばれる他のプロセスについて述べる。この実装においては、ＡＬＧＯ３は以下を含む。
１）新たなノードＭｐが非公開キーと、非対称暗号プリミティブを用いる自己署名済み証明書（ＭｐＳｐ）とを作成する。
２）Ｇ内の各ノードＭｘが、ＭｘＳｐ証明書を作成する。
３）Ｍｐが、Ｇ内の他のノードのそれぞれに対するＭｐＳｘ証明書を作成する。
４）ステップ１、２および３の結果から構成される集合ＩＮを定義する。ＩＮは、（Ｎ＊２＋１）個の証明書を含む。

１つの実装において、集合ＩＮは、１個またはそれ以上の新たなノードによって作成された証明書を含むことができる。また、アタッカによって送られるＩＮ証明書集合が、適切な証明書に加えて、任意の他の不正確な証明書を含む可能性もあることに注目されたい。

１つの実装においては、Ｍｐ個のノードは、常に対で作成される。すなわち、２Ｍｐ個のノードが常にＡＬＧ０３内で作成される。これは、Ｎが奇数である必要があるときに極めて重大となる。タイブレーカが存在し、Ｎが偶数である場合には、必要ではない。

１つの実装においては、Ｘは、証明書を追加することによって新たなＴを作成することが可能である。これは、より多くのノードを含むか、または、有効性のためにもはやＴ内に存在しないノードを置き換えるために、ＸがＧを安全に再定義することを可能にすることから、望ましいものであり得る。Ｘは、証明書ＩＮの集合を受け取る。以下のＡＬＧ０２によって、我々は、ＩＮのどの部分がＴに追加されるべきかを計算することが可能になる。このプロセスによって、我々は、（アタッカによって送られた）不正確な証明書を、その証明書が我々の信頼のおけるストアＴに入る前に排除することが可能になる。

図７を参照して、ＡＬＧＯ２と呼ばれる他のプロセスについて述べる。本十実装においては、ＡＬＧＯ２は以下を含む。
１）ＩＮ内にＭｘＳｘ証明書の集合ＳＳを作成する。これは、Ｔへのエントリを入念に検査されているＩｎ内の全ての自己署名済み証明書の集合である。
２）ＳＳ内の各ＭｙＳｙ証明書に対して（ｙは入念に検査されるべきノードである）、
ａ）Ｔ内のいずれかのＭｘＳｘによって署名されたＴまたはＩＮ内の全ての証明書の集団Ｔ′を作成する。Ｔ内のＭｘＳｘは信頼性があるため、Ｔ′は、ＴまたはＩＮに存在する信頼のおけるノードによって署名された全ての証明書を含む。
ｂ）Ｔ′内の全てのＭｘＳｙの集団ＶＴを作成する。ＶＴは、ｙをターゲットとする全ての信頼性ある証明書の集団である。
ｃ）ＡＬＧＯ１のステップ１で設立されたものと同様の有効性ルールを用いてＶＴ内の各証明書の有効性をチェックし、ＶＴから無効証明書を破棄する。
ｄ）ＶＴ内で任意のＭｘＳｙに署名を行ったＴ内のＭｘＳｘの数の合計がＴ内の全てのＭｘＳｘの過半数でない場合、ＳＳ内の次のＭｙＳｙに対して、ステップ２を繰り返す。この場合、ｙは、適切に検査されなかった。信頼性のおけるノードの過半数は、ｙを保証する証明書を作成しなかった。
ｅ）ＩＮ内の全てのＭｙＳｘ証明書の集合ＶＣを作成する（この場合、ｘはＴ内のＭｘＳｘによって表されるノードである）。これは、ｙによって署名され、Ｔ内の信頼性あるノードをターゲットとする全ての証明書の集合である。
ｆ）ＶＣ内の証明書の合計がＴ内の全てのＭｘＳｘの過半数である場合、ＭｙＳｙおよびＶＣ内の全ての証明書をＴ′に追加する。入念に検査されたノードｙがＴ内の信頼性あるノードの過半数を保証した場合、信頼性ある集合Ｔ′に、Ｔ′内の信頼性あるノードをターゲットとするｙの全ての証明書とともに、ｙの自己署名済み証明書を追加する。
ｇ）ＴをＴ′と置換する。
３）Ｔ上でＡＬＧＯ１を実施する。

ＡＬＧＯ２は、Ｘに対して既知であるように、Ｇ内のノードの数が変化することを許容する。その理由は、Ｔはそれらの新たなノードに対する証明書を含むからである。

ノードをＧから除去する：ノードをＧに追加可能であることに加えて、Ｇからノードを除去できることもまた有益である。１つの実装において、Ｇ内のノードは、以下の方法でＧからノードＭｐを除去できる。失効証明書を、失効のターゲット（Ｍｐ）と、Ｇ内のノード（Ｍｘ）による署名と、失効値とを含む証明書として定義する。１つの実装においては、失効値は、「無効」と呼ばれる証明書の値フィールドである。失効値は、Ｘ並びにＧおよびＷのメンバがその証明書のターゲットが無効であること意味することを理解する何らかの値であればよい。有効な失効証明書は、Ｍｘに対する有効な署名を有するものである。

ＡＬＧ０４と呼ばれる他のプロセスについて述べる。この実装においては、ＡＬＧＯ４は以下を含む。
１）Ｍｐをターゲットとする全てのＭｘによって作成された失効証明書の集合ＧＲを作成する。ＭｘおよびターゲットであるＭｐによって作成されたＧＲ内の任意の証明書としてＭｘＲｐを定義する。
２）ＧＲはＸ（および一般的にはＷ）に分配される。

１つの実装において、Ｘは証明書ストアＴＲ内に、そのような全ての失効証明書を記憶する。

１つの実装において、Ｔ内の有効証明書は、ＴＲ内に証明書ＭｘＲｐが存在しない証明書ＭｘＭｐである。すなわち、本実装は、ＴＲ内の有効ＭｘＲｐの存在がＴ内のいくつかのＭｘＳｐを無効にするように、ＡＬＧＯ１のステップ１を修正する。ＴＲ内に証明書ＭｘＲｐが存在し、Ｔ内に証明書ＭｘＳｐが存在する場合、Ｔ内のＭｘＳｐはもはや有効ではない。好ましい実装では、失効証明書ＧＲの集合を受け取ったことに応じて、ＸがＧＲをＴＲに追加し、ＡＬＧＯ１を実施する。好ましい実装においては、Ｘは、Ｔ内のＭｘＳｘによって署名されたＧＲからの証明書を、ＴＲに追加するのみである。

１つの実装においては、失効証明書ＭｙＲｙは（ここではＭｙノードがそれ自体を無効にする）、Ｍｙによって署名された全ての証明書が、そのＭｙＳｙ証明書を含むことから、無効であると考えられるべきである。これは、ノードが自身を無効にすることを可能にする。１つの実装においては、これは、ＭｘノードがＭｘＲｙ失効証明書を作成することを除外するべきでない。

１つの実装においては、各ＭｘがＣＡによって署名された証明書を使用し、そのＣＡがＭｘに対する失効証明書を発行する場合、Ｘは、Ｍｘによって署名された各証明書を無効にし、このような証明書を全てＴから除去することができる。この場合、Ｘは、ＴＲ内にＣＡの失効証明書を記憶するべきである。本実装は他の有効性条件をＡＬＧＯ１のステップ１に追加することに注目されたい。例えば、図８は、Ｍ１が証明書Ｍ１Ｒ２を介してＭ２を無効にした際の証明書間の関係のマップを示す。

Ｇを用いて作業を実施する：Ｇは今や、認証された方法でＸからサービスをリクエストすることができる。ＧがＸを用いてアクションＡを実施することを望んでいると仮定する。Ａは、ＸがＧに対して認証することを望むアクションである。すなわち、Ａを実施するために、Ｘは、アクションが達成されることをグループＧが望むということについての有効な認証を必要とする。

１つの実装においては、ＡｘがアクションＡを権威付けるＭｘによって署名されたメッセージとなるように、Ａｘを定義する。全てのＡｘメッセージから構成される集合ＡＧを定義する。この場合、各Ａｘは、対応する一意のＭｘによって署名される。例えば、Ｍ１はＡ１に署名し、Ｍ２はＡ２に署名する、等である。

１つの実装においては、ＭｘノードＭＩｎｉｔは、Ｇ内の他の全てのＭｘノードから署名を照合することによってＸとの通信を開始し、管理する。

ＡＬＧＯ４と呼ばれる他のプロセスについて述べる。１つの実装においては、Ｘは、Ｇが以下の方法でＡを実施するように権限を与えることができる。
１）Ｘが、ＭＩｎｉｔからＡＧをリクエストする。
２）ＭＩｎｉｔが、その非公開キーを用いてＡｘに署名し、ＡをＧ内の他の全てのＭｘに送る。
３）各Ｍｘの１個またはそれ以上がＡｘを作成し、これらの値をＭＩｎｉｔに返す。
４）ＭＩｎｉｔは今やＡＧを保持している。ＡＧは、Ｎ個以下の署名済みメッセージを含み、各々は一意のＭｘからのものである。
５）ＭＩｎｉｔが、ＡＧをＸに送る。
６）Ｘが、各Ａｘを有効にし、コマンドが有効であり、署名が有効であり、且つＡｘに署名するＭｘがＴ内に存在することを確実にする。
７）Ｘが、一意なＭｘノードからの有効なＡｘメッセージの数を合計する。
８）合計がＴ内の全Ｎ個の署名済み証明書の過半数である場合、Ｘはアクションを認可する。

１つの実装においては、ＭＩｎｉｔは存在せず、各ＭｘはＡｘを直接Ｘに送る。この場合、Ｘが控えめなＭｘから各Ａｘメッセージを受け取った後、ＡＬＧＯ６を実行する。

ＡＬＧＯ６と呼ばれる他のプロセスについて、図９を参照して述べる。この実装において、ＡＬＧＯ６は以下を含む。
１）各Ｍｘが、ＡｘをＸに送る。
２）Ａｘを受け取る都度、Ｘは、それまでに受け取ったＡｘのそれぞれを検証し、コマンドが有効であり、署名が有効であり、さらにＡｘに署名するＭｘがＴ内に存在することを確実にする。
３）Ｘが、一意のＭｘノードからの全てのこのような有効なＡｘメッセージの数を合計する。
４）その合計がＴ内のＭｘＳｘ証明書の過半数である場合、Ｘはアクションを認可する。

証明書は、ＴおよびＧＣのような組またはグループ内で処理され、これらのグループ内の典型的な実装の証明書は、同じグループ内の他の証明書と比較した場合、同一であるコンテンツ部分を含む。例えば、Ｇ内の全てのＭｘに対して、所与のＰに対して作成された全てのＭｘＳｐ証明書は、Ｍｐに対する同一情報を含む。この静的コンテンツは、認可されているアクション、または証明書署名者によって相互署名された他の証明書であってもよい。さらに、同じ概念が、コンテンツの署名者に対しても当てはまる。Ｇ内の所与のＰに対して、Ｐによって作成された全てのＭｐＳｘがＰによって署名される。この対称性のため、相互署名が生じる前に証明書が互いの知識を有する場合、上記プロセスの複雑性を実質上低減することが可能になる。すなわち、合意形成は同期して行われ、ノード間ではアトミックである。多くの典型的実装においては、Ｇ内にどのメンバを含むかについてノードが互いに同意しなければならないことが真実であるため、これは事実である。次に、簡素化されているが同等の方法の具体的な形態を示し、この署名および相互署名が単にＧ内の多数のＭｘ間での正式な同意であることを示す。

同期符号化を用いる１つの実装においては、各Ｍｘは、相互証明されるべきＧ内のＭｘを互いに知っている。Ｇを識別する１組の非公開キーを生成することが可能である。このキーリストは、各々のＭｘによって別個に署名可能であり、公開キーのリストおよびＧ内の各Ｍｘの署名を含む１個の文書に追加可能である。このことは、Ｇ内の各Ｍｘによってハッシュされ、署名されたＧの許可メンバのリストを含む文書Ｄを生成し、図１０におけるＪＳＯＮフォーマットに示すように（全てのＭｘが署名されたと仮定して）同数のアイテムを有する第２のリストを生成する。１つの実装においては、Ｄは「クロック」整数値を含む。他の実装においては、現在の時間値は、「クロック」値として十分となり得る。

いくつかの実装においては、満了、以前は有効ではない、等の他の有効性の値が存在し得る。

この符号化は、上記非対称証明書モデルと比較して、かなり効率的である。７個のメンバを含むＧに対して、非対象アプローチは４９個の離散的な非対称証明書を生成し、ＡＬＧＯ１を介する処理の検証を要求する。同期符号化において、同一情報は、全ての自己および相互署名を含んで存在するが、１個の文書に対して７個の署名のみが必要となる。さらに、Ｔ，ＧＣおよびＧＴはＤのみを含む。さらに他の証明書は必要ない。

１つの実装においては、ＡＬＧＯ１は、Ｄが存在すると仮定して、ＡＬＧＯ１０１と置換することが可能である。この場合、Ｔ＝ＤおよびＤ′＝ＧＣである。本実装においては、全てのＭｘメンバは、Ｄを置換する新たなＤ′がＴ内に保持されるクロック値よりも大きい「クロック」値を有することに同意する。すなわち、より古いＤ文書を置換するべきＤ′文書は、より大きい「クロック」値を有することになる。

ＡＬＧＯ１０１は以下を含む。
１．Ｄ内の全ての一意キーをカウントし、２で割った総数をＣＯＵＮＴとして定義する（切り上げ）。
２．変数ｎを定義し、ゼロに設定する。
３．以下の基準を満たす場合、Ｄ′内の各署名に対してｎの値を１だけ増す。
ａ）署名が、Ｄ′内のキーのリストに見出されるキーとマッチングすることを確実にする。
ｂ）署名が、Ｄ内のキーのリストに見出されるキーとマッチングすることを確実にする。
ｃ）署名が、Ｄ′内のキーのリストに正しく行われたことを確実にする。
４．ｎがＣＯＵＮＴよりも大きいか、またはｎがＣＯＵＮＴに等しく、さらにタイブレーカノードがステップ３を正しく完了した場合、継続する。そうでない場合は、Ｄ′を拒否する。
５．Ｄ′内の「クロック」値がＴの「クロック」値よりも大きい場合、継続する。そうでない場合は、Ｄ′を拒否する。
６．Ｄ′は、満了、以前は有効ではない、等を含む全ての有効性およびフォーマット要件を満たす。これらの１個が満たされない場合、Ｄ′を拒否する。
７． ＤをＤ′と置換する。

いくつかの実装においては、ＡＬＧＯ１０１はまた、ＡＬＧＯ２、ＡＬＧＯ３およびＡＬＧＯ４を置換可能である。すなわち、我々の同期符号化の場合、ノードのＧへの追加または除去およびＴの更新は全て、ＡＬＧＯ１０１を介して機能する。Ｄ′内のキーのリストは、新たなＭｘ個のノードに対するキーを含む、より多いか、またはより少ないキーを有することが可能であるので、ＡＬＧＯ１０１はＴを変更し、さらにそれを検証することが可能である。いくつかの実装においては、「カウント」フィールドがＧ内のトポロジ変化につき常に１だけ増加する場合、Ｄ′メッセージのストリームは、任意のＸ内のＴを、任意の有効な前バージョンから更新することが可能である。これは、送信されたＤ′がＸによって保持されるＤよりも１だけ大きい「カウント」値を有するように、各Ｄ′をＸに送信することにより達成することが可能である。これは、任意の数のＸにわたって、非常に簡単で的確なＴの同期を許容する。例えば、図１１は、全ての署名および有効性の要件が満たされていると仮定して、図１０に見られるＤを置換する。

１つの実装においては、同期符号化を使用するようにＡＬＧＯ５を変更することも可能である。これらの場合、メッセージグループＡＧの代わりに１個の文書ＡＤが送られる。ＡＤは、署名リストおよびアクションＡを含む。個々のＡｘメッセージの代わりにＡＤ内の署名に対して、署名の検証が行われる。

いくつかの実装では、たとえ少数であっても、Ｍｘノードの一部の組が認可局として行動できるようにすることが有益である。整数の「定足数」フィールドをＤに加えることにより、ＡＬＧＯ１０１に見られるＣＯＵＮＴ値の代わりに定足数値を使用することが可能である。すなわち、厳密な過半数を設定する代わりに、ノードの必要数を任意の値に設定することが可能である。例えば、Ｇが７個のノードを含む場合、定足数を２に設定可能である。この場合、ＡＬＧＯ１０１は、Ｄの有効な置換となるために、２以上より多い数のＤ′に対する署名を要求する。

いくつかの実装では、ある一定のＭｘノードが他のノードよりも安全でない例を構成するために、サブグループＧ′に分類されグループ化された複数のＭｘノードを有することが有益である。この場合、「バケット」と呼ばれる図１２に見られるものと類似のグループ化構文を定義できる。

１つの実装においては、「バケット」ＧＢｘ内の各グループは、ミニチュアグループＧであると考えられる。すなわち、Ｇは、「定足数」フィールドおよび真であると評価するＧ内のＧＢｘバケットの数に基づいてアクションを認可し、このような各々のバケットＧＢｘは、その定足数値およびＧＢｘ内のＭｘの数によって定義される。さらに、これらのバケットの各々は、必要に応じてさらなるバケットグループを内部に含むことができる。これは、Ｇのフラクタル表現であり、Ｇ内の投票特性の任意のコントロールを可能にする。Ｄ′をＤの置換として認可するために、ＡＬＧＯ１０１が再帰的方法で実行され、その結果、各バケットは、そのバケットに対してＡＬＧＯ１０１を実行させる。例えば、図１２に見られるＤは、Ｍ４および署名に見られる（Ｍ１、Ｍ２、Ｍ３）の過半数を有するＤ′からの置換を許容する。Ｄはまた、（Ｍ１、Ｍ２、Ｍ３）の過半数および（Ｍ５、Ｍ６、Ｍ７）の過半数によって満たされる。

この実装は、特定の性能特性、負荷分散、安全性、および分配特性に対して微調整されるＧのトポロジを、厳密な多数決システムを用いて可能となる以上に許容するという利点を有する。関連する認可セクションで見られるように、この原理は、包括的認可代数学にさらにまとめることが可能である。
グループコマンドおよびコントロールを用いるグループ権限の作成

グループコマンドおよびコントロール機構の様々な実装について述べたが、この機構は、グループ権限（ＧＡ）と呼ばれる概念の作成に適用することも可能である。ＥＮＴにおいて、ＧＡは、従来のＰＫＩシステムにおける認証局（ＣＡ）と同等である。いくつかの実施形態によれば、ＧＡは以下のように描写され得る。

最初に、ＰＫＩシステムＰＫおよびユーザＵｘを定める。Ｕｘは、システムの任意のユーザである。Ｕ１はユーザ１等である。Ｕｘによって作成される非公開／公開キー対ＵｘＰＰＫを定義する。この場合、Ｕｘは非公開キーを保持する。例えば、Ｕ１のＰＰＫはＵ１ＰＰＫである。Ｕｘは、ＰＫ内の証明書を管理することが義務である証明書コントロールオフィサを表す場合もある。Ｕｘがこのようなオフィサである場合、Ｕ１Ｐは、Ｕｘによっては作成されそうにないであろうが、発信側ユーザによっては作成される。この場合、以下の実装に影響を与えないので、Ｕｘの代わりにオフィサを用いる。暗号プロセスＣＡＬを定義する。これは、使い古された非対称暗号技術である。

Ｎ個のノードのグループＧを作成する。「グループコマンドおよびコントロール」セクションにおいて上で概説した機構を用いることにより、証明書ストアＧＣを作成する。それらの規則に従うと、Ｇは１個のエンティティとしてコマンドを発行することができる。Ｇ内の任意のノードＭｘを定義する。この場合、各々のＭｘは、ＧＣ内の自己署名済み証明書および相互署名済み証明書を有する。例えば、Ｍ１はＧ内のノード１である。

各ノードＭｘは、ＵｘＰＰＫの公開部分を含む証明書に署名することが可能である。このような各々の署名済み証明書は、ＭｘがＵｘにつき１個以上の固有署名済み証明書を作成しないように一意の相手Ｕｘを識別するものとして証明書が定義できるよう、証明書フィールドの一意の組み合わせを含まなければならない。この証明書をＵｘＣとして定義する。１つの実装において、このような全ての証明書は、グループコマンドおよびコントロールセクションにおいて、同期方法につき１個の文書ＵＣに組み合わせることができる。

１つの実装において、当業者は、Ｘ．５０９ｘ標準に存在するフィールド、例えば組織、下位組織および共通名等の共通するものを選択することができる。

１つの実装において、証明書内の独自の情報は、特定の一意的数値を含むフィールドになり得る。この場合、全てのＵｘは、証明書を介して、無名数として定義される。

１つの実装においては、Ｕｘは、ＡＬＧＯ１を用いるＧ内の各Ｍｘから証明をリクエストできる。

ＡＬＧＯ１と呼ばれる他のプロセスについて、図１３を参照して述べる。本実装においては、ＡＬＧ０１は以下を含む。
１．Ｕｘが、ＵｘＰＰＫを作成する。
２．Ｕｘが、ＵｘＰＰＫ内の公開キーとＵｘに対する一意識別子Ｉを含む証明書リクエストＵｘＲを作成する。
３．Ｇ内の各Ｍｘは、ＵｘＲを受け取ったときに以下のアクションを実施する。
ａ）Ｍｘは、ＵｘＲ内の一意識別子を含む証明書を作成していないことを検証する。その時点で次のＭｘに対してステップ３を実行していた場合、ユーザに証明書を戻さない。
ｂ）Ｍｘは、ＵｘＰＰＫの一意識別子および公開部分を含む新たな証明書ＵｘＣを作成し且つ署名し、この証明書をＵｘに戻す。

Ｕｘは、全てのＭｘによって作成されたＵｘＣからなる証明書の組ＵｘＳを有する。この場合、各々の証明書は、一意のＭｘによって署名される。ＵＡＬＧＯ１のステップ４の出口は存在しないと仮定すると、ＵｘＳはＮ個の証明書を含む。

グループＧは、従来のＰＫＩシステム内において、ＣＡに対する置換として使用可能である。

Ｕｘは、ＰＫのいずれかのユーザに接触し、ＵｘＰＰＫの非公開部分を用いて認証することができる。Ｘを、ＰＫに対してＵｘの認証を望むＵｘによって接触された相手方として定義する。この場合、ＰＫはＧをＧＡとして使用する。ＵｘＡを、ＵｘによってＸに送られる署名済み認証として定義する。一般に、Ｘはランダム値をＵｘに送り、Ｕｘは署名済みメッセージＵｘＭを用いて応答する。この場合、ＵｘＭはＵｘの非公開キーによって署名されたものである。

ＡＬＧＯ２と呼ばれる他のプロセスについて述べる。本実装においては、ＡＬＧ０２は以下を含む。
１．Ｘが、ＵｘＳをリクエストする。
２．Ｘが、ＵｘＭが適切な署名および情報を含むことを検証する。そうでない場合は、認証は失敗である。
３．ＵｘＳ内の各ＵｘＣに対して、Ｘが、ＵｘＣがＧのメンバによって署名されたことを確認し、ＵｘＣが有効であることを宣言する。オプションで、Ｘは、同様に他の型式の有効性、例えば、有効開始日および有効終了日等を任意にチェックすることとしてもよい。
４．Ｘが、全ての有効なＵｘＣ証明書の数を含む合計Ｓを生成する。
５．Ｓが、ＮがＧ内のノードの数であるとして（Ｎ／２）＋１よりも大きい場合、ＸはＵｘを認証している。

Ｇ内のＪ個のノードがアタッカによって占拠されていると仮定する。これは、Ｊ個のＭｘ署名が信頼出来ないことを意味する。しかしながら、ＪがＮ／２よりも小さい限り、システムは安全である。アタッカがなりすまされた証明書を用いてＵｘＳを作成する場合、ＵｘＳはＪ個の証明書のみを含む。このことは、アタッカが、ＡＬＧＯ２のステップ５における認証に合格するのに必要な過半数を得ることを妨げる。

１つの実装において、Ｘは追加的に、ＵｘＣに署名する各ＭｘがＧ内の他のＭｘの過半数による有効な相互署名を有することをさらに検証する。もしそうでない場合は、そのＭｘによって署名されたＵｘＣは、無効であるとみなされる。さらに、ＸによるＡＬＧＯ２の将来の繰り返しは、この情報を用いて、Ｍｘを完全にディスカウントすることもできる。Ｍｘがディスカウントされた場合、Ｘによれば、Ｇ内のノードの総数はＮ−１となる。

信頼レベルという概念を定義する。これは、Ｘを成功裏に検証し認証するＧ内の認証ノードの割合を意味する。これは（Ｓ＊２）／Ｎの値である。信頼レベルが１００％よりも高い場合、システムは安全であり、このようなトランザクションを完全に信頼できると定義できる。１００％よりも高いレベルは、追加の値を有さないことに注目するべきである。したがって、２００％の信頼レベルを生成するＧ内の全てのＭｘに対する完全な認証チェックは、１００％よりも高い信頼レベル以下の値を本質的に有する。

タイブレーカノードを使用し、タイブレーカノードが適切に認証され、Ｓ＝Ｎ／２である場合、信頼レベルに明らかな過半数を与えるためにＳに１を加算する。

基本的には、（Ｎ／２）＋１個よりも多いＭｘの任意のエンティティ収集コントロールがシステムをコントロールする。そのエンティティは、それによってコントロールされていないＭｘが過半数のＭｘによって無効化されたその相互署名を有するように、Ｇを変更することが可能である。この場合、Ｎは、適切な相互署名を有するＭｘの数となり、これはエンティティによってコントロールされたＭｘのみになる。従って、１００％よりも高い信頼値は完全な信頼を表す。

１つの実装において、Ｘによるある種の動作は、信頼レベルにより制限され得る。例えば、２０％の信頼レベルは、低セキュリティデータに対する読み出し専用の情報アクセスを許容し、５０％のレベルは、メッセージ送信のようなクリティカルでない相互作用を許容するとともに、Ｅメールがチェックされることを許容し、１００％以上のレベルは、送金、ＰＫ方針の変更等のクリティカルなトランザクションに対して使用される。

各Ｍｘ証明書がＣＡによって署名される１つの実装において、Ｘは、Ｍによって署名された各ＵｘＣがそのＣＡによって正しく署名されたことをさらに検証することができる。もしそうでない場合は、ＵｘＣは無効であることが宣言される。

１つの実装において、Ｘは、Ｔと呼ばれる集合の内部にＧの部分集合を維持し、Ｇの代わりにＴに対して検証を行う。Ｔは、ＧのＮ−１個以下のノードを含み得る。

１つの実装において、Ｘは、有効なＭｘに対して１個のＵｘＣのみを検証する。ＵｘＣが有効である場合、ＸはＵｘを認証している。この場合、Ｘの信頼レベルは２／Ｎである。例えば、Ｎが３である場合、信頼レベルは６６％となる。この動作モードは、Ｇ内のただ１個のＭｘを占拠したアタッカがＸに対して有効となることを許容するため、推薦されない。しかしながら、この動作モードが、金融取引、クリティカルなデータの交換、ならびにコマンドおよびコントロールのためにＴＬＳ／ＳＳＬ接続を認証するための全てのウェブブラウザにおける現存の最新式機構と、セキュリティ上同一であることに注目する価値がある。

ＥＮＴは、グループ権限構造を実現することもできる。このＧＡは、異なる非対称キープロセスを実行する異なる場所にあるサーバのグループから構成される。このようなサーバの各々は、ルートと呼ばれる。各ルートは、他の全てのルートから独立して署名および動作を行う。各ルートは、連続する文字の集合として定義された一意な名前を有する。同時に、ルートは、グループコマンドおよびコントロール並びにグループ権限セクションに見られるプロセスを用いて、新たなベリニムを発行することができる。好ましい実装は、奇数個のノードを有するＧＡを作成して、デッドロックを回避することである。ＥＮＴにおいては、グル―プコマンドおよびコントロール内のＡＬＧＯ１において計算された過半数を作成する全てのルートに対する署名済みおよび自己署名済み証明書の集合は、ルートリングと呼ばれる。１つの実装において、これらの証明書は、グループコマンドおよびコントロールセクションにつき１個の文書に同期して組み合わせられ得る。

ＥＮＴルートは、破棄される場合もある。これは、ＥＮＴシステムの安全性または信頼性を低減するいずれかの理由のために発生する可能性がある。いくつかの潜在的原因は、不良コンピュータハードウェア、悪意ある攻撃、監査の失敗、自然災害、計画されたルートの老化等である。ルートは、グループコマンドおよびコントロールセクションにおいて概説された機構を介して破棄される。ルートが破棄されるべき場合、ルートリング内の他の各々のルートサーバは、破棄されるべきルートをターゲットとする破棄証明書を生成することになる。過半数のこのような証明書が一意のルートによって発行されると、問題のルートは、グループコマンドおよびコントロールにおいて概説された機構により、ルートノードの連結グラフから除去される。これらの証明書を受け取るＥＮＴシステム内のユーザは、同様に、破棄されたルートノードをその信頼性ストア（Ｔ）から除去する。

１つの実装において、ルートノードはそれ自体を無効化することができる。この場合、システムは、他のルートによる過半数の無効証明書と同等であるとして、その無効化を処理する。すなわち、それ自体を無効化するルートは、過半数の他のルートがそのルートに対する無効証明書を生成したかの如く処理されなければならない。様々な実装によれば、両方の機構を使用することが推薦される。

ＥＮＴルートもまた、加算可能である。これは、システムが成長する必要があるとき、または破棄されたルートが置換される必要があるとき、発生する。ＥＮＴは、グループコマンドおよびコントロールに見られるノードを加えるための機構を利用して、このタスクを成し遂げる。まず、新たな各ルートに対するＰＰＫが生成される。その後、公開キー部分が、ルートリング内の各ルートに送られる。ルートリングルートの各々は、その後、新たなルートの公開キーを含むこの新たなルートに対する相互署名を生成する。これらの証明書は、その後、グループコマンドおよびコントロールセクションのＡＬＧＯ２に概説された機構を介して、各ルートの信頼性ストア（Ｔ）に加えられる。
ＥＮＴシステム状態および信頼性ストア

ＥＮＴルート信頼性ストアは、理想的には、全ＥＮＴネットワーク内の（ＥＮＴソフトウェアを実行する）あらゆるＥＮＴ可能化システム上に記憶される。これらの装置は、ＥＮＴノードと呼ぶことが出来る。ＥＮＴシステムの全てのユーザが、別個の信頼性ストア（Ｔ）を維持することが有益である。これによって、部分的に、または散発的に接続されたＥＮＴ装置が、ＥＮＴシステムのルートまたは他の部分がたとえ到達不能であっても、動作を有用に維持することが可能になる。さらに、アタッカは、システムの有効性に全体として損傷を与えるためには、システム内の多数のノードを打ち負かすことが必要になる。ルートノード無効化および新たなＥＮＴルートノードが処理されるので、これらの証明書は、グループコマンドおよびコントロールのＡＬＧＯ１（またはＡＬＧＯ１０１）が決定論的かつ冪等元となった後、ＥＮＴシステム全体が更新された同一の状態を有するようになるまで、ＥＮＴノード間で伝播され得る。

１つの実装において、ＥＮＴノードの信頼性ストアは、通信または情報交換を行う度に同期され得る。１つの実装において、ノードは、信頼性ストアＴ内の全ての証明書を、処理する前に交換する。これは、かなり大量のデータになる場合があるのであまり好ましくない。

１つの実装において、ルートの自己署名済み証明書から暗号ハッシュが生成される。これらの証明書は、最初にオーダされる。決定論的オーダリングは、この要件を満たす。好ましい実装においては、オーダリングは、ルート名の標準アルファベット順オーダリングにより構成される。ルート自己署名済み証明書のオーダリストが一旦作成されると、数値ハッシュを生成するハッシング関数を介して各々のこのような証明書を順に挿入することにより、ハッシュが計算される。各ＥＮＴノードは、このハッシュを独立して作成し、結果的に生じる値を記憶する。

１つの実装において、２個のＥＮＴノードが通信するか、または情報交換するとき、このハッシュをまず最初に交換することになる。このハッシュのミスマッチは、２個のＥＮＴノードに、その信頼性ストア（Ｔ）を交換するように強いる。グループコマンドおよびコントロールのＡＬＧＯ１（ＡＬＧＯ１０１）に示すように、全てのノードが交換された後に、信頼性ストアが再計算される。ＡＬＧＯ１（ＡＬＧＯ１０１）の１反復の後、双方のＥＮＴノードは、同一の信頼性ストア、従って同一のハッシュ値を有することになる。

１つの実装においては、ルート証明書のアルファベット順のオーダリングが上記のように実施される。各証明書は、その後、ハッシュされる。このような各証明書のハッシュは、その後、順にデータオブジェクトに加えられる。実際、ハッシュ値は、共に順に連結され、ＥＮＴＳＴＡＴＥの値を生成する。さらに、ＥＮＴシステムバージョンを決定する値が、ＥＮＴＳＴＡＴＥに連結される。ＥＮＴシステムバージョンは、システムが使用する定数、許可されたプロセス等の情報を含むことができる。一旦計算されると、ＥＮＴＳＴＡＴＥは、（ＥＮＴＳＴＡＴＥにおけるその位置ずれにより）個別に認識可能な全てのルートを含むオブジェクトまたはデータ、さらにノード間の互換性チェックのために使用することが可能なシステムコンテキスト値を反映する。このＥＮＴＳＴＡＴＥは、その後、ノード間で交換可能である。ＥＮＴＳＴＡＴＥのハッシュが、最初に交換され得る。これがマッチングしない場合、信頼性ストアの全体またはその一部（ＥＮＴＳＴＡＴＥにおけるルートハッシュにより決定される）が、両方の信頼性ストアがマッチングするまで交換可能となる。

１つの実装において、ＥＮＴノードは、信頼性ストアの全体を受信するためにいずれかのルートに問い合わせることができ、加えて、他のＥＮＴノードからこの情報を受信することができる。

１つの実装において、システムバージョンは、多数の値および設定によって定義可能である。いくつかの設定は、使い古された暗号プロセス、最小キー長等の決め打ちされた値、証明書命名構造やフォーマット等のポリシー設定を含む。好ましい実装においては、これらの値全てが１個のバージョン属性値によって決定され、これがシステムバージョンとして使用され得る。

１つの実装において、ＥＮＴノードは、その信頼性ストアハッシュまたはシステムバージョン属性値が異なる場合、相互作用しない可能性がある。ＥＮＴノードは、取引を行う前に、その信頼性ストアおよびシステムバージョンのコンセンサスを得なければならない。システムバージョン上のミスマッチの場合、ノードは、その接続を終了するべきであり、より低いシステムバージョンを有するノードは、そのソフトウェアを更新するべきである。信頼性ストアミスマッチの場合、両ノードは、任意のトランザクションを継続できるようになる時点でコンセンサスに到達するまで、証明書を交換するべきである。コンセンサスに到達できない場合、トランザクションを終了するべきである。
ルートノードによるベリニム発行

ＥＮＴにおいて、ベリニムは、その一意番号またはマッピングに基づいて一意に識別可能であり、第１のルートによって発行されてリクエストを受け取る。他のＰＫＩシステムにおいて、名前または記述的部分は、発行した証明書に対して使用される。典型的な値は、名前、組織、組織単位等である。しかしながら、好ましい実装において、ＥＮＴは、番号としての抽象的な識別子を直接発行することによって動作する。各番号は、一意であり、グループ権限セクションにおいて述べたようにシステム内で一意であることが保証されている。２個のルートは、２個の要求元に対して同一の識別子を発行できない。他の実装では、英数字を使用するか、または要求元が所与の識別子の値を選択することも可能である。

ベリニムは、各々が一意なルートノードによって発行された１組の証明書として定義可能である。このような各証明書は、要求元が提出する公開キーや、システム内の一意番号を含む。従って、完全ベリニムは、Ｎはがそのベリニムに対して各々が一意識別子を含むＥＮＴ内のルートノードの数であるとして、Ｎ／２＋１個以上の証明書を含む。本文書内の様々な場所は、ベリニム信任状に関連する。この用語は、ベリニム内で見られる証明書をいう。ベリニムおよびベリニム信任状は、コンテキストが暗号プリミティブまたは信任状に関連する場合、相互交換可能である。いくつかの実装において、１個の文書は、グループコマンドおよびコントロールセクションにより、多数の証明書と同じ情報を含むことが可能である。

ベリニムの発行は、要求元（ベリニムをリクエストするユーザ）がＰＰＫを作成し、コアルートのうちのいずれかにリクエストを提出する状態で開始する。リクエストは、ＰＰＫ対の公開キーを含む。１つの実装において、リクエストはまた、以下で述べるピアノードのリストを含む場合もある。

１つの実装において、各々のルートは、要求元に割り当てる数値の所定のブロックを有する。例えば、ルート１はブロック値１−１０００を有し、ルート２はブロック値１００１−２０００を有する、等である。１つの典型的な実装において、これらのブロック範囲は、３２ビットブロックとなり得る。ブロックに対する許可を得たルートのみが、与えられたブロック内の番号を割り当てることができる。他のルートブロック内の番号の割り当ては、セキュリティ違反として処理するべきである。ＥＮＴの中央局は、どのルートがどのブロックを発行可能であるかを指示する。好ましい実装において、そのブロックの全てを発行したルートは、無効化され、新たなブロック上での発行制御を有する新たなルートと置換されるべきである。他の実装においては、そのブロックの全てを発行したルートに対し、中央局によって新たなブロックを割り当て可能である。好ましい実装において、ルートは、以前は発行されていないその有効ブロック内で選択された連番を、要求元に対して発行する。他の実装において、ルートは、その有効ブロックから乱数を発行することができる。

ルートが、そのブロックから、まだ割り当てられていない数値ＮＶを一旦選択すると、ルートは、要求元の公開キーおよびＮＶを含む証明書を作成し、それに署名する。この証明書は、その後、ＥＮＴシステム内の他の有効ルートのそれぞれへ送られる。これらの他のルートノードの各々は、ＮＶを含む証明書をまだ発行していないことをまず検証し、その後、同一要求元の公開キーおよびＮＶを含む証明書を作成し、それに署名する。この組の証明書は、その後、完全ベリニムとして要求元へ戻される。実際、要求元は、新たに作成された証明書をルートが預け入れるであろうデータストアをチェックするであろう。要求元は今や、いかなる目的にも応じた有効ベリニムを有する。

一旦発行されると、ベリニムに対する非公開キーが失われる、盗まれる、または無効化される可能性がある。ある時点で、非公開キーは、所与のベリニムに対して置換される必要がある。これらのイベントが発生する際、コントロールする非公開キーが失くなるとコントロールが失われるので、ベリニム所有者がベリニムのコントロールを再構築するための機構を設けることが重要である。従来のＰＫＩシステムにおいては、これは、問題のユーザの識別を再構築するためにいくらかの人材の関与を必要する。ＥＮＴにおいては、任意のＰＫＩシステムに適用可能なリレーショナル認可と呼ばれる新規な技術を用いて、プロセスが自動化される。
リレーショナル認可：

以下のセクションでは、ユーザがＰＫＩシステム内の自身の信任状または非公開キーのコントロールを失ったときにＰＫＩ信任状のコントロールを（置換によって）再構築する方法、または、他の信任状の相関的な使用に基づいて信任状のアクションを認可する方法について述べる。これらは、オーナシップポリシーおよび１つ以上のコントロールポリシーとして、それぞれ考えられ得る。上位概念、すなわちダビングされたリレーショナル認可は、エンティティが、自身で定義するピアグループに基づき、オーナシップを再構築し、エンティティに対する新たな署名済み信任状を作成するために証明書権限又はグループ権限とともに使用され得るそれらのピアの署名又はバウチャを要求することを許容しなければならない。さらに、同じ概念が、それ自体の信任状を有する１組のピアエンティティが、そのエンティティに対するアクション（またはコントロール機構）を裏付けることを可能にする。

第一に、リレーショナル認可は、エンティティ自身によって要求されるものを越えてピア内に存在するための特定の特性を必要としないことに注目されたい。すなわち、それは、匿名であり且つ非公開である。第二に、ＣＡは、現在時の最新式機構に基づいて更新を実施する必要がもはやなく、これは常に集中アプローチとなる。最後に、マンパワー、管理またはプロシージャに関してＣＡには何も要求が出されず、事実上、ＣＡは、抽象的識別を超えてユーザ／エンティティの情報を管理する必要が全くないことに、全体を通じて注目されたい。

このセクションの大半は、信用状の更新のためのリレーショナル認可の利用に特に集中するものであるが、概説した発明は、認可されたアクションが望ましく、多数の信任状がその認可に対する入力として望ましい時に、より広範囲に亘る適用可能性を有する。例えば、リレーショナル認可は、信頼性に対するアイデンティティのコントロールを証明し、データに対するアイデンティティアクセスを可能にし、または何らかの目的のために、信任状内の公開キーを、協力して作業する多数のエンティティから構成されるポリシーと置換することができる。

Ｎ個のエンティティ／ユーザのグループから構成されるＰＫＩシステムＰＫを定義する。ユーザは、人間、コンピュータ、モバイルデバイス、または信任状を記憶且つ使用可能にする他の電子的可能化システムであってもよい。ＣＡを、ＰＫの証明書権限として定義する。ＣＡは、グループ権限（ＧＡ）であってもよい。各エンティティをＵ１ないしＵＮとして定義し、さらにＣＡにより署名されたその信任状をＣ１ないしＣＮとして定義する。この場合、Ｕ５はユーザ５を表し、Ｃ５はユーザ５の信任状を表す。各エンティティの非公開キーをＰ１ないしＰＮとして定義し、この場合、Ｐ５はエンティティ５の非公開キーであり、さらにＰｍを任意のエンティティの非公開キーとして定義する。Ｕｘを、Ｃｘを新たな証明書Ｃｘ′と置換する必要があるエンティティとして定義する。Ｍ個のエンティティでグループＧを定義し、この場合、各エンティティは、ＰＫ内に存在し、Ｕｘとの実在の、または帯域外の関係を有する。それらのエンティティのうちの任意のものをＵｍとして定義する。Ｕｍに対する信任状をＣｍとして定義する。例えば、３個のエンティティＵｑ、ＵｚおよびＵｙでＧを定義し、各々はＣｑ、ＣｚおよびＣｙをそれぞれコントロールする。図１４を参照されたい。

１つの実装において、Ｇを含むデータオブジェクトＬおよびポリシーステートメントＳを定義する。Ｓは、ブール値を出力として提供するステートメントに、Ｇのメンバを組み合わせるための１組の処理ルールから構成されるポリシーステートメントである。例えば、Ｓは、連続的な文字リスト「（ＵｙおよびＵｑ）または（ＵｚおよびＵｙ）」を含むことが可能である。さらに他の非ブール値、例えば「過半数（Ｕｙ、Ｕｑ、Ｕｚ）」または「（Ｕａ、Ｕｙ、Ｕｑ、Ｕｚ）の２」等が作成され得る。Ｓは、ＣＡがＵｘのためのキーの取り換えを可能にする際の基準を定める。有用なルールは、基本ブール演算子（ＯＲ、ＡＮＤ、ＮＯＴ）、グループ化ステートメントに対するオーダリング、および関数を含む。任意の数の異なる関数がサポートされ得るが、関数は、真偽を示す値を戻さなければならず、Ｇの１つまたはそれ以上のメンバを入力として取らなければならない。Ｓの構文は、信任状フォーマットおよび具体的な実装に大きく依存するが、ＸＭＬ、ＪＳＯＮ、文字列または他のバイナリフォーマットから構成することが可能である。これらのステートメントは、もしステートメント内の任意のＵｍが「真」の値と置換されるのであれば、真偽を評価することができる。デフォルトでは、全てのこのような値は偽であるとみなされる。要するに、Ｕｍ値は、Ｕｍがアクションを認可するバウチャに署名した場合、または、Ｃｍが自身で真であると評価したポリシーＳｍを含む場合、ＡＬＧＯＹを介して「真」の値と置換される。

他の実装において、Ｓ内の演算子のグループ化は、先行値を有することができる。この値は、入力に関する優先度を設定することができる。例えば、「（ＵｘおよびＵｙ、１０１）」は、ステートメントが優先度１０１を有することを表すことができる。１つの実装において、真であると評価するより高い優先度ステートメントは、真であると評価するより低い優先度ステートメントより優位に立つ。いくつかのＵｍエンティティがアタッカによって危険にさらされていることをもしアタッカが獲得するならば、優先度は有用となり、アタッカは、Ｓを介して真の値になりすますことができる。この場合、アタッカがコントロールを持つ、有効であるがなりすまされたエンティティよりも、より安全な組のＵｍを優先させることがＣＡにとって有益である。これによって、Ｓの代数は、ポリシー内でさえ、コントロールの階層を含むことが可能となる。この場合、ＣＡは、最後に認可されたアクションの優先度の値を記憶する。より高い優先度のアクションが後に発生した場合、ＣＡは、新たな相互作用を許可し、前の相互作用を破棄することができる。

いくつかの実装において、より高い優先度の信任状のリセットは、特定の期間、より低い優先度のリセットを無効にすることが出来る。例えば、２週間である。これは、アタッカがその期間、再度ポリシーをリセットすることを許可せず、異なる認可グループの間でポリシーがばたつくことを防止する。

他の実装において、データオブジェクトＬはＧを含む必要がない。なぜなら、この情報もまたＳ内に存在するからである。

典型的な実装において、認証は、一般に非公開キーを用いて直接行われる。しかしながら、リレーショナル認可を用いると、信任状は、代わりにＳを介してピアのグループに対して認証されることができる。すなわち、Ｓは、信任状内の公開キーを取り換えることが可能である。例えば、信任状が組織を表し、その組織が秘密のデータアクセスを必要とし、３人がそのアクセスを認可するために必要とされた場合、特定のＰＰＫを必要とする組織の代わりに、その認証プロセスを満たすためにリレーショナル認可を使用することができる。一例として、ある人の信任状は、銀行口座にアクセスするために、スマートフォンおよびキーホルダーサイズのデバイスの両方を用いることを求められるかもしれない。電話とキーの両方が公開キーを含み、協力して、その個人が自分の信任状においてＳを介して銀行口座にアクセスすることを可能とする。この場合、信任状は、公開キーの代わりに、認証に対するポリシーを含む。公開キーは、ポリシーＳ内の当事者によって保持される。明白にするために、Ｐｍは、当事者Ｘを含むポリシーステートメントＳと置換され、Ｘが所有するＰｘは、非公開キーであってもよいし、他のポリシーステートメントＳｘであってもよい。このような場合、ネスト化されたＳｘステートメントがループを形成しないことは極めて重大である。例えば、Ｕ１が「Ｕ２」からなるＳ１を有し、Ｕ２が「Ｕ１」からなるＳ２を有する場合、いずれのステートメントも決して真であると評価出来ないことになる。その理由は、いずれのステートメントも、ステートメントＳｍの部分を真であると設定できるＰＰＫからの入力を有しないからである。いくつかの実装において、このルーピングは、深さ基準を用いて制限することが可能であり、その結果、プロセスが終了する前にはある一定の整数回の再帰のみが許可され、偽の戻り値が戻される。いくつかの実装において、ポリシーＳは、少なくとも１つのパスが真の値を戻す場合にのみ、正当であるとされてもよい。

トークン化プログラムについて述べる他の文献に含まれることであるが、ステートメントＳ′を介してコントロールされたＵ１を含むステートメントＳが、Ｕ１がＳ内のどこに現れるとしても、Ｕ１をＳ′と置換することによって拡大できることには、注目する価値がある。例えば、Ｓが「Ｕ１およびＵ２」であり、Ｓ′がＵ１に対して存在し、「Ｕ４およびＵ５」から構成された場合、Ｓは「Ｕ１」をＳ′と置換し、「Ｕ４、Ｕ５およびＵ２」を生成することが可能である。

１個のＬには、各々がシステム内の特定のアクションまたは権限に対応する多数のポリシーが存在し得る。例えば、アクセス、認証、更新等である。いくつかの実装においては、オーナシップポリシーがＣＡを用いて作成および管理され得るのと同じ方法で、任意の数のこのようなポリシーが、ユーザによって作成、分配、管理され得る。ＪＳＯＮフォーマットにおける信任状の例として図１５を参照されたい。ある一定の実装においては、これらのポリシーステートメントは、ＣＡによって発行された信任状内に存在する可能性がある。他の実装においては、これらのポリシーステートメントは、それら自身が署名し且つ認証済みであり、ＣＡによっても署名されたメッセージ内に存在することとしてもよい。

典型的実装において、ポリシーは、図１５に示すように、ＡＬＧＯＹを介して置換可能な信任状内に存在する。すなわち、これらの（グループとしての）ポリシーは、１つの信用状更新プロセスを介して置換される。いくつかの実装は、これらの別個のポリシーの更新を個々に分離することを望む可能性もある。このような場合、ＡＬＧＯＹが存在し、このような各々のポリシー宣言に対して実行される。この機構は、一般に思い浮かぶものよりも、「アイデンティティ」のさらに分散された概念を提供し、管理コストの増加、複雑さの増大等を含む実質上の二次的効果を有する可能性がある。

１つの実装において、ＣＡは、公開キーを提示する要求エンティティに対して、一時的な信任状を提供する。これらの信任状は、決して繰り返されない単に増大する数値を含む。発行されたこのような証明書は、この番号および関連付けられた公開キーにのみ基づく、その識別メトリックにおいて互いに異なる。さらに、これらの信任状は、他の目的のためには使用出来ないように、システム内で明確にマークされる。いかなるユーザも、いつでもこのような証明書をリクエストすることができる。例えば、何人かのユーザは、連続の１０００を含む証明書をリクエストすることができる。このような証明書をリクエストする次のユーザは、証明書１００１を受け取る、等である。同じエンティティが、任意の数の証明書をリクエストすることが可能である。この一変形例は、このような証明書がエンティティ情報を含むことを可能にすることである。この情報は、Ｕｘが要求元である場合、Ｕｘのアイデンティティとマッチする。この証明書は、いかなる形でも、Ｕｘを識別するために使用されてはならない。その目的は、安全でアドレス可能な方法で、任意の連番と公開キーとの関係を確立することのみである。

Ｕｘが新たなＰＰＫキーＰｘ′を作成し、上記機構を用いてＰｘ′（公開部分）を含む一意証明書をリクエストすると仮定する。この一時的証明書をＴｘと呼ぶ。Ｕｘは今や、ＰＫ内で認識される証明書を有し、それによって他のユーザがその連番を用いてＴｘの一意性を検証できる機構を提示する。さらに、Ｔｘは今や、ＵｘとしてではなくＰＫ内の一意エンティティとしてＰＫの他のメンバと共に認証するために、一時的容量でＵｘによって使用され得る。一意性は、一意の連続番号によって定義される。

ＵｘおよびＵｍが人々である１つの実装において、Ｕｘは実世界におけるＵｍと接触し、Ｕｘに対する再入力リクエストをＣＡに提示するようリクエストする。好ましい実装において、Ｕｘは連番を言葉でＵｍに伝達する。他の伝達方法は、電話、言葉による対面、または音声付ビデオを含み得る。重要な基準は、Ｕｘが新たなキーの必要性およびＴｘ内の連番を伝達し、ＵｘがＵｍに対しアイデンティティの確実な証拠を提供することである。このコンテキストにおけるアイデンティティの証拠は、Ｕｍが、ＵｘをＣｘの正当な所有者として認識し、Ｕｘが人であり、Ｕｘが、Ｕｍが正当所有者であると考える人であることを意味する。最良の解決策はＵｘおよびＵｍの物理的ミーティングであり、２番目に最良な解決策はビデオであり、３番目に最良な解決策は電話である、等である。所有権及びアイデンティティの証拠は、強ければ強いほどよい。代わりの、またはサポートする機構は、ＤＮＡサンプル、指紋、またはある型式のバイオメトリクスを含み得る。これらの具体的な使用および手続きは、本文書の範囲にはない。しかしながら、意図は、ＵｍがＵｘを認識し、彼らがＵｘの実社会におけるアイデンティティになりすますことによりＣｘまたはＣｘ′のコントロールを獲得しようとするアタッカではないことを決定できる、ということである。人々以外のエンティティが、本文書の範囲を超えて、本人確認識別基準の異なるセットを使用するであろうが、これらは、共有の秘密、コンピューティングデバイスへの物理的アクセス等から構成され得る。

１つの実装において、Ｕｍは、公開キーを除外したＣｘ内の情報と、Ｔｘ内に見られる一意な連番とを含むＵｘのための署名済み更新メッセージＲＣｘを作成する。Ｕｍは、このメッセージをＣＡに送る。

過度に単純化した実装において、ＵｘがＴｘ内に見られる公開キーをコントロールすることを任意のＵｍが裏付ける場合、ＣＡはＣｘ′を作成する。ＣＡは、ＲＣｘを受け取ったことに応じて、Ｃｘ′内の情報がＣｘ内の情報にマッチングすることを検証し、Ｃｘ′を作成するべきである。より形式的に展開されたこれらのステップは、図１６のＡＬＧＯＸを参照すると以下のとおりである。
１．ＵｘがＰＰＫＰｘ′（またはポリシーＡｘ）を作成する。
２．ＵｘがＣＡから証明書Ｔｘをリクエストする。この場合、ＴｘはＰｘ′（またはＡｘ′）の公開部分を含む。
３．Ｕｘが、Ｕｘ′のアイデンティティの実社会における検証を実施するＵｍに接触する。
４．Ｕｍが、Ｃｘ内のユーザアイデンティティ情報とＴｘの連番とを含む署名済みメッセージＲＣｘを作成する。
５．ＣＡが、ＲＣｘ内の連番をＴｘ内の連番にマッチングすることによりＴｘ内の公開キーを抽出する。
６．ＣＡが、Ｕｍの署名を検証し、ＲＣｘ内のアイデンティティ情報を検証し、その後、Ｔｘからの公開キーと、ＲＣｘ内のユーザ情報とを含むＣｘ′を作成する。

ステップ６においてＣｘ′を作成するための過度に単純化した機構は、多くの例で推薦されない。ＰＫ内のＵｍのコントロールを得たアタッカが、システム内の他のいかなるＣｘをも危険にさらすことは明らかである。より堅牢な機構が続く。ＴｘがＣｘ′の作成に必要ないことにも注目されたい。これは単に有用であるに過ぎない。各Ｕｍは、代わりに、Ｕｘの識別情報と、Ｐｘ′の公開部分とを含む更新証明書をＣＡに提出することが可能である。公開キーは、ＵｘとＵｍとの間の検証手続きの最中にＵｍに与えられる。Ｔｘは、ＣＡに到達するために、公開キー部分のためのより自動的でヒューマンフレンドリな方法を単に提供する。

ＵｘがＣｘをコントロールする時にＵｘによって署名され、ＬとＵｘの識別情報とを含むメッセージＲＡｘを定義する。Ｕｘが、ＰＫ内のＣｘを発行した直後、そして、ＵｘがＰｘのコントロールを失う前に、このメッセージを作成したことは極めて重大である。もしＲＡｘが作成される前にＵｘがＰｘのコントロールを失うと、この更新戦略の全体が失敗する。１つの実装において、Ｕｘは、Ｃｘを作成する最初の手続きの一部としてＲＡｘを作成した。すなわち、ＣｘおよびＲＡｘは、相前後して作成された。これは、ＲＡｘが存在しない期間を排除する。このことは、アタッカが、Ｃｘを更新して置換するＵｘの能力を永久に破壊することを防止する。

Ｕｘは、ＣＡにＲＡｘを提示する。ＣＡは、ＲＡｘがＰｘに署名されたこと、およびＣＡによって署名されたＣｘにＰｘが対応していることをチェックすることにより、メッセージを検証する。ＣＡは、その後、ＲＡｘを無期限で記憶する。このメッセージは、ＰＫのメンバがユーザＵｘのために代替の証明書Ｃｘ′の作成をリクエストすることを可能とするルールを定める。

Ｕｘは今や、各Ｕｍに接触し、先に概説したアプローチを用いて、ＣＡに再入力リクエストを提示することを要求する。このような各Ｕｍは、Ｕｘに対する情報を識別する署名済みメッセージＲＣｘおよびＰｘ′に対応する公開キーを提示する。Ｕｘは、より少数のユーザが真のブール出力値を生成することを要求されているとＳ内のルールが指示する場合、Ｍ人に満たないＵｍユーザに接触する必要があるかもしれない。

ＣＡは、Ｇ内の異なるＵｍユーザからいくつかのＲＣｘメッセージを受け取る。ＣＡは、ＣＡによって署名された有効な証明書Ｃｍを使用して、各署名済みメッセージがＰＫ内のＵｍから発生したものであることを検証する。ＣＡはまた、各ＲＣｘが同一の公開キーを含むことを検証する。もしそうでない場合、ＣＡは、受け取った全てのＲＣｘを計算するべきであり、この公開キーは大抵のＲＣｘにおいてマッチングする。マッチングしないＲＣｘは、破棄されるべきである。

多数の有効なＲＣｘメッセージが、Ｕｘのための有効なキー情報を含む１個のピアｘから存在することは可能である。例えば、ピアは２個のバウチャを発行することが可能であり、各々は、Ｕｘが２個の異なるキーを用いて更新バウチャリクエストをピアに２度送った場合、更新のターゲットとして異なる公開キーを含む。ＣＡは、これらのうちのどれを使用するべきかを決定する方法を持たない。この場合、ＣＡは、全てのピアから入力される全てのバウチャを、Ｕｘのための一意な公開キーによる組に照合する。全てのＲＣｘメッセージの組に２つ以上の公開キーが存在する場合、ＣＡは各々に対する組を作成する。ＣＡは、その後、このような各組を処理する。オーナシップポリシーにおける基準を通過する第１の組は、Ｕｘに対する新たな公開キーを決定する。認証に使用されるエンティティ公開キーが存在しないが、代わりに認証ポリシーが存在する場合もある。

ＣＡは、その後、Ｕｘに対するＬ内のＳをロードして実行し、出力値を計算する。出力値は、ステートメントＳにおける各Ｕｍに対する真の値を挿入することにより計算される。例えば、Ｓが「（ＵｙおよびＵｑ）」であり、ＣＡがＵｙから有効ＲＣｙを受け取ったが、Ｕｑからは何も受け取っていない場合、Ｓは偽の出力値を有する「（真および偽）」として計算される。計算の結果が偽である場合、ＣＡは何もしない。ＣＡが真の値を計算する場合、ＣＡは、Ｓに対して書かれた基準が正しく満たされていることを検証する。もしそうであるならば、ＣＡはＵｘに対するＣｘ′を作成し、更新は成功である。形式的に展開されたこれらのステップは、ＡＬＧＯＹと呼ばれ、以下の通りである。
１．ＵｘがＰＫ内の信任状Ｃｘを最初に獲得した時、Ｕｘがその後、データオブジェクトＬを含む署名済みメッセージＲＡｘをＣＡに提示する。書名は、Ｕｘの署名、またはＣｘがキーの代わりにポリシーＳを含む場合、ＲＡｘを認可するのに十分なＳ内の認可する所有者の署名でなければならない。
２．ＣＡは、ＲＡｘの署名および有効性を検証した。有効な場合、ＣＡはＲＡｘを無期限で記憶した。
３．その後、ＵｘはＣｘ（またはポリシーＡｘ）のコントロールを失う。
４．Ｕｘが、新たなＰＰＫＰｘ′（またはポリシーＡｘ′）を作成する。
５．Ｕｘが、ＣＡからの証明書Ｔｘをリクエストする。この場合、ＴｘはＰｘ′の公開部分を含む。
６．Ｕｘが、Ｕｘ′のアイデンティティの実社会における検証を実施する一意なＵｍに接触する。
７．Ｕｍが、Ｃｘ（Ａｘ）内のユーザアイデンティティ情報とＴｘの連番とを含む署名済みメッセージＲＣｘを生成する。
８．ＣＡが、ＲＣｘ内の連番をＴｘ内の連番にマッチングすることにより、Ｔｘにおける公開キーを抽出する。
９．ＣＡが、Ｕｍの署名を検証し、且つＲＣｘ内のアイデンティティ情報を検証する。
１０．ＣＡがその後、ＲＡｘ内のＳを実行し、Ｕｍが署名するか、または真であると評価されたポリシーＣｍ（Ａｍ）を有する限り、Ｕｍの各場合を「真」と置換する。ＲＡｘに署名した、または真であると評価されたポリシーＣｍ（Ａｍ）を有したＧ内のあらゆる一意Ｕｍに対して、このステップを繰り返す。ポリシー評価は恐らく再帰的であることに注目されたい。
１１．Ｓが真であると評価する場合、ＣＡがその後、Ｃｘと同じ情報を含むが、代わりにＴｘに見られる更新済み公開キーを有するＣｘ′を作成する。
１２．ＣＡがその後、Ｕｘのための前回のＣｘ（Ａｘ）を無効化し、新たなＣｘ′（Ａｘ′）を発行する。これは、ＣＲＬを用いて、また好ましくは、新規キーの破棄において概説した一意破棄プロセスを用いて生じる場合もある。その場合、各ＲＣｘメッセージＭＵＳＴがＣｘ（またはＡｘ内のポリシー情報）に見られる公開キーを含むことに注目されたい。そうでない場合は、ＣＡは、所与のＲＣｘメッセージがどのＣｘを置換することを意味しているのかを知ることはない。存在しない場合、これは、アタッカがリプレーアタックを実施することを可能にする。

Ｇが変化する場合、ＵｘがＲＡｘを更新可能であることが重要である。あるユーザがもはやユーザ内に存在しないこと、新たなメンバがＧに加えられるべきであること等が可能である。このように、ＲＡｘは置換可能であるべきである。しかしながら、Ｕｘは、ＲＡｘを安全には交換できない。Ｐｘがアタッカにより不正アクセスされたと想像してみてほしい。ＵｘがＲＡｘを更新可能である場合、アタッカも同様である。アタッカは、ＲＡｘをアタッカに有益なＲＡｘと置換可能である。その後、もはやＰｘのコントロールを有さないことにＵｘが気付いた場合、ＲＡｘはもはやＵｘのための信頼のグループを含まず、代わりにアタッカがＲＡｘ内に配置したものを何でも含むのであるから、彼らは頼りになるものを持たないことになる。従って、ＲＡｘの置換は、他の機構を使用するべきである。

代わりに、ＲＡｘはＣｘ′またはＡｘ′が作成されるのと同じ方法で置換可能であるべきである。Ｕｘは、その選択した新たなＬ′をＴｘに加える。各Ｕｍはその後、Ｔｘに対する連番を含む署名済みメッセージを作成して、これをＣＡに送る。ＣＡはその後、ＡＬＧＯＹステップ１０を用いて各メッセージを検証し、Ｓの同じ結果を計算する。真である場合、ＣＡはステップ１１において、ＲＡｘを、Ｌ′を含むＲＡｘ′と置換する。ＣＡはその後、ＲＡｘの使用を停止し、将来の更新全てに対してＲＡｘ’を使用する。この手続きは、ステップ１１において、ＣＡがＬ′を含むＲＡｘ′とＲＡｘを置換し、ＴｘがＬ′を含むということを除けば、ＡＬＧＯＹに見られるものと同一である。

１つの実装において、多数のＲＣｘメッセージをＣＡに送られた１個のメッセージに組み合わせることは可能である。ＲＣｘメッセージ内のキー情報は、ユーザ識別情報であり、連番であるので、この情報は、１個またはそれ以上のＵｍメンバによって署名された１個の文書に加えられ得る。多数の署名を有する文書は、その後、多数の個々のＲＣｘメッセージの代わりに、ＣＡに提示され得る。図１７を参照されたい。

いくつかの実装において、ＲＡｘ′置換（修正されたＡＬＧＯＹのステップ１２）を、ある所定期間、エスクロウに配置することが可能である。これは、アタッカがＳ内の認可ノードのコントロールを獲得し、信任状オーナに反応するための時間が与えられる前に信任状をリセットすることを防止する、この場合、ＣＡは、ステップ１２を即座に実施したり、ＲＡｘ′を公開したりしない。その代りに、ＣＡは、所定の期間、ＲＡｘ′を記憶する。いくつかの実装において、この期間は、期間をデータオブジェクトＬに加えることによって信任状オーナによって設定される。いくつかの実装において、期間は、システム全体にわたって固定される。この時間中に、ＣＡは、ＳおよびＵｘ内の各認可エンティティに接触する場合があり、信任状リセットが保留されていることを、そのエンティティに通知する。代わりに、ＣＡは、信任状がリセット保留中であることを述べる公開署名済みメッセージをポスティングすることが可能であり、Ｕｘおよび他の認可エンティティがその公開場所を定期的にチェックすることを可能にする。この手続きは、アタッカに、リセットが保留中である様々な認可エンティティを同時に通知しながら、延長期間に多数の信任状を捕らえて保持することを強いる。それらのエンティティが各々、その個々のＣｘ信任状に対して更新機構としてリレーショナル認可を使用し、各々が他の認可エンティティと共に別個のＲＡｘ更新信任状を有する場合、アタッカが、必要な期間、エンティティＣｘ′の更新なしに、多数の信任状を乗っ取って保持する可能性は極めて低い。

人は今や、そのような設定が現存のＰＫＩ更新手続きよりもどれだけ安全であるかを計算するために、セキュリティ比較を実施することができる。現在の技術水準での実装においては、単一障害点が常に存在する。セキュリティオフィサまたは更新プロセスを担当するグループのいずれかは、ＣＡによって評価されている署名リクエストを作成する。これは、その後、適用される。しかしながら、セキュリティオフィサまたはグループの署名キーがアタッカによって不正アクセスされる場合、アタッカは、キーが破棄可能となるまで、新たなユーザ証明書の将来の作成へのアクセスを得る。

１人の人間が、手続き上のグループまたはオフィサと同一のセキュリティコンテキストまたはセキュリティトレーニングを有する可能性はきわめて低いが、一方で我々は、順列計算を介して、協力して行動するあまり安全でない多数のキーを用いてグループやオフィサのセキュリティを越えることは難しくないということも知ることができる。例えば、セキュリティオフィサの署名に加えて２個の一意Ｕｍエンティティからのさらに２個のＲＣｘ署名を含むことによって、劇的な効果が生まれる。各Ｕｍの信任状がＣｍの寿命の間に、飛躍的に高められた５０％のセキュリティ侵害の機会を有したとすれば、セキュリティ全体は、セキュリティオフィサのキーのみの４００％まで増大する。実際、このリストに（Ｓ内のブール演算を用いて）「ａｎｄｅｄ」を追加した各々のさらなるユーザは、セキュリティをさらに２倍にまで増大させる。これは、各々のさらなるユーザに対して不正アクセスの確率が半分だけ低減する指数関数である。明らかに、このアプローチは、最新式の再入力プロシージャよりも安全である。さらに、リレーショナル認可原理は、認証、データアクセス、委任等に対する同レベルの増大したセキュリティを生み出すことを望まれる任意の組のコントロール特性に対して適用され得る。
ＥＮＴ内のリレーショナル認可：

ベリニムのキーが無効化されるか、または不正アクセスされると、リレーショナル認可が、ベリニムのコントロールを再構築するために使用さ得る。ベリニム（Ｕｘ）のオーナが、オーナが信頼するピアＥＮＴユーザのリストを作成する。これらのユーザは、その後、そのオーナのベリニムに対して更新ピアグループとなる。オーナがベリニムのコントロールを失うと、オーナは、そのピアグループ（Ｇ）に十分に接触し、ベリニムのコントロールを再構築する。どのピアがそして何個のピアがコントロールを再構築できるかを計算するための正確な方法はベリニムのオーナに任され、（ステートメントＳを介して）定義される。これは、当然のことながら、ユーザが早期にオーナシップポリシーを作成したことを意味する（ＲＡｘ）。

１つの実装において、オーナは、スクラッチから新たなＥＮＴベリニムをまず作成することにより、ベリニムのコントロールを再構築できる（Ｔｘを作成することと同等である）。この新たなベリニムが一旦作成されると、それは、安全な転送および認証のために、他のＥＮＴピアと共に使用され得る。その後、このベリニムは、更新ピアに接触するために使用され得る。各ピアは、その後、ユーザが、更新されるベリニムの正しいオーナであることを（音声またはビデオチャットを介して）検証し、さらにその後、署名した裏書（ＲＣｘ）を作成することにより、その更新に対して保証することができる。この裏書はルートに転送可能であり、そのルートはその後、問題のベリニムに対する１組の証明書を再発行する。各ルートは独立してＡＬＧＯＹを実施し、さらにグループ権限セクションに見られる組み合わせ論を介して、そのＣｘ′証明書がＵｘに対する新たなベリニム信用状となることに注目されたい。

ベリニムが発行された後、ベリニムの所有者は、署名済みオーナシップポリシーメッセージ（上記のＲＡｘ）をルートに提示するかもしれない。オーナシップポリシーメッセージは、ベリニムが新たなＰＰＫを含むように合法的に更新されることを許容するポリシーステートメント（上記ステートメントＳと同じ）と、ピア更新メンバのリスト（上記オブジェクトＬ内のリスト）とを含むベリニムオーナによって作成された署名済みメッセージである。

更新バウチャメッセージ（上記ＰＣｘメッセージ）は、所与のベリニムに対する更新ピアグループの任意のメンバによって署名されたメッセージであり、裏書としてルートサーバに提示される。

ポリシーメッセージは、ターゲットベリニウムｉｄを含む更新バウチャメッセージをルートが受け取る度に実施されるブール式を含む。ブール式が真である場合、そのベリニムに対する新たな証明書をルートは発行する。この場合において、公開キーは、全ての有効な更新バウチャメッセージにおいてマッチングするキーである。

リレーショナル認可により、オーナシップポリシー内のブール式は、変数、論理演算子、および真偽を評価する論理関数を含む。組み合わせは、ブールステートメントを形成する。各変数は、ベリニムｉｄである。受け取られた各々の署名済みの真正更新バウチャメッセージに対して、適切なベリニムｉｄは真の値と置換される。更新バウチャが存在しない状態でブール式が真であると評価される場合、ポリシーは無効であるとみなされ、維持されない。ブール式が、オーナシップポリシーが適用されるベリニムｉｄを含む場合、ポリシーは無効であるとみなされ、維持されない。

オーナシップポリシーメッセージは、ブールステートメントと、ピアベリニムのリストとを含む。このピアベリニムｉｄのリストは、ブール式における変数として見出されるベリニムｉｄから構成されなければならない。ルートに送られた第１の有効なポリシーは、このような維持されたオーナシップポリシーのみである。その後のポリシーメッセージは（以下で述べるように、新たなポリシーを確立するために十分なバウチャが伴っていない限り）廃棄される。従って、オーナシップポリシーは、ベリニム証明書が発行された後、可能な限り好都合な方法でサーバに送られることが重要である。アタッカがユーザの非公開キーを簡単にハイジャック可能であり、オーナシップポリシーメッセージがまだ送られていない場合、ハイジャックは永久的であり、逆行できないものとなる。ベリニムの所有者がピア可能化オーナシップポリシーを欲しない場合、そのベリニム所有者は、ブールステートメントが常に偽であると評価するオーナシップポリシーをトランクに提示するべきである。

現存のポリシーを変えるためには、以下の基準を満たさなければならない。
１．現存のオーナシップポリシーのピアリストに見られるピアベリニムが、有効なオーナシップポリシーメッセージを提示できる。ブール式およびベリニムｉｄリストは、このような全てのメッセージに亘りマッチングする。
２．ブールステートメント内のベリニムｉｄ変数を真で置換する際に、現在のオーナシップポリシーブールステートメントが満たされなければならない。すなわち、真正のオーナシップポリシーメッセージがマッチしているベリニムｉｄから受け取られ、その後ブールステートメントが真であると評価されるならば、現存のオーナシップポリシーブールステートメント内の各ベリニムｉｄは、真の値と置換される。

これらの基準を満たすことは、ターゲットベリニムに対して更新するように認可されたピアグループもまた、ポリシーの変更を認可する、ということを確立する。それはまた、新たなブールステートメントが全ての関連するピアによって厳密に同意されることも確立する。この時点で、現存のポリシーは、新たなポリシーと置換される。

いくつかの実装において、情報漏洩を防止するために改良がなされ得る。情報漏洩は、オーナシップポリシーを調査する人にはベリニム更新ピアが可視であるという点で起こり得る。ベリニム間の続く関係を追跡することによって、ベリニム間の関係を推察するために使用する連結グラフを生成し、人々または機械に対する実社会マッピングを簡素化することが可能となる。このような情報を有するアタッカは、ベリニムの永久的コントロールを獲得することが可能になる１組のノード上で協調的な攻撃を理論的に計画することが可能である。これを防止する改良を実施することが可能であるが、システムが複雑になる。

情報漏洩を制限するための１つの実装において、各オーナシップポリシー（上記Ｌの内容）は、Ｌ′を作成するために、各ルートのＰＰＫの公開キー部分を用いて暗号化され得る。一旦暗号化されると、ルートサーバのみがＬの暗号化された内容を解読可能となる。他のいかなる外部関係者もＬの内容を解読できない。ルートが更新バウチャを受け取ると、ルートは、Ｌ′の内容を解読してＬを生成することが可能となり、その後、上記のようにＳに対する値を計算することができる。

１つの実装において、外部監査施設Ａが更新プロセスを検証し監査できることは有益である。これは、ＡがＬ′を計算できることを意味している。ベリニムのオーナＯはＬを有する。その理由は、元々Ｏが、暗号化してルートに送る前にＬを計算したからである。１つの実装において、Ｏは比較的非公開であるどこかの場所で単にＬを維持している。好ましい実装においては、Ｏは、ルートからＬをリクエストすることが可能である。この場合、Ｏによってコンタクトされたルートは、Ｌ′をＬに解読し、Ｏの非公開キーでＬを暗号化してＬ″を生成し、このメッセージをＯに送信する。Ｏは今や、その非公開キーを用いて、Ｌ″を解読してＬを読み出すことができる。一旦何らかの機構を介してＬを読み出すと、ＯはＬをＡに提示できる。Ａは今や、ルートの公開キーを用いてＬを暗号化することにより、Ｌ′を計算し、検証することができる。これによって、Ａが獲得したものと同じＬをルートが用いていることが確実となる。

上記実装において、Ａもまた、十分な監査を実施するために、ルートに提示された全ての更新バウチャへのアクセスを必要とする。Ａは，これらの値をＯから読み出すことができる。好ましい実装において、Ａは、更新バウチャをルートから直接読み出すことができる。本実装において、ルートは、以前のように、Ｏに対するポリシーまたはベリニムを更新する。更新が一旦うまくいくと、ルートは、その後、全ての更新バウチャを１個のオブジェクトに並べ、そのオブジェクトをＬで暗号化し、ＲＶを生成する。ルートは、その後、ＲＶを公開する。監査人Ａは今やＲＶを読み出すことができ、Ｌを用いて、ポリシー置換またはベリニムキー置換において使用される全ての更新バウチャを読み出すことができる。Ａは今や監査を十分に行って、ベリニムキーを更新するか、または現存のオーナシップポリシーを置換することについての許可をルートが有したことを確実にすることができる。リクエストに際し、Ｏに対して監査の失敗が増大する可能性もある。その後、正しい監査情報が存在しない場合、ルートが危険にさらされることが確定する可能性もある。

１つの実装において、Ｌは、Ｌを極めて一意とする乱数または乱数値を含むことができる。例えば、１２８ビットの乱数値をＬに加算する。これは、アタッカがＬ内のベリニムｉｄに対する潜在価値およびＳのフォーマットを推測し、試行錯誤によってＬを再構築することを妨げる。

好ましい実施形態では、ベリニムに対する信任状の新たな置換組が作成されると、現存の信任状が無効化される。これは、現存のＰＫＩシステムにおいて使用可能であり、以下で述べるキー失効に対する新規なアプローチを介して成就される。要するに、最新の作成タイムスタンプを有する所与のルートによって署名された有効証明書は、有効証明書であるとみなされる。より以前の日付のタイムスタンプを有する同一のベリニムｉｄを含む他の全ての証明書は、無効であるとみなされる。
新規なキー失効

新規な改良点を説明するために、適切なコンテキストを提供することが必要である。証明書権限Ａと、データ記憶（ディレクトリと呼ばれる場合が多い）Ｄと、ユーザＵとを有していると想像されたい。Ｕは、Ａから新たな証明書をリクエストすることを認可されている。Ｕは、非公開／公開キー対（ｐｘ、ｐｙ）とともに非対称キーＫを作成する。Ｕは、Ａが署名し認可したｐｙを含む証明書Ｃを作成することを望む。

１つの実装において、Ｕは、Ｃをリクエストする前に、以下のステップを実施する。

他のより典型的な実装において、Ｕは、Ｃをリクエストした後に、以下のアクションを実施する。

図１８を参照して、手続きＡＬＧＯ１について述べる。
１．Ｕは、非対称キー１ないしＮの組ＫＥＹＳを作成する。この場合、ｎは証明書更新がＡから必要とされる前に仮定された、Ｃの寿命にマッチングする任意の数である。値ｎは、任意の時間増分に基づいて決定することも可能である。例えば、証明書更新間の期間が１年であり、増分が１日である場合、ｎ＝３６６である。これは、区間ごとに、すなわち日ごとに、１つの証明書を提供する。代わりに、Ｎはスペース、送信、または他の必要条件に基づいて決定することが可能であり、間隔は番号Ｎから得られる。値Ｎは１よりも大きくなる必要はなく、この場合、ＫＥＹＳは１個のキー対のみを含む。Ｕは、その後、証明書１ないしＮを含む組Ｓを作成し、キー対ＫＥＹＳ［ｘ］を用いて証明書Ｓ［ｘ］を作成し、各証明書は、証明書チェーンＣ−＞Ｃ′が有効な証明書チェーンになるように、Ｃによって署名される。Ｓ内の各証明書もまた、証明書「連続」フィールドに一意の値を含む。一般に、この値は１ないしＮとなり、この場合、Ｓ内の証明書１はシリアル値を有し、証明書２はシリアル値２を有する、等である。
２．Ｕは、ｐｘとともにＳ内の各証明書に署名する。
３．１つの実装において、Ｕは、例えば「Ｎ ＴＥＲＭＩＮＡＴＥ」のシリアル終端値を含む最終的な証明書Ｆを作成する。代わりの実装は、異なる証明書値、または、証明書増分の終了を表すいくつかのトークンを含むシリアル値に対する異なるテキスト値を使用する。すなわち、それは、全ての証明書を見る人が、Ｎよりも大きい値を有するＳ内の証明書が存在しないことを決定できるように、Ｓの組を終了させる。他の実装において、Ｆは作成されない。
４．Ｃを作成する任意のリクエスト（以前の場合）および全ての上記ステップが達成された後、Ｕは、ｐｘおよびｐｙを含むキーＫを破壊する。

Ｋは今や、回復不可能である。アタッカは、これらのステップが行われた機械にアクセスしない限り、Ｋにアクセスできないか、またはＳ内のキーに類似の、または対称の追加のキーを作成できない。Ｕは今や、数値的に増分されたＳ内のＮ個の証明書のリスト、ならびにＳの組のサイズを明白に示し、さらに終了を明白に示す情報を含む証明書Ｆを有する。さらに、Ｕは、これらの証明書をいかなる他の者ともまだ共有していない。それらは、局所的に作成され、Ａは必要ではなかった。

Ｎ個のオブジェクトから構成されるＣＥＲＴの組を定義する。ここでは、各オブジェクトは、１とＮの間の各ｘのための対（Ｓ［ｘ］、ＫＥＹＳ［ｘ］）を含む。

１つの実装において、Ｕは今や、ＣＥＲＴ内の各オブジェクトおよび非公開キーＰを有する証明書Ｆを暗号化し、１組のサイズＮの暗号化オブジェクトであるＰＳの組を生成する（各々は、証明書または証明書／ＫＥＹ［ｘ］対）を含む）。Ｐは、Ｕにのみに知られたパスワードである。

他の実装において、ＵはＣＥＲＴ内の各オブジェクトをＪ個の部分に分け、Ｊ個のキーを用いて暗号化する。これらのキーは、非対称または対称キーであってもよい。非対称キーの場合、１つの実装は、ピアユーザの証明書を用いて各部を暗号化することである。このピアグループをＴと呼ぶ、このような場合、ＰＳは、１組の集合から構成され、各々は、これらの暗号化されたオブジェクトを含み、各部分集合はＪ個の部分から構成される。

１つの実装において、Ｕは、保存のためにディレクトリにＰＳを転送する。

１つの実装において、Ｕは、保存のために他のピアユーザにＰＳを転送する。

１つの実装において、Ｕは、ディスクドライブ上、またはペンドライブ等の他の記憶媒体にオフラインでＰＳを記憶する。

１つの実装において、Ｕは、ＰＳ内の各オブジェクトＰ′をＪ個の部分に分解し、このような各部分を異なる場所に配置する。場所は、ピア、ローカルの記憶装置、ＣＡ記憶装置等、上記の場所を含み得る。

証明書Ｃ″（Ｃプライム）を集合Ｓ内のいずれかの証明書として定義する。ＰＫＩシステムは、証明書Ｃ′をＣの有効性を有するものとして処理しなければならない。Ｃ′がＡの正しい証明書チェーンを維持することは、検証され得る。ＡはＣに署名し、ＣはＣ′に署名した。従って、Ｃ′はＰＫＩ証明書チェーンを用いてＡへの直接経路を有する。その後、各Ｃ′がＣによって署名されたことが明らかとなる。従って、Ｃの記録を有する場合、ＰＫＩシステムの他のメンバが明らかにＣ′をＡまで追跡することが可能であり、ＵがＣ′を保持する際に、信頼のおける通信、認証、認可等がＵに対するシステム内で発生することを可能にする。

ＰＫＩシステムの各ユーザ（ディレクトリ、個人、ＣＡ，第３者等）は、より大きいシリアル値を含む証明書Ｃ′を有効証明書として、より小さいシリアル値を有するＣによって署名された任意の現存の証明書を破棄され無効化されたものとして処理しなければならない。

上記を含む場合の１つの実装において、終端値を含む最終的証明書Ｆを受け取る各ユーザは、Ｃ′を用いるいずれのトランザクションももはや許容してはならない。

以下の例は、図１９を参照してこの概念を実証する。
１．シリアル値２を有するＣ′が、ディレクトリＤに提示される。
２．Ｄは、シリアル値１を有するＣ′を含む。
３．Ｄが、シリアル値１を有するＣ′を廃棄し、シリアル値２を有するＣ′を記憶する。
４．ユーザＨが、Ｕに対する証明書をリクエストし、シリアル値２を有するＣ′を受け取る。
５．Ｆが、ディレクトリＤに提示される。
６．ユーザＨが、Ｕに対する証明書をリクエストし、Ｆを受け取る。ユーザＨは、トランザクションおよびいずれかの将来のトランザクションを許可しない。

従って、全体としてのＰＫＩシステム内における進行中の最新のＣ′は有効Ｃ′とみなされ、より小さいシリアル値を有する全ての他のものは、無視され、廃棄されたものとみなされる。システムのいずれかのユーザがＣ′内のシリアルに対してより大きい値を受け取る場合、そのＣ′が使用され、より小さいシリアルＣ′に開かれた接続部は閉じられ、より小さいシリアルＣ′証明書に対する全てのサービスが無効とされる。

１つの実装において、リクエストまたは署名された指示または他のビジネスが、非公開キー部分、すなわちユーザを有するＣ′を保持するエンティティによって実施され、または開始されると、そのユーザは、多数のディレクトリに対し、より大きいＣ′が存在するか否かをチェックするよう問い合わせる。もしそうである場合には、そのリクエストまたはビジネスはキャンセルされるか、エンティティが接続解除されるか、等である。すなわち、より小さい値Ｃ′の所有者は、有効なオーナであるとはみなされない。このような実装においては、ＰＫＩを含むディレクトリの世界全体に１つ存在すると仮定すれば、クエリに加えられた各々の追加のディレクトリは、より大きい値Ｃ′が見出される機会を増大させることが示され得る。

Ｕは今や、同一の暗号強度を有して機能するＣのための代替品として使用できる証明書のリストを有する。Ｕは、ＰＫＩシステムの残りがそのＣ′を見るのみであり、より大きい値のＣ′は見ない限りは、その集合内のＣ′を使用することが可能である。

Ｃ１、Ｃ２、、、ＣＮをＣＥＲＴ内の証明書の値として定める。Ｋ１、Ｋ２、、、ＫＮをＣＥＲＴ内のキーの公開／非公開対として定め、Ｋ１はＣ１を用いて暗号化されたデータを解読し、Ｋ２は、Ｃ２個の符号化データを解読する、等である。

ＡがＣに署名し、ＵがＡＬＧＯ１を実施した後、Ｕは、Ｃ１およびＫ１を用いて開始可能となる。Ｃ１またはＫ１が失われる、盗まれる、またはある期間に基づく場合、Ｕは以下のアクションを実施できる。明確にするために、１つの実装において、Ｕは、毎日、またはいずれかの期間に基づいて、証明書を循環させることができる。Ｕは，Ｃ２およびＫ２を含む暗号化されたまたは分割されたオブジェクトを得る。このオブジェクトは、１つの実装においては暗号化され、Ｕは、それを非公開パスワードで解読する。他の実装において、Ｕは全てのピースＰ′を集め、様々な場所からＣ２およびＫ２を再構築し、その後、内容を（もし解読される場合には）解読する。他の実装においては、ＵはピアＴに接触し、各メンバを解読し、ＵがＣ２およびＫ２を再構築可能になるまでその部分をＵに提示する。

Ｕは今や、有効なＣ２およびＫ２を有する。Ｕは、１つまたはそれ以上のディレクトリにＣ２を分配する。このような各ディレクトリは、Ｃ１をＣ２と置換する。このような各ディレクトリに接触する将来のユーザ全ては、Ｃ１の代わりにＣ２を得て、それが有効であり且つＣ１が無効であることを確認できる。１つの実装において、Ｕはまた、Ｕが相互作用するか、または相互作用してきたユーザのリストにＣ２を分配する。これらのユーザは、Ｃ２をキャッシュし、即座にアタッカがＣ１を使用出来ないようにすることができる。１つの実装において、ユーザがＣ２をキャッシュするならば、ユーザは、１つまたはそれ以上のディレクトリに接触して最新の証明書をリクエストする必要はなくなる。

Ｃ１を有するアタッカは、Ｃ２が一旦システム内に導入されると、Ｕのためのデータおよびサービスへのアクセスが不可能になる。Ｃ１は、たとえ明白な失効プロセスが実施されなくても、実際には無効化される。代わりに、Ｃ２の発布が、Ｃ１の使用を無効化し且つ不要にする。この型式の積極的なコントロールは、Ｕに、それ自体の証明書有効性ステータスを管理し、知ることによって最も利益を得るシステムのユーザに対して新たな証明の知識を公表する権限を与えるものであるため、非常に強力である。

Ｕが、証明書、証明書失効リスト（ＣＲＬ）または他のデータをＡからリクエストすることが必要である時がなかったことに注目されたい。全ての失効は、トランザクションが発生する時にのみ、Ｕおよびシステムの様々な他の部分によって処理されている。さらに、ＵおよびＣ２を再構築するために頼りにしたいずれかのピアグループを除いて、誰も手動の方法に参加しなかった。Ｘが１からｎである将来の各ＣＸに対して、Ｕは同じ演算を実施することが可能である。１つの実装において、Ｕが彼らの証明書はもはや使用するべきではないと判断する時、もしくはその場合、または、Ｃが有効なタイムスタンプをもはや含まないために、Ｕはディレクトリまたは他の手段を介してＰＫＩシステムに証明書Ｆをリリースすることが可能である。他の実装において、ＡＬＧＯ１からのステップ２を使用する代わりに、Ａは、各キーにｐｘで署名することに代えて各キーに署名する。Ａは、証明書に署名しなければならないが、最初のＣ１を越えてその証明書を分配したり公布したりしてはならない。この場合、証明書チェーンは、Ａ―＞Ｃ′のようになる。そうでない場合は、ステップは同じある。
トラベリングキー：

リレーショナル認可を使用してキー更新を実施するには、中央ルートとの通信、ピアの関与およびＯの部分に対する時間と努力が必要である。さらに、ユーザが更新プロセスを実施しなければならない時は、その度に、中央ルートが必要となり、これによって、ＥＮＴ中央システムに余分の負荷を生成され得る。ユーザが使い捨てのキーを有するのであれば、より良い。これによって、ユーザは、様々な目的のために一時的にその非公開キーをホスティングする装置を切り替えることが可能になり、その装置がなくなるか、または盗まれる等の場合を許容する。ユーザが、ルートサーバに接触することなく、より頻繁にキーを切り替えることも可能になる。理想的には、ユーザが、ルートサーバに可能な限り接触しないようにするべきである。ＥＮＴにおいて、これらの取り換え可能なキーは、トラベリングキーと呼ばれる。トラベリングキーは、非公開非対称キーと、連番を含む公開証明書とから構成される。上記セクションによれば、トラベリングキー証明書におけるより大きい連番は、より小さい連番を有する既存のトラベリングキー証明書を無効化する。

トラベリングキーは、キー無効化および除去のための上記機構を使用する。ベリニムの非公開キー部分は、トラベリングキーのグループに署名し、さらにそれを作成するために使用される。そのキーは、その後破壊され、同等レベルのセキュリティおよび必要に応じてキーをロールオーバする能力を提供する１組のトラベリングキーを残す。

１つの実装において、１組のトラベリングキーが製造される。数は実際には変化するが、３０以上で十分となるはずである。さらに、終了証明書もまた、上記ルールに従って作成される。終了証明書がＥＮＴ内のいずれかのピアノードにリリースされる場合、そのピアノードは、もはや現存のベリニム証明書を受け入れず、ベリニムは、ピア更新プロセスを用いて更新する必要がある。

１つの実装において、ユーザは、安全な１か所において、そのトラベリングキーのいくつか、または全てを記憶することとしてもよい。しかしながら、好ましい実装において、トラベリングキーはいくつかのグループのピア間で分配される。ピアは、ピア更新プロセス用に使用されるものと同じピアであってもよく、または異なる組であってもよい。

１つの実装では、キーは、ラウンドロビン方式でピアに対して、（必要になるまで）記憶するために分配される。例えば、キーが分配されるピアが３個存在する場合、ピア１は、連番１のキーを受け取り、ピア２は、キー２を受け取る、等である。これによってユーザは、任意のピアと接触し、より大きい連番のキーを獲得することが可能になる。ＥＮＴシステム内に見られる最も大きい連番が有効なキーとして考えられるので、任意のピアがより進化したキーを生成できるべきである。好ましい実装において、終了証明書は、全てのピアと共に記憶される。これによって、任意の既知のピアからユーザにアクセス可能となる。

１つの実装において、分配された各キーは、ベリニムオーナのみに知られているキーで暗号化される。これによって、意のままに、または信任状を含む装置またはメモリ記憶が不正アクセスされるか、または盗まれる場合に、いずれのピアもベリニム信任状にアクセスすることが妨げられる。この機構は、各トラベリングキー証明書および非公開キー対を暗号化するために、多数の非対称キー暗号化プロセスのうちのいくつかを使用する。非対称キーは、ベリニムオーナによって選択されたパスワードである。
リレーショナル認可およびトラベリングキーを実装することについての操作上の配慮

好ましい実装においては、ＥＮＴにより、ユーザは、その最近のトラベリングキーをいずれかの、または全てのルートに提示することが可能になる。ルートは、ユーザに対してＥＮＴシステム上で観察された最も有効なトラベリングキーを記憶する。実際には、ユーザが新たなトラベリングキーの使用を開始する際、そのキーのコピーをルートサーバに提示し、それによって、最新のキーのためのルートに対する任意のノードによる任意のクエリが、そのキーを返すことになる。

１つの実装において、ＥＮＴにより、ユーザはその最新のトラベリングキーを他のＥＮＴノードに送信することにより、それらのノードを直接更新することが可能になる。これは、キー公布と呼ばれる。これは、ユーザが、直接に接触可能な様々なＥＮＴ可能化サービスを有する場合に有用である。これらの場合、ユーザ（または、その代わりのソフトウェア）は、ユーザの記録済みサービスの全てに接触し、最新のトラベリングキーを直接送信することができる。ＥＮＴノードは、特に、そのノードに関連性がある場合、他のＥＮＴノードベリニムのキャッシュを維持するように促される。ＥＮＴノードがトラベリングキー証明書を受け取り、その証明書が、あまり有効ではないトラベリングキーのための現存の証明書よりも新しい場合、そのノードは、現存のキー証明書をより新しいバージョンと交換するべきである。この概念は、所与のユーザによって使用される任意のサービスがユーザの最新のＥＮＴ信任状を有することが確実となることから、非常に有用である。これによって、アタッカが、不正アクセスされたトラベリングキーまたは以前のベリニム信任状を使用するために持ち得る機会を減らすことになる。さらに、サービスセキュリティポリシーによっては、性能を改良する場合もある。

１つの実装において、ＥＮＴは、インターネット周辺に配置された多数のデータストアを有する。これらのストアの各々は、システム上のベリニムの部分集合に対するベリニム信任状およびトラベリングキーのリストを含む。ユーザは、これらのセンターのいずれかと共にキー公布を使用してもよい。いずれかのユーザサービスと同様に、より有効なベリニム信任状またはトラベリングキーを受け取るセンターは、その現存するコピーをより有効なものと交換する。実際、データストアは、ベリニム識別子の範囲をサービスするものと思われる。データストアが一旦ベリニムｉｄを１から１０００までカバーすると、他のものは、ベリニムｉｄを１００１から２０００までをカバーすることになる、等である。実際には、多数のデータストアが同じｉｄの範囲をカバーするものと思われる。多数のデータストアが同じベリニムｉｄの範囲をカバーする場合、それらのストアは、ベリニム信任状またはトラベリングキーのいずれかの成功裏の更新を、同じベリニムｉｄをカバーする他のストアに伝達するべきである。

サービスに対するキー公布は、第１のステップとしての上記ルート提示機構上では、第１のステップとして好ましい。データストアに対するキー公布は、好ましい第２のステップである。全てのステップは、実際に推薦されており、可能な限り迅速に達成されるはずである。好ましい実装においては、不正アクセスの場合の損失の値がより大きいサービスが、より小さい値のノード以前に接触されるべきである。全てのサービスが更新されると、データストアが更新されるべきである。ルート更新は、最終的に成就される。

他の実装において、異なる公布技術を使用することが可能である。例えば、ピアツーピアネットワークを使用して、より新しい信任状に対して多数のピアをサーチすることが可能である。このような多くの他のトポロジおよび技術が存在する。

所与のノードにより提供されたサービスの臨界性に基づいて、セキュリティレベルを設定することが可能である。

例えば、ＥＮＴを使用する銀行は、損失コストがより高くなるために、チャットサイトよりも、厳密な有効性チェックに対して高い要求を有する。厳密なテストを実施すると、時間（待機時間）、帯域幅およびいくつかの倍数による計算の観点から、トランザクションのコストが増大する。従って、ＥＮＴは、多様なセキュリティレベルを提供する。ベリニムの検証は、２つの主たる段階から構成される。第１の段階は、キャノピ検証と呼ばれ、それぞれ異なるルートによって署名された多数の現存の証明書の検証から構成される。もしＮ個のルートが存在するとすると、全キャノピ検証がセキュリティチェックとなり、その場合、Ｎ／２個よりも多いルート署名チェーンが確認される。しかしながら、これは、ある型式のトランザクションに対して有用であるよりもセキュリティが高い可能性がある。従って、１およびＮ／２＋１個の署名チェーン間のどこかの場所が、所与のトランザクションに対して検証されなければならない。より高いセキュリティトランザクションに対しては、完全セキュリティチェックを実施するべきである（グループ権限セクションで定義したように、１００％以上の信頼性レベル）。自明な、または非常に小さい値のトランザクションに対しては、１個のルートに対して１個の署名チェーンチェックが達成され得る。１個のルート署名チェーンのみのチェックにより、そのルートをコントロールするアタッカがユーザになりすますことが可能になる。これは、より多くのルートチェーンを検証することにより軽減される。なぜなら、アタッカが多数のルートに不正アクセスする可能性は小さいからである。完全キャノピ検証レベルでは、アタッカは、Ｎ／２個よりも多いノードのコントロールを獲得していなければならない。事実上、ＥＮＴシステム全体のコントロールを握らなければならないことになる。

第２の段階は、ベリニム信任状に対するシステム全体のサーチと、最も有効なトラベリングキー信任状（もし使用するならば）とから構成される。アタッカがサービスにアクセスし、古い信任状を手渡し、サービスがより新しい信任状の存在に対してチェックしない場合、サービスは、アタッカの信任状が有効であったと仮定するだろう。高価値トランザクションに対して、最も安全な機構は、有効ベリニム信任状と有効トラベリングキーとの両方に対して適切なデータストアの１つをチェックすることである。しかしながら、低価値トランザクションに対しては、このステップは、省略されるか、または「怠惰に」実施され得る。怠惰なチェックによって、トランザクションは継続可能となる。しかしながら、チェックは、トランザクションが継続可能である間は、適切なデータストアに対して非対称的に成就される。サーチがより新しい信任状を見つけ出し、トランザクションを開始するために使用した現存の信任状が無効であることを証明する場合、トランザクションは、可能であるならば、終了して逆行させるべきである。

１つの実装において、第２段階のチェックは、ユーザが決定した適時の期間内にサーチが既に行われている場合、スキップされ得る。例えば、以前のサーチが最後の３０分以内に行われていた場合、チェックをスキップすることが可能である。

好ましい１つの実装は、３つのセキュリティレベルを使用する。「過度に単純化した」レベルチェックは、１個のルートに対するキャノピ検証を単に実施するのみであり、第２段階は全く行わない。「基本」レベルは、完全セキュリティチェックを実施し、その後、より新しい信任状に対して「怠惰な」サーチを行う、というものである。「完璧」なレベルチェックは完全セキュリティチェックを実施し、トランザクション前の信任状サーチは継続するように許可される。

１つの実装において、トランザクションはキャッシュされることを許される。これによって、ベリニム信任状またはトラベリングキーが変化するまで、後のトランザクション上でキャノピ検証がスキップ可能となる。ベリニムを有する第１のトランザクションでは、サービスがキャノピ検証を必要とする。しかしながら、チェックは、ルートの過半数が所与のベリニムに対してバウチャされるのを確実にするように全体的に構成される。ベリニム信任状がその最初のトランザクション以来変化していない場合、後のトランザクションは、他のキャノピ検証を実施する必要なく、このキャッシュされた結果を使用できる。

両方のセキュリティチェックが一旦行われると、サービスはオーナシップの証拠をリクエストする。これは、サービスを用いてトランザクションを開始するユーザがトラベリングキーの適当な非公開キー部分を有し、またはトラベリングキーを使用しない場合には、ベリニム内に見られる公開部分にマッチングする非公開キー部分を有することを確実にする。これは通常、ＴＬＳ標準に見られるようなハンドシェーク機構を伴う。このトピックは他の情報原によってうまくカバーされ、信頼性を決定し、非公開通信チャネルを確立するためのＰＫＩシステム内に見られる従来の機構に従う。ＥＮＴにおいては、もし利用可能であれば、トラベリングキーを使用する場合もある。そうでない場合は、すべて同一の公開キーを有するのであるから、ベリニム信用状内のいかなる証明書が使用されてもよい。

１つの実装において、トランザクションが開始されると、ユーザは最新のベリニムおよびトラベリングキーの情報をサービスに送信する。これによって、サービスは、「過度に単純化した」または「基本的な」セキュリティチェックを実施中であるならば、他のサービスに接触する必要なく、トランザクションを処理することが可能になる場合もある。

図２０を参照すると、ブロック図は一実施形態によるシステム１００を示しており、このシステム１００は、上記のようにＥＮＴシステムを使用して、様々な他のシステムにアクセスすることが可能なユーザアクセスターミナル１０５を備える。ユーザアクセスターミナル１０５は、スマートフォン、携帯電話、ＶｏＩＰフォン、パーソナルデジタルアシスタント、タブレットコンピュータ、ラップトップコンピュータ、携帯用デジタル音楽プレーヤ、音声もしくはデータを伝達する他のモバイルデバイス、またはこれらの組み合わせのような多数のデバイスのうちの１つであってもよい。ユーザアクセスターミナル１０５は、例えばローカルエリアネットワークへの有線または無線接続を含むネットワーク接続コンピュータシステムを備えることも可能である。ユーザアクセスターミナルは、電子アプリケーションに対するユーザアクセスをコントロールするための機能を果たすために動作可能な好適なデバイスを備えてよく、図１５に示す特定のコンポーネントは、ここで述べる一般的概念を例示し、述べるためのものであることが容易に理解されるであろう。様々な実施形態においては、ユーザアクセスターミナル１０５は、上記例による動作が可能である。

図２０の実施形態におけるユーザアクセスターミナル１０５は、直接に、またはネットワークを介してアクセスシステム１１０に接続する。このようなネットワークは、多数の異なるプロトコルのいずれかでデータを送信することが可能な好適なネットワークを備えることも可能である。このようなネットワークは、周知のものであり、ここでさらに詳細に説明する必要はない。アクセスシステム１１０は、例えば、他のネットワーク接続コンポーネントを有するインターネット等のネットワーク１１５に相互接続される。セントラルサーバコンピュータシステム１２０はネットワーク１１５に接続され、様々な実施形態で、上記のようにＥＮＴシステムに関連する機能を果たす。セントラルサーバコンピュータシステム１２０は、例えば、１個以上のサーバコンピュータ、パーソナルコンピュータ、ワークステーション、ウェブサーバ、または他の好適なコンピューティングデバイスから構成することができ、所与のサーバのための個々のコンピューティングデバイスは、ローカルにあるか、または互いに遠く離れていてもよい。ユーザシステム１２５もまた、ネットワーク１１５に直接接続され得る。このようなユーザシステム１２５は、上記のようなシステムを採用できる他のユーザアクセス点であってもよい。

本発明は、例示の目的のためにのみ、特定の実施形態を用いてここで述べられた。しかしながら、本発明の原理が他の方法でも具体化可能であることは、当業者には直ちに明らかであろう。従って、本発明は、ここで開示した特定の実施形態に限定されるものではなく、以下に示す請求の範囲のスコープに十分見合うものとして見なされるべきである。

Claims (15)

1. 人間、エンティティまたは電子デバイスのための一意識別子を作成するための方法であって、前記方法は、１より大きい数（Ｎ）のルートサーバを含むグループ権限構造内で実現され、
   第１のルートサーバにおいて、要求元から一意識別子に対するリクエストを受け取るステップと、
   前記第１のルートサーバにおいて、一意識別子とポリシーと含む第１の証明書を発行するステップであって、前記ポリシーは、１個またはそれ以上の他の一意識別子を含み、該ポリシー内の他の識別子の数が１より大きい場合には少なくとも１個のブール演算子または数学関数をさらに含むステップと、
   前記第１のルートサーバにおいて、該第１のルートサーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて、前記発行した第１の証明書に署名するステップと、
   前記第１のルートサーバから他の前記ルートサーバのそれぞれに対して、前記署名した発行済み第１の証明書を送信するステップと、
   他の前記ルートサーバのそれぞれにおいて、前記署名した発行済み第１の証明書の抽象的一意識別子を検証するステップと、
   他の前記ルートサーバのそれぞれにおいて、前記一意識別子及び前記ポリシーを含む追加の証明書を発行するステップと、
   他の前記ルートサーバのそれぞれにおいて、前記それぞれの他のルートサーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて、前記発行済み追加証明書に署名するステップと、
   データレポジトリにおいて、前記要求元に対する前記署名した発行済み第１の証明書及び前記署名した発行済み追加証明書を記憶するステップと
   を備えることを特徴とする方法。
2. 前記Ｎは奇数であり、
   前記各ルートサーバは、他の全てのルートサーバから独立して署名し動作する
   ことを特徴とする請求項１に記載の方法。
3. ２個のルートコンピュータサーバは、２個の異なる要求元に対して同一の一意識別子を発行することはできない
   ことを特徴とする請求項１に記載の方法。
4. 各ルートサーバは、排他的な範囲の一意識別子を発行することを許可されている
   ことを特徴とする請求項１に記載の方法。
5. 前記要求元に対する前記署名した発行済み第１の証明書および前記署名した発行済み追加証明書は、前記要求元のいかなる説明または識別も含まない
   ことを特徴とする請求項１に記載の方法。
6. 前記抽象的一意識別子は、多数（Ｘ）の前記署名した発行済み第１の証明書および前記署名した発行済み追加証明書が有効である時に有効であるとみなされ、
   Ｘ＝Ｎ／２＋１である
   ことを特徴とする請求項１に記載の方法。
7. 前記リクエストは、前記ポリシーをさらに含む
   ことを特徴とする請求項１に記載の方法。
8. 前記ルートサーバにおいて、前記第１の発行済み証明書内の前記一意識別子の更新のための更新リクエストを受け取るステップであって、前記更新リクエストは、非公開キーを用いて前記他の一意識別子に関連する人、エンティティまたは電子デバイスのそれぞれによって署名されるステップと、
   各ルートサーバにおいて、前記第１の発行済み証明書内の前記ポリシーの実行を介して前記更新リクエストを検証するステップと、
   各ルートサーバにおいて、前記第１の発行済み証明書を交換するための交換証明書を発行するステップと、
   各ルートサーバにおいて、該それぞれのルートサーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて前記交換証明書に署名するステップと、
   データレポジトリにおいて、前記署名した発行済み交換証明書を記憶するステップと
   をさらに備えることを特徴とする請求項１に記載の方法。
9. 前記グループ権限は、前記ポリシーの実施を自動化する
   ことを特徴とする請求項１に記載の方法。
10. 前記第１の発行済み証明書は、公開キーまたは前記要求元に関連する公開キーの識別を備える
    ことを特徴とする請求項１に記載の方法。
11. 前記ポリシーは、前記一意識別子を交換または更新するためのポリシーを含む
    ことを特徴とする請求項１に記載の方法。
12. 前記ポリシーは、前記一意識別子を認証するためのポリシーを含む
    ことを特徴とする請求項１に記載の方法。
13. 人間、エンティティまたは電子デバイスのための一意識別子を作成するための方法であって、前記方法は、サーバ上で実現され、
    前記サーバにおいて、要求元から一意識別子に対するリクエストを受け取るステップと、
    前記サーバにおいて、一意識別子とポリシーと含む第１の証明書を発行するステップであって、前記ポリシーは、１個またはそれ以上の他の一意識別子を含み、該ポリシー内の他の識別子の数が１より大きい場合には少なくとも１個のブール演算子または数学関数とを含むステップと、
    前記サーバにおいて、該サーバに関連付けられた公開／非公開キー対のうちの非公開キーを用いて、前記発行した第１の証明書に署名するステップと、
    データレポジトリにおいて、前記署名した発行済み第１の証明書を記憶するステップと
    を備えることを特徴とする方法。
14. 前記署名した発行済み第１の証明書は、前記要求元のいかなる説明または識別も含まない
    ことを特徴とする請求項１３に記載の方法。
15. 前記リクエストは、前記ポリシーをさらに含む
    ことを特徴とする請求項１３に記載の方法。