EDIINT Working Group

Dale Moberg

Internet draft

Rik Drummond

Expires: August 2004





February 2004



               MIME-based Secure Peer-to-Peer

         Business Data Interchange over the Internet

                         Using HTTP



                             AS2



              draft-ietf-ediint-as2-15.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 AS4.



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 SHA-1

hash algorithm be used for all outgoing messages, and that

both MD5 and SHA-1 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.



A signed payload is contained within two parts of multipart

structure. The first part is the document itself and the

second part the pkcs-7 signature. Encryption, when present,

always occurs after applying the signature.



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

                          application/xml)(encrypted)



Encryption, signature

   -RFC2616/2045

     -RFC2633 (application/pkcs7-mime)

       -RFC1847 (multipart/signed)(encrypted)

         -RFC1767/RFC2376  (application/EDIxxxx or

                            application/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.



HTTPS refers to the use of HTTP over TLS [13]. Usually only

a multipart/signed message body would be sent using TLS, as

encrypted message bodies would be redundant. However,

encrypted message bodies are not prohibited.



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. While TCP-based

communication sets no intrinsic limit on size of files

transferred,[3] sections 3.5 and 3.6 discuss some options

for compressing or chunking entities to be transferred.



5.3 Modification of MIME or other headers or parameters used



5.3.1 Content-Length



The use of the content-length header must follow the

guidelines of [3], specifically sections 4.4 and 14.13.



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, 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 for the MDN

          signed-receipt-protocol=optional, pkcs7-signature;

          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  ed 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.

Canonicalization will insure header lines are terminated

by CRLF and use a CRLF as a separator between the headers

and the body.



- 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.



For signed messages, the algorith used to calculate the

MIC MUST be the same as the algorithm that was used on the

message that was signed. If the message is not signed, then

the SHA-1 algorithm should be used. This field is set only

when the contents of the message are processed successfully.

This field is used in conjunction with the recipient's

signature on the MDN 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]  M. Murata, S. St.Laurent, "XML Media Types", RFC 3023,

January 2001.



[13] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000





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