INTERNET DRAFT Mats Jansson, LiNK draft-ietf-ediint-as1-03.txt Chuck Shih, Actra Expire in six months Rik Drummond, Drummond Group 7 March, 1997 MIME-based Secure EDI 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 email@example.com. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. Table of Contents 1. Introduction 2. Overview 2.1 Purpose of a security guideline for MIME EDI 2.2 Definitions 2.2.1 Terms 2.2.2 The secure transmission loop 2.2.3 Definition of receipts 2.3 Assumptions 2.3.1 EDI process assumptions 2.3.2 Flexibility assumptions 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP  3.2 RFC 822 Text Message Format  3.3 RFC 1847 MIME Security Multiparts  3.4 RFC 1892 Multipart/report  3.5 RFC 1767 EDI Content  3.6 RFC 2015 PGP/MIME  3.7 RFC 2045,2046, and 2049 MIME  3.8 Internet draft (fajman): Message Disposition Notification  3.9 Internet draft (dusse): - S/MIME Specification  4. Structure of an EDI MIME message - Applicability 4.1 Introduction 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature 4.2.2 No encryption, signature 4.2.3 Encryption, no signature 4.2.4 Encryption, signature 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature 4.3.2 No encryption, signature 4.3.3 Encryption, no signature 4.3.4 Encryption, signature 5. Receipts 5.1 Introduction 5.2 Requesting a signed receipt 5.2.1 Additional signed receipt considerations 5.3 Message Disposition Notification Format 5.3.1 Message Disposition Notification Extension Fields 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing 5.4.2 Example 6. Public key certificate handling 6.1 Near term approach 6.2 Long term approach 7. Authors' Addresses 8. References 1. Introduction The authors would like to extend special thanks to Carl Hage Dale Moberg and Karen Rosenthal for providing the team with valuable, and very thorough feedback. Without participants like these, these efforts become hard to complete in a way useful to the users of the technology. The authors would also like to thank Nancy Turaj for her help in editing portions of this document. Previous work on Internet EDI focused on specifying MIME content types for EDI data ( 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. 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 way by which a receipt or a signed Notification (MDN) receipt is accomplished within Internet Messaging. 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 . 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,  "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 from the previous step. 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 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 "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 indeed has to be returned with a signature. If a receipt is requested, explicitly specifying that the receipt be signed, but the recipient cannot support the requested signature format, 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. This is consistent with the MDN 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 features. 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. -X12.58 and UN/EDIFACT security considerations The most common EDI standards, 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 is either 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 these cases an un-signed receipt or MDN should be returned with the correct "signed-receipt-disposition" value. -Formatting choices This specification defines 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 the RFC 2015, as reflected in  MIME Security with Pretty Good Privacy (PGP), and Internet draft  S/MIME Specification from RSA Security, Inc. (dusse) Compliance with this specification dictates that AT LEAST one of these methods is supported. -Hash function, message digest choices When signature is used, unless specified otherwise by the chosen method (PGP/MIME or S/MIME), the SHA1 checksum hash function is recommended. 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 receipt. Receiver sends back a receipt. (3) Sender sends encrypted data, does NOT request a receipt. (4) Sender sends encrypted data, requests a receipt. Receiver sends back a 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 a 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 a 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  This is the core mail transfer standard that all MTAs need to adhere to. 3.2 RFC 822 Text Message Format  Defines message header fields and the parts making up a message. 3.3 RFC 1847 MIME Security Multiparts  This document defines security multiparts for MIME: multipart/encrypted and multipart/signed. 3.4 RFC 1892 Multipart/report  This RFC defines the use of Multipart/report content type, something that the MDN draft (fajman) relies on for the receipt functionality. 3.5 RFC 1767 EDI Content  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  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  These are the basic MIME standards, upon which all MIME related RFCs build, including this one. Key contributions include definition of "content type" and sub-type "multipart", in addition to encoding guidelines, which establish 7-bit US-ASCII as the lowest common denominator used. 3.8 Internet draft (fajman): Message Disposition Notification  This Internet draft defines how a message disposition notification (MDN) is requested, and the structure of the MDN. NOTE: This is the only specification we were not able to take "as is". Extension field-names beginning with "X-" will not be defined as a standard field. MDN field names not beginning with "X- " need to be registered with the Internet Assigned Numbers Authority (IANA) and described in an RFC. The "X-" extension fields described in this document will be registered with IANA. 3.9 Internet draft (dusse): S/MIME Message Specification  This specification describes how MIME shall carry PKCS7 signature and envelope information. 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) 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-02.txt is digitally signed by a receiving trading partner and returned to the sending trading partner as part of a multipart/signed MIME message. The required support for signed receipts when doing Internet EDI is as follows: 1). Create a multipart/report; report-type = disposition-notification. 2). Calculate the MIC on the message disposition notification. 3). Digitally sign the MIC. 4). 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). 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 received 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 signature is compared with the MIC calculated using the same one-way hash function that the sending trading partner used. 4). The receiving trading partner formats the MDN and sets the calculated MIC into the "X-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 is 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 then 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 "X-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 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-02.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>; 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. An example of a formatted options line would be as follows: Disposition-notification-options: signed-receipt-protocol=O, x-pkcs7-signature; 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 MIC algorithm and signature algorithm used in formulating the signed receipt are agreed to in the trading partner relationship. The actual algorithms used in the signed receipt are always returned as part of the 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 "signed-receipt-protocol" 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 desirable 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 and extension fields 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 indeed has to be returned with a signature. 2). When a receipt is requested, explicitly specifying that the receipt be signed, but the recipient cannot support the requested signature format, 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 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 should still be returned. The request for a signed receipt should still be honored, though the transaction itself may not be valid. The reason for why the contents could not be processed should still be set in the "disposition-field". When a request for a signed receipt is made, then the calculation of the "X-Received-content-MIC" should be as follows: - For any signed messages, the MIC to be returned is calculated on the RFC 1767 MIME header and content, or multipart MIME header and content. - For encrypted, unsigned messages, the MIC to be returned is calculated on the decrypted RFC 1767 MIME header and content, or multipart MIME header and content. - For unsigned, unencrypted messages, the MIC should be calculated over the message body 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. A new extension field that further qualifies the "disposition-field" is defined by this specification. The field "X-Disposition-qualifier-field" is used to convey additional error or status information on the value specified in the "disposition-field". 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. The "X-Disposition-qualifier-field" allows for qualifying an "autoprocessed-with-warning" disposition value with a "X-Disposition-qualifier-field" of "authentication-failed" for instance. This use of a disposition qualifier value would convey in the above example, that even though authentication failed, the receiving trading partner still processed the received EDI transactions. 5.3 Message Disposition Notification Format The format of a message disposition notification is as specified in draft-ietf-receipt-mdn-02.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 - 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 - for EDI use: "notprocessed" - The received content(s) was not processed. "autoprocessed" - The message has been processed automatically in some manner (e.g., printed, faxed, forwarded, gatewayed) in response to some user request made in advance, without being displayed to the user. The user may or may not see the message later. "autoprocessed-with-warning" - The message has been processed automatically in some manner (e.g., printed, faxed, forwarded, gatewayed) in response to some user request made in advance, without being displayed to the user. The user may or may not see the message later. | Additionally, the "disposition-qualifier-field" may be set with a warning description. "decryption-failed" - The receiver could not decrypt the contents. "authentication-failed" - The receiver could not authenticate the sender. "integrity-check-failed" - The receiver could not verify content integrity. "unexpected-processing-error" - A catch-all for additional processing errors. Note: The "notprocessed" disposition value should be used when the message content is being rejected or ignored, for instance if it is determined that a signed receipt cannot be returned so the UA chooses not to process the message content itself. The "unexpected-processing-error" should be used when an actual error is encountered when processing the message content. 5.3.1 Message Disposition Notification Extension Fields The following "extension fields" will be added in order to support signed receipts for RFC 1767 MIME content types and multi-part MIME content types that include the RFC 1767 MIME content types. The "extension fields" defined below follow the "disposition-field" in the MDN. The "X-Disposition-qualifier-field" is used to further qualify the value in the "disposition-field". The value of the "X-Disposition-qualifier-field" can be used to further describe the "autoprocessed-with-warning" disposition value, or as further elaboration of any other "disposition-field". This field is optional, and when it is not used, does not appear in the MDN. The values for the "X-Disposition-qualifier-field" are implementation dependent. - extension field = "X-" "Disposition-qualifier-field" ":" value The "X-Received-content-MIC" extension field is set when the integrity of the received message is verified. The MIC is the hex coded quantity computed over a "body part" with a message digest or hash function. For details of "what" the "X-Received-content-MIC" should be calculated over, see Section 5.2.1. The algorithm used to calculate the "X-Received-content-MIC" value should be the same as the "micalg" value received in the multipart/signed. When no signature is received, then it is recommended that the SHA1 algorithm be used to calculate the "X-Received-content-MIC" value. 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 "non-repudiation of receipt" to occur on the sender's side. - extension field = "X-" "Received-content-MIC" ":" MIC where: <MIC> = <hexMicValue> "," <micalg> <hexMicValue> = the result of the one way hash function, coded as hexadecimal digits. < micalg> = the micalg value defined in RFC1847, an IANA registered MIC algorithm ID token. The "X-Signed-receipt-disposition" extension field is set when a request for a signed receipt is made by the sender, but cannot be returned by the receiver. - extension field = "X-" "Signed-receipt-disposition": signed-receipt-disposition where signed-receipt-disposition is: "unsupported-format" - A request for a signed receipt cannot be returned because the requested format is not supported. "unexpected-error" - A catch-all for errors that prevent a signed receipt from being returned when it has been requested. 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  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  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 , do not define a way in which to convey that a message has been compressed. However, RFC 2045  does allow the definition of additional MIME header fields to further describe the content of a message. RFC 2068 , 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 furthur described in RFC 1952 , 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. 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: <firstname.lastname@example.org> &Disposition: autoprocessed &X-Disposition-qualifier-field: none &X-Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, rsa-sha1 & &--xxxxx &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" documentation.) Note: As specified by RFC 1892 , 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 it 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 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  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. 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. Authors' Addresses Mats Jansson email@example.com LiNK 2317 Broadway, Suite 330 Redwood City, CA 94063 USA Chuck Shih firstname.lastname@example.org Actra Corp. 610 East Caribbean Drive Sunnyvale, CA 94089 USA Rik Drummond email@example.com The Drummond Group 5008 Bentwood Ct. Ft. Worth, TX 76132 USA 8. References  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.  D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995.  D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 13, 1982.  M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, Sept. 1996.  R. Fajman, "An Extensible Message Format for Message Disposition Notifications", draft-ietf-receipt-mdn-01.txt, May 13, 1996.  J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995  J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1, 1982.  S. Dusse, "S/MIME Message Specification; PKCS Security Services for MIME", Internet draft: draft-dusse-mime-msg-spec 00.txt  C. Shih, "Requirements for Inter-operable Internet EDI", July 1996.  G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 15, 1996.  R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.  L. Deutsch, "GZIP File Format Specification Version 4.3", RFC 1952, May 23, 1996.