要約

  • RFC 9919は、事前生成したOCSP応答をクライアント、プロキシ、レスポンダーでキャッシュする。だがHTTPヘッダーは暗号学的に保護されず、キャッシュの指針にしか使えない。
  • 受理には、対象証明書との対応、署名と署名者権限、署名内のstatus、thisUpdate、nextUpdate、正確なクライアント時計が必要である。
  • 新鮮なgoodも限定的な失効情報にすぎない。発行、証明書全体の有効性、アプリケーション権限、処理結果までは証明しない。

キャッシュは答えを運ぶが、答えを作らない

何百万もの証明書を扱う環境で、照会ごとに新しい署名応答を作れば、レスポンダーとネットワークが負荷の中心になる。RFC 9919はRFC 5019を置き換え、応答の事前生成、小さなメッセージ、HTTP GET、クライアントと中間キャッシュの利用を組み合わせる。

その結果、運用画面には二種類の「新しさ」が現れる。HTTPのfreshnessは、保存した表現を再利用できるか、いつ取り直すかを決める。OCSPのfreshnessは、権限を持つ署名者が示した証明書statusが署名済みの時間範囲にまだ入っているかを決める。

Expires、ETag、Cache-Controlは配送に有用だが、OCSP署名の対象ではない。RFC 9919は、これらが改変され得るため、キャッシュ指針としてのみ扱い、最後は署名済みOCSPResponse内の値に依拠するよう求める。キャッシュヒットは新たな照会ではない。同じ証拠を別の経路から受け取っただけである。

署名の中にある三つの時刻

thisUpdateは、そのstatusが正しいとレスポンダーが把握していた時点を示す。nextUpdateは、それまでに新しい情報が利用可能になる時点である。producedAtは応答へ署名した時刻だ。事前生成では、同じ値になる場合があっても意味は別である。

RFC 9919は高負荷プロファイルでnextUpdateを必須にした。クライアントは現在のGMT時刻がthisUpdateとnextUpdateの間にあることを確認し、欠落した応答を拒否し、締切を過ぎた応答をstaleとして拒否する。時計差を吸収する小さな許容値は設定できるが、それは各環境の判断であって、証拠から自動的に生まれない。

ここで端末時計がセキュリティ入力になる。進みすぎた時計は有効な応答を早く拒否し、可用性を落とす。遅れた時計は期限切れのgoodを受理し続け、その間に新しい応答がrevokedへ変わっていても気づかない。署名検証の成功は、比較に使った現在時刻の正しさを保証しない。

nonceはリクエストと応答を結びつけ、再送攻撃を抑える。ただし軽量プロファイルでは拡張を避ける方向があり、期待したnonceがないという理由だけで拒否せず、時間によるfreshness確認へ戻る場面がある。したがって時計、署名時間窓、許容値を一つの判断記録として残す必要がある。

max-ageは混雑をずらし、nextUpdateは効力を閉じる

RFC 9919では、HTTP max-ageをthisUpdateより後、nextUpdateより前に置く。クライアントは最終締切より前から更新でき、レスポンダーもその時点までに新しい応答を用意する。人気証明書の全利用者が同じ秒に戻る負荷集中を避けられる。

しかしmax-ageはstatusの署名ではない。プロキシが外側のヘッダーを変えても、内側のOCSPResponseは変わらない。ヘッダーが何を示しても、署名済みnextUpdateを越えたキャッシュ応答に頼ってはならない。中間キャッシュが期限切れを返すなら、キャッシュを迂回して再試行する。その操作は新しい応答を探すもので、古い応答の寿命を延ばすものではない。

TLSのcertificate status機構で応答を運ぶ場合も同じだ。別HTTP接続やround tripを省けても、handshakeがOCSPの時間窓を更新するわけではない。対象、署名者、status、時刻は添付された応答自身から検証する。

goodが語らないこと

上位のsuccessfulは、レスポンダーが対象証明書について権威ある記録を持ち、正常形式で回答できたことを示す。証明書ごとのgood、revoked、unknownとは別である。

さらにRFC 6960のgoodは、最低限、そのserial numberを持ち有効期間内にある証明書が失効していないという肯定応答だ。証明書が実際に発行されたことや、応答生成時刻が証明書の有効期間内だったことまで必ずしも示さない。認証パス、名前、用途、ローカル権限は別の検査である。

監査可能なreceiptには、対象CertID、応答hash、署名者と権限根拠、署名algorithm、証明書status、producedAt、thisUpdate、nextUpdate、比較した端末時刻、時計ずれ、許容値、nonceの扱いを残す。HTTP側はage、max-age、Expires、ETag、再検証とcache bypassを別欄にする。最終的なアプリ受理や取引結果も別記録である。

RFC 9919はCertIDのissuer name/key hashにSHA-256を要求する。RFC 5019互換の古いクライアントはSHA-1を使い得るが、速やかに移行すべきである。SHA-1要求数は残存クライアント群を示す移行指標にはなるが、freshnessが正しく判定された証明にはならない。

情報源