EDIINT Working Group Chuck Shih draft-ietf-ediint-as2-04.txt Dale Moberg Expires in six months. Rik Drummond 24 February 1999 HTTP Transport for Secure EDI Status of this Memo This document is an Internet-Draft and 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 view the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in an Internet- Drafts Shadow 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 2.3 Other Reply Content 2.3.1 Non-Repudiation of the POST Reply 2.4 Error Recovery 3. Referenced RFCs and their contribution 3.1 RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1 [11] 3.2 RFC 2246: Transport Layer Security [13] 3.3 RFC 1847: MIME Security Multiparts [6] 3.4 RFC 1892: Multipart/report [10] 3.5 RFC 1767: EDI Content [2] 3.6 RFC 2015: PGP/MIME [4] 3.7 RFC 2045, 2046, and 2049: MIME [1] 3.8 RFC 2298: Message Disposition Notification [5] 3.9 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 Final-Recipient and Original Recipient 4.2.3 Message-Id and Original-Message-Id 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 are specified in ([12] "MIME-based Secure EDI" ). 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 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 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], 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 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. A Message-ID header MUST be added to support message 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 human-readable section of the MDN to aid in 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], section 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 request line must be followed by a CRLF. The Request-URI is typically exchanged out of band, as part of setting up a bilateral trading partner agreement. Automation of this process is outside this specification but might involve obtaining a session URL from an authentication page, for example. The request line 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, 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 status codes return status concerning HTTP operations. The status code should be 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 codes will be 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 [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 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). The user agent application may respond with an unsolicited multipart/report as a message body. Entity headers for content-type and content-length MUST be provided. When a message disposition notice extension header is present in the POST request 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 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 SHOULD be derived from the entity headers of the request If the "To" field is missing, for signed messages, the value for Original-recipient may be the email address field from the signer's X.509 attribute for email addresses if that value is available. An application MUST report the Message-ID of a request. The human readable part (the first part of the multipart/report) SHOULD include items such as the subject, date and other information when those fields are present in entity header fields following the POST request. The HTTP reply SHOULD normally omit the third part of the report (used to return the original message or its headers in the SMTP context). 2.3 Other Reply Content In general, both HTTP servers and HTTP clients should be prepared to process the basic EDI data formats when they are embedded within MIME multiparts. The response to the POST operation may include other MIME wrapped content besides an MDN Receipt. If a receipt was requested within the POST data, and additional content is to be returned, the receipt multipart/report MUST be combined with the other data using some MIME multipart pattern. Real-time EDI processing systems MAY use MIME multipart content-types to include a response EDI message, for example, a Quote in response to a Request-For-Quote transaction. 2.3.1 Non-Repudiation of the POST Reply If the reply to a POST operation requires a receipt for non- repudiation (for example, the reply includes content other than a receipt), the top-level headers in the response MUST include the same headers required for POST data described above: Disposition-Notification-To, Message-ID, From, and To. Other headers described above used in a MDN SHOULD be included, for example Date and Subject. The MDN receipt of the response data must be returned using a subsequent POST operation. A POST operation used only to transmit an MDN SHOULD not include the Disposition- Notification-To receipt request, and only a 200 ("OK") response would be expected. An MDN in response to a reply may be combined with a subsequent EDI message sent with a POST operation, for example a Purchase-Order transaction in response to a Quote. The MIME multipart/mixed form is used to combine the MDN with the other data, the same as for a POST reply. 2.4 Error Recovery If the HTTP client fails to read the HTTP server response data, the POST operation with identical content (including Message-ID) SHOULD be repeated, if the error condition is transient. The Message-ID on a POST operation can be reused if and only if all of the content (including the original Date) is identical. Details of the retry process -- including time intervals to pause, number of retries to attempt, timeouts for retrying -- are implementation dependent. Servers should be prepared to receive a POST with a repeated Message-ID. The MIME reply body previously sent should be resent, including the MDN and other MIME parts. 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 RFC 2246 [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 This document defines security multiparts for MIME: multipart/encrypted and multipart/signed. 3.4 RFC 1892 [10] : Multipart/report This RFC defines the use of the multipart/report content type that the MDN RFC 2298 [5] presupposes. 3.5 RFC 1767 [2] : 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 [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 [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 RFC 2298 [5] : Message Disposition Notification This 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 in [12]. 3.9 RFC 2311 [8] : S/MIME Version 2 Message Specification This specification describes how MIME shall carry PKCS7 1.5 envelopes. 3.10 RFC ???? [12] : MIME-based Secure EDI 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 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 HTTP can handle binary data and so there is no need to use the Content 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. 4.2.2 Final and Original Recipient The final and original recipient distinction should not arise for HTTP transport because SMTP aliases and mailing lists should not be used. 4.2.3 Message-Id and Original-Message-Id The Message-Id and Original-Message-Id distinction should not arise for 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", 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", RFC 2311. [9] C. Shih, "Requirements for Interoperable Internet EDI", Internet draft: 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-08.txt. [13] T. Dierks, "The TLS Protocol, Version 1.0," Internet draft: draft-ietf-tls-protocol-05.txt. 7. Authors' Addresses Chuck Shih Chuck.Shih@gartner.com 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--