要約

  • RFC 6487は、RPKIリソース証明書のAuthority Key IdentifierにauthorityCertIssuerとauthorityCertSerialNumberを含めることを禁じる。一方、一般のX.509プロファイルであるRFC 5280は両者を任意フィールドとして定義している。
  • Barryのコミット994a598はauthorityCertIssuerを配列必須のGeneralNamesパーサーに接続した。翌日のRapportコミットb1a59aは、従来の単一文字列を一つのrfc822Nameを含む配列へ変更し、FORT向けの期待ログも対象フィールドに合わせた。
  • 実行順はBarry、relying party、ログ確認、VRP確認である。ソースはこの設計を示すものの、公開された実行ログ、デコード済み証明書、リリースに結びついた結果は確認できない。
  • Rapportは四つの検証器セレクターを記載しているが、このテストでフィールド名まで照合するのはfort2の場合だけだ。他の検証器では空の出力が影響を示しても、拒否理由までは特定しない。

不正な入力を作れなければ、検証器は試されない

規則そのものは明確だ。Authority Key Identifierは、証明書を発行者の公開鍵へ結びつける拡張である。RFC 6487では自己署名証明書を除いて必須で、非クリティカルとされ、authorityCertIssuerとauthorityCertSerialNumberは存在してはならない。土台となるRFC 5280では、この二つは任意の構成要素として定義され、利用する場合は対で現れる。RPKIは一般PKIXより狭い選択肢を採ったことになる。

負の適合性テストは簡単に見える。禁止メンバーを持つCA証明書を作り、その下にROAを置き、検証器が経路起源情報を出さないことを確認すればよい。しかし最初の「作る」が成立しなければ、後段は別の事象を測る。生成器が記述を読めない、フィールドを落とす、証明書を書き出す前に停止する。そのいずれでもVRPは空になり得るが、検証器の準拠性は何も分からない。

Barryはまさに入力を作る役目を担う。LACNICは2025年、鍵と値の記述から正常または意図的に異常なRPKIリポジトリを生成するツールとしてBarryを紹介した。Rapportはそれをrelying partyに与え、出力を検査する。再現しにくい境界条件を自動化できる一方、生成器も証拠の一部になる。

GeneralNamesが要求する形

2026年9月1日のBarryコミット994a598321336baf1767f0fbfb460ed96c29fe4fは、AKIのauthorityCertIssuerを実装した。ext.cではこのフィールドがft_gnames型に関連付けられている。field.cのparse_gnamesは入力が集合または配列であることを確認し、要素数に応じてASN.1のGeneralNameを確保し、各要素をオブジェクトとして解釈する。配列でなければ、「集合／配列が必要」というエラー経路へ進む。

同じコミットで加わったBarryの機能テストは、rfc822Name、iPAddress、registeredIDの三要素を配列に並べる。これは適合するRPKI証明書の例ではない。生成器がGeneralNameの複数の選択肢を符号化できることを確かめる材料だ。

修正前のRapportフィクスチャはauthorityCertIssuer = "CN=Fake Issuer"だった。配列ではなく単一の文字列である。現在のパーサーと照合すれば、旧フィクスチャが現在の入力契約に合わないという限定的な判断はできる。ただし、過去のBarryバイナリで実際にどう動いたか、そもそもその組み合わせが実行されたかまでは分からない。公開されたランタイム証跡がないからだ。

翌2日のRapportコミットb1a59a39ea3b3f8ddc66571a7177c8afb1d0967cは、値を一要素の配列へ変更した。中身はtype = rfc822Name、valueは例示用メールボックスの文字列である。このメール表現が発行者名として自然かどうかは問題ではない。RPKIプロファイルはメンバーの存在そのものを禁じる。修正の意味は、Barryの型体系で禁止状態を組み立てられる形になったことにある。

診断名も一つずれていた

従来のrun.shは、FORTのログにauthorityCertSerialNumberを含むメッセージがあることを期待していた。フィクスチャが追加しようとしたのはauthorityCertIssuerである。修正後はログ期待値もissuerフィールドを指す。入力と診断の対象が初めてそろった。

修正後の順序は読みやすい。まずrun_barry、次にrun_rp、その後にcheck_logfile、最後にcheck_vrpsである。監査可能な結果なら、それぞれに別の受領記録が必要になる。Barryのバージョンと終了状態、生成証明書のハッシュとAKIのデコード、検証器の製品名・バージョン・設定・トラストアンカー、観測した拒否信号、期待VRPと実際VRPのハッシュである。

今回固定した公開情報には、その一式がない。GitHub上でb1a59aのcheck runはゼロで、Rapportのタグとリリースも見当たらない。これは開発者が手元で何も試していないという証明ではない。外部の読者が、ソース修正を実行済み・再現可能・版管理済みの結果として扱えないという境界を示す。

空のVRPは結果であって理由ではない

check_vrpsは引数から期待ファイルを作る。このテストは引数なしで呼ぶため、期待ファイルは空になる。検証器のCSV出力は共通形式へ整形、ソートされ、空ファイルとの差分を取られる。差分がなければ、ファイル出力にVRPが一件もなかったことが分かる。

