要約

  • SCTは、ログが証明書エントリーを所定時間内に取り込むという署名付きの約束であり、通常の証明書検証やブラウザ固有のCT判定を代替しない。
  • リリース判定ではSCT数ではなく、CT実施状態を含む対象クライアントの外部接続結果を保存する必要がある。

証明書発行システムには三つのSCTが並ぶ。すべての署名が正しく、配布先も新しい証明書を保持している。それでも一部のブラウザはTLS接続を拒否する。この場面で不足しているのはSCTではなく、発行側の受領と依存側の判断を結ぶ証拠である。

RFC 9162によれば、SCTはログが受理した証明書または事前証明書を追記型Merkle TreeへMaximum Merge Delay以内に取り込むという約束だ。後から包含証明や整合性を監査できる。一方、同RFCはSCTの検証がサーバー証明書とチェーンの通常検証の代わりにならないとも明記する。

ChromeのCTポリシーはさらに、SCTの提示方法、異なるログの数、運営者の独立性、SCT発行時と検証時のログ状態を評価する。有効期間180日以下でSCTを証明書に埋め込む場合、現行ルールでは少なくとも二つの異なるログと二つの異なる運営者が必要で、検証時にも寄与できる状態のログが含まれなければならない。TLSでSCTを渡す場合は別の条件になる。

したがって「有効なSCTが三つ」という表示だけでは足りない。同一運営者への集中、状態が変わったログ、提示経路の違いを隠してしまうからだ。

ログ集合には更新時刻がある

ChromeはCTログ一覧を毎日更新する。ログと運営者だけでなく、Qualified、Usable、ReadOnly、Retired、Rejectedなどの状態が判定に関わる。固定した「信頼済みログ一覧」では、発行時と検証時という二つの時点を再現できない。

さらに、Chromeが保持する最も新しい対応ログ一覧が70日以上更新されない場合、CTの強制は無効になる。古い端末で接続に成功しても、現行ポリシー適合の証拠とは限らない。試験記録にはブラウザの版、ログ一覧のタイムスタンプ、CTが実際に強制されていたかを含める必要がある。

Chromeの一覧は汎用の信頼台帳でもない。GoogleはChrome互換性のための利用範囲を示し、他のユーザーエージェントがそのまま執行基盤に転用することを警告している。Appleは独自ポリシーを公開し、現在承認中のログと過去に承認されたログを区別し、必要なSCT構成と同一運営者から数えられる上限を定めている。同じCT技術でも、受理式は一つではない。

時間シャードは証明書の期限をログ選択に持ち込む

Chromeが新規ログに求める時間シャードでは、各ログが証明書のnotAfter範囲を持ち、範囲外の提出を拒否する。ログ運営者は連続する期間を用意するが、発行側は証明書の失効日とログ状態の両方を見て選ばなければならない。

サイト運営者向けのChrome資料は、既存証明書のCT情報が証明書の期限より先に有効性を失う場合があると説明する。その場合、TLS経由で新しいSCTを提示するか、証明書自体の交換が必要になる。期限監視だけではこのリスクを検知できない。

ここで確認できる事実は、RFCとChrome、Appleの公開ポリシーである。発行受領を実クライアントと照合すべきだという結論は運用上の推論だ。公開情報から、特定組織のブラウザ構成、例外、終端、シミュレーター精度、障害履歴は分からない。認証局、ログ、ブラウザの現在の不具合を主張するものでもない。未知の部分は自ら測定しなければならない。

受理台帳には、証明書フィンガープリント、対象名と終端、SCT提示方法、ログIDと時刻、ChromeとAppleの有効ポリシー・一覧、試験したクライアントと版、外部ハンドシェイク結果、例外、担当者、交換までの余裕を結び付ける。受領票を持つのは発行システムだが、利用者が接続できることを証明する責任はサービス側に残る。

出典