One document matched: draft-ietf-ediint-as1-05.txt
Differences from draft-ietf-ediint-as1-04.txt
EDIINT Working Group Chuck Shih
draft-ietf-ediint-as1-05.txt Mats Jansson
Expires: 10 July 98 Rik Drummond
8 July 1997
MIME-based Secure EDI
draft-ietf-ediint-as1-05.txt
Status of this Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
This document describes how to securely exchange EDI documents
using MIME and public key cryptography.
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/follow the discussion, you
need to subscribe at 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.
Shih, Jansson, Drummond Page 1
MIME-based Secure EDI 8 July 1997
Table of Contents
1. Introduction 3
2. Overview 4
2.1 Purpose of a security guideline for MIME EDI 4
2.2 Definitions
2.2.1 Terms 4
2.2.2 The secure transmission loop 5
2.2.3 Definition of receipts 5
2.3 Assumptions
2.3.1 EDI process assumptions 6
2.3.2 Flexibility assumptions 7
3. Referenced RFCs and their contribution 8
3.1 RFC 821 SMTP [7] 8
3.2 RFC 822 Text Message Format [3] 9
3.3 RFC 1847 MIME Security Multiparts [6] 9
3.4 RFC 1892 Multipart/report [9] 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 Internet draft (fajman): Message Disposition 9
Notification [5]
3.9 Internet draft (dusse): - S/MIME Specification [8] 9
4. 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
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. Receipts 11
5.1 Introduction 11
5.2 Requesting a signed receipt 14
5.2.1 Additional signed receipt considerations 15
5.3 Message Disposition Notification Format 16
5.3.1 Message Disposition Notification Extensions 18
Shih, Jansson, Drummond Page 2
MIME-based Secure EDI 8 July 1997
5.3.2 Disposition Mode, Type and Modifier Use 19
5.3.2.1 Successful Processing 19
5.3.2.2 Unprocessed Content 19
5.3.2.3 Content Processing Errors 20
5.3.2.4 Content Processing Warnings 21
5.4 Message Disposition Notification Processing 21
5.4.1 Large File Processing 21
5.4.2 Example 22
6. Public key certificate handling 24
6.1 Near term approach 24
6.2 Long term approach 24
7. Acknowledgments 25
8. References 26
9. Authors' Addresses 27
1. 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 and drafts:
-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 (elkins)
-RFC 2045 to 2049 MIME RFCs
-Internet draft: Message Disposition Notification (fajman)
-Internet draft: S/MIME Specification (dusse)
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.
Shih, Jansson, Drummond Page 3
MIME-based Secure EDI 8 July 1997
Note that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted
as described in RFC 2119.
2. Overview
2.1 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 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.
PGP/MIME Digital envelope security based on the Pretty
Good Privacy (PGP) standard (Zimmerman),
integrated with MIME Security Multiparts [6].
Shih, Jansson, Drummond Page 4
MIME-based Secure EDI 8 July 1997
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 encrypts the data and
provides a digital signature, using either PGP/MIME or S/MIME.
In addition, they request a signed receipt.
-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 sends a signed receipt in the
form of a signature over the hash of a message disposition
notification, which contains a hash of the received message.
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
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
Shih, Jansson, Drummond Page 5
MIME-based Secure EDI 8 July 1997
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, all bets are off -- a receipt may or may not
be returned. This behavior is consistent with the MDN Internet
draft.
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 sender
and content of a signed receipt. 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
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.
Shih, Jansson, Drummond Page 6
MIME-based Secure EDI 8 July 1997
-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 signature is REQUIRED as
part of the returned receipt, unless an error condition occurs
in which a signed-receipt 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 Internet draft [8] "S/MIME Message
Specification; PKCS Security Services for MIME". 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.
Shih, Jansson, Drummond Page 7
MIME-based Secure EDI 8 July 1997
-Hash function, message digest choices
When 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. 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.
Shih, Jansson, Drummond Page 8
MIME-based Secure EDI 8 July 1997
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 draft (fajman) 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 Internet draft (fajman): Message Disposition Notification [5]
This Internet draft 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 Internet draft (dusse): S/MIME Message Specification [8]
This specification describes how MIME shall carry PKCS7
envelopes.
Shih, Jansson, Drummond Page 9
MIME-based Secure EDI 8 July 1997
4. Structure of an EDI MIME message - Applicability
4.1 Introduction
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. 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"
-RFC1767 (application/EDIxxxx) (encrypted)
4.2.4 Encryption, signature
-RFC822/2045
-RFC1847 (multipart/encrypted)
-RFC2015 (application/pgp-encrypted)
-"Version 1"
-RFC1767 (application/EDIxxxx) (encrypted)
-RFC2015 (application/pgp-signature) (encrypted)
Shih, Jansson, Drummond Page 10
MIME-based Secure EDI 8 July 1997
4.3 Structure of an EDI MIME message - S/MIME
4.3.1 No encryption, no signature
-RFC822/2045
-RFC1767 (application/EDIxxxx)
4.3.2 No encryption, signature
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767 (application/EDIxxxx)
-Draft (dusse) (application/x-pkcs7-signature)
4.3.3 Encryption, no signature
-RFC822/2045
-Draft (dusse) (application/x-pkcs7-mime)
-RFC1767 (application/EDIxxxx) (encrypted)
4.3.4 Encryption, signature
-RFC822/2045
-Draft (dusse) (application/x-pkcs7-mime)
-RFC1847 (multipart/signed) (encrypted)
-RFC1767 (application/EDIxxxx) (encrypted)
-Draft (dusse) (application/x-pkcs7-signature) (encrypted)
5. 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
draft-ietf-receipt-mdn-04.txt is digitally signed by a receiving
trading partner as part of a multipart/signed MIME message.
The following support for signed receipts is REQUIRED:
Shih, Jansson, Drummond Page 11
MIME-based Secure EDI 8 July 1997
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
message disposition notification.
3). The ability to digitally sign the MIC.
4). The ability to create a multipart/signed content with the message
disposition notification as the first body part, and the signed
MIC calculated on the message disposition notification 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:
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.
Shih, Jansson, Drummond Page 12
MIME-based Secure EDI 8 July 1997
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"
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 multi-part MIME content that contains the EDI Interchange
is then enveloped in either S/MIME or PGP/MIME format.
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
Shih, Jansson, Drummond Page 13
MIME-based Secure EDI 8 July 1997
authenticated the sender of the EDI Interchange.
4). As a non-repudiation of receipt when the signed MIC calculated
over the MDN, is successfully decrypted by the sender with the
receiving trading partner's public key.
5.2 Requesting a signed receipt
Message Disposition Notifications are requested as per draft-ietf-
receipt-MDN-04.txt, "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
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 = signed-receipt-protocol=O,
<protocol symbol>; signed-receipt-micalg=O, <micalg1>, <micalg2>,...;
The currently supported values for <protocol symbol> are "x-pkcs7-
signature", for the S/MIME detached signature format, or "pgp-signature",
for the pgp signature format.
The signed-receipt-micalg is a list of MIC algorithm values defined in
RFC1847, an IANA registered MIC algorithm ID token.
An example of a formatted options line would be as follows:
Disposition-notification-options: signed-receipt-protocol=O,
x-pkcs7-signature; signed-receipt-micalg=O, rsa-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-
Shih, Jansson, Drummond Page 14
MIME-based Secure EDI 8 July 1997
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 "O" is defined in the MDN draft and
has the following meaning:
Parameters with an importance of "O" 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, will obviously not return a
signed receipt.
The importance of "O" 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.
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.
Shih, Jansson, Drummond Page 15
MIME-based Secure EDI 8 July 1997
3). When a signature is not explicitly requested, or if the
signed receipt request parameter is not recognized by the UA,
then all bets are off. In this situation, 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, or the multipart 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,
or the multipart 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
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
draft-ietf-receipt-mdn-04.txt. For use in Internet EDI, the
following format will be used:
- content-type - per RFC 1892 and the ietf-receipt-MDN specification
- reporting-ua-field - per ietf-receipt-MDN specification
Shih, Jansson, Drummond Page 16
MIME-based Secure EDI 8 July 1997
- MDN-gateway-field - per ietf-receipt-MDN specification
- original-recipient-field - per ietf-receipt-MDN specification
- final-recipient-field - per ietf-receipt-MDN specification
- original-message-id-field - per ietf-receipt-MDN specification
- disposition-field - the following "disposition-mode" values SHOULD
be used for Internet EDI:
"automatic-action" - The disposition described by the disposi-
tion type was a result of an automatic
action, rather than an explicit instruc-
tion by the user for this message.
"manual-action" - The disposition described by the disposi-
tion 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)
without being displayed to the user. The user may
or may not see the message later.
"failed" - A failure occurred that prevented the proper gener-
ation 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 dis-
position type with appropriate disposition modifiers
is to be used in such situations.
Shih, Jansson, Drummond Page 17
MIME-based Secure EDI 8 July 1997
- 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, 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".
- extension field = "Received-content-MIC" ":" MIC
where:
<MIC> = <base64MicValue> "," <micalg>
<base64MicValue> = the result of the one way hash function, base64
encoded.
Shih, Jansson, Drummond Page 18
MIME-based Secure EDI 8 July 199
< 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 draft-ietf-
receipt-mdn-04.txt. 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":
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
Shih, Jansson, Drummond Page 19
MIME-based Secure EDI 8 July 1997
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 hash over the MDN. 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.
"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
Shih, Jansson, Drummond Page 20
MIME-based Secure EDI 8 July 1997
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
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
Shih, Jansson, Drummond Page 21
MIME-based Secure EDI 8 July 1997
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 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.
Shih, Jansson, Drummond Page 22
MIME-based Secure EDI 8 July 199
This example follows the S/MIME application/x-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=rsa-sha1; protocol="application/x-pkcs7-signature"
--separator
&Content-Type: multipart/report; report-type=disposition
& notification; boundary = "xxxxx"
&
&--xxxxx
&Content-Type: text/plain
&
&The message sent to Edi Recipient <Edi_Recipient@edicorp.com>
&has been received, the EDI Interchange was successfully
&decrypted and its integrity was verified. In addition, the
&sender of the message, Edi Sender <Edi_Sender@othercorp.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: good-edi-internet-ua.edicorp.com (ediua 1.0)
&Original-Recipient: rfc822; Edi_Recipient@edicorp.com
&Final-Recipient: rfc822; Edi_Recipient@edicorp.com
&Original-Message-ID: <17759920005.12345@edicorp.com>
&Disposition: automatic-action/MDN-sent-automatically, processed
&Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, rsa-sha1
&
&--xxxxx
Shih, Jansson, Drummond Page 23
MIME-based Secure EDI 8 July 1997
&Content-Type: message/rfc822
&
&To: <recipient email>
&Subject:
&
& [additional header fields go here]
&
&--xxxxx--
--separator
Content-Type: application/x-pkcs7-signature
Content-Transfer-Encoding: base64
@ContentType = SignedData
@version = Version
@digestAlgorithms = DigestAlgorithmIdentifiers
@signerInfos = SignerInfo
--separator--
Notes:
-The lines preceded with "&" is what the signature is calculated
over.
-The text preceded by "@" indicates PKCS#7 defined fields and types.
(For details on how to prepare the multipart/signed with protocol
= "application/x-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. Public key certificate handling
6.1 Near term approach
In the near term, the exchange of public keys and certification
Shih, Jansson, Drummond Page 24
MIME-based Secure EDI 8 July 199
of these keys must be handled as part of the process of
establishing a trading partnership. The UA and/or EDI application
interface must maintain a database of public keys used for
encryption or signatures, in addition to the mapping between EDI
trading partner ID and RFC 822 [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 Implementation Guide Version 2. 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. Acknowledgments
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.
Shih, Jansson, Drummond Page 25
MIME-based Secure EDI 8 July 1997
8. 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] 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", draft-ietf-receipt-mdn-04.txt, June 14, 1997.
[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] S. Dusse, "S/MIME Message Specification; PKCS Security
Services for MIME", Internet draft: draft-dusse-mime-msg-spec
00.txt
[9] C. Shih, "Requirements for Inter-operable Internet EDI",
Internet draft: draft-ietf-ediint-req03.txt July 1997.
[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.
Shih, Jansson, Drummond Page 26
MIME-based Secure EDI 8 July 1997
9. Authors' Addresses
Chuck Shih
chucks@actracorp.com
Actra Corp.
610 East Caribbean Drive
Sunnyvale, CA 94089 USA
Mats Jansson
mjansson@agathon.com
LiNK
2317 Broadway, Suite 330
Redwood City, CA 94063 USA
Rik Drummond
drummond@onramp.com
The Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA
Shih, Jansson, Drummond Page 27
MIME-based Secure EDI 8 July 1997
| PAFTECH AB 2003-2026 | 2026-04-22 23:31:21 |