これは必要な確認だ。異常なCA証明書の下にはROAがあるため、そこからVRPを採用してはならない。ただし空集合への道は一つではない。禁止AKIを正しく拒否した場合も、リポジトリ取得に失敗した場合も、別の欠陥でチェーンが壊れた場合も、誤ったTALを使った場合も空になり得る。生成されたオブジェクトと実行記録がなければ、空という結果は原因を選別しない。

FORTについては、このテスト固有の手掛かりがある。呼び出しはcheck_logfile fort2で、helperは現在のRPが指定された名前と一致しない場合、ログを調べずに戻る。したがってauthorityCertIssuerを名指しする厳密な診断確認はFORT 2専用だ。

同じリビジョンのREADMEには、fort2、routinator、rpki-client、rpki-proverの四セレクターがあり、一回の実行では一つを対象にすると書かれている。アダプターが四つあることと、全テストが四種類の同等な証拠を持つことは別である。他の三つでもVRPが空かは比較できるが、ソース上はフィールド単位の拒否理由を同じ精度で検査していない。

「合格」を三つの状態に分解する

運用者が使える適合性表は、少なくとも構築、判断、出力を別欄にすべきだ。構築欄にはBarryのコミットとバイナリ指紋、フィクスチャのハッシュ、終了コード、生成証明書、AKIのデコードを置く。判断欄には検証器のバージョンと設定、TAL、安定したエラーコードまたは診断を置く。出力欄には期待集合と観測集合のハッシュを置く。

すべての検証器に同じログ文言を求める必要はない。人間向けログを安定APIとみなさないプロジェクトもある。構造化エラー、製品固有のコード、あるいは「ペイロードは受理されなかった」という範囲の狭い結論でもよい。比較可能性は同じ文字列からではなく、各欄が証明できる範囲を正確に書くことから生まれる。

さらに、ソースにテストが存在する状態、特定ビルドで実行された状態、版の付いたスイートに結果が含まれる状態を分けたい。第一段階は設計レビュー、第二段階は再現、第三段階は導入判断に対応する。一つの緑印でまとめると、動き続けるmainブランチが過去の保証まで書き換えてしまう。

証明書のデコードが二つの世界をつなぐ

不足している証拠の中で、最も小さく効果が大きいのは、Barryが出力した証明書そのものとAKIの独立デコードである。フィクスチャは作成者の意図を示し、パーサーは受理できる入力形式を示す。DER成果物だけが、検証器へ渡ったバイト列に何が入っていたかを示す。証明書のハッシュ、デコードツールの版、観測したフィールドを一組にすれば、意図と実体の間の隙間が閉じる。

これはBarryの能力とRapportによる能力の利用を分けるためにも必要だ。994a598はGeneralNamesの処理機構を追加し、機能テストも備えた。b1a59aの配列はその契約に沿う。だが、対象ランでどのBarryバイナリが選ばれ、どの設定が有効だったかは、成果物なしには固定できない。ソースの整合性は重要だが、実行時の同一性とは別の軸である。

受領記録は大規模でなくてよい。入力ファイル、Barryと検証器の版、生成オブジェクト一覧、開始・終了時刻、終了コード、診断分類、VRPの期待値と実測値を小さな機械可読マニフェストにまとめればよい。CIジョブやリリースへ結び付ければ、ログ画面のスクリーンショットより長く検証可能な証拠になる。

LACNICの2025年12月の記事はBarryとRapportを初期段階と表現し、当時はFORTを中心に説明した。後のREADMEは四セレクターを挙げる。これは時間を隔てた成長の記録である。古い記事で現在の能力を否定しても、現在の一覧で過去の四製品分の結果を作り出してもいけない。

現時点で言える最も強い結論は控えめだ。BarryはauthorityCertIssuerを組み立てる機構を得た。Rapportはその型に合わせてフィクスチャを直し、FORTの診断名も対象に合わせた。ソース上のテストは整った。しかし、FORTを含む四つのrelying partyでテストが通ったとする公開証明は、ここにはない。

出典

  1. LACNIC Blog「Open-Source Projects at LACNIC」: https://blog.lacnic.net/en/open-source-projects-lacnic/
  2. Barryコミット994a598: https://github.com/LACNIC/barry/commit/994a598321336baf1767f0fbfb460ed96c29fe4f
  3. Barryのパーサーとフィールド接続: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/field.c および https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/ext.c
  4. BarryのGeneralNamesフィクスチャ: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/test/functional/tests/gnames.rd
  5. Rapport修正コミットb1a59a: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c
  6. 修正後のフィクスチャとrunner: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd および https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  7. RapportのhelperとREADME: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tools/checks.sh および https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/README.md
  8. RFC 6487: https://www.rfc-editor.org/rfc/rfc6487.html
  9. RFC 5280: https://www.rfc-editor.org/rfc/rfc5280.html
  10. 修正前の69da5feにあるフィクスチャとrunner: https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd および https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  11. 修正コミットb1a59aの変更ファイル: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/checks
  12. main上のフィクスチャパスの履歴: https://github.com/LACNIC/rapport/commits/main/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd
  13. Rapportのタグとリリース: https://github.com/LACNIC/rapport/tags および https://github.com/LACNIC/rapport/releases