要約

  • AFRINICの現行資源認証ページは、2020年5月公開の48ページのRPKI認証実務規程、バージョン3.0へ直接リンクしている。
  • 第V.8節は、AFRINICがIANAから「アジア太平洋地域」のIPアドレスとAS番号を管理する権限を与えられたと記す。AFRINICとIANAが示す実際のサービス地域はアフリカとインド洋地域である。
  • APNICの現行CPSには、ほぼ同じ三文から成る終了条項があり、APNICとアジア太平洋が正しく対応している。類似は確認できるが、転載元や作成者は特定できない。
  • これは公開統制文書の不整合であって、証明書、ROA、TAL、資源配分、検証結果、経路障害の証拠ではない。条項単位の訂正・置換記録が要る。

古いPDFが「現行」であり続ける経路

文書の日付だけなら、2020年の誤記をいま扱う理由は弱く見える。だが、現行性を決めるのは年齢ではなく、組織が現在どの文書を公式入口から示しているかだ。

AFRINICのResource Certificationページは、ポリシー文書として Certificate Practice Statement (CPS) を掲げ、CPS へリンクする。履歴版や廃止版という注記はない。

取得したPDFは195,830バイト、48ページで、SHA-256は 2770e175edbd611c798d0036229a05f3e830843dc4ee202e35e5e944db91d5f0 だった。表紙には AFRINIC Certification Practice Statement for the Resource PKI、バージョン3.0、2020年5月公開とある。ファイルのHTTP Last-Modified も2020年5月28日を示した。

問題の文は36ページ、第V.8節 CA or RA termination にある。AFRINICはIANAからIPアドレス空間とAS番号資源をアジア太平洋地域で管理する唯一の権限を与えられた、と書かれている。続いて、その権限に沿って自地域のRPKIを設けたとし、最後にCA機能を別主体へ終了・移行する規定はないと述べる。

同ページは画像としてレンダリングして確認した。検索結果の混線でも、OCRの誤読でも、改ページで別文書が連結された結果でもない。

しかも地域名は補足的な住所欄ではなく、CAの制度上の根拠と終了時の扱いを説明する節に置かれている。だからこそ、文字を直すだけでなく、当該節を誰がどの権限で見直したかが重要になる。

AFRINICとIANAの説明は一致している

正しい地域を探すために、解釈を積み重ねる必要はない。AFRINICのAboutページは、同組織をアフリカとインド洋地域にサービスを提供するRIRと説明する。Service Regionページは、北部、西部、中部、東部、南部、インド洋の六つに分ける。

IANAのRIR案内も、AFRINICをアフリカとインド洋の一部、APNICをアジア・太平洋に対応させている。さらに2005年のAFRINIC認定報告は、アフリカ各国とインド洋地域を列挙し、第5のRIRへの移行を記録している。

したがって、地域の境界をめぐる二つの見解が競合しているのではない。現在リンクされているCPSの組織名と地域名が食い違っている、という一点が確定する。

HTTPヘッダーにも限界がある。資源認証ページのHTMLは取得時に2026年8月20日の Last-Modified を返した。一方、PDFは2020年の日付である。この差は配信されたファイルの状態を示すが、8月に担当者がリンク先や全条項を再審査した証拠にはならない。サイト全体のビルドや移行でもHTMLの日時は変わり得る。

APNICの第5.8節は鏡になる

地域名の出所を考えるうえで最も近い比較対象は、APNICの現行CPSである。

APNICの第5.8節も、IANAからの権限、自地域でのRPKI設置、CA機能を別主体へ移行する規定がないこと、という三段階で書かれている。そこではAPNICとアジア太平洋地域が正しく対応する。

単語の一致だけではない。文の順番と役割がほぼ同じだ。AFRINIC文書がAPNIC文書を基にした可能性、または双方が共通雛形を使った可能性は考えられる。しかし、公開された編集履歴も注釈も承認ログもない。どちらが先か、誰が置換し忘れたかを断定するのは、証拠の範囲を超える。

それでも比較には意味がある。読者は二つの公式文書を並べ、正しい組み合わせを自分で確認できる。さらに、一括置換の危険も見える。Asia-Pacific を Africa and the Indian Ocean に直すことと、隣のCA移行文を維持するかどうかは、別々の判断だからだ。

CPSの誤文はROAではない

RPKIに関する記事では、文書と運用対象を混同しないことが欠かせない。RFC 6484は、RPKIのCertificate Policyと各CAのCertification Practice Statementの関係を定める。CPSはCAがどのような実務を採ると公表しているかを示す重要文書である。

