セキュリティ

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 Merkle Inclusion Proofs
        1. 2.1.3.1 Generating an Inclusion Proof
        2. 2.1.3.2 Verifying an Inclusion Proof
      4. 2.1.4 Merkle Consistency Proofs
        1. 2.1.4.1 Generating a Consistency Proof
        2. 2.1.4.2 Verifying Consistency between Two Tree Heads
      5. 2.1.5 Example
    2. 2.2 Signatures
  4. 3 SUBMITTERS
    1. 3.1 Certificates
    2. 3.2 Precertificates
      1. 3.2.1 Binding Intent to Issue
  5. 4 LOG FORMAT AND OPERATION
    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 Merkle Inclusion Proofs

2.1.3.1 Generating an Inclusion Proof
2.1.3.2 Verifying an Inclusion Proof

2.1.4 Merkle Consistency Proofs

2.1.4.1 Generating a Consistency Proof
2.1.4.2 Verifying Consistency between Two Tree Heads

2.1.5 Example

2.2 Signatures

3 SUBMITTERS

3.1 Certificates

3.2 Precertificates

3.2.1 Binding Intent to Issue

4 LOG FORMAT AND OPERATION

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, .