要約

  • OCSPステープリングは、署名済みの証明書状態をTLSハンドシェイク内で届け、クライアントによる応答者への別途問い合わせを不要にする。
  • goodの意味は意図的に限定され、thisUpdate、nextUpdate、producedAtはその主張の時間的な境界を示す。
  • 署名と時間検証に合格しても、各エッジが応答を取得した時刻や、後から生じた失効情報が全拠点に導入済みかは分からない。
  • 運用には、証明書と応答者を状態時刻、取得、配信コホート、検証方針、判断時刻へ結び付ける失効鮮度レシートが必要になる。

特定の事業者や実在の事故を指さない仮想例を考える。認証局がgoodとする署名済みOCSP応答を作り、あるエッジが取得してキャッシュした。その後に証明書が失効する。別のエッジは新しい応答を取得したが、最初のエッジは以前の応答を、その有効期間内で提示し続けた。クライアントはローカル方針どおりに古いステープルを検証できる。それでも「失効が全拠点で有効になった」という運用上の主張を裏付ける情報は得られない。

境界は仕様そのものに書かれている。RFC 6960は、完全な証明書失効リストを取得せずに証明書状態を確認する仕組みとしてOCSPを定義する。確定状態を示す応答は署名され、応答者を識別し、特定の証明書についての状態を含む。未認証の稼働表示より強い証拠だが、対象、発行文脈、時間範囲を持つ一つの主張であることに変わりはない。

特にgoodは広く読み過ぎやすい。最低限の意味は、問い合わせたシリアル番号を持ち有効期間内にある証明書が、その時点で失効済みとして登録されていないことだ。RFCは直後に範囲を限定する。goodは、その証明書が実際に発行されたことも、応答の生成時刻が証明書の有効期間内だったことも、必ずしも示さない。拡張によって追加情報を表せる場合はあるが、基本状態だけで証明書、サーバー、アカウント、現在のサービス管理権限を一括して保証することはできない。

三つの時刻が証拠の境界を可視化する。thisUpdateは、応答者が示した状態を正しいと認識していた直近の時刻である。nextUpdateは、新しい情報が利用可能になる期限を表す。producedAtは応答者が応答に署名した時刻だ。これらは同義ではない。最近署名された応答が、より前に確認された状態を記述することもある。nextUpdateが未来でも、その後に起きた運用イベントが全キャッシュと全エッジへ既に伝わったことは証明しない。

署名済み応答を受け入れる前に、依拠者は対象証明書との一致、署名、署名者の現在の権限を確認し、thisUpdateが十分新しく、存在するnextUpdateが現在時刻より後であることを判断する。これにより、状態オブジェクトが真正で、クライアントの鮮度方針に照らして受け入れ可能だと分かる。しかし、そのオブジェクトが提示サーバーへ届くまでの配信経路や導入結果は記録されない。

RFC 6066はTLSのstatus_request拡張を説明する。サーバーは証明書と共にOCSP応答を送り、クライアントはハンドシェイク中に応答者へ直接問い合わせずに済む。応答を受け取ったクライアントは内容を検査し、満足できなければハンドシェイクを中断する必要がある。ステープリングが改善するのは状態証拠の届け方であり、証拠が本来持つ意味を広げるものではない。

分散サービスでは、この違いがそのまま運用課題になる。同じ証明書が多数の入口、TLS終端群、配信地域で使われることがある。各群が異なる経路で状態オブジェクトを取得し、キャッシュし、入れ替える場合もある。OCSP応答に入っているのは応答者の知識と時刻であり、全エッジの一覧、設定リビジョン、直近の取得結果、交換完了の確認ではない。「ステープルを検証できた」と「最新の失効状態が全エッジで実施されている」は別の問いである。

RFC 7633は、さらに別の制御点を加える。証明書はstatus_requestなど、サーバーが満たすべきTLS機能を宣言できる。対応クライアントは、期待される状態証拠を提供しない設定を拒否できる。宣言がなければ、ステープルがない理由は、正規サーバーが未対応なのか意図的に省いたのかだけでは判断できない。ただし、仕様で定められた場合には、別の情報源を使って検証することも認められている。Must-Stapleは証拠の提示を要求するが、古い応答を新しくはせず、全ての誤発行を防ぐことも、証明書の背後にあるアプリケーションを現在も正しい主体が管理していると示すこともない。

運用上の誤りは、四つの状態を一つの緑色表示へまとめることだ。証明書チェーンが有効でも、OCSP署名が有効でも、応答がクライアントの時間方針を満たしていても、エッジが最新状態より遅れている可能性は残る。運用者が更新済みと考える配信コホートに、そのエッジが含まれていない場合もある。「ステープルあり」だけを記録する画面では区別できない。

有用な失効鮮度レシートは、証拠の鎖を圧縮せずに残す。証明書のシリアル番号と証明書チェーン全体、応答者の識別情報、返された状態、thisUpdate、nextUpdate、producedAt、取得時刻、導入したエッジまたは配信コホート、検証方針、判断時刻を結び付ける。交換失敗も記録し、トランスポート認証と現在のアプリケーション権限を分離する。

これはステープリングが弱いという意味ではない。境界を明確にすることで、むしろ実用性が高まる。クライアントのプライバシー漏えい、遅延、リアルタイムの第三者問い合わせへの依存を減らせる。Must-Stapleは証拠の欠落を方針上の失敗にできる。署名と時刻検査は、範囲の定まった証明書状態を認証できる。問題は、それらの利点を証拠が含まない包括的保証へ昇格させたときに起きる。

したがって、判断すべきなのはOCSPを抽象的に信頼するか否かではない。ステープルがどの運用上の主張を満たせるかである。真正で十分新しい応答はハンドシェイク検証に決定的となり得る。失効が全ての稼働エッジへ届いたことを保証するには、追加の配信証拠が必要だ。アプリケーションの操作を許可するには、証明書状態オブジェクトから権限を借りず、現在の本人性と方針を別途判断しなければならない。

出典

RFC 6960 — Online Certificate Status Protocol、RFC 6066 — TLS拡張定義、RFC 7633 — TLS Feature拡張。