One document matched: draft-ietf-ediint-as2-00.txt
EDIINT Working Group Chuck Shih
draft-ietf-ediint-as2-00.txt Dale Moberg
Expires in six months Rik Drummond
14 November 1997
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,
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 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): Transport Layer Security [11]
3.3 RFC 1847 MIME Security Multiparts [6]
3.4 RFC 1892 Multipart/report [9]
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 Internet draft (fajman): Message Disposition Notification [5]
3.9 Internet draft (dusse): - S/MIME Specification [8]
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, and Original Recipient
4.2.4 Message-Id and Original-Message-Id
4.2.5 Host
5. Acknowledgments
6. References
7. Authors' Addresses
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 specified ([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 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.
An option to make use of Transport Layer Security [13] to provide
privacy is also added.
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 should 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 be added to support
message reconciliation, although the role of this value is not
crucial in a connection-oriented (the HTTP/1.1 default) transaction.
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-URI is normally exchanged
out of band, as part of setting up a trading partner agreement.
Automation of this process is outside this specification.)
The request line must be followed by a CRLF.
The request line may be followed by general headers and
request headers, but 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 headers used for requesting a message disposition
notification (unsigned or signed) have previously been mentioned.
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 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.
Successful responses will be discussed 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, 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. 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 application may include an unsolicited multipart/report
as a message body. Extended headers for content-type
and content-length must be provided.
When a message disposition notice extended header is present
in the POST request extended 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 a 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
be derived from the entity headers of the request,
because the "To" field may be absent in the entity
headers. In the case of a signed report,
the value 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,
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.
An application should 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.
The human readable part (the first part of the multipart/report)
may omit items such as the subject, date and other information
not generally present in header fields in the POST request.
Generally the first report part will consist of some text
reflecting the disposition status.
The HTTP reply SHOULD omit the third part of the report (which
can includes 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: Transport Layer
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 MIME Security Multiparts [6]
This document defines security multiparts for MIME:
multipart/encrypted and multipart/signed.
3.4 RFC 1892 Multipart/report [10]
This RFC defines the use of the multipart/report content type,
something that the MDN draft (fajman) builds upon.
3.5 RFC 1767 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]
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]
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): Message Disposition Notification [5]
This Internet draft 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.
3.9 Internet draft (dusse): S/MIME Message Specification [8]
This specification describes how MIME shall carry PKCS7
envelopes.
3.10 Internet draft (shih): 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, 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. 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 Message-Id and Original-Message-Id
In SMTP, required and useful for reconciliation of MDN receipt
with original message.
In HTTP, not required but could be useful for reconciliation
4.2.5 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
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.
[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, "S/MIME Message Specification; PKCS Security
Services for MIME", Internet draft: draft-dusse-mime-msg-spec
00.txt
[9] C. Shih, "Requirements for Interoperable Internet EDI",
Internet draft: draft-ietf-ediint-req03.txt July 1997.
[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,
[13] T. Dierks, "The TLS Protocol, Version 1.0," Internet draft:
draft-ietf-tls-protocol-04.txt, April 28, 1997.
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
| PAFTECH AB 2003-2026 | 2026-04-22 23:28:46 |