EDIINT Working Group Terry Harding
Internet draft Richard Scott
Expires: October 2003
March 2003
FTP Transport for Secure Peer-to-Peer
Business Data Interchange over the Internet
draft-ietf-ediint-as3-00.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.
Abstract
This document describes how to exchange structured business data
securely using FTP 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#3" 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 959 File Transfer Protocol
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. FTP Considerations
5.1 Sending EDI in FTP 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 FTP Response Status Codes
5.5 FTP Error Recovery
6. AS2 Headers
6.1 AS3 Version Header
6.2 AS3 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 AS3-MDN General Formats
7.4.2 AS3-MDN Construction
7.4.3 AS3-MDN Fields
7.4.4 Additional AS3-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 FTP Post
8. Public key certificate handling
9. Security Considerations
10. Acknowledgements
11. References
12. Authors' Addresses
Appendix
A. Message Examples
B. IANA Registration Form
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, data integrity, authenticity, non-repudiation of origin and
non-repudiation of receipt over FTP. 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 959 File 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 FTP upload operation is used to send appropriately packaged EDI,
XML, or other business data. The receiving application will poll
the ftp server for inbound messages, unpackage and handle the message
data and to generate a reply for the originator that contains a
message disposition acknowledgement within a multipart/report that is
signed or unsigned. This request/reply transactional interchange
provides secure, reliable, and authenticated transport for EDI or
other business data using FTP. 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.
Signed Receipt A receipt with a digital signature.
Asynchronous Receipt A receipt returned to the sender on a
different communication session than the
sender's original message session.
Message Disposition The Internet messaging format used to convey a
Notification (MDN) receipt. This term is used interchangeably with
receipt. A MDN is a receipt.
Non-repudiation of NRR is a "legal event" that occurs when the
receipt (NRR) 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 AS3.
MD5 A secure, one-way hash algorithm used in
conjunction with digital signature. This
algorithm is accepted in AS3 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
AS3 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 FTP 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 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 receipt is used if the acknowledgment is for
an interchange resulting in a receipt which is NOT signed. The term
signed receipt 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 the recipient of the message. Note that NRR is not possible
without signatures.
For information on how to format and process receipts in AS3, 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.
- Security Formatting
This specification relies on the guidelines set forth in
RFC 2633/2630 [8] "S/MIME Version 3 Message Specification;
Cryptographic Message Syntax". S/MIME as defined in this
Applicability statement.
- Hash function, message digest choices
When a signature is used, it is RECOMMENDED that the SHA1 hash
algorithm be used for all outgoing messages, and that both MD5
and SHA1 be supported for incoming messages.
- Permutation Summary
In summary, the following twelve security permutations are possible
in any given trading relationship:
1. Sender sends un-encrypted data, does NOT request a receipt.
2. Sender sends un-encrypted data, requests an unsigned receipt.
The receiver sends back the unsigned receipt.
3. Sender sends un-encrypted data, requests a signed receipt. The
receiver sends back the signed receipt.
4. Sender sends encrypted data, does NOT request a receipt.
5. Sender sends encrypted data, requests an unsigned receipt. The
receiver sends back the unsigned receipt.
6. Sender sends encrypted data, requests a signed. The receiver
sends back the signed receipt.
7. Sender sends signed data, does NOT request a 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
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.
3. Referenced RFC's and their contribution
3.1 RFC 959 File Transfer Protocol [3]
This document specifies how data is transferred using FTP.
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. Structure of an AS3 message
4.1 Introduction
The basic structure of AS3 messages consists of MIME format inside an
SMTP message with a few additional specific AS3 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 AS3 implementations and RFCs are
mentioned specifically in the sections below.
4.2 Structure of an Internet EDI MIME message
No encryption, no signature
-RFC822/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
No encryption, signature
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC2633 (application/pkcs7-signature)
Encryption, no signature
-RFC822/2045
-RFC2633 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
Encryption, signature
-RFC822/2045
-RFC2633 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC2633 (application/pkcs7-signature)(encrypted)
MDN, no signature
-RFC822/2045
-RFC2298 (message/disposition-notification)
MDN, signature
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC2298 (message/disposition-notification)
-RFC2633 (application/pkcs7-signature)
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. FTP Considerations
5.1 FTP Security Requirements
FTP has long been viewed as an insecure protocol primarily because of its
use of clear text authentication [FTP]. This is addressed by RFC 2228, and
the use of one of the security mechanisms described therein is strongly
encouraged. Specifically, conforming implementations of AS3 SHALL employ
FTP client/servers that support the AUTH command described within [SFTP].
While any authentication mechanism based upon [SFTP] MAY be utilized, AUTH
TLS (as described in [MURRAY]) MUST be supported.
5.2 MIME Considerations for FTP
5.2.1 Required/Optional Headers
An AS3 message MUST contain the following outer headers:
To
From
Date
Message-ID
Content-Type
An AS3 message OPTIONALLY MAY contain the following outer headers:
Subject
Content-Length
AS3-Version (assumed to be 1.0 if not present)
An AS3 message requesting a receipt MUST contain a
Disposition-Notification-To header and MAY contain a
Disposition-Notification-Options header (if the receipt is to be signed.)
Additional headers SHOULD NOT be used.
5.2.2 Content-Transfer-Encoding not used in FTP transport
FTP defines several data structures and character encodings via the
STRU[cture] and TYPE commands. AS3 requires the file-structure (default)
and the binary type. The Content-Transfer-Encoding header SHOULD NOT be
used; if the header is present, it MUST have a value of binary or 8-bit,
and the absence of this header MUST NOT result in transaction failure.
Content transfer encoding of MIME parts within the AS3 message are
similarly constrained.
5.2.3 Epilogue must be empty
A MIME message containing an epilogue [MIME] SHALL NOT be used.
5.3 Large file transfers
Large files are handled correctly by the TCP layer. However, there is a
mechanism for compressing data described in [EDIINT-COMPRESSION] which
efficiently reduces transmission requirements for many data types
(including both XML and traditional EDI data.)
5.3.1 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.2 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.4 FTP Error Recovery
to be completed
6. Additional AS3 Specific FTP Headers
The following headers are to be included in all AS3 messages and all
AS3 MDNs.
6.1 AS3 Version Header
To promote backward compatibility with future AS3 implementations.
AS3-Version: 1.0
- is used in all implementations implementing this specification.
6.2 AS3 System Identifiers
To aid the receiving system in identifying the sending system,
AS3-From and AS3-To headers are used.
AS3-From: < AS3-name >
AS3-To: < AS3-name >
These AS3 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.
AS3-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS3-qtext = AS3-text / SP ; allow space only in quoted text
AS3-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS3-quoted-name = DQUOTE 1*128( AS3-qtext /
AS3-quoted-pair) DQUOTE
AS3-atomic-name = 1*128AS2-text
AS3-name = AS3-atomic-name / AS3-quoted-name
The AS3-From header value and the AS3-To header value MUST each be an
AS3-name, MUST each be comprised of 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 AS3-quoted-name SHOULD be used only if the AS3-name does not
conform to AS3-atomic-name.
The AS3-To and AS3-From header fields MUST be present in all AS3
messages and AS3 MDN's.
The sending system may choose to limit the possible AS3-To/AS3-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.
If either the AS3-From or the AS3-To or the combination of both header
values is determined to be invalid or unknown by the receiving system,
the receiving system MAY respond with an unsigned MDN with an
explanation of the error, if the sending system requested an MDN, but
is not restricted to this option.
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.
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 provide 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 Asynchronous MDNs
The asynchronous AS3-MDNs are returned on a separate FTP TCP/IP
connection and are a response to an AS3 message.
The following diagram illustrates the asynchronous delivery of an
AS3-MDN delivery:
Asynchronous AS3-MDN
[S] ----( connect )----> [R] [FTP Server]
[S] ----( send )-------> [R] [AS3-Message]
[S] ----( disconnect )-> [R] [FTP Server]
[S] <---( connect )----- [R] [FTP Server]
[S] <---( send )-------- [R] [AS3-MDN]]
[S] <---( disconnect )-- [R] [FTP Server]
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" ":" ftp-url
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 FTP and
retaining as much as possible from the [4] functionality, the
ftp-url must be present.
The ftp-url field is specified as an RFC 1738
<URL:ftp://host.com:port/url-path>, and while it MUST be present,
it may be ignored if the ftp-url points to an unknown location. If the
ftp-url points to an unknown location it is RECOMMENDED that the mdn is
returned back to a known ftp-url for the sender of the received message.
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. 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 "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: // Requests the MDN
ftp://host:port/inbox // Location to return MDN
Disposition-notification-options: // The signing options for MDN
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
Disposition-notification-options syntax:
Disposition-notification-options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
where
disposition-notification-parameters =
parameter *(";" parameter)
where
parameter = attribute "=" importance ", " 1#value"
where
importance = "required" | "optional"
So the Disposition-notification-options string could be:
signed-receipt-protocol=optional, <protocol symbol>;
signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
The currently supported value for <protocol symbol> is "pkcs7-signature"
for the S/MIME detached signature format.
The currently supported values for MIC algorithm <micalg> values are:
Algorithm Value
Used
-------- -------
MD5 md5
SHA-1 sha1
Receiving agents SHOULD be able to recover gracefully from a <micalg>
parameter value that they do not recognize.
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.
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 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 AS3 Message Disposition
Notification (AS3-MDN).
7.4.1 AS3-MDN General Formats
The AS3-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. Refer to RFC 2045 for format of MIME-message-headers.
The format of the AS3-MDN is
AS3-MDN = *(( MIME-message-headers | entity-headers )CRLF)
CRLF
AS3-MDN-body
AS3-MDN-body =
AS3-signed-MDN-body | AS3-unsigned-MDN-body
7.4.2 AS3-MDN Construction
The AS3-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 AS3-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 AS3-MDN is signed, the transfer-layer ( "outermost" )
entity-headers of the AS3-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
AS3-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS3-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS3-received-content-MIC-field CRLF ]
7.4.3 AS3-MDN Fields
The rules for constructing the AS3-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 AS3-disposition-field and that the
AS3-received-content-MIC field has been added. The differences
between the RFC 2298 disposition-field and the
AS3-disposition-field are described below. Where
there are differences between this document and RFC 2298, those
entity names have been changed by prepending "AS3-". Entities below
that do not differ from RFC 2298 are not necessarily further
defined in this document.
Refer to RFC 2298 for AS3-MDN entities that are not further defined
in this document.
AS3-disposition-field = "Disposition" ":" disposition-mode ";"
AS3-disposition-type [ '/' AS3-disposition-modifier ]
disposition-mode = action-mode "/" sending-mode
action-mode = "manual-action" | "automatic-action"
sending-mode = "MDN-sent-manually" | "MDN-sent-automatically"
AS3-disposition-type = "processed" | "failed"
AS3-disposition-modifier = ( "error" | "warning" ) |
AS3-disposition-modifier-extension
AS3-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: " AS3-MDN-warning-description |
"failure: " AS3-MDN-failure-description
AS3-MDN-warning-description = *( TEXT )
AS3-MDN-failure-description = *( TEXT )
AS3-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. 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 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.
AS3-MDN field names ( e.g. "Disposition:", "Final-Recipient:")
are case-insensitive ( cf. RFC 2298, 3.1.1 ).
AS3-MDN action-modes, sending-modes, AS2-disposition-types, and
AS3-disposition-modifier values that are defined above, and
user-supplied *( TEXT ) values are also case-insensitive. AS3
implementations MUST NOT make assumptions regarding the values
supplied for AS3-MDN-warning-description,
AS3-MDN-failure-description nor for the values of any (optional)
error, warning, or failure fields.
7.4.4 Additional AS3-MDN Programming Notes
1. Unlike SMTP, for FTP transactions, Original-Recipient and
Final Recipient should not be different. The value in
Original-Message-ID MUST match the original Message-ID
header value.
2. Refer to RFC 1892 and RFC 2298 for the formatting of the
content-type entity-headers for the MDN.
3. 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.
4. 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.
5. Use a sending-mode of "MDN-sent-automatically" when the MDN is
sent because the UA had previously been configured to do so.
6. Use a sending-mode of "MDN-sent-manually" when the user
explicitly gave permission for this particular MDN to be sent.
7. The sending-mode "MDN-sent-manually" is ONLY meaningful with
"manual-action", not with "automatic-action".
8. 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 will 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.
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" AS3-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:" AS3-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" AS3-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:" AS3-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" AS3-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:" AS3-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
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 ftp 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 zzzzzzzzzzzzzzzztrue: 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 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
To be completed.
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] J. Postel, J. Reynolds,
"FILE TRANSFER PROTOCOL (FTP)", RFC 959, October 1985.
[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.zz
[6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts
for MIME:
Multipart/Signed and Multipart/Encryptezd", RFC 1847, Oct. 3, 1995
[7] J. Postel, "Simple Mail Transfer Protocozl", STD 10, RFC 821,
August 1, 1982.zzzzzzzzzzzz
[8] B. Ramsdell, "S/MIME Version 3 Message Specification;
Cryptographic Message Syntazx", RFC 2633 RFC 2630, June 1999.
[9] G. Vaudreuil, "The Multipart/Report Content Type for the
Reporting of Mail System Adminzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzistzrative 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
Terry Harding
tharding@cyclonecommerce.com
Cyclone Commerce
8388 E. Hartford Drive, Suite 100
Scottsdale, AZ 85255 USA
Richard Scott
rscott@cyclonecommerce.com
Cyclone Commerce
8388 E. Hartford Drive, Suite 100
Scottsdale, AZ 85255 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 receipt
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-Version: 1.0
AS3-From: cyclone
AS3-To: "trading partner"
Message-Id: <200207310834482A70BF63@host.com>
Disposition-Notification-To: ftp://host:port/mdnbox
Disposition-Notification-Options: signed-receipt-
protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as3BouNdary1as3";
protocol="application/pkcs7-signature"; micalg=sha1
--as3BouNdary1as3
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
--as3BouNdary1as3
Content-Type: application/pkcs7-signature
[omitted binary pkcs7 signature data]
--as3BouNdary1as3--
A.2 MDN for Message A.1 Above
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-From: "trading partner"
AS3-To: cyclone
AS3-Version: 1.0
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
------=_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@host.com>
& From: cyclone
& To: "trading partner"
& 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: AS3 Server
& Original-Recipient: rfc822; "trading partner"
& Final-Recipient: rfc822; "trading partner"
& Original-Message-ID: <200207310834482A70BF63@host.com>
& 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.
B. IANA Registration Form
A.1 IANA registration of the signed-receipt-protocol content
disposition parameter
Parameter-name: signed-receipt-protocol
Syntax: See section 7.3 of this document
Specification: See section 7.3 of this document
A.2 IANA registration of the signed-receipt-micalg content
disposition parameter
Parameter-name: signed-receipt-micalg
Syntax: See section 7.3 of this document
Specification: See section 7.3 of this document
A.3 IANA registration of the Received-content-MIC MDN extension
field name
Extension field name: Received-content-MIC
Syntax: See section 7.4.3 of this document
Specification: See section 7.4.3 of this document.
Datatracker
Report a datatracker bug
draft-ietf-ediint-as3-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4823.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |