要約

  • LACNICのコンテンツ4984は二つの /rpki/ URLを表示する一方、hrefには /innovaportal/file/4983/1/ 配下の二つの旧経路を保存している。
  • 8月30日の取得では、表示URLはいずれもHTTP 200、text/html、7,014バイトで、SHA-256も同一だった。実際のリンク先は502バイトと518バイトの異なるTALを返した。
  • 二つのTALが指す証明書も別物で、両方とも取得できた。したがって確認できたのは配布表示の不整合であり、検証器、リポジトリ、証明書、ROA、経路の障害ではない。
  • 可視ラベルと解決後のリンク先を同時に試し、メディア型、TAL構文、ハッシュ、証明書との対応、訂正履歴を束ねた公開レシートが必要だ。

人が押すURLと機械が読むURL

RPKI Trust Anchors - TAL のページは、TALがリポジトリの場所と公開鍵を含むと説明し、通常用とAS0用の内容を示している。そのうえで、二つのファイルをダウンロードできるとして完全なURLを掲げる。

表示はLACNICの公開ホスト上の /rpki/lacnic.tal と /rpki/lacnic-as0.tal である。しかし、CMSのコンテンツ4984 に保存されたhrefは、それぞれ /innovaportal/file/4983/1/lacnic.tal と /innovaportal/file/4983/1/lacnic-as0.tal だ。フロントエンド環境 はInnovaportalの基点を innova.lacnic.net/innovaportal としている。

クリックはhrefを使う。コピーは画面上の文字を使う。普通のウェブ閲覧では意識しない差だが、運用資料のURLはそのままスクリプト、チケット、監査記録へ移る。リンク確認を「押して開いた」で終えれば、コピー利用の失敗は見えない。

旧配布基盤を残すこと自体に問題はない。必要なのは、表示先が正式なエンドポイントなのか、別名なのか、単なる説明文なのかを明示することだ。

200が示したのはウェブサーバの応答だけ

2026年8月30日04:48 UTC、キャッシュを避けて二つの表示URLを取得した。通常用表示URL も AS0用表示URL もHTTP 200で、内容型は text/html だった。

サイズはどちらも7,014バイト、SHA-256は 7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416 で一致した。最終更新時刻も8月28日13:20:15 GMTで同じだった。中身はLACNICのウェブアプリを起動するHTMLであり、二種類のTALではなかった。

最終更新時刻から発生時点を決めることはできない。利用者が実際にコピーしたか、外部キャッシュが同じ応答をしたかも不明だ。観測は特定時点の応答を固定するだけである。

それでも監視設計への含意は明確だ。HTTP 200と短い応答時間だけを見れば正常になる。証明書URI、空行、公開鍵という構造まで読む監視なら、HTMLをTALとして扱う前に止められる。

古い経路では二つのファイルが生きていた

通常用TALのInnovaportal先 は application/aux、502バイト、SHA-256 d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a を返した。先頭にはHTTPSとrsyncの証明書位置が並び、その後に公開鍵がある。

AS0用の配布先 は518バイト、SHA-256 671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff だった。リポジトリ位置、証明書、鍵材料が通常用とは異なる。

TALが示す通常用証明書 は1,166バイト、AS0用証明書 は1,160バイトで、ともに取得できた。

ここから「リポジトリは正常だった」と全体評価を広げることも、「表示URLが違うからRPKIが壊れた」と広げることもできない。分かるのは、調べた二つのTALとそのHTTPS証明書が取得可能だったという範囲だけだ。ページは多くの検証ツールが必要なTALを同梱しているとも記す。影響の推測はさらに慎重でなければならない。

拡張子ではなく文法を検査する

RFC 8630 によれば、TALは一つ以上の証明書URIを順番に置き、空行を挟み、トラストアンカーのSubjectPublicKeyInfoをBase64で記す。依拠側は証明書を取得し、現行の自己署名RPKI CA証明書であることと、鍵がTALに一致することを確かめる。

この手順は、名前解決、HTTP応答、TAL解析、証明書取得、鍵照合を別々の結果として扱う。200 はそのうち一つにすぎない。

公開ページには、さらに「表示と動作の一致」という前段がある。リダイレクトや別ホストの配布は、関係が明示されていれば問題にならない。今回の弱点は、ページが一つのURLをファイルの所在として見せながら、クリック成功を別URLに依存していることだ。

小さな移行ずれとして直せる

最も穏当な読み方は、サイト移行時のルートと旧ファイル配布の接続が揃っていない、というものだ。新しい /rpki/ 経路はアプリ入口を返し、CMSの旧hrefは機能を保っている。素材そのものが失われた兆候はない。

修正方法は一つではない。表示文字を実際のInnovaportal先に合わせてもよい。表示URLを正式な別名として各TALへリダイレクトしてもよい。重要なのは、クリック、コピー、自動取得が同じ役割の同じ版へ収束することだ。

黙って修正すれば将来は良くなるが、過去のHTML応答の理由が消える。短い訂正とページ版のレシートがあれば、旧状態を偽りと扱わずに新しい正規状態へ移れる。

配布レシートに必要な項目

レシートはページ版、表示文字、生href、絶対URL、通常用かAS0用か、想定内容型、別名の状態を一行で結ぶ。監視は表示URLとhref先の双方を取得する。

次に、ステータス、内容型、バイト数、強いハッシュを保存し、TAL構文を解析する。URIと鍵を抽出し、優先証明書を取得し、自己署名、期間、鍵一致を別々に記録する。HTMLが来たなら、配布層の不整合として扱い、経路安全性の判定まで飛躍しない。

訂正時には旧ページハッシュ、検出時刻、理由区分、後継先、維持する別名を残す。これで、修正後も古い収集結果の由来を説明できる。

今回、クリック先は二つのTALを返した。表示URLは二つとも同じHTMLを返した。どちらも200だったからこそ、可用性と配布物の同一性を分けて測る必要がある。

出典