HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:16:05 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 22 Oct 1996 22:23:00 GMT ETag: "323b1e-1667-326d4944" Accept-Ranges: bytes Content-Length: 5735 Connection: close Content-Type: text/plain INTERNET DRAFT Mats Jansson, LiNK draft-ietf-ediint-as1-00.txt Chuck Shih, Actra Expire in six months Nancy Turaj, Mitre Corp. Rik Drummond, Drummond Group 19 October, 1996 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 mjansson@agathon.com, with "AS#1" in the Subject field. -Be specific as to what section you are referring to, preferrably 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. -If you are questioning fundamental methods, make it clear to us and we will bring the issue to the ediint list for discussion. To follow the discussion, you need to subscribe at ietf-ediint@imc.org. 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. Structure of an EDI MIME message 3.1 Referenced RFC's and their contribution 3.1.1 RFC 821 SMTP [7] 3.1.2 RFC 822 Text Message Format [3] 3.1.3 RFC 1521 MIME [1] 3.1.4 RFC 1847 MIME Security Multiparts [6] 3.1.5 RFC 1892 Multipart/report [9] 3.1.6 RFC 1767 EDI Content [2] 3.1.7 RFC 2015 PGP/MIME [4] 3.1.8 Internet draft (fajman): Message Disposition Notification [5] 3.1.9 RSA Specifications - S/MIME (RSA Security, Inc.) [8] 3.2 Vocabulary 3.3 Structure of an EDI MIME message - No encryption/No signature 3.4 Structure of an EDI MIME message - Encryption/No signature 3.4.1 S/MIME 3.4.2 PGP/MIME 3.5 Structure of an EDI MIME message - No encryption/Signature 3.5.1 S/MIME 3.5.2 PGP/MIME 3.6 Structure of an EDI MIME message - Encryption/Signature 3.6.1 S/MIME 3.6.2 PGP/MIME 4. Receipts 4.2 Requesting a signed receipt 4.3 Message Disposition Notification Format 4.4 Message Disposition Notification Processing 4.4.1 Segmented Messages 4.4.2 Multiple Mime Body Parts 4.4.3 Example 5. Public key certificate handling 5.1 Near term approach 5.2 Long term approach 6. Authors' Addresses 7. References 1. Introduction Previous work on internet EDI focussed 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 enhancements 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 RFC's and drafts: -RFC 821 SMTP -RFC 822 Text Message Formats -RFC 1521 MIME -RFC 1767 EDI Content Type -RFC 1847 Security Multiparts for MIME -RFC 1892 Multipart/Report -Internet draft: Message Disposition Notification (fajman) -RFC 2015 MIME/PGP (elkins) -S/MIME Specification (RSA) Our intent here is to define clearly and precisely how these are pieced 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