Summary

  • STI Certificate Transparency草案第05版はSTIR作業部会のInternet-Draftで、2026年11月5日までIETF最終意見募集にある。電話の署名証明書を監査可能なログに登録し、SCTという署名済み時刻証明を証明書に埋め込む構想だ。
  • SCTは、ログが予備証明書を最大取り込み遅延の範囲内で記録するという約束である。通話の検証サービスはPASSporT署名、証明書チェーン、SCTを検査し、その場でログに問い合わせない。
  • 別の監視者が新しいログ項目のTNAuthListと組織名を、担当する電話番号や事業者コードと照合する。競合の発見と証明書の失効判断は、通話とは別の時計で動く。

同じ電話番号について、異なる二つの組織名を載せた証明書があり、両方にログの受領証が付いているとしよう。後から発行された方で署名した通話が届く時、監視者はまだその項目を読んでいないかもしれない。検証側には署名を調べる材料がある。番号の正当な利用者による競合調査はまだ終わっていない。草案の仕組みを点検する仮定であり、実際の不正発行事例ではない。

草案はRFC 6962の追記型ログを電話識別へ持ち込む。RFC 8226のTNAuthListが番号や事業者コードに関する権限情報を載せ、RFC 9060は番号範囲の委任証明書を定める。認証局は予備証明書と中間証明書を提出する。ログは公開した受理対象のルートまでチェーンを検証し、SCTを返す。認証局はそれを最終証明書に入れる。

受領証が先に走り、調査が後から追う

SCTには、予備証明書を最大取り込み遅延のうちにMerkle木へ加えるというログの署名済み約束がある。期限後には署名された木の状態と包含証明で実際の収録を確かめ、連続する木の状態の整合性も検査できる。受領、収録、監査を一つの「確認済み」にまとめれば、番号の競合が放置されうる時間が見えなくなる。

第7.2節は通話経路を意図的に短くする。認証サービスは証明書を有効にする時点でSCTを検査して結果をキャッシュできる。SIPのIdentityヘッダーを受けた検証サービスはPASSporT署名、受理されたSTIの信頼アンカーまでのチェーン、信頼するログ鍵によるSCT署名を確認する。通話中にログから証明を同期取得することは認めない。ログの応答や監視者の巡回を待っていたら、この設計の速度は消える。

速度は監視の仕事を消さない。ログが確かめるのは認証局のチェーンであり、番号の利用権者を継続的に調べる台帳ではない。監視者は担当番号と事業者コード、各ログの接続先、最後に見た署名済み木の状態を持つ。新しい項目を読み、TNAuthListと組織名を照合し、知らない名義なら警報を出す。担当番号の一覧が抜けていれば、ログの全項目を読んでも肝心の重複を見逃せる。

警報の先に誰の停止権限があるか

草案は不正発行が確定した後の処置をSTI側の制度に委ねる。発行局に証明書を失効させる方法と、信頼アンカー一覧から認証局を外す方法を例に挙げる。前者は個別の証明書、後者はより広い証明書群に効く。監視者が異常を発見する権限と、そのどちらかのスイッチを押す権限は同じとは限らない。責任者のいない警報箱では、暗号学的な証拠が積まれるだけだ。

APIの表面も慎重な再利用にとどまる。RFC 6962の/ct/v1/と同じ意味の操作を使い、運用上は/stict/v1/という経路を推奨する。経路名を付け替えても、全ログを誰が見るか、番号一覧を誰が更新するか、競合時に誰が失効を命じるかは決まらない。

実運用を判断するには、証明書発行からログ収録、競合警報、最終処置までの時刻付き記録が要る。草案に実測の検知時間や不正発行件数はない。通話を速くする仕組みに予算を付けるなら、遅い監視にも名前と予算を与えるべきだ。受領証だけが先に現れ、警報が後回しなら、制度は速さを信頼と取り違える。

STI CT草案 · RFC 6962 · RFC 8226 · RFC 9060 · RFC 8224