STI 证书透明度让通话先走，号码冲突另查

Summary

STI Certificate Transparency 草案第 05 版仍是 STIR 工作组的 Internet-Draft，正在 IETF 最后征询，截止日为 2026 年 11 月 5 日。它拟让签署电话的证书先进入可审计日志，并携带日志签发的 SCT。
SCT 是日志在最长合并期限内纳入预证书的签名承诺。电话验证端检查 PASSporT、证书链和 SCT，却不得在通话路径上同步查询日志。
监测者后来读取新条目，对照 TNAuthList、实体名称及所监护的号码或服务商代码。发现不同实体宣称同一号码之后，还须有人调查并决定撤销证书或调整信任锚。

设想两家机构各持一张证书，都宣称可以使用同一号码，也都拿到了日志收据。后一张证书用于签署电话时，监测者可能尚未读到它。验证端有足够材料完成本地签名检查，却没有号码权利人的调查结论。这是用来拆解草案职责的假设场景，不是已经发生的欺诈案。

草案借用 RFC 6962 的追加式日志机制。电话身份凭证依据 RFC 8226 的 TNAuthList 标记号码或服务商代码，RFC 9060 则处理号码范围的委托证书。签发机构提交预证书和中间证书链；日志检查链条是否抵达其接受并公布的根证书，然后交回 SCT，供最终证书嵌入。

签收是承诺，查重是另一份工作

SCT 承诺日志会在最长合并期限内把预证书纳入 Merkle 树。期限过去，审计者可以用签名树头和纳入证明确认条目存在，再用一致性证明检查历史有没有被改写。签收、实际入树、独立审计发生在不同时间。把三者压成一个“已验证”图标，正好抹去冲突最可能生长的空档。

通话路径之所以快，是因为证书随身带着收据。认证服务可以在启用证书时本地校验并缓存。接到 SIP Identity 头的验证服务检查 PASSporT 签名、委托证书链以及受信任日志密钥下的 SCT 签名。草案第 7.2 节明确不让认证或验证服务在每通电话上向日志发同步请求。公开日志暂时迟缓，不会自动把每通电话拖住。

速度换来的任务必须有人接手。日志认可的是一条证书链和自己的入树承诺，不负责维护每个号码的实时权利清单。监测者要保存各日志地址、上一份树头、自己负责的号码或服务商代码，持续抓取新条目，抽出 TNAuthList 和实体名称来比对。发现陌生领取者才会报警。号码清单漏掉一个范围，日志再完整，监测者也可能睁眼错过。