要約

  • Rapportが2026年9月4日に分割したRFC 9286テストの一方は、正常なキャッシュを作った後でca2.mftを削除し、影響を受けたCAのキャッシュ2件を含む合計6件のVRPを期待する。
  • スクリプトには検証器がマニフェスト欠落を警告しなければならないと書かれているが、そのcheck_logfile行は#で始まり、固定コミットではシェルから実行されない。
  • RFC 9286は、理由を示す警告を必須とし人間への通知を推奨する条項と、同じCAインスタンスのキャッシュを期限まで使い続けるよう求める条項を分けている。
  • したがって受入結果には、保持した検証状態と、運用者に届いた意味的な信号を別々に記録しなければならない。片方の成功は、もう片方の証明にならない。

消えたファイルと消えなかった結果

このテストの巧みさは、派手な停止ではなく、証拠だけが静かに古くなる状況を作る点にある。最初の実行では二つのCAがそれぞれ2件のVRPを供給し、合計4件の正常状態を成立させる。次の状態では三つ目のCAを加えたうえで、二つ目のCAに属するca2.mftを削除する。さらにHTTP取得を無効にして依存当事者を再実行するため、検証器は新しいマニフェストを別経路で取り戻せない。

二度目の期待値は6件だ。最初のCAの2件、追加された三つ目のCAの2件、そして取得に失敗した二つ目のCAから以前に検証済みだった2件が並ぶ。この集合は、失敗した取得をCA全体の即時消去に変換しないという性質を検証する。短時間の公開障害によって、ルート起点の判断が突然反転するのを避けるための継続措置である。

そのVRP確認のすぐ上に、別の期待が人間の言葉で残されている。検証器は欠けたマニフェストについて警告しなければならない、というコメントだ。続くFORT向けcheck_logfile命令もソースには存在する。しかし行頭の#により、POSIXシェルは命令ではなくコメントとして扱う。固定したリビジョンが実行時に検査するのは保持後のVRP集合であり、この行を通じた警告の存在ではない。

ここから実装の挙動を推測してはいけない。コメントアウトは、FORTやRoutinator、rpki-client、rpki-proverなどが実際に沈黙した証拠ではない。テスト自体の失敗、VRP期待値の誤り、実運用のRPKIリポジトリでの異常も示さない。なぜ無効なのか、別のCI層が同じ意味を確認しているのか、将来いつ有効になるのかも公開された固定資料からは分からない。確認できるのは、この特定のシナリオの警告断言が当該スクリプトでは動かない、という狭い事実だけである。

RFC 9286が分けた二つの責務

マニフェストは、CA公開点に結び付く証明書、CRL、署名済みオブジェクトの目録に署名を与える。同じ公開点を複数のCAインスタンスが共有することはできるが、一つのマニフェストが記述するのは対応する一つのCAインスタンスだけだ。このため処理単位は単なるディレクトリではない。CA証明書のSIAに記されたマニフェストURIを手掛かりに、インスタンスごとに処理される。

RFC 9286はマニフェストを取得できない場合、取得を失敗として終了し、失敗処理へ進める。その失敗処理では二つの行為を別々に述べる。まず、そのCAインスタンスの処理が終了した理由を含む警告を生成しなければならず、人間の運用者に通知することも推奨される。次に、関連するキャッシュ済みオブジェクトが古くなるか、後の成功取得で置き換えられるまで、それらを使い続けるべきだとする。

この二つは同じ安全策の表裏だが、同じ出力ではない。キャッシュ継続は、取得経路の揺らぎを検証結果の急変へ増幅しない。警告は、現在の結果が新しい取得だけから作られたものではないことを運用者に知らせる。前者は「どの状態で計算を続けるか」、後者は「なぜその状態を使い、誰が注意すべきか」に答える。6件のVRPだけで両方に答えたことにはならない。

実際、データ面が正常に見えるほど信号の必要性は高まる。6件という数は、新鮮な取得がすべて成功した場合と一致し得る。監視が最終集合しか見なければ、2件がキャッシュから運ばれたという来歴の変化は消える。出力の連続性を維持したことが、証拠の連続性まで証明したかのように扱われてしまう。

キャッシュを直ちに捨てない理由も重要だ。公開点の一時的な問題が次回の取得で解消する可能性があるとき、最後に成功した状態を使うことで、依存当事者が有効なルートを無効と解釈したり、その逆を起こしたりする危険を抑えられる。だがこの猶予は無期限の免許ではない。鮮度の期限と再試行があり、故障理由を人が認識できて初めて管理可能な劣化になる。

隣のテストは何を実行しているか

