RFC 5402

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

📅 published February 2010, from ietf

RFC 5402: Compressed Data within an Internet Electronic Data Interchange (EDI) Message ✨

Okay bestie, this one's from T. Harding, Ed. at Axway 💼. It's an Informational doc from the Independent Submission stream, so it's not a standards-track spec. It's dated February 2010 and has ISSN 2070-1721 🎀. Its header doesn't list anything it obsoletes or updates, so it's just a standalone explainer.

Abstract

Okay so this doc explains how to use compression (RFC 3274) inside an Internet EDI (Electronic Data Interchange) 'AS' message 📦 The AS message is defined in RFCs 3335, 4130, and 4823 🌸.

Status of This Memo

Heads up, this is NOT a standards-track spec. It's published for informational purposes 🦋.

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved by the RFC Editor aren't a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💅.

Info about the current status, errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc5402 ✨.

IESG Note

The content of this RFC was once considered by the IETF, so it may look like a current IETF work in progress or a published IETF work 👀. It's not a candidate for any level of Internet Standard. Readers should be careful about how much they trust it when deciding whether to implement or deploy it 💀.

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.

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

1. Introduction 🌈

Historically, electronic messages made by systems following the IETF EDIINT Working Group specs AS1 [AS1], AS2 [AS2], and AS3 [AS3] didn't have a standardized, transport-neutral way to compress large payloads 😭. Then RFC 3274, "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", showed up, and now we do have a transport-neutral mechanism for compressing large payloads 🙌.

A typical EDIINT 'AS' message is a multi-layered MIME message. It can have a payload layer, a signature layer, and/or an encryption layer 🧁. When an 'AS' message comes in, a Message Integrity Check (MIC) value must be computed using the rules in the EDIINT 'AS' RFCs, and it must be sent back to the sender in a Message Disposition Notification (MDN) 💌.

Adding a new compression layer means this document has to outline new steps for building and layering 'AS' messages and for computing the MIC value that goes back 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 Message Syntax) MIME entity described in [COMPRESSED-DATA] can wrap a MIME entity that holds either an unsigned or a signed business document 🍓.

Implementers should follow the right specs from the "MIME Media Types" registry [MIME-TYPES] that IANA maintains, based on what kind of object is being packaged. For example, to package an XML object, you use the MIME media type application/xml in the Content-Type MIME header field, and the rules for enveloping the object are in [XMLTYPES] 🧚.

Here's a MIME entity example 👇

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

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

The MIME entity gets compressed with [ZLIB] and placed inside a CMS compressed-data object as outlined in [COMPRESSED-DATA] 🗜️. The compressed-data object then gets MIME encapsulated following the details 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
3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD/cK/JWTHJRe76MUXnfBW8m7Hd5zhQ4ri
+kV1/3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA
Note: Content-Transfer-Encoding of base64 is only needed if the compressed-data MIME bodypart travels over a 7-bit protocol like SMTP and is visible in the outer layer of the MIME message 📨. If the compressed-data MIME bodypart sits inside an encrypted MIME bodypart, Content-Transfer-Encoding isn't required on the compressed-data MIME bodypart, but it is required on the encrypted MIME bodypart 🔐.

3. Structure of an EDI MIME Compressed Message 🧩

When you compress a document that's going to be signed, the application MAY compress the innermost MIME body before signing (see Sections 3.2 and 3.5), or it MAY compress the outer multipart/signed MIME body (see Sections 3.3 and 3.6), but it MUST NOT do both within the same document 🙅‍♀️. The receiving application MUST support both methods of compression when unpacking an inbound document 💖.

Note: Sections 3.1 - 3.6 show the individual layers of a properly formatted EDI MIME message with a compressed data layer 🦋. For how to actually build the resulting MIME message, check the appropriate RFCs 📚. application/xxxxxxx is used to show an application media subtype 🌸.

3.1. No Encryption, No Signature

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

This is the layer stack for an unsigned, unencrypted compressed message 🎀. The first line says the MIME message conforms to [RFC5322] and [RFC2045] with a Content-Type of application/pkcs7-mime. Inside the pkcs7-mime entity is a compressed MIME entity holding the electronic business document 💅.

3.2. No Encryption, Signature

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

This shows a signed, unencrypted compressed message where the payload gets compressed before it's signed ✍️.

3.3. No Encryption, Signature

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

This shows a signed, unencrypted compressed message where a signed payload gets compressed 🗜️.

3.4. Encryption, No Signature

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

This shows an unsigned, encrypted compressed message where the payload gets compressed before it's encrypted 🔒.

3.5. Encryption, 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 shows a signed, encrypted compressed message where the payload gets compressed before being signed and encrypted 🧁.

3.6. Encryption, 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 shows a signed, encrypted compressed message where the payload gets signed before it's compressed and encrypted 🌈.

4. MIC Calculations for Compressed Messages Requesting Signed Receipts 💌

4.1. MIC Calculation 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 bodypart that contains either compressed or uncompressed data 🗜️.

4.2. MIC Calculation 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. MIC Calculation 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 🚨

If a message comes in where a receipt was requested and decompression fails, the following disposition modifier gets returned in the signed MDN 💔.

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

9. Normative References ✨

okay bestie, this is the reading list the spec is built on 📚 every doc in here is a must-read to implement this correctly 💅

  • [AS1] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 3335, September 2002.
  • [AS2] Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", RFC 4130, July 2005.
  • [AS3] Harding, T. and R. Scott, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", RFC 4823, April 2007.
  • [ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
  • [DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
  • [MIME-TYPES] IANA, "MIME Media Types" registry, available from http://www.iana.org.
  • [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
  • [S/MIME3.1] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
  • [XMLTYPES] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [COMPRESSED-DATA] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.

10. Acknowledgments 🫶

a big shoutout to the whole crew in the EDIINT Working Group 💖 a bunch of them worked super hard on this doc and helped make it happen ✨

the people who made direct contributions to this document are:

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

Author's Address 🦋

Terry Harding Axway Scottsdale, Arizona USA

EMail: tharding@us.axway.com 💜

📦 where this page comes from