要約

  • rpki-clientが予告した拒否は8月18日に一つの出来事として到来しなかった。当日のコミットは9.9を準備したが、該当分岐は警告のままで拒否しなかった。
  • 8月21日のportable最新版は9.8のままだった。一方、独立したrpki-clientコンソールはAFRINICオブジェクトを処理し、別のエラーを示しながら、過去のX.509名警告を表示していなかった。
  • 証拠が示すのは管理された互換性移行であり、一斉切替や障害ではない。ROV方針を変える前に、通知、ソース、リリース、導入を別々の時計として読む必要がある。

一つの期限が四つの運用時計になった

2026年2月19日、rpki-clientメンテナーのJob SnijdersはAFRINICのDatabase Working Groupに対し、8月18日火曜日から、X.509の発行者名または主体名のcommonNameがASN.1のPrintableStringで符号化されていない証明書を拒否すると警告した。AFRINICが掲げていた7月31日の解消目標に間に合わなければ、影響を受ける会員のRPKIサービスに支障が出る可能性があるという内容だった。期限を示したメールは公開アーカイブに残っている。

8月18日、上流には確かにPrepare for rpki-client 9.9 releaseというコミットが入った。変更内容はバージョン表記を9.8から9.9へ進めるものだった。しかし、この問題を厳格なエラーにする変更ではない。

該当するvalid_printable_string()では、commonNameがPrintableString以外でも、追加の詳細表示を指定したときに警告するだけである。検証失敗を返すreturn 0は、9.9のバージョン変更時点のソースでも#if 0に囲まれ、コンパイル対象から外れている。コメントは「本来はエラーにすべき」と明記しているが、実行される挙動はまだ警告である。

さらに、8月21日時点のportable版リリース一覧では、4月公開の9.8が最新だった。ソースツリーのバージョン更新、署名済みリリース、OSパッケージ、運用環境への導入は別々の段階だ。2月の予告だけを根拠に「18日に拒否が始まった」とは言えない。

独立バリデータが第四の時計を示した

独立運用のrpki-clientコンソールが、導入状態について最も有用な観測を提供した。8月21日の実行では、rpki-client -c -jがAFRINICを含む世界のリポジトリを取得・検証していた。08時33分UTC以降、AFRINICの二つのmanifestでシーケンス欠落を記録し、その後に期限切れのAFRINIC ROAを二つ報告した。

ログはエラーを隠していなかったが、非PrintableStringの発行者名・主体名に対する過去の警告は表示しなかった。発行者自身の報告より独立性は高いものの、一つの実装の公開ログに特定メッセージがないという観測であり、全AFRINIC証明書の暗号学的な全数検査ではない。

したがって、結論は祝勝ではなく運用上のものに限るべきだ。固定したソースでは期限後も拒否分岐が有効にならず、独立バリデータはAFRINIC素材を処理しながら別種の不具合を示した。この組合せは旧来の露出が減ったことと整合するが、最後の再発行時刻や全Relying Party実装の一致までは証明しない。

コンソールに出た期限切れROAとmanifestのシーケンス欠落は別の問題であり、過去のUTF8String不備との関連を示す証拠はない。

小さな型の違いが、鍵の更新を伴う作業になった

RFC 6487の4.5節は、RPKI資源証明書の発行者名と主体名を規定し、commonNameをPrintableStringで表すよう求めている。AFRINICのホステッドRPKIは2022年のシステム更新後、この値をUTF8Stringとして発行した。

AFRINICは2024年3月の説明で、更新したOpenSSL設定が原因だったとした。文書から想定される既定値と実際の挙動にずれがあり、後のOpenSSL文書修正では、実際の既定マスクがutf8onlyであり、PrintableString互換の型に制限するにはnombstrが必要だと整理された。

署名処理を直せば、新規発行は正しくなる。しかし、すでに署名済みの証明書やオブジェクトは書き換わらない。影響を受けたホステッドCAをrekeyし、そこから派生するオブジェクトを再発行する必要があった。AFRINICは、公開点の不整合を避け、多数のEE証明書を持つ会員への影響を抑えるため、作業を分割すると説明していた。

仕様上は一つの型判定でも、運用上は鍵、証明書、manifest、ROA、検証キャッシュが連なる移行になる。AFRINICは発行と会員調整を担い、バリデータのメンテナーは例外処理を担い、各ネットワークは導入時期を決める。どこか一つが期限を宣言しても、全体が同時に切り替わるわけではない。

約6,000経路という数字の正しい読み方

2025年11月17日、Snijdersは非準拠の発行者名を持つオブジェクトが988件、主体名を持つものが657件残っていると報告した。その時点で例外を外した場合、AFRINICトラストアンカー配下のユニークなVRPは21,027件から19,480件へ一時的に減ると試算した。約6,000件のBGP経路広告がROVのvalidからnot-foundへ移るという見積もりも示した。数値と前提は同じDBWGメールに記録されている。

これは「その時点で例外を撤去すれば」という反実仮想である。8月に6,000件が実際に状態を変えたという観測ではない。Not-foundはinvalidとも、到達不能とも同義ではなく、当該広告を裏付けていた経路起点認証の根拠が失われることを意味する。

今回確認した公開情報には、その規模の変化や障害が起きたことを示す報告はない。試算を障害件数のように扱えば、事実を誤るだけでなく、再発行が間に合った可能性を見落とす。

この試算の意義は別にある。例外を残し続けるソフトウェア上の負担と、早く外しすぎた場合に会員が失う保護を同時に可視化した。発行側でオブジェクトを直してから共通ルールを厳格にすることが、両方の費用を抑える唯一の順序だった。

先に共有データを直す方が安全である

バリデータが先に厳格化すれば、発行側に残った既知の不備のためにVRPが消え、資源保有者が移行費用を負う。規格準拠は達成しても、継続性を損なう恐れがある。

発行側が先に署名処理を修正し、CAをrekeyし、依存オブジェクトを再発行し、複数の独立観測で警告が消えたことを確認できれば、その後の例外撤去は通常の共通化作業になる。現在は、独立コンソールが旧警告を出さず、rpki-clientの寛容な分岐はまだ残っている。

これは例外を恒久化してよいという意味ではない。特定の発行者だけを許容するコードは監査を難しくし、実装間の結果を分かりにくくする。複数の独立した検証で対象がゼロだと確認されれば、例外を外す合理性は一段と高まる。

8月18日の期限は、ソフトウェアを時刻どおり切り替えた点ではなく、切り替え前に発行側の作業を終わらせる圧力を生んだ点で機能したのかもしれない。稼働中のネットワークにとっては、その方が価値がある。

最終報告が埋めるべき空白

公開資料だけでは、最後の非準拠オブジェクトがいつ再発行されたのか、終盤に何個のホステッドCAをrekeyしたのかは分からない。1月の議論では、AFRINICが手順記事、会員向け周知、helpdeskを計画していると紹介される一方、具体的な日程がないとの指摘があった。この記録は調整方針を示すが、実施完了を証明しない。

今後、AFRINICが前後の件数、実施日、検証方法、複数実装での結果をまとめれば、現在の強い推定を完了記録に変えられる。rpki-client側についても、拒否を有効にするコミット、署名済みportableリリース、下流パッケージという段階を分けて追う必要がある。

現時点で言えることは十分に重要だ。日付だけでは移行は終わらない。Lu HengのRunning-Code Primacyが示す順序どおり、変更は実装、検証、導入、採用を経て運用上の現実になる。8月21日の四つの時計は、2月に予告された一つのスイッチではなく、管理中の互換性ギャップを示していた。