01 · CT信任模型与角色分工
CT解决的核心问题是：如何在不改变"浏览器信任CA"这一基本模型的前提下，使CA的签发行为变得可公开审计。其信任模型引入了一个新的独立角色——日志（Log），并围绕它形成五方协作结构：
| 角色 | 职责 | 关键机制 |
|---|---|---|
| CA（证书颁发机构） | 签发证书前/后将证书（或预证书）提交给一个或多个CT日志，获取SCT并递交客户端 | 预证书Poison扩展（OID 1.3.6.1.4.1.11129.2.4.3）；嵌入SCT列表扩展（OID 1.3.6.1.4.1.11129.2.4.2） |
| 日志运营方（Log Operator） | 运行仅追加Merkle树日志，承诺"已提交条目将按期并入树"，签名发布STH | get-sth / get-entries / get-proof-by-hash / get-sth-consistency等只读API；接受全球审计 |
| 客户端（浏览器/操作系统） | 校验证书携带的SCT：验证签名、日志ID有效性、时间戳合理性，并按政策要求SCT数量与来源组合 | Chrome按日志清单（log list）核对SCT签名公钥；v1日志ID=日志SPKI的SHA-256 |
| 审计方（Auditor/Monitor） | 验证日志行为正确性：包含证明抽查、一致性证明验证、树增长监控 | 密码学审计（proof verification）＋运营监控（可用性、STH频率） |
| 品牌方/监测方 | 消费日志数据流进行仿冒检测与资产盘点（本课题主体） | 日志流式接入、相似度检测、风险分级与处置联动 |
核心信任假设：CT的密码学设计使"日志篡改历史"在计算上不可行（Merkle树抗第二原像）；但日志仍可能"对未来撒谎"——为不同客户端展示不同的树（split-view）。对抗该威胁的手段是：客户端验证一致性证明、跨方 gossip 交换STH、以及浏览器厂商对清单内日志的持续监控（详见第6页）。
02 · 核心数据结构：Merkle树、叶节点、SCT与STH
2.1 Merkle树与叶节点（v1，RFC 6962 §3）
- Merkle Hash Tree：日志将所有已提交条目组织成二叉Merkle树；任意叶节点存在O(log n)大小的审计证明（audit path），任意两个树状态之间存在O(log n)的一致性证明（consistency proof）——这是CT"可审计性"的数学基础。
- 叶节点结构（v1）：MerkleTreeLeaf = version(1字节，恒为0) ‖ leaf_type(1字节，0=timestamped_entry) ‖ timestamped_entry。timestamped_entry内含：timestamp（毫秒，日志承诺的并入截止时间）、entry_type（0=x509_entry为正式证书，1=precert_entry为预证书）、signed_entry（证书内容或预证书的TBS+发行者信息）、extensions（扩展字段）。
- 叶子哈希：leaf_hash = SHA-256(0x00 ‖ MerkleTreeLeaf)——叶前缀0x00与内部节点前缀0x01构成Merkle树防第二原像的标准域分离（domain separation）。
- STH（v1）：日志对 tree_size（条目数）、timestamp（毫秒）、root_hash（当前树根）的签名，签名数据带"tree_head"版本标签（v0）前缀；STH以不超过政策要求的频率签发（行业惯例为每24小时至少一次，主流日志实际远高于此）。
- SCT（v1）：version(0) ‖ log_id（日志SPKI的SHA-256）‖ timestamp（日志承诺：该证书将在该时间前并入）‖ extensions ‖ 签名（签"certificate_timestamp"结构）。SCT时间戳不晚于证书有效期结束（主流客户端策略允许少量时钟容差，具体以Chrome政策文档为准）。
2.2 预证书机制：为什么需要"Poison扩展"
CA为在签发正式证书前先获得SCT（嵌入证书扩展的需求），会先构造一张"预证书"提交日志：预证书与最终证书序列号相同、公钥相同，但额外携带一个不可解析的CT Poison扩展。该设计的两个目的：其一，防止同一张证书被重复计入（若攻击者把预证书当正式证书提交另一日志，Poisson扩展使其在TLS中不可用，且日志侧可识别去重）；其二，使"日志中先出现正式证书、后出现预证书"之类的顺序异常可被发现——监测方可利用这一点检测日志与CA行为异常。对监测工程的意义：同一张证书在CT数据中通常出现两条记录（precert_entry与x509_entry），必须按序列号+SPKI指纹归并，否则告警量翻倍。
2.3 SCT的三种递交通道
| 通道 | 机制 | 现状 |
|---|---|---|
| X.509扩展（嵌入SCT） | CA获得SCT后将其写入正式证书的SCT列表扩展（OID 1.3.6.1.4.1.11129.2.4.2），随证书本身分发 | 当前绝对主流；Chrome要求嵌入路径的SCT组合满足其政策 |
| TLS扩展（服务端递交） | 服务器在TLS握手"server hello"阶段通过signed_certificate_timestamp扩展（扩展类型18）递交SCT | 要求更严格的SCT组合（多日志来源），部署较少，主要用于灵活性场景 |
| OCSP装订递交 | SCT随OCSP响应装订下发 | 该通道正被逐步淘汰：Chrome CT政策明确自Chrome 148起不再接受OCSP装订方式递交的SCT（现行更早版本仍接受），以官方政策页面最新版本为准 |
03 · CT v1与CT v2（RFC 9162）差异解析
| 维度 | CT v1（RFC 6962，2013） | CT v2（RFC 9162，2021） |
|---|---|---|
| 运行现状 | 公网绝对主力；Chrome/Apple强制政策运行于v1日志体系 | 部署早期；Sunlight等新实现推动中；与v1长期共存 |
| 叶节点格式 | leaf_type+timestamped_entry，precert_entry内嵌TBS与发行者信息 | 重构叶节点结构：明确区分证书与预证书字段、重定义扩展语义、取消冗余编码 |
| STH形态 | 签名结构（tree_size/timestamp/root_hash），二进制编码 | 引入"checkpoint"文本行格式（与Go透明日志生态tlog.Checkpoint同构），便于工具链处理与交叉审计 |
| 传输绑定 | 与TLS 1.2时代机制兼容 | 绑定TLS 1.3及现代密码套件；签名算法灵活性提升（如Ed25519） |
| API风格 | JSON over HTTP（get-entries等） | 保持HTTP只读查询理念，参数与响应格式重新规范化 |
| 工程倾向 | 功能性优先，历史包袱较多 | 简洁性优先：更少歧义、更小解析面，配合高频STH（秒级）实现降低审计时延 |
对监测工程的直接要求：①解析层必须同时兼容v1与v2叶节点编码（字段顺序与precert表示不同）；②日志清单来源不同（Chrome清单覆盖其认可的v1日志；v2日志有独立清单管理）；③归并键设计需以"序列号+SPKI指纹"为主，避免跨版本格式差异导致重复告警。
04 · 日志清单与运营治理
4.1 浏览器日志清单（Log List）机制
- Chrome清单：以JSON格式发布（gstatic.com/ct/log_list/，v2/v3版本），列明每个日志的log_id、URL、运营方、合格MMD（最大并入延迟）及状态；客户端据此验证SCT签名公钥。清单状态枚举：usable（可用）、frozen（冻结，不再并入新条目但仍可审计历史）、retired（退役，客户端不再接受其新SCT）、rejected（拒绝）——状态及其生效时间戳均公开可查。
- Apple清单：Apple维护其认可的日志清单并随策略更新；工程实现须分别消费两套清单，监测方按清单全集接入以最大化覆盖。
- 治理逻辑：清单机制是浏览器对日志运营方的"软准入"——日志须满足Chrome CT Log Policy等要求（可用性、并入时延、密钥管理、事件响应）方能入列；违规日志可被降状态或移出清单，构成生态治理闭环。
4.2 主流公开日志与运营方（示例，以官方清单为准）
| 运营方 | 日志系列（示例） | 说明 |
|---|---|---|
| Argon2017—Argon2023系列、Xenon2022—Xenon2024系列 | 运营历史最长的日志家族；按年度滚动启用/退役新日志（Argon2018等早期日志已按计划退役） | |
| Cloudflare | Nimbus2018—Nimbus2025系列 | 独立第三方日志家族，同样采用年度滚动模式 |
| Sectigo | Sabre、Mammoth | 长期运行的通用日志；Sectigo同时运营公共查询服务crt.sh |
| Let's Encrypt | 2024年宣布基于Sunlight实现的新日志 | CA运营自有日志的新趋势，体现"CA+日志"纵向一体化 |
注意：日志清单是动态治理对象——新日志启用、旧日志冻结/退役持续发生（年度滚动是常态）。监测工程必须将"清单变更"作为一级事件处理：退役日志不再增长但历史数据仍有效；忽略清单变更会导致SCT验证策略误判与数据接入断档（详见第3页工程实践）。
05 · 客户端验证与开源生态组件
- Chrome验证流程（概要，以现行CT政策页面为准）：①从证书扩展/TLS扩展收集SCT列表；②按日志清单验证每个SCT签名与log_id；③检查SCT时间戳与证书有效期的一致性；④按证书有效期核对SCT数量与日志运营方组合：现行政策要求嵌入SCT来自至少2个不同日志（证书有效期≤180天）或3个不同日志（>180天），且其中至少来自2个不同的日志运营方（Chrome已于2022年3月起取消"必须包含一个Google运营日志"的旧要求）；⑤任一环节失败即按CT不合规处理证书链。
- Google certificate-transparency-go：CT协议的官方Go语言实现库（github.com/google/certificate-transparency-go），提供日志客户端、数据类型解析、证明验证与Merklized结构工具——是自建监测/审计工具的首选基础库。
- Trillian：Google开源的透明数据存储框架（github.com/google/trillian），为自建CT日志或透明账本提供Merkle树存储、签名与API服务骨架。
- Sunlight：轻量级CT日志实现（filippo.io/sunlight），以checkpoint格式高频发布树头（秒级量级），显著降低审计与镜像的数据新鲜度延迟，代表CT工程化的新一代方向。
- crt.sh：Sectigo运营的公共CT查询服务，提供Web检索与JSON API（/?q=域名&output=json），覆盖全部公共日志——低成本品牌自查与人工研判的标准工具。
本节参考来源（本页）
以下均为真实可查的权威来源（IETF RFC官方档案、浏览器/日志运营方官方文档、开源项目、学术会议论文），用于支撑本页事实性表述。
IETF RFC 6962《Certificate Transparency Version 1.0》（2013年6月）：rfc-editor.org/rfc/rfc6962（第2、3节：数据结构、预证书、SCT/STH）。
IETF RFC 9162《Certificate Transparency Version 2》（2021年12月）：rfc-editor.org/rfc/rfc9162（checkpoint格式与v2协议）。
Chrome CT日志清单（机器可读，含状态字段定义）：gstatic.com/ct/log_list/v3/log_list.json；Chrome CT政策项目文档：googlechrome.github.io/CertificateTransparency/ct_policy.html（Chrome CT政策官方页面，动态更新）。
certificate-transparency-go（CT官方Go库）：github.com/google/certificate-transparency-go；Trillian：github.com/google/trillian。
Sunlight项目文档（高频STH与checkpoint实践）：filippo.io/sunlight。
crt.sh公共查询服务与JSON API：crt.sh；CT Poison扩展OID注册（1.3.6.1.4.1.11129.2.4.3）：oidref.com。
Apple CT支持文档：support.apple.com/en-us/HT205280；CA/B Forum：cabforum.org。