要約

  • RFC 3075 の中核検証は、正規化した SignedInfo に対する署名値と、そこに並ぶ各 Reference の変換後データに対するダイジェストを別々に確かめた。
  • 成功結果は、選ばれなかったノード、署名されない表示資源、拘束されない KeyInfo、Manifest の未検査項目、アプリケーションの信頼判断までは証明しなかった。

2001年3月、XMLDSIG 作業部会は XML と任意のデジタルデータに適用できる署名構文を RFC 3075 として公表した。署名は文書の内側にも外側にも置け、対象は同一文書にも外部 URI にも存在できた。だが、この自由度を理解するには「何に署名したか」をファイル名ではなく処理経路として読む必要がある。

一つの成功表示には二つの検証があった

SignedInfo は実際に署名値がかかる制御面だった。検証器はまず各 Reference の対象を得て、指定された変換の結果をダイジェストし、DigestValue と照合する。次に SignedInfo を指定方式で正規化し、選んだ鍵と SignatureMethod で SignatureValue を確かめる。

署名値だけが正しくても、参照ダイジェストが一致しなければ対象は結び付かない。ダイジェストだけが一致しても、それを誰の鍵が認証したかは確定しない。両方が通って初めて、特定の鍵と特定の処理記述・ダイジェスト群が結ばれる。それでも、署名要素の近くにある全ノードや、アプリケーションが後で利用した全データが保護されたとは限らない。

対象を決めたのは Transforms の出口だった

Reference は URI だけでなく、順序を持つ変換列を含められた。XPath は木の一部を選び、XSLT は別の表現を生成し、Base64 は文字列表現から元のバイトを取り出し、正規化はノード集合を再現可能なオクテット列にした。ダイジェスト入力はこの出口である。

編集可能欄を意図的に除外した定型書類や、自分自身の署名値を計算対象から外す enveloped signature では、この選択性が必要だった。したがって部分署名は不具合ではない。危険なのは、利用者や業務規則が選択結果を原文書全体と取り違える場合だ。変換で捨てられた金額、宛先、注記、表示資源は変わっても、署名は依頼された対象に対して正しく成功し得る。

さらに RFC 3075 は、中核検証が毎回 URI を新しく取得し、宣言された各変換を実行した事実まで保証しないとした。すでに変換済みのキャッシュを許すアプリケーションも、再取得を要求するアプリケーションもあり得る。最終ダイジェストが同じでも、鮮度と取得経路の証拠は同じではない。

正規化は意味ではなく計算面を固定した

XML パーサーは改行や属性値を正規化し、実体を展開し、名前空間をノードへ写し、属性順などの表面情報を失う。DOM や SAX を通った署名者と検証者が同じバイト列を再構築できなければ、暗号計算を比較できない。

Canonical XML はそのための物理表現を与えた。これは同じ情報モデルから同じ入力を作る仕組みであり、異なる画面が同じ意味を持つこと、schema が信頼できること、名前空間の説明が正しいこと、除外ノードが無害であることを認定する機構ではない。後の Canonical XML 1.1 も、一般的な正規形とアプリ固有の等価性を区別した。

人が見たものと署名対象を接続する

RFC 3075 の安全性節は表示を副次的な問題にしなかった。署名が人や自動機構の判断を表すなら、実際に提示された内容を可能な限り正確に保護する必要がある。画面画像そのものを署名する方法は明快だが、後の機械処理が難しい。代わりに、データとともにフィルター、スタイルシート、クライアント条件など表示を左右する入力を署名できる。

検証側も、元データや途中状態ではなく、変換され署名された形を操作し表示すべきだった。外部スタイルシートが画面の意味を変えるのに参照へ含まれなければ、表示は変化してもデータ署名は壊れない。

これは XML Signature が人の同意を自動的に成立させるという話ではない。RFC は、鍵と参照データを結び付ける一方、鍵を人物・組織へ対応させる規範や、署名対象の意味を定義しなかった。表示要件、権限、合意はアプリケーションの仕事だった。

KeyInfo は鍵の手掛かりであり、信頼の結論ではない

任意要素 KeyInfo には公開鍵、証明書情報、名前、取得方法などを置けた。受信側が文脈から鍵を知っていれば省略もできた。標準構造では SignedInfo の外にあり、拘束したければ別の Reference で含められた。

しかし、KeyInfo のバイトを署名しても権限判断は完成しない。正しい証明書でも対象業務には使えない場合がある。正確な KeyName でも局所的な索引にすぎない場合がある。RFC 2807 が定めた範囲も、内容と鍵の暗号的関係を中核とし、任意の信頼・断言意味をアプリ側に残していた。

Manifest の署名と各項目の検証は別だった

Manifest は参照の一覧を持ち、対象が取得不能または不一致のときの扱いをアプリケーションに委ねた。SignedInfo が Manifest を参照すれば、その外枠のダイジェストは中核検証の対象になる。だが、内部参照のどれを検査し、失敗をどう扱うかはアプリ定義だった。

したがって「Manifest は本物」と「全項目の取得・変換・照合が成功」は同義ではない。監査には項目別結果が必要であり、外枠の成功だけを全資源の証明にしてはならない。

後続仕様は暗号の周囲を狭めた

RFC 3275 は相互運用経験を踏まえて2002年に RFC 3075 を廃止し、いくつかの構文を修正した。後の W3C XML Signature 1.1 と Best Practices は、SignedInfo を認証してから危険な参照処理を行うこと、検証鍵への信頼を別に確立すること、XPath・XSLT・RetrievalMethod・外部 URI を制限すること、利用予定の要素が本当に保護されているかをアプリ自身が確認することを勧めた。

これは特定の RFC 3075 実装に事故があった証拠ではない。選択と処理を記述できる署名には、暗号ライブラリの真偽値より狭く明示的な運用方針が必要だという継続した設計判断である。

Lu Heng の Running-Code Primacy と Reality Layers は後世の分析枠であり、RFC 著者の主張ではない。実際にアルゴリズムへ入ったバイトと実行結果を残すこと、そして「署名済み」という象徴、選択データ、表示、信頼判断、実世界の効果を分離することに使える。RFC 3075 の価値は署名の権威を広げた点ではなく、その権威の終点を記述可能にした点にある。

出典

Lu Heng は RFC 3075、RFC 3275、W3C 勧告の著者でも承認者でもない。二つの論考は、明示した後世の分析枠としてのみ用いた。