1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Independent Submission T. Harding, Ed.
Request for Comments: 5402 Axway
Category: Informational February 2010
ISSN: 2070-1721
<span class="h1">Compressed Data within an Internet</span>
<span class="h1">Electronic Data Interchange (EDI) Message</span>
Abstract
This document explains the rules and procedures for utilizing
compression (<a href="./rfc3274">RFC 3274</a>) 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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5402">http://www.rfc-editor.org/info/rfc5402</a>.
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. Readers of this RFC should exercise caution in
evaluating its value for implementation and deployment.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> 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
<span class="grey">Harding Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5402">RFC 5402</a> Compressed Data in an Internet EDI Message February 2010</span>
carefully, as they describe your rights and restrictions with respect
to this document.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Historically, electronic messages produced by systems following the
guidelines as outlined in the IETF EDIINT Working Group
specifications AS1 [<a href="#ref-AS1" title=""MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet"">AS1</a>], AS2 [<a href="#ref-AS2" title=""MIME-Based Secure Peer-to- Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)"">AS2</a>], and AS3 [<a href="#ref-AS3" title=""FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet"">AS3</a>] did not have a way
to provide a standardized transport neutral mechanism for compressing
large payloads. However, with the development of <a href="./rfc3274">RFC 3274</a>,
"Compressed Data Content Type for Cryptographic Message Syntax
(CMS)", we now have a 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: payload layer, signature
layer, and/or encryption layer. When an 'AS' message is received, a
Message Integrity Check (MIC) value must be computed based upon
defined rules within the EDIINT 'AS' RFCs and must be returned to the
sender of the message via a Message Disposition 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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Compressed Data MIME Layer</span>
The compressed-data CMS (Cryptographic Message Syntax) MIME entity as
described in [<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>] may encapsulate a MIME entity that
consists of either an unsigned or signed business document.
Implementers are to follow the appropriate specifications identified
in the "MIME Media Types" registry [<a href="#ref-MIME-TYPES" title=""MIME Media Types"">MIME-TYPES</a>] 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 MIME header field and the specifications for enveloping
the object are contained in [<a href="#ref-XMLTYPES" title=""XML Media Types"">XMLTYPES</a>].
MIME entity example:
Content-type: application/xml; charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<!-- sample xml document -->
<span class="grey">Harding Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5402">RFC 5402</a> Compressed Data in an Internet EDI Message February 2010</span>
The MIME entity will be compressed using [<a href="#ref-ZLIB" title=""ZLIB Compressed Data Format Specification version 3.3"">ZLIB</a>] and placed inside a
CMS compressed-data object as outlined in [<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>]. The
compressed-data object will be MIME encapsulated according to details
outlined in [S/MIME3.1], <a href="./rfc3851#section-3.5">RFC 3851, Section 3.5</a>.
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 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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Structure of an EDI MIME Compressed Message</span>
When compressing a document that will be signed, the application MAY
compress the innermost MIME body before signing (see Sections <a href="#section-3.2">3.2</a> and
3.5), or it MAY compress the outer multipart/signed MIME body (see
Sections <a href="#section-3.3">3.3</a> and <a href="#section-3.6">3.6</a>), 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.6) show the individual layers
of a properly formatted EDI MIME message with a compressed data
layer. Please refer to the appropriate RFCs for the proper
construction of the resulting MIME message. "application/xxxxxxx" is
used to indicate an application media subtype.
<span class="grey">Harding Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5402">RFC 5402</a> Compressed Data in an Internet EDI Message February 2010</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. No Encryption, No Signature</span>
-RFC5322/2045
-[<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>](application/pkcs7-mime)
-[<a href="#ref-MIME-TYPES" title=""MIME Media Types"">MIME-TYPES</a>](application/xxxxxxx)(compressed)
This section shows the layers of an unsigned, unencrypted compressed
message. The first line indicates that the MIME message conforms to
[<a href="./rfc5322" title=""Internet Message Format"">RFC5322</a>] and [<a href="./rfc2045" title=""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"">RFC2045</a>] with a Content-Type of
application/pkcs7-mime. Within the pkcs7-mime entity is a compressed
MIME entity containing the electronic business document.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. No Encryption, Signature</span>
-RFC5322/2045
-[<a href="./rfc1847" title=""Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"">RFC1847</a>] (multipart/signed)
-[<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>](application/pkcs7-mime)
-[<a href="#ref-MIME-TYPES" title=""MIME Media Types"">MIME-TYPES</a>](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.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. No Encryption, Signature</span>
-RFC5322/2045
-[<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>](application/pkcs7-mime)
-[<a href="./rfc1847" title=""Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"">RFC1847</a>] (multipart/signed)(compressed)
-[<a href="#ref-MIME-TYPES" title=""MIME Media Types"">MIME-TYPES</a>](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.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Encryption, No Signature</span>
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>](application/pkcs7-mime) (encrypted)
-[<a href="#ref-MIME-TYPES" title=""MIME Media Types"">MIME-TYPES</a>](application/xxxxxxx)(compressed)(encrypted)
This section shows the layers of an unsigned, encrypted compressed
message where the payload is compressed before it is encrypted.
<span class="grey">Harding Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5402">RFC 5402</a> Compressed Data in an Internet EDI Message February 2010</span>
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Encryption, Signature</span>
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[<a href="./rfc1847" title=""Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"">RFC1847</a>] (multipart/signed) (encrypted)
-[<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>](application/pkcs7-mime) (encrypted)
-[<a href="#ref-MIME-TYPES" title=""MIME Media Types"">MIME-TYPES</a>](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature) (encrypted)
This section shows the layers of a signed, encrypted compressed
message where the payload is compressed before being signed and
encrypted.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Encryption, Signature</span>
-RFC5322/2045
-RFC3851 (application/pkcs7-mime)
-[<a href="#ref-COMPRESSED-DATA">COMPRESSED-DATA</a>](application/pkcs7-mime) (encrypted)
-[<a href="./rfc1847" title=""Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"">RFC1847</a>] (multipart/signed) (compressed)(encrypted)
-[<a href="#ref-MIME-TYPES" title=""MIME Media Types"">MIME-TYPES</a>](application/xxxxxxx) (compressed)(encrypted)
-RFC3851 (application/pkcs7-signature)(compressed)(encrypted)
This section shows the layers of a signed, encrypted compressed
message where the payload is signed before being compressed and
encrypted.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. MIC Calculations for Compressed Messages Requesting Signed Receipts</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. MIC Calculation for Signed Message</span>
For any signed message, the MIC to be returned is calculated over the
same data that was signed in the original message as per [<a href="#ref-AS1" title=""MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet"">AS1</a>]. The
signed content will be a MIME bodypart that contains either
compressed or uncompressed data.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. MIC Calculation for Encrypted, Unsigned Message</span>
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.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. MIC Calculation for Unencrypted, Unsigned Message</span>
For unsigned, unencrypted messages, the MIC is calculated over the
uncompressed data content including all MIME header fields and any
applied Content-Transfer-Encoding.
<span class="grey">Harding Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5402">RFC 5402</a> Compressed Data in an Internet EDI Message February 2010</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Error Disposition Modifier</span>
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
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. EDIINT Version Header Field</span>
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 [<a href="#ref-AS2" title=""MIME-Based Secure Peer-to- Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)"">AS2</a>] and
[<a href="#ref-AS3" title=""FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet"">AS3</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Compression Formats</span>
Implementations MUST support ZLIB [<a href="#ref-ZLIB" title=""ZLIB Compressed Data Format Specification version 3.3"">ZLIB</a>], which utilizes DEFLATE
[<a href="#ref-DEFLATE" title=""DEFLATE Compressed Data Format Specification version 1.3"">DEFLATE</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This document is not concerned with security, except for any security
concerns mentioned in the referenced RFCs.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Normative References</span>
[<a id="ref-AS1">AS1</a>] Harding, T., Drummond, R., and C. Shih, "MIME-based
Secure Peer-to-Peer Business Data Interchange over the
Internet", <a href="./rfc3335">RFC 3335</a>, September 2002.
[<a id="ref-AS2">AS2</a>] Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-
Peer Business Data Interchange Using HTTP,
Applicability Statement 2 (AS2)", <a href="./rfc4130">RFC 4130</a>, July 2005.
[<a id="ref-AS3">AS3</a>] Harding, T. and R. Scott, "FTP Transport for Secure
Peer-to-Peer Business Data Interchange over the
Internet", <a href="./rfc4823">RFC 4823</a>, April 2007.
[<a id="ref-ZLIB">ZLIB</a>] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", <a href="./rfc1950">RFC 1950</a>, May 1996.
[<a id="ref-DEFLATE">DEFLATE</a>] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", <a href="./rfc1951">RFC 1951</a>, May 1996.
[<a id="ref-MIME-TYPES">MIME-TYPES</a>] IANA, "MIME Media Types" registry, available from
<a href="http://www.iana.org">http://www.iana.org</a>.
<span class="grey">Harding Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5402">RFC 5402</a> Compressed Data in an Internet EDI Message February 2010</span>
[<a id="ref-RFC1847">RFC1847</a>] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", <a href="./rfc1847">RFC 1847</a>, October 1995.
[<a id="ref-RFC2045">RFC2045</a>] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", <a href="./rfc2045">RFC 2045</a>, November 1996.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC5322">RFC5322</a>] Resnick, P., Ed., "Internet Message Format", <a href="./rfc5322">RFC 5322</a>,
October 2008.
[S/MIME3.1] Ramsdell, B. and S. Turner, "Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification", <a href="./rfc5751">RFC 5751</a>, January 2010.
[<a id="ref-XMLTYPES">XMLTYPES</a>] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", <a href="./rfc3023">RFC 3023</a>, January 2001.
[<a id="ref-COMPRESSED-DATA">COMPRESSED-DATA</a>]
Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", <a href="./rfc3274">RFC 3274</a>, June
2002.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
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:
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
Harding Informational [Page 7]
</pre>
|
