要約

  • RFC 9741のBase64用sloppy演算子が省くのは、未使用ビットをゼロとする検証である。.jsonも復号後の値を制約するもので、唯一の文字列表現を保証しない。
  • 同値の別表記が承認や請求に影響するかは、各処理の識別規則と実際の結び付きによる。文字列の例だけで不正操作や誤請求が証明されるわけではない。
  • 受理する表現、業務上の同一性、暗号処理の入力を別々に定義し、課金単位に即して互換性の費用と証拠の管理責任を決める必要がある。

保存量が増えていないのに、受付の仕事は増える

キャッシュが効いたから費用は一回分、とは限らない。同じ内容を二度受け取れば、受付、復号、待ち行列への投入、監査記録は二度発生し得る。保存する資源が一つであることと、サービスが処理した要求が一つであることは、異なる主張だ。

ここでは、内容参照を受け付ける仮想のサービスを考える。受付担当は文字列から得られるバイトを検証し、承認担当は申請時の文字列を記録する。資源担当はキャッシュと利用枠を管理し、会計担当はその一部の記録から請求を作る。実在する製品、導入例、事故を報告するものではない。

受付が二つの表記を同じ許可値として受理し、会計が別々の文字列キーで数える場合、何を一件とするかはまだ決まっていない。一資源の二つの呼び名なのか、二つの有料要求なのか、それとも一度だけ許された操作の再実行なのか。復号器は内容を示せても、契約上の単位や承認範囲を選ぶ権限を持たない。

一つのハッシュに統一すれば解決する、という結論も早すぎる。別の顧客が同じ内容を送ったからといって、承認まで共有してよいわけではない。同一顧客でも目的や操作が違えば、別の判断が必要になる。資源の重複排除、要求の計数、行為の承認を一つの「同じ」に押し込めると、本来残すべき区別が失われる。

小さな未使用部分が、別の文字列を作る

Carsten BormannによるRFC 9741は、2025年3月にIETFの標準化過程に属するRFCとして公開され、CDDLにテキスト変換・処理の制御演算子を追加した。規格の公開は、特定の検証器による実装や運用上の成功を示す証拠ではない。

第2.1節では、パディングなしのBase64urlである.b64uと.b64u-sloppy、パディングを持つ従来型Base64である.b64cと.b64c-sloppyを区別する。sloppy版が省略するのは、余分な未使用ビットがゼロかどうかの検証だ。文字集合やパディングの規則まで任意になるわけではない。

一バイトの例を手計算すると境界が見える。ZgとZhの最初の八ビットはいずれも01100110、すなわち0x66である。二つ目の六ビット群の残り四ビットは、前者では0000、後者では0001となる。同じバイトを許す制御値に対して、厳格版とsloppy版の関係する差がこの部分に現れる。これはビット配置からの導出であり、本稿でCDDL実装を実行した適合試験ではない。従来型の対応例はZg==とZh==で、パディングを勝手に省略する例ではない。

RFC 4648第3.5節は、適合する符号化器にパディングビットをゼロとすることを求め、復号器の拒否については参照する仕様との関係を説明している。この一バイト配置では四ビットを変えられるため、同じ有効ビットを持つ表記が十六通りになる。ただし、あらゆる長さの参照が必ず十六の別表記を持つという意味ではない。

この限定は運用上も重要だ。sloppyという名前から、任意の空白、異なる文字集合の混在、途中で切れた入力まで許されると読んではいけない。互換性の入口は、許容範囲を指定した規則であるべきで、一般的な入力修復の約束ではない。

署名が守る表現と、キャッシュが使う同一性

資源担当が表記差を消したくても、その判断を認証にそのまま適用できない。通常のBase64url符号化されたJWSでは、RFC 7515が定める署名入力は、符号化済みの保護ヘッダーと符号化済みのペイロードを点で結んだものである。JSONとして解析した値が等しいという理由で、その入力を再直列化した文字列に置き換える権限は生じない。

応用側が明示的にデータモデルの正規表現への署名を選ぶことはできる。RFC 8785のJCSは、制約された入力領域に対して決定的な表現を与える独立投稿の情報提供RFCだ。しかし、それは.jsonに含まれる暗黙の義務ではなく、別途選ぶ方式である。本稿は非符号化ペイロード拡張やすべての署名形式には一般化しない。

「使う前に正規化する」という指示には、何に使う前かが欠けている。キャッシュ索引のための変換と、選んだ署名形式で必要な原入力の検証では、順序も証拠も異なる。送り手が認証したのは元の表現かもしれない。保存上は不要な差でも、認証上は保全すべき差になり得る。

JSONの検証成功も、固定キーの発行ではない

次の二つは、小整数と固定文字列からなる同じメンバー値を持つ例である。

{"account":"team-a","units":1}

{ "units": 1, "account": "team-a" }

異なるのはメンバーの順番と意味を変えない空白だけで、重複名はない。RFC 8259がJSONの構文を示し、I-JSONのRFC 7493は重複名などの相互運用上の問題を排除し、メンバー順はメッセージの意味を変えないとする。

RFC 9741第2.4節の.jsonは、RFC 8949第6.2節の既定のJSONからCBORへの変換による値を制約する。意味を変えない空白やマップ項目の直列化順は制約できない。したがって、フォームが検証を通過しても、承認照会や請求索引に使える唯一の文字列表現が発行されたことにはならない。

もちろん、見た目が似ていればすべて同値ではない。数値精度、変換の選択、数値を文字列として扱う応用モデルは別に検討する必要がある。配列の並べ替えや重複キーをこの例と同列に扱ってはならない。応用の制約は制御値に反映させるもので、変換器が補ってくれるわけではない。

ほかの演算子も一律の寛容さを求めてはいない。大小文字の扱いを選べる十六進表記や、任意の先頭ゼロを認めない十進表記は、表現ごとの選択を示す。重要なのは何もかも同じ規則にすることではなく、各項目がどの差を許し、その後どの識別に使われるかを記述することだ。

誤請求と呼ぶには、請求単位の証拠が要る

仮想サービスで二つの請求が見つかったとしても、同じバイトだったという事実だけでは誤りと判断できない。要求単位の契約なら二度の受付作業に料金が付く場合があり、論理資源単位の契約なら別表記による資源数の増加を認めない場合がある。操作単位なら、操作の識別と状態遷移を調べなければならない。

実際の影響を示すには、計数に使うキー、その範囲、承認と実行の結び付き、最終状態を確認する必要がある。別表記が承認を回避したと主張するなら、本来阻止すべき規則と、どの判定や結び付きが変わったかを示す。再実行の禁止が破られたという主張にも、行為の識別と状態の証拠が要る。規格上の表現空間だけでは事故は確定しない。

Lu Hengの最小共通仕様に関する議論は、決定的で共有すべき規則を業務上の取り決めと分ける分析視点を与える。本稿への応用は、値の受理規則を薄く明確にし、課金や承認の判断を明示することだ。Lu HengによるRFC 9741の評価やIETFの会計要件を意味しない。

稼働コードを重視する議論からは、規則の公開と実際の採用を分けて考えられる。現実と象徴の層に関する考察も、検証済みという表示を業務全体の証拠と取り違えないための視点にとどまる。RFC 8610第5節もCDDL仕様と照合器の正しさだけに頼らず、ほかの防御を備えるよう注意している。

互換性は有益であり得る。しかし、顧客の修正を省いた分が内部の調査と照合に移るなら、受理成功率だけでは費用を説明できない。その移転を誰が引き受けるかが、検証器の外側に残る判断である。