要約
- RFC 5198のNet-UnicodeはUTF-8だけではない。NFC、コードポイントの割り当て状態、CRLF、制御文字の扱いまでを組み合わせたネットワークテキスト形式である。
- OSや言語ライブラリのUnicodeデータは、アプリケーションコードを変えずに更新され得る。判定を再現するには、実際のUnicode/NFC版と入出力の証跡が必要になる。
「同じリリース」が証明しないもの
アプリケーションのハッシュは、その成果物が同じであることを示す。しかし、成果物が参照した全データまで同じだとは示さない。RFC 5198は、Unicode変換や正規化をOSまたは言語ライブラリに任せる実装が多いと指摘する。これらの関数はアプリケーションコードの変更なしに更新される。しかも、アプリケーション自身がUnicode版や正規化手続の版を知る現実的な方法を持たず、両者の整合性も保証できない場合がある。
ここで重要なのは、NFCが無秩序に変わるという話ではない。未割り当てコードポイントを含まず、既にNFCである文字列について、Unicodeは将来版でもNFCであり続ける安定性を約束している。動くのはレパートリーの境界だ。旧版で未割り当ての点は自分自身に正規化されるが、将来そこに文字が割り当てられると別の正規化関係に参加し得る。RFC 5198準拠の送信側は、自分が依存する版で未割り当ての点を送ってはならない。
したがって、同じアプリケーションが異なるUnicodeデータを読むと、送信可能集合が変わり得る。NFC=trueだけでは、その境界を誰が、どの表で判定したのか分からない。
Net-Unicodeを一つの検査に潰さない
RFC 3629のUTF-8は符号化を定める。RFC 5198は、その上に共通のテキストストリームを定める。行を持つプロトコルなら終端はCRLFでなければならない。CR NULは歴史的に許されるが推奨されず、NULを文字列終端とする処理系では危険になる。C1制御文字は使用禁止で、IND、NEL、U+2028、U+2029も改行の代わりにはならない。先頭BOMも許されない。
送信前の文字列はNFCにするべきであり、依存するUnicode版で未割り当ての点を含めてはならない。Unicode版とNFC版は一致していなければならない。
これらは別々の判定である。UTF-8デコード、割り当て表、正規化、行規則、制御文字フィルターを一つの成功値にまとめると、障害時に原因を逆算できない。RFC 5198のエラッタにも区別がある。C1をASCII範囲と呼ぶ記述への技術的指摘はReportedであり、C1禁止そのものは本文で明確だ。Verifiedの1402は参照方向を「下」から「上」へ直す編集上の修正にすぎない。
セキュリティ境界ごとに同じ文字列とは限らない
RFCは、受信文字列が正規化済みだと仮定するなと警告する。意図的な非正規形が、素朴なテキスト照合を行うファイアウォールをすり抜ける可能性があるからだ。
ゲートウェイが旧い表で正規化し、アプリケーションが新しい表で再処理するなら、二つの制御点は同じ入力を受けても同じ状態を比較しているとは限らない。署名検証の前に変換したのか、受信オクテットを検証した後に変換したのかも重要である。CRLFの書き換えは位置を変え、BOMを印、データ、エラーのどれと扱うかで記録の意味も変わる。
RFC 5198は、既にUTF-8利用を精密に定義したプロトコルを上書きする規格ではない。適用したプロファイル名、処理順序、実際の表を証跡に結び付ける必要がある。
再現可能な受入証跡
証跡には、アプリケーションの版とハッシュに加え、ホストまたはコンテナイメージ、言語ランタイム、Unicode Character Database、NFC実装とデータ版を含める。取得できない情報は「不明」として残す。
メッセージ単位では、受信オクテットのハッシュ、UTF-8結果、コードポイント列、指定版での割り当て判定を結ぶ。BOM、私用領域、C0、C1、CR、LF、CR NUL、U+2028、U+2029は別々に記録する。正規化前とNFC出力のハッシュ、入力が既にNFCだったかどうかも必要だ。
最後に、比較、フィルタリング、署名、保存といった下流の行為を、権限と観測結果から分ける。Net-Unicodeへの適合は人の同一性や認可を証明しない。本稿が問うのは、もっと手前の事実である。同じアプリケーション版の下で、どのUnicode契約が実行されたのか。
情報源
- RFC 5198 HTML
- RFC 5198 テキスト
- RFC 5198 情報ページ
- IETF Datatracker:RFC 5198
- RFC 5198 履歴
- RFC 5198 参照関係
- RFC 5198 エラッタ
- RFC 3629 — UTF-8
- RFC 2277 — 文字集合と言語
- RFC 4690 — 国際化ドメイン名の論点
- RFC 3454 — Stringprep
- RFC 8264 — PRECISフレームワーク
- RFC 6365 — 国際化用語
- RFC 854 — Telnet
- RFC 698 — Telnet拡張ASCII
- Unicode Standard Annex #15 — 正規化形式
- Unicode安定性ポリシー
- Heng Lu — 現実の層と象徴的権力
- Heng Lu — 最小初期仕様
- Heng Lu — running codeの優先
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
