RFC翻訳: Certificate Transparency Version 2.0

概要

本文書は TLS (Transport Layer Security) サーバ証明書の存在を発行時または観測時に公開されたログに記録するための証明書の透明性 (Certificate Transparency: CT) プロトコルのバージョン 2.0 を記述する。このプロトコルにより誰もが認証局 (CA) の活動を監視して疑わしい証明書の発行を検知できるだけでなく、証明書ログ自身も監査できる。このプロトコルの最終的な目的は、ログに記録されていない証明書の承認をクライアントが拒否し、CA が発行したすべての証明書をログに追加することを強制することである。

本文書は RFC 6962 を廃止する。また、様々な CT ログアーティファクトを送信するために使用される新しい TSL 拡張機能も規定する。

ログは、本文書で定義されている送信とクエリーのプロトコル操作を実装するネットワークサービスである。

Table of Contents

1. 概要
2. 1 はじめに
   1. 1.1 要件言語
   2. 1.2 データ構造と OIDs
   3. 1.3 CT 1.0 からの主な相違点
3. 2 暗号コンポーネント
   1. 2.1 マークルツリー
      1. 2.1.1 マークルツリーの定義
      2. 2.1.2 エントリに基づくツリーヘッドの検証
      3. 2.1.3 マークル包含証明
         1. 2.1.3.1 包含証明の生成
         2. 2.1.3.2 包含証明の検証
      4. 2.1.4 マークル整合性証明
         1. 2.1.4.1 整合性証明の生成
         2. 2.1.4.2 2 つのツリーヘッド間の整合性検査
      5. 2.1.5 例
   2. 2.2 署名
4. 3 提出者
   1. 3.1 証明書
   2. 3.2 事前証明書
      1. 3.2.1 発行意図の束縛
5. 4 ログフォーマットと操作
   1. 4.1 ログのパラメータ
   2. 4.2 提出の評価
      1. 4.2.1 最小受理基準
      2. 4.2.2 裁量的受理基準
   3. 4.3 ログエントリ
   4. 4.4 ログ ID
   5. 4.5 TransItem 構造
   6. 4.6 ログアーティファクト拡張
   7. 4.7 マークルグリーの葉
   8. 4.8 署名付き証明書タイムスタンプ (SCT)
   9. 4.9 マークルツリーのヘッド
   10. 4.10 署名付きツリーのヘッド (STH)
   11. 4.11 マークル整合性証明
   12. 4.12 マークル包含証明
   13. 4.13 ログの閉鎖
6. 5 ログクライアントメッセージ
   1. 5.1 ログエントリに提出
   2. 5.2 最新の署名済みツリーヘッドの取得
   3. 5.3 2 つの STH 間のマークル整合性証明の取得
   4. 5.4 葉ハッシュによるログからのマークル包含証明の取得
   5. 5.5 葉ハッシュによるマークル包含証明、STH、および整合性証明の取得
   6. 5.6 ログからエントリと STH の取得
   7. 5.7 受理された信頼アンカーの取得
7. 6 TLS サーバ
   1. 6.1 TLS クライアント認証
   2. 6.2 複数の SCTs
   3. 6.3 TransItemList 構造
   4. 6.4 SCT、包含証明、および STH の提示
   5. 6.5 transparency_info TLS 拡張
8. 7 証明書認証局
   1. 7.1 透明性情報 X.509v3 拡張
      1. 7.1.1 OCSP レスポンス拡張
      2. 7.1.2 証明書拡張
   2. 7.2 TLS 機能 X.509v3 拡張
9. 8 クライアント
   1. 8.1 TLS クライアント
      1. 8.1.1 SCT と包含証明の受信
      2. 8.1.2 TBSCertificate の再構築
      3. 8.1.3 SCT の検証
      4. 8.1.4 包含証明の取得
      5. 8.1.5 包含証明の検証
      6. 8.1.6 コンプライアンスの評価
   2. 8.2 監視者
   3. 8.3 監査
10. 9 アルゴリズムの柔軟性
11. 10 IANA に関する考慮事項
    1. 10.1 既存レジストリへの追加
       1. 10.1.1 TLS ExtensionType への新しいエントリ
       2. 10.1.2 TRANS 用 URN サブ名前空間 (urn:ietf:params:trans)
    2. 10.2 新しい CT 関連レジストリ
       1. 10.2.1 ハッシュアルゴリズム
       2. 10.2.2 署名アルゴリズム
       3. 10.2.3 VersionedTransType
       4. 10.2.4 Log Artifact Extension
       5. 10.2.5 Log ID Registry
       6. 10.2.6 CT Error Types
    3. 10.3 OID の割り当て
12. 11 セキュリティ考察
    1. 11.1 誤発行された証明書
    2. 11.2 誤発行証明書の検出
    3. 11.3 不正動作するログ
    4. 11.4 複数の SCT
    5. 11.5 DNS 情報の漏洩
13. 12. References
    1. 12.1. Normative References
    2. 12.2. Informative References
14. Appendix A. v1 と v2 の並行サポート (参考情報)
15. Appendix B. ASN.1 モジュール (参考情報)
16. Acknowledgements

1 はじめに

Certificate Transparency は、発行された証明書の追記専用ログを提供することで、不正発行された証明書の問題を軽減することを目指している。ログ自体は不正発行を防止するものではないが、利害関係者 (特に証明書に名前が記載されている者) がそのような不正発行を検出できることを保証する。これは、何らかの包含基準に従って、あらゆる形式のバイナリデータを透過的にログに記録するために使用できる汎用的なメカニズムであることに注意。この文書では、公開 TLS サーバ証明書 (すなわち、包含基準が公開認証局 (CA) によって発行された有効な証明書であるもの) への使用のみを説明する。"公開" の典型的な定義は [CABBR] に見られる。

各ログは証明書チェーンを含んでおり誰でも提出 (submit) できる。公開 CA が新しく発行したすべての証明書を 1 つ以上のログに提供することが期待されている。ただし、証明書保有者も自身の証明書チェーンを提供できるし、第三者も提供できる。大量の偽の証明書の提出によってログが使用不能になることを回避するために、各チェーンはログによって受理される信頼アンカーで終了することが要求される。ログは、受理する意思のあるチェーンの長さを制限してもよいが、そのようなチェーンも受理可能な信頼アンカーで終了しなければならない。チェーンがログに受理されると、署名付きタイムスタンプが返される。これは、そのチェーンが提出されたという証拠を後で TLS クライアントに提出するために使用できる。したがって、TLS クライアントは、受理するすべての有効な証明書に署名付きタイムスタンプが付随していることを要求できる。

不正発行を懸念する者はログを監視して定期的にすべての新しいエントリを要求することができ、自身が責任を持つドメインに対して予期しない証明書が発行されたかどうかを確認できる。この情報をどう扱うか、特に不正発行が発生したことを発見した場合にどうするかは、この文書の範囲外である。しかし、おおまかに言えば、証明書を失効させるために CA と協力したり、信頼アンカーリストの管理者と協力して CA を削除させたりするなど、不正発行された証明書に対処するために既存のビジネスメカニズムを発動できる。勿論、誰でもログを監視でき、証明書が誤って発行されたと確信したなら適切と思われる行動を取ることができる。

同様に、特定のログから署名付きタイムスタンプを観測した者は、後でそのログから包含証明を請求できる。ログがこれを提供できない場合 (または実際に対応する証明書が監視者のそのログのコピーに存在しない場合)、それはログの不正な動作の証拠である。チェック操作は非同期であり、ネットワーク接続の問題やファイアウォールの気まぐれなどの潜在的な問題にもかかわらず、クライアントが遅延泣く処理を進めることを可能にする。

各ログの追記専用特製はマークルツリーを使用して達成される。マークルツリーは、ログの特定のインスタンスタンスが特定の以前のスーパーセットであることを効率的に証明し、ログの様々な不正行為 (例えば、その後ログに記録されない証明書に対して署名付きタイムスタンプを発行するなど) を効率的に提出するために使用できる。

この文書で説明しているログ監査メカニズムは、異なるクライアントに対して一貫性のないそれ自身が異なるビューを示すような不正なログによって回避される可能性がある。したがって、各ログを信頼された第三者として扱う必要がある。それらの欠点に対処し、ログを妄信的に信頼する必要性を回避するメカニズムが開発されているが、そのようなメカニズムはこの文書の範囲外である。

1.1 要件言語

この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] に記載されているように解釈されるものとする。ただし、これらがすべて大文字で表示される場合に限る。

1.2 データ構造と OIDs

データ構造は [RFC8446] のセクション 3 に規定された規約に従って定義およびエンコードされる。

この文書はログ ID を識別するため (セクション 4.4 参照)、事前証明書の暗号メッセージ構文 (CMS; Cryptographic Message Syntax) eContentType (セクション 3.2 参照)、証明書内の X509v3 拡張セクション 7.1.1 参照) を識別するためにオブジェクト識別子 (OID) を使用する。これらの OID はアークで定義されており、そのエンコーディングが短いために選択された。

1.3 CT 1.0 からの主な相違点

この文書は CT 1.0 プロトコル [RFC6962] を改訂し、廃止する。CT 1.0 の配備から得られた知見とコミュニティからのフィードバックに基づいている。主な変更点は以下の通りである。

• ハッシュおよび署名アルゴリズムの柔軟化: 許可されるアルゴリズムは現在 IANA レジストリで指定されている。

• 事前証明書の形式: 事前証明書は現在 X.509 証明書ではなく CMS オブジェクトであり、[RFC5280] のセクション 4.1.2.2 における証明書シリアル番号の一意性要件に違反することを回避している。

• ログ ID: 現在、各ログは公開鍵のハッシュではなく OID によって識別される。OID の割り当ては IANA レジストリから利用可能である。

• TransItem 構造: この新しいデータ構造はほとんどの種類の CT データをカプセル化するために使用される。1 つ以上の TransItem 構造からなる TransItemList は [RFC6962] で SignedCertificateTimestampList が使用されていたあらゆる場所で使用できる。

• マークルツリーの葉: MerkleTreeLeaf 構造は TransItem 構造に置き換えられた。これにより、拡張性が容易になり、1 つの抽象化レイヤーを削除することでは構造が簡素化される。

• ログアーティファクト: 現在、これらは型付けされ IANA レジストリによって管理される。また署名付き証明書タイムスタンプ (SCT) だけではなく署名付きツリーヘッド (STH) にも現われることができる。

• API 出力: 核構造の構成要素ではなく、完全な TransItem 構造が返される。

• get-all-by-hash: これは包含証明と対応する整合性証明を同時に取得する新しいクライアント API である。

• submit-entry: これは add-chain と add-pre-chain を置き換える新しいクライアント API である。

• 証明を伴う SCT の提示: TLS サーバは、[RFC6962] が SCT のみを提示するために定義したメカニズムのいずれかを使用して、対応する包含証明と共に SCT を提示しても良い。(SCT のみを提示することも依然としてサポートされている。)

• CT TLS 拡張: signed_certificate_timestamp TLS 拡張は transparency_info TLS 拡張に置き換えられた。

• 検証アルゴリズム: 包含証明を検証するため、2 つの STH 間の整合性を検証するため、および関連する葉入力エントリの完全なリストが与えられたときにルートハッシュを検証するための詳細なアルゴリズムが追加された。

• 広範な明確化と編集作業。

2 暗号コンポーネント

2.1 マークルツリー

マークルツリー (Merkle tree) の完全な説明はこの文書の範囲を超えている。簡単に説明すると、これはそれぞれの非葉ノードがその子ノードのハッシュであるような二分木である。CT においては、この数は最大でも 2 つである。その他の情報は [RFC8391] の Introduction と Reference セクションにある。

2.1.1 マークルツリーの定義

ログは効率的な監査のために二分マークルツリーを使用する。使用されるハッシュアルゴリズムはログのパラメータ (セクション 4.1 参照) の一つである。本文書は許容可能なハッシュアルゴリズムのレジストリを確立する (セクション 10.2.1 参照)。このドキュメントを通じて使用するハッシュアルゴリズムを \({\rm HASH}\) と呼び、その出力のバイトサイズを \({\rm HASH\_SIZE}\) と呼ぶ。マークルツリーハッシュへの入力はデータエントリのリストである。これらのエントリはハッシュ化されマークルツリーの葉を形成する。出力は \({\rm HASH\_SIZE}\) のマークルツリーハッシュである。\(n\) 個の入力の順序付きリスト \(D_n = \{d_0, d_1, \ldots, d_{n-1}\}\) が与えられたとき、マークルツリーハッシュ (\({\rm MTH}\)) は以下のように定義される:

空リストのハッシュは空文字列のハッシュである: \[ {\rm MTH}(\{\}) = {\rm HASH}() \] 1 つのエントリを持つリストのハッシュ (葉ハッシュとも呼ばれる) は次のようになる: \[ {\rm MTH}(\{ d_0 \}) = {\rm HASH}({\tt 0x00} \, || \, d_0) \] \(n \gt 1\) に対して、\(n\) より小さい 2 の最大乗を \(k\) とする (すなわち \(k \gt n \ge 2k\))。\(n\) 要素のリスト \(D_n\) のマークルツリーハッシュは再帰的に次のように定義される: \[ {\rm MTH}(D_n) = {\rm HASH}({\tt 0x01} \, || \, {\rm MTH}(D_{0:k}) \, || \, {\rm MTH}(D_{k:n})) \] ここで:

• \(||\) は連結を表す。
• \(:\) はリストの連結を表す
• \(D_{k_1:k_2} = D'_{k_2-k_1}\) は長さ \(k_2-k_1\) のリスト \(\{d'_0 = d_{k_1},\) \(d'_1 = d_{k_1+1},\) \(\ldots,\) \(d'_{k_2-k_1-1} = d_{k_2-1}\}\) を表す。

葉とノードのハッシュ計算が異なることに注意。このドメンの分離は第二原像耐性を与えるために必要である。

入力リストの長さが 2 のべき乗である必要はない。しかし、その形状母の数によって一意に決まる。(注: このマークルツリーは [CrosbyWallach] によって定義された履歴木と本質的に同じであるが、我々の定義では非完全木で扱いが異なる。)

2.1.2 エントリに基づくツリーヘッドの検証

クライアントが \(0\) から \({\rm tree\_size}-1\) までのエントリの完全なリストを持っており、同じ \({\rm tree\_size}\) 個のログから返されたツリーヘッド \({\rm root\_hash}\) に対してこのリストを検証したい場合、次のアルゴリズムを使用できる:

1. スタックを空にする。

2. \(0\) から \({\rm tree\_size}-1\) までの各 \(i\) について:

   1. \({\rm HASH}({\tt 0x00} \, || \, e_i)\) をスタックにプッシュする。

   2. \({\rm merge\_count}\) を、\({\rm LSB}(i \gt\gt {\rm merge\_count})\) が設定されていない最小の値 (0 を含む) に設定する。ここで \({\rm LSB}\) は最下位ビット (least significant bit) を意味する。言い換えれば、\({\rm merge\_count}\) を \(i\) の最下位ビットから始まる連続する \(1\) の個数に設定する。

   3. \({\rm merge\_count}\) 回の繰り返し:

      1. スタックから \({\rm right}\) をポップする。

      2. スタックから \({\rm left}\) をポップする。

      3. \({\rm HASH}({\tt 0x01} \, || \, {\rm left} \, || \, {\rm right})\) をスタックにプッシュする。

3. スタックに複数の要素が残っている場合、要素が 1 つになるまで同じマージ手順 (上記ステップ 2(c) のサブ項目) を繰り返す。

4. スタックに残った要素が、与えられた \({\rm tree\_size}\) に対するマークルツリーハッシュであり、提供された \({\rm root\_hash}\) と等しいかを比較する。

2.1.3 マークル包含証明

マークルツリーにおける葉ノードの包含証明 (inclusion proof) とは、そのツリー全体のマークルツリーハッシュを計算するために必要な、最小限の追加ノードのリストである。ツリー内の各ノードは、葉ノードか、その直下 (つまり葉方向) の 2 つのノードから計算される。ツリーをルートに向かって上方向に一段ずつ上がるごとに、包含証明に含まれるノードを、それまでに計算されたノードと結合する。言い換えれば、包含証明とは、ある葉からルートに至るまでのノードを計算するために必要な不足ノードのリストである。もし包含証明から計算されたルートが真のルートと一致するなら、その包含証明は該当の葉がツリーに存在することを証明する。

2.1.3.1 包含証明の生成

ツリーに\(n\) 個の入力の順序付きリスト \(D_n=\{d_0,d_1,\ldots,d_{n-1}\}\) が与えられたとき、\(m+1\) 番目の入力 \(d_m\), \(0\le m \lt n\) に対するマークル包含証明 \({\rm PATH}(m,D_n)\) は次のように定義される。

• 入力が 1 要素のみのツリー、すはわち \(D_1 = \{d_0\}\) の場合、その葉の証明は空である。\[ {\rm PATH}(0, \{d_0\}) = \{\} \]

• \(n \gt 1\) の場合、\(k\) を \(n\) より小さい最大の 2 のべき乗とする。\(n \gt m\) 個の要素からなるリストにおける \(m+1\) 番目の要素 \(d_m\) の証明は、次のように再帰的に定義される。\[ \begin{cases} {\rm PATH}(m, D_n) = {\rm PATH}(m, D_{0:k}) : {\rm MTH}(D_{k:n}) & \text{if $m \lt k$} \\ {\rm PATH}(m, D_n) = {\rm PATH}(m-k, D_{k:n}) : {\rm MTH}(D_{0:k}) & \text{if $m \ge k$} \end{cases} \]

ここで演算子 \(:\) と \(D_{k_1:k_2}\) の表記の定義はセクション 2.1.1 と同じである。

2.1.3.2 包含証明の検証

クライアントが包含証明 (たとえば TransItem 構造体の inclusion_proof_v2 型) を受け取り、与えられた tree_size と root_hash に入力 hash が含まれているかを検証したい場合、以下のアルゴリズムを使用して証明できる。

1. inclusion_proof_v2 構造体から得られる leaf_index を tree_size と比較する。もし leaf_index が tree_size 以上であれば証明検証は失敗とする。

2. leaf_index と sn を tree_size - 1 に設定する。

3. r を hash に設定する。

4. inclusion_path 配列の各要素 p について:

   1. sn が 0 の場合、反復を停止し証明検証は失敗とする。

   2. LSB(fn) がセットされているか、または fn が sn と等しい場合:

      1. r を HASH(0x01 || p || r) に設定する。

      2. LSB(fn) が設定されていない場合、fn と sn の両方を右シフトする処理を、LSB(fn) が設定されるか fn が 0 になるまで繰り返す。

      それ以外の場合:

      1. r を HASH(0x01 || r || p) に設定する。

   3. 最後に fn と sn の両方を 1 ビット右にシフトする。

5. sn が 0 であり、r と root_hash が等しければ、ログは hash の包含を証明したことになる。そうでなければ証明検証は失敗する。

2.1.4 マークル整合性証明

マークル整合性証明 (Merkle consistency proof) はツリーの追記専用特性 (append-only property) を証明するものである。マークルツリーハッシュ \({\rm MTH}(D_n)\) と、その最初の \(m\) 個の葉に基づく過去に提示されたハッシュ \({\rm MTH}(D_{0:m})\), \(m \le n\) に対する整合性証明とは、両方のツリーにおいて最初の \(m\) 個の入力 \(D_{0:m}\) が同一であることを証明するために必要なノードのリストである。つまり、整合性証明には \({\rm MTH}(D_n)\) を検証するのに十分な中間ノード (入力へのコミットメント) が含まれていなければならず、そのうち (部分集合としての) 同じノードが \({\rm MTH}(D_{0:m})\) の検証にも利用できる必要がある。我々は、一意で最小の整合性証明を出力するアルゴリズムを定義する。

2.1.4.1 整合性証明の生成

ツリーへの \(n\) 個の入力の順序付きリスト \(D_n=\{d_0,d_1,\ldots,d_{n-1}\}\) が与えられたとき、過去に提示されたマークルツリーハッシュ \({\rm MTH}(D_{0:m})\), \(0 \lt m \lt n\) に対するマークル整合性証明 \({\rm PROOF}(m,d_n)\) は次のように定義される: \[ {\rm PROOF}(m,D_n) = {\rm SUBPROOF}(m, D_n, {\tt true}) \] \({\rm SUBPROOF}\) におけるブール値は、\(D_{0:m}\) から生成される部分木が \(D_n\) から生成されるマークルツリーの完全な部分木であるかどうかを表し、これはつまり部分木のマークルツリーハッシュ \({\rm MTH}(D_{0:m})\) が既知かどうかを示している。最初の \({\rm SUBPROOF}\) 呼び出しではこれを \({\tt true}\) と設定する。\({\rm SUBPROOF}\) は次のように定義される:

\(m=n\) の場合の部分証明は、\(m\) が \({\rm PROOF}\) の元々要求された値である場合 (つまり \(D_{0:m}\) から生成される部分木が \({\rm PROOF}\) が要求された元の \(D_n\) から生成されるマークルツリーの完全な部分木であり、部分木のマークルツリーハッシュ \({\rm MTH}(D_{0:m})\) が既知の場合)、空となる: \[ {\rm SUBPROOF}(m, D_m, {\tt true}) = \{\} \] そうでない場合、\(m=n\) の部分証明は入力 \(D_{0:m}\) をコミットするマークルツリーハッシュである: \[ {\rm SUBPROOF}(m, D_m, {\tt false}) = \{{\rm MTH}(D_m)\} \] \(m \lt n\) において \(k\) を \(n\) より小さい最大の 2 のべきとする。部分証明は次の適切なステップを使って再帰的に定義される:

\(m \le k\) の場合、右側の部分木のエントリ \(D_{k:n}\) の要素は現在のツリーにしか存在しない。我々は左側の部分木のエントリ \(D_{0:k}\) が整合的であることを証明し、\(D_{k:n}\) へのコミットメントを追加する: \[ {\rm SUBPROOF}(m, D_n, b) = {\rm SUBPROOF}(m, D_{0:k}, b) : {\rm MTH}(D_{k:n}) \] \(m \gt k\) の場合、左側の部分木のエントリ \(D_{0:k}\) は両方のツリーで同一である。我々は右側の部分木のエントリ \(D_{k:n}\) が整合的であることを証明し、\(D_{0:k}\) へのコミットメントを追加する: \[ {\rm SUBPROOF}(m, D_n, b) = {\rm SUBPROOF}(m - k, D_{k:n}, {\tt false}) : {\rm MTH}(D_{0:k}) \] 結果として得られる証明内のノード数は \(\lceil\log_2 n\rceil+1\) によって上限が定められる。

ここで演算子 \(:\) と \(D_{k_1:k_2}\) の表記の定義はセクション 2.1.1 と同じである。

2.1.4.2 2 つのツリーヘッド間の整合性検査

クライアントがサイズ \({\rm first}\) のツリーの先頭部分 \({\rm first\_hash}\) を持ち、サイズ \({\rm second}\) に対する \({\rm second\_hash}\) を持ち (\(0 \lt {\rm first} \lt {\rm second}\))、さらに両者間の整合性証明を受け取った場合 (例えば consistency_proof_v2 型の TransItem において)、次のアルゴリズムによって整合性証明を検証できる:

1. \({\rm consistency\_path}\) が空配列であれば、検証を停止し失敗とする。

2. \({\rm first}\) が 2 のべき乗の場合、\({\rm first\_hash}\) を \({\rm consistency\_path}\) 配列の先頭に追加する。

3. fn を \({\rm first}-1\) に、sn を \({\rm second}-1\) に設定する。

4. LSB(fn) が設定されている場合、LSB(fn) が設定されなくなるまで fn と sn の両方を等しく右シフトする。

5. fr と sr の両方を \({\rm consistency\_path}\) 配列の先頭の値に設定する。

6. \({\rm consistency\_path}\) 配列内の残りの各値 \(c\) に対して:

   1. sn が 0 である場合、反復を停止して証明の検証を失敗とする。

   2. LSB(fn) が設定されている場合、または fn と sn が等しい場合:

      1. fr を \({\rm HASH}({\tt 0x01}\,||\,c\,||\,{\rm fr})\) に設定する。

      2. sr を \({\rm HASH}({\tt 0x01}\,||\,c\,||\,{\rm sr})\) に設定する。

      3. LSB(fn) が設定されていない場合、LSB(fn) が設定されるか、fn が 0 となるまで fn と sn の両方を等しく右シフトする。

      それ以外の場合:

      1. sr を \({\rm HASH}({\tt 0x01}\,||\,{\rm sr}\,||\,c)\) に設定する。

   3. 最後に、fn と sn の両方を 1 回右にシフトする。

7. 上記の手順をすべて実行した後、算出した fr が与えられた \({\rm first\_hash}\) と一致し、かつ算出した sr が与えられた \({\rm second\_hash}\) と一致し、さらに sr が 0 であることを検証する。

