wdiff rfc5402.original rfc5402.txt

Internet Draft Editor: Terry Harding
draft-ietf-ediint-compression-12.txt
Independent Submission T. Harding, Ed.
Request for Comments: 5402 Axway
Expires: February 27, 2009 August 27, 2008
Intended Status:
Category: Informational January 2010
ISSN: 2070-1721

Compressed Data within an Internet EDI
Electronic Data Interchange (EDI) Message

Status of this memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

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.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

This document explains the rules and procedures for utilizing
compression (RFC 3274) within an Internet EDI (Electronic Data
Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823.

Status of This Memo

This document is not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5402.

IESG Note

The content of this RFC was at one time considered by the IETF, and
therefore it may resemble a current IETF work in progress or a
published IETF work. This RFC is not a candidate for any level of
Internet Standard. The IETF disclaims any knowledge of the fitness
of this RFC for any purpose and in particular notes that the decision
to publish is not based on IETF review for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. The RFC Editor has chosen to publish this document at its
discretion. Readers of this RFC should exercise caution in
evaluating its value for implementation and deployment. See RFC 3932
for more information.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http:trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.

1. Introduction

Historically, electronic messages produced by systems following the
guidelines as outlined in the IETF EDIINT working group Working Group
specifications AS1[AS1], AS2[AS2] AS1 [AS1], AS2 [AS2], and AS3[AS3], AS3 [AS3] did not have a way
to provide a standardized transport neutral mechanism for compressing
large payloads. However, with the development of RFC 3274 - Compressed 3274,
"Compressed Data Content Type for Cryptographic Message Syntax (CMS),
(CMS)", we now have a transport neutral transport-neutral mechanism for compressing
large payloads.

A typical EDIINT 'AS' message is a multi-layered MIME message,
consisting of one or more of the following, following: payload layer, signature
layer
layer, and/or the encryption layer. When an 'AS' message is received received, a
Message Integrity Check(MIC) Check (MIC) value must be computed based upon
defined rules within the EDIINT 'AS' RFCs and must be returned to the
sender
Compressed Data within an Internet EDI Message February 2009 of the message via an a Message Disposition Notification(MDN). Notification (MDN).

The addition of a new compression layer will require this document to
outline new procedures for building/layering 'AS' messages and
computing a MIC value that is returned in the MDN receipt.

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 [RFC2119].

2. Compressed Data MIME Layer

The compressed-data CMS(Cryptographic CMS (Cryptographic Message Syntax) MIME entity as
described in [COMPRESSED-DATA] may encapsulate a MIME entity
which that
consists of either an unsigned or signed business document.

Implementers are to follow the appropriate specifications identified
under "References"
in [MIME-TYPES], the "MIME Media Types" registry [MIME-TYPES] maintained by IANA
for the type of object being packaged. For example, to package an
XML object, the MIME media type of "application/xml" is used in the Content-type
Content-Type MIME header field and the specifications for enveloping
the object are contained in [XMLTYPES]; [XMLTYPES].

MIME entity example:

Content-type: application/xml; charset="utf-8"

<?xml version="1.0" encoding="UTF-8"?>

The MIME entity will be compressed using [ZLIB] and placed inside a
CMS compressed-data object as outlined in [COMPRESSED-DATA]. The
compressed data
compressed-data object will be MIME encapsulated according to details
outlined in [S/MIME3.1], RFC 3851, Section 3.5.

Example:

Content-Type: application/pkcs7-mime; smime-type=compressed-data;
name=smime.p7z
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7z

MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg
Hnic7ZRdb9owFIbvK/k/5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49/XHoUW7S/0
fU5ivWnasml72XFb3gb5druui7ytN803M570nii7C5r8tfwR281hy/p/KSM3+jzH5s3+
P3VT3QbLusnt8WPIuN5vN/vaA2+DulnXTXkXvNTr8j8ouZmkCmGI/UW+ZS/C8zP0bz2d
UEk2M8mlaxjRMByAhZTj0RGYg4TvogiRASROsZgjpVcJCb1KV6QzQeDJ1XkoQ5Jm+C5P
v+ORAcshOGeCcdFJyfgFxdtCdEcmOrbinc/+BBMzRThEYpwl+jEBpciSGWQkI0TSlREm
SGLuESm/iKUFt1y4XHBO2a5oq0IKJKWLS9kUZTA7vC5LSxYmgVL46SIWxIfWBQd6Adrn
vGxVibLqRCtIpp4g2qpdtqK1LiOeolpVK5wVQ5P7+QjZAlrh0cePYTx/gNZuB9Vhndtg
W9ogK+3rnmg3YWygnTuF5GDS+Q/jIVLnCcYZFc6Kk/+c80wKwZjwdZIqDYWRH68MuBQS
Compressed Data within an Internet EDI Message February 2009
3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD/cK/JWTHJRe76MUXnfBW8m7Hd5zhQ4ri
+kV1/3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA

Note: Content-Transfer-Encoding of base64 would only be required if
the compressed-data MIME bodypart is transferred via a 7-bit protocol
like SMTP and is visible in the outer layer of the MIME message. If
the compressed-data MIME bodypart is placed inside of an encrypted
MIME bodypart, content-transfer-encoding would not be required on the
compressed-data MIME bodypart, but would be required on the encrypted
MIME bodypart.

3. Structure of an EDI MIME compressed message Compressed Message

When compressing a document which that will be signed, the application MAY
compress the inner most innermost MIME body before signing, see Section signing (see Sections 3.2 and 3.5
3.5), or it MAY compress the outer multipart/signed MIME
body, see Section body (see
Sections 3.3 and 3.6 3.6), but it MUST NOT do both within the same
document. The receiving application MUST support both methods of
compression when unpackaging an inbound document.

Note: The following sections 3.1 (3.1 - 3.6 3.6) show the individual layers
of a properly formatted EDIINT EDI MIME message with a compressed data
layer. Please refer to the appropriate RFCs for the proper
construction of the resulting MIME message.

3.1 "application/xxxxxxx" is
used to indicate an application media subtype.

3.1. No encryption, no signature

-RFC2822/2045 Encryption, No Signature

-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)

This section shows the layers of an unsigned, unencrypted compressed
message. The first line indicates that the MIME message conforms to
RFCs 2822
[RFC5322] and RFC 2045 [RFC2045] with a Content-Type of application/pkcs7-mime. application/pkcs7-
mime. Within the pkcs7-mime entity is a compressed MIME entity
containing the electronic business document.

3.2

3.2. No encryption, signature

-RFC2822/2045 Encryption, Signature

-RFC5322/2045
-[RFC1847] (multipart/signed)
-[COMPRESSED-DATA](application/pkcs7-mime)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)

