要約

  • RFC 9919 では nextUpdate が必須であり、欠けている応答や、クライアント時刻がその期限を過ぎた応答は拒否しなければならない。
  • 正しい署名が証明するのは、認可された応答者と署名対象の完全性である。古い good の延命や HTTP ヘッダーの真正性ではない。
  • 監査には応答そのものに加え、時計の品質、許容差、キャッシュ経路、検証方針、最終的なアプリケーション動作が必要になる。

失効したのは署名ではなく、主張の効力である

キャッシュから返った OCSP 応答の署名が通る。ステータスは good。HTTP も成功している。それでもクライアントが拒否すべき場面がある。現在時刻が署名済みの nextUpdate を越えていた場合だ。

RFC 9919 が対象とするのは、数百万から数億の証明書と、それを上回る利用者を抱え得る PKI である。応答を事前に作り、クライアントやネットワークで保存し、別のプロトコル交換に載せれば、帯域、往復、応答者の計算負荷を下げられる。毎回の問い合わせに専用応答を作る中央サービスへの依存も減る。

ただし、キャッシュされた物体はリアルタイムの会話ではない。thisUpdate は応答者がその状態を正しいと知った最新時刻、producedAt は署名時刻、nextUpdate はより新しい情報が得られる期限を示す。RFC 9919 はこの nextUpdate を必須にした。欠落は拒否、期限超過も stale として拒否である。

暗号学的な署名は、その後も検証できるかもしれない。期限が切れたのはビット列の真正性ではなく、「現在の受入れ判断に使える」という限定的な効力だ。新しい応答では既に revoked になっている可能性がある。

good は万能な安全証明ではない

RFC 6960 における good の意味は狭い。最低限、そのシリアル番号を持ち、有効期間内にある証明書について、応答者が失効済みと認識していないことを表す。実際に発行された証明書かどうかまで常に保証するものではない。証明書自体の期間、信頼パス、サービス名、利用者の権限も別に検証される。

署名応答を受け入れるには、対象証明書との対応、署名、署名者が当該 CA のために応答する権限、thisUpdate の新しさ、nextUpdate が現在より後であることを確認する。アプリケーションの認可はさらにその外側にある。

運用画面の「OCSP 成功」は、この連鎖を隠す。到達できたこと、確定ステータスを得たこと、認可された署名者だったこと、期限内だったこと、証明書の全検証が通ったこと、接続を許可したことは同じ事実ではない。障害記録では分けて残す必要がある。

ローカル時計がセキュリティ判断に参加する

リクエストごとの nonce は応答を一つの問い合わせに結び付ける反面、事前生成や共有キャッシュと相性が悪い。RFC 9919 は通常、リクエスト拡張を付けないよう求める。nonce を送ったのに応答側が返さなくても、応答者が nonce 対応だと既知でない限り、その理由だけで拒否せず時間検証へ戻る。

そこで正確な時刻が必須になる。クライアントは現在時刻が thisUpdate と nextUpdate の間にあることを確かめる。小さな許容差は使えるが、環境で得られる同期精度に応じて決める値であり、無条件の猶予ではない。

時計が進み過ぎれば有効な応答を早期に拒否する。遅過ぎれば、失効後も期限切れの good を受け入れ得る。したがって、時刻同期プロセスの稼働だけを監視しても足りない。検証プロセスが実際に使った時刻、オフセットや不確実性、許容差、直前の時刻跳躍を記録すべきである。

HTTP の鮮度と OCSP の鮮度は別物である

小さな OCSP リクエストは、キャッシュ可能にするため GET を使う。応答者は Date、Last-Modified、Expires、ETag、Cache-Control を付ける。max-age を nextUpdate より前に置けば更新を分散でき、must-revalidate はキャッシュが意図的に古い応答を返すのを抑える。

しかし RFC 9919 は、これら HTTP ヘッダーが暗号学的に保護されていないと明記する。ヘッダーは配送とキャッシュの手引きであり、証明書ステータスの根拠は OCSP 応答内の署名対象値である。キャッシュが新鮮と判定しても nextUpdate を越えた状態主張を復活させられない。

逆に、プロキシが期限切れオブジェクトを返したときはキャッシュを迂回して再取得できる。それでも取得した新しい応答は、対象、署名者権限、署名、時刻、状態の全検証を受ける。

TLS stapling も配送主体を変えるだけだ。TLS サーバーは OCSP 応答を運ぶが、状態の作者にはならない。クライアントは署名済み時間枠を独立して評価する。

SHA-256 への移行を過大評価しない

RFC 9919 は RFC 5019 を廃止し、新しいクライアントに CertID の発行者名と発行者鍵のハッシュとして SHA-256 を要求する。古い SHA-1 対応を残し続ける実装上の複雑さと攻撃面を減らすための移行である。

ただし SHA-256 は鮮度を証明しない。強い識別ハッシュを持つ応答も期限切れになる。現代的な署名も、署名者の権限やクライアント時計を補わない。アルゴリズム移行、状態検証、最終認可は別々に受け入れるべき作業である。

結果ではなく判断の領収書を残す

証明書の指紋とシリアル、発行者名・鍵ハッシュとアルゴリズム、OCSP 応答の完全なバイト列とハッシュ、応答者 ID、署名者チェーンと認可結果、producedAt、thisUpdate、nextUpdate、状態と失効情報を保持する。

さらに、受信時刻、利用した時計の情報源と不確実性、許容差、nonce の扱い、検証器の版と方針、受入れ・拒否理由、アプリケーションの後続動作を結び付ける。HTTP のキャッシュノード、Age、ETag、Expires、迂回再試行は配送証拠として有用だが、署名済み状態の一部ではない。

HTTP は到着を示す。署名済み OCSP は、誰がどの期間について何を述べたかを示す。ローカルログは、どの時刻と方針で判断したかを示す。アプリケーション記録は、その判断が何を動かしたかを示す。この四層を一つの緑色に戻してはいけない。

情報源