2.1.5 例

次の図は 7 個の葉を持つ二分マークルツリーである。

           hash
          /    \
         /      \
        /        \
       /          \
      /            \
     k              l
    / \            / \
   /   \          /   \
  /     \        /     \
 g       h      i      j
/ \     / \    / \     |
a b     c d    e f     d6
|  |    |  |   |  |
d0 d1   d2 d3  d4 d5

d0 の包含証明は \([b,h,l]\)、d3 の包含証明は \([c,g,l]\)、d4 の包含証明は \([f,j,k]\)、d6 の包含証明は \([i,k]\) である。

同じツリーを 4 つのステップで増分的に構築した場合は次のようになる。

        hash0          hash1=k
        / \              /  \
       /   \            /    \
      /     \          /      \
      g      c         g       h
     / \     |        / \     / \
     a b     d2       a b     c d
     | |              | |     | |
    d0 d1            d0 d1   d2 d3

              hash2                    hash
              /  \                    /    \
             /    \                  /      \
            /      \                /        \
           /        \              /          \
          /          \            /            \
         k            i          k              l
        / \          / \        / \            / \
       /   \         e f       /   \          /   \
      /     \        | |      /     \        /     \
     g       h      d4 d5    g       h      i      j
    / \     / \             / \     / \    / \     |
   a b     c d             a b     c d    e f     d6
   | |     | |             | |     | |    | |
  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5

hash0 と hash の間の整合性証明は \({\rm PROOF}(3,D_7)=[c,d,g,l]\) である。非葉ノード \(c\), \(g\) は hash0 を検証するために使用され、加えて非葉ノード \(d\), \(l\) は hash が hash0 と整合的であることを示すために使用される。

hash1 と hash の間の整合性証明は \({\rm PROOF}(4,D_7)=[l]\) である。hash は hash1\(=k\) と \(l\) を使用して検証できる。

hash2 と hash の間の整合性証明は \({\rm PROOF}(6,D_7)=[i,j,k]\) である。非葉ノード \(k\) と \(i\) は hash2 を検証するために使用され、加えて非葉ノード \(j\) は hash が hash2 と整合的であることを示すために使用される。

2.2 署名

データ構造に署名する際、ログはセクション 10.2.2 で詳述する IANA の "Signature Algorithms" レジストリの署名アルゴリズムの 1 つを使用しなければならない。

3 提出者

提出者 (submitter) は、公開監査のために証明書または証明書発行前事前証明 (事前証明書; precertificate) を以下に説明するようにログに提出する。ログに記録された各証明書または事前証明書をその発行者に帰属させられるように、各提出は、受理された信頼アンカーまで検証チェーンを構築するために必要なすべての追加証明書を伴わなければならない (セクション 5.7)。信頼アンカー (ルート CA 証明書または中間 CA 証明書) は提出から省略することができる。

ログが提出を受理した場合、署名付き証明書タイムスタンプ (Signed Certificate Timestamp; SCT) を返す (セクション 4.8 参照)。提出者は、返された SCT がその形式を理解しており、それを TLS ハンドシェイクで直接使用する意図がある場合、または証明書を構築する意図がある場合、セクション 8.1 に記載されているように返された SCT を検証すべきである。提出者が SCT を必要としない場合 (例えば、証明書が単にログで利用可能にするために提出される場合)、SCT を検証することができる。

3.1 証明書

任意のエンティティが証明書をログに提出できる (セクション 5.1)。TLS クライアントがログに記録されていない証明書を拒否することが予想されるため、証明書の発行者および主体はそれらを提出する強い動機を持つことが期待される。

3.2 事前証明書

CA は、発行前に証明書を事前通知してもよい。これは、その発行される証明書に対してログが有効なエントリを作成するために使用できる事前証明書 (セクション 5.1) を提出することによって行う。CA は、返された SCT を発行される証明書に組み込むことができる。返された SCT が発行される証明書に組み込まれない例の 1 つは、CA が事前証明書を複数のログに送信するが、最初に返された SCT のみを組み込む場合である。

事前証明書は、次のプロファイルに準拠する CMS [RFC5652] signed-data オブジェクトである:

• [X690] に記載されているように DER エンコードされていなければならない。

• SignedData.version は v3 (3) でなければならない。

• SignedData.digestAlgorithms は SignerInfo.digestAlgorithm の OID 値と同じでなければならない (下記を参照)。

• SignedData.encapContentInfo は:

  • eContentType は OID 1.3.101.78 でなければならない。

  • eContent は、発行される証明書の TBSCertificate と同一となる TBSCertificate [RFC5280] を含まなければならない。ただし、透明性情報 (Transparency Information) (セクション 7.1) は省略されなければならない。

• SignedData.certificates は省略されなければならない。

• SignedData.crls は省略されなければならない。

• SignedData.signerInfos は 1 つ以上の SignerInfo を含まなければならない:

  • version は v3 (3) でなければならない。

  • sid は subjectKeyIdentifier オプションを使用しなければならない。

  • digestAlgorithm は、セクション 10.2.1 に記載されている IANA の "Hash Algorithms" レジストリに列挙されているハッシュアルゴリズム OID の 1 つでなければならない。

  • signedAttrs は存在しなければならず、2 つの属性を含まなければならない:

    • content-type 属性。その値は SignedData.encapContentInfo.eContentType の値と同じでなければならない。

    • message-digest 属性。その値は SignedData.encapContentInfo.eContent のハッシュでなければならない。

  • signatureAlgorithm は TBSCertificate.signature と同じ OID でなければならない。

  • signature は、対応する証明書を葉加工する位置を持つ同じ (ルートまたは中間) CA からのものでなければならない (セクション 3.2.1 参照)。

  • unsignedAttrs は省略されなければならない。

SignerInfo.signedAttrs はメッセージダイジェスト計算プロセス ([RFC5652] のセクション 5.4 参照) に含まれる。これにより、SignerInfo.signature の値が、有効な証明書を構築するために (SignedData.encapContentInfo.eContent からの) TBSCertificate と組み合わせて使用できる有効な X.509v3 署名にならないことが保証される。

3.2.1 発行意図の束縛

通常の状況では、事前証明書の提出と対応する証明書の発行の間には短い遅延がある。より長い遅延も時折予測される (例えばログサーバのダウンタイムなど)。場合によっては、CA が実際に対応する証明書を発行しないこともある。それにもかかわらず、事前証明書の署名は対応する証明書を発行するという CA の拘束意図を示している。これは次のことを意味する:

• 事前証明書の発行は、対応する証明書の不正発行と同等と見なされる。CA は、対応する証明書が実際に発行されていない場合でも、責任を問われることを予期すべきである。

• 事前証明書を観測すると、クライアントは対応する証明書が発行されたと合理的に推定できる。クライアントは、存在すると推定される証明書に関するステータス情報 (例えばオンライン証明書ステータスプロトコル [RFC6960] を使用するか、証明書失効リスト [RFC5280] を確認することによって) を取得することを望む場合がある。特に、対応する事前証明書が不正に発行されたという証拠または疑いがある場合である。

• TLS クライアントは、対応する事前証明書の存在に基づいて存在すると推定される各証明書について、CA が失効させることができ、証明書ステータスサービスを提供できることを要求するポリシーを持つ場合がある。

4 ログフォーマットと操作

ログは、提出された証明書および事前証明書エントリの単一の追記専用マークルツリーである。

ログは有効な提出を受け取って受理すると、提出された証明書または事前証明書に対応する SCT を返さなければならない。ログが以前にこの有効な提出を観測している場合、セクション 11.3 で議論されているように、以前に返したものと同じ SCT を返すべきである。同じ提出に対して異なる SCT を生成する場合、各 SCT に対して 1 つずつ、複数のログエントリを作成する必要がある (タイムスタンプは葉構造の一部であるため)。証明書が過去に事前証明書としてログに記録されている場合、その事前証明書の precert_sct_v2 型の SCT は適切ではない。代わりに x509_sct_v2 型の新しい SCT を生成すべきである。

SCT は、受理された提出に対応するエントリをそのマークルツリーに追加するというログの契約である。ログは SCT を生成すると、ログのパラメータの 1 つである最大マージ遅延 (MMD; Maximum Merge Delay) として知られる固定時間内に次の動作を実行することによって、この契約を果たさなければならない (セクション 4.1 参照):

• 受理された提出を表すエントリにツリーのインデックスを割り当てる。

• ツリーのルートを計算する。

• ツリーのルートに署名する (セクション4.10 参照)。

ログは、ツリーのルートに署名する前に複数のエントリを追加してもよい。

ログのオペレータは、ログからのデータの取得または共有に対していかなる条件も課すべきではない。

4.1 ログのパラメータ

ログは不変のパラメータの集合によって定義される。これらのパラメータは、クライアントがログと通信し、ログのアーティファクトを検証するために使用される。最終の STH を除き、これらの各パラメータはログのオペレータがログの運用を開始する前に確立されなければならない。

• ベース URL: クライアントメッセージ用の URL [RFC3986] を構築するために使用されるプレフィクス (セクション 5 参照)。ベース URL は "https" URL でなければならず、ポートを含むことができ、任意の数のパスセグメントを持つパスを含むことができるが、クエリ文字列、フラグメント、または末尾の "/" を含んではならない。例: https://ct.example.org/blue

• ハッシュアルゴリズム: マークルツリーに使用されるハッシュアルゴリズム (セクション 10.2.1 参照)。

• 署名アルゴリズム: 使用される署名アルゴリズム (セクション 2.2 参照)。

• 公開鍵: ログによって生成された署名を検証するために使用される公開鍵。ログは他のいかなるログとも同じ鍵ペアを使用してはならない。

• ログ ID: ログを一意に識別する OID。

• 最大マージ遅延: ログがコミットした MMD。この文書は実験を可能にするために値に対する制限を意図的に規定していない。

• バージョン: ログがサポートするプロトコルのバージョン (現在は 1 または 2)。

• 最大チェーン長: ログが制限を課す場合、ログが受理する最大の証明書チェーン提出の長さ。

• STH 頻度カウント: 最大マージン遅延に等しい任意の期間内にログが生成してもよい STH の最大数 (セクション 4.10 参照)。

• 最終 STH: ログが閉鎖された場合 (つまり新しいエントリを受け付けなくなった場合) でも既存のエントリは依然として有効であることができる。この場合、これ以上新しいエントリが検出なしに追加されないことを保証するために、クライアントはログ内の最終的に有効な STH を知るべきである。この値は signed_tree_head_v2 型の TransItem 構造の形式で提供されなければならない。ログがまだエントリを受け付けている場合、この値は提供されるべきではない。

[JSON.Metadata] は上記の要素を含むメタデータ形式の例である。

4.2 提出の評価

ログは、最小受理基準 (セクション 4.2.1 参照) および裁量的受理基準 (セクション 4.2.2 参照) に照らして評価することによって、提出を受理するか拒否するかを決定する。

受理基準が満たされている場合、ログは提出を受理すべきである。(例えば、サービス拒否攻撃からログ自身を保護するために、受理可能な提出を一時的に拒否することを決定する場合がある。)

ログは、受理された信頼アンカーのリストの取得を許可すべきである (セクション 5.7 参照)。各信頼アンカーはルート CA 証明書または中間 CA 証明書である。このリストは、主要なブラウザベンダーによって信頼されているルート証明書の和集合であることが有用かもしれない。

4.2.1 最小受理基準

ログに記録された証明書および事前証明書が受理された信頼アンカーに帰属可能であることを保証し、監視者がログ内で見つけられるものに対する明確な期待を設定し、無効な提出によって過負荷になることを回避するために、次の条件のいずれかが満たされていない場合、ログは提出を拒否しなければならない:

• submission, type, chain の入力はセクション 5.1 に記載されてるように設定されなければならない。ログは、誤った順序の CA 証明書に対応したり、中間 CA 証明書の他のソースを使用して証明書パス構築を試みたりしてはならない。

• チェーン内の 0 個以上の中間 CA 証明書のそれぞれは、次の機能の一方または両方を持たなければならない:

  • CA 証明書を示す cA ブール値が true に設定された Basic Constraints 拡張。

  • keyCertSign ビットが 1 に設定された Key Usage 拡張。

• チェーン内の各証明書は、チェーンの上位に見られる 0 個以上の Basic Constraints pathLenConstraints 値によって課される制限の範囲内になければならない。

• 事前証明書の提出は、セクション 3.2 のすべての要件に準拠しなければならない。

4.2.2 裁量的受理基準

最小受理基準が満たされているが、提出が [RFC5280] の検証ルールに従って完全に有効ではない場合 (例えば、証明書または事前証明書が期限切れであったり、まだ有効でなかったり、失効していたり、ASN.1 DER エンコーディングエラーを示しているがログはまだそれを解析できたり、など)、提出の受理可能性はログの裁量に委ねられる。このような提出を受理することは、CA 証明書発行ソフトウェアの癖 (個性) に対応し、提供可能なポリシーおよび技術標準に対する CA のコンプライアンスの監視を促進するために有用である。しかし、この文書が [RFC5280] に準拠しない可能性のあるすべての方法を列挙し、ログがそれらを考慮することは非現実的である。

ログは受理するチェーンの長さを制限すべきである。最大チェーン長はログのパラメータの 1 つである (セクション 4.1 参照)。

4.3 ログエントリ

提出が受理され SCT が発行された場合、それを受理したログは検証に使用された完全なチェーンを保持しなければならない。このチェーンには、証明書または事前証明書、提出者によって提出された 0 個以上の中間 CA 証明書、および (提出から省略された場合であっても) チェーンの検証に使用された信頼アンカーを含まなければならない。ログは、CA が部分的または空のチェーンをログに記録することで責任を回避されないように、監査の要求に応じてこのチェーンを提供しなければならない (セクション 5.6 参照)。

各ログエントリは x509_entry_v2 または precert_entry_v2 型の TransItem 構造である。ただし、ログはそのエントリを任意の形式で保存してもよい。ログがこの TransItem を完全に保存しない場合、対応する TimestampedCertificateEntryDataV2 構造の timestamp および sct_extensions を保存しなければならない。TransItem は、これらのフィールドと、ログが提出の検証に使用した完全なチェーンから再構築できる。

4.4 ログ ID

各ログは OID によって識別される。これはログパラメータの 1 つであり (セクション4.1 参照)、他のいかなるログを識別するためにも使用されてはならない。ログのオペレータは、OID を自分で割り当てるか、ログ ID レジストリ (セクション 10.2.5 参照) へ要求しなければならない。

OID を割り当てることのできる OID アークを取得する 1 つの方法は登録フォームに記入して IANA から民間企業番号 (Private Enterprise Number) を要求することである。レジストリの唯一の利点は DER エンコーディングが小さくなることである。(OID の割り当てには中央登録局が必要ないことを思い出して欲しいが、ログは帯域外の手段で潜在的なクライアントに自分たちの存在を知らせたい場合がほとんどだろう。) 様々なデータ構造には ASN.1 タグおよび長さバイトを除いた、この OID の DER エンコーディングを不透明なベクトルに含む:

opaque LogID<2..127>;

ASN.1 の長さと不透明ベクトルの長さはサイズ (1 バイト) と値が同一であるため、OID の完全な DER エンコーディング (タグと長さを含む) は、単に OBJECT IDENTIFIER タグ (0x06) を不透明ベクトルの長さと内容の前に付加することで再現できることに注意。

ログを識別するために使用する OID は、そのタグと長さを除いた値の DER エンコーディングが 127 オクテット以下でなければならないように制限される。

4.5 TransItem 構造

様々なデータ構造は、それぞれの型とバージョンが共通の方法で識別されることを保証するために TransItem 構造にカプセル化される。

enum {
  x509_entry_v2(0x0100),
  precert_entry_v2(0x0101),
  x509_sct_v2(0x0102),
  precert_sct_v2(0x0103),
  signed_tree_head_v2(0x0104),
  consistency_proof_v2(0x0105),
  inclusion_proof_v2(0x0106),

  /* 予約済みコードポイント */
  reserved_rfc6962(0x0000..0x00FF),
  reserved_experimentaluse(0xE000..0xEFFF),
  reserved_privateuse(0xF000..0xFFFF),
  (0xFFFF)
} VersionedTransType;

struct {
  VersionedTransType versioned_type;
  select (versioned_type) {
    case x509_entry_v2: TimestampedCertificateEntryDataV2;
    case precert_entry_v2: TimestampedCertificateEntryDataV2;
    case x509_sct_v2: SignedCertificateTimestampDataV2;
    case precert_sct_v2: SignedCertificateTimestampDataV2;
    case signed_tree_head_v2: SignedTreeHeadDataV2;
    case consistency_proof_v2: ConsistencyProofDataV2;
    case inclusion_proof_v2: InclusionProofDataV2;
  } data;
} TransItem;

versioned_type はセクション 10.2.3 の IANA レジストリからの値であり、カプセル化されたデータ構造の型と、それが準拠するこのプロトコルの最も古いバージョンを識別する。この文書は v2 である。

data はカプセル化されたデータ構造である。DataV2 という接尾辞を持つ様々な構造はこの文書の後のセクションで定義される。

VersionedTransType は v1 の列挙型である。Version、LogEntryType、SignatureType、および MerkleLeafType [RFC6962] を組み合わせていることに注意。また v1 は TransItem を定義していなかったが、この文書は v2 実装が v1 実装と共存する方法についてのガイドライン (付録 A 参照) を提供する。

このプロトコルの将来のバージョンは、対応するデータ構造が変更されない限り、この文書で定義された VersionedTransType 値を再利用することができ、新規または変更されたデータ構造のために新しい VersionedTransType を追加してもよい。

4.6 ログアーティファクト拡張

enum {
  reserved(65535)
} ExtensionType;

struct {
  ExtensionType extension_type;
  opaque extension_data<0..2^16-1>;
} Extension;

Extension 構造体は SCT (セクション 4.8) や STH (セクション 4.10) を含むアーティファクトに対する汎用的な拡張性を提供する。extension_data フィールドの解釈は extension_type の値によってのみ決定する。

この文書は拡張を定義していないが、将来の ExtensionType 値のためのレジストリを確立している (セクション10.2.4 参照)。新しい ExtensionType を登録する各文書は、それが使用される可能性のあるコンテキスト (例えば SCT、STH、またはその両方) を指定し、対応する extension_data の解釈方法を記述しなければならない。

4.7 マークルグリーの葉

ログのマークルツリーの葉はログのエントリに対応する (セクション 4.3 参照)。各葉は、TimestampedCertificateEntryDataV2 構造をカプセル化する x509_entry_v2 または precert_entry_v2 型の TransItem 構造の葉ハッシュ (セクション 2.1) である。葉ハッシュは \({\rm HASH}({\tt 0x00}\,||\,{\rm TransItem})\) として計算されることに注意。ハッシュアルゴリズムはログのパラメータの 1 つである。

opaque TBSCertificate<1..2^24-1>;

struct {
  uint64 timestamp;
  opaque issuer_key_hash<32..2^8-1>;
  TBSCertificate tbs_certificate;
  Extension sct_extensions<0..2^16-1>;
} TimestampedCertificateEntryDataV2;

timestamp は証明書または事前証明書がログによって受理された日時で、Unix エポック (1970 年 1 月 1 日 00:00:00 UTC -- [UNIXTIME] 参照) から経過したミリ秒を示す 64 ビット符号なし数値の形式であり、うるう秒を無視したネットワークバイトオーダーである。ログのマークルツリーの葉は厳密な時系列順序である必要はないことに注意。

issuer_key_hash は証明書または事前証明書を発行した CA の公開鍵の \({\rm HASH}\) であり、SubjectPublicKeyInfo [RFC5280] として表現された鍵の DER エンコードに対して計算される。これは、CA を証明書または事前証明書に束縛するために必要であり、対応する STH が、tbs_certificate と一致する TBSCertificate を持つ他の証明書または事前証明書に対して有効になることを不可能にする。issuer_key_hash の長さは \({\rm HASH\_SIZE}\) と一致しなければならない。

tbs_certificate は提出からの DER エンコードされた TBSCertificate である (事前証明書の TBSCertificate は、セクション 8.1.2 に記載されているように、対応する証明書から再構築できることに注意)。

sct_extensions は対応する SCT の SCT 拡張とバイト単位で同一である。

TransItem の型はセクション 5.1 の呼び出しで提供された type パラメータの値に対応する。

4.8 署名付き証明書タイムスタンプ (SCT)

SCT は SignedCertificateTimestampDataV2 構造をカプセル化する x509_sct_v2 または precert_set_v2 型の TransItem 構造である:

struct {
  LogID log_id;
  uint64 timestamp;
  Extension sct_extensions<0..2^16-1>;
  opaque signature<1..2^16-1>;
} SignedCertificateTimestampDataV2;

log_id は、セクション 4.4 に記載されているように、このログの不透明なベクトルにエンコードされた一意の ID である。

timestamp は対応する TimestampedCertificateEntryDataV2 構造からの timestamp と等しい。

sct_extensions は 0 個以上の SCT 拡張のベクトルである。このベクトルは同じ extension_type を持つ複数の拡張を含んではならない。ベクトル内の拡張は extension_type フィールドの値によって純度づけなければならず、最小値が最初である。すべての SCT 拡張は非クリティカルな X.509v3 拡張と同様である (すなはち mustUnderstand フィールドは設定されていない)。受信者は理解できない拡張を無視すべきである。さらに、実装は理解できる拡張を無視することを選択してもよい。

signature は、ログのパラメータで宣言されている署名アルゴリズムを使用して (セクション 4.1 参照)、x509_entry_v2 または precert_entry_v2 型の TransItem 構造 (セクション 4.7 参照) に対して計算される。

4.9 マークルツリーのヘッド

ログは、そのマークルツリーに関する情報を TreeHeadDataV2 に保存する:

opaque NodeHash<32..2^8-1>;

struct {
  uint64 timestamp;
  uint64 tree_size;
  NodeHash root_hash;
  Extension sth_extensions<0..2^16-1>;
} TreeHeadDataV2;

NodeHash の長さはログの \({\rm HASH\_SIZE}\) と一致しなければならない。

timestamp はセクション 4.7 で定義された形式を使用した現在の日時である。

tree_size はログのマークルツリーに現在含まれているエントリ数である。

root_hash はマークルツリーのルートである。

sth_extensions は 0 個以上の STH 拡張のベクトルである。このベクトルは同じ extension_type を持つ複数の拡張を含んではならない。ベクトル内の拡張は extension_type フィールドの値によって順序付けられなければならず、最小値が最初である。実装が理解できない拡張を観測した場合、その拡張を無視すべきである。さらに、実装は理解できる拡張を無視することを選択してもよい。

4.10 署名付きツリーのヘッド (STH)

各ログは定期的に現在のツリーのヘッド情報 (セクション 4.9 参照) に署名して STH を生成すべきである。クライアントがログの最新の STH を要求した場合 (セクション 5.2 参照)、ログはログの MMD よりも古くない STH を返されなければならない。

しかし、STH はここのクライアントをマークするために使用される可能性があるため (各クエリに対して新しい STH を生成することに良いって)、ログはそのパラメータで宣言された頻度よりも頻繁に STH を生成してはならない (セクション 4.1 参照)。一般に、ログに新しいエントリがない限り新しい STH を生成する必要はない。ただし、ログが MMD 期間中に提出を受け付けない場合、ログは同じマークルツリーハッシュに新しいタイムスタンプで署名しなければならない。

STH は SignedTreeHeadDataV2 構造をカプセル化する signed_tree_head_v2 型の TransItem 構造である:

struct {
  LogID log_id;
  TreeHeadDataV2 tree_head;
  opaque signature<1..2^16-1>;
} SignedTreeHeadDataV2;

log_id は、セクション 4.4 に記載されているように、このログの不透明なベクトルにエンコードされた一意の ID である。

tree_head の timestamp は、ツリーの中の最新の SCT タイムスタンプと少なくとも同じ新しさでなければならない。各後続のタイムスタンプは前回の更新のタイムスタンプよりも新しくなければならない。

tree_head は最新のツリーのヘッド情報を含む (セクション 4.9 参照)。

signature はログのパラメータで宣言された署名アルゴリズムを使用して (セクション 4.1 参照) tree_head フィールドに対して計算される。

4.11 マークル整合性証明

クライアントへの配布用のマークル整合性証明を準備するために、ログは ConsistencyProofDataV2 構造をカプセル化する consistency_proof_v2 型の TransItem 構造を生成する:

struct {
  LogID log_id;
  uint64 tree_size_1;
  uint64 tree_size_2;
  NodeHash consistency_path<0..2^16-1>;
} ConsistencyProofDataV2;

log_id は、セクション 4.4 に記載されているように、このログの不透明なベクトルにエンコードされた一意の ID である。