This section shows the layers of a signed, unencrypted compressed
message where the payload is compressed before being signed.

3.3

3.3. No encryption, signature

-RFC2822/2045
Compressed Data within an Internet EDI Message February 2009 Encryption, Signature

-RFC5322/2045
-[COMPRESSED-DATA](application/pkcs7-mime)
-[RFC1847] (multipart/signed)(compressed)
-[MIME-TYPES](application/xxxxxxx)(compressed)
-RFC3851 (application/pkcs7-signature)(compressed)

This section shows the layers of a signed, unencrypted compressed
message where a signed payload is compressed.

3.4

3.4. Encryption, no signature

-RFC2822/2045 No Signature

-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[MIME-TYPES](application/xxxxxxx)(compressed)(encrypted)

This section shows the layers of an unsigned, encrypted compressed
message where the payload is compressed before it is encrypted.

3.5

3.5. Encryption, signature

-RFC2822/2045 Signature

-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[RFC1847] (multipart/signed) (encrypted)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature) (encrypted)

This section shows the layers of an a signed, encrypted compressed
message where the payload is compressed before being signed and
encrypted.

3.6

3.6. Encryption, signature

-RFC2822/2045 Signature

-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[COMPRESSED-DATA](application/pkcs7-mime) (encrypted)
-[RFC1847] (multipart/signed) (compressed)(encrypted)
-[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature)(compressed)(encrypted)

This section shows the layers of an a signed, encrypted compressed
message where the payload is compressed signed before being signed compressed and
encrypted.

