7.1. 信頼当事者

7.1. 信頼当事者

このドキュメントは、信頼当事者が、Attesterに関する情報の信頼性を評価できるVerifierを信頼するシナリオをカバーしています。このような信頼は、1つ以上の「トラストアンカー」を「トラストアンカーストア」と呼ばれる安全な場所に保存することで表現されます。

[RFC6024]で定義されているように:

トラストアンカーは、公開鍵と関連データを介して権威のあるエンティティを表します。公開鍵はデジタル署名の検証に使用され、関連データはトラストアンカーが権威を持つ情報のタイプを制約するために使用されます。

トラストアンカーは証明書である場合もあれば、必要に応じて追加データ（公開鍵アルゴリズムやパラメータなど）を伴う生の公開鍵である場合もあります。このドキュメントの文脈では、[TCG-DICE-SIBDA]や[RATS-PSA-TOKEN]で説明されている対称モードのように、トラストアンカーは対称鍵である場合もあります。

したがって、Verifierを信頼することは、信頼当事者がVerifierの鍵または証明書をそのトラストアンカーストアに保存することで表現される場合があります。また、Verifierの証明書パスにあるエンティティ（例えば、認証局）の公開鍵または証明書を保存することで表現される場合もあります。例えば、信頼当事者は、帯域外で確立された鍵マテリアルとTLSのようなプロトコルを組み合わせて通信することで、Verifierが期待されるものであることを検証できます。ここでは、信頼された鍵マテリアルの確立とEvidenceの作成の間にVerifierが侵害されていないという前提があります。

より高いセキュリティレベルのために、信頼当事者は、Verifierがその証明結果を受け入れる前に、信頼当事者がVerifierの信頼性を評価するために使用できる自身に関する情報をVerifierが最初に提供することを要求する場合があります。このようなプロセスは、提供される情報の正確性に対するより高いレベルの信頼を提供します。例えば、本物のVerifierがマルウェアによって侵害されていないという信念などです。

例えば、信頼当事者「A」がVerifier「B」の正確性に対するこのような信頼を確立する明示的な方法の1つは、BがまずAttesterとして機能し、AがVerifier/信頼当事者の組み合わせとして機能することです。その後、AがBを信頼できると受け入れた場合、他のAttesterのVerifierとしてBを受け入れることを選択できます。

同様に、信頼当事者は、証明結果の評価ポリシーを提供する信頼当事者所有者も信頼する必要があり、一部のシナリオでは、信頼当事者が更新されたポリシーを受け入れる前に、信頼当事者所有者がリモート証明手順を経ることを要求する場合さえあります。これは、上記で議論したように、信頼当事者がVerifierへの信頼を確立する方法と同様の方法で実行できます。つまり、トラストアンカーストアに対して資格情報を検証し、オプションで信頼当事者所有者からの証明結果を要求します。