要約

  • NROが2025年12月に更新したRPKIロードマップは、短期のTrust Anchor証明書を中核機能とし、当時の提供者をAPNIC、ARIN、LACNIC、全RIRでの提供目標を2025年末としていた。
  • 2026年8月29日、AFRINICのTALから取得できた自己署名ルート証明書は、2020年3月30日から2030年3月28日までの有効期間を持っていた。
  • これは公開記録の未接続を示すが、障害、経路の無効化、検証失敗を証明しない。確認した資料には「短期」の上限やAFRINIC固有の例外判断がない。
  • 実装記録には、機能定義、発行証明書、フィンガープリント、TAL鍵の継続性、リポジトリ公開、Relying Partyの取得観測、例外、切り戻し、訂正履歴を結び付ける必要がある。

期限を過ぎても、表と証明書の間が空いている

NROのロードマップで問題になるのは、わずか一行である。機能名は「Short-lived TA certificates」。当時すでに提供していたRIRとしてAPNIC、ARIN、LACNICが並び、全RIRでの提供時期は「End of 2025」と記されている。

ページの最終更新日は2025年12月2日だった。したがって、この表は年末直前の計画であって、期限後の完了報告ではない。計画表が将来を指すこと自体は当然だ。問題は期限が過ぎた後、実装済み、例外付き、延期、定義変更、未完了という別々の状態を区別する記録が追加されていないことにある。

AFRINICの公開物をたどると、より具体的な状態が見える。2026年8月29日、公開TALは取得可能で、その先頭URIはRPKIリポジトリのAfriNIC.cerを指していた。自己署名証明書の名称はAfriNIC-Root-Certificate、シリアル番号はE5CF72BA6C7E9E28。有効期間は2020年3月30日から2030年3月28日までだった。

ファイルは存在し、URIは応答し、フィンガープリントも確認できた。ここからサービス障害を読み取ることはできない。確認できるのは、共通目標から8カ月後にも約10年の有効期間を持つ証明書が配布されており、その状態と「短期化」の関係がロードマップ上で説明されていないことだけだ。

穏当な説明はいくつもある。ロードマップが更新されていないのかもしれない。AFRINICは別の資料で定義した方式を採用しているかもしれない。置き換えを試験中、延期中、あるいは例外扱いとしている可能性もある。既存証明書を管理された再発行時点まで維持する設計かもしれない。今回の公開資料では、どれを採るべきか判断できない。

つまり、まず問うべきは故障ではなく証拠の接続である。期限を掲げた側が、その後の状態を利用者の推測に委ねるべきではない。

「短期」の定義がなければ監査判定にはならない

約10年という期間を「短期」という語と比べれば、目標未達と断言したくなる。しかし、公開資料が示していない基準を記事側が作ることはできない。

ロードマップには最大有効期間、通常の更新周期、新旧証明書の重複期間、例外を認める主体が書かれていない。RIR間の機能差を整理した基準文書にも、AFRINICについて日付付きの受入記録はない。2年、1年、90日といった数値を採用条件として扱う根拠はない。

それでも、観測した証明書には意味がある。宣伝文句でも予測でもなく、AFRINIC自身のTALが示す場所から取得した運用上の成果物だからだ。これは特定時点の事実を提供する。一方で、欠けている機能定義や組織としての受入判断を代行するものではない。

ここでは三つの記録を分けなければならない。コミットメントは何を実現する予定かを示す。技術成果物は何が実際に配布されていたかを示す。実装確認記録は、その成果物が合意された条件を満たしたか、例外や延期があるかを示す。これらを一つにすると、発表が実装の代わりになってしまう。

状態語は簡潔でよい。「公開定義どおり完了」「特定の例外付きで完了」「新期限へ延期」「別の制御策に置換」「未完了」で足りる。更新がないことは、六つ目の実装状態ではない。

TALが固定するのは鍵であり、同一証明書ではない

RFC 7730を読むと、証明書の有効期間を短くしても、各運用者に新たな信頼判断を毎回配り直す必要がない理由が分かる。

TALには取得先と、Trust Anchor証明書を検証するための公開鍵情報が含まれる。参照先は現在有効な自己署名RPKI CA証明書で、その公開鍵はTAL内の鍵と一致しなければならない。通常の更新や資源変更による再発行ではTrust Anchor鍵を安定させ、再発行した証明書を同じ安定URIから取得できるようにする。

