EDIINT Working Group T. Harding
Internet draft Cyclone Software
Expires: Mar / 2000 R. Drummond
Drummond Group
Chuck Shih
Gartner Group
September, 1999
MIME-based Secure EDI
draft-ietf-ediint-as1-11.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 obsoleted 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 (1998). All rights reserved.
Abstract
This document describes how to securely exchange EDI and other
business related documents using MIME and public key
cryptography.
Harding, Shih, Drummond [Page 1]
MIME-based Secure EDI September 1999
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.
Feedback Instructions:
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#1" 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
Security Considerations 3
1.0 Introduction 3
2.0 Overview 4
2.1 Purpose of a security guideline for MIME EDI 4
2.2 Definitions 4
2.2.1. Terms 4
2.2.2 The secure transmission loop 5
2.2.3 Definition of receipts 5
2.3 Assumptions 6
2.3.1 EDI process assumptions 6
2.3.2 Flexibility assumptions 7
3.0 Referenced RFCs and their contribution 8
3.1 RFC 821 SMTP [7] 8
3.2 RFC 822 Text Message Format [3] 8
3.3 RFC 1847 MIME Security Multiparts [6] 9
3.4 RFC 1892 Multipart/report [10] 9
3.5 RFC 1767 EDI Content [2] 9
3.6 RFC 2015 PGP/MIME [4] 9
3.7 RFC 2045, 2046, and 2049 MIME [1] 9
3.8 RFC 2298 Message Disposition Notification [5] 9
3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 9
4.0 Structure of an EDI MIME message - Applicability 10
4.1 Introduction 10
4.2 Structure of an EDI MIME message - PGP/MIME 10
4.2.1 No encryption, no signature 10
Harding, Shih, Drummond [Page 2]
MIME-based Secure EDI September 1999
4.2.2 No encryption, signature 10
4.2.3 Encryption, no signature 10
4.2.4 Encryption, signature 10
4.3 Structure of an EDI MIME message - S/MIME 11
4.3.1 No encryption, no signature 11
4.3.2 No encryption, signature 11
4.3.3 Encryption, no signature 11
4.3.4 Encryption, signature 11
5.0 Receipts 11
5.1 Introduction 11
5.2 Requesting a signed receipt 14
5.2.1 Additional Signed Receipt Considerations 16
5.3 Message Disposition Notification Format 17
5.3.1 Message Disposition Notification Extensions 18
5.3.2 Disposition Mode, Type, and Modifier Use 19
5.4 Message Disposition Notification Processing 21
5.4.1 Large File Processing 21
5.4.2 Example 23
6.0 Public key certificate handling 25
6.1 Near term approach 25
6.2 Long term approach 25
7.0 Acknowledgments 25
8.0 References 26
9.0 Authors' Addresses 27
Security Considerations
This document discusses the mechanisms, requirements and
Technologies necessary to conduct secure EDI over Internet using
either PGP/MIME or S/MIME. It further discusses the
implementation of encryption, digital signature, integrity and
signed-receipt for MIME objects transported over SMTP, HTTP or
FTP.
1.0 Introduction
Previous work on Internet EDI focused on specifying MIME content
Types for EDI data ([2] RFC 1767). This Applicability Statement
expands on RFC 1767 to specify use of a comprehensive set of data
security features, specifically data privacy, data
integrity/authenticity, non-repudiation of origin and non-
repudiation of receipt. This draft recognizes contemporary RFCs
and Internet drafts and is attempting to "re-invent" as little as
possible.
With an enhancement in the area of "receipts", as described below
(3.1.8), secure Internet MIME based EDI can be accomplished by
using and complying with the following RFCs:
Harding, Shih, Drummond [Page 3]
MIME-based Secure EDI September 1999
-RFC 821 SMTP
-RFC 822 Text Message Formats
-RFC 1767 EDI Content Type
-RFC 1847 Security Multiparts for MIME
-RFC 1892 Multipart/Report
-RFC 2015 MIME/PGP
-RFC 2045 to 2049 MIME RFCs
-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 Applicability Statement.
2.0 Overview
2.1 Purpose of a security guideline for MIME EDI
The purpose of these specifications is to ensure interoperability
between EDI user agents, invoking some or all of the commonly
expected security features. This standard 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.2 Definitions
2.2.1. Terms
EDI Electronic Data Interchange
EC Electronic Commerce
Receipt The functional message that is sent from a
receiver to a sender to acknowledge
receipt of an EDI/EC interchange.
Signed Receipt Same as above, but with a digital
signature.
Message Disposition The Internet messaging format used to
Notification convey a receipt. This term is used
interchangeably with receipt. A signed
MDN is a signed receipt.
Non-repudiation of NRR is a "legal event" that occurs when
Receipt (NRR) 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.
Harding, Shih, Drummond [Page 4]
MIME-based Secure EDI September 1999
PGP/MIME Digital envelope security based on the
Pretty Good Privacy (PGP) standard
(Zimmerman), integrated with MIME Security
Multiparts [6].
S/MIME A format and protocol for adding
Cryptographic signature and/or encryption
services to Internet MIME messages.
2.2.2 The secure transmission loop
The functional requirements document, [9] "Requirements for
Inter-operable Internet EDI" (can be found at www.ietf.org),
Provides extensive information on EDI security and the
user/business related processes surrounding the need for and use
of EDI security. In this document, it is assumed that the reader
is familiar with the requirements document.
This document's focus is on the formats and protocols for
Exchanging EDI content that has had security applied to it using
the Internet's messaging transport.
The "secure transmission loop" for EDI involves one organization
sending a signed and encrypted EDI 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 either PGP/MIME or 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 to
the sending organization in the form of a message disposition
notification message. 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, would
Satisfy all security requirements. This specification, however,
leaves full flexibility for users to decide the degree to which
they want to deploy those security features with their EDI
Harding, Shih, Drummond [Page 5]
MIME-based Secure EDI September 1999
trading partners.
2.2.3 Definition of receipts
The term used for both the functional activity and message for
acknowledging receipt of an EDI/EC interchange is receipt, or
signed receipt. The first 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.
The "rule" is:
- If a receipt is requested, explicitly specifying that the
receipt be signed, then the receipt MUST be returned with a
signature.
- If a receipt is requested, explicitly specifying that the
receipt be signed, but the recipient cannot support the
requested protocol format or requested MIC algorithms, then a
receipt, either signed or unsigned SHOULD be returned.
- If a signature is not explicitly requested, or if the signed
receipt request parameter is not recognized by the UA, a
receipt may or may not be returned. This behavior is
consistent with the MDN RFC 2298.
A term often used in combination with receipts is "Non-
Repudiation of Receipt (NRR). 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.
2.3 Assumptions
2.3.1 EDI process assumptions
-Encrypted object is an EDI Interchange
This specification assumes that a typical EDI interchange is the
lowest level object that will be subject to security services.
In 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
interchanges including envelope segments remain intact and
unreadable during secure transport.
-EDI envelope headers are encrypted
Harding, Shih, Drummond [Page 6]
MIME-based Secure EDI September 1999
Congruent with the above statement, EDI envelope headers are NOT
visible in the MIME package. In order to optimize VAN-to-
Internet routing, 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 that.
-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.3.2 Flexibility assumptions
-Encrypted or un-encrypted data
This specification allows for EDI message exchange where the EDI
Data can either be un-protected or protected by means of
encryption.
-Signed or un-signed data
This specification allows for EDI message exchange with or
Without digital signature of the original EDI transmission.
-Use of receipt or not
This specification allows for EDI 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 un-
signed receipt or MDN SHOULD be returned with the correct
"disposition modifier" error value.
-Formatting choices
This specification defines the use of two methods for formatting
EDI contents that have security applied to it:
-PGP/MIME
-S/MIME
This specification relies on the guidelines set forth in RFC
2015, as reflected in [4] "MIME Security with Pretty Good
Privacy" (PGP), and RFC 2633/ 2630 [8] "S/MIME Version 3
Harding, Shih, Drummond [Page 7]
MIME-based Secure EDI September 1999
Message Specification; Cryptographic Message Syntax". Compliance
with this specification REQUIRES the use of PGP/MIME or S/MIME
as defined in this Applicability statement, and the [9]
"Requirements for Inter-operable Internet EDI" draft.
-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.
In summary, the following eight 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 a signed or
unsigned receipt. The receiver sends back the signed or
unsigned receipt.
(3) Sender sends encrypted data, does NOT request a receipt.
(4) Sender sends encrypted data, requests a signed or unsigned
receipt. The receiver sends back the signed or un-signed
receipt.
(5) Sender sends signed data, does NOT request a signed or un-
signed receipt.
(6) Sender sends signed data, requests a signed or un-signed
receipt. Receiver sends back the signed or un-signed
receipt.
(7) Sender sends encrypted and signed data, does NOT request a
signed or un-signed receipt.
(8) Sender sends encrypted and signed data, requests a signed or
un-signed receipt. Receiver sends back the signed or un-
signed receipt.
NOTE: Users can choose any of the eight possibilities, but only
example (8), when a signed receipt is requested, offers the
whole suite of security features described in the "Secure
transmission loop" above.
3.0 Referenced RFCs and their contribution
3.1 RFC 821 SMTP [7]
This is the core mail transfer standard that all MTAs need to
Adhere to.
Harding, Shih, Drummond [Page 8]
MIME-based Secure EDI September 1999
3.2 RFC 822 Text Message Format [3]
Defines message header fields and the parts making up a message.
3.3 RFC 1847 MIME Security Multiparts [6]
This document defines security multiparts for MIME:
multipart/encrypted and multipart/signed.
3.4 RFC 1892 Multipart/report [10]
This RFC defines the use of the multipart/report content type,
something that the MDN RFC 2298 builds upon.
3.5 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.6 RFC 2015 PGP/MIME [4]
This RFC defines the use of content types "multipart/encrypted",
"multipart/signed", "application/pgp encrypted" and
"application/pgp-signature" for defining MIME PGP content.
3.7 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.8 RFC 2298 Message Disposition Notification [5]
This Internet RFC defines how a message disposition notification
(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 and the "Requirements" specification.
3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8]
This specification describes how MIME shall carry CMS Objects.
4.0 Structure of an EDI MIME message - Applicability
4.1 Introduction
The structures below are described hierarchically in terms of
Harding, Shih, Drummond [Page 9]
MIME-based Secure EDI September 1999
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. The "requirements
document" has several examples described in an Appendix for those
interested.
Also, these structures describe the initial transmission only.
Receipts, and requests for receipts are handled in section 5.
4.2 Structure of an EDI MIME message - PGP/MIME
4.2.1 No encryption, no signature
-RFC822/2045
-RFC1767 (application/EDIxxxx)
4.2.2 No encryption, signature
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767 (application/EDIxxxx)
-RFC2015 (application/pgp-signature)
4.2.3 Encryption, no signature
-RFC822/2045
-RFC1847 (multipart/encrypted)
-RFC2015 (application/pgp-encrypted)
-"Version: 1"
-RFC2015 (application/octet-stream)
-RFC1767 (application/EDIxxxx) (encrypted)
4.2.4 Encryption, signature
-RFC822/2045
-RFC1847 (multipart/encrypted)
-RFC2015 (application/pgp-encrypted)
-"Version: 1"
-RFC2015 (application/octet-stream)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767 (application/EDIxxxx)(encrypted)
-RFC2015 (application/pgp-signature)(encrypted)
4.3 Structure of an EDI MIME message - S/MIME
4.3.1 No encryption, no signature
-RFC822/2045
-RFC1767 (application/EDIxxxx)
Harding, Shih, Drummond [Page 10]
MIME-based Secure EDI September 1999
4.3.2 No encryption, signature
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767 (application/EDIxxxx)
-RFC2633 (application/pkcs7-signature)
4.3.3 Encryption, no signature
-RFC822/2045
-RFC2633 (application/pkcs7-mime)
-RFC1767 (application/EDIxxxx) (encrypted)
4.3.4 Encryption, signature
-RFC822/2045
-RFC2633 (application/pkcs7-mime)
-RFC1847 (multipart/signed) (encrypted)
-RFC1767 (application/EDIxxxx) (encrypted)
-RFC2633 (application/pkcs7-signature) (encrypted)
5.0 Receipts
5.1 Introduction
In order to support non-repudiation of receipt (NRR), a signed
receipt, based on digitally signing a message disposition
notification, is to be implemented by a receiving trading
partner's UA (User Agent). 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.
4). 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.
5). 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:
Harding, Shih, Drummond [Page 11]
MIME-based Secure EDI September 1999
1). The receiving trading partner acknowledges receipt of the
sent EDI Interchange.
2). If the sent message was signed, then the receiving trading
partner has authenticated the sender of the EDI Interchange.
3). If the sent message was signed, then the receiving trading
partner has verified the integrity of the sent EDI
Interchange.
Regardless of whether the EDI Interchange was sent in S/MIME or
PGP/MIME format, the receiving trading partner's UA MUST provide
the following basic processing:
1). If the sent EDI 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 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
Harding, Shih, Drummond [Page 12]
MIME-based Secure EDI September 1999
digital signature. The "protocol" option specified in the
second part of the multipart/signed is as follows:
S/MIME: protocol = "application/pkcs-7-signature"
PGP/MIME: protocol = "application/pgp-signature"
8). The signature information is formatted according to S/MIME or
PGP/MIME specifications.
The EDI 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 EDI 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.
5.2 Requesting a signed receipt
Message Disposition Notifications are requested as per RFC 2298,
"An Extensible Message Format for Message Disposition
Notification". 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
Harding, Shih, Drummond [Page 13]
MIME-based Secure EDI September 1999
The mail-address field is specified as an RFC 822 user@domain
address, and is the return address for the message disposition
notification.
In addition to requesting a message disposition notification, a
message disposition notification that is digitally signed, or
what has been referred to as a signed receipt, can be requested
by placing the following in the message header following the
"Disposition-Notification-To" line.
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 values for <protocol symbol> are
"pkcs7-signature", for the S/MIME detached signature format, or
"pgp-signature", for the pgp signature format.
The currently supported values for MIC algorithm values are:
Algorithm Value
used
MD5 md5
SHA-1 sha1
(Historical note: some early implementations of EDIINT emitted
and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.)
Receiving agents SHOULD be able to recover gracefully from a
micalg parameter value that they do not recognize.
Harding, Shih, Drummond [Page 14]
MIME-based Secure EDI September 1999
An example of a formatted options line would be as follows:
Disposition-notification-options:
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
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
MDN RFC 2298 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 5.3 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.
Harding, Shih, Drummond [Page 15]
MIME-based Secure EDI September 1999
5.2.1 Additional Signed Receipt Considerations
The "rules" stated in Section 2.2.3 for signed receipts are as
follows:
1). When a receipt is requested, explicitly specifying that the
receipt be signed, then the receipt MUST be returned with a
signature.
2). When a receipt is requested, explicitly specifying that the
receipt be signed, but the recipient cannot support either
the requested protocol format, or 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-Transfer-Encoding or
Content-Encoding, and without the MIME or any other RFC 822
Harding, Shih, Drummond [Page 16]
MIME-based Secure EDI September 1999
headers, since these are sometimes altered or reordered by MTAs.
5.3 Message Disposition Notification Format
The format of a message disposition notification is specified in
RFC 2298 For use in Internet EDI, the following format will be
used:
- content-type - per RFC 1892 and the RFC 2298 specification
- reporting-ua-field - per RFC 2298 specification
- MDN-gateway-field - per RFC 2298 specification
- original-recipient-field - per RFC 2298 specification
- final-recipient-field - per RFC 2298 specification
- original-message-id-field - per RFC 2298 specification
- disposition-field - the following "disposition-mode"
values SHOULD be used for
Internet EDI:
"automatic-action" - 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.
"manual-action" - 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.
"MDN-sent-automatically" - The MDN was sent because the UA had
previously been configured to do
so.
"MDN-sent-manually" - The user explicitly gave permission for
this particular MDN to be sent. "MDN-
sent-manually" is meaningful with
"manual-action", but not with
"automatic-action".
- disposition-field - the following "disposition-type" values
SHOULD be used for Internet EDI:
"processed" - The message has been processed in some manner
(e.g., printed, faxed, forwarded, gatewayed)
Harding, Shih, Drummond [Page 17]
MIME-based Secure EDI September 1999
without being displayed to the user. The user
may or may not see the message later.
"failed" - A failure occurred that prevented the proper
generation of an MDN. More information about the
cause of the failure may be contained in a
Failure field. The "failed" disposition type is
not to 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.
- disposition-field - the following "disposition-modifier"
values SHOULD be used for Internet EDI:
"error" - An error of some sort occurred that prevented
successful processing of the message. Further
information is contained in an Error field.
"warning" - The message was successfully processed but some
sort of exceptional condition occurred. Further
information is contained in a Warning field.
5.3.1 Message Disposition Notification Extensions
The following "extension field" will be added in order to support
signed receipts for RFC 1767 MIME content type and multipart MIME
content types that include the RFC 1767 MIME content type. The
extension field" defined below follows the "disposition-field" in
the MDN.
The "Received-content-MIC" extension field is set when the
integrity of the received message is verified. The MIC is the
base64 encoded quantity computed over the received message with a
hash function. For details of "what" the "Received-content-MIC"
should be calculated over, see Section 5.2.1. The algorithm used
to calculate the "Received-content-MIC" value MUST be the same as
the "micalg" value used by the sender in the multipart/signed
message. When no signature is received, or the mic-alg parameter
is not supported then it is RECOMMENDED that the SHA1 algorithm
be used to calculate the MIC on the received message or message
contents.
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".
Harding, Shih, Drummond [Page 18]
MIME-based Secure EDI September 1999
- extension field = "Received-content-MIC" ":" MIC
where:
<MIC> = <base64MicValue> "," <micalg>
<base64MicValue> = the result of one way hash function, base64
encoded.
< micalg> = the micalg value defined in RFC1847, an IANA
registered MIC algorithm ID token.
5.3.2 Disposition Mode, Type, and Modifier Use
Guidelines for use of the "disposition-mode", "disposition-
type", and "disposition-modifier" fields within Internet EDI are
discussed in this section. The "disposition-mode", "disposition-
type', and "disposition-modifier' fields are described in detail
in RFC 2298. The "disposition-mode', "disposition-type" and
"disposition-modifier" values SHOULD be used as follows:
5.3.2.1 Successful Processing
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":
Harding, Shih, Drummond [Page 19]
MIME-based Secure EDI September 1999
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.
5.3.2.2 Unprocessed 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 syntax of the "failed" "disposition-type" is general,
Allowing the sending of any textual information along with the
"failed" "disposition-type". For use in Internet EDI, the
following "failed" values are defined:
"Failure: unsupported format"
"Failure: unsupported MIC-algorithms"
5.3.2.3 Content Processing Errors
When errors occur processing the received message content, the
"disposition-field" should be set to the "processed"
"disposition-type" value and the "error" "disposition-modifier"
value. 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.
Harding, Shih, Drummond [Page 20]
MIME-based Secure EDI September 1999
"Error: unexpected-processing-error" - a catch-all for any
additional processing
errors.
An example of how the "disposition-field" would look when
content processing errors are detected is as follows:
Disposition: "disposition-mode";
processed/Error: decryption-failed
5.3.2.4 Content 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. 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
content processing warnings are detected is as follows:
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing continued
5.4 Message Disposition Notification Processing
5.4.1 Large File Processing
Large EDI Interchanges sent via SMTP can be automatically
fragmented by some message transfer agents. A subtype of
message, "partial", is defined in RFC 2045 [1] to allow large
objects to be delivered as separate pieces of mail and to be
automatically reassembled by the receiving user agent. Using
message, "partial", can help alleviate fragmentation of large
messages by different message transfer agents, but does not
completely eliminate the problem. It is still possible that a
piece of a partial message, upon re-assembly, may prove to
contain a partial message as well. This is allowed by the
Internet standards, and it is the responsibility of the user
agent to re-assemble the fragmented pieces.
It is RECOMMENDED that the size of the EDI Interchange sent via
SMTP be configurable so that if fragmentation does occur, then
Harding, Shih, Drummond [Page 21]
MIME-based Secure EDI September 1999
message, "partial" can be used to send the large EDI
Interchange in smaller pieces. RFC 2045 [1] defines the use of
Content-Type: message/partial. Support of the message/partial
content type for use in Internet EDI is OPTIONAL.
The receiving UA is required to re-assemble the original
message before sending the message disposition notification to
the original sender of the message. A message disposition
notification is used to specify the disposition of the entire
message that was sent, and should not be returned by a
processing UA until the entire message is received, even if the
received message requires re-assembling.
In general, EDI content compresses well, since there is
Repetitive data in most EDI Interchanges. Instead of
implementing the message/partial, compression of the EDI
Interchange can be done after the signature is applied to the
EDI Interchange, and before encryption. When no signature is
applied, then compression is applied before the encryption.
Compression is an alternative solution to implementing Content-
Type: message/partial when sending large EDI Interchanges on
the Internet.
Applying compression before encryption strengthens
cryptographic security since repetitious strings are reduced.
This sequence of signature, compression, then encryption, or
compression then encryption, is consistent with the order in
which PGP implementations handle compression.
Note: Compression is done automatically when using PGP
encryption.
The MIME standards [1], do not define a way in which to convey
that a message has been compressed. However, RFC 2045 [1] does
allow the definition of additional MIME header fields to
further describe the content of a message.
RFC 2068 [11], the HTTP/1.1 specification does define a
Content-Encoding field that is primarily used to convey
compression information:
Content-Encoding = "Content-Encoding" ":" content-coding
where content-coding can take on the values of "gzip" or
"compress". The gzip compression standard is further described
in RFC 1952 [12], and compress is the standard UNIX file
compression program. Both gzip and compress are registered with
IANA.
Trading partners can adopt the use of the Content-Encoding
header if they need to compress their EDI data and convey the
Harding, Shih, Drummond [Page 22]
MIME-based Secure EDI September 1999
compression type to their trading partners.
5.4.2 Example
The following is an example of a signed receipt returned by a
UA after successfully processing a MIME EDI content type. The
Sending trading partner has requested a return signed receipt.
This example follows the S/MIME application/pkcs-7-signature
format.
NOTE: This example is provided as an illustration only, and is
not considered part of the protocol specification. If an
example conflicts with the protocol definitions specified above
or in the other referenced RFCs, the example is wrong.
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="separator";
micalg=sha1; protocol="application/pkcs7-signature"
--separator
& Content-Type: multipart/report; report-type=disposition
& notification; boundary="xxxxx"
&
& --xxxxx
& Content-Type: text/plain
&
& The message sent to Recipient <Recipient@cyclonesoftware.com>
& has been received, the EDI Interchange was successfully
& decrypted and its integrity was verified. In addition, the
& sender of the message, Sender <Edi_Sender@cyclonesoftware.com>
& 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.
&
& --xxxxx
& Content-Type: message/disposition-notification
&
& Reporting-UA: Interchange.cyclonesoftware.com (CI 2.2)
& Original-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com
& Final-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com
& Original-Message-ID: <17759920005.12345@cyclonesoftware.com >
& Disposition: automatic-action/MDN-sent-automatically; processed
& Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1
&
Harding, Shih, Drummond [Page 23]
MIME-based Secure EDI September 1999
& --xxxxx
& Content-Type: message/rfc822
&
& To: <recipient email>
& Subject:
&
& [additional header fields go here]
&
& --xxxxx-
--separator
Content-Type: application/pkcs7-signature; name=smime.p7s;
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg
ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA
oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU=
--separator--
Notes:
-The lines preceded with "&" is what the signature is calculated
over.
(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".)
Note: As specified by RFC 1892 [10], 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.
It is RECOMMENDED that the received headers from the original
message be placed in the third body part, as they can be helpful
in tracking problems.
Also 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.
6.0 Public key certificate handling
6.1 Near term approach
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
Harding, Shih, Drummond [Page 24]
MIME-based Secure EDI September 1999
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 [3] email address. The procedures
for establishing a trading partnership and configuring the secure
EDI messaging system might vary among trading partners and
Software packages.
For systems which make use of X.509 certificates, it is
RECOMMENDED that trading partners self-certify each other if an
agreed upon certification authority is not used. It is highly
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.
This applicability statement does NOT require the use of a
certification authority. The use of a certification authority
is therefore OPTIONAL.
6.2 Long term approach
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.
7.0 Acknowledgments
Many thanks go out to the previous authors of the MIME-based
Secure EDI IETF Draft: Mats Jansson.
The authors would like to extend special thanks to Carl Hage, Jun
Ding, Dale Moberg, and Karen Rosenthal for providing the team
with valuable, and very thorough feedback. Without participants
like those cited above, these efforts become hard to complete in
a way useful to the users and implementers of the technology.
In addition, the authors would like to thank Harald Alvestrand,
Jim Galvin, and Roger Fajman for their guidance and input.
8.0 References
[1] N. Borenstein, N.Freed, "Multipurpose Internet Mail
Extensions (MIME)
Part One: Format of Internet Message Bodies", RFC 2045,
December 02, 1996.
Harding, Shih, Drummond [Page 25]
MIME-based Secure EDI September 1999
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] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 13, 1982.
[4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)",
RFC 2015, Sept. 1996.
[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] T. Harding, R. Drummond, "Requirements for Inter-operable
Internet EDI", Internet draft: draft-ietf-ediint-req07.txt
September 1999.
[10] G. Vaudreuil, "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC
1892, January 15, 1996.
[11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January
1997.
[12] L. Deutsch, "GZIP File Format Specification Version 4.3",
RFC 1952, May 23, 1996.
9.0 Authors' Addresses
Terry Harding
Harding, Shih, Drummond [Page 26]
MIME-based Secure EDI September 1999
tharding@cyclonesoftware.com
Cyclone Software
14505 N. Hayden Road. Suite 300
Scottsdale, AZ, 85260
Chuck Shih
chuck.shih@gartner.com
Gartner Group.
251 River Oaks Parkway
San Jose, CA 95134-1913 USA
Rik Drummond
drummond@onramp.com
The Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA
Harding, Shih, Drummond [Page 27]