tree_size_1 は古い木のサイズである。

tree_size_2 は新しい木のサイズである。

consistency_path はセクション 2.1.4 に記載されているように 2 つの STH の整合性を証明するマークルツリーノードのベクトルである。

4.12 マークル包含証明

クライアントへの配布用のマークル包含証明を準備するために、ログは InclusionProofDataV2 構造をカプセル化する inclusion_proof_v2 型の TransItem 構造を生成する:

struct {
  LogID log_id;
  uint64 tree_size;
  uint64 leaf_index;
  NodeHash inclusion_path<0..2^16-1>;
} InclusionProofDataV2;

log_id は、セクション 4.4 に記載されているように、このログの不透明なベクトルにエンコードされた一意の ID である。

tree_size はこの包含証明が基づくツリーのサイズである。

leaf_index はこの包含証明に対応するログエントリの 0 から始まるインデックスである。

inclusion_path はセクション 2.1.3 に記載されているように、選択された証明書または事前証明書の包含を証明するマークルツリーノードのベクトルである。

4.13 ログの閉鎖

ログのオペレータは、署名アルゴリズムの廃止などさまざまな理由でログの閉鎖を決定することがある。ログにまだ期限切れになっていない証明書エントリがある場合、TLS クライアントにそのログの認識を停止させると、そのログから SCT が無効化される効果がある。これを回避するために次の措置を講じるべきである。

• ログが凍結されることをクライアントと監視者に知らせる。これは API の一部ではないため、帯域外の関連するメカニズムを介して行う必要がある。

• 新しい提出の受理を停止する (このような要求に対してはエラーコード "shutdown" を返すべきである)。

• 最後に受理された提出から MMD が経過し、すべての保留中の提出が組み込まれたら、最終 STH を発行し、ログのパラメータの 1 つとして公開する。最後の SCT 発行から MMD が経過した後のタイムスタンプを持つ STH を持つことで、クライアントは最終的に STH に対する特別な処理なしにこのログを定期的に監査できる。この時点でログの秘密鍵はもはや必要なくなり破棄できる。

• ログのすべてのエントリ内の証明書が期限切れになるか、他のログに存在するまで、ログを実行し続ける (これは、他のログをスキャンするか、証明書に記載されているドメインに接続して提供される SCT を検査することによって判断できる)。

5 ログクライアントメッセージ

メッセージは HTTPS の GET または POST リクエストして送信される。POST のパラメータとすべてのレスポンスは、JavaScript Object Notation (JSON) オブジェクト [RFC8259] としてエンコードされる。GET のパラメータは "HTML 4.01 Specification" [HTML401] に記載されている "application/x-www-form-urlencoded" 形式を使用し、順序に依存しない Key-Value URL パラメータとしてエンコードされる。バイナリデータは、ここのメッセージで指定されるように [RFC4648] のセクション 4 に従って Base64 エンコードされる。

クライアントはログのベース URL を設定される。これはログのパラメータの 1 つである。クライアントはこのベース URL にサフィックスを追加することでリクエストの URL を構築する。この構造は [RFC8820] に記載されているように、ログのオペレータがこれらのサービスを配備する方法にある程度の制限を課す。しかし、このプロトコルのバージョン 1 での運用経験は、これらの制限が実際には問題でないことを示している。

JSON オブジェクトと URL パラメータには、実験を可能にするためにここで指定されていないフィールドが含まれている場合があることに注意。解釈できないフィールドは無視されるべきである。

実際には、ログサーバは複数のフロントエンドマシンを含む場合がある。これらのマシンを完全に同期させることは非現実的であるため、マシン間のスキューによって引き起こされるエラーが発生する可能性がある。そのようなエラーが起こりうる場合、フロントエンドは追加情報を返し (以下に指定)、可能であればクライアントが進捗できるようにする。フロントエンドはギャップのないデータのみを提供しなければならない (つまり、例えばフロントエンドはその STH に記録されたすべてのログエントリから一貫性を証明できない限り STH で応答しない)。

例えば、2 つの STH 間の整合性証明が要求された場合、到達したフロントエンドはどちらか一方または両方の STH をまだ認識してない可能性がある。両方を認識していない場合、認識している最新の STH を返す。最初の STH は認識しているが 2 番目の STH を認識していない場合、認識している最新の STH と、最初の STH から返された STH への整合性証明を返す。2 番目の STH は知っているが最初の STH を知らないケースは発生すべきではない (上記の「ギャップなし」要件を参照)。

ログがクライアントのリクエストを処理できない場合、4xx/5xx の HTTP レスポンスコードを返さなければならず ([RFC7231] 参照)、以下のサブセクションで概説されるレスポンスの代わりに、本文は以下を含む JSON Problem Detail オブジェクト ([RFC7807] のセクション 3 参照) であるべきである。

• type: 問題を識別する URN 参照。エラーに対する自動応答を促進するために、この文章では "urn:ietf:params:trans:error:" という URN 名前空間内で type フィールドで使用するための標準トークンのセットを定義する。

• detail: ログがリクエストを処理できなかったエラーを説明する人が読める形式の文字列。理想的には、エラーを修正できるように十分な詳細を含む。

例えば <Base URL>/ct/v2/get-entries?start=100&end=99 というリクエストに対してログは次のような本文を持つ 400 Bad Request レスポンスコードを返す:

{
  "type": "urn:ietf:params:trans:error:endBeforeStart",
  "detail": "'start' cannot be greater than 'end'"
}

ほとんどのエラータイプはリクエストのタイプに固有であり、以下のそれぞれのサブセクションで定義される。1 つの例外は "malformed" エラータイプであり、これはログサーバがこの文書に準拠していないためクライアントのリクエストを解析できなかったことを示す:

クライアントは 500 Internal Server Error および 503 Service Unavailable レスポンスを一時的な障害として扱うべきであり、後に同じリクエストを変更なしで再試行することができる。503 レスポンスの場合、ログは [RFC7231] に従って Retry-After ヘッダを含めることができ、クライアントがリクエストを再試行する前に待機する最小時間を要求しても良い。このヘッダフィルードがない場合、この文章は最小時間を指定しない。

クライアントは 4xx エラーをリクエストの問題として扱うべきであり、リクエストに何らかの変更を加えずに再提出を試みるべきではない。完全なステータスコードが追加の詳細を提供することがある。

この文書は、意図的に HTTP ステータスコードの使用に関するより具体的なガイダンスを提供しない。

5.1 ログエントリに提出

POST <Base URL>/ct/v2/submit-entry

• 入力:

  • submission: Base64 エンコードされた証明書または事前証明書。

  • type: submission の型を示す VersionedTransType 整数値。x509_entry_v2 の場合は 1、precert_entry_v2 の場合は 2。

  • chain: 0 個以上の JSON 文字列の配列。各文字列はエンコードされた CA 証明書である。最初の要素は submission の承認者であり、2 番目の要素は最初の要素を認証する、といった具合である。chain の最後の要素 (または chain が空の配列である場合は submission) は、受理された信頼アンカーによって承認される。

• 出力:

  • sct: このログによって署名された、submission に対応する x509_sct_v2 または precert_sct_v2 型の Base64 エンコードされた TransItem。

  提出されたエントリがこのログのツリーに即座に追加される場合 (または既に存在する場合)、ログは次も出力すべきである:

  • sth: このログの最新の STH。signed_tree_head_v2 型の Base64 エンコードされた TransItem。

  • inclusion: submission の sth への包含を証明する、inclusion_proof_v2 型の Base64 エンコードされた TransItem。

• エラーコード:

  type	detail
  badSubmission	submission が有効な証明書でも有効な事前証明書でもありません。
  badType	type が 1 でも 2 でもありません。
  badChain	chain の最初の要素が submission の承認者ではない、または 2 番目の要素が最初の要素を承認していない、など
  badCertificate	chain 内の 1 つ以上の証明書が有効ではありません (例: 適切にエンコードされていない)。
  unknownAnchor	chain の最後の要素 (または chain が空の配列の場合は submission) が、受理された信頼アンカーではなく、また受理された信頼アンカーによって承認されていません。
  shutdown	ログは提出を受け付けなくなりました。

sct のバージョンが v2 でない場合、v2 クライアントは署名を検証できない可能性がある。これをエラーとして解釈してはならない。これは、返された SCT を使用しない v2 準拠クライアントの強制的なアップグレードを回避するためである。

ログが、チェーン内の不正なエンコーディング以外は正しく検証されるエンコーディングを検出した場合、ログは証明書をログに記録するか "badCertificate" エラーを返さなければならない。証明書がログに記録された場合、SCT を発行しなければならない。証明書をログに記録することは有用である。なぜなら、監視者 (セクション 8.2) がこれらのエンコーディングエラーを検出でき、一部の TLS クライアントによって受理される可能性があるからである。

もし、submission がログによって信頼アンカーとして受理されている証明書であり、その発行者が別の受理済み信頼アンカーでなく、かつ証明書チェーンの最初の要素でもない場合、ログは "unknownAnchor" エラーを返されなければならない。ログは、発行者の公開鍵にアクセスできない場合、submission に対する SCT を生成できない。

返された sct を TLS クライアントに提供する意図がある場合、sth および inclusion (もし返された場合) も TLS クライアントに提供されるべきである。例えば type が 2 (つまり precert_sct_v2 を示す) であった場合、3 つの TransItem すべてを証明書に埋め込むことができる。

5.2 最新の署名済みツリーヘッドの取得

POST <Base URL>/ct/v2/get-sth

• 入力: なし
• 出力:

  • sth: このログによって署名された、ログの MMD より古くない signed_tree_head_v2 タイプの Base64 エンコードされた TransItem。

5.3 2 つの STH 間のマークル整合性証明の取得

POST <Base URL>/ct/v2/get-sth-consistency

• 入力:

  • first: 古い方の tree_size (10 進数)。

  • second: 新しい方の tree_size (10進数, オプション)。

  両方のツリーサイズ葉、既存の v2 STH からのものでなければならない。ただし、受信側のフロントエンドはスキューのために既存の STH の一方または両方を知らない可能性がある。両方が既知の場合、consistency 出力のみが返される。first は既知だが second が既知ではない場合 (または省略された場合)、最新の既知の STH と、first の STH と最新の STH との間の整合性証明とともに返される。いずれも既知でない場合、最新の既知の STH が整合性証明なしで返される。

• 出力:

  • consistency: Base64 エンコードされた consistency_proof_v2 型の TransItem。この tree_size_1 は入力と一致しなければならない。sth 出力が省略されている場合、tree_size_2 は second 入力と一致しなければならない。first と second が等しく、既知の STH に対応する場合、返される整合性証明は空 (要素数が 0 の consistency_path 配列) でなければならない。

  • sth: このログによって署名された、Base64 エンコードされた signed_tree_head_v2 型の TransItem。

  consistency 出力には署名は必要ないことに注意。これは、2 つの署名済み STH 間の整合性を検証するために使用されるためである。

• エラーコード:

  type	detail
  firstUnknown	first は最新の既知の STH より前であるが、既存の STH からのものではない。
  secondUnknown	second は最新の既知の STH より前であるが、既存の STH からのものではない。
  secondBeforeFirst	second が first より小さい。

consistency 出力の使用方法の概要についてはセクション 2.1.4.2 参照。

5.4 葉ハッシュによるログからのマークル包含証明の取得

POST <Base URL>/ct/v2/get-proof-by-hash

• 入力:

  • hash: Base64 エンコードされた v2 葉ハッシュ。

  • tree_size: 証明の基礎とするツリーの tree_size (10 進数)。

  hash はセクション 4.7 で定義されているように計算されなければならない。tree_size に対して v2 STH が存在しなければならない。スキューによって、フロントエンドは要求されたツリーヘッドを知らない可能性がある。その場合、フロントエンドは、既知の最新の STH と、その STH への包含証明を返す。フロントエンドが要求されたツリーヘッドを知っている場合は inclusion のみが返される。

• 出力:

  • inclusion: Base64 でエンコードされた inclusion_proof_v2 型の TransItem。この inclusion_path 配列のマークルツリーノードは、選択された STH 内の証明書 (hash パラメータで指定される) の包含を証明する。

  • sth: このログによって署名された、Base64 エンコードされた signed_tree_head_v2 型の TransItem。

  inclusion 出力には署名が必要ないことに注意。これは、署名されている選択された STH に含まれていることを確認するために使用されるためである。

