設定の手引き

7 ACMS Cloudで利用する各種通信プロトコルの概要(AS2手順)

7.1 概要

AS2手順が提供する機能の概要を解説します。
ACMS Cloudの概要の他、AS2手順のプロトコルの詳細について学びたい場合は、以下のリンクをご参照ください。
https://community.dal.co.jp/s/article/protocol-as2

7.1.1 特徴

ACMS Cloudの通信機能として、AS2メッセージ交換プロトコル(以降、AS2手順)を実装しています。AS2手順を使用した相互運用が可能になります。

AS2手順はEDIINT(EDI over the Internet)によって定められています。AS1はSMTPを用いた通信方式、AS2はHTTPを用いた通信方式です。

AS2手順は、RFC4130によって定められた機能を実装します。

  • メッセージ処置通知(MDN)による受取
  • 同期応答
  • 非同期式応答
  • 受取の否認防止(NRR:Non-Repudiation of Receipt)
    • メッセージIDと暗号のハッシュ(MIC)の照合による受信後の否認防止
  • S/MIMEによる暗号化およびデジタル署名

AS2手順は、インターネット通信プロトコルであるHTTP Version 1.1を介して、取引企業のビジネスプロセス間でビジネス文書を交換します。

7.1.2 AS2手順

HTTP/1.1の通信プロトコルをサポートします。

TLSプロトコルとの結合によりHTTPSをサポートします。

相互通信に必要な情報は、すべてメッセージヘッダ(HTTPヘッダ/AS2ヘッダ/MIMEヘッダ)部に登録され、ビジネス文書などの送信ファイルはMIMEボディに格納されます。

AS2手順は、前身のAS1プロトコルの通信プロトコルをSMTPからHTTPに変更したものです。そのため、受信確認はMDN(メッセージ処理通知)によって行われます。

またS/MIMEによって暗号化やデジタル署名を行うことにより、データのセキュリティを高めています。

送信者は受信者からMDN(メッセージ処理通知)を受取、その中にある署名、MIC値が正しいことを確認し、データが確実に相手に受け渡されたことを確認します。

7.2 仕様

AS2手順が提供する機能の仕様を解説します。 

7.2.1 メッセージフォーマット

AS2メッセージは、通信に必要な情報をメッセージヘッダに格納します。

メッセージヘッダは、HTTPヘッダ、AS2ヘッダ、MIMEヘッダから構成されます。

7.2.2 圧縮および暗号化、デジタル署名

メッセージの圧縮有無、暗号化有無、署名有無、MDN要否は柔軟に組み合わせて運用可能です。

MDNには署名の有無の2通りがあります。(MDNには圧縮と暗号化はありません)

正確なNRR(受取否認防止)は、署名されたメッセージに対する署名されたMDNによって提供されます。

7.2.2.1 署名付きMIMEマルチパートデータの受信

署名付きのMIMEマルチパートデータの受信はできません。(通信相手にエラーを応答して終了します)

7.2.2.2 メッセージの圧縮および暗号化、デジタル署名

メッセージの圧縮有無、暗号化有無、署名有無、および、MDN要否は柔軟に組み合わせて運用可能ですが、AS2が送信するメッセージの加工は、「署名→圧縮→暗号化」の順序で行います。

受信メッセージの加工の順序は受信メッセージのヘッダ情報“Content-Type:”と“Content-Type:”の“smime-type”に従って判断します。

“Content-Type: multipart/signed;”ならば、署名付きデータ

“Content-Type:”に“smime-type=signed-data”があれば、署名データ

“Content-Type:”に“smime-type=enveloped-data”があれば、暗号化データ

“Content-Type:”に“smime-type=compressed-data”があれば、圧縮データ

MDNには署名なしと署名ありの2通りありますが、圧縮と暗号化は行いません。

