セキュリティ

RFC翻訳: Certificate Transparency Version 2.0

Takami Torao RFC 9162
  • このエントリーをはてなブックマークに追加
Internet Engineering Task Force (IETF)
Request for Comments: 9162
Obsoletes: 6962
Category: Experimental
Published: December 2021
ISSN: 2070-1721
B. Laurie
Google
E. Messeri
Google
R. Stradling
Sectigo

概要

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

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

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

Table of Contents

  1. 概要
  2. 1 INTRODUCTION
    1. 1.1 Requirements Language
    2. 1.2 Data Structures and OIDs
    3. 1.3 Major Differences from 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 Log Parameters
    2. 4.2 Evaluating Submissions
      1. 4.2.1 Minimum Acceptance Criteria
      2. 4.2.2 Discretionary Acceptance Criteria
    3. 4.3 Log Entries
    4. 4.4 Log ID
    5. 4.5 TransItem Structure
    6. 4.6 Log Artifact Extensions
    7. 4.7 Merkle Tree Leaves
    8. 4.8 Signed Certificate Timestamp (SCT)
    9. 4.9 Merkle Tree Head
    10. 4.10 Signed Tree Head (STH)
    11. 4.11 Merkle Consistency Proof
    12. 4.12 Merkle Inclusion Proof
    13. 4.13 Shutting Down a Log
  6. 5 LOG CLIENT MESSAGES
    1. 5.1 Submit Entry to Log
    2. 5.2 Retrieve Latest Signed Tree Head
    3. 5.3 Retrieve Merkle Consistency Proof between Two STHs
    4. 5.4 Retrieve Merkle Inclusion Proof from Log by Leaf Hash
    5. 5.5 Retrieve Merkle Inclusion Proof from Log by Leaf Hash and Tree Size
    6. 5.6 Retrieve Entries and STH from Log
    7. 5.7 Retrieve Accepted Trust Anchors
  7. 6 TLS SERVERS
    1. 6.1 TLS Client Authentication
    2. 6.2 Multiple SCTs
    3. 6.3 TransItemList Structure
    4. 6.4 Presenting TransItems
    5. 6.5 transparency_info TLS Extension
  8. 7 CERTIFICATION AUTHORITY ACTIONS
    1. 7.1 X.509v3 Extensions and OCSP
      1. 7.1.1 Transparency Information X.509v3 Extension in OCSP
      2. 7.1.2 Transparency Information X.509v3 Extension in Certificates
  9. 8 CLIENTS
    1. 8.1 TLS Clients
      1. 8.1.1 Receiving TransItems
      2. 8.1.2 Reconstructing the TBSCertificate
      3. 8.1.3 Validating SCTs
      4. 8.1.4 Fetching Inclusion Proofs
      5. 8.1.5 Validating Inclusion Proofs
      6. 8.1.6 Evaluating Compliance
    2. 8.2 Monitor
    3. 8.3 Auditing
  10. 9 ALGORITHM AGILITY
  11. 10 IANA CONSIDERATIONS
    1. 10.1 Additions to Existing Registries
      1. 10.1.1 New Entry to the TLS ExtensionType Values Registry
      2. 10.1.2 URN Sub-namespace for TRANS Error Types
    2. 10.2 New Certificate Transparency Registries
      1. 10.2.1 Hash Algorithms
      2. 10.2.2 Signature Algorithms
      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 Assignment
  12. 11 SECURITY CONSIDERATIONS
    1. 11.1 Misissued Certificates
    2. 11.2 Detection of Misissued Certificates
    3. 11.3 Misbehaving Logs
    4. 11.4 Preventing Single CA and Log Compromise
    5. 11.5 Malicious Monitor Concerns
  13. 12. References
    1. 12.1. Normative References
    2. 12.2. Informative References

1 INTRODUCTION

1.1 Requirements Language

1.2 Data Structures and OIDs

1.3 Major Differences from CT 1.0

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 を生成すべきである。

4.1 Log Parameters

4.2 Evaluating Submissions

