1. Informal Introduction (非公式な序論)

Certificate Transparency (証明書透明性, CT) は, 発行された全証明書の, 公開的に監査可能で追記のみ (append-only) かつ信頼不要なログを提供することで, 誤発行証明書 (misissued certificates) の問題を緩和することを目指します。ログは公開的に監査可能であるため, 誰でも各ログの正しさを検証し, 新しい証明書が追加されたタイミングを監視できます。ログ自体は誤発行を防ぐものではありませんが, 関心のある当事者 (特に証明書に記載された者) がそのような誤発行を検出できるようにします。これは一般的な仕組みですが, 本文書では公開 TLS サーバ証明書と, 公開認証局 (public certificate authorities, CAs) による発行に限定して説明します。

各ログは証明書チェーンで構成され, 誰でも提出できます。公開 CA は新規発行証明書を1つ以上のログに寄与することが期待されます。また, 証明書保有者が自身の証明書チェーンを寄与することも期待されます。ログがスパムにより無用化されるのを避けるため, 各チェーンは既知の CA 証明書でルート付けされていなければなりません。チェーンがログに提出されると署名付きタイムスタンプが返され, 後にクライアントへチェーンが提出された証拠として用いることができます。したがって TLS クライアントは, 自分が見る全証明書がログ済みであることを要求できます。

誤発行を心配する者はログを監視し, 定期的に新規エントリを問い合わせ, 自分が責任を負うドメインについて期待しない証明書が発行されていないか確認できます。その情報をどう扱うか, 特に誤発行を見つけたときに何をするかは本文書の範囲外ですが, 概して既存のビジネス上の仕組みで誤発行証明書に対処できます。もちろん, 望む者は誰でもログを監視し, 証明書が誤って発行されたと考えれば適宜行動できます。

同様に, 特定のログから署名付きタイムスタンプを見た者は, 後からそのログに包含証明 (proof of inclusion) を要求できます。ログがこれを提供できない (あるいは実際にモニタが保持するそのログの写しに対応する証明書が欠けている) 場合は, ログの誤動作の証拠になります。検査操作は TLS 接続を遅延させずに進められるよう, ネットワーク接続の問題やファイアウォールの都合に対応するため非同期に行われます。

各ログの追記のみという性質は, 技術的には Merkle Trees (メルクル木) を用いて達成されます。メルクル木は, ログの任意の特定バージョンが, 任意の過去の特定バージョンのスーパーセットであることを示すのに使えます。同様に, メルクル木によりログを盲信する必要はありません。ログが異なる相手に異なる内容を示そうとすれば, ツリールートと一貫性証明 (consistency proofs) を比較することで効率的に検出できます。同様に, ログのその他の不正 (例: 署名付きタイムスタンプを発行した後に証明書をログしない) も効率的に検出し, 広く世界に証明できます。

1.1. Requirements Language (要件言語)

本文書に現れるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, RFC 2119 [RFC2119] に記載のとおりに解釈されます。

1.2. Data Structures (データ構造)

データ構造は, [RFC5246] の第4節に示された慣例に従って定義されます。