ACMS Cloudがデジタル署名を行う際に利用できる証明書の署名アルゴリズムは下記になります。

  • SHA1withRSA
  • SHA224withRSA
  • SHA256withRSA
  • SHA384withRSA
  • SHA512withRSA
  • SHA1withECDSA
  • SHA256withECDSA
  • SHA384withECDSA
  • SHA512withECDSA

通信ユーザー情報の「署名アルゴリズム」に“署名の作成で使用するキーペアに従う”を設定した場合は、キーペアの署名アルゴリズムが上記のアルゴリズムであれば、それに従ってデジタル署名を行います。

キーペアの署名アルゴリズムが上記以外であれば、「SHA1withRSA」を使用します。

7.2.2.3 証明書の要否

必要となる証明書との関連を記述します。

S/MIMEによるメッセージの加工において、メッセージの授受を行う当方(ACMS Cloud)と相手の証明書が必要となります。メッセージの圧縮有無、暗号化有無、署名有無、および送受信の方向により必要となる証明書が異なります。

■メッセージと証明書

No

メッセージ

送信側

受信側

圧縮

暗号化

署名

当方証明書

相手証明書

当方証明書

相手証明書

1

なし

なし

なし

×

×

×

×

2

なし

なし

あり

×

×

3

なし

あり

なし

×

×

4

なし

あり

あり

5

あり

なし

なし

×

×

×

×

6

あり

なし

あり

×

×

7

あり

あり

なし

×

×

8

あり

あり

あり

○:必要、×:不要、△:署名データに相手証明書が含まれない場合に必要

■MDNと証明書

No

MDN

送信側

受信側

返送

署名

当方証明書

相手証明書

当方証明書

相手証明書

1

なし

なし

×

×

×

×

2

あり

なし

×

×

×

×

3

あり

あり

×

×

○:必要、×:不要、△:署名データに相手証明書が含まれない場合に必要

署名に証明書を含めるか否かの設定は「17.1.1.2 論理ファイルを作成する」または「17.2.1.2 論理ファイルを作成する」を参照してください。

7.2.2.4 暗号アルゴリズムとダイジェスト方式

AS2手順は、メッセージの暗号化において通信ユーザー、論理ファイルの送信データの暗号アルゴリズムに指定された共通鍵暗号アルゴリズムを使用します。

MICの計算アルゴリズムであるダイジェスト方式は、受信したMDN署名要求の signed-receipt-micalgパラメーターで指定されたアルゴリズムを使用します。MDN署名要求がない場合には “sha1” を使用します。当方が送信者である場合には通信ユーザーのMICアルゴリズムに指定されたアルゴリズムを使用します。

7.2.2.5 Key agreementアルゴリズムとKey wrapアルゴリズム

メッセージの暗号化において公開鍵アルゴリズムが“ECC”の公開鍵を利用する場合、通信ユーザーのKey agreementアルゴリズムとKey wrapアルゴリズムに指定されたアルゴリズムを使用します。

Key agreement アルゴリズムおよびKey wrap アルゴリズムは共通鍵暗号において共通鍵をメッセージの送信者と受信者とで生成、共有する際に使用されるアルゴリズムとなります。

RFC5753に記載されているKey agreementアルゴリズム、Key wrapアルゴリズムが使用できます。

Key agreement アルゴリズムおよびKey wrap アルゴリズムに関する詳細は「RFC 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)」を参照してください。

■Key agreementアルゴリズム

項目名

説明

ECDH_SHA1KDF

dhSinglePass-stdDH-sha1kdf-scheme

ECDH_SHA224KDF

dhSinglePass-stdDH-sha224kdf-scheme

ECDH_SHA256KDF

dhSinglePass-stdDH-sha256kdf-scheme

ECDH_SHA384KDF

dhSinglePass-stdDH-sha384kdf-scheme

ECDH_SHA512KDF

dhSinglePass-stdDH-sha512kdf-scheme

ECCDH_SHA1KDF

dhSinglePass-cofactorDH-sha1kdf-scheme