したがって、鍵の継続性と証明書の有効期間は別の問題である。AFRINICはTALで固定された信頼関係を保ちながら、日付や資源を新たに表す証明書を発行できる。証明書更新は、直ちに鍵交換を意味しない。

同時に、実装は複数段階になる。正しい証明書を発行し、所定の場所で公開し、Relying Partyソフトウェアが取得し、現在有効か、自己署名か、TAL鍵と一致するかを確かめ、ローカルの受入処理を行う必要がある。RFC 7730は、リポジトリ再同期時とキャッシュ済み証明書の期限前に取得と確認を行うよう述べている。

よって「短期証明書を発行した」だけでも移行全体の成功は証明できない。必要なのは、有効期間ポリシー、発行、鍵一致、公開、限定された取得観測、例外、訂正経路がつながった記録だ。

この記録を経路状態と混同してもいけない。今回の資料には、経路がRPKI Invalidになった、ルーターがプレフィックスを拒否した、リポジトリ更新が失敗した、誤ったオブジェクトがキャッシュされたという証拠はない。それぞれ別の観測が必要である。

有効期間を縮めても、リスクは消えずに移動する

短期証明書の利点は、「短いから安全」という単純なものではない。有効期間を短くすれば、古い状態が現行として受け入れられる期間を制限できる。更新を日常的に実行し、仕組みを定期的に試すこともできる。

ただし、その効果は自動化、公開、取得が確実に働くことを前提とする。頻繁な再発行は不具合を早く見つける機会を増やす一方、期限直前の発行遅延や公開障害を直す時間を短くする。

長期証明書は更新の回数を減らすが、古い資源状態や日付表現を長く許容する。選択肢は安全と利便性の二択ではない。どの障害を、どの頻度と時間幅で引き受けるかという配分である。

だから「実装済み」は、発行可能なコードが存在するという意味にとどめてはならない。どの本番証明書が方針を示すのか、移行開始日はいつか、新旧状態の重複はどう扱ったか、公開先をどう確認したか、どの検証器群を観測したか、次回発行が間に合わない場合の切り戻し条件は何かまで示すべきだ。

秘密鍵、HSM構成、攻撃に利用できる手順を公開する必要はない。日付、ハッシュ、結果区分、集計値、観測範囲で十分な説明ができる。

必要なのは小さな実装確認記録だ

最初に「短期」を定義する。通常の有効期間、更新を始める時期、重複ルール、例外承認者を記す。従来より短いという相対基準なら、比較対象も明記する。

次に公開済みの証明書情報を並べる。発行RIR、シリアル番号、SHA-256フィンガープリント、notBefore、notAfter、リポジトリURI、TALとの公開鍵一致である。

さらに、権威ある公開点、観測したRelying Partyの標本、測定外の母集団を分離する。標本で成功したことを、インターネット上の全検証器が更新したという主張に拡大してはならない。

例外については、識別子、理由区分、責任者、再確認日、終了条件を示せばよい。機密の検討内容は守れる。訂正は上書きではなく追記とし、誤った指紋や変更された日付、機能の再分類があっても以前の状態を残す。

五つのRIRの約束をAFRINICで観測する

NRO RPKI Programは調整の仕組みである。定義をそろえ、不要な差を減らし、複数地域で資源を持つ運用者が基本機能を比較しやすくする価値がある。

しかし、NROがAFRINICの認証局を運用するわけではない。AFRINICがTrust Anchorを発行・公開し、Relying Party開発者が取得と受入の動作を実装し、ネットワーク運用者が検証結果を経路ポリシーにどう使うかを決める。

結論は限定される。AFRINICの証明書は、共通目標に対して再現可能な観測点を提供する。AFRINICのRPKIが壊れていることも、NROが実装状況を偽ったことも証明しない。2025年末の目標と、定義された条件の下で受け入れられたAFRINICの本番状態との間に、公開証拠が欠けていることを示す。

修正は難しくない。NROは古い行を履歴として残し、定義、RIR別状態、証拠日、例外を追記できる。AFRINICは有効期間ポリシーと次回発行の限定的な受入事実を公開できる。Trust Anchorの運用は平穏であるべきだ。その実装履歴まで曖昧である必要はない。

Sources