要約

  • RFC 5402 は、受領通知が要求された圧縮メッセージを展開できない場合、署名付き MDN で Error: decompression-failed を返す。
  • この通知は受信者が圧縮層を越えられなかったという帰属可能な事実であり、文書の意味を審査して拒否した証拠ではない。
  • MIME、圧縮、署名、暗号化、MIC、添付抽出、業務受理を別々に記録しなければ、正確な障害が誤った商取引判断へ変換される。

負の通知にも狭く強い価値がある

沈黙より、署名された失敗報告の方がはるかに有用である。署名を検証できれば、どの取引相手がどのメッセージに対して、どの処理境界で失敗したと述べたかを記録できる。RFC 5402 の decompression-failed は、その境界を圧縮層に置く。

しかし、正確さは範囲を広げる理由にはならない。展開できなければ、受信者は注文番号、数量、金額、権限を評価できなかった可能性がある。「内容を拒否した」ではなく「内容を再構成できなかった」が証明された事実である。

RFC 5402 は 2010 年 2 月に Independent Stream の Informational RFC として公開された。IESG Note は Standards Track の候補ではなく、実装・配備価値を慎重に評価すべきだと示す。文書は AS1、AS2、AS3 の EDIINT メッセージに圧縮を加える方法を定義するが、特定製品の動作や現行普及を保証しない。

圧縮位置によって署名対象が変わる

署名する文書では、内側の MIME 本文を圧縮してから署名する方法と、multipart/signed を作ってから全体を圧縮する方法が認められる。同じ文書で両方を行ってはならず、受信実装は両方を展開できなければならない。

前者では署名が CMS CompressedData を覆う。後者では未圧縮の MIME 内容が署名され、その署名構造が外側の圧縮に入る。署名付きメッセージの返却 MIC は、元の署名と同じデータから計算される。したがって MIC の入力は、層順序によって圧縮済みの場合も未圧縮の場合もある。

「注文ファイルの MIC」という項目だけでは再現できない。必要なのは、層順序、署名対象範囲、MIME 正規化、ハッシュ方式、入力段階である。最終 XML のハッシュが一致しないからといって直ちに改ざんではなく、別の合法な表現を測っている可能性がある。

逆に、最終ファイルが同じに見えても、署名対象の復元や MIC 検証が正しかったとは限らない。意味上の同一性と暗号学的なバイト同一性は関連するが、同じ主張ではない。

転送符号化は外から見える層に付く

圧縮されたバイナリ MIME 部分が SMTP のような 7 ビット経路に露出するとき、RFC 5402 は base64 Content-Transfer-Encoding が必要だと説明する。圧縮部分が暗号化 MIME の内側にあるなら、内側ではなく外側の暗号化部分に転送符号化が必要になる。

これは調査上の座標である。送信元 MIME、圧縮 CMS、暗号化された包み、base64 の通信表現は別々のバイト列だ。受信側では転送復号、復号、展開、MIME 解析が続く。最終文書だけを保存すると、改行変換、切断、復号失敗、展開失敗の場所を特定できない。

未署名の圧縮メッセージでは、RFC 5402 は展開後の内容に MIME ヘッダーと適用された Content-Transfer-Encoding を含めて MIC を計算する。AS2 の RFC 4130 には正規化規則もある。読みやすく整形した文書は、同じ業務情報を持っていても MIC 入力ではないことがある。

証跡には各段階の生データとハッシュ、変換規則、実行時刻を残すべきだ。最終状態から途中の証拠を推測してはならない。

ZLIB 対応は一回の処理成功ではない

RFC 5402 は ZLIB の対応を必須とし、ZLIB は DEFLATE を利用する。RFC 3274 は CMS CompressedData とアルゴリズム識別子を定める。圧縮レベルの違いは展開互換なので、レベルをパラメーターとして送る必要はない。

それでも互換性の端は残る。ASN.1 の歴史的事情により、アルゴリズムのパラメーターは省略形と NULL 形の両方に遭遇し得る。片方しか受け付けない実装も、製品表では ZLIB 対応と記載できてしまう。

さらに MIME の配置、サイズ上限、正規化、エラー処理、相手との合意がある。RFC 5402 の圧縮を使う AS2・AS3 実装は Version 1.1 以上を示す必要があるが、ヘッダーは能力または意図であり、個別メッセージの成功証明ではない。

能力広告、契約上の許可、実際の設定、観測された結果を分ける。そうしなければ、古い能力情報が現在の処理を保証したように見える。

RFC 4130 も失敗時の署名付き通知を要求する

AS2 の RFC 4130 は、署名付き受領通知によって受信、整合性、署名メッセージの送信者認証を確認する仕組みを述べる。original-message-id と Received-content-MIC が送信と受信報告を結び、受信側の署名が報告者を結ぶ。

同じ RFC は、内容処理に失敗しても署名付き通知要求を満たすよう求める。その場合、取引自体は有効でない可能性があり、Disposition に理由を入れる。つまり「署名付き MDN がある」と「業務が成功した」は最初から別である。

decompression-failed を受け取ったら、保存した通信表現と層情報から再現し、破損、方式解釈、制限値、相手設定を切り分けるべきだ。業務側が即座に拒否処理や代替発注を行うと、別経路で成立した取引との重複も起こり得る。

複数添付では共通失敗と個別処理を分ける

RFC 6362 は multipart/related に複数文書を入れる方法を説明する。圧縮・未署名の場合、MIC は転送方式に従って正規化された展開後の multipart 全体を対象とする。MIC が一致しなければ、すべての添付を無効として再送する。

これは共通の完全性境界である。しかし、正しく抽出された後の各文書は別々の運命を持つ。XML はスキーマ検査を受け、PDF は保管され、画像はポリシー違反になるかもしれない。保存や取引処理は実装依存とされる。

親の交換記録に MIME と MIC と MDN を置き、子の添付記録に Content-ID、媒体型、抽出ハッシュ、解析結果、アプリ判断を置く。共通 MIC を各添付の意味上の承認へコピーしてはならないし、一つの業務エラーを通信全体の暗号エラーへ書き換えてもならない。

到達した層だけを報告する

完全な証跡は取引相手の合意と許可されたプロファイルから始まる。次に MIME 元データ、正規化、圧縮識別子とパラメーター、署名範囲、暗号化範囲を保存する。受信側では転送復号、復号、展開、署名、MIC を順番に記録する。

その後に MDN の署名、相手証明書、元メッセージ ID、Disposition が来る。添付抽出、形式検査、重複防止、取引照合、権限確認、業務受理はさらに後段である。

公開資料は現行ベンダーの普及率や特定障害を示さない。だが境界は明確である。decompression-failed は圧縮層までの正確な負の証拠であり、その正確さを守るには「取引拒否」へ拡大しないことが必要だ。