ECCDH_SHA224KDF

dhSinglePass-cofactorDH-sha224kdf-scheme

ECCDH_SHA256KDF

dhSinglePass-cofactorDH-sha256kdf-scheme

ECCDH_SHA384KDF

dhSinglePass-cofactorDH-sha384kdf-scheme

ECCDH_SHA512KDF

dhSinglePass-cofactorDH-sha512kdf-scheme

ECMQV_SHA1KDF

mqvSinglePass-sha1kdf-scheme

ECMQV_SHA224KDF

mqvSinglePass-sha224kdf-scheme

ECMQV_SHA256KDF

mqvSinglePass-sha256kdf-scheme

ECMQV_SHA384KDF

mqvSinglePass-sha384kdf-scheme

ECMQV_SHA512KDF

mqvSinglePass-sha512kdf-scheme

ECDH_SHA1KDF

dhSinglePass-stdDH-sha1kdf-scheme

ECDH_SHA224KDF

dhSinglePass-stdDH-sha224kdf-scheme

ECDH_SHA256KDF

dhSinglePass-stdDH-sha256kdf-scheme

ECDH_SHA384KDF

dhSinglePass-stdDH-sha384kdf-scheme

ECDH_SHA512KDF

dhSinglePass-stdDH-sha512kdf-scheme

■Key wrapアルゴリズム

項目名

説明

DES_EDE3_WRAP

id-alg-CMS3DESwrap

AES128_WRAP

id-aes128-wrap

AES192_WRAP

id-aes192-wrap

AES256_WRAP

id-aes256-wrap

7.2.3 メッセージシーケンスとNRR(受取否認防止)

署名されたMDNは、メッセージIDと文書のハッシュ値であるMIC(Message Integrity Check)が記載されています。送信側は、メッセージIDと送信前にあらかじめ計算したMICを保持します。受信したMDNの署名を検証し、問題がなければ受信したMDNに記載されたメッセージIDとMICを送信側で保持するメッセージIDとMICに照合します。その結果、メッセージIDとMICが同一であった場合、NRR(受取否認防止)としてメッセージIDとMICを保存し、受信側がデータを確実に受け取った証拠と見なします。

MICの計算アルゴリズムはsha224、sha256、sha384、sha512、sha1、md5です。

7.2.4 同期・非同期MDNシーケンス

AS2手順は、同期、非同期MDNをサポートします。

■同期MDN

■非同期MDN

7.2.5 AS2メッセージ交換プロトコルの実装仕様

ACMS CloudにおけるAS2メッセージの組立と分解、メッセージ交換の実際の仕様について記述します。

7.2.5.1 ビジネス文章の扱い

ビジネス文書のデータフォーマット、メッセージの種類(文書の種類)、及び、文書の内容に関しては基本的に関知しません。EDI文書のフォーマットの違いやメッセージの種類に関しては、論理ファイルの設定次第となりますが、送受信するビジネス文書自体の加工処理は行いません。

7.2.5.2 通信ユーザーの識別情報

AS2メッセージのメッセージヘッダとACMS Cloudにおける通信ユーザーとの関連を記述します。

受信したメッセージヘッダの“AS2-From”の値から相手識別子を編集し、“AS2-To”の値から当方識別子を編集します。相手識別子と当方識別子を結合して通信ユーザーを検索するインデックス・キーとします。

送信するメッセージヘッダの“AS2-From”の値に通信ユーザーの当方識別子を設定し、“AS2-To”の値に通信ユーザーの相手識別子を設定します。

■通信ユーザー情報との関連

受信ヘッダ

送信ヘッダ

通信ユーザーの項目

AS2-From

AS2-To

相手識別子

AS2-To

AS2-From

当方識別子

7.2.5.3 論理ファイルの識別情報

AS2メッセージのメッセージヘッダとACMS Cloudにおける論理ファイルとの関連を記述します。

