要約

  • abc、"abc"、#616263#、3:abc、|YWJj| は同じ3オクテットを表せるが、署名計算に使う一意のバイト列は正規表現だけが定める。
  • 表示ヒントは署名対象に含まれ得るが、型の安全性、信頼、認可を証明するものではない。
  • 受信入力、パーサー設定、正規出力、署名、型解釈、方針判断、観測結果を分離し、ハッシュで結ぶ必要がある。

画面の文字と署名境界は別物

ある端末は abc、保存ファイルは "abc"、トレースは #616263#、転送データは 3:abc、診断ツールは |YWJj| と表示する。RFC 9804 は、これらが同じ3オクテットに解析され得ることを示す。しかし、どれか一つの画面を保存しても、署名境界を通ったバイト列は分からない。

S-expression はオクテット列または有限リストである。仕様は用途を四つに分ける。高度表現は人の入力とデバッグ向け、基本転送はバイナリや行長に制約がある経路向け、正規表現は署名向け、メモリ表現は実装内部向けである。

正規表現では、文字列を10進のバイト長、コロン、実データの順で出力する。リストに装飾的な空白はない。全体を Base64 化して波括弧に入れる基本転送も使えるが、それは包装であり、復号後は同じ正規バイト列でなければならない。

高度表現はトークン、引用符、16進、Base64、長さ指定、空白を許す。対応は任意であり、アプリケーションの要求か能力確認があって初めて受理すべきである。「解析成功」だけのログでは、パーサーの版、許可した記法、深さ・長さ制限、適用したプロファイルを再現できない。

署名された表示ヒントも表示ヒントである

RFC 9804 の表示ヒントは、データをどう見せるかをアプリケーションに伝え、それ以外の機能を持たない。存在すれば正規表現に含まれるため、署名で覆うことはできる。しかし証明されるのはヒントが含まれた事実であり、型が正しいこと、処理系が安全なこと、動作が許可されることではない。

ヒントがなければローカル既定値を使え、一般既定値は application/octet-stream である。同じオクテットを二つのアプリが異なる形で表示してもよい。等価判定もプロファイルの所有物だ。仕様はヒントとデータの双方の一致を推奨するが、ヒントを無視する規則も認める。監査記録にはその規則と版が要る。

文法受理は第一関門にすぎない。RFC 9804 は高度表現やヒント、空の文字列・リストを禁止し、資源上限を加えることを認める。SPKI では RFC 2693 が空リストを禁じ、先頭に型文字列を要求する。汎用文法より用途プロファイルの方が狭い実例である。

証拠列は受信したバイトと枠組みから始まる。パーサー、許可文法、プロファイル、制限を記録し、抽象オブジェクトを保存する。次に再度正規化してハッシュを得る。署名検証はそのハッシュと鍵を指定し、画面表示で代用しない。

その後に意味が来る。RFC 2692 は SPKI 認可の意味をアプリケーションコードの作者が定めるとする。RFC 2693 は信頼済みタプルと認可縮約を示すが、最終許可はアプリケーションに依存する。型ハンドラー、方針版、主体、操作、資源、判断を残し、実行結果はさらに別に観測する。

受信、受理、解析、正規化、署名、解釈、認可、実行を一つの緑色表示に畳まない。パーサーが違えば入力と正規ハッシュを比べ、署名が同じで結果が違えばハンドラーと方針を調べる。RFC 9804 はバイト単位の合意を可能にするが、後段の権限までは与えない。

出典