view Side-By-Side changes

Date: Tue, 09 Apr 2002 02:16:46 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 07 Apr 1998 05:47:57 GMT
ETag: "2e7a98-5690-3529be0d"
Accept-Ranges: bytes
Content-Length: 22160
Connection: close
Content-Type: text/plain
EDIINT Working Group                                        Chuck Shih
draft-ietf-ediint-as2-00.txt
draft-ietf-ediint-as2-03.txt                                Dale Moberg
Expires in six months months.                                      Rik Drummond
                                                        14 November 1997
                                                            10 February 1999

                      HTTP Transport for Secure EDI 

                      draft-ietf-ediint-as2-00.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, Internet-Draft and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts. is in full conformance
with all provisions of Section 10 of RFC2026.

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 view the current status of any Internet-Draft, please check
the
"1id-abstracts.txt" ``1id-abstracts.txt'' listing contained in the Internet-Drafts an 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). Directory, see http://www.ietf.org/shadow.html.


Abstract

This document describes how to exchange EDI documents securely
using http transport for EDI data that is packaged in MIME messages
that use public key security body parts. 

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#2" 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.

Table of Contents

1.  Introduction                                              
   1.1 Purpose and relation to previous work
   1.2 Overall operation 

2. Stages of an HTTP EDI exchange transaction
   2.1 EDI sending using POST 
    2.1.1 Response and Error Codes for POST requests
    2.1.2 Using Transport Layer Security
   2.2 Receipt Reply

3. Referenced RFCs and their contribution                   
   3.1  RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1 [11]   
   3.2  Internet draft (dierks):  RFC ????: Transport Layer Security [11] [13]
   3.3  RFC 1847 1847: MIME Security Multiparts [6]                
   3.4  RFC 1892 1892: Multipart/report [9] [10]                        
   3.5  RFC 1767 1767: EDI Content [2]                             
   3.6  RFC 2015 2015: PGP/MIME [4]                                
   3.7  RFC 2045, 2046, and 2049 2049: MIME [1]                     
   3.8  Internet draft (fajman):  RFC 2298: Message Disposition Notification [5]
   3.9  Internet draft (dusse): -  RFC 2311: S/MIME Version 2 Specification [8]
   3.10 RFC ????: MIME-based Secure EDI [12]

4. Differences between HTTP and SMTP based transport
   4.1 Unused MIME headers and operations
    4.1.1  Content-Transfer-Encoding not used
    4.1.2  Epilogue must be empty 
    4.1.3  Lengthy message bodies and Message/partial
   4.2 Differences in MIME or other headers or parameters used
    4.2.1  Content-Length needed.
    4.2.2  Disposition-notification-to 
    4.2.3  To, Final-Recipient,  Final-Recipient and Original Recipient
    4.2.4
    4.2.3  Message-Id and Original-Message-Id
    4.2.5
    4.2.3  Host header

5.  Acknowledgments                                         

6.  References                                              

7.  Authors' Addresses                                      

A.  Example exchange.