同じ変更で分けられたもう一方のテストは、CA証明書とSIAのマニフェストURIを変える。こちらは同一CAインスタンスの一時的な欠落ではなく、壊れたSIAを伴うCA識別の変化を扱う。期待するVRP集合から影響CAを外し、兄弟CAと新しいCAの結果を残すだけでなく、FORTのログに対する警告チェックを実際に実行する。

この比較から、どの製品が正しいかを裁くことはできない。しかし、Rapportが少なくとも二つの能力を持つことは読み取れる。CAインスタンスの連続性を区別して期待集合を変えられること、そして隣接シナリオでは運用者向け診断をテスト命令として確認できることだ。同一インスタンスの回退に不足しているのは、フレームワークそのものではなく、結果集合と診断を一つの受入証拠に結び付ける実行部分である。

さらに、どんな警告でも一行あればよいわけではない。壊れたSIAでは影響CAのVRPを外し、同一インスタンスの欠落ではキャッシュを残す。両方に警告があっても、原因と回退判断は違う。警告は該当CAインスタンス、取得失敗の種類、キャッシュ採用または除外の決定を指さなければ、最終結果との整合を確認できない。

ログ文言ではなく意味を固定する

コメントを外し、FORTの英文をそのまま正規表現で探すだけなら変更は小さい。だが複数の依存当事者を扱う試験では、製品固有の句読点や単語順を共通契約にするのは脆い。ログの改善や版更新だけでテストが壊れれば、重要な警告確認が保守負担として再び無効化される誘因も生まれる。

Rapport側で固定すべきなのは文ではなく意味的なイベントである。最低限、マニフェスト取得不能という理由分類、影響したCAインスタンスへの参照、キャッシュを使い続けるという判断、キャッシュの年齢または鮮度期限、重大度、発行時刻、通知またはエスカレーションの扱いを要求する。各製品用アダプターは、構造化イベント、メトリクス、システムログ、文書化された診断のいずれかをその意味に対応させればよい。

柔軟性は情報を薄めることではない。時刻の表記、フィールドの順序、メッセージの自然言語は変わってよい。一方で、ただの一般エラーに落ちたり、CAインスタンスを特定できなかったり、キャッシュ利用を最終件数から推測させたりする出力は合格にしてはならない。移植性は、必須の意味と自由な表現を切り離すことで得られる。

二列の受入レシート

最終的な緑か赤かとは別に、各実行は二列のレシートを残すべきだ。第一列はキャッシュ判断である。影響CAインスタンス、現在の証明書とSIAの指紋、最後に成功した取得、キャッシュ対象集合またはダイジェスト、鮮度期限、今回の失敗理由、保持・除外されたVRP差分、兄弟CAの分離、次回再試行を記録する。

第二列は運用者信号である。検出した理由分類、関連CA、明示された回退判断、キャッシュ年齢、重大度、イベント時刻、予定した通知経路に届いたかどうかを記す。それぞれの列には元の証拠への参照が必要だ。レビューする人が、6件の期待集合を確かめた場所と、警告の意味を確かめた場所を別々にたどれるようにする。

この形式なら、「VRPが残ったから警告も出たはず」という省略も、「警告があったから正しいキャッシュが残ったはず」という省略もできない。二列が揃ったときだけ、同一CAインスタンスに対するRFCの姿勢を完全にテストできる。状態は連続して提供され、その来歴が劣化した事実は人から隠れない。

CAインスタンスへの結合は特に重要である。一つの公開点を複数インスタンスが共有し得るため、同じ場所にあったというだけでキャッシュの所有を決められない。証明書とSIAの指紋、最後の成功状態、兄弟CAの分離が、古いオブジェクトを別インスタンスへ誤接続するのを防ぐ。警告側にも同じ参照があれば、運用者はどの検証枝が猶予状態にあるのかを判断できる。

公開ソースが示す限界

LACNICはRapportを依存当事者テスターとして紹介し、リポジトリも早期開発段階と説明している。早期の道具だからこそ、公開されたシェルテストは価値がある。規範文をどの単位で実行可能な期待へ変えたか、そしてどの境界がまだ実行されていないかを、外部から検証できるからだ。

確認できる結論は限定的で明確だ。2026年9月4日の変更は、CA証明書とSIAが変わる場面と、同一CAインスタンスでマニフェストだけが欠ける場面を分けた。後者はキャッシュ2件を含む6件のVRPを要求する。警告すべきだという説明はあるが、そのチェック行はコメントである。RFC 9286は警告とキャッシュ継続を別の要求として記し、隣のテストは警告チェックを実行する。

それ以上は断定できない。ある検証器が現実に警告を出さなかったとは言えず、LACNICがこの試験を認証や本番判定に使うとも言えない。コメントの理由も分からない。だから次の改善は非難ではなく測定である。キャッシュ継続と運用者信号に別々の合否を与え、同じレシートで提示することだ。

出典