• エラーコード:

  type	detail
  hashUnknown	hash は既知のリーフのハッシュではない (スキューによって、または既知の証明書がまだマージされて居ことによって引き起こされる可能性がある)。
  treeSizeUnknown	hash は最新の既知の STH より前であるが、既存の STH からのものではない。

consistency 出力の使用方法の概要についてはセクション 2.1.4.2 参照。

5.5 葉ハッシュによるマークル包含証明、STH、および整合性証明の取得

POST <Base URL>/ct/v2/get-all-by-hash

• 入力:

  • hash: Base64 エンコードされた v2 葉ハッシュ。

  • tree_size: 証明の基礎とするツリーの tree_size (10 進数)。

    hash はセクション 4.7 で定義されているように計算されなければならない。tree_size に対して v2 STH が存在しなければならない。

  スキューによって、フロントエンドは要求されたツリーヘッドまたは要求されたハッシュを認識できない可能性があり、次のようなケースが発生する:

  ケース	応答
  最新の STH < 要求されたツリーヘッド	最新の STH を返す。
  最新の STH > 要求されたツリーヘッド	最新の STH と、それを要求されたツリーヘッドの間の整合性証明を返す (セクション 5.3 参照)。
  最新の STH にハッシュが含まれている	inclusion を返す。

  複数のケースが真となる可能性があることに注意。その場合、返されるデータはそれらの和集合である。いずれも真ではない可能性もある。その場合、フロントエンドは空の応答を返されなければならない。

• 出力:

  • inclusion: Base64 でエンコードされた inclusion_proof_v2 型の TransItem。この inclusion_path 配列のマークルツリーノードは、選択された STH 内の証明書 (hash パラメータで指定される) の包含を証明する。

  • sth: このログによって署名された、Base64 エンコードされた signed_tree_head_v2 型の TransItem。

  • consistency: Base64 でエンコードされた consistency_proof_v2 型の TransItem。要求されたツリーヘッドと返された STH の整合性を証明する。

  inclusion または consistency 出力には署名が必要ないことに注意。これは、署名されている選択された STH に含まれていることを確認するために使用されるためである。

エラーはセクション 5.4 と同じである。

inclusion 出力の使用方法の概要についてはセクション 2.1.3.2 参照。また、consistency 出力の使用方法の概要についてはセクション 2.1.4.2 参照。

5.6 ログからエントリと STH の取得

POST <Base URL>/ct/v2/get-entries

• 入力:

  • start: 取得する最初のエントリのインデックス (0 から始まる 10 進数)。

  • end: 取得する最後のエントリのインデックス (0 から始まる 10 進数)。

• 出力:

  • entries: オブジェクトの配列。各オブジェクトは以下で構成される:

    • log_entry: Base64 エンコードされた x509_entry_v2 または precert_entry_v2 型の TransItem 構造体 (セクション 4.3 参照)。
    • submitted_entry: submit-entry に送信された入力と同等の JSON オブジェクト。送信に含まれていなかった場合は chain フィールドに信頼アンカーが追加される。

    • sct: このログによって署名された、Base64 エンコードされた x509_sct_v2 または precert_sct_v2 型の TransItem。

    • sth: このログによって署名された、Base64 エンコードされた singed_tree_head_v2 型の TransItem。

このメッセージは署名されていないことに注意。entries データは、取得した STH に対応するマークルツリーハッシュを構築することでデータを検証できる。すべての葉は v2 でなければならない。ただし、v2 準拠のクライアントは認識できない TransItem 型をエラーと解釈してはならない。これは、一部のエントリを解析できない可能性があることを意味するが、各クライアントは認識するエントリを検査でき、認識されない葉をツリーへの不透明な入力として扱うことによってデータの整合性を検証できることに注意。

start と end パラメータは、セクション 5.2 の get-sth によって返される tree_size から 0 ≦ x < tree_size の範囲内であるべきである。

start パラメータは end パラメータ以下でなければならない。

各 submitted_entry 出力パラメータには、その信頼アンカーが submit-entry に提供されなかった場合でも (セクション 5.1 参照)、ログが submission の検証に使用した信頼アンカーを含まなければならない。

ログサーバは、0 ≦ start < tree_size かつ end ≧ tree_size のリクエストに対して、指定された範囲内の有効なエントリのみを含む部分的な応答を返すことで処理しなければならない。end ≧ tree_size はスキューによって引き起こされる可能性がある。以下の制限も適用される可能性があることに注意:

ログは get-entries リクエストごとに取得できるエントリ数を制限することができる。クライアントが許可された数を超えるエントリを要求した場合、ログは許可される最大数のエントリを返すものとする。これらのエントリは start で指定されたエントリから始まる連続したものとする。エントリ数の制限は不変ではなく、したがって制限はいつでも変更または解除される可能性があり、セクション 4.1 の他のログパラメータとともにリストされていないことに注意。

スキューの影響によりログサーバが start と end の間にエントリを持たない可能性がある。この場合、空の entries 配列を返さなければならない。

いずれの場合でも、ログサーバは認識している最新の STH を返さなければならない。

log_entry のエントリの完全なリストを使用して root_hash を検証する方法の概要については、セクション 2.1.2 を参照。

• エラーコード:

  type	detail
  startUnknown	start がマークルツリー内のエントリ数より大きい。
  endBeforeStart	start は end より大きい値は指定できない。

5.7 受理された信頼アンカーの取得

POST <Base URL>/ct/v2/get-anchors

• 入力: なし
• 出力:

  • certificate: JSON 文字列の配列。各文字列は、ログが受理可能な Base64 エンコードされた CA 証明書である。

  • max_chain_length: サーバが受理できるチェーンの長さを制限している場合、これはチェーン内の証明書の最大数 (10 進数) である。制限がない場合、この値は省略される。

  このデータは署名されておらず、プロトコルは正確性を保証するために TLS のセキュリティ保障に依存している。

6 TLS サーバ

CT に対応する TLS サーバは、クライアントの要求があったとき、TLS の完全なハンドシェイクの中で、サーバ証明書に対応する SCT を提示する必要がある。このとき、提示方法は RFC で定義された複数の仕組みのうち少なくとも 1 つを用いなければならない。(もちろん、サーバはクライアントが最初にそれを指定して場合にのみ TLS 拡張を送信できる。) サーバは対応する包含証明と STH も提示すべきである。

サーバは [RFC8446] のセクション 4.2 で定義された TLS 1.3 拡張を使用して transparency_info 型で SCT を提供できる (セクション6.5 参照)。このメカニズムにより、TLS サーバは他の二つのメカニズムとは異なり、CA の協力成しに CT に参加できる。また、SCT と包含証明をその場で更新することもできる。

サーバはオンライン証明書ステータスプロトコル (OCSP; Online Certificate Status Protocol) [RFC6960] レスポンス拡張 (セクション 7.1.1 参照) を使用し、TLS ハンドシェイクの一部として OCSP レスポンスを提供することができる。TLS ハンドシェイク中にレスポンスを提供することは一般に "OCSP stapling" として知られている。TSL 1.3 の場合、情報は status_request 拡張データ内の拡張としてエンコードされる ([RFC8446] のセクション 8 参照)。stapling を使用することで SCT と包含証明をその場で更新することもできる。

CT 情報は X.509v3 証明書内の拡張としてエンコードすることもできる (セクション 7.1.2 を参照)。このメカニズムにより変更されていない TLS サーバの使用が可能になるが、SCT と包含証明をその場で更新することはできない。SCT と包含証明の起源となったログが、証明書の全存続期間にわたって TLS クライアントによって受理されるとは限らないため、TLS クライアントがその後証明書を非準拠と見なすリスクがある。そのような事態が発生した場合、CT 情報を配信するために他の 2 つのメカニズムのいずれかを使用する必要があるか、それが不可能な場合は証明書を再発行する必要がある。

6.1 TLS クライアント認証

この仕様には TLS サーバが TLS クライアント証明書に対して CT を使用する方法は含まれていない。これは有用かもしれないが、次の理由によりここには明部かされていない:

• より大きなセキュリティ上の懸念は、クライアントが不正な (illegitimate) サーバと対話することになることである。

• 一般に、TLS クライアント証明書は CT ログに提出されることは期待されておらず、特に一般公開を意図したものには提出されない。

6.2 複数の SCTs

CT を使用する TLS サーバは、複数のログから SCT を送信すべきである。その理由は以下の通り:

• TLS クライアントによって信頼されるログのセットは統一されておらず静的でもない。各クライアントベンダーは独立した信頼されるログのリストを保持している可能性があり、時間の経過と共に新しいログが信頼されるようになり、現在のログが信頼されなくなる可能性がある。クライアントによるログの発見、信頼、不信は帯域外で処理されることが期待されており、この文書の範囲外であることに注意。

• CA とログが共謀すれば、クライアントから一時的に不正発行を隠すことが可能である。TLS クライアントが複数のログから SCT の提供を要求する場合、この攻撃を実行することはより困難になる。

• ログが不正動作をしたり鍵の漏洩を被った場合、結果としてクライアントがそれを信頼しなくなる可能性がある。SCT が使用される期間は相当に長くなる可能性があるため (証明書に埋め込まれている場合、現在の実務では数年が一般的)、複数のログから SCT を含めることで、証明書が TLS クライアントによって拒否される確率が低下する。

• TLS クライアントは、上記のリスクに関連するポリシーを持ち、TLS サーバに複数の SCT の提示を要求する場合がある。例えば、この文書の執筆時点では Chromium [Chromium.Log.Policy] は EV インジケーターを表示するために、拡張検証 (Extended Validation, EV) 証明書と共に複数の SCT を提示することを要求している。

SCT を取得するログを選択するために、例えば TLS サーバは一般的な TLS クライアントが受理し認識するログのセットを調査できる。

6.3 TransItemList 構造

複数の SCT、包含証明、および実際にはあらゆる型の TransItem 構造は次のようにリストに結合される。

opaque SerializedTransItem<1..2^16-1>;

struct {
  SerializedTransItem trans_item_list<1..2^16-1>;
} TransItemList;

ここで SerializedTransItem はシリアライズされた TransItem 構造を含む不透明なバイト列である。このエンコーディングにより、TLS クライアントは各 TransItem を個別にデコードできることが保証される (したがって、例えばバージョンアップグレードがある場合、古い TransItem 構造を解析しながら解釈できないバージョンの新しい TransItem 構造をスキップすることができる)。

6.4 SCT、包含証明、および STH の提示

TLS ハンドシェイク中に送信される各 TransItemList において、TLS サーバは x509_sct_v2 または precert_sct_v2 型の TransItem 構造を含まなければならない。

TLS ハンドシェイクで包含証明と STH を提示することは、クライアントのプライバシーを保護し (セクション 8.1.4 参照)、ログサーバへの負荷を軽減するのに役立つ。したがって、TLS サーバがそれらを取得できる場合、TransItemList に inclusion_proof_v2 および signed_tree_head_v2 型の TransItem も含めるべきである。

6.5 transparency_info TLS 拡張

TLS クライアントが ClientHello に transparency_info 拡張型を含め、TLS サーバが transparency_info 拡張をサポートしている場合:

• TLS サーバは、受信した extension_data が空であることを検証しなければならない。

• TLS サーバは、関連する TransItem の TransItemList を構築しなければならず (セクション 6.4 参照)、サーバ証明書または stapled OCSP レスポンスに既に埋め込まれている TransItem は省略すべきである (セクション 7.1 参照)。構築された TransItemList が空でない場合、TLS サーバは、extension_data をこの TransListItem に設定して transparency_info 拡張を含まなければならない。リストが空の場合、サーバは extension_data 要素を省略すべきであるが、空の配列を送信することができる。

TLS サーバは次のメッセージにのみこの拡張を含まなければならない:

• ServerHello メッセージ (TLS 1.2 以前の場合)

• Certificate または CertificateRequest メッセージ (TLS 1.3 の場合)

TLS サーバは、セッションの再開は元のセッション情報を使用するため、TLS セッションが再開される場合にこの拡張を処理したり含めたりしてはならない。

7 証明書認証局

7.1 透明性情報 X.509v3 拡張

OID が 1.3.101.75 を持つ透明性情報 X.509v3 拡張は、原則として非クリティカル (noncritical) とすべきである。この拡張は TransLimitList 構造体の中に 1 個以上の TransItem 構造体を含む。この拡張は OCSP レスポンス (セクション 7.1.1 参照) および証明書 (セクション 7.1.2 参照) のいずれかに含めることができる。[RFC5280] では、X.509v3 拡張の extnValue フィールド (型は OCTET STRING) には ASN.1 値の DER 符号化を格納しなければならないと定めている。したがって TransItemList を直接そのまま格納してはならない。代わりに TransItemList を追加の OCTET STRING で包み、その外側の OCTET STRING を extnValue フィールドに格納しなければならない:

