要約

  • RFC 9654 の実装要求者は、暗号学的に強い擬似乱数生成器で最低 32 オクテットの nonce を生成する。応答内の完全一致は、その応答を今回の要求へ結び、別の nonce を持つ過去応答の再利用を防ぐ。
  • 一致は、応答者の失効情報源が最新であること、署名者が正当に委任されていること、CertID が目的の証明書を示すこと、時刻条件やアプリケーション許可が成立することまでは証明しない。
  • 監査可能な記録は、生の要求・応答、nonce の生成と比較、署名権限、証明書識別子、署名時刻、上流データ水位、検証方針、最終セッション動作を分離して残す。

正しいデコードが開く一枚目の扉

RFC 9654 の nonce は、要求では requestExtensions、応答では responseExtensions に置かれる。OID は 1.3.6.1.5.5.7.48.1.2 で共通し、拡張の extnValue という外側の OCTET STRING が、Nonce という内側の OCTET STRING を包む。

この二重構造は単なる表記ではない。実装は OID を見つけても、外側と内側を取り違え得る。ログは値の先頭だけを保存し得る。比較関数は文字列表現を正規化して、元のオクテット列を失い得る。

したがって「nonce を認識した」では足りない。要求 DER とハッシュ、応答全体とハッシュ、拡張位置、外側と内側の長さ、取り出した値、完全一致の結果を保存する。IANA の PKIX モジュール識別子 111 と 112 は ASN.1 文法を調整するが、配備済みパーサーの挙動までは証明しない。

長さの三つの意味

型が許す範囲は 1～128 オクテットである。新仕様を実装する要求者は最低 32 を使う。拡張をサポートする応答者は 16～32 を受理しなければならない。1～15 または 33～128 については、nonce を付けずに応答できる。0 または 128 超は malformedRequest で拒否する。

最大値 128 は「常に使うべき強度」ではない。32 を上限としていた RFC 8954 との互換性があり、古い実装が長い値を処理できるとは限らない。RFC 9654 は長い値を必要とする暗号方式へ余地を与えつつ、必須相互運用範囲を狭く明示した。

試験は 16、32、33、128 と、不正な 0、129 を分けるべきである。受理して反映した、受理したが省略した、形式不正で拒否した、という結果は異なる。単一の成功率では運用判断ができない。

乱数源はメッセージより前にある

RFC 9654 は RFC 4086 に基づく暗号学的に強い擬似乱数生成器を要求する。予測可能な nonce なら、攻撃者は将来値を持つ応答を先に取得できる。小さ過ぎる空間なら候補を列挙できる。

どちらの場合も、後の比較は真になり得る。失われたのは「今回の要求のために新しく、事前に予測できなかった」という前提である。よって記録は生成器の種類、健全性、生成時刻、長さ、再利用の有無、再起動後の系列まで含める。

これは実行コードの優位が求める区別である。仕様への準拠宣言ではなく、実際にロードされた生成器と実際の値の履歴が、その実行の証拠になる。

最新の応答と最新の根拠は同じではない

RFC 9654 は、要求者の nonce を含む応答が、古いコピーではなくサーバーからの最新応答であることを保証すると説明する。この主張の対象は応答である。サーバーが CA から受け取る失効データの到着時点ではない。

RFC 6960 は producedAt、thisUpdate、nextUpdate、revocationTime を分ける。署名した時、状態が正しいと把握した時、新情報を提供する時、失効した時は別の事実である。CertID も発行者名ハッシュ、公開鍵ハッシュ、シリアル番号を通じて対象を示す。

CA が 10:00 に失効を公開し、応答者のレプリカが 10:05 に取り込むとする。10:03 に応答者は新しい nonce に対して新しい署名応答を作れる。その応答は要求に対して新しくても、権威ある変更より遅れている。元データの現在性を主張するには、フィードのカーソル、バッチ版、取り込み時刻など別の証拠が要る。

署名者の権限も別である。RFC 6960 は発行 CA、要求者が直接信頼する応答者、または CA が直接委任した適切な証明書を持つ応答者を求める。nonce 一致は委任を作らない。good も、発行実績、証明書有効期間、名前一致、業務上の許可を自動では証明しない。

省略時には別の検証路へ入る

RFC 5019 の大規模環境は、事前生成とキャッシュを重視する。要求ごとの固有応答は再利用性を下げる。そのため応答者は、要求に nonce があっても応答で省略できる。クライアントがサポートを確知しない場合、欠落だけで拒否せず、署名された時刻に基づく検証へ戻る。

この分岐には残余リスクがある。経路上の攻撃者は nonce のない過去応答を返し得る。RFC 9654 は thisUpdate と nextUpdate の間隔を短くすることで窓を狭めると述べる。

監視は「一致」「方針上許された欠落と時刻フォールバック」「不一致」「不正形式」を分け、その後の署名、権限、時刻、アプリ判断を関連付ける。欠落と不一致を同じエラーにすることも、すべてを OCSP 成功にまとめることも誤りである。

一連のレシートを構成する

最初に対象証明書の指紋、シリアル、発行者ハッシュと想定応答者を保存する。次に要求バイト、nonce 生成情報、長さ、値の保護されたハッシュ、宛先を保存する。応答については全バイト、応答状態、応答者 ID、署名者チェーン、委任と署名検証を残す。

結合層では nonce の有無と完全一致を残す。状態層では CertID、状態、各時刻、失効情報、観測可能なら上流フィード水位を残す。ローカル判断では時計、誤差、許容幅、検証器ビルド、方針版、理由コードを残す。アプリ層が証明書パス、名前、許可・拒否、セッション動作で閉じる。

現実の層は、近接した事実を同一視しない。最小初期仕様は共有部分を、符号化、長さ、乱数、比較という検証可能な規則に限定し、取り込み、容量、リスク許容、アプリ判断を責任ある運用者へ残す。

出典