1.  Introduction

    1.1 Purpose and relation to previous work
         
    Early work on Internet EDI focused on specifying MIME content
    types for EDI data ([2] RFC 1767). The functional requirements 
    document [9], "Requirements for Interoperable Internet EDI," 
    provides extensive information on EDI security
    and the business and user processes surrounding the need for and 
    use of EDI security. In addition, MIME structures
    appropriate for SMTP transport of the packaged EDI data have
    been are
    specified in ([12] "MIME-based Secure EDI" draft ). 
    That specification also describes comprehensive security features,
    specifically data privacy, data integrity/authenticity, 
    non-repudiation of origin and non-repudiation of receipt. 

    In this document, it is assumed that the reader is familiar 
    with the SMTP/MIME transport document, the requirements document, 
    and the RFCs applied or referenced in those documents.

    This draft, like the SMTP/MIME transport document, builds on 
    previous RFCs and is attempting to "re-invent" as little 
    as possible.  The goal here is to specify how previously specified 
    MIME messaging structures and operations can be adapted for use with 
    HTTP servers and clients to obtain secure, reliable, 
    and acknowledged transport for EDI data.

    The applicability statement, [12] "MIME-based Secure EDI," 
    explained the basic EDI transaction using the concept of a
    "secure transmission loop" for EDI. This loop 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:

       i. 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.

       ii. The receiving organization decrypts the message and verifies 
       the signature, resulting in verified integrity of the data and
       authenticity of the sender.

       iii. The receiving organization then sends a signed receipt in the
       form of
       using 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. Other restricted subsets of 
    functionality have also been characterized. In this document, the
    goal is to make use of HTTP instead of SMTP as a transport protocol,
    and make changes needed to adapt to protocol packaging differences.
    In either transport case, the body of the message is a MIME structure.
    SMTP RFC 822 headers needed for the secure transmission
    loop become either HTTP entity-headers or extension-headers 
    [11, section 7.1]. Content transfer encodings (such as "base 64" and
    "quoted-printable" that have been needed in the SMTP context 
    are omitted in the HTTP context.

    An option to make use of Transport Layer Security [13] to provide 
    privacy is also added. added; compression can be provided using HTTP content-codings
    [11, sections 3.5, 14.3, 14.12]. (Content codings are not be be
    confused with the MIME concept of content transfer encodings.)
    Other differences are noted in the following and emphasized again
    in the concluding section.

    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. 

   1.2 Overall operation
    
    A HTTP POST operation [11] is used to send appropriately packaged
    EDI or other business data. The Request-URI ([11] ([11], section 9.5)
    identifies a process to unpack and handle the message data 
    and to generate a reply for the client that contains a message 
    disposition acknowledgement. This request/reply transaction 
    provides secure, reliable, and authenticated transport for EDI 
    or other business data using HTTP. 
 

2. Stages of an HTTP EDI exchange transaction

    An EDI data file or stream is first structured into one of the
    message templates described in [12], sections 4.2.1 to 4.2.4 or
    4.3.1 to 4.3.4 for PGP/MIME or S/MIME security. If TLS is to be used,
    the typical packaging will be that provided in 4.2.2 or 4.3.2; 
    that is, a multipart/signed message will be created with no 
    encryption in the message. Otherwise, if privacy 
    is desired, message templates 4.2.4 or 4.3.4 are used. 
    Content transfer encoding MUST not be used.  A content-length 
    field MUST be provided.

    To request an unsigned message disposition notification, 
    additional extension headers should MUST be added to the content-type
    and content-length headers in the entity header section preceding
    the message body. 

    A Disposition-Notification-To [5] header is added to indicate 
    that a message disposition notification is requested
    in the reply to the POST request. The value for this header
    plays no real role in the reply mechanism, unlike in the
    SMTP transport reply. A Message-ID header may MUST 
    be added to support message reconciliation, although reconciliation. Both "From"
    and "To" headers MUST be supplied. Other headers, especially
    "Subject" and "Date", SHOULD be supplied; these values
    are often mentioned in the role human-readable section of this value is not
    crucial the MDN
    to aid in a connection-oriented (the HTTP/1.1 default) transaction. identifying the original message.

    A Disposition-Notification-Options header is used to request 
    a signed message disposition notification. The parameters 
    used to select protocols for signed message disposition 
    notification are found in [12].

    2.1 EDI sending using POST 
    
    For sending EDI, the following protocol elements are typically
    present: a request line [11], ([11], section 5.1, 5.1), entity headers, a 
    CRLF pair to mark the end of the entity headers, followed by the
    message-body. 

    The request line will have the form: "POST Request-URI HTTP/1.1".
    The spaces must be present. (The The request line must be followed by a CRLF.
    The Request-URI is normally typically exchanged out of band, 
    as part of setting up a bilateral trading partner agreement.
    Automation of this process is outside this specification.)
    The request line must be followed by specification but
    might involve obtaining a CRLF. session URL from an authentication page,
    for example.

    The request line may be followed by general headers and
    request headers, but must MUST be followed by entity headers
    specifying content length ([11] section 14.14) and content type
    [11] section 14.18. The Host request header ([11] sections 9 
    and 14.23) MUST be included.

    The entity or extension headers used for requesting a message disposition
    notification (unsigned or signed) have previously been mentioned. mentioned,
    as have those  ("To" "From" "Message-Id") that are needed as values
    for MDN fields. 

    2.1.1 Response and Error Codes for POST requests

    The status line for response to errors in the POST request line
    will be provided by a status line with the following protocol
    elements present ( [11], section 6.1 ) : HTTP version (normally,
    HTTP/1.1), a status code, reason phrase, and CRLF. 

    The suggested status codes return status concerning HTTP operations.
    The status code should be a 204 ("No Content")
    in case the request-URI process does not produce 
    an entity to return. Other explicit error codes are 
    documented in [11], sections 6.1.1 and throughout section 10. 
    For errors in the request-URI, 400 ("Bad Request"), 
    404 ("Not Found") and similar codes are appropriate status codes.
    These codes are specified in [11].

    Successful responses codes will be discussed mentioned in section 2.2 below, 
    where the inclusion of an entity containing the message 
    disposition notification is also discussed.

    2.1.2 Using Transport Layer Security

    To use Transport Layer Security, Security [13], the request-URI should indicate
    the appropriate scheme value, https. Usually only a multipart/signed
    message body would be sent using TLS, as encrypted message bodies
    would be redundant. Encrypted message bodies may be sent, however.
  
    2.2 Receipt Reply

    The response to the POST command varies depending upon whether
    a receipt has been requested and upon what kind of receipt
    has been requested.

    With no extended header requesting a receipt, and no errors
    accessing the request-URI specified processing, the status
    line in the Response to the POST request should be 200, 
    201 or 202. in the
    200 range. Status code 200 ("OK") should be used when
    an entity is returned (a signed receipt in a multipart/signed 
    content type or an unsigned receipt in a multipart/report). 
    Status 201 ("Created") should be used if a URI pointing to a receipt
    is returned; this may be preferable to returning an unsolicited
    receipt. 
    The code 202 ("Accepted") should be used to indicate
    processing unable to generate acknowledgements; this status
    is non-committal on the disposition of the message.
    
    An user agent application may include respond with an unsolicited 
    multipart/report as a message body. Extended Entity headers for content-type 
    and content-length must MUST be provided.

    When a message disposition notice extended extension header is present
    in the POST request extended entity headers, then entity headers for
    the message disposition notice should be included and a message
    body containing the multipart/report [10] or multipart/signed [6]
    should be included in the Response entity headers as appropriate. 
    The basic responsibilities of responding to requests are discussed
    at length in [12] section 5, and in detail within section 5.2.1.

    Message Disposition Notifications, when used in the HTTP reply
    context, will normally contain a restricted set of features
    of closely parallel a SMTP MDN. 

    The disposition field is a required element in the machine 
    readable second part of a multipart/report. 
    The final-recipient-field([5] section 3.1) value need not SHOULD
    be derived from the entity headers of the request,
    because request
    If the "To" field may be absent in the entity
    headers. In the case of a is missing, for signed report, messages,
    the value for Original-recipient may be the email 
    address field from the signer's X.509 attribute for 
    email addresses.
    For unsigned reports, a technical or administrative
    contact's email address may be included. However, addresses if a "To" field is present in the request headers,
    then that value should be used for the value of the
    "Final-Recipient" field in the message/disposition-notification
    body part. is available.

    An application should MUST report the Message-ID of a request
    if it was included in the request using the original-message-
    id-field in the message/disposition-notification body part. request.

    The human readable part (the first part of the multipart/report)
    may omit
    SHOULD include items such as the subject, date and other information 
    not generally 
    when those fields are present in entity header fields in following the
    POST request.
    Generally the first report part  will consist of some text 
    reflecting the disposition status.
     
    The HTTP reply SHOULD normally omit the third part of the report (which
    can includes
    (used to return the original message or its headers in the SMTP
    context).
    
3. Referenced RFCs and their contribution

     3.1 RFC 2068 [11] : The HyperText Transfer Protocol, HTTP,
     provides an application level protocol for distributed hypermedia
     information systems. This standard specifies the protocol HTTP/1.1.

     3.2 Internet Draft  draft-ietf-tls-protocol-04.txt: RFC ???? [13] : Transport Layer Security 
     Security specifies a protocol similar to SSL version 3 that provides
     communications privacy over the Internet.  Applications can
     communicate without eavesdropping, tampering, or message forgery.

     3.3 RFC 1847 [6] : MIME Security Multiparts [6] 

     This document defines security multiparts for MIME:
     multipart/encrypted and multipart/signed.

     3.4 RFC 1892 Multipart/report [10] : Multipart/report 

     This RFC defines the use of the multipart/report content type,
     something type
     that the MDN draft (fajman) builds upon. RFC 2298 [5] presupposes.

     3.5 RFC 1767 [2] :  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] : 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 [1] : MIME 

     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): RFC 2298 [5] : Message Disposition Notification [5] 

     This Internet draft RFC defines how a message disposition notification
     (MDN) is requested, and the format and syntax of the MDN. 
     The MDN is the basis upon which receipts and signed receipts
     are defined in this and the "Requirements" specification. in [12].
        
     3.9 Internet draft (dusse): RFC 2311 [8] : S/MIME Version 2 Message Specification [8] 
     This specification describes how MIME shall carry PKCS7 1.5
     envelopes.
    
     3.10 Internet draft (shih): RFC ???? [12] : MIME-based Secure EDI [12] 
     This applicability statement describes security patterns,
     MIME content types, and acknowledgement policies and
     mechanisms for EDI or business data transport.
    

4. Comparison of HTTP and SMTP based transport

    The major difference between HTTP and SMTP transport for secure
    EDI is found in the persistence of the connection over the send
    and reply transaction. SMTP may involve mail relays; HTTP
    may involve intermediate proxies. Likewise, SMTP MTAs must invoke
    user agents to handle messages, and HTTP servers handle
    the POST request via a cooperating thread or process.

    For HTTP version 1.1, TCP persistent connections are the default, 
    ( [11] sections 8.1.2, 8.2, and 19.7.1).

    A number of other differences exist because HTTP does not
    conform to MIME [1] as used in SMTP transport. Relevant
    differences are summarized below.

  4.1 Unused MIME headers and operations

   4.1.1  Content-Transfer-Encoding not used in HTTP transport

    Because HTTP, unlike SMTP, does not have an early history
    involving 7-bit restriction,

    HTTP can handle binary data and so there is no need to use
    the Content Transfer Encodings transfer encodings of MIME [1]. This difference
    is discussed in [11] section 19.4.4.
      
   4.1.2  Epilogue must be empty 

    The EBNF for a multipart [1] RFC 2046, section 5.1.1 allows 
    a multipart to have trailing octets after the close delimiter. 
    In [11] section 3.7.2, it is explicitly noted that multiparts 
    must have null epilogues.

   4.1.3  Lengthy message bodies

    In [12], section 5.4.1, options for large file processing are
    discussed for SMTP transport. For HTTP, large files should
    be handled correctly by the TCP layer. However, [11] sections
    3.5 and 3.6 discuss some options for compressing or chunking
    entities to be transferred. Section 8.1.2.2 discusses a
    pipelining option that may be useful for segmenting large
    amounts of data.

  4.2 Differences in MIME or other headers or parameters used

   4.2.1  Content-Length

    Because connections are persistent, closing a connection
    cannot be used to indicate the end of an entity. Therefore,
    [11] sections 4.4 and 14.14 indicate the need for a
    Content-Length entity header in a request. In MIME,
    Content-Length is not normally used.
 
   4.2.2  Disposition-notification-to 
   
    In MIME, a value is needed in order to mail the 
    message disposition notification to an address.

    In HTTP, a value is not needed because the reply
    goes back as an "immediate" response, using the
    existing TCP connection. A good value to use would 
    be a technical or administrative contact email address.
    The header itself must be present.

 
   4.2.3  To, Final Recipient, and Original Recipient

    The "To" is optional in the POST request. 

    If present, it should be used as the Final-Recipient value
    if request generated. If absent, Final-Recipient value may
    be the signer email address for unsigned receipts or 
    a technical or administrative contact email address.

    The final and original recipient distinction should not
    arise for HTTP transport.

   4.2.4 transport because SMTP aliases and mailing
    lists should not be used.

   4.2.3 Message-Id and Original-Message-Id

   In SMTP, required

    The Message-Id and useful for reconciliation of MDN receipt
   with original message.

   In HTTP, Original-Message-Id distinction should not required but could be useful
    arise for reconciliation


   4.2.5 HTTP transport because SMTP MTA alterations should
    not occur.

   4.2.4 Host header

    The host request header field must be included in the
    POST request made when sending business data. This field
    is to allow one server IP address to service multiple
    hostnames, and potentially conserve IP addresses.
    See [11], sections 14.23 and 19.5.1.
    
5. Acknowledgments

   Carl Hage, Karen Rosenfeld and Chuck Fenton have provided valuable suggestions
   for the improvement of this applicability statement.

6. 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. RFC 2298, March 1998.

[6]  J. Galvin, S. Murphy, S. Crocker, N. Freed,  "Security Multiparts
     for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct.    
     3, 1995

[7]  J. Postel, "Simple Mail Transfer Protocol",  STD 10, RFC 821,
     August 1, 1982.

[8]  S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka,
     "S/MIME Version 2 Message Specification; PKCS Security
     Services for MIME", Internet draft: draft-dusse-mime-msg-spec
     00.txt Specification", RFC 2311.

[9]  C. Shih, "Requirements for Interoperable Internet EDI",
     Internet draft: draft-ietf-ediint-req03.txt  July 1997. draft-ietf-ediint-req05.txt.

[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] C. Shih, "MIME-based Secure EDI", Internet draft: 
     draft-ietf-ediint-as1-04.txt, 
     draft-ietf-ediint-as1-08.txt.

[13] T. Dierks, "The TLS Protocol, Version 1.0,"  Internet draft:
     draft-ietf-tls-protocol-04.txt, April 28, 1997.
     draft-ietf-tls-protocol-05.txt.


7.  Authors' Addresses

Chuck Shih
chucks@actracorp.com
Actra Corp.
610 East Caribbean Drive
Sunnyvale, CA 94089 USA

Dale Moberg
dale_moberg@stercomm.com
Sterling Commerce
4600 Lakehurst Ct.
Dublin, OH 43016 USA

Rik Drummond
drummond@onramp.com
The Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA



Appendix A. Example Exchange.

   NOTE:  This example is provided as illustration only
   If the example conflicts with the previous text, 
   the example is wrong.

   Likewise, the use of entity or extension fields in
   this example is not to be construed as a definition for those type
   names or extension fields.


A.1 Sending a multipart signed for trading partner 1 back to 
trading partner 2. "#" indicates a comment line.

POST https://tp2server.company2.com/cgi-bin/tp1drawer.pl HTTP/1.1
Host: tp2server.company2.com
From: tp1@company1.com
To: tp2@company2.com
Date: Tue, 06 Nov 2001 12:53:01 UT
Subject: Purchase orders for 6 November 2001
Message-Id: <20011106@company1.com>
Disposition-Notification-To: tp1@company1.com
# continuation lines not used in actual HTTP protocol data unit
Content-Type: multipart/signed; boundary="20011106RsXgYlvCNW" ; 
 protocol=application/pkcs7-signature;  micalg=rsa-md5
Content-Length: 3056

--20011106RsXgYlvCNW
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
Content-Length: 2605

ISA ...
# EDI transaction data
IEA  ...
--20011106RsXgYlvCNW
Content-Type: application/pkcs7-signature
Content-Length: 804

# omitted binary data
--20011106RsXgYlvCNW--

A.2
Returning a signed MDN (using the previously established TLS security) 
from trading partner 2 back to trading partner 1.
"#" indicates a comment line.

HTTP/1.0 200 OK
Server: HTTPEDI/1.1
Content-type: multipart/signed;
Content-Length: 1200

--boundary1
Content-type: multipart/report
Content-length: 1133

--boundary2
Content-type: text/plain
Content-length: 85

Message <20011106@company1.com> was authenticated;
EDI processing was initiated. 
--boundary2
Content-type: message/disposition-notification
Content-length: 213

Reporting-UA: Company2UA
Original-Message-Id: <20011106@company1.com>
Original-Recipient: tp2@company2.com
X-Received-Content-MIC: w7AguNJEmhF/qIjJw6LnnA==,rsa-md5
Disposition: MDN-sent-automatically/processed

--boundary2--

--boundary1
Content-Type: application/pkcs7-signature
Content-Length: 560

# Signature data omitted
--boundary1--

----