要約

  • OCSP stapling は、署名付きの証明書状態応答をサーバーが TLS のやり取りに添える仕組みだった。運ぶ役割は移せても、署名の権限と受信側の検証は省けない。
  • 応答の再利用は外部への問い合わせを減らす一方、鮮度の管理を必要とした。証明書に機能の提供を宣言すれば欠落を判断しやすくなるが、証明書の配備と状態応答の準備が切り離せなくなる。

誰が渡したかより、誰が署名したか

サーバーが証明書とともに、その状態は good だという応答を送ってきたとする。サーバー自身の言葉だけなら、確かめたい相手に結論まで任せることになる。

しかし OCSP の応答は、通常の TLS 接続とは別に署名を持つ。クライアントは、その署名者が対象証明書の状態について回答する権限を持つかを調べる。サイトの TLS 秘密鍵を入手した者でも、それだけで正当な OCSP 応答を発行できるわけではない。

ここに配送と権限の分離がある。サーバーには、受け取った証明を渡す役割を担わせる。証明の内容を決める権限まで渡す必要はない。検証可能な物を作っておけば、利害関係のある相手も配送経路として使える。

往復を減らすための拡張

この仕組みは、2003 年 6 月の RFC 3546 にすでに登場している。クライアントが status_request で状態情報を求め、サーバーが証明書の直後に OCSP 応答を送る。帯域などに制約のあるネットワークで、失効リストの転送や追加の往復を減らすことが背景にあった。

2011 年 1 月の RFC 6066 は、後の TLS の枠組みにおける拡張を記述した。そこでは CertificateStatus という独立したメッセージが、符号化された OCSP 応答を運ぶ。2011 年を仕組みの発明年とするのは、2003 年の仕様を見落とすことになる。

添えられた応答が必要な検証を満たせば、クライアントはその確認のために第三者のサービスへ別の接続を開かずに済む。その問い合わせに伴う遅延や情報の露出も避けられる。ただし、閲覧全体が匿名になるわけではない。状態を作るサービスも、サーバーが今後使う応答を供給するために必要なままである。

肯定的な応答は、全面的な保証ではない

RFC 6960 が 2013 年に整理した状態値には、good、revoked、unknown がある。とりわけ good は読み過ぎやすい。これは状態問い合わせへの肯定的な回答であり、証明書が実際に発行されたことまで必ずしも証明しない。

したがって、サイトが安全だという判定でも、証明書チェーンの確認を省く許可でもない。クライアントは応答と対象証明書の対応、署名、署名者の権限、時刻を確かめる必要がある。発行 CA、明示的に信頼された応答者、適切な委任を受けた応答者が仕様上の役割を担うのであって、単なる Web サーバーという立場が権限を生むのではない。

使いやすい経路に置かれたからといって、証拠が答えられる問いまで増えるわけではなかった。

保存しておける回答には、古さが残る

あらかじめ作った応答を複数の接続で使えれば、毎回の生成や問い合わせを減らせる。2007 年 9 月の軽量プロファイル RFC 5019 は、そのための事前生成、配布、キャッシュを扱った。

再利用を支えるのは、署名だけではない。thisUpdate は示された状態が正しいと分かっていた時刻、producedAt は署名した時刻、nextUpdate は新しい情報がいつまでに利用可能になるかを示す。後から署名しても、観測した状態そのものが新しくなるわけではない。

軽量プロファイルは nextUpdate を要求し、正確な時刻による鮮度確認を必要とする。一方、基本の OCSP ではこのフィールドを省略できる。両者を混ぜて、すべての応答が同じ必須項目を持つと説明してはいけない。署名されていない HTTP のキャッシュ指定も、それだけで署名付き応答の許容期間を延ばす根拠にはならない。

状態サービスが一時停止しても、手元にまだ受理可能な応答があれば接続を支えられる場合がある。しかし、その余裕は時間とともに減る。新たな失効情報が公表されても、以前に配られた肯定的な応答の中身は自動では変わらない。再利用の効率は、過去に分かった状態を後で使うという時間差の上に成り立っていた。

応答がないことに、意味を与える

初期の拡張は任意だった。クライアントが求めても、サーバーが状態応答を送らないことはあり得る。未対応なのか、不都合な情報を出したくないのか、欠落だけでは区別できない。

RFC 6066 の安全性の議論 は、漏えいした鍵を使う攻撃者が拡張に未対応だと装う場合を明記していた。OCSP 検証を必要とするクライアントは、応答サービスに直接問い合わせるか、接続を断念する必要がある。送られてきた応答が検証を満たさない場合には、ハンドシェイクを中止する。応答の欠落と失効の通知は同じではない。

2015 年 10 月の RFC 7633 は、証明書に TLS Feature 拡張を入れて status_request を宣言する方法を示した。通常 Must-Staple と呼ばれる仕組みの基礎である。対応するクライアントは、サーバーの自己説明ではなく、証明書に記された期待と実際の動作を比べられる。

もっとも、すべてのクライアントに全機能の実装を求めた仕様ではなく、別の手段で検証できる場合などの例外もある。世界中のクライアントが一斉に同じ拒否動作をするという意味ではない。それでもサーバー側には具体的な責任が生じる。必要な状態応答が準備される前に新しい証明書を使い始めると、正当に発行された証明書でも期待を満たせなくなる。

形式が変わっても残った構造

2018 年の RFC 8446 は、TLS 1.3 では状態情報を対象の CertificateEntry 内の拡張に載せるとした。古い独立メッセージとは運び方が違うが、署名の権限までサーバーに移ったわけではない。

OCSP stapling の歴史が示すのは、証拠の入手先と証拠を信じる根拠は別に設計できるということだ。ただし、入手を簡単にした後にも、正しい証明書に対応する新しい証拠を届け続ける仕事は残る。ここで挙げた仕様は設計の記録であり、現在の全ブラウザーや CA の対応状況を測ったものではない。

出典

RFC 3546、RFC 6066、RFC 6960、RFC 5019、RFC 7633、RFC 8446。運用責任に関する記述は、これらの要件から導いた分析である。