EDIINT Working Group
Dale Moberg
Internet draft
Rik Drummond
Expires: December 2003
April 2003
MIME-based Secure Peer-to-Peer
Business Data Interchange over the Internet
Using HTTP
AS2
draft-ietf-ediint-as2-13.txt
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsolete by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Any questions, comments, and reports of defects or
ambiguities in this specification may be sent to the mailing
list for the EDIINT working group of the IETF, using the
address <ietf-ediint@imc.org>. Requests to subscribe to the
mailing list should be addressed to <ietf-ediint-
request@imc.org>.
Copyright Notice
Copyright (c) The Internet Society (2002). All rights
reserved.
NOTE FROM WG LEADER: This draft has been extensively
rewritten from draft-ietf-ediint-as2-11.txt to enhance
clarity. The previous draft attempted to combine two means
of accomplishing the objectives, which made the draft very
cumbersome and greatly contributed to the lack of clarity.
This draft extends the AS1 functionality to HTTP and drops
PGP and GISB related information. In the event that GISB
related information is still required as an IETF standard, I
recommend we do the draft as AS3.
Abstract
This document describes how to exchange structured business
data securely using HTTP transfer for XML, Binary,
Electronic Data Interchange, (EDI - either the American
Standards Committee X12 or UN/EDIFACT, Electronic Data
Interchange for Administration, Commerce and Transport) or
other data describable in MIME used for business to business
data interchange. The data is packaged using standard MIME
content-types. Authentication and privacy are obtained by
using Cryptographic Message Syntax (S/MIME) security body
parts. Authenticated acknowledgements make use of
multipart/signed replies to the original HTTP message.
Feedback Instructions:
NOTE TO RFC EDITOR: This section should be removed by the
RFC editor prior to publication.
If you want to provide feedback on this draft, follow these
guidelines:
-Send feedback via e-mail to the ietf-ediint list for
discussion, with "AS#2" in the Subject field. To enter or
follow the discussion, you need to subscribe to ietf-
ediint@imc.org.
-Be specific as to what section you are referring to,
preferably quoting the portion that needs modification,
after which you state your comments.
-If you are recommending some text to be replaced with your
suggested text, again, quote the section to be replaced, and
be clear on the section in question.
Table of Contents
1.0 Introduction
2.0 Overview
2.1 Overall operations
2.2 Purpose of a security guideline for MIME EDI
2.3 Definitions
2.3.1 Terms
2.3.2 The secure transmission loop
2.3.3 Definition of receipts
2.4 Assumptions
2.4.1 EDI process assumptions
2.4.2 Flexibility assumptions
3.0 Referenced RFCs
3.1 RFC 2616 HTTP v1.1
3.2 RFC 1847 MIME Security Multiparts
3.3 RFC 1892 Multipart/report
3.4 RFC 1767 EDI Content
3.5 RFC 2045, 2046, 2049 MIME
3.6 RFC 2298 Message Disposition Notification
3.7 RFC 2633, 2630 S/MIME Version 3 Message
Specifications
3.8 RFC 2376 XML Media Types
4.0 Structure of an AS2 message
4.1 Introduction
4.2 Structure of an Internet EDI MIME message
5.0 HTTP Considerations
5.1 Sending EDI in HTTP Post Requests
5.2 Unused MIME Headers and Operations
5.2.1 Content-Transfer-Encoding not used in HTTP
transport
5.2.2 Message bodies
5.3 Modification of MIME or other headers or parameters
used
5.3.1 Content-Length
5.3.2 Final Recipient and Original Recipient
5.3.3 Message-Id and Original-Message-Id
5.3.4 Host header
5.4 HTTP Response Status Codes
5.5 HTTP Error Recovery
6.0 Additional AS2 Specific HTTP Headers
6.1 AS2 Version Header
6.2 AS2 System Identifiers
7.0 Structure and Processing of an MDN Message
7.1 Introduction
7.2 Synchronous and Asynchronous MDNs
7.3 Requesting a Signed Receipt
7.3.1 Signed receipt considerations
7.4 MDN Format
7.4.1 AS2-MDN general formats
7.4.2 AS2-MDN construction
7.4.3 AS2-MDN fields
7.4.4 Additional AS2-MDN programming notes
7.5 Disposition Mode, Type, and Modifier
7.5.1 Disposition mode overview
7.5.2 Successful processing status indications
7.5.3 Unsuccessful processed content
7.5.4 Unsuccessful non-content processing
7.5.5 Processing warnings
7.5.6 Backwards compatibility with disposition
Type, Modifier, and Extension
7.6 Receipt Reply Considerations in a HTTP Post
8.0 Public Key Certificate Handling
9.0 Security Considerations
10.0 Acknowledgements
11.0 References
12.0 Authors' Addresses
Appendix
A. Message Examples
B. IANA Registration Form
1.0 Introduction
Previous work on Internet EDI focused on specifying MIME
content types for EDI data [2] and extending this work to
support secure EC/EDI transport over SMTP [4]. This
document expands on RFC 1767 to specify a comprehensive set
of data security features, specifically data privacy, data
integrity/authenticity, non-repudiation of origin and non-
repudiation of receipt over HTTP. This document also
recognizes contemporary RFCs and is attempting to "re-
invent" as little as possible. While this document focuses
on EDI data, any other data type describable in a MIME
format are also supported.
Internet MIME based EDI can be accomplished by using and
complying with the following RFC's :
-RFC 2616 Hyper Text Transfer Protocol
-RFC 1767 EDI Content Type
-RFC 2376 XML Media Types
-RFC 1847 Security Multiparts for MIME
-RFC 1892 Multipart/Report
-RFC 2045 to 2049 MIME RFC's
-RFC 2298 Message Disposition Notification
-RFC 2630, 2633 S/MIME v3 Specification
Our intent here is to define clearly and precisely how these
are used together, and what is required by user agents to be
compliant with this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119.
2.0 Overview
2.1 Overall Operations
A HTTP POST operation [3] is used to send appropriately
packaged EDI, XML, or other business data. The Request-URI
([3], section 9.5) identifies a process to unpack and handle
the message data and to generate a reply for the client that
contains a message disposition acknowledgement or a
multipart/report, signed or unsigned, and possibly other
turnaround transactions. This request/reply transactional
interchange provides secure, reliable, and authenticated
transport for EDI or other business data which use HTTP. The
security protocols and structures used also support
auditable records of these transmissions, acknowledgements,
and authentication.
2.2 Purpose of a security guideline for MIME EDI
The purpose of these specifications is to ensure
interoperability between B2B Electronic Commerce user
agents, invoking some or all of the commonly expected
security features. This document is also NOT limited to
strict EDI use, but applies to any electronic commerce
application where business data needs to be exchanged over
the Internet in a secure manner.
2.3 Definitions
2.3.1. Terms
EDI - Electronic Data Interchange
EC - Business to Business Electronic Commerce
B2B - Business to Business
Receipt - The functional message that is sent from a
receiver to a sender to acknowledge receipt of an EDI/EC
interchange. This message may be either synchronous or
asynchronous in nature.
Signed Receipt - A receipt with a digital signature.
Synchronous Receipt - A receipt returned to the sender
during the same HTTP session as the sender's original
message
Asynchronous Receipt - A receipt returned to the sender
on a different communication session than the sender's
original message session
Message Disposition Notification (MDN) - The Internet
messaging format used to convey a receipt. This term is used
interchangeably with receipt. A MDN is a receipt.
Non-repudiation of receipt (NRR) - NRR is a "legal
event" that occurs when the original sender of an EDI/EC
interchange has verified the signed receipt coming back from
the receiver. NRR IS NOT a functional or a technical
message.
S/MIME - A format and protocol for adding Cryptographic
signature and/or encryption services to Internet MIME
messages.
CMS - Cryptographic Message Syntax (CMS) is an
encapsulation syntax used to digitally sign, digest,
authenticate, or encrypt arbitrary messages.
SHA-1 - A secure, one-way hash algorithm used in
conjunction with digital signature. This is the recommend
algorithm for AS2
MD5 - A secure, one-way hash algorithm used in
conjunction with digital signature. This algorithm is
accepted in AS2 but not recommended due to its short key
length
MIC - The message integrity check (MIC), also called
the message digest, is the digest output of the hash
algorithm used by the digital signature. The digital
signature is computed over the MIC.
User Agent (UA) - The application that handles and
processes the AS2 request
2.3.2 The secure transmission loop
This document's focus is on the formats and protocols for
exchanging EDI/EC content that has had security applied to
it using the Internet's HTTP environment.
The "secure transmission loop" for EDI/EC involves one
organization sending a signed and encrypted EDI/EC
interchange to another organization, requesting a signed
receipt, followed later by the receiving organization
sending this signed receipt back to the sending
organization. In other words, the following transpires:
-The organization sending EDI/EC data signs and
encrypts the data using S/MIME. In addition, the message
will request a signed receipt to be returned to the sender
of the message.
-The receiving organization decrypts the message and
verifies the signature, resulting in verified integrity of
the data and authenticity of the sender.
-The receiving organization then returns a signed
receipt, as requested either synchronously or
asynchronously, to the sending organization in the form of a
message disposition notification. This signed receipt will
contain the hash of the signature from the received message,
indicating to the sender that the received message was
verified and/or decrypted properly.
The above describes functionality which, if implemented,
will satisfy all security requirements and implement non-
repudiation of receipt for the exchange. This specification,
however, leaves full flexibility for users to decide the
degree to which they want to deploy those security features
with their trading partners.
2.3.3 Definition of receipts
The term used for both the functional activity and the
message for acknowledging delivery of an EDI/EC interchange
is receipt or signed receipt. The term is used if the
acknowledgment is for an interchange resulting in a receipt
which is NOT signed. The second term is used if the
acknowledgment is for an interchange resulting in a receipt
which IS signed.
A term often used in combination with receipts is non-
repudiation of receipt. NRR refers to a legal event which
occurs only when the original sender of an interchange has
verified the signed receipt coming back from recipient of
the message. Note that NRR is not possible without
signatures.
For information on how to format and process receipts in
AS2, refer to section 7.
2.4 Assumptions
2.4.1 EDI/EC process assumptions
-Encrypted object is an EDI/EC Interchange
This specification assumes that a typical EDI/EC interchange
is the lowest level object that will be subject to security
services.
Specifically, in EDI ANSI X12, this means anything between,
and including segments ISA and IEA. In EDIFACT, this
means anything between, and including, segments UNA/UNB and
UNZ. In other words, the EDI/EC interchanges including
envelope segments remain intact and unreadable during secure
transport.
-EDI envelope headers are encrypted
Congruent with the above statement, EDI envelope headers are
NOT visible in the MIME package. In order to optimize
routing from existing commercial EDI networks (called Value
Added Networks or VANs) to the Internet, work may need to be
done in the future to define ways to pull out some of the
envelope information to make them visible; however, this
specification does not go into any detail on this.
-X12.58 and UN/EDIFACT security considerations
The most common EDI standards bodies, ANSI X12 and EDIFACT,
have defined internal provisions for security. X12.58 is
the security mechanism for ANSI X12 and AUTACK provides
security for EDIFACT. This specification DOES NOT dictate
use or non-use of these security standards. They are both
fully compatible, though possibly redundant, with this
specification.
2.4.2 Flexibility assumptions
-Encrypted or un-encrypted data
This specification allows for EDI/EC message exchange where
the EDI/EC data can either be un-protected or protected by
means of encryption.
-Signed or unsigned data
This specification allows for EDI/EC message exchange with
or without digital signature of the original EDI
transmission.
-Use of receipt or not
This specification allows for EDI/EC message transmission
with or without a request for receipt notification. If a
signed receipt notification is requested however, a MIC
value is REQUIRED as part of the returned receipt, unless an
error condition occurs in which a MIC value cannot be
returned. In error cases, an unsigned receipt or MDN SHOULD
be returned with the correct "disposition modifier" error
value.
-Use of synchronous or asynchronous receipts
This specification allows in addition to a receipt request
the specification of the type of receipt that should be
returned. It supports synchronous or asynchronous receipts
in the MDN format specified in section 7 of this document.
-Security Formatting
This specification relies on the guidelines set forth in RFC
2633/2630 [8] "S/MIME Version 3 Message Specification;
Cryptographic Message Syntax". S/MIME as defined in this
Applicability statement.
-Hash function, message digest choices
When a signature is used, it is RECOMMENDED that the SHA1
hash algorithm be used for all outgoing messages, and that
both MD5 and SHA1 be supported for incoming messages.
-Permutation Summary
In summary, the following twelve security permutations are
possible in any given trading relationship:
1. Sender sends un-encrypted data, does NOT request a
receipt.
2. Sender sends un-encrypted data, requests an unsigned
receipt. The receiver sends back the unsigned receipt.
3. Sender sends un-encrypted data, requests a signed
receipt. The receiver sends back the signed receipt.
4. Sender sends encrypted data, does NOT request a
receipt.
5. Sender sends encrypted data, requests an unsigned
receipt. The receiver sends back the unsigned receipt.
6. Sender sends encrypted data, requests a signed receipt.
The receiver sends back the signed receipt.
7. Sender sends signed data, does NOT request a signed or
unsigned receipt.
8. Sender sends signed data, requests an unsigned receipt.
Receiver sends back the unsigned receipt.
9. Sender sends signed data, requests a signed receipt.
Receiver sends back the signed receipt.
10. Sender sends encrypted and signed data, does NOT
request a signed or unsigned receipt.
11. Sender sends encrypted and signed data, requests an
unsigned receipt. Receiver sends back the unsigned receipt.
12. Sender sends encrypted and signed data, requests a
signed receipt. Receiver sends back the signed receipt.
NOTE: Users can choose any of the twelve possibilities, but
only the last example (12), when a signed receipt is
requested, offers the whole suite of security features
described in the "Secure transmission loop" above.
Additionally, the receipts discussed above may be either
synchronous or asynchronous in nature depending on the type
requested. The use of either the synchronous or asynchronous
receipts does not change the nature of the "Secure
transmission loop" in support of NRR.
3.0 Referenced RFC's and their contribution
3.1 RFC 2616 HTTP v1.1 [3]
This document specifies how data is transferred using HTTP.
3.2 RFC 1847 MIME Security Multiparts [6]
This document defines security multipart for MIME:
multipart/encrypted and multipart/signed.
3.3 RFC 1892 Multipart/report [9]
This RFC defines the use of the multipart/report content
type, something that the MDN RFC 2298 builds upon.
3.4 RFC 1767 EDI Content [2]
This RFC defines the use of content type "application" for
ANSI X12 (application/EDI-X12), EDIFACT
(application/EDIFACT) and mutually defined EDI
(application/EDI-Consent).
3.5 RFC 2045, 2046, and 2049 MIME [1]
These are the basic MIME standards, upon which all MIME
related RFCs build, including this one. Key contributions
include definition of "content type", "sub-type" and
"multipart", as well as encoding guidelines, which
establishes 7-bit US-ASCII as the canonical character set to
be used in Internet messaging.
3.6 RFC 2298 Message Disposition Notification [5]
This Internet RFC defines how a MDN is requested, and the
format and syntax of the MDN. The MDN is the basis upon
which receipts and signed receipts are defined in this
specification.
3.7 RFC 2633 and 2630 S/MIME Version 3 Message
Specifications [8]
This specification describes how MIME shall carry
Cryptographic Message Syntax (CMS) Objects.
3.8 RFC 2376 XML Media Types [12]
This RFC defines the use of content type "application" for
XML (application/xml).
4.0 Structure of an AS2 message
4.1 Introduction
The basic structure of an AS2 messages consists of MIME
format inside an HTTP message with a few additional specific
AS2 headers. The structures below are described
hierarchically in terms of which RFC's are applied to form
the specific structure. For details of how to code in
compliance with all RFC's involved, turn directly to the
RFC's referenced. Any difference between AS2 implantations
and RFCs are mentioned specifically in the sections below.
4.2 Structure of an Internet EDI MIME message
No encryption, no signature
-RFC2616/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
No encryption, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC2633 (application/pkcs7-signature)
Encryption, no signature
-RFC2616/2045
-RFC2633 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or
/xml)(encrypted)
Encryption, signature
-RFC2616/2045
-RFC2633 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or
/xml)(encrypted)
-RFC2633 (application/pkcs7-signature)(encrypted)
MDN over HTTP, no signature
-RFC2616/2045
-RFC2298 (message/disposition-notification)
MDN over HTTP, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC2298 (message/disposition-notification)
-RFC2633 (application/pkcs7-signature)
MDN over SMTP, no signature
MDN over SMTP, signature
Refer to the EDI over SMTP standard [4].
While all MIME content types SHOULD be supported. The
following MIME content types MUST be supported:
Content-type: multipart/signed
Content-Type: multipart/report
Content-type: message/disposition-notification
Content-Type: application/PKCS7-signature
Content-Type: application/PKCS7-mime
Content-Type: application/EDI-X12
Content-Type: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML
5.0 HTTP Considerations
5.1 Sending EDI in HTTP Post Requests
The request line will have the form: "POST Request-URI
HTTP/1.1", with spaces and followed by a CRLF. The Request-
URI is typically exchanged out of band, as part of setting
up a bilateral trading partner agreement. Applications
should be prepared to deal with an initial reply containing
a status indicating a need for authentication of the usual
types used for authorizing access to the Request-URI ([3],
section 10.4.2 and elsewhere).
The request line is followed by entity headers specifying
content length ([3] section 14.14) and content type ([3],
section 14.18). The Host request header ([3] sections 9 and
14.23) is also included.
When using Transport Layer Security [10] or SSLv3, the
request-URI should indicate the appropriate scheme value,
HTTPS. Usually only a multipart/signed message body would be
sent using TLS, as encrypted message bodies would be
redundant. Encrypted message bodies are not prohibited,
however.
The receiving AS2 system MAY disconnect from the sending AS2
system before completing the reception of the entire entity
if it determines the entity being sent is too large to
process.
For HTTP version 1.1, TCP persistent connections are the
default, ([3] sections 8.1.2, 8.2, and 19.7.1). A number of
other differences exist because HTTP does not conform to
MIME [1] as used in SMTP transport. Relevant differences are
summarized below.
5.2 Unused MIME Headers and Operations
5.2.1 Content-Transfer-Encoding not used in HTTP transport
HTTP can handle binary data and so there is no need to use
the Content transfer encodings of MIME [1]. This difference
is discussed in [3] section 19.4.4. However, a Content
transfer encoding value of binary or 8-bit is permissible
but not required. The absence of this header must not result
in transaction failure. Content transfer encoding of MIME
bodyparts within the AS2 message is also allowed.
5.2.2 Message bodies
In [3] section 3.7.2, it is explicitly noted that multiparts
must have null epilogues.
In [4], sections 5.4.1, options for large file processing
are discussed for SMTP transport. For HTTP, large files
should be handled correctly by the TCP layer. However, [3]
sections 3.5 and 3.6 discuss some options for compressing or
chunking entities to be transferred. [3] Section 8.1.2.2
discusses a pipelining option that is useful for segmenting
large amounts of data.
5.3 Modification of MIME or other headers or parameters used
5.3.1 Content-Length
Because connections are persistent, [3] sections 4.4 and
14.14 indicate that a Content-Length entity header in a
request (provided that chunked transfer-encoding is not
used). The only exception to this for AS2 messages is when a
one-line, successful, HTTP response is provided.
5.3.2 Final Recipient and Original Recipient
The final and original recipient values SHOULD be the same
value. These values MUST NOT be aliases or mailing lists.
5.3.3 Message-Id and Original-Message-Id
Message-Id and Original-Message-Id is formatted as defined
in RFC2822:
"<" id-left "@" id-right ">" (RFC2822 3.6.4)
Message-Id length is a maximum of 998 characters. For
maximum backward compatibility, Message-Id length SHOULD be
255 characters or less. Message-Id SHOULD be globally
unique, id-right should be something unique to the sending
host environment (e.g. a host name).
When sending a message, always include the angle brackets.
Angle brackets are not part of the Message-Id value. For
maximum backward compatibility, when receiving a message, do
not check for angle brackets. When creating the Original-
Message-Id header in an MDN, always use the exact syntax as
received on the original message - don't strip or add
angle brackets.
5.3.4 Host header
The host request header field must be included in the POST
request made when sending business data. This field is to
allow one server IP address to service multiple hostnames,
and potentially conserve IP addresses. See [3], sections
14.23 and 19.5.1.
5.4 HTTP Response Status Codes
The status codes return status concerning HTTP operations.
For example, the status code 401, together with the WWW-
Authenticate header, is used to challenge the client to
repeat the request with an Authorization header. Other
explicit status codes are documented in [3], sections
6.1.1 and throughout section 10.
For errors in the request-URI, 400 ("Bad Request"), 404
("Not Found") and similar codes are appropriate status
codes. These codes and their semantics are specified by [3].
A careful examination of these codes and their semantics
should be made before implementing any retry functionality.
Retries should not be made if the error is not transient or
if retries are explicitly discouraged.
5.5 HTTP Error Recovery
If the HTTP client fails to read the HTTP server response
data, the POST operation with identical content, including
same Message-ID should be repeated, if the condition is
transient.
The Message-ID on a POST operation can be reused if and only
if all of the content (including the original Date) is
identical.
Details of the retry process -- including time intervals to
pause, number of retries to attempt, timeouts for retrying -
- are implementation dependent. These settings are selected
as part of the trading partner agreement.
Servers should be prepared to receive a POST with a repeated
Message-ID. The MIME reply body previously sent should be
resent, including the MDN and other MIME parts.
6.0 Additional AS2 Specific HTTP Headers
The following headers are to be included in all AS2 messages
and all AS2 MDNs, except for asynchronous MDNs that are sent
using SMTP and follow the AS1 semantics[4].
6.1 AS2 Version Header
To promote backward compatibility AS2 includes a version:
AS2-Version: 1.0 - is used in all implementations
implementing this specification. 1.x
will be interpreted as 1.0 by all
implementation implemented with the AS2-
Version: 1.0 header. That is only the
most significant digit is used as the
version identifier for those not
implementing additional non-AS2
specified functionality.
AS2-Version: 1.0 through 1.9 MAY be used
All implementations WILL interpret "1.0
through 1.9" as implementing this
specification. However implementation
MAY extend this specification with
additional functionality by specifying
versions 1.1 through 1.9. If this
mechanism is used the additional
functionality WILL be completely
transparent to implementations with AS2-
Version: 1.0 designation.
AS2-Version: 1.1 - Designates those implementations which
support Compression as defined by RFC
3274.
Receiving systems MUST NOT fail due to the absence of the
AS2-Version header. Absence would indicate the message is
from an implementation based on a previous version of this
specification.
6.2 AS2 System Identifiers
To aid the receiving system in identifying the sending
system, AS2-From and AS2-To headers are used.
AS2-From: < AS2-name >
AS2-To: < AS2-name >
These AS2 headers contain textual values, as described
below, identifying the sender/receiver of a data exchange.
Their values may be company specific, such as DUNS number,
or it may be simply an identification string agreed upon
between the trading partners.
AS2-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS2-qtext = AS2-text / SP ; allow space only in quoted
text
AS2-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
AS2-quoted-pair) DQUOTE
AS2-atomic-name = 1*128AS2-text
AS2-name = AS2-atomic-name / AS2-quoted-name
The AS2-From header value and the AS2-To header value MUST
each be an AS2-name, MUST each be comprised of from 1 to 128
printable ASCII characters and MUST NOT be folded. The value
in each of these headers is case-sensitive. The string
definitions given above are in ABNF format.
The AS2-quoted-name SHOULD be used only if the AS2-name does
not conform to AS2-atomic-name.
The AS2-To and AS2-From header fields MUST be present in all
AS2 messages and AS2 MDN's whether asynchronous or
synchronous in nature, except for asynchronous MDNs which
are sent using SMTP.
The sending system may choose to limit the possible AS2-
To/AS2-From textual values but must not exceed them. The
receiving system must make no restrictions on the textual
values and should handle all possible implementations.
However, implementers must be aware that older AS2 products
may not adhere to this convention. Trading partner
agreements should be made to insure that older products can
support the system identifiers that are used.
There is no required response to a client request containing
invalid or unknown AS2-From or AS2-To header values. The
receiving AS2 system MAY return an unsigned MDN with an
explanation of the error, if the sending system requested an
MDN.
7.0 Structure and Processing of an MDN Message
7.1 Introduction
In order to support non-repudiation of receipt, a signed
receipt, based on digitally signing a message disposition
notification, is to be implemented by a receiving trading
partner's UA. The message disposition notification,
specified by RFC 2298 is digitally signed by a receiving
trading partner as part of a multipart/signed MIME message.
The following support for signed receipts is REQUIRED:
1) The ability to create a multipart/report; where the
report-type = disposition-notification.
2) The ability to calculate a message integrity check
(MIC) on the received message. The calculated MIC value
will be returned to the sender of the message inside
the signed receipt.
3) The ability to create a multipart/signed content
with the message disposition notification as the first
body part, and the signature as the second body part.
4) The ability to return the signed receipt to the
sending trading partner.
5) The ability to return either a synchronous or
asynchronous receipt as the sending party requests.
The signed receipt is used to notify a sending trading
partner that requested the signed receipt that:
1) The receiving trading partner acknowledges
receipt of the sent EC Interchange.
2) If the sent message was signed, then the
receiving trading partner has authenticated the sender
of the EC Interchange.
3) If the sent message was signed, then the
receiving trading partner has verified the integrity of
the sent EC Interchange.
Regardless of whether the EDI/EC Interchange was sent in
S/MIME format or not, the receiving trading partner's UA
MUST provides the following basic processing:
1) If the sent EDI/EC Interchange is encrypted, then
the encrypted symmetric key and initialization vector
(if applicable) is decrypted using the receiver's
private key.
2) The decrypted symmetric encryption key is then
used to decrypt the EDI/EC Interchange.
3) The receiving trading partner authenticates
signatures in a message using the sender's public key.
The authentication algorithm performs the following:
a) The message integrity check (MIC or Message
Digest), is decrypted using the sender's public
key.
b) A MIC on the signed contents (the MIME header
and encoded EDI object, as per RFC 1767) in the
message received is calculated using the same one-
way hash function that the sending trading partner
used.
c) The MIC extracted from the message that was
sent, and the MIC calculated using the same one-
way hash function that the sending trading partner
used is compared for equality.
4) The receiving trading partner formats the MDN and
sets the calculated MIC into the "Received-content-MIC"
extension field.
5) The receiving trading partner creates a
multipart/signed MIME message according to RFC 1847.
6) The MDN is the first part of the multipart/signed
message, and the digital signature is created over this
MDN, including its MIME headers.
7) The second part of the multipart/signed message
contains the digital signature. The "protocol" option
specified in the second part of the multipart/signed is
as follows:
S/MIME: protocol = "application/pkcs-7-
signature"
8) The signature information is formatted according
to S/MIME specifications.
The EC Interchange and the RFC 1767 MIME EDI content header
can actually be part of a multi-part MIME content-type.
When the EDI Interchange is part of a multi-part MIME
content-type, the MIC MUST be calculated across the entire
multi-part content, including the MIME headers.
The signed MDN, when received by the sender of the EDI
Interchange can be used by the sender:
1) As an acknowledgment that the EDI Interchange sent,
was delivered and acknowledged by the receiving trading
partner. The receiver does this by returning the
original-message-id of the sent message in the MDN
portion of the signed receipt.
2) As an acknowledgment that the integrity of the EDI
Interchange was verified by the receiving trading
partner. The receiver does this by returning the
calculated MIC of the received EC Interchange (and 1767
MIME headers) in the "Received-content-MIC" field of
the signed MDN.
3) As an acknowledgment that the receiving trading
partner has authenticated the sender of the EDI
Interchange.
4) As a non-repudiation of receipt when the signed MDN
is successfully verified by the sender with the
receiving trading partner's public key and the
returned MIC value inside the MDN is the same as the
digest of the original message.
7.2 Synchronous and Asynchronous MDNs
The AS2-MDN exists in two varieties: synchronous and
asynchronous.
The synchronous AS2-MDN is sent as an HTTP response to an
HTTP POST or as an HTTPS response to an HTTPS POST. This
form of AS2-MDN is called synchronous because the AS2-MDN is
returned to the originator of the POST on the same TCP/IP
connection.
The asynchronous AS2-MDN is sent on a separate HTTP, HTTPS,
or SMTP TCP/IP connection. Logically, the asynchronous AS2-
MDN is a response to an AS2 message. However, at the
transfer-protocol layer, assuming that no HTTP pipelining is
utilized, the asynchronous AS2-MDN is delivered on a unique
TCP/IP connection, distinct from that used to deliver the
original AS2 message. When handling an asynchronous request,
the HTTP response must be sent back before the MDN is
processed and sent on the separate connection.
When an asynchronous AS2-MDN is requested by the sender of
an AS2 message, the synchronous HTTP or HTTPS response
returned to the sender prior to terminating the connection
MUST be a transfer-layer response indicating the success or
failure of the data transfer. The format of such a
synchronous response MAY be the same as that response
returned when no AS2-MDN is requested.
The following diagram illustrates the synchronous versus
asynchronous varieties of AS2-MDN delivery:
Synchronous AS2-MDN
[C] ----( connect )----> [S]
[C] -----( send )------> [S] [HTTP Request [AS2-Message]]
[C] <---( receive )----- [S] [HTTP Response [AS2-MDN]]
Asynchronous AS2-MDN
[C] ----( connect )----> [S]
[C] -----( send )------> [S] [HTTP Request [AS2-Message]]
[C] <---( receive )----- [S] [HTTP Response]
[C]*<---( connect )----- [S]
[C] <--- ( send )------- [S] [HTTP Request [AS2-MDN]]
[C] ----( receive )----> [S] [HTTP Response]
* Note: An AS2-MDN may be directed to a different host than
that of the sender of the AS2 message and may utilize a
different transfer protocol than that used to send the
original AS2 message.
The advantage of the synchronous MDN is that it can provide
the sender of the AS2 Message with a verifiable confirmation
of message delivery within a synchronous logic flow.
However, if the message is relatively large, the time
required to process this message and return an AS2-MDN to
the sender on the same TCP/IP connection may exceed the
maximum configured time permitted for an IP connection.
The advantage of the asynchronous MDN is that it provides
for the rapid return of a transfer-layer response from the
receiver confirming the receipt of data, therefore not
requiring a TCP/IP connection to necessarily remain open for
very long. However, this design requires that the
asynchronous AS2-MDN contain enough information to uniquely
identify the original message so that, when received by the
AS2 Message originator, the status of the original AS2
Message can be properly updated based on the contents of the
AS2-MDN.
Synchronous MDNs and asynchronous HTTP and HTTPS MDNs are
handled according to the requirements of this specification.
However, asynchronous SMTP MDNs are formatted according the
requirements of RFC 3335 [4].
7.3 Requesting a Signed Receipt
Message Disposition Notifications are requested as per RFC
2298. A request that the receiving user agent issue a
message disposition notification is made by placing the
following header into the message to be sent:
MDN-request-header = "Disposition-notification-to"
":" mail-address
This syntax is a residual of the use of MDN's in a SMTP
transfer. Since this specification is adjusting the
functionality from SMTP to HTTP and retaining as much as
possible from the [4] functionality, the mail-address must
be present but has no meaning in this specification. The
mail-address field is specified as an RFC 2822 local-
part@domain [addr-spec] address, and while it MUST be
present, it MUST NOT be used in any manner in products. Lack
of the appropriate syntax WILL BE ignored by the receiving
application.
In addition to requesting a message disposition
notification, an asynchronous message disposition
notification can be requested by placing the following
header into the message to be sent:
Receipt-Delivery-Option: return-url
For requesting MDN based receipts, the originator supplies
the syntax of extension headers that precede the message
body.
The header "tags" are as follows:
A Disposition-notification-to header is added to indicate
that a message disposition notification is requested in the
reply to the POST request. This header is specified in [5].
A Message-ID header is added to support message
reconciliation, so that an Original-Message-Id value can be
returned in the body part of MDN. Other headers, especially
"Subject" and "Date", SHOULD be supplied; the values of
these headers are often mentioned in the human-readable
section of a MDN to aid in identifying the original message.
Disposition-notification-options identifies characteristics
of message disposition notification in accordance with [5].
EXAMPLE:
Disposition-notification-to: xxx@temp.org
// Requests the MDN
Disposition-notification-options: //
The signing options
signed-receipt-protocol=optional, pkcs7-signature;
// for the MDN
signed-receipt-micalg=optional, sha1, md5
Receipt-Delivery-Option: return-url
// Requests the MDN
// to be
asynchronous
Disposition-notification-options syntax:
Disposition-notification-options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
where
disposition-notification-parameters =
parameter *(";" parameter)
where
parameter = attribute "=" importance ", " 1#value"
where
importance = "required" | "optional"
So the Disposition-notification-options string could be:
signed-receipt-protocol=optional, <protocol
symbol>;
signed-receipt-micalg=optional, <micalg1>,
<micalg2>,...;
The currently supported value for <protocol symbol> is
"pkcs7-signature" for the S/MIME detached signature format.
The currently supported values for MIC algorithm <micalg>
values are:
Algorithm Value
Used
--------- -------
MD5 md5
SHA-1 sha1
Receipt-delivery-option syntax:
The "receipt-delivery-option: return-url" string indicates
the url to return the asynchronous MDN. This string is NOT
present if the receipt is to be synchronous. Because the
email value in Disposition-notification-to has no
significance for how or where the receipt is transported,
the extension header "Receipt-delivery-option" is to be used
to provide that information. The receipt-delivery-option's
value MUST be a URL indicating the delivery transport
destination for the receipt.
An example request for an asynchronous MDN via an HTTP
transport:
Receipt-delivery-option: http://www.AS2system.com
An example request for an asynchronous MDN via an HTTP/S
transport:
Receipt-delivery-option: https://www.AS2system.com
An example request for an asynchronous MDN via an SMTP
transport:
Receipt-delivery-option: mailto:joe@abc.com
For more information on requesting SMTP MDNs, refer to RFC
3335 [4].
The semantics of the "signed-receipt-protocol" and the
"signed-receipt-micalg" parameters
The semantics of the "signed-receipt-protocol" parameter is
as follows:
1) The "signed-receipt-protocol" parameter is used to
request a signed receipt from the recipient trading partner.
The "signed-receipt-protocol" parameter also specifies the
format in which the signed receipt should be returned to the
requester.
The "signed-receipt-micalg" parameter is a list of
MIC algorithms preferred by the requester for use in signing
the returned receipt. The list of MIC algorithms should be
honored by the recipient from left to right.
Both the "signed-receipt-protocol" and the "signed-
receipt-micalg" option parameters are REQUIRED when
requesting a signed receipt.
The lack of the presence of the "Receipt-Delivery-Option"
indicates a receipt is synchronous in nature. The presence
of the "Receipt-Delivery-Option: return-url" indicates that
an asynchronous receipt is requested and should be sent to
the "return-url".
2) The "importance" attribute of "Optional" is defined in
the RFC 2298 section 2.2 and has the following meaning:
Parameters with an importance of "Optional" permit a
UA that does not understand the particular options parameter
to still generate a MDN in response to a request for a MDN.
A UA that does not understand the "signed-receipt-protocol"
parameter, or the "signed-receipt-micalg" will obviously
not return a signed receipt.
The importance of "Optional" is used for the signed
receipt parameters because it is RECOMMENDED that an MDN be
returned to the requesting trading partner even if the
recipient could not sign it.
The returned MDN will contain information on the
disposition of the message as well as why the MDN could not
be signed. See the 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 2298, "An Extensible Message Format for
Message Disposition Notifications".
The "rule" is:
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 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, that the UA send back at a minimum, an
unsigned receipt. If a signed receipt however 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 for why the contents
could not be processed MUST be set in the "disposition-
field".
When a request for a signed receipt is made, the
"Received-content-MIC" MUST always be returned to the
requester. The "Received-content-MIC" MUST be calculated as
follows:
- For any signed messages, the MIC to be returned is
calculated on the RFC1767/RFC2376 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.
- For encrypted, unsigned messages, the MIC to be returned
is calculated on the decrypted RFC 1767/RFC2376 MIME header
and content. The content after decryption MUST be
canonicalized before the MIC is calculated.
- For unsigned, unencrypted messages, the MIC MUST be
calculated over the message contents without the MIME or any
other RFC 822 headers, since these are sometimes altered or
reordered by MTAs.
7.4 MDN Format and value
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 entity 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
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 rules for constructing the
disposition-notification-content as defined in section 7 of
RFC 2298 [5] except that the RFC 2298 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 2298 disposition-field and the
AS2-disposition-field are described below. Where there are
differences between this document and RFC 2298, those entity
names have been changed by pre-pending "AS2-". Entities
below that do not differ from RFC 2298 are not necessarily
further defined in this document. Refer to RFC 2298 for AS2-
MDN entities that are not further defined in this document.
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 newer error codes to this specification, are not
mentioned in the AS1 RFC, 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.
The algorithm used to calculate the message-digest MUST be
the same as the "micalg" parameter's algorithm that is found
in the Disposition-Notification-Options header. When the
micalg parameter is not provided then the SHA-1 algorithm
SHOULD be used to calculate the MIC. 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 in order for the sender to verify non-
repudiation of receipt.
AS2-MDN field names ( e.g. "Disposition:", "Final-
Recipient:") are case-insensitive ( cf. RFC 2298, 3.1.1 ).
AS2-MDN action-modes, sending-modes, AS2-disposition-types,
and AS2-disposition-modifier values that 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, AS2-MDN-failure-description nor for the values
of any (optional) error, warning, or failure fields.
7.4.4 Additional AS2-MDN programming notes
1. 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.
2. Refer to RFC 2298 for the formatting of the MDN except
for the specific deviations mentioned above.
3. Refer to RFC 1892 and RFC 2298 for the formatting of the
content-type entity-headers for the MDN.
4. Use an action-mode of "automatic-action" when the
disposition described by the disposition type was a result
of an automatic action, rather than an explicit instruction
by the user for this message.
5. 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.
6. Use a sending-mode of "MDN-sent-automatically" when the
MDN is sent because the UA had previously been configured to
do so.
7. Use a sending-mode of "MDN-sent-manually" when the user
explicitly gave permission for this particular MDN to be
sent.
8. The sending-mode "MDN-sent-manually" is ONLY meaningful
with "manual-action", not with "automatic-action".
9. The "failed" disposition type MAY 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 would provide a brief overview of how
processed, error, failure, and warnings 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 to not 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.
Since 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 this specification does not restrict the use of the
"disposition-mode" to just 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
in the case where 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, so the EDI UA chooses not to
process the message contents itself, should be specified in
the MDN "disposition-field" as follows:
Disposition: "disposition-mode"; failed/Failure:
unsupported format
The "failed" AS2-disposition-type should 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 WILL
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 processing the received message other than
content, the "disposition-field" should be set to the
"processed" "disposition-type" value and the "error"
"disposition-modifier" value.
The "error" AS2-disposition-modifier with the "processed"
disposition-type should 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 pre-
defined description of a specific, well-known error. Further
information about the error may be contained in an error-
field.
For use in Internet EDI, the following "error" "disposition-
modifier" values are defined:
"Error: decryption-failed" - the receiver could not
decrypt the message contents.
"Error: authentication-failed" - the receiver could not
authenticate the sender.
"Error: integrity-check-failed" - the receiver could not
verify content integrity.
"Error: unexpected-processing-error" - a catch-all for
any additional processing errors.
An example of how the "disposition-field" would look
when other than content processing errors are detected is as
follows:
EXAMPLE
Disposition: "disposition-mode"; processed/Error:
decryption-failed
7.5.5 Processing warnings
Situations arise in EDI where 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'
SHOULD be set to the "processed" "disposition-type" value,
and the "warning" "disposition-modifier" value.
The "warning" AS2-disposition-modifier should 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 an warning-
field.
For use in Internet EDI, the following
"warning" "disposition-modifier" values are defined:
"Warning: authentication-failed, processing continued"
An example of how the "disposition-field" would look when
other than content processing warnings are detected is as
follows:
EXAMPLE
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing
continued
7.5.6 Backwards compatibility with disposition type,
modifier and extension
The following set of examples represent 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 represent allowable
constructions of the Disposition field that combine the
historic constructions above with optional RFC 2298 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 represent allowable
constructions of the Disposition field that employ pure RFC
2298 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 a 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 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 this may be discarded
by the client. 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 a MDN, the first part of the multipart/report (the "human-
readable" part) should include items such as the subject,
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, a 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.0 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 EDI trading partner ID and RFC 822 [11]
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, that they also exchange public key certificates
using the recommendations specified in the S/MIME Version 3
Message Specification. The message formats and S/MIME
conformance requirements for certificate exchange are
specified in this document.
In the long term, additional Internet-EDI standards may be
developed to simplify the process of establishing a trading
partnership, including the third party authentication of
trading partners, as well as attributes of the trading
relationship.
9.0 Security Considerations
This entire document is concerned with secure transport of
business to business data, and considers both privacy and
authentication issues.
Extracted from S/MIME Version 2 Message Specification: 40-
bit encryption is considered weak by most cryptographers.
Using weak cryptography offers little actual security over
sending plaintext. However, other features of S/MIME, such
as the specification of tripleDES or AES and the ability
to announce stronger cryptographic capabilities to parties
with whom you communicate, allow senders to create messages
that use strong encryption. Using weak cryptography is
never recommended unless the only alternative is no
cryptography. When feasible, sending and receiving agents
should inform senders and recipients the relative
cryptographic strength of messages.
Extracted from S/MIME Version 2 Certificate Handling: When
processing certificates, there are many situations where the
processing might fail. Because the processing may be done by
a user agent, a security gateway, or other program, there is
no single way to handle such failures. Just because the
methods to handle the failures has not been listed, however,
the reader should not assume that they are not important.
The opposite is true: if a certificate is not provably
valid and associated with the message, the processing
software should take immediate and noticeable steps to
inform the end user about it.
Some of the many places where signature and certificate
checking might fail include:
- no certificate chain leads to a trusted CA
- no ability to check the CRL for a certificate
- an invalid CRL was received
- the CRL being checked is expired
- the certificate is expired
- the certificate has been revoked
There are certainly other instances where a certificate may
be invalid, and it is the responsibility of the processing
software to check them all thoroughly, and to decide what to
do if the check fails.
The following certificate types MUST be supported.
With URL
Without URL
Self Certified
Certification Authority Certified
The URL, which matches the source server identity, SHOULD be
carried in the certificate. However, the receiver SHOULD NOT
expect that the certificate would contain a matching URL.
Since the certificates were exchanged with the establishing
of the trading partner relationship, the server identify may
be ignored.
The complete certification chain MUST be included in all
certificates. All certificate verifications MUST "chain to
root". Additionally, the certificate hash should match the
hash recomputed by the receiver.
10.0 Acknowledgements
Carl Hage, Karen Rosenfeld, Chuck Fenton and many others
have provided valuable suggestions improving this
applicability statement. The authors would also like to
thank the vendors who participated in the Drummond Group Inc
AS2 interoperability testing. Their contributions led to
great improvement in the clarity of this document.
11.0 References
[1] N. Borenstein, N.Freed, "Multipurpose Internet Mail
Extensions (MIME)
Part One: Format of Internet Message Bodies", RFC
2045,
December 02, 1996.
N. Borenstein, N.Freed, "Multipurpose Internet Mail
Extensions (MIME)
Part Two: Media Types", RFC 2046, December 02, 1996.
N. Borenstein, N.Freed, "Multipurpose Internet Mail
Extensions (MIME)
Part Five: Conformance Criteria and Examples", RFC
2049 ,
December 02, 1996.
[2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC
1767, March 2, 1995.
[3] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-
Lee, "Hypertext Transfer Protocol--HTTP/1.1", RFC 2616,
March 1997.
[4] T. Harding, R. Drummond, C. Shih, "Peer-to-Peer MIME-
based Secure Business Data Interchange", RFC 3335, September
2002.
[5] R. Fajman, "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security
Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, Oct. 3, 1995
[7] J. Postel, "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1, 1982.
[8] B. Ramsdell, "S/MIME Version 3 Message Specification;
Cryptographic Message Syntax", RFC 2633 RFC 2630, June 1999.
[9] G. Vaudreuil, "The Multipart/Report Content Type for
the Reporting of Mail System Administrative Messages", RFC
1892, March 15, 1996.
[10] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC
2246, March 1999.
[11] D. Crocker, "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 13, 1982.
[12] E. Whitehead, M. Murata, "XML Media Types", RFC 2376,
July 1998.
12.0 Authors' Addresses
Dale Moberg
dmoberg@cyclonecommerce.com
Cyclone Commerce
8388 E. Hartford Drive, Suite 100
Scottsdale, AZ 85255 USA
Dick Brooks
dick.brooks@systrends.com
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284 USA
Rik Drummond
Rvd2@drummondgroup.com
Drummond Group Inc.
4700 Bryant Irvin Court
Fort Worth, TX 76107 USA
Appendices
A. Message Examples
NOTE: All examples are provided as an illustration only, and
are not considered part of the protocol specification. If an
example conflicts with the protocol definitions specified
above or in the other referenced RFC's, the example is
wrong.
A.1 Signed message requesting a signed, synchronous receipt
POST /invoke/wm.EDIINT/receive HTTP/1.0
Host: 208.234.160.12:80
User-Agent: AS2 Company Server
Date: Wed, 31 Jul 2002 13:34:50 GMT
From: mrAS2@as2.com
AS2-Version: 1.1
AS2-From: "\" as2Name \""
AS2-To: 0123456780000
Subject: G1 Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: mrAS2@as2.com
Disposition-Notification-Options: signed-receipt-
protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 2464
--as2BouNdary1as2
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
--as2BouNdary1as2
Content-Type: application/pkcs7-signature
[omitted binary pkcs7 signature data]
--as2BouNdary1as2--
A.2 MDN for Message A.1 Above
HTTP/1.0 200 OK
Set-Cookie: ssnid=35MdRcIFhez60mO6UDq+JDMWoumBQ=666612;
path=/;
AS2-From: 0123456780000
AS2-To: "\" as2Name \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
Content-Length: 1980
------=_Part_57_648441049.1028122454671
& Content-Type: multipart/report; Report-Type=disposition-
notification;
& boundary="----=_Part_56_1672293592.1028122454656"
&
&------=_Part_56_1672293592.1028122454656
&Content-Type: text/plain
&Content-Transfer-Encoding: 7bit
&
&MDN for -
& Message ID: <200207310834482A70BF63@\"~~foo~~\">
& From: "\" as2Name \""
& To: "0123456780000"
& Received on: 2002-07-31 at 09:34:14 (EDT)
& Status: processed
& Comment: This is not a guarantee that the message has
been completely processed or &understood by the receiving
translator
&
&------=_Part_56_1672293592.1028122454656
&Content-Type: message/disposition-notification
&Content-Transfer-Encoding: 7bit
&
&Reporting-UA: AS2 Server
&Original-Recipient: rfc822; 0123456780000
&Final-Recipient: rfc822; 0123456780000
&Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\">
&Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
&Disposition: automatic-action/MDN-sent-automatically;
processed
&
&------=_Part_56_1672293592.1028122454656--
------=_Part_57_648441049.1028122454671
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ
cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA
------=_Part_57_648441049.1028122454671--
Notes:
1. The lines proceeded with "&" is what the signature is
calculated over.
2. For details on how to prepare the multipart/signed with
protocol = "application/pkcs7-signature" see the "S/MIME
Message Specification, PKCS Security Services for MIME".)
3. Note that the textual first body part of the
multipart/report can be used to include a more detailed
explanation of the error conditions reported by the
disposition headers. The first body part of the
multipart/report when used in this way, allows a person to
better diagnose a problem in detail.
4. As specified by RFC 1892 [9], returning the original or
portions of the original message in the third body part of
the multipart/report is not required. This is an optional
body part. However, it is RECOMMENDED that this body part be
omitted or left blank.
A.3 Signed, encrypted message requesting a signed,
asynchronous receipt
Message-ID: <#as2_company#01#a4260as2_companyout#>
Date: Thu, 19 Dec 2002 15:04:18 GMT
From: me@as2.com
Subject: async MDN request
Mime-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=enveloped-
data; name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7m
Recipient-Address: 10.240.1.2//
Disposition-Notification-To:
http://10.240.1.2:8201/exchange/as2_company
Disposition-Notification-Options: signed-receipt-
protocol=optional, pkcs7-signature; signed-receipt-
micalg=optional, sha1
Receipt-Delivery-Option:
http://10.240.1.2:8201/exchange/as2_company
AS2-From: as2_company
AS2-To: "AS2 Test"
AS2-Version: 1.1
Host: 10.240.1.2:8101
Connection: close
Content-Length: 3428
[omitted binary encrypted data]
A.4 Asynchronous MDN for Message A.3 Above
POST /exchange/as2_company HTTP/1.1
Host: 10.240.1.2:8201
Connection: close, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
Date: Thu, 19 Dec 2002 15:03:38 GMT
Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
AS2-Version: 1.1
Mime-Version: 1.0
Recipient-Address:
http://10.240.1.2:8201/exchange/as2_company
AS2-To: as2_company
AS2-From: "AS2 Test"
Subject: Your Requested MDN Response
From: as2debug@as2.com
Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature"; boundary="----
=_Part_337_6452266.1040310218750"
Content-Length: 3103
------=_Part_337_6452266.1040310218750
Content-Type: multipart/report; report-type=disposition-
notification;
boundary="----=_Part_336_6069110.1040310218718"
------=_Part_336_6069110.1040310218718
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The message <x12.edi> sent to Recipient <AS2 Test>
on Thu, 19 Dec 2002 15:04:18 GMT with Subject <async MDN
request>
has been received, the EDI Interchange was successfully
decrypted
and its integrity was verified. In addition, the sender of
the message,
Sender <as2_company> at Location
<http://10.240.1.2:8201/exchange/as2_company>
was authenticated as the originator of the message.
There is no guarantee however that the EDI interchange was
syntactically
correct, or was received by the EDI application/translator.
------=_Part_336_6069110.1040310218718
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit
Reporting-UA: AS2@test:8101
Original-Recipient: rfc822; "AS2 Test"
Final-Recipient: rfc822; "AS2 Test"
Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
Disposition: automatic-action/MDN-sent-automatically;
processed
Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1
------=_Part_336_6069110.1040310218718--
------=_Part_337_6452266.1040310218750
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=
------=_Part_337_6452266.1040310218750-
B. IANA Registration Form
A.1 IANA registration of the signed-receipt-protocol content
disposition parameter
Parameter-name: signed-receipt-protocol
Syntax: See section 7.3 of this document
Specification: See section 7.3 of this document
A.2 IANA registration of the signed-receipt-micalg content
disposition parameter
Parameter-name: signed-receipt-micalg
Syntax: See section 7.3 of this document
Specification: See section 7.3 of this document
A.3 IANA registration of the Received-content-MIC MDN
extension
field name
Extension field name: Received-content-MIC
Syntax: See section 7.4.3 of this document
Specification: See section 7.4.3 of this document
Datatracker
Report a datatracker bug
draft-ietf-ediint-as2-13
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4130.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |