要約

  • RIPE Database 1.123は、descr:とremarks:のUTF-8処理で分解形UnicodeをNFCへ正規化し、その後に制御文字の無害化とIDNA変換を行う。
  • 正規化は妥当な相互運用対策だが、提出された文字列、データベースの正準表現、特定の出力経路が返したバイト列は、それぞれ別の証拠である。
  • 自由記述や認証情報、個人データを公開せずに、三つの段階を結ぶ正規化記録を作ることはできる。

一文字の背後に二つの並びがある

公開されたテストは Ondřej Caletka という名前を使う。ここにある ř は、合成済みの U+0159 一文字で表せる。普通の r である U+0072 の直後に、結合文字の caron U+030C を置いてもよい。正しく描画されれば同じ抽象文字になるが、素のバイナリ比較では一致しない。

Whois 1.123へ入ったRIPE NCCのコミットは、処理の順番まで示している。createUtf8Attribute は属性値のJavaエスケープを解除し、ICUのNFCインスタンスで正規化する。その結果の符号位置を順に処理し、制御文字を無害化してから、既存のIDNA変換へ渡す。ブラウザーが表示時にアクセントを整える話ではない。値の変換経路そのものだ。

追加された試験では、descr: に U+0072 U+030C を与え、得られるJava文字列の長さが一であることを求める。さらに、分解形で書かれた Ondřej Caletka が、単一の U+0159 を含む Ondřej Caletka になることを確認する。

リリースノートによれば、1.123の本番展開日は2026年7月8日である。記述は限定的で、descr: または remarks: にある分解形Unicodeを正規化するという。現行のCharacter Encoding文書も、この二つをUTF-8対応の自由記述属性として挙げ、NFCを使うと明記している。

正規化を疑う前に、その防御効果を見る

Unicode Standard Annex #15は、NFCを正準分解の後に正準合成を行う形式と定義する。正準等価な二つの文字列が同じNFC結果を持つことが重要だ。キーボードや編集ソフトがアクセントを別の符号位置として入力しただけで、同じテキストが永久に別のバイト列として残る問題を減らせる。

したがって、正規化を改ざんと呼ぶのは適切ではない。NFCは抽象テキストの正準等価性を保つ。また、より広い表示上の差を畳み込む互換正規化とも違う。多様なクライアントが読む登録データでは、等価な表現を一つに寄せること自体が防御になる。

RIPE NCCは範囲も絞った。2026年4月30日に本番へ入った1.122がUTF-8を認めたのは descr: と remarks: だけだった。Database Working Groupへの提案は、地域の言語で通知を書ける価値を出しながら、名前、住所、個人データの国際化へ踏み込まない最小限の変更だと説明する。自由記述欄へ個人データを入れてはならないという注意も変わらない。

問題は、分解形を正準値として温存すべきかではない。後から見た人が、提出時の並び、正規化後の値、配信時の表現を区別できるかである。

出口を選べば、証拠のバイト列も変わる

RIPEの文書は出力経路を二つの系統に分ける。Whoisのポート43、NRTMv3、通常の .gz 日次ダンプは既定でLatin-1を使う。インターフェースが扱えない文字は ? に置き換えられる。データベースのWebアプリ、Whois REST API、RDAP、NRTMv4、Syncupdates、.utf8.gz ダンプは既定でUTF-8を使う。ポート43ではcharset指定も可能だ。

旧来の利用者を維持するためのLatin-1と、正準文字を運ぶUTF-8は、どちらも運用上の理由を持つ。しかしLatin-1のフィードから保存したオブジェクトは、RIPE Database由来というだけで正準UTF-8値とバイト単位で同一にはならない。出口で生じた ? は、更新者が入力した ? でもない。

ミラーは受信したストリームをハッシュする。運用者は更新確認を保存する。調査者は昔のダンプとREST応答を比べる。どの表現をハッシュしたか記録がなければ、エンコーディング差が内容変更に見える。一方、画面だけなら、もともと違った入力がNFCで同じになった事実を見落とす。

公開資料は、特定のミラーが誤っているとは述べない。1.123以前の全オブジェクトが一括変換されたか、RIPE NCCが正規化前の入力を内部保存しているかも分からない。分からない部分を事故物語で埋める必要はない。意図した変換がある以上、証拠がその前後のどちらを固定したかを示すべきだという結論は残る。

内容を載せない正規化記録

更新時の記録には、オブジェクトと版、操作確認、属性種別、入力インターフェースと文字集合を入れられる。NFCの名称、ソフトウェア版またはコミット、符号位置列が変わったか、制御文字や無効な符号位置の置換が起きたかも、内容を見せずに記録できる。

完全性の証明にはプライバシー上の工夫が要る。短く予測しやすい文の公開ハッシュは総当たりできる場合がある。アクセス制御された一括ハッシュ、鍵付きコミットメント、権限を持つ当事者だけが照合できる証明の方がよい。descr: や remarks:、更新資格情報を公開する必要はない。

取得側では、クエリまたは複製インターフェース、要求したcharset、シリアライズ版、実際に受け取ったオブジェクトのダイジェストを加える。修正版とは置換関係で結ぶ。これで「提出」「正準」「出力」の三段階が、同じ言葉に押し込められなくなる。

この記録が証明するのは文章の真偽ではない。NFCを通った remarks: がネットワーク運用者を特定するわけでも、descr: が資源所有や現在の経路を証明するわけでもない。どの変換規則で表現が結ばれたかだけを証明する。その狭さが重要である。

証拠から言えないこと

NFCが停止、攻撃、認可失敗、本人取り違えを起こしたという資料はない。全RPSL属性がUTF-8対応になった証拠もない。person:、role:、org-name: や住所の国際化を意味する変更でもない。コミットだけから過去の各オブジェクトの扱いを推測してはならない。

8月のNRTM事案も別である。余分な改行、無効なRPSLオブジェクト、ストリーム停止、1.124の変更が中心だった。複製の連続性とUnicode表現の保全は、同じ記事にも同じ記録にもまとめない。

出典

  1. RIPE Databaseリリースノート
  2. RIPE Databaseの文字エンコーディング
  3. RIPE Databaseの過去の四半期計画
  4. RIPE 90 Database Working Group運用報告
  5. descr: と remarks: へのUTF-8導入提案
  6. Whois 1.122リリース告知
  7. RIPE LabsのUTF-8影響分析
  8. 分解形Unicodeを正規化するRIPE-NCCのコミット
  9. RIPE-NCC Whoisリリース一覧
  10. Unicode Standard Annex #15