AS2プロトコル仕様では、ACMS Cloudにおけるファイルを識別するメッセージヘッダ内のフィールドを明確に規定していません。

AS2メッセージ交換プロトコルでは、通信ユーザーのファイル指定文字列に設定された文字列を、ファイルを識別するためのフィールドとして使用します。デフォルトは“Content-Disposition”フィールドの“filename=”パラメーターとなります。

受信したメッセージヘッダから通信ユーザーのファイル指定文字列に設定されたフィールドの値を取得し、論理ファイルを検索するインデックス・キーとします。通信ユーザーの受信ファイル名の種類を「部分一致」と指定すると、フィールドの値の一部をインデックス・キーとすることができます。「チェックしない」と指定すると、フィールドの値をインデックス・キーとせず、ファイル名を指定しないで登録した論理ファイルを使用して受信処理をおこないます。

送信するメッセージヘッダに通信ユーザーのファイル指定文字列と論理ファイルのファイル名に設定された文字列とを“:△1”で結合して設定します。通信ユーザーのファイル指定文字列を指定しない場合は“Content-Disposition: Attachment; filename=”と論理ファイルのファイル識別文字列に設定された文字列とを結合します。※△は半角スペース(0x20)

■AS2メッセージのメッセージヘッダと論理ファイルとの関連

No

通信ユーザーの項目

固定文字列

論理ファイルの項目

1

ファイル指定文字列

“:△”

ファイル名

2

送信時

“Content-Disposition: Attachment; filename=”

なし

ファイル名

受信時

“Content-Disposition”フィールドの“filename=”パラメーター

※△は半角スペース(0x20)

AS2メッセージの中で、ファイル情報を取得/設定する範囲は次のとおりです。

単独ファイル(非S/MIME形式)受信時

論理ファイルを検索するインデックス・キーをHTTPヘッダのファイル指定文字列に指定されたヘッダから取得します。

グラフィカル ユーザー インターフェイス

AI によって生成されたコンテンツは間違っている可能性があります。
単独ファイル(S/MIME形式)受信、及びマルチファイル受信時

論理ファイルを検索するインデックス・キーをMIMEヘッダのファイル指定文字列に指定されたヘッダから取得します。
なお、RFC2183でContent-Dispositionヘッダのfilenameパラメーターによりボディパートのファイル名を指定することが定められており、各MIMEボディパートのファイル名は各MIMEヘッダに指定する必要がありますが、一部のAS2環境ではHTTPヘッダへのファイル名指定にのみ対応している場合があります。
そのようなAS2環境からのファイル受信時にはHTTPヘッダからインデックス・キーを取得する必要があります。
MIMEヘッダからインデックス・キーの値を取得できない場合にHTTPヘッダから取得するか否かをプロパティ「comm.as2.receive.filename.read.httpheader」で指定可能です。

グラフィカル ユーザー インターフェイス, アプリケーション

AI によって生成されたコンテンツは間違っている可能性があります。

■単独ファイル(非S/MIME形式)送信時

通信ユーザーのファイル指定文字列と論理ファイルのファイル名に設定された文字列を結合した文字列をHTTPヘッダに設定します。

グラフィカル ユーザー インターフェイス が含まれている画像

AI によって生成されたコンテンツは間違っている可能性があります。

単独ファイル(S/MIME形式)送信、及びマルチファイル送信時

通信ユーザーのファイル指定文字列と論理ファイルのファイル名に設定された文字列を結合した文字列をMIMEヘッダに設定します。
なお、RFC2183でContent-Dispositionヘッダのfilenameパラメーターによりボディパートのファイル名を指定することが定められており、各MIMEボディパートのファイル名は各MIMEヘッダに指定する必要がありますが、一部のAS2環境ではHTTPヘッダからのファイル名取得にのみ対応している場合があります。
そのようなAS2環境へのファイル送信時には結合した文字列をHTTPヘッダに設定する必要があります。
HTTPヘッダにも設定するか否かをプロパティ「comm.as2.send.filename.write.httpheader」で指定可能です。