TransparencyInformationSyntax ::= OCTET STRING

TransparencyInformationSyntax は TransItemList を含んでいる。

7.1.1 OCSP レスポンス拡張

認証局は OCSP レスポンス内の singleResponse の singleExtensions フィールドに透明性情報 X.509v3 拡張を含めることができる。この拡張に含まれるすべての SCT および包含証明は、該当 SingleResponse の certID によって識別される証明書、またはそれに対応する事前証明書に対応するものでなければならない。

7.1.2 証明書拡張

認証局は、発行する証明書の中に証明書透明性情報拡張を追加することができる。ただし、その中に含める SCT や包含証明は必ずこの証明に対応する事前証明書に関する者でなければならない。

7.2 TLS 機能 X.509v3 拡張

認証局は TLS 機能拡張 [RFC7633] の中で transparency_info TLS 拡張を識別する証明書を発行すべきではない。これは、TLS サーバが CT に参加するために transparency_info TLS 拡張をサポートする必要がないためである (セクション 6 参照)。

8 クライアント

ログの楽アインとが実行する可能性のある機能にはさまざまなものがある。ここでは、いくつかの典型的なクライアントと、それらがどのように機能すべきかを説明する。ログに何らかの不整合があれば、ログが正しく動作しなかったことの証拠として使用される可能性があり、データ構造上の署名によりログはその不正な動作を否定することができない。

すべてのクライアントはログと通信してその応答を検証するためにさまざまなパラメータを必要とする。これらのパラメータはセクション 4.1 で説明されているが、この文書ではpらメータの取得方法については説明しない。これは実装依存である (例えば [Chromium.Policy] 参照)。

8.1 TLS クライアント

8.1.1 SCT と包含証明の受信

TLS クライアントは、証明書と共に、または証明書内で SCT と包含証明を受け取る。CT を使用する TLS クライアントは、TLS サーバが SCT を提示する可能性のある 3 つのメカニズムのすべてを実装しなければならない (セクション 6 参照)。

TLS 拡張をサポートする transparency_info TLS クライアント (セクション 6.5 参照) をサポートする TLS クライアントは ClientHello メッセージに空の extension_data を含めるべきである。TLS サーバが TLS セッションの再開時に transparency_info TLS 拡張を含めた場合、TLS クライアントはハンドシェイクを中止しなければならない。

8.1.2 TBSCertificate の再構築

証明書に対する SCT の検証 (TransItem の type が x509_sct_v2 である場合) では、証明書の変更されていない TBSCertificate コンポーネントを使用する。

事前証明書の SCT (TransItem の type が precert_sct_v2 である場合) を検証する前に、証明書の TBSCertificate コンポーネントから事前証明書の TBSCertificate コンポーネントを以下のように再構成する必要がある:

• 透過性情報拡張 (セクション 7.1 参照) を削除する。

• OID 1.3.6.1.4.1.11129.2.4.2 で識別される埋め込み v1 SCT を削除する ([RFC6962] のセクション 3.3 参照)。これにより、埋め込まれた v1 と v2 の SCT が証明書内に共存できるようになる (付録 A 参照)。

8.1.3 SCT の検証

受信した SCT を使用するためには、TLS クライアントはまず次のようにそれを検証しなければならない:

• SCT の TransItem 型に応じて x509_entry_v2 または precert_entry_v2 型の TransItem を構築することにより署名入力を計算する。TimestampedCertificateEntryDataV2 構造体は次のように構築される:

  • timestamp は SCT からコピーされる。

  • tbs_certificate は、セクション 8.1.2 で説明されているように、サーバ証明書の TBSCertificate 部分である。

  • issuer_key_hash はセクション 4.7 で説明されているように計算される。

  • sct_extensions は SCT からコピーされる。

• log_id で識別される、対応するログの公開鍵を使用して、計算された署名入力に対して SCT の signature を検証する。必要な署名アルゴリズムはログのパラメータの 1 つである。

TLS クライアントが対応するログパラメータを持っていない場合、SCT の検証を試みることはできない。コンプライアンスを評価する際 (セクション 8.1.6 参照)、TLS クライアントは検証できた SCT のみを考慮する。

SCT の検証は、サーバ証明書とそのチェーンの通常の検証の代替ではないことに注意。

8.1.4 包含証明の取得

TLS クライアントが受信した SCT を検証したがまだ対応する包含証明を持っていない場合、TLS クライアントは get-proof-by-hash (セクション 5.4) または get-all-by-hash (セクション 5.5) を使用してログから直接包含証明書を要求することができる。

ログから直接包含証明を取得すると、クライアントがどの TLS サーバと通信していたかがログに開示されることに注意。これは重大なプライバシーの懸念と見なされる可能性があるため、TLS サーバが包含証明を送信する方が好ましいと考えられる (セクション 6.4 参照)。

8.1.5 包含証明の検証

TLS クライアントが包含証明 (および STH) を受信また取得した場合、提供された STH に対する包含証明の検証に進むべきである。また、TLS クライアントは提供された STH と既知の STH との間の整合性を検証すべきである。

TLS クライアントが SCT より前の STH を保持している場合、監査の過程において、ログから新しい STH を請求し (セクション 5.2)、その後、整合性証明を要求することによってそれを検証することができる (セクション 5.3)。TLS クライアントが get-all-by-hash を使用する場合、既に新しい STH を持っていることに注意。

8.1.6 コンプライアンスの評価

コンプライアンスを達成するために必要な証拠 (SCT、包含証明、またはそれらの組み合わせ) の量と形式、および非コンプライアンスへの対処方法を指定することは、クライアントのローカルポリシー次第である。

TLS クライアントがコンプライアンスを評価できるのは、CT を使用する TLS クライアントにとって実装が必須である 3 つのメカニズムのいずれかによって、TLS サーバに SCT と包含証明を送信する機会を与えた場合のみである (セクション 8.1.1 参照)。したがって、TLS クライアントは ClientHello に transparency_info と status_request の両方の TLS 拡張を含めなかった場合、コンプライアンスを評価してはならない。

8.2 監視者

監視者 (monitor) は、ログを監視しして正しい動作を確認したり、興味のある証明書を探したり、またはその両方を行う。例えば、整合性検証のために新しいエントリを取得する際に、特定ドメイン名に適用されるすべての証明書について報告するように監視者を構成できる。

監視者は、監視するすべてのログのすべての新しいエントリを少なくとも検査しなければならず、ログ全体のコピーを保持することを選択することができる。

既存のエントリをすべて検査するには、監視者はログごとに次の手順を 1 回実行すべきである:

1. 現在の STH を取得する (セクション 5.2)。

2. STH の署名を検証する。

3. STH に対応するツリー内のすべてのエントリを取得する (セクション 5.6)。

4. 該当する場合、各エントリが興味のある証明書かどうかを確認する。

5. 取得したエントリから作成されたツリーが、STH 内のハッシュと同じハッシュを生成することを確認する。

新しいエントリを検査するには、監視者はログごとに次の手順を繰り返し実行すべきである:

1. 現在の STH を取得する (セクション 5.2)。これを STH が変更されるまで繰り返す。実験を可能にするため、この文書ではポーリング頻度を規定しない。

2. STH の署名を検証する。

3. STH に対応するツリー内のすべての新規エントリを取得する (セクション 5.6)。長期間にわたって利用できない場合、これはログ側の不正な動作と見なされるべきである。

4. 該当する場合は、各エントリが雇用実のある証明書であるかどうかを確認する。

5. 次のいずれか:

   1. すべてのエントリの更新されたリストが、新しい STH と同じハッシュを持つツリーを生成することを検証する。

   または、すべてのログエントリを保持していない場合:

   1. 新しい STH と以前の STH の整合性証明を取得する (セクション 5.3)。

   2. 整合性証明を検証する。

   3. 新しいエントリが整合性証明内の対応する要素を生成することを検証する。

6. ステップ 1 から繰り返す。

8.3 監査

監査は、ログの現在公開されている状態が、正常であることが確認されている以前の公開状態から到達可能であること、およびログによって SCT の形式で行った約束が守られていることを保証する。監査は監視者または TLS クライアントによって実行される。

特に、ログの動作にはチェックすべき 4 つの特徴がある:

• 最大マージ遅延 (MMD)

• STH 頻度家運℃

• 追記専用特製

• すべてのクエリ元に提示されるログビューの一貫性

良性で適合性のあるログは、時間の経過と共に一連の STH を公開し、各 STH は以前の STH と以前の STH の公開以降にヨルに取り込まれたエントリから導出される。これは STH の監査を通じて証明できる。TLS クライアントに返された SCT は、付随する証明書と照合し、ログのマークルツリーに対するマークル包含証明を使用するrことで監査できる。

監査が失敗した場合に監査人が取るべき行動は規定されていないが、一般的に、監査が失敗した場合、監査人はログの不正な動作の署名済み証拠を所有していることに注意。

監視者 (セクション 8.2) は、受信した STH の整合性を検証し、各エントリが取得可能であること、および STH が実際にすべての取得されたエントリからツリーを生成した結果であることを確認することによって監査できる。

TLS クライアント (セクション 8.1) は、SCT のタイムスタンプ + 最大マージ遅延以降の日付を持つ任意の STH に対して SCT を検証し、マークル包含証明を要求すること (セクション 5.4) によって監査できる。また、SCT がそれと共に到着したサーバ証明書に対応していること (つまり、ログエントリがその証明書であるか、またはその証明書に対応する事前証明書であるか) も検証できる。

すべてのエンティティに提示されるログビューの整合性の確認は、CT を使用するエンティティのセット間でログの応答を共有する方法を必要とするため、実行がより困難であり、セクション 11.4 で議論されている。

9 アルゴリズムの柔軟性

ログがその存続期間の途中でいずれかのアルゴリズムを変更することはできない:

• 署名アルゴリズム: SCT 署名は有効なままでなければならないため、署名アルゴリズムは追加のみ可能であり、削除できない。

• ハッシュアルゴリズム: ログは、ハッシュアルゴリズムの変更を認識していないクライアントとの後方互換を可能にするために、古いハッシュアルゴリズムと新しいハッシュアルゴリズムの両方をサポートしなければならない。

ログに複数の署名またはハッシュアルゴリズムを許可すると、すべてのデータ構造がそれをサポートする必要があり、クライアントの実装が大幅に複雑になる。これが、この文書でサポートしていない理由である。

稼働中のログで使用されているアルゴリズムを廃止する必要が生じた場合、ログはセクション 4.13 で指定されているように閉鎖されなければならず、新しいログを開始すべきである。まだ期限切れになっておらず、新しい SCT を必要とする閉鎖されたログ内の証明書は、新しいログに提出されるべきであり、そのログから SCT が代わりに使用される。

10 IANA に関する考慮事項

このセクションで言及されている割り当てポリシー基準は [RFC8126] で概説されているポリシーを参照する。

10.1 既存レジストリへの追加

このサブセクションは既存のレジストリへの追加を定義する。

10.1.1 TLS ExtensionType への新しいエントリ

IANA は [RFC8446] で定義されている TLS ExtensionType Values レジストリにに次のエントリを追加して値を割り当てた。

10.1.2 TRANS 用 URN サブ名前空間 (urn:ietf:params:trans)

IANA は [RFC3553] のテンプレートに従って IETF URN Sub-namespace for Registered Protocol Parameter Identifiers レジストリに新しいエントリを追加した:

• レジストリ名: trans
• 仕様: RFC 9162
• リポジトリ: https://www.iana.org/assignments/trans
• インデックス値: 変換不要

10.2 新しい CT 関連レジストリ

IANA は <https://www.iana.org/assignments/> に表示されるリストに新しいプロトコルレジストリ Public Notary Transparency を追加した。

このセクションの残りの部分では新しい Public Notary Transparency レジストリ内に作成されたサブレジストリを定義する。

10.2.1 ハッシュアルゴリズム

IANA は Hash Algorithm という名前のハッシュアルゴリズム値のレジストリを次のように登録した:

Hash Algorithm レジストリは最初は次のように構成される:

指定された専門家は、提案されたアルゴリズムが公開仕様であり、既知の原像攻撃や衝突攻撃がない暗号ハッシュアルゴリズムとして使用するのに適していることを確認すべきである。これらの攻撃はログの完全性を損なう可能性がある。

10.2.2 署名アルゴリズム

