idnits 2.17.1 draft-ietf-ediint-compression-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 355. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 27, 2008) is 5721 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1847' is defined on line 289, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (ref. 'XMLTYPES') (Obsoleted by RFC 7303) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Terry Harding 2 draft-ietf-ediint-compression-12.txt Axway 3 Expires: February 27, 2009 August 27, 2008 4 Intended Status: Informational 6 Compressed Data within an Internet EDI Message 8 Status of this memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document explains the rules and procedures for utilizing 33 compression (RFC 3274) within an Internet EDI (Electronic 34 Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, 35 and 4823. 37 1. Introduction 39 Historically, electronic messages produced by systems following the 40 guidelines as outlined in the IETF EDIINT working group 41 specifications AS1[AS1], AS2[AS2] and AS3[AS3], did not have a way 42 to provide a standardized transport neutral mechanism for 43 compressing large payloads. However, with the development of 44 RFC 3274 - Compressed Data Content Type for Cryptographic Message 45 Syntax (CMS), we now have a transport neutral mechanism for 46 compressing large payloads. 48 A typical EDIINT 'AS' message is a multi-layered MIME message, 49 consisting of one or more of the following, payload layer, signature 50 layer and/or the encryption layer. When an 'AS' message is received 51 a Message Integrity Check(MIC) value must be computed based upon 52 defined rules within the EDIINT 'AS' RFCs and returned to the sender 53 Compressed Data within an Internet EDI Message February 2009 55 of the message via an Message Disposition Notification(MDN). 57 The addition of a new compression layer will require this document to 58 outline new procedures for building/layering 'AS' messages and 59 computing a MIC value that is returned in the MDN receipt. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 62 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 63 "OPTIONAL" in this document are to be interpreted as described in 64 [RFC2119]. 66 2. Compressed Data MIME Layer 68 The compressed-data CMS(Cryptographic Message Syntax) MIME entity 69 as described in [COMPRESSED-DATA] may encapsulate a MIME entity 70 which consists of either an unsigned or signed business document. 72 Implementers are to follow the appropriate specifications identified 73 under "References" in [MIME-TYPES], for the type of object being 74 packaged. For example, to package an XML object, the MIME media 75 type of "application/xml" is used in the Content-type MIME header 76 field and the specifications for enveloping the object are 77 contained in [XMLTYPES]; 79 MIME entity example: 81 Content-type: application/xml; charset="utf-8" 83 84 86 The MIME entity will be compressed using [ZLIB] and placed inside 87 a CMS compressed-data object as outlined in [COMPRESSED-DATA]. The 88 compressed data object will be MIME encapsulated according to details 89 outlined in [S/MIME3.1], RFC 3851, Section 3.5. 91 Example: 93 Content-Type: application/pkcs7-mime; smime-type=compressed-data; 94 name=smime.p7z 95 Content-Transfer-Encoding: base64 96 Content-Disposition: attachment; filename=smime.p7z 98 MIAGCyqGSIb3DQEJEAEJoIAwgAIBADANBgsqhkiG9w0BCRADCDCABgkqhkiG9w0BBwGg 99 Hnic7ZRdb9owFIbvK/k/5PqVYPFXGK12YYyboVFASSp1vQtZGiLRACZE49/XHoUW7S/0 100 fU5ivWnasml72XFb3gb5druui7ytN803M570nii7C5r8tfwR281hy/p/KSM3+jzH5s3+ 101 P3VT3QbLusnt8WPIuN5vN/vaA2+DulnXTXkXvNTr8j8ouZmkCmGI/UW+ZS/C8zP0bz2d 102 UEk2M8mlaxjRMByAhZTj0RGYg4TvogiRASROsZgjpVcJCb1KV6QzQeDJ1XkoQ5Jm+C5P 103 v+ORAcshOGeCcdFJyfgFxdtCdEcmOrbinc/+BBMzRThEYpwl+jEBpciSGWQkI0TSlREm 104 SGLuESm/iKUFt1y4XHBO2a5oq0IKJKWLS9kUZTA7vC5LSxYmgVL46SIWxIfWBQd6Adrn 105 vGxVibLqRCtIpp4g2qpdtqK1LiOeolpVK5wVQ5P7+QjZAlrh0cePYTx/gNZuB9Vhndtg 106 W9ogK+3rnmg3YWygnTuF5GDS+Q/jIVLnCcYZFc6Kk/+c80wKwZjwdZIqDYWRH68MuBQS 107 Compressed Data within an Internet EDI Message February 2009 109 3CAaYOBNJMliTl0X7eV5DnoKIFSKYdj3cRpD/cK/JWTHJRe76MUXnfBW8m7Hd5zhQ4ri 110 +kV1/3AGSlJ32bFPd2BsQD8uSzIx6lObkjdz95c0AAAAAAAAAAAAAAAA 112 Note: Content-Transfer-Encoding of base64 would only be required 113 if the compressed-data MIME bodypart is transferred via a 7-bit 114 protocol like SMTP and is visible in the outer layer of the 115 MIME message. If the compressed-data MIME bodypart is placed 116 inside of an encrypted MIME bodypart, content-transfer-encoding 117 would not be required on the compressed-data MIME bodypart, but 118 would be required on the encrypted MIME bodypart. 120 3. Structure of an EDI MIME compressed message 122 When compressing a document which will be signed, the application 123 MAY compress the inner most MIME body before signing, see Section 124 3.2 and 3.5 or MAY compress the outer multipart/signed MIME 125 body, see Section 3.3 and 3.6 but MUST NOT do both within 126 the same document. The receiving application MUST support both 127 methods of compression when unpackaging an inbound document. 129 Note: The following sections 3.1 - 3.6 show the individual 130 layers of a properly formatted EDIINT MIME message with a compressed 131 data layer. Please refer to the appropriate RFCs for the proper 132 construction of the resulting MIME message. 134 3.1 No encryption, no signature 136 -RFC2822/2045 137 -[COMPRESSED-DATA](application/pkcs7-mime) 138 -[MIME-TYPES](application/xxxxxxx)(compressed) 140 This section shows the layers of an unsigned, unencrypted compressed 141 message. The first line indicates that the MIME message conforms to 142 RFCs 2822 and RFC 2045 with a Content-Type of application/pkcs7-mime. 143 Within the pkcs7-mime entity is a compressed MIME entity containing 144 the electronic business document. 146 3.2 No encryption, signature 148 -RFC2822/2045 149 -[RFC1847] (multipart/signed) 150 -[COMPRESSED-DATA](application/pkcs7-mime) 151 -[MIME-TYPES](application/xxxxxxx)(compressed) 152 -RFC3851 (application/pkcs7-signature) 154 This section shows the layers of a signed, unencrypted compressed 155 message where the payload is compressed before being signed. 157 3.3 No encryption, signature 159 -RFC2822/2045 160 Compressed Data within an Internet EDI Message February 2009 162 -[COMPRESSED-DATA](application/pkcs7-mime) 163 -[RFC1847] (multipart/signed)(compressed) 164 -[MIME-TYPES](application/xxxxxxx)(compressed) 165 -RFC3851 (application/pkcs7-signature)(compressed) 167 This section shows the layers of a signed, unencrypted compressed 168 message where a signed payload is compressed. 170 3.4 Encryption, no signature 172 -RFC2822/2045 173 -RFC3851 (application/pkcs7-mime) 174 -[COMPRESSED-DATA](application/pkcs7-mime) (encrypted) 175 -[MIME-TYPES](application/xxxxxxx)(compressed)(encrypted) 177 This section shows the layers of an unsigned, encrypted compressed 178 message where payload is compressed before it is encrypted. 180 3.5 Encryption, signature 182 -RFC2822/2045 183 -RFC3851 (application/pkcs7-mime) 184 -[RFC1847] (multipart/signed) (encrypted) 185 -[COMPRESSED-DATA](application/pkcs7-mime) (encrypted) 186 -[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted) 187 -RFC3851 (application/pkcs7-signature) (encrypted) 189 This section shows the layers of an signed, encrypted compressed 190 message where the payload is compressed before being signed 191 and encrypted. 193 3.6 Encryption, signature 195 -RFC2822/2045 196 -RFC3851 (application/pkcs7-mime) 197 -[COMPRESSED-DATA](application/pkcs7-mime) (encrypted) 198 -[RFC1847] (multipart/signed) (compressed)(encrypted) 199 -[MIME-TYPES](application/xxxxxxx) (compressed)(encrypted) 200 -RFC3851 (application/pkcs7-signature)(compressed)(encrypted) 202 This section shows the layers of an signed, encrypted compressed 203 message where the payload is compressed before being signed 204 and encrypted. 206 4. MIC Calculations For Compressed Messages Requesting Signed Receipts 208 4.1 MIC Calculation For Signed Message 210 For any signed message, the MIC to be returned is calculated over 211 the same data that was signed in the original message as per [AS1]. 212 The signed content will be a mime bodypart that contains either 213 compressed or uncompressed data. 215 Compressed Data within an Internet EDI Message February 2009 217 4.2 MIC Calculation For Encrypted, Unsigned Message 219 For encrypted, unsigned messages, the MIC to be returned is 220 calculated over the uncompressed data content including all 221 MIME header fields and any applied Content-Transfer-Encoding. 223 4.3 MIC Calculation For Unencrypted, Unsigned Message 225 For unsigned, unencrypted messages, the MIC is calculated 226 over the uncompressed data content including all MIME header 227 fields and any applied Content-Transfer-Encoding. 229 5. Error Disposition Modifier 231 For a received message where a receipt has been requested 232 and decompression fails, the following disposition modifier will be 233 returned in the signed MDN. 235 "Error: decompression-failed" - the receiver could not decompress 237 6. EDIINT Version Header Field 239 Any application that supports the compression methods outlined within 240 this document MUST use a version identifier value of "1.1" or greater 241 within the AS2 or AS3 Version header field as describe in [AS2] and 242 [AS3]. 244 7. Compression Formats 246 Implementations MUST support ZLIB [ZLIB] which utilizes 247 DEFLATE[DEFLATE]. 249 8. Security Considerations 251 This document is not concerned with security, except for any 252 security concerns mentioned in the referenced RFCs. 254 9. IANA Considerations 256 This document has no actions for IANA. 258 Author's Addresses 260 Terry Harding 261 Axway 262 Scottsdale, Arizona, USA 263 tharding@us.axway.com 265 References 267 Normative References 268 Compressed Data within an Internet EDI Message February 2009 270 [AS1] T. Harding, R. Drummond, C. Shih, MIME-based Secure Peer-to-Peer 271 Business Data Interchange over the Internet, RFC 3335, Sept 2002 273 [AS2] D. Moberg, R. Drummond, MIME-Based Secure Peer-to-Peer Business 274 Data Interchange Using HTTP, Applicability Statement 2 (AS2), 275 RFC 4130, July 2005. 277 [AS3] T. Harding, R. Scott, FTP Transport for Secure Peer-to-Peer 278 EDI over the Internet, RFC 4823, May 2007. 280 [ZLIB] RFC1950 ZLIB Compressed Data Format Specification version 3.3, 281 P.Deutsch and J-L Gailly, May 1996. 283 [DEFLATE] RFC1951 DEFLATE Compressed Data Format Specification version 284 1.3, P.Deutsch, May 1996. 286 [MIME-TYPES] "Media Types," http://www.isi.edu/in- 287 notes/iana/assignments/media-types/media-types. 289 [RFC1847] Security Multiparts for MIME: Multipart/Signed and 290 Multipart/Encrypted, J. Galvin, S. Murphy, S. Crocker, 291 N. Freed RFC 1847, October 1995. 293 [RFC2119] Key Words for Use in RFC's to Indicate Requirement Levels, 294 S.Bradner, March 1997. 296 [S/MIME3.1]S/MIME Version 3.1 Message Specification, B.Ramsdell, 297 July 2004. RFC 3851 299 [XMLTYPES] M. Murata, S. St.Laurent, D. Kohn, 300 "XML Media Types", RFC 3023, January 2001. 302 [COMPRESSED-DATA] Compressed Data Content Type for Cryptographic 303 Message Syntax (CMS), P. Gutmann, RFC 3274, 304 June 2002. 306 Acknowledgements 308 A number of the members of the EDIINT Working Group have also worked 309 very hard and contributed to this document. The following people 310 have made direct contributions to this document. 312 David Fischer, Dale Moberg, Robert Asis and everyone involved in the 313 AS1, AS2 Interop testing during 2002. 315 Compressed Data within an Internet EDI Message February 2009 317 Copyright Statement 319 Copyright (C) The IETF Trust (2008). 321 This document is subject to the rights, licenses and restrictions 322 contained in BCP 78, and except as set forth therein, the authors 323 retain all their rights. 325 This document and the information contained herein are provided on an 326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 328 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 329 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 330 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 333 Intellectual Property 335 The IETF takes no position regarding the validity or scope of any 336 Intellectual Property Rights or other rights that might be claimed to 337 pertain to the implementation or use of the technology described in 338 this document or the extent to which any license under such rights 339 might or might not be available; nor does it represent that it has 340 made any independent effort to identify any such rights. Information 341 on the procedures with respect to rights in RFC documents can be 342 found in BCP 78 and BCP 79. 344 Copies of IPR disclosures made to the IETF Secretariat and any 345 assurances of licenses to be made available, or the result of an 346 attempt made to obtain a general license or permission for the use of 347 such proprietary rights by implementers or users of this 348 specification can be obtained from the IETF on-line IPR repository at 349 http://www.ietf.org/ipr. 351 The IETF invites any interested party to bring to its attention any 352 copyrights, patents or patent applications, or other proprietary 353 rights that may cover technology that may be required to implement 354 this standard. Please address the information to the IETF at 355 ietf-ipr@ietf.org. 357 Expires February 27, 2009