グラフィカル ユーザー インターフェイス が含まれている画像

AI によって生成されたコンテンツは間違っている可能性があります。

7.2.5.4 MDNの編集

ACMS Cloudでは応答時に以下の通りMDNを作成し、通信相手に送信します。

置換シンボルは通信時に具体的な接続相手やメッセージの情報に置換して編集します。

■人間可読メッセージ

MDNの種類

正常MDN

人間可読メッセージ

Content-Type: text/plain; charset=us-ascii

Content-Transfer-Encoding: 7bit

The message sent to Recipient %SelfPartyId% on %RefToMsgDate% with %RefToSubject% has been received.

The EDI Interchange was successfully decrypted, and its integrity was verified.

In addition, the sender of the message, Sender %UserPartyId% was authenticated as the originator of the message.

There is no guarantee, however, that the EDI interchange was syntactically correct, or that it was received by the EDI application/translator.

機械通知メッセージ

Content-Type: message/disposition-notification

Content-Transfer-Encoding: 7bit

Reporting-UA: %Service%@ACMS

Original-Recipient: rfc822; %SelfPartyId%

Final-Recipient: rfc822; %SelfPartyId%

Original-Message-ID: %RefToMessageId%

Disposition: automatic-action/MDN-sent-automatically; processed

Received-Content-MIC: %RefToMIC%, %MicAlg%

エラーMDN

人間可読メッセージ

Content-Type: text/plain; charset=us-ascii

Content-Transfer-Encoding: 7bit

The message sent to Recipient %SelfPartyId% on %RefToMsgDate%with %RefToSubject% has been received. but, %ErrorDescription% occured.

機械通知メッセージ

Content-Type: message/disposition-notification

Content-Transfer-Encoding: 7bit

Reporting-UA: %Service%@ACMS

Original-Recipient: rfc822; %SelfPartyId%

Final-Recipient: rfc822; %SelfPartyId%

Original-Message-ID: %RefToMessageId%

Disposition: automatic-action/MDN-sent-automatically; %errorCode%

Received-Content-MIC: %RefToMIC%, %MicAlg%

■置換シンボル

シンボル

置換情報

%Service%

“EDIINT-AS2”固定

%UserPartyId%

通信ユーザーの相手識別子

%SelfPartyId%

通信ユーザーの当方識別子

%RefToMsgDate%

受信メッセージの”Date:”の値

%RefToSubject%

受信メッセージの”Subject:”の値

%RefToMessageId%

受信メッセージの”Message-Id:”の値

%RefToMIC%

受信メッセージの実データから算出したMIC値

%MicAlg%

受信メッセージのDisposition-Notification-Options:で指定されたMICアルゴリズム

%errorCode%

機械通知メッセージ内、Dispositionフィールドに設定すべきエラーまたは警告

%ErrorDescription%

人間可読メッセージ内に設定すべきエラーまたは警告

■機械通知メッセージのDispositionフィールドに設定するエラーまたは警告

エラーと警告

(%errorCode%)

意味

processed/warning: duplicate-document

二重受信警告

processed/error: decompression-failed

伸張エラー

processed/error: decryption-failed

暗号解読エラー

processed/error: insufficient-message-security

セキュリティが不十分なエラー

processed/error: authentication-failed

署名部の証明書検証エラー(署名エラー)

processed/error: unexpected-processing-error

その他のエラー

■人間可読メッセージに設定するエラーまたは警告

エラーと警告

(%ErrorDescription%)

意味

duplicate-document

二重受信警告

decompression-failed

伸張エラー

decryption-failed

暗号解読エラー

insufficient-message-security

セキュリティが不十分なエラー

authentication-failed

署名部の証明書検証エラー(署名エラー)

unexpected-processing-error

その他のエラー

TOP