IANA は Signature Algorithm という名前の署名アルゴリズム値のレジストリを確立した。

次の記述がレジストリに追加されている:

注記

これは TLS SignatureScheme レジストリのサブセットであり、CT に適したアルゴリズムに限定されている。これの主な利点は TLS ワーキンググループとその専門家の専門知識を活用できることである。

注記

値 0x0403 が 2 回出現する。これは混乱を招くかもしれないが、検証プロセスはどちらのアルゴリズムでも同じであり、署名生成時にどちらを使用するかの選択はログサーバ内部でのみ行われるため問題ない。

Signature Algorithm レジストリには次の登録がある:

Signature Algorithm レジストリは最初は次のように構成される:

指定された専門家は、提案されたアルゴリズムが公開仕様であり、([RFC8446] によって確立された) TLS SignatureScheme レジストリに値が割り当てられており、署名アルゴリズムとして使用するのに適していることを確認すべきである。

10.2.3 VersionedTransType

IANA は VersionedTransTypes という名の VersionedTransType 値のレジストリを確立した:

以下の記述が追加された:

注記

0x0000..0x00FF の範囲は、v1 SCT を v2 SCT およびその他の TransItem 構造特別できるように予約されている。

VersionedTransTypes レジストリの登録は次の通り:

VersionedTransTypes レジストリは最初は次のように構成される:

指定された専門家は、公開仕様をレビューし、実装の相互運用性を保証するのに十分な詳細さがあることを確認すべきである。

10.2.4 Log Artifact Extension

10.2.5 Log ID Registry

10.2.6 CT Error Types

10.3 OID の割り当て

IANA は、この文書の付録 B にある ASN.1 モジュールを識別するために SMI Security for PKIX Module Identifier レジストリからオブジェクト識別子を割り当てた。

11 セキュリティ考察

CA、ログ、およびサーバがここで説明されている動作を実行することにより、TLS クライアントはログと署名済みタイムスタンプを使用して誤発行された証明書を受け入れる可能性を低減できる。サーバが証明書に対して有効な署名済みタイムスタンプを提示した場合、クライアントは、ログがその証明書を公開することにコミットしたことを認識する。これにより、クライアントは証明書の主体として活動する監視者が誤発行に気づき、誤発行された証明書の失効を CA に依頼するなど、何らかの措置を講じる時間があったことを知る。ただし、適切な監視者がログを確認していない場合や、CA が証明書の失効を拒否している場合もあるため、署名済みタイムスタンプはｋろえを保証するものではない。

さらに、TSL クライアントがログに記録されていない証明書を受け入れない場合、サイト所有者はおそらく CA の支援を受けて証明書をログに送信する大きな動機を持つことになり、システム全体の透明性が向上する。

11.1 誤発行された証明書

公開ログに記録されていない、つまり有効な SCT を持たない誤発行された証明書は準拠しているとは見なされない。ログから SCT が取得できる誤発行された証明書は、ログが正しく動作していると仮定すると、最大マージ遅延時間以内に公開ログに表示される。ログは、MMD までの任意の期間の STH を提供することが許可されているため、誤発行された証明書が監査に利用されずに使用できる最大期間は MMD の 2 倍である。

11.2 誤発行証明書の検出

ログ自体は誤発行された証明書を検出するものではなく、ドメイン所有者などの利害関係者がログを監視し、誤発行された証明書が検出されたときに是正措置を講じることに依存している。

11.3 不正動作するログ

ログはさまざまな方法で不正動作を起こす可能性がある。例としては、SCT を持つ証明書を MMD 以内にマークルツリーに組み込むことに失敗する、異なる時間および/または異なる当事者に対してマークルツリーの矛盾する異なるビューを提示する、STH を頻繁に発行しすぎる、ログに記録された証明書の署名を変更する、ログに記録された証明書の証明者を含むチェーンの提示に失敗する、などが挙げられる。

MMD 契約の違反はログクライアントが観測された各 SCT に対してマークル包含証明 (セクション 5.4) を要求することによって検出される。これらのチェックは非同期で実行でき、証明書ごとに 1 回だけ実行すれば十分である。ただし、プライバシーに関する懸念が生じる可能性があることに注意 (セクション 8.1.4 参照)。

追記専用特性または STH 発行レート制限の違反は、複数のクライアントが STH のインスタンスを比較することによって検出できる。この手法は「ゴシップ」として知られており、現在も研究が進められていてここでは定義しない。このようなケースにおける不正行為の証拠として、STH 発行レート制限違反を証明する間隔が狭すぎる一連の STH、または追記専用特性の違反を証明するログのコピーから計算されたルートハッシュと一致しない STH のいずれかが挙げられる。

ログが同じタイムスタンプとデータを持つが異なる署名を持つ複数の STH または SCT を生成する場合、SCT を報告するクライアントは追跡またはトレースされる可能性がある。ログは次のいずれかによってリスクを軽減すべきである:

• 決定論的署名方式を使用する、または

• それぞれの異なる提出に対して最大 1 つの SCT を生成し、それぞれの異なる tree_size ごとに最大 1 つの STH を生成する。これらの SCT および STH はぞれぞれ、ログによって保存され同じ証明書を提出する、または同じ STH を要求する他のクライアントに提供される。

11.4 複数の SCT

TSL サーバにそれぞれ異なるログからの複数の SCT を提供することを要求することにより、TSL クライアントは CA とログが共謀する攻撃の有効性を低減する (セクション 6.2 参照)。

11.5 DNS 情報の漏洩

悪意のある監視者は、ログを使用して、他の方法では発見が容易できないかもしれないドメイン名の存在を知ることができる。一部のサブドメインラベルは、そのサブドメインが使用されているサービスやソフトウェアに関する情報を明らかにする可能性があり、それが標的型攻撃を助長する可能性がある。

12. References

12.1. Normative References

1. [FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.
2. [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C Recommendation SPSD-html401-20180327, March 2018, <https://www.w3.org/TR/2018/SPSD-html401-20180327>.
3. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
4. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>.
5. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
6. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
7. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
8. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
9. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
10. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
11. [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
12. [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
13. [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
14. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
15. [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) Feature Extension", RFC 7633, DOI 10.17487/RFC7633, October 2015, <https://www.rfc-editor.org/info/rfc7633>.
16. [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <https://www.rfc-editor.org/info/rfc7807>.
17. [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
18. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
19. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
20. [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. Mohaisen, "XMSS: eXtended Merkle Signature Scheme", RFC 8391, DOI 10.17487/RFC8391, May 2018, <https://www.rfc-editor.org/info/rfc8391>.
21. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
22. [UNIXTIME] IEEE, "The Open Group Base Specifications Issue 7", Section 4.16 Seconds Since the Epoch, IEEE Std 1003.1-2008, 2016, <http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16>.
23. [X690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, February 2021.

12.2. Informative References

24. [CABBR] CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates", Version 1.7.3, October 2020, <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf>.
25. [Chromium.Log.Policy] The Chromium Projects, "Chromium Certificate Transparency Log Policy", <https://googlechrome.github.io/CertificateTransparency/log_policy.html>.
26. [Chromium.Policy] The Chromium Projects, "Chromium Certificate Transparency Policy", <https://googlechrome.github.io/CertificateTransparency/ct_policy.html>.
27. [CrosbyWallach] Crosby, S. and D. Wallach, "Efficient Data Structures for Tamper-Evident Logging", Proceedings of the 18th USENIX Security Symposium, Montreal, August 2009, <http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf>.
28. [JSON.Metadata] The Chromium Projects, "Chromium Log Metadata JSON Schema", <https://www.gstatic.com/ct/log_list/log_list_schema.json>.
29. [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
30. [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, <https://www.rfc-editor.org/info/rfc6268>.
31. [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
32. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
33. [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020, <https://www.rfc-editor.org/info/rfc8820>.
34. [X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, February 2021.

Appendix A. v1 と v2 の並行サポート (参考情報)

Certificate Transparency ログは、v1 ([RFC6962] 準拠) または v2 (この文書準拠) のいずれかでなければならない。データ構造に互換性がないため、v2 ログは有効な v1 SCT を発行できない。

ただし、v1 SCT は v2 SCT とは異なる TLS、X.509、および OCSP 拡張で配信されるため、CT クライアントは同じ証明書に対して v1 と v2 の SCT を同時にサポートできる。

X.509 証明書に対する v1 と v2 の SCT は独立して検証できる。事前証明書の場合、v2 SCT は ([RFC6962] のセクション 3.1 で説明されているように、v1 事前証明書内の) TBSCertificate を v1 ログに送信する前に TBSCertificate に埋め込むべきである。これにより、[RFC6962] には準拠しているが本文書に準拠していない TLS クライアントは、埋め込まれた v2 SCT を認識する必要がない。発行者は、以下の手順に従って埋め込まれた v1 と v2 SCT を持つ X.509 証明書を作成できる:

• セクション 3.1 で説明されているように、CMS 事前証明書を作成して v2 ログに送信する。

• セクション 7.1.2 で説明されているように、取得した v2 SCT を TBSCertificate に埋め込む。

• その TBSCertificate を使用して、[RFC6962] のセクション 3.1 で説明されているように v1 事前証明書を作成して v1 ログに送信する。

• [RFC6962] のセクション 3.1 で説明されているように、v1 SCT を TBSCertificate に埋め込む。

• その TBSCertificate (現在 v1 と v2 の SCT の両方を含む) に署名して、最終的な X.509 証明書を発行する。

Appendix B. ASN.1 モジュール (参考情報)

以下の ASN.1 [X.680] モジュールは実装者にとって有用である可能性がある。このモジュールは [RFC5912] および [RFC6268] を参照している。

CertificateTransparencyV2Module-2021
 -- { id-mod-public-notary-v2 from above, in
        iso(1) identified-organization(3) ...
    form }
DEFINITIONS IMPLICIT TAGS ::= BEGIN

-- EXPORTS ALL --

IMPORTS
  EXTENSION
  FROM PKIX-CommonTypes-2009 -- RFC 5912
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkixCommon-02(57) }

  CONTENT-TYPE
  FROM CryptographicMessageSyntax-2010  -- RFC 6268
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

  TBSCertificate
  FROM PKIX1Explicit-2009 -- RFC 5912
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-explicit-02(51) }
;

--
-- Section 3.2.  Precertificates
--

ct-tbsCertificate CONTENT-TYPE ::= {
  TYPE TBSCertificate
  IDENTIFIED BY id-ct-tbsCertificate }

id-ct-tbsCertificate OBJECT IDENTIFIER ::= { 1 3 101 78 }

--
-- Section 7.1.  Transparency Information X.509v3 Extension
--

ext-transparencyInfo EXTENSION ::= {
   SYNTAX TransparencyInformationSyntax
   IDENTIFIED BY id-ce-transparencyInfo
   CRITICALITY { FALSE } }

id-ce-transparencyInfo OBJECT IDENTIFIER ::= { 1 3 101 75 }

TransparencyInformationSyntax ::= OCTET STRING

--
-- Section 7.1.1.  OCSP Response Extension
--

ext-ocsp-transparencyInfo EXTENSION ::= {
   SYNTAX TransparencyInformationSyntax
   IDENTIFIED BY id-pkix-ocsp-transparencyInfo
   CRITICALITY { FALSE } }

id-pkix-ocsp-transparencyInfo OBJECT IDENTIFIER ::=
   id-ce-transparencyInfo

--
-- Section 8.1.2.  Reconstructing the TBSCertificate
--

ext-embeddedSCT-CTv1 EXTENSION ::= {
   SYNTAX SignedCertificateTimestampList
   IDENTIFIED BY id-ce-embeddedSCT-CTv1
   CRITICALITY { FALSE } }

id-ce-embeddedSCT-CTv1 OBJECT IDENTIFIER ::= {
   1 3 6 1 4 1 11129 2 4 2 }

SignedCertificateTimestampList ::= OCTET STRING

END

Acknowledgements

The authors would like to thank Erwann Abelea, Robin Alden, Andrew Ayer, Richard Barnes, Al Cutter, David Drysdale, Francis Dupont, Adam Eijdenberg, Stephen Farrell, Daniel Kahn Gillmor, Paul Hadfield, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, Kat Joyce, Emilia Kasper, Stephen Kent, Adam Langley, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer, Trevor Perrin, Pierre Phaneuf, Eric Rescorla, Rich Salz, Melinda Shore, Ryan Sleevi, Martin Smith, Carl Wallace, and Paul Wouters for their valuable contributions.

A big thank you to Symantec for kindly donating the OIDs from the 1.3.101 arc that are used in this document.