Summary

  • AS2-From と AS2-To は取引当事者が合意する大文字・小文字を区別した文字列であり、証明書から自動的に導かれる世界共通 ID ではない。
  • draft-ietf-ediint-rfc4130bis-04 は、HTTPS 用 TLS 証明書と、署名・暗号化用 AS2 証明書を分離しなければならないとする。
  • 署名、反転した AS2 名、Message-ID、MIC が整合しても、鍵を当該名称・方向・取引関係に割り当てたローカルな承認記録は別途必要である。

四つの欄を一つの「信頼済み」に潰さない

運用台帳の一行には、少なくとも AS2 名、メッセージ証明書のフィンガープリント、許可された方向、取引関係が必要だ。ところが製品画面がそれを一つの緑色の「trusted partner」にまとめると、どの事実が検証され、どの判断が人によって与えられたのか見えなくなる。

第 04 版の本文は、その分離を読む材料になる。Datatrackerでは EDIINT ワーキンググループの活動中の文書で、文書 APIの状態は I-D Exists、履歴では 2026 年 9 月 24 日公開である。目標は Proposed Standard だが、まだ RFC ではない。RFC 4130を廃止するのは承認された場合だけだ。

AS2 名は二者間の合意である

第 6.3 節は DUNS 番号のような企業固有値だけでなく、取引相手が合意した文字列を認める。1～128 文字の印刷可能 ASCII、大文字・小文字を区別し、全メッセージと MDN に必須である。応答の AS2-To は要求の AS2-From、応答の AS2-From は要求の AS2-To と一致する。

これは経路選択と相関の証拠になる。しかし法人名、DNS 名、証明書サブジェクトとの同一性は作らない。未知の値に対し、受信側は unknown-trading-relationship または unknown-trading-partner を含む未署名 MDN を返せる。その判定には既にローカルな相手先表が必要である。

チャネルと文書は別の資格情報を持つ

TLS 証明書は HTTPS エンドポイントを保護する。RFC 8446は TLS 1.3、RFC 9110は HTTP セマンティクスを定める。RFC 9525は現代的なサービス ID の参考にはなるが、AS2 草案に組み込まれた結合規則ではない。

AS2 証明書はメッセージと MDN の署名・暗号化に使う。構造は RFC 8551の S/MIME、RFC 5652の CMS、証明書検証は RFC 5280の PKIX 系譜に置ける。草案は TLS と AS2 に同じ証明書を使うことを禁じ、侵害と更新の境界を分ける。

ここで「有効」と「許可済み」が分かれる。証明書チェーンは発行・信頼ポリシーに答える。AS2 管理者は、当該鍵が今、この名称、この方向、この契約に使えるかを決める。

配布経路にも権限が要る

第 9.2 節は CEM の Internet-Draftを参照し、Certificate Exchange Messaging の対応を推奨する。手作業なら、稼働前に鍵の完全性と真正性を確保しなければならない。Well-Known URIから取得する場合も、要求者の認証と正当な取引相手へのアクセス認可が必要だ。

自己署名証明書は、フィンガープリントを安全な別経路で確認してから本番利用する。発行者署名が改ざんを検出しても、取得者、割当先、入出力方向までは決めないからである。

稼働記録には、名称の正確な表記、関係、方向、用途、フィンガープリント、シリアル、アルゴリズム、有効期間、信頼方式、交換元、承認者、稼働時刻、重複期間、戻し鍵を残すべきだ。期限切れ・失効・非信頼証明書は即時かつ目立つエラーにするという要件も、このローカル認可の代用ではない。

MDN は自分の検証鍵を選べない

送信側は原文、Message-ID、MIC を保存する。受信側の署名付き MDN に対し、署名、Original-Message-ID、返された MIC を照合する。RFC 8098は現在の MDN 枠組みである。

草案は署名と MIC を確認した結果を “non-repudiation of receipt” と呼ぶが、本稿はそれを一般的な法的判断に広げない。また、配送と業務受理の違いは既存記事の領域である。ここで問うのは、その手前にある検証鍵の選択権限だ。

証拠は、HTTP/TLS 接続、AS2 名の解析と反転、証明書検証、ローカル相手先認可、署名、Message-ID/MIC 相関、MDN disposition、EDI 受理、商業結果の順に積み上がる。途中を省いても、後段の成功は省いた判断を復元しない。

第 03 版にも主要な証明書規定があるため、第 04 版で突然すべて新設されたとは言えない。HTML と XMLは構造確認に使えるが、導入実績の証拠ではない。

監査で再現すべきなのは現在の設定ではなく、メッセージ到着時点の設定である。鍵の受領経路、確認者、承認者、切替時刻、旧鍵の停止時刻がそろって初めて、当時の署名検証に組織的な帰属を与えられる。

情報源と限界

資料は第 04 版のテキスト・HTML・XML、Datatracker のページ・API・履歴、第 03 版、RFC 4130、RFC 8098、RFC 8551、RFC 8615、RFC 5652、RFC 5280、CEM 草案、RFC 9110、RFC 9525、RFC 8446 で構成する。経営判断には Lu Heng の稼働コード優先、現実の層と象徴権力、最小初期仕様を別に参照した。特定製品、障害、攻撃、訴訟についての証拠は含まれない。