One document matched: draft-ietf-ediint-as1-00.txt

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