EDIINT Working Group Dale Moberg
Internet draft Rik Drummond
Expires: July 2003
January 2003
HTTP Transport for Secure Peer-to-Peer
Business Data Interchange over the Internet
draft-ietf-ediint-as2-12.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 clumbersom and greatly contributed to the lack of
clarity. This draft extends the AS1 functionality to HTTP, drops PGP and gib??
In the event that gib?? is still required as and ietf standard i recommend
we do it as AS3.
Moberg, Drummond, [page 1]
HTTP Transport for Secure EDI Jan 2003
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 repliesto 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. Introduction
2. Overview
2.1 Overall operations
2.2 Purpose of a security guideline for MIME EDI
2.3 Definitions
2.4 Assumptions
2.4.1 EDI process assumptions
2.4.2 Flexibility assumptions
3. Referenced RFCs
3.1 RFC 2616 HTTP v1.1
Moberg, Drummond, [page 2]
HTTP Transport for Secure EDI Jan 2003
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. Structure of an AS2 message
4.1 Introduction
4.2 Structure of EDI MIME message
5. 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
5.2.2 Epilogue must be empty
5.2.3 Lengthy 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. AS2 Headers
6.1 AS2 Version Header
6.2 AS2 System Identifiers
7. 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. Public key certificate handling
9. Security Considerations
10. Acknowledgements
11. References
12. Authors' Addresses
Appendix
A. Message Examples
B. IANA Registration Form
Moberg, Drummond [page 3]
HTTP Transport for Secure EDI Jan 2003
1. 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,
dataintegrity/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. 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 using 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
Moberg, Drummond, [page 4]
HTTP Transport for Secure EDI Jan 2003
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.
* 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.
Moberg, Drummond, [page 5]
HTTP Transport for Secure EDI Jan 2003
* -The receiving organization then returns a signed receipt, as
requested either synchronous or asynchronous, 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
Moberg, Drummond, [page 6]
HTTP Transport for Secure EDI Jan 2003
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 utgoing 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. 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.
Moberg, Drummond, [page 7]
HTTP Transport for Secure EDI Jan 2003
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. 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).
Moberg, Drummond, [page 8]
HTTP Transport for Secure EDI Jan 2003
4. 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
Moberg, Drummond, [page 9]
HTTP Transport for Secure EDI Jan 2003
Content-Type: application/edi-consent
Content-Type: application/XML
5. 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], 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 Epilogue must be empty
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, closing a connection cannot be used
to indicate the end of an entity. Therefore, [3] sections 4.4 and 14.14
indicate the need for a Content-Length entity header in a request is a
MUST. The only exception to this for AS2 messages is when a one-line,
successful, HTTP response is provided.
5.3.2 Final 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
Moberg, Drummond, [page 10]
HTTP Transport for Secure EDI Jan 2003
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. 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 over SMTP [4] and single line
HTTP 1.1 responses (section 5.5).
6.1 AS2 Version Header
Moberg, Drummond, [page 11]
HTTP Transport for Secure EDI Jan 2003
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 implementation 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.
Moberg, Drummond, [page 12]
HTTP Transport for Secure EDI Jan 2003
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.
If either the AS2-From or the AS2-To or the combination of both header values is
determined to be invalid or unknown by the receiving system, the receiving system
MAY respond in one of the following ways, but is not limited to these options:
1. The receiving AS2 system MAY disconnect from the sending AS2 system
before completing the reception of the entire entity if it determines the HTTP
headers do not represent a valid trading-relationship.
2. The receiving AS2 system MAY return an HTTP response with a response
code in the 2xx range, with or without any explanation of the error, even if
the sending system requested an MDN.
3. The receiving AS2 system MAY return an unsigned MDN with an
explanation of the error, if the sending system requested an MDN.
7. 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
Moberg, Drummond, [page 13]
HTTP Transport for Secure EDI Jan 2003
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.
Moberg, Drummond, [page 14]
HTTP Transport for Secure EDI Jan 2003
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
Moberg, Drummond, [page 15]
HTTP Transport for Secure EDI Jan 2003
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
Moberg, Drummond, [page 16]
HTTP Transport for Secure EDI Jan 2003
SHA-1 sha1
Receiving agents SHOULD be able to recover gracefully from a <micalg> parameter
value that they
do not recognize.
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.
Moberg, Drummond, [page 17]
HTTP Transport for Secure EDI Jan 2003
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 MIME header and content.
Canonicalization as specified in RFC 1848 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 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 prior to Content-Tranfer-Encoding and 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
Moberg, Drummond, [page 18]
HTTP Transport for Secure EDI Jan 2003
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
Moberg, Drummond, [page 19]
HTTP Transport for Secure EDI Jan 2003
names have been changed by prepending "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" value used by the sender in the multipart/signed message. When no
signature is received, or the micalg parameter is not provided then the SHA-1
algorithm SHOULD be used to calculate the MIC. This field is set only when
Moberg, Drummond, [page 20]
HTTP Transport for Secure EDI Jan 2003
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 a user's, administrator's, or under software
control.
Moberg, Drummond, [page 21]
HTTP Transport for Secure EDI Jan 2003
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
Moberg, Drummond, [page 22]
HTTP Transport for Secure EDI Jan 2003
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:
Moberg, Drummond, [page 23]
HTTP Transport for Secure EDI Jan 2003
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.
When a Disposition-Notification-To extension header is present in the POST
request entity headers, then entity headers for the MDN should be included.
The content type for the MDN receipt (multipart/report [9] or multipart/signed
[6]) should be included in the Response entity headers.
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.
If the "To" field is missing, for signed messages, the value for Original-recipient
may be the email address field from the signer's X.509 attribute for email
addresses, if that value is available. For a MDN, an application must
report the Message-ID of the request. The human readable part (the first part
of the multipart/report) should include items such as the subject, date and other
information when those fields are present in entity header fields following
the POST request. The HTTP reply should normally omit the third optional
part of the multipart/report (used to return the original message or its headers in
Moberg, Drummond, [page 24]
HTTP Transport for Secure EDI Jan 2003
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 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. 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
Moberg, Drummond, [page 25]
HTTP Transport for Secure EDI Jan 2003
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. 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. 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. 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
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
Moberg, Drummond, [page 26]
HTTP Transport for Secure EDI Jan 2003
[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--
Moberg, Drummond, [page 27]
HTTP Transport for Secure EDI Jan 2003
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
A.4 Asynchronous MDN for Message A.3 Above
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
Moberg, Drummond, [page 28]
HTTP Transport for Secure EDI Jan 2003
