要約

  • RFC 3548が扱ったのは、仕様が単に「base64」と書き、文字集合、改行、パディング、文字集合外の入力への応答を定めないという、目立たない相互運用上の問題だった。
  • MIMEのメール転送ルールは一つの用途別プロファイルであり、あらゆるデコーダーに共通する契約ではない、というのが同文書の要点だ。

Base64文字列はテキストエディターで読める。そのため、バイト列を印字可能な文字へ変えれば、どのデコーダーでも逆変換できるはずだと思いやすい。RFC 3548が記録する経緯は、もっと複雑だ。実装ごとに小さな違いが積み重なる一方、プロトコル文書は「base64」という名前だけで話が通じるかのように記していた。

食い違いは6ビットの計算ではなく、その周囲にある。エンコーダーは改行を挿入するのか。末尾の = は必須なのか。想定外の文字をデコーダーは拒否するのか、それとも無視するのか。64個の位置にどの記号を割り当てるのか。近隣の形式の答えを借りれば、その形式の中では動いても、別の振る舞いを期待する相手とは合わないことがある。

RFC 3548は2003年7月、Informational RFCとして公開され、こうした曖昧さを減らそうとした。序論は、プロトコル仕様が正確な説明や参照を示さずに「base64」を使い、MIMEを根拠として挙げながら折り返しや文字集合外の文字の影響を見落とす例を指摘する。そこで一般的なBase16、Base32、Base64を整理し、周辺の選択肢を明示した。

混同を招きやすいのは、MIMEが特定の文脈を定義しているからだ。RFC 2045のBase64は、メッセージ本文向けのContent-Transfer-Encodingである。1行76文字という上限はメールの文脈に属する。PEMは同じくメール時代の制約のもとで64文字を使っていた。RFC 3548が一般的な参照仕様に示したのは、その仕様が明示的に求めない限り、エンコーダーは改行を加えないというルールだ。相手側が改行をデータとして数えたり拒否したりするなら、それは単なる体裁ではない。

パディングと許容範囲もプロファイルが決める。RFC 3548は、参照側の仕様が別の規則を定めない限り、適切なパディングを末尾に含めるよう求める。また、明示的な例外がない限り文字集合外の入力は拒否する。MIMEはCRLFを含むそうした文字を無視できるが、それはMIME自身の例外だ。他のプロトコルへ持ち込めば、受理する入力の範囲が変わる。同RFCは隠れた通信路や実装エラーを懸念材料として挙げるが、特定製品で起きた攻撃を報告しているわけではない。

文字集合にも名前が必要だった。通常のBase64は値62と63に + と / を使う。RFC 3548はURLやファイル名に適した代替として、それらを と _ に置き換える方式を記録した。この方式を同一のエンコーディングとみなしたり、単に「base64」と呼んだりすべきではない、と明記している。パス、ファイル名、識別子の欄には、メール本文とは異なる制約がある。

2006年10月、RFC 4648がStandards Track文書としてRFC 3548を置き換えた。プロファイルを明示する考え方を引き継ぎ、Base64とBase32のパディング用ビットをゼロにする正準エンコーディング規則を加えた。そうしないと、別々の文字列から同じバイト列が得られる場合がある。これはMIMEの改行とは別の問題だ。二つのRFCを合わせて読むと、「デコードできた」だけではプロトコル仕様にならないことがわかる。表記、パディング、許容範囲、値を解釈する層を、送受信側で合意しなければならない。

Baseエンコーディングは暗号化でも認証でもない。オクテットを特定の伝送で扱いやすいテキスト表現にするものだ。RFC 3548が残した歴史的な貢献は控えめだが重要である。なじみのある名称を、完全なルール一式と取り違えてはならないと示した。

出典