Disposition field in Section 7.5 for more information.
Within an EDI trading relationship, if a signed receipt is
expected and is not returned, then the validity of the transaction
is up to the trading partners to resolve.
In general, if a signed receipt is required in the trading
relationship and is not received, the transaction will likely not
be considered valid.
7.3.1. Signed Receipt Considerations
The method used to request a receipt or a signed receipt is defined
in RFC 3798, "An Extensible Message Format for Message Disposition
Notifications".
The "rules" are as follows:
1. When a receipt is requested, explicitly specifying that the
receipt be signed, then the receipt MUST be returned with a
signature.
2. When a receipt is requested, explicitly specifying that the
receipt be signed, but the recipient cannot support either the
requested protocol format or the requested MIC algorithms, then
either a signed or unsigned receipt SHOULD be returned.
3. When a signature is not explicitly requested, or if the signed
receipt request parameter is not recognized by the UA, then no
receipt, an unsigned receipt, or a signed receipt MAY be returned
by the recipient.
NOTE: For Internet EDI, it is RECOMMENDED that when a signature is
not explicitly requested, or if parameters are not recognized, the UA
send back, at a minimum, an unsigned receipt. If, however, a signed
receipt was always returned as a policy, whether requested or not,
then any false unsigned receipts can be repudiated.
When a request for a signed receipt is made, but there is an error in
processing the contents of the message, a signed receipt MUST still
be returned. The request for a signed receipt SHALL still be
honored, though the transaction itself may not be valid. The reason
why the contents could not be processed MUST be set in the
"disposition-field".
When a signed receipt request is made, the "Received-content-MIC"
MUST always be returned to the requester (except when corruption
prevents computation of the digest in accordance with the following
specification). The "Received-content-MIC" MUST be calculated as
follows:
o For any signed messages, the MIC to be returned is calculated
on the RFC1767/RFC3023 MIME header and content.
Canonicalization on the MIME headers MUST be performed before
the MIC is calculated, since the sender requesting the signed
receipt was also REQUIRED to canonicalize.
o For encrypted, unsigned messages, the MIC to be returned is
calculated on the decrypted RFC 1767/RFC3023 MIME header and
content. The content after decryption MUST be canonicalized
before the MIC is calculated.
o For unsigned, unencrypted messages, the MIC MUST be calculated
over the message contents without the MIME or any other RFC
2822 headers, since these are sometimes altered or reordered by
Mail Transport Agents (MTAs).
7.4. MDN Format and Values
This section defines the format of the AS2 Message Disposition
Notification (AS2-MDN).
7.4.1. AS2-MDN General Formats
The AS2-MDN follows the MDN specification [5] except where noted in
this section. The modified ABNF definitions in this document use the
vertical-bar character, ’|’, to denote a logical "OR" construction.
This usage follows RFC 2616 [3]. HTTP entities referred to below are
not further defined in this document. Refer to RFC 2616 [3] for
complete definitions of HTTP entities. The format of the AS2-MDN is:
AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN |
AS2-async-smtp-MDN
AS2-sync-MDN =
Status-Line
*(( general-header | response-header | entity-header )
CRLF )
CRLF
AS2-MDN-body
Status-Line =
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
AS2-async-http-MDN =
Request-Line
*(( general-header | request-header | entity-header )
CRLF )
CRLF
AS2-MDN-body
Request-Line =
Method SP Request-URI SP HTTP-Version CRLF
AS2-async-smtp-MDN =
*(( general-header | request-header | entity-header )
CRLF )
CRLF
AS2-MDN-body
AS2-MDN-body =
AS2-signed-MDN-body | AS2-unsigned-MDN-body
7.4.2. AS2-MDN Construction
The AS2-MDN-body is formatted as a MIME multipart/report with a
report-type of "disposition-notification". When the message is
unsigned, the transfer-layer ("outermost") entity-headers of the
AS2-MDN contain the content-type header that specifies a content-type
of "multipart/report" and parameters indicating the report-type, and
the value of the outermost multipart boundary.
When the AS2-MDN is signed, the transfer-layer ("outermost") entity-
headers of the AS2-MDN contain a content-type header that specifies a
content-type of "multipart/signed" and parameters indicating the
algorithm used to compute the message digest, the signature-
formatting protocol (e.g., pkcs7-signature), and the value of the
outermost multipart boundary. The first part of the MIME
multipart/signed message is an embedded MIME multipart/report of type
"disposition-notification". The second part of the multipart/signed
message contains a MIME application/pkcs7-signature message.
The first part of the MIME multipart/report is a "human-readable"
portion that contains a general description of the message
disposition. The second part of the MIME multipart/report is a
"machine-readable" portion that is defined as:
AS2-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS2-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS2-received-content-MIC-field CRLF ]
7.4.3. AS2-MDN Fields
The rules for constructing the AS2-disposition-notification content
are identical to the disposition-notification-content rules provided
in Section 7 of RFC 3798 [5], except that the RFC 3798 disposition-
field has been replaced with the AS2-disposition-field and that the
AS2-received-content-MIC field has been added. The differences
between the RFC 3798 disposition-field and the AS2-disposition-field
are described below. Where there are differences between this
document and RFC 3798, those entity names have been changed by pre-
pending "AS2-". Entities that do not differ from RFC 3798 are not
necessarily further defined in this document; refer to RFC 3798,
Section 7, "Collected Grammar", for the original grammar.
AS2-disposition-field =
"Disposition" ":" disposition-mode ";"
AS2-disposition-type [ ’/’ AS2-disposition-modifier ]
disposition-mode =
action-mode "/" sending-mode
action-mode =
"manual-action" | "automatic-action"
sending-mode =
"MDN-sent-manually" | "MDN-sent-automatically"
AS2-disposition-type =
"processed" | "failed"
AS2-disposition-modifier =
( "error" | "warning" ) | AS2-disposition-modifier-extension
AS2-disposition-modifier-extension =
"error: authentication-failed" |
"error: decompression-failed" |
"error: decryption-failed" |
"error: insufficient-message-security" |
"error: integrity-check-failed" |
"error: unexpected-processing-error" |
"warning: " AS2-MDN-warning-description |
"failure: " AS2-MDN-failure-description
AS2-MDN-warning-description = *( TEXT )
AS2-MDN-failure-description = *( TEXT )
AS2-received-content-MIC-field =
"Received-content-MIC" ":" encoded-message-digest ","
digest-alg-id CRLF
encoded-message-digest =
1*( ’A’-Z’ | ’a’-’z’ | ’0’-’9’ | ’/’ | ’+’ | ’=’ ) (
i.e. base64( message-digest ) )
digest-alg-id = "sha1" | "md5"
"Insufficient-message-security" and "decompression-failed" are new
error codes that are not mentioned in the AS1 RFC 3335, and may not
be compatible with earlier implementations of AS2.
The "Received-content-MIC" extension field is set when the integrity
of the received message is verified. The MIC is the base64-encoded
message-digest computed over the received message with a hash
function. This field is required for signed receipts but optional
for unsigned receipts. For details defining the specific content
over which the message digest is to be computed, see Section 7.3.1 of
this document.
For signed messages, the algorithm used to calculate the MIC MUST be
the same as that used on the message that was signed. If the message
is not signed, then the SHA-1 algorithm SHOULD be used. This field
is set only when the contents of the message are processed
successfully. This field is used in conjunction with the recipient’s
signature on the MDN so that the sender can verify non-repudiation of
receipt.
AS2-MDN field names (e.g., "Disposition:", "Final-Recipient:") are
case insensitive (cf. RFC 3798, Section 3.1.1). AS2-MDN action-
modes, sending-modes, AS2-disposition-types, and AS2-disposition-
modifier values, which are defined above, and user-supplied *( TEXT )
values are also case insensitive. AS2 implementations MUST NOT make
assumptions regarding the values supplied for AS2-MDN-warning-
description or AS2-MDN-failure-description, or for the values of any
(optional) error, warning, or failure fields.
7.4.4. Additional AS2-MDN Programming Notes
o Unlike SMTP, for HTTP transactions, Original-Recipient and Final-
Recipient SHOULD not be different. The value in Original-
Message-ID SHOULD match the original Message-ID header value.
o Refer to RFC 3798 for the formatting of the MDN, except for the
specific deviations mentioned above.
o Refer to RFC 3462 and RFC 3798 for the formatting of the content-
type entity-headers for the MDN.
o Use an action-mode of "automatic-action" when the disposition
described by the disposition type was a result of an automatic
action rather than that of an explicit instruction by the user for
this message.
o Use an action-mode of "manual-action" when the disposition
described by the disposition type was a result of an explicit
instruction by the user rather than some sort of automatically
performed action.
o Use a sending-mode of "MDN-sent-automatically" when the MDN is
sent because the UA had previously been configured to do so.
o Use a sending-mode of "MDN-sent-manually" when the user explicitly
gave permission for this particular MDN to be sent.
o The sending-mode "MDN-sent-manually" is meaningful ONLY with
"manual-action", not with "automatic-action".
o The "failed" disposition type MUST NOT be used for the situation
in which there is some problem in processing the message other
than interpreting the request for an MDN. The "processed" or
other disposition type with appropriate disposition modifiers is
to be used in such situations.
7.5. Disposition Mode, Type, and Modifier
7.5.1. Disposition Mode Overview
This section provides a brief overview of how "processed", "error",
"failure", and "warning" are used.
7.5.2. Successful Processing Status Indication
When the request for a receipt or signed receipt, and the received
message contents are successfully processed by the receiving EDI UA,
a receipt or MDN SHOULD be returned with the disposition-type set to
"processed". When the MDN is sent automatically by the EDI UA, and
there is no explicit way for a user to control the sending of the
MDN, then the first part of the "disposition-mode" SHOULD be set to
"automatic-action". When the MDN is being sent under user-
configurable control, then the first part of the "disposition-mode"
SHOULD be set to "manual-action". Since a request for a signed
receipt should always be honored, the user MUST not be allowed to
configure the UA not to send a signed receipt when the sender
requests one.
The second part of the disposition-mode is set to "MDN-sent-manually"
if the user gave explicit permission for the MDN to be sent. Again,
the user MUST not be allowed to explicitly refuse to send a signed
receipt when the sender requests one. The second part of the
"disposition-mode" is set to "MDN-sent-automatically" whenever the
EDI UA sends the MDN automatically, regardless of whether the sending
was under the control of a user, administrator, or software.
Because EDI content is generally handled automatically by the EDI UA,
a request for a receipt or signed receipt will generally return the
following in the "disposition-field":
Disposition: automatic-action/MDN-sent-automatically; processed
Note that this specification does not restrict the use of the
"disposition-mode" just to automatic actions. Manual actions are
valid as long as it is kept in mind that a request for a signed
receipt MUST be honored.
7.5.3. Unsuccessful Processed Content
The request for a signed receipt requires the use of two
"disposition-notification-options", which specify the protocol format
of the returned signed receipt, and the MIC algorithm used to
calculate the MIC over the message contents. The "disposition-field"
values that should be used if the message content is being rejected
or ignored (for instance, if the EDI UA determines that a signed
receipt cannot be returned because it does not support the requested
protocol format, the EDI UA chooses not to process the message
contents itself) MUST be specified in the MDN "disposition-field" as
follows:
Disposition: "disposition-mode"; failed/Failure:
unsupported format
The "failed" AS2-disposition-type MUST be used when a failure occurs
that prevents the proper generation of an MDN. For example, this
disposition-type would apply if the sender of the message requested
the application of an unsupported message-integrity-check (MIC)
algorithm.
The "failure:" AS2-disposition-modifier-extension SHOULD be used with
an implementation-defined description of the failure. Further
information about the failure may be contained in a failure-field.
The syntax of the "failed" disposition-type is general, allowing the
sending of any textual information along with the "failed"
disposition-type. Implementations MUST support any printable textual
characters after the Failure disposition-type. For use in Internet
EDI, the following "failed" values are pre-defined and MUST be
supported:
"Failure: unsupported format"
"Failure: unsupported MIC-algorithms"
7.5.4. Unsuccessful Non-Content Processing
When errors occur in processing the received message (other than
content), the "disposition-field" MUST be set to the "processed"
value for disposition-type and the "error" value for disposition-
modifier.
The "error" AS2-disposition-modifier with the "processed"
disposition-type MUST be used to indicate that an error of some sort
occurred that prevented successful processing of the message.
Further information may be contained in an error-field.
An "error:" AS2-disposition-modifier-extension SHOULD be used to
combine the indication of an error with a predefined description of a
specific, well-known error. Further information about the error may
be contained in an error field.
For internet EDI use, the following "error" AS2-disposition-modifier
values are defined:
o "Error: decryption-failed" - the receiver could not
decrypt the message
contents.
o "Error: authentication-failed" - the receiver could not
authenticate the sender.
o "Error: integrity-check-failed" - the receiver could not
verify content integrity.
o "Error: unexpected-processing-error" - a catch-all for any
additional processing
errors.
An example of how the "disposition-field" would look when errors
other than those in content processing are detected is as follows:
Disposition: "disposition-mode"; processed/Error:
decryption-failed
7.5.5. Processing Warnings
Situations arise in EDI when, even if a trading partner cannot be
authenticated correctly, the trading partners still agree to continue
processing the EDI transactions. Transaction reconciliation is done
between the trading partners at a later time. In the content
processing warning situations as described above, the "disposition-
field" MUST be set to the "processed" disposition-type value, and the
"warning" to the "disposition-modifier" value.
The "warning" AS2-disposition-modifier MUST be used with the
"processed" disposition-type to indicate that the message was
successfully processed but that an exceptional condition occurred.
Further information may be contained in a warning-field.
A "warning:" AS2-disposition-modifier-extension SHOULD be used to
combine the indication of a warning with an implementation-defined
description of the warning. Further information about the warning
may be contained in a warning-field.
For use in Internet EDI, the following "warning"
disposition-modifier-extension value is defined:
"Warning: authentication-failed, processing continued"
An example of how the "disposition-field" would look when warning
other than those for content processing are detected is as follows:
Example:
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing continued
7.5.6. Backward Compatibility with Disposition Type, Modifier, and
Extension
The following set of examples represents typical constructions of the
Disposition field that have been in use by AS2 implementations. This
is NOT an exhaustive list of possible constructions. However, AS2
implementations MUST accept constructions of this type to be backward
compatible with earlier AS2 versions.
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically;
processed/error: authentication-failed
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically;
failed/failure: sender-equals-receiver
The following set of examples represents allowable constructions of
the Disposition field that combine the historic constructions above
with optional RFC 3798 error, warning, and failure fields. AS2
implementations MAY produce these constructions. However, AS2
servers are not required to recognize or process optional error,
warning, or failure fields at this time. Note that the use of the
multiple error fields in the second example below provides for the
indication of multiple error conditions.
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically;
processed/error: decryption-failed
Error: The signature did not decrypt into a valid PKCS#1
Type-2 block.
Error: The length of the decrypted key does not equal the
octet length of the modulus.
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Warning: An identical message already exists at the
destination server.
Disposition: automatic-action/MDN-sent-automatically;
failed/failure: sender-equals-receiver
Failure: The AS2-To name is identical to the AS2-From name.
The following set of examples represents allowable constructions of
the Disposition field that employ pure RFC 3798 Disposition-modifiers
with optional error, warning, and failure fields. These examples are
provided as informational only. These constructions are not
guaranteed to be backward compatible with AS2 implementations prior
to version 1.1.
Disposition: automatic-action/MDN-sent-automatically; processed
Disposition: automatic-action/MDN-sent-automatically;
processed/error
Error: authentication-failed
Error: The signature did not decrypt into a valid PKCS#1 Type-2
block.
Error: The length of the decrypted key does not equal the
octet length of the modulus.
Disposition: automatic-action/MDN-sent-automatically;
processed/warning
Warning: duplicate-document
Disposition: automatic-action/MDN-sent-automatically; failed
Failure: sender-equals-receiver
7.6. Receipt Reply Considerations in an HTTP POST
The details of the response to the POST command vary depending upon
whether a receipt has been requested.
With no extended header requesting a receipt, and with no errors
accessing the request-URI specified processing, the status line in
the Response to the POST request SHOULD be in the 200 range. Status
codes in the 200 range SHOULD also be used when an entity is returned
(a signed receipt in a multipart/signed content type or an unsigned
receipt in a multipart/report). Even when the disposition of the
data was an error condition at the authentication, decryption or
other higher level, the HTTP status code SHOULD indicate success at
the HTTP level.
The HTTP server-side application may respond with an unsolicited
multipart/report as a message body that the HTTP client might not
have solicited, but the client may discard this. Applications SHOULD
avoid emitting unsolicited receipt replies because bandwidth or
processing limitations might have led administrators to suspend
asking for acknowledgements.
Message Disposition Notifications, when used in the HTTP reply
context, will closely parallel a SMTP MDN. For example, the
disposition field is a required element in the machine-readable
second part of a multipart/report for a MDN. The final-recipient-
field ([5], Section 3.1) value SHOULD be derived from the entity
headers of the request.
In an MDN, the first part of the multipart/report (the human-readable
part) SHOULD include items such as the subject, the date, and other
information when those fields are present in entity header fields
following the POST request. An application MUST report the Message-
ID of the request in the second part of the multipart/report (the
machine-readable part). Also, an MDN SHOULD have its own unique
Message-ID HTTP header. The HTTP reply SHOULD normally omit the
third optional part of the multipart/report (used to return the
original message or its headers in the SMTP context).
8. Public Key Certificate Handling
In the near term, the exchange of public keys and certification of
these keys MUST be handled as part of the process of establishing a
trading partnership. The UA and/or EDI application interface must
maintain a database of public keys used for encryption or signatures,
in addition to the mapping between the EDI trading partner ID and the
RFC 2822 [9] email address and HTTP URL/URI. The procedures for
establishing a trading partnership and configuring the secure EDI
messaging system might vary among trading partners and software
packages.
X.509 certificates are REQUIRED. It is RECOMMENDED that trading
partners self-certify each other if an agreed-upon certification
authority is not used. This applicability statement does NOT require
the use of a certification authority. The use of a certification
authority is therefore OPTIONAL. Certificates may be self-signed.
It is RECOMMENDED that when trading partners are using S/MIME they
also exchange public key certificates, considering advice provided in
[12].
The message formats useful for certificate exchange are found in [7]
and [13].
In the long term, additional standards may be developed to simplify
the process of establishing a trading partnership, including the