4.2.1 Minimum Acceptance Criteria

4.2.2 Discretionary Acceptance Criteria

4.3 Log Entries

4.4 Log ID

4.5 TransItem Structure

4.6 Log Artifact Extensions

4.7 Merkle Tree Leaves

4.8 Signed Certificate Timestamp (SCT)

4.9 Merkle Tree Head

4.10 Signed Tree Head (STH)

4.11 Merkle Consistency Proof

4.12 Merkle Inclusion Proof

4.13 Shutting Down a Log

5 LOG CLIENT MESSAGES

5.1 Submit Entry to Log

5.2 Retrieve Latest Signed Tree Head

5.3 Retrieve Merkle Consistency Proof between Two STHs

5.4 Retrieve Merkle Inclusion Proof from Log by Leaf Hash

5.5 Retrieve Merkle Inclusion Proof from Log by Leaf Hash and Tree Size

5.6 Retrieve Entries and STH from Log

5.7 Retrieve Accepted Trust Anchors

6 TLS SERVERS

6.1 TLS Client Authentication

6.2 Multiple SCTs

6.3 TransItemList Structure

6.4 Presenting TransItems

6.5 transparency_info TLS Extension

7 CERTIFICATION AUTHORITY ACTIONS

7.1 X.509v3 Extensions and OCSP

7.1.1 Transparency Information X.509v3 Extension in OCSP

7.1.2 Transparency Information X.509v3 Extension in Certificates

8 CLIENTS

8.1 TLS Clients

8.1.1 Receiving TransItems

8.1.2 Reconstructing the TBSCertificate

8.1.3 Validating SCTs

8.1.4 Fetching Inclusion Proofs

8.1.5 Validating Inclusion Proofs

8.1.6 Evaluating Compliance

8.2 Monitor

8.3 Auditing

9 ALGORITHM AGILITY

10 IANA CONSIDERATIONS

10.1 Additions to Existing Registries

10.1.1 New Entry to the TLS ExtensionType Values Registry

10.1.2 URN Sub-namespace for TRANS Error Types

10.2 New Certificate Transparency Registries

10.2.1 Hash Algorithms

10.2.2 Signature Algorithms

10.2.3 VersionedTransType

10.2.4 Log Artifact Extension

10.2.5 Log ID Registry

10.2.6 CT Error Types

10.3 OID Assignment

11 SECURITY CONSIDERATIONS

11.1 Misissued Certificates

11.2 Detection of Misissued Certificates

11.3 Misbehaving Logs

11.4 Preventing Single CA and Log Compromise

11.5 Malicious Monitor Concerns

12. References

12.1. Normative References

  1. [FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc3986>.
  6. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <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, , <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, , <https://www.rfc-editor.org/info/rfc5280>.
  9. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, .

12.2. Informative References

  1. [CABBR] CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates", Version 1.7.3, , <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf>.
  2. [Chromium.Log.Policy] The Chromium Projects, "Chromium Certificate Transparency Log Policy", <https://googlechrome.github.io/CertificateTransparency/log_policy.html>.
  3. [Chromium.Policy] The Chromium Projects, "Chromium Certificate Transparency Policy", <https://googlechrome.github.io/CertificateTransparency/ct_policy.html>.
  4. [CrosbyWallach] Crosby, S. and D. Wallach, "Efficient Data Structures for Tamper-Evident Logging", Proceedings of the 18th USENIX Security Symposium, Montreal, , <http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf>.
  5. [JSON.Metadata] The Chromium Projects, "Chromium Log Metadata JSON Schema", <https://www.gstatic.com/ct/log_list/log_list_schema.json>.
  6. [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, , <https://www.rfc-editor.org/info/rfc5912>.
  7. [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, , <https://www.rfc-editor.org/info/rfc6268>.
  8. [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, , <https://www.rfc-editor.org/info/rfc6962>.
  9. [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, , <https://www.rfc-editor.org/info/rfc8126>.
  10. [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, , <https://www.rfc-editor.org/info/rfc8820>.
  11. [X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, .