4. MIC Calculations For for Compressed Messages Requesting Signed Receipts

4.1

4.1. MIC Calculation For for Signed Message

For any signed message, the MIC to be returned is calculated over the
same data that was signed in the original message as per [AS1]. The
signed content will be a mime MIME bodypart that contains either
compressed or uncompressed data.

Compressed Data within an Internet EDI Message February 2009

4.2

4.2. MIC Calculation For for Encrypted, Unsigned Message

For encrypted, unsigned messages, the MIC to be returned is
calculated over the uncompressed data content including all MIME
header fields and any applied Content-Transfer-Encoding.

4.3

4.3. MIC Calculation For for Unencrypted, Unsigned Message

For unsigned, unencrypted messages, the MIC is calculated over the
uncompressed data content including all MIME header fields and any
applied Content-Transfer-Encoding.

5. Error Disposition Modifier

For a received message where a receipt has been requested and
decompression fails, the following disposition modifier will be
returned in the signed MDN.

"Error: decompression-failed" - the receiver could not decompress
the message

6. EDIINT Version Header Field

Any application that supports the compression methods outlined within
this document MUST use a version identifier value of "1.1" or greater
within the AS2 or AS3 Version header field as describe in [AS2] and
[AS3].

7. Compression Formats

Implementations MUST support ZLIB [ZLIB] [ZLIB], which utilizes
DEFLATE[DEFLATE]. DEFLATE
[DEFLATE].

8. Security Considerations

This document is not concerned with security, except for any security
concerns mentioned in the referenced RFCs.

9. IANA Considerations

This document has no actions for IANA.

Author's Addresses

Terry Harding
Axway
Scottsdale, Arizona, USA
tharding@us.axway.com

References Normative References
Compressed Data within an Internet EDI Message February 2009

[AS1] T. Harding, R. T., Drummond, R., and C. Shih, MIME-based "MIME-based
Secure Peer-to-Peer Business Data Interchange over the Internet,
Internet", RFC 3335, Sept 2002 September 2002.

[AS2] D. Moberg, D. and R. Drummond, MIME-Based "MIME-Based Secure Peer-to-Peer Peer-
to-Peer Business Data Interchange Using HTTP,
Applicability Statement 2 (AS2), (AS2)", RFC 4130, July 2005.

[AS3] T. Harding, T. and R. Scott, FTP "FTP Transport for Secure
Peer-to-Peer
EDI Business Data Interchange over the Internet,
Internet", RFC 4823, May April 2007.

[ZLIB] RFC1950 ZLIB Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3,
P.Deutsch and J-L Gailly, 3.3", RFC 1950, May 1996.

[DEFLATE] RFC1951 DEFLATE Deutsch, P., "DEFLATE Compressed Data Format
Specification version
1.3, P.Deutsch, 1.3", RFC 1951, May 1996.

[MIME-TYPES] "Media Types," http://www.isi.edu/in-
notes/iana/assignments/media-types/media-types. IANA, "MIME Media Types" registry, available from
http://www.iana.org.

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

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.

[RFC2119] Key Words Bradner, S., "Key words for Use use in RFC's RFCs to Indicate
Requirement Levels,
S.Bradner, Levels", BCP 14, RFC 2119, March 1997.

[S/MIME3.1]S/MIME

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.

[S/MIME3.1] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification, B.Ramsdell, Specification",
RFC 3851, July 2004. RFC 3851

[XMLTYPES] M. Murata, S. St.Laurent, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.

[COMPRESSED-DATA] Compressed
Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS), P. Gutmann, (CMS)", RFC 3274, June
2002.

Acknowledgements

10. Acknowledgments

A number of the members of the EDIINT Working Group have also worked
very hard and contributed to this document. The following people have
made direct contributions to this document. document:

David Fischer, Dale Moberg, Robert Asis Asis, and everyone involved in the
AS1, AS2 Interop testing during 2002.

Compressed Data within an Internet EDI Message February 2009

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Expires February 27, 2009

Author's Address

Terry Harding
Axway
Scottsdale, Arizona
USA

EMail: tharding@us.axway.com