5. Clients (クライアント)

ログのクライアントが行いうる機能はさまざまです。ここでは典型的なクライアントとその動作例を説明します。いかなる不整合も, ログが正しく動作していなかった証拠として用いることができ, データ構造上の署名によりログはその不正行為を否定できません。

すべてのクライアントは互いにゴシップ (gossip) し, 少なくとも STH を交換すべきです。これだけで一貫したビューを共有できます。ゴシップの正確な仕組みは別文書で説明される予定ですが, 多様な方式があると期待されます。

5.1. Submitters (提出者)

提出者は上述のとおり証明書または Precertificate をログに提出します。返された SCT を用いて証明書を構成するか, TLS ハンドシェイクで直接利用できます。

5.2. TLS Client (TLSクライアント)

TLS クライアントは直接ログのクライアントではありませんが, サーバ証明書とともに (またはその中に) SCT を受け取ります。証明書とチェーンの通常の検証に加え, SCT データおよび証明書から署名入力を計算し, 対応するログの公開鍵で署名を検証すべきです。クライアントがログの公開鍵をどのように取得するかは本文書では説明しません。

TLS クライアントは, タイムスタンプが未来の SCT を拒否しなければなりません。

5.3. Monitor (モニタ)

モニタはログを監視し, 正しく振る舞っているか確認します。また関心のある証明書も監視します。

モニタは少なくとも, 監視する各ログの新規エントリをすべて調べる必要があります。ログ全体のコピーを保持してもよいです。そのためには, 各ログについて次の手順に従うべきです。

現在の STH を取得する (第4.3節)。
STH 署名を検証する。
STH に対応する木のすべてのエントリを取得する (第4.6節)。
取得したエントリから構築した木のハッシュが STH のハッシュと一致することを確認する。
現在の STH を取得する (第4.3節)。STH が変わるまで繰り返す。
STH 署名を検証する。
STH に対応する木の新規エントリをすべて取得する (第4.6節)。長期間利用不能なままなら, ログ側の不正行為とみなすべきです。
次のいずれか:
1. 更新後の全エントリのリストが, 新しい STH と同じハッシュの木を生成することを検証する。
または, すべてのログエントリを保持しない場合:
1. 新しい STH と前の STH との一貫性証明を取得する (第4.4節)。
2. 一貫性証明を検証する。
3. 新規エントリが一貫性証明の対応する要素を生成することを検証する。
手順5へ進む。

5.4. Auditor (監査者)

監査者はログに関する部分的な情報を入力とし, 自分が持つ他の部分的な情報と整合していることを検証します。監査者は TLS クライアントの不可欠な構成要素かもしれません。スタンドアロンサービスかもしれません。またはモニタの二次機能かもしれません。

同一ログからの STH の任意のペアは, 一貫性証明 (第4.4節) を要求することで検証できます。

SCT を伴う証明書は, SCT タイムスタンプ + Maximum Merge Delay より後の日付の任意の STH に対して, メルクル監査証明 (第4.5節) を要求することで検証できます。

監査者はもちろん, 随時自発的に STH を取得してもよいです (第4.3節)。