しかし、CPSは資源証明書でもROAでもない。manifest、CRL、TAL、リポジトリの署名済みオブジェクト、validatorの判定でもない。

凍結した資料からは、AFRINIC証明書にアジア太平洋という地域属性が埋め込まれた事実は確認できない。この文章を理由にアドレスやASNが誤配分された証拠も、APNICの権限が失われた証拠もない。信頼アンカーの鍵変更、リポジトリ障害、検証済みペイロード集合の変化も示されていない。

経路についても同じである。あるprefixがRPKI Invalid や NotFound になった、ルータが経路を拒否した、到達性が失われた、という測定はない。鍵侵害、会員ポータル障害、CA停止の報告もない。

逆に、運用事故が証明されないからといって、CPSの誤りが無害になるわけではない。CPSは、依存者がCAの実務を知るために参照する文書である。組織、権限、地域を結ぶ一文が誤っていれば、単語だけが古いのか、節全体が未審査なのか、版管理の問題なのかを外部から区別できない。

終了・移行文にも慎重さが要る。公開CPSが「別主体への移行規定はない」と述べることは確認できる。そこから、内部の災害復旧計画、事業継続策、裁判所や法令に基づく緊急権限まで存在しないとは言えない。外部CAへの制度的移行と、同一組織内の復旧は同義ではない。

上書きより小さな訂正票

見た目だけを直すなら、同じURLに地域名を変更したPDFを置けばよい。だが、それでは変更前後の関係が消える。

必要なのは大規模な監査報告ではなく、条項単位の訂正票である。文書ID、旧版と新版の番号、両PDFのSHA-256、第V.8節の旧文と新文、承認者の役割、承認権限、承認・公開・発効の各時刻を載せればよい。

変更の性質も分ける。地域名の修正は編集上の訂正であり得る。CA移行文の変更は、実務またはガバナンス変更になり得る。ひとつの「更新済み」という表示にまとめると、何が変わったか分からない。

移行文を変えない場合でも、reviewed and retained に相当する状態を明記するべきだ。別文書が統治するなら、その文書を特定する。変更するなら、根拠と発効日を示す。隣接文を沈黙させたまま地域名だけ直すと、節全体を再確認したのか判断できない。

長期URLは新版を指し続けてよい。ただし、そこで配信されるバイト列が訂正票の新ハッシュと一致することが必要だ。旧3.0版には不変の履歴URLを与え、変更通知から新旧双方へリンクする。第三者がHTTP status、ETag、byte length、SHA-256、条項本文を読み戻せれば、訂正は再現可能になる。

証明書、鍵、リポジトリ、サービス状態に変化がなければ、影響欄には document correction only と書ける。「RPKIに問題はない」という広い表現より、変更が文書だけだったと限定する方が検証しやすい。

2020年という日付から分からないこと

バージョン3.0が2020年に作られた事実だけでは、誤記がいつ始まったかは分からない。バージョン1.0や2.0にも同文があったのか、内部レビューで指摘済みなのか、別の未リンク文書が優先されるのかも、今回の資料からは確定できない。

本記事が扱う現在性は、2026年8月31日時点の入口である。AFRINICが資源認証の読者に示しているリンクが、この3.0版へ到達する。そのため、文書自体が古くても、公開上の選択は現在の状態として検証できる。

責任者の氏名も推測できない。内容、法的承認、技術的ホスティング、ウェブ配備は別部署かもしれない。訂正票に必要なのは、誤記の犯人探しではなく、いま変更を承認できる責任ある役割である。

また、APNICの文章と一致するからといって、APNICのCA移行方針がAFRINICにも適切だとは限らない。地域訂正を利用して継承制度まで静かに変えるべきではない。後者は別の決定記録を必要とする。

正確さと抑制を同じ記録に置く

修正完了の条件は、検索結果から Asia-Pacific が消えることではない。読者が現行CPSの版とハッシュを確かめ、正しい地域を読み、移行文の扱いを知り、旧3.0版をAFRINIC自身の履歴から取得できることだ。

そうすれば、組織は文書不備を運用障害へ誇張せずに是正できる。依存者は機密の鍵情報や設備情報を求めずに変更を確認できる。将来の監査者は、どの時点でどの本文が公開されていたかを再構成できる。

安定したURLは、安定した内容管理の証拠ではない。URLの後ろにあるバイト列を、版、承認、旧版、変更理由と結び付けて初めて、公開信頼文書になる。

情報源