idnits 2.17.1 draft-ietf-ediint-as3-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 26. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 33. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 8. The "failed" disposition type MAY NOT be used for the situation in which there is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the MDN is being sent under user configurable control, then the first part of the "disposition-mode" should be set to "manual-action". Since a request for a signed receipt should always be honored, the user MUST not be allowed to configure the UA to not send a signed receipt when the sender requests one. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The second part of the "disposition-mode" is set to "MDN-sent-manually" if the user gave explicit permission for the MDN to be sent. Again, the user MUST not be allowed to explicitly refuse to send a signed receipt when the sender requests one. The second part of the "disposition-mode" is set to "MDN-sent-automatically" whenever the EDI UA sends the MDN automatically, regardless of whether the sending was under a user's, administrator's, or under software control. -- 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 (January 2006) is 6673 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FTP' is mentioned on line 646, but not defined == Missing Reference: 'SFTP' is mentioned on line 651, but not defined == Missing Reference: 'MIME' is mentioned on line 699, but not defined == Missing Reference: 'S' is mentioned on line 842, but not defined == Missing Reference: 'R' is mentioned on line 842, but not defined == Missing Reference: 'AS3-Message' is mentioned on line 1281, but not defined == Missing Reference: 'AS3-MDN' is mentioned on line 841, but not defined == Unused Reference: '8' is defined on line 1580, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1595, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1598, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2298 (ref. '6') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 821 (ref. '8') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2630 (ref. '9') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2633 (ref. '10') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 2632 (ref. '11') (Obsoleted by RFC 3850) ** Obsolete normative reference: RFC 1892 (ref. '12') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 2246 (ref. '13') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 822 (ref. '14') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2822 (ref. '15') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2376 (ref. '16') (Obsoleted by RFC 3023) == Outdated reference: A later version (-12) exists of draft-ietf-ediint-compression-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ediint-compression (ref. '18') Summary: 14 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EDIINT Working Group Terry Harding 2 Internet draft Richard Scott 3 Expires: August 2006 5 January 2006 7 FTP Transport for Secure Peer-to-Peer 8 Business Data Interchange over the Internet 10 draft-ietf-ediint-as3-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 The IETF takes no position regarding the validity or scope of any 20 Intellectual Property Rights or other rights that might be claimed to 21 pertain to the implementation or use of the technology described in 22 this document or the extent to which any license under such rights 23 might or might not be available; nor does it represent that it has 24 made any independent effort to identify any such rights. Information 25 on the procedures with respect to rights in RFC documents can be 26 found in BCP 78 and BCP 79. 28 Copies of IPR disclosures made to the IETF Secretariat and any 29 assurances of licenses to be made available, or the result of an 30 attempt made to obtain a general license or permission for the use of 31 such proprietary rights by implementers or users of this 32 specification can be obtained from the IETF on-line IPR repository at 33 http://www.ietf.org/ipr. 35 The IETF invites any interested party to bring to its attention any 36 copyrights, patents or patent applications, or other proprietary 37 rights that may cover technology that may be required to implement 38 this standard. Please address the information to the IETF at 39 ietf-ipr@ietf.org. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that other 43 groups may also distribute working documents as Internet-Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress. 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 Abstract 58 This Applicability Statement (AS) describes how to exchange structured 59 business data securely using the File Transfer Protocol (FTP) for XML, 60 Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or 61 other data used for business-to-business data interchange for which 62 MIME packaging can be accomplished using standard MIME content-types. 63 Authentication and data confidentiality are obtained by using 64 Cryptographic Message Syntax (S/MIME) security body parts. 65 Authenticated acknowledgements employ multipart/signed replies to the 66 original message. 68 Table of Contents 70 1. Introduction 71 2. Overview 72 2.1 Overall operations 73 2.2 Purpose of a security guideline for MIME EDI 74 2.3 Definitions 75 2.4 Operational assumptions and options 76 2.4.1 EDI process assumptions 77 2.4.2 Process options 78 2.4.2.1 Security options 79 2.4.2.2 Compression options 80 3. Referenced RFCs 81 3.1 RFC 959 File Transfer Protocol 82 3.2 RFC 2228 FTP Security Extensions 83 3.3 RFC 1847 MIME Security Multiparts 84 3.4 RFC 1892 Multipart/report 85 3.5 RFC 1767 EDI Content 86 3.6 RFC 2045, 2046, 2049: MIME 87 3.7 RFC 2298 Message Disposition Notification 88 3.8 RFC 2633, 2630: S/MIME Version 3 Message Specifications 89 3.9 RFC 2632 S/MIME Version 3 Certificate Handling 90 3.10 RFC 3274 Compressed Data Content for Cryptographic Message 91 Syntax 92 3.11 RFC 3023 XML Media Types 93 4. Structure of an AS3 message 94 4.1 Introduction 95 4.2 Structure of EDI MIME message 96 5. AS3-specific headers 97 5.1 AS3-From and AS3-To headers 98 5.2 AS3-Version header 99 6. FTP Considerations 100 6.1 FTP Security Requirements 101 6.2 Large File Transfers 102 6.3 MIME Considerations for FTP 103 6.3.1 Required/Optional Headers 104 6.3.2 Content-Transfer-Encoding Not Used 105 6.3.3 Epilogue Must be Empty 106 6.3 Modification of MIME or other headers or parameters used 107 6.3.1 Required/Optional Headers 108 6.3.2 Content-Transfer-Encoding Not Used 109 6.3.3 Epilogue Must Be Empty 110 6.3.4 Message-Id and Original-Message-Id 111 7. Structure and Processing of an MDN Message 112 7.1 Introduction 113 7.2 Message Disposition Notifications (MDN) 114 7.3 Requesting a signed receipt 115 7.3.1 Signed receipt considerations 116 7.4 MDN Format 117 7.4.1 AS3-MDN General Formats 118 7.4.2 AS3-MDN Construction 119 7.4.3 AS3-MDN Fields 120 7.4.4 Additional AS3-MDN Programming Notes 121 7.5 Disposition Mode, Type, and Modifier 122 7.5.1 Disposition Mode Overview 123 7.5.2 Successful Processing Status Indications 124 7.5.3 Unsuccessful Processed Content 125 7.5.4 Unsuccessful Non-Content Processing 126 7.5.5 Processing Warnings 127 8. Public key certificate handling 128 9. Security Considerations 129 10. Acknowledgements 130 11. References 131 12. Authors' Addresses 133 Appendix 134 A. Message Examples 136 1. Introduction 138 Previous work on Internet EDI focused on specifying MIME content types 139 for EDI data [2] and extending this work to support secure EC/EDI 140 transport over SMTP [5]. This document expands on RFC 1767 to specify 141 a comprehensive set of data security features, specifically data 142 privacy, data integrity, authenticity, non-repudiation of origin and 143 non-repudiation of receipt over FTP. This document also recognizes 144 contemporary RFCs and is attempting to "re-invent" as little as 145 possible. While this document focuses on EDI data, any other data type 146 describable in a MIME format are also supported. 148 Internet MIME based EDI can be accomplished by using and complying 149 with the following RFC's and Internet drafts: 151 -RFC 959 File Transfer Protocol 152 -RFC 2228 FTP Security Extensions 153 -RFC 1767 EDI Content Type 154 -RFC 3023 XML Media Types 155 -RFC 1847 Security Multiparts for MIME 156 -RFC 1892 Multipart/Report 157 -RFC 2045 to 2049 MIME RFC's 158 -RFC 2298 Message Disposition Notification 159 -RFC 2630, 2632, 2633: S/MIME v3 Specifications 160 -RFC 3274 Compressed Data Content for Cryptographic Message 161 Syntax 162 -draft-murray-auth-ftp-ssl-16.txt 163 -draft-ietf-ediint-compression-02.txt 165 Our intent here is to define clearly and precisely how these are used 166 together, and what is required by user agents to be compliant with 167 this document. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119. 173 2.0 Overview 175 2.1 Overall Operations 177 A FTP upload operation is used to send appropriately-packaged EDI, 178 XML, or other business data. The receiving application will poll 179 the FTP server for inbound messages, unpackage and handle the message 180 data and generate a reply for the originator that contains a 181 message disposition acknowledgement within a multipart/report that is 182 signed or unsigned. This request/reply transactional interchange 183 provides secure, reliable, and authenticated transport for EDI or 184 other business data using FTP. The security protocols and structures 185 used also support auditable records of these transmissions. 187 2.2 Purpose of a security guideline for MIME EDI 189 The purpose of these specifications is to ensure interoperability 190 between B2B Electronic Commerce user agents, invoking some or all of 191 the commonly expected security features. This document is also NOT 192 limited to strict EDI use, but applies to any electronic commerce 193 application where business data needs to be exchanged over the 194 Internet in a secure manner. 196 2.3 Definitions 198 2.3.1. Terms 200 EDI Electronic Data Interchange 202 EC Business to Business Electronic Commerce 204 B2B Business to Business 206 Receipt The functional message that is sent from a 207 receiver to a sender to acknowledge receipt of 208 an EDI/EC interchange. 210 Signed Receipt A receipt containing a digital signature. 212 Message Disposition The Internet messaging format used to convey a 213 Notification (MDN) receipt. This term is used interchangeably with 214 receipt. A MDN is a receipt. 216 Non-repudiation of NRR is a "legal event" that occurs when the 217 receipt (NRR) original sender of an EDI/EC interchange has 218 verified the signed receipt coming back from the 219 receiver. NRR IS NOT a functional or a technical 220 message. 222 S/MIME A format and protocol for adding Cryptographic 223 signature and/or encryption services to Internet 224 MIME messages. 226 NOTE: While the S/MIME specification describes 227 more than one format for a signed message, 228 all signed messages or receipts used with 229 AS3 MUST utilize the multipart/signed 230 format. 232 SHA-1 A secure, one-way hash algorithm used in 233 conjunction with digital signature. SHA-1 is the 234 recommend algorithm for AS3. 236 MD5 A secure, one-way hash algorithm used in 237 conjunction with digital signature. This 238 algorithm is acceptable but not recommended 239 due to its short key length and known weaknesses. 241 MIC The message integrity check (MIC) is a 242 representation of the message digest, which 243 results from the application of the selected hash 244 algorithm to the content to be signed. Of 245 particular interest is the the digital signature, 246 which includes an encrypted copy of the digest. 247 Additionally, an MDN containing a 248 Received-Content-MIC" header will also contain 249 (as that header's value) a base-64 encoded 250 representation of the digest. 252 User Agent (UA) The application that handles and processes the 253 AS3 request. 255 STL Secure Transmission Loop, described in the next 256 section 258 2.3.2 The Secure Transmission Loop 260 This document's focus is on the formats and protocols for exchanging 261 EDI/EC content to which security services have been applied using 262 the File Transmission Protocol (FTP) as the transport. 264 The "Secure Transmission Loop" (STL) comprises the following two 265 steps: 267 a) The originator sends a signed and encrypted document with a 268 request for a signed receipt. 270 b) The recipient decrypts the document, verifies the signature, 271 and returns a signed receipt to the sender. 273 In other words, the following events occur during the execution of 274 the STL: 276 - The organization sending EDI/EC data signs and encrypts the data 277 using S/MIME. In addition, the message will request a signed 278 receipt to be returned to the sender of the message. 280 - The receiving organization decrypts the message and verifies the 281 signature, resulting in verified integrity of the data and 282 authenticity of the sender. 284 - The receiving organization then returns a signed receipt, as 285 requested to the sending organization in the form of a message 286 disposition notification. This signed receipt will contain the 287 hash of the signature from the received message, indicating to 288 the sender that the received message was verified and/or 289 decrypted properly. 291 The above describes functionality which, if implemented, will 292 satisfy all security requirements and provide non-repudiation of 293 receipt for the exchange. While trading partners will usually want 294 to utilize the STL, this specification does not require it. 296 2.3.3 Definition of Receipts 298 The term used for both the functional activity and the message for 299 acknowledging delivery of an EDI/EC interchange is "receipt" or 300 "signed receipt". The term receipt is used if the acknowledgment 301 is for an interchange resulting in a receipt which is NOT signed. 302 The term signed receipt is used if the acknowledgment is for an 303 interchange resulting in a receipt which IS signed. A term often 304 used in combination with receipts is non-repudiation of receipt. 305 NRR refers to a legal event which occurs only when the original 306 sender of an interchange has verified the signed receipt coming back 307 from the recipient of the message. Note that NRR is not possible 308 without signatures. 310 For additional information on formatting and processing receipts 311 in AS3, refer to section 7. 313 2.4 Operational assumptions and options 315 2.4.1 EDI/EC process assumptions 317 - Encrypted object is an EDI/EC Interchange 319 This specification assumes that a typical EDI/EC interchange is the 320 lowest level object that will be subject to the application of 321 security services. 323 Specifically, for EDI ANSI X12, the entire document (including 324 the ISA and IEA segments) is the atom to which security is applied. 325 For EDIFACT, the corresponding definition includes segments UNA/UNB 326 and UNZ. In other words, EDI/EC interchanges including envelope 327 segments remain intact and unreadable during secure transport. 329 - EDI envelope headers are encrypted 331 Congruent with the above statement, EDI envelope headers are 332 NOT visible in the MIME package. In order to optimize routing 333 from existing commercial EDI networks (called Value Added Networks 334 or VANs) to the Internet, work may need to be done in the future to 335 define ways to extract some elements of the envelope to make 336 them visible; however, that is beyond the scope of this 337 specification. 339 - X12.58 and UN/EDIFACT security considerations 341 The most common EDI standards bodies, ANSI X12 and EDIFACT, have 342 defined internal provisions for security. X12.58 is the security 343 mechanism for ANSI X12 and AUTACK provides security for EDIFACT. 344 This specification DOES NOT dictate use or non-use of these 345 security standards. They are both fully compatible, though possibly 346 redundant, with this specification. 348 2.4.2 Process options 350 2.4.2.1 Security options 352 - Encrypted or un-encrypted data 354 This specification allows for EDI/EC message exchange where the 355 EDI/EC data can be either un-protected or protected by means of 356 encryption. 358 - Signed or unsigned data 360 This specification allows for EDI/EC message exchange with or 361 without digital signature of the original EDI transmission. 363 - Use of receipt or not 365 This specification allows for EDI/EC message transmission with or 366 without a request for receipt notification. If a signed receipt 367 notification is requested however, a MIC value is REQUIRED as 368 part of the returned receipt, unless an error condition occurs 369 which results in the inability to compute a valid digest. (Such a 370 case would result, for instance, if an encrypted message could not 371 be decrypted.) Under such circumstances, an unsigned receipt (MDN) 372 SHOULD be returned with the correct "disposition modifier" error 373 value. 375 - Security Formatting 377 This specification relies on the guidelines set forth in 378 RFCs 2630 [9] and 2633 [10]. The first of these RFCs describes the 379 Cryptograpic Message Syntax (CMS) and the second contains the 380 S/MIME Version 3 Message Specification describing a MIME container 381 for CMS objects. Whenever the term S/MIME is used in this 382 document, it refers to Version 3 as described therein. 384 - Hash function, message digest choices 386 When a signature is used, it is RECOMMENDED that the SHA-1 hash 387 algorithm be used for all outgoing messages; however, both MD5 388 and SHA-1 MUST be supported for incoming messages. 390 - Permutation Summary 392 In summary, the following twelve security permutations are possible 393 in any given trading relationship: 395 1. Sender sends un-encrypted data, does NOT request a receipt. 397 2. Sender sends un-encrypted data, requests an unsigned receipt. 398 The receiver sends back the unsigned receipt. 400 3. Sender sends un-encrypted data, requests a signed receipt. The 401 receiver sends back the signed receipt. 403 4. Sender sends encrypted data, does NOT request a receipt. 405 5. Sender sends encrypted data, requests an unsigned receipt. The 406 receiver sends back the unsigned receipt. 408 6. Sender sends encrypted data, requests a signed receipt. The 409 receiver sends back the signed receipt. 411 7. Sender sends signed data, does NOT request a receipt. 413 8. Sender sends signed data, requests an unsigned receipt. 414 Receiver sends back the unsigned receipt. 416 9. Sender sends signed data, requests a signed receipt. Receiver 417 sends back the signed receipt. 419 10. Sender sends encrypted and signed data, does NOT request a 420 receipt. 422 11. Sender sends encrypted and signed data, requests an unsigned 423 receipt. Receiver sends back the unsigned receipt. 425 12. Sender sends encrypted and signed data, requests a signed 426 receipt. Receiver sends back the signed receipt. This case 427 represents the Secure Transmission Loop described above. 429 2.4.2.2 Compression options 431 The AS3 specification supports compression of transmitted data 432 directly through the application of RFC 3274. Implementation 433 details may be found in that RFC and in Harding's draft, 434 "Compressed Data for EDIINT", currently on a parallel standards 435 track. 437 3. Referenced RFC's and their contribution 439 3.1 RFC 959: File Transfer Protocol [3] 441 RFC 959 specifies how data is transferred using the File Transfer 442 Protocol (FTP) 444 3.2 RFC 2228: FTP Security Extensions [4] 445 This RFC describes a framework for providing security services to 446 FTP. 448 3.3 RFC 1847: MIME Security Multiparts [7] 450 This document defines security multiparts for MIME: 451 multipart/encrypted and multipart/signed. 453 3.4 RFC 1892: Multipart/report [12] 455 RFC 1892 defines the use of the multipart/report content type, upon 456 which RFC 2298 builds to define the Message Disposition Notification. 458 3.5 RFC 1767: EDI Content [2] 460 This RFC defines the use of content type "application" for ANSI X12 461 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually 462 defined EDI (application/EDI-Consent). 464 3.6 RFC 2045, 2046, and 2049: MIME [1] 466 These are the basic MIME standards, upon which all MIME related 467 RFCs build, including this one. Key contributions include definition 468 of "content type", "sub-type" and "multipart", as well as encoding 469 guidelines, which establishes 7-bit US-ASCII as the canonical 470 character set to be used in Internet messaging. 472 3.7 RFC 2298: Message Disposition Notification [6] 474 This Internet RFC defines how a Message Disposition Notification 475 (MDN)is requested, as well as the format and syntax of the MDN. The 476 MDN is the vehicle used by this specification to provide both signed 477 and unsigned receipts. 479 3.8 RFC 2630:CMS[9] and 2633 S/MIME Version 3 Message 480 Specifications[10]. 482 This specification describes how MIME shall carry Cryptographic 483 Message Syntax (CMS) Objects. 485 3.9 RFC 2632: S/MIME Version 3 Certificate Handling [11] 487 RFC 2632 describes certificate handling in the context of CMS and 488 S/MIME. 490 3.10 RFC 3274: Compressed Data Content Type for Cryptographic Message 491 Syntax (CMS) [17] 493 This specification provides a mechanism to wrap compressed data 494 within a CMS object. 496 3.11 RFC 3023: XML Media Types [16] 498 This RFC defines the use of content type "application" for XML. Note 499 that while conforming implementations SHOULD support the expanded 500 syntax that RFC 3023 introduces for the "+xml" suffix, no support for 501 external parsed entity types is anticipated (as it adds significant 502 complexity to signature processing). 504 4. Structure of an AS3 message 506 4.1 Introduction 508 The basic structure of AS3 messages comprises MIME encapsulated data 509 with both customary MIME headers and a few additional AS3-specific 510 outer headers. The structures below are described hierarchically in 511 terms of which RFCs have been applied to form the specific structure. 512 The reader is referred directly to the referenced RFCs for 513 implementation details. 514 Any additional restrictions imposed by this AS are specifically 515 discussed in the sections which follow. 517 4.2 Structure of an Internet EDI MIME message 519 No encryption, no signature 521 -RFC822/2045 522 -RFC1767/RFC2376 (application/EDIxxxx or /xml) 524 No encryption, signature 526 -RFC822/2045 527 -RFC1847 (multipart/signed) 528 -RFC1767/RFC2376 (application/EDIxxxx or /xml) 529 -RFC2633 (application/pkcs7-signature) 531 Encryption, no signature 533 -RFC822/2045 534 -RFC2633 (application/pkcs7-mime) 535 -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) 537 Encryption, signature 539 -RFC822/2045 540 -RFC2633 (application/pkcs7-mime) 541 -RFC1847 (multipart/signed)(encrypted) 542 -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) 543 -RFC2633 (application/pkcs7-signature)(encrypted) 545 MDN, no signature 547 -RFC822/2045 548 -RFC2298 (message/disposition-notification) 550 MDN, signature 552 -RFC822/2045 553 -RFC1847 (multipart/signed) 554 -RFC2298 (message/disposition-notification) 555 -RFC2633 (application/pkcs7-signature) 557 While all MIME content types SHOULD be supported. 558 The following MIME content types MUST be supported: 560 Content-type: multipart/signed 561 Content-Type: multipart/report 562 Content-type: message/disposition-notification 563 Content-Type: application/PKCS7-signature 564 Content-Type: application/PKCS7-mime 565 Content-Type: application/EDI-X12 566 Content-Type: application/EDIFACT 567 Content-Type: application/edi-consent 568 Content-Type: application/XML 570 5. AS3-specific Headers 572 5.1 AS3-From and AS3-To headers 574 The AS3-From and AS3-To headers have been provided to assist the 575 sender and the recipient of an EC document to identify each other: 577 AS3-From: < AS3-name > 578 AS3-To: < AS3-name > 580 These headers contain textual values, described by the ABNF below, 581 identifying the sender/receiver of a data exchange. A value may 582 be company specific (e.g., a DUNS number), or it may be simply some 583 string mutually acceptable to both trading partners used to identify 584 each to the other. 586 AS3-text = "!" / ; printable ASCII characters 587 %d35-91 / ; except double-quote (%d34) 588 %d93-126 ; or backslash (%d92) 590 AS3-qtext = AS3-text / SP ; allow space only in quoted text 592 AS3-quoted-pair = "\" DQUOTE / ; \" or 593 "\" "\" ; \\ 595 AS3-quoted-name = DQUOTE 1*128( AS3-qtext / 596 AS3-quoted-pair) DQUOTE 598 AS3-atomic-name = 1*128AS3-text 600 AS3-name = AS3-atomic-name / AS3-quoted-name 602 The AS3-From header value and the AS3-To header value MUST each be an 603 AS3-name comprising 1 to 128 printable ASCII characters. The header 604 MUST NOT be folded, and the value for each of these headers 605 is case-sensitive. 607 The AS3-quoted-name SHOULD be used only if the AS3-name does not 608 conform to AS3-atomic-name. 610 The AS3-To and AS3-From header fields MUST be present in all AS3 611 messages and AS3 MDN's. 613 Implementations which map entities such as EDI identifiers/qualifiers 614 to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From 615 text values to a subset of the full set defined above but may not 616 extend that set. 618 If either the AS3-From or the AS3-To or the association of the two 619 header values is determined to be invalid or unknown to the receiving 620 system, the receiving system MAY respond with an unsigned MDN 621 containing an explanation of the error if the sending system 622 requested an MDN, but it is not required to return an MDN under those 623 circumstances. 625 5.2 AS3-Version header 627 The AS3-Version header is a header which is required only if the 628 value of the header is not "1.0". Its purpose is to allow systems 629 to determine which version of this specification, should the 630 specification evolve over time, the sender of a document has used to 631 package the document. A user agent MUST NOT reject a message if the 632 version header is missing. 634 AS3-Version: 1*DIGIT . 1*DIGIT 636 A version header value of "1.1" indicates an implementation can 637 support EDIINT data compression [18]. A user agent MUST NOT send 638 compressed messages to trading partners who do not use a version 639 header of "1.1" or greater. 641 6. FTP Considerations 643 6.1 FTP Security Requirements 645 FTP has long been viewed as an insecure protocol primarily because 646 of its use of cleartext authentication [FTP]. This is addressed by 647 RFC 2228, and the use of one of the security mechanisms described 648 therein is strongly encouraged. Specifically, conforming 649 implementations of AS3 SHALL employ FTP client/servers that support 650 the AUTH command described within [SFTP]. While any authentication 651 mechanism based upon [SFTP] MAY be utilized, AUTH TLS (as described 652 in [MURRAY]) MUST be supported. 654 6.2 Large file transfers 656 Large files are handled correctly by the TCP layer. However, there 657 is the mechanism for compressing data referenced in section 2.4.2.2 658 above which efficiently reduces transmission requirements for many 659 data types (including both XML and traditional EDI data.) 660 Additionally, some FTP implementations support compression as well. 662 6.3 MIME Considerations for FTP 664 6.3.1 Required/Optional Headers 666 An AS3 message MUST contain the following outer headers: 668 AS3-To 669 AS3-From 670 Date 671 Message-ID 672 Content-Type 674 An AS3 message OPTIONALLY MAY contain the following outer headers: 676 Subject 677 AS3-Version (assumed to be 1.0 if not present) 678 Content-Length 680 An AS3 message requesting a receipt MUST contain a 681 Disposition-Notification-To header and MAY contain a 682 Disposition-Notification-Options header(if the receipt is to be 683 signed) 685 Additional headers MAY be present but are ignored. 687 6.3.2 Content-Transfer-Encoding Not Used 689 FTP defines several data structures and character encodings via the 690 STRU[cture] and TYPE commands. AS3 requires the file-structure 691 (default) and the image type. The Content-Transfer-Encoding header 692 SHOULD NOT be used; if the header is present, it MUST have a value of 693 binary or 8-bit, and the absence of this header MUST NOT result in 694 transaction failure. Content transfer encoding of MIME parts within 695 the AS3 message are similarly constrained. 697 6.3.3 Epilogue Must Be Empty 699 A MIME message containing an epilogue [MIME] SHALL NOT be used. 701 6.3.4 Message-Id and Original-Message-Id 703 Message-Id and Original-Message-Id are formatted as defined in 704 section 3.6.4 of RFC2822 [15]: "<" id-left "@" id-right ">". 705 Message-Id length is a maximum of 998 characters. Message-Id 706 SHOULD be globally unique, id-right should be something unique 707 to the sending host environment (e.g. a host name). When sending 708 a message, always include the angle brackets. Angle brackets are 709 not part of the Message-Id value. 711 NOTE: When creating the Original-Message-Id header in an MDN, 712 always use the exact syntax contained in the original 713 message: do not strip or add "angle brackets". 715 7. Structure and Processing of an MDN Message 717 7.1 Introduction 719 In order to support non-repudiation of receipt, a signed receipt, 720 based on digitally signing a message disposition notification, is to 721 be implemented by a receiving trading partner's UA. The message 722 disposition notification specified by RFC 2298 is digitally signed by 723 a receiving trading partner as part of a multipart/signed MIME 724 message. 726 The following support for signed receipts is REQUIRED: 728 1) The ability to create a multipart/report; 729 where the report-type = disposition-notification. 731 2) The ability to calculate a message integrity check (MIC) on the 732 received message. The calculated MIC value will be returned to the 733 sender of the message inside the signed receipt. 735 3) The ability to create a multipart/signed content with the message 736 disposition notification as the first body part, and the signature 737 as the second body part. 739 4) The ability to return the signed receipt to the sending trading 740 partner. 742 The signed receipt is used to notify a sending trading partner that 743 requested the signed receipt that: 745 1) The receiving trading partner acknowledges receipt of the sent EC 746 Interchange. 748 2) If the sent message was signed, then the receiving trading partner 749 has authenticated the sender of the EC Interchange. 751 3) If the sent message was signed, then the receiving trading partner 752 has verified the integrity of the sent EC Interchange. 754 Regardless of whether the EDI/EC Interchange was sent in S/MIME 755 format or not, the receiving trading partner's UA MUST provide the 756 following basic processing: 758 1) If the sent EDI/EC Interchange is encrypted, then the encrypted 759 symmetric key and initialization vector (if applicable) is 760 decrypted using the receiver's private key. 762 2) The decrypted symmetric encryption key is then used to decrypt the 763 EDI/EC Interchange. 765 3) The receiving trading partner authenticates signatures in a 766 message using the sender's public key. 768 The authentication algorithm performs the following: 770 a) The message integrity check (MIC or Message Digest), is 771 decrypted using the sender's public key. 773 b) A MIC on the signed contents (the MIME header and encoded EDI 774 object, as per RFC 1767) in the message received is calculated 775 using the same one-way hash function that the sending trading 776 partner used. 778 c) The MIC extracted from the message that was sent, and the MIC 779 calculated using the same one-way hash function that the 780 sending trading partner used is compared for equality. 782 4) The receiving trading partner formats the MDN and sets the 783 calculated MIC into the "Received-content-MIC" extension field. 785 5) The receiving trading partner creates a multipart/signed MIME 786 message according to RFC 1847. 788 6) The MDN is the first part of the multipart/signed message, and the 789 digital signature is created over this MDN, including its MIME 790 headers. 792 7) The second part of the multipart/signed message contains the 793 digital signature. The "protocol" option specified in the second 794 part of the multipart/signed is as follows: S/MIME: 795 protocol = "application/pkcs7-signature" 797 8) The signature information is formatted according to S/MIME 798 specifications. The EC Interchange and the RFC 1767 MIME EDI 799 content header can actually be part of a multi-part MIME 800 content-type. When the EDI Interchange is part of a multi-part 801 MIME content-type, the MIC MUST be calculated across the entire 802 multi-part content, including the MIME headers. 804 The signed MDN, when received by the sender of the EDI Interchange 805 can be used by the sender: 807 1) As an acknowledgment that the EDI Interchange sent, was delivered 808 and acknowledged by the receiving trading partner. The receiver 809 does this by returning the original-message-id of the sent message 810 in the MDN portion of the signed receipt. 812 2) As an acknowledgment that the integrity of the EDI Interchange was 813 verified by the receiving trading partner. The receiver does this 814 by returning the calculated MIC of the received EC Interchange 815 (and 1767 MIME headers) in the "Received-content-MIC" field of the 816 signed MDN. 818 3) As an acknowledgment that the receiving trading partner has 819 authenticated the sender of the EDI Interchange. 821 4) As a non-repudiation of receipt when the signed MDN is 822 successfully verified by the sender with the receiving trading 823 partner's public key and the returned MIC value inside the MDN is 824 the same as the digest of the original message. 826 7.2 Message Disposition Notifications (MDN) 828 The AS3-MDNs are returned on a separate FTP TCP/IP 829 connection and are a response to an AS3 message. 831 The following diagram illustrates the delivery of an 832 AS3-MDN delivery: 834 AS3-MDN 836 [S] ----( connect )----> [R] [FTP Server] 837 [S] ----( send )-------> [R] [AS3-Message] 838 [S] ----( disconnect )-> [R] [FTP Server] 840 [S] <---( connect )----- [R] [FTP Server] 841 [S] <---( send )-------- [R] [AS3-MDN]] 842 [S] <---( disconnect )-- [R] [FTP Server] 844 Note: Refer to Section 7.4.4 for additional 845 programming notes. 847 7.3 Requesting a signed receipt 849 Message Disposition Notifications are requested as per RFC 2298. A 850 request that the receiving user agent issue a message disposition 851 notification is made by placing the following header into the message 852 to be sent: 854 MDN-request-header = "Disposition-notification-to" ":" ftp-url 856 This syntax is a residual of the use of MDN's in a SMTP transfer. 857 Since this specification is adjusting the functionality from SMTP to 858 FTP and retaining as much as possible from the [5] functionality, the 859 ftp-url must be present. 861 The ftp-url field is specified as an RFC 1738 862 , and while it MUST be present, 863 it may be ignored if the ftp-url points to an unknown location. If 864 the ftp-url points to an unknown location it is RECOMMENDED that the 865 mdn is returned back to a known ftp-url for the sender of the 866 received message. 868 For requesting MDN based receipts, the originator supplies the 869 required extension headers that precede the message body. 871 The header "tags" are as follows: 873 A Disposition-notification-to header is added to indicate that a 874 message disposition notification is requested. This header is 875 specified in [6]. 877 A Message-ID header is added to support message reconciliation, so 878 that an Original-Message-Id value can be returned in the body part of 879 MDN. 881 Other headers, especially "Date", SHOULD be supplied; the 882 values of these headers are often mentioned in the human-readable 883 section of a MDN to aid in identifying the original message. 885 Disposition-notification-options identifies characteristics of 886 message 888 Disposition notification in accordance with [6]. 890 EXAMPLE: 891 Disposition-notification-to: // Requests the MDN 892 ftp://host:port/inbox // Location to return MDN 893 Disposition-notification-options: // The signing options for 894 MDN 895 signed-receipt-protocol=optional, pkcs7-signature; 896 signed-receipt-micalg=optional, sha1, md5 898 Disposition-notification-options syntax: 900 Disposition-notification-options = 901 "Disposition-Notification-Options" ":" 902 disposition-notification-parameters 904 where 906 disposition-notification-parameters = 907 parameter *(";" parameter) 909 where 911 parameter = attribute "=" importance ", " 1#value" 913 where 915 importance = "required" | "optional" 917 So the Disposition-notification-options string could be: 919 signed-receipt-protocol=optional, ; 920 signed-receipt-micalg=optional, , ,...; 922 The currently supported value for is 923 "pkcs7-signature" for the S/MIME detached signature format. 925 The currently supported values for MIC algorithm 926 values are: 927 Algorithm Value 928 Used 929 -------- ------- 930 MD5 md5 931 SHA-1 sha1 933 Receiving agents SHOULD be able to recover gracefully from a 934 parameter value that they do not recognize. 936 The semantics of the "signed-receipt-protocol" parameter is as 937 follows: 939 1) The "signed-receipt-protocol" parameter is used to request a 940 signed receipt from the recipient trading partner. The 941 "signed-receipt-protocol" parameter also specifies the format in 942 which the signed receipt should be returned to the requester. 944 The "signed-receipt-micalg" parameter is a list of MIC algorithms 945 preferred by the requester for use in signing the returned receipt 946 and calculating the micalg in the Received-content-MIC header. 948 The list of MIC algorithms should be honored by the recipient from 949 left to right. Both the "signed-receipt-protocol" and the 950 "signed-receipt-micalg" option parameters are REQUIRED when 951 requesting a signed receipt. 953 2) The "importance" attribute of "Optional" is defined in the 954 RFC 2298 section 2.2 and has the following meaning: 956 Parameters with an importance of "Optional" permit a UA that does 957 not understand the particular options parameter to still generate 958 a MDN in response to a request for a MDN. A UA that does not 959 understand the "signed-receipt-protocol" parameter, or the 960 "signed-receipt-micalg" will obviously not return a signed 961 receipt. 963 The importance of "Optional" is used for the signed receipt 964 parameters because it is RECOMMENDED that an MDN be returned to 965 the requesting trading partner even if the recipient could not 966 sign it. 968 The returned MDN will contain information on the disposition of 969 the message as well as why the MDN could not be signed. See the 970 Disposition field in section 7.5 for more information. 972 Within an EDI trading relationship, if a signed receipt is expected 973 and is not returned, then the validity of the transaction must be 974 determined by the trading partners. Typically, if a signed receipt 975 is required by the trading relationship and is not received, the 976 transaction will likely not be considered valid. 978 7.3.1 Signed Receipt Considerations 980 The method used to request a receipt or a signed receipt is defined 981 in RFC 2298, "An Extensible Message Format for Message Disposition 982 Notifications". 984 The "rules" for processing a receipt-request follow: 986 1) When a receipt is requested, explicitly specifying that the receipt 987 be signed, then the receipt MUST be returned with a signature unless 988 conditions (2) or (3) below are applicable. 990 2) When a receipt is requested, explicitly specifying that the receipt 991 be signed, but the recipient cannot support either the requested 992 protocol format, or requested MIC algorithms, then either a signed or 993 unsigned receipt SHOULD be returned. 995 3) When a receipt is requested, explicitly specifying that the receipt 996 be signed, but the recipient is unable to compute the digest (e.g., 997 message was encrypted and recipient unable to decrypt), then the 998 recipient SHOULD NOT return "Received-Content-MIC" in the MDN to the 999 requestor. If the MDN sets the disposition (e.g., "processed/error: 1000 decryption-failed") appropriately, then the "Received-Content-MIC" 1001 may be returned but the value must be discarded. 1003 4) When a signature is not explicitly requested, or if the signed 1004 receipt request parameter is not recognized by the UA, then no 1005 receipt, an unsigned receipt, or a signed receipt MAY be returned 1006 by the recipient. 1008 5) If a message is received without a request for a receipt, then a 1009 receipt (signed or unsigned) MAY be returned. 1011 The "Received-content-MIC" MUST be calculated as follows: 1013 - For any signed messages, the MIC to be returned is calculated on 1014 the RFC1767 MIME header and content. Canonicalization as specified 1015 in RFC 1848 MUST be performed before the MIC is calculated, since 1016 the sender requesting the signed receipt was also REQUIRED to 1017 canonicalize. 1019 - For encrypted, unsigned messages, the MIC to be returned is 1020 calculated on the decrypted RFC 1767 MIME header and content. The 1021 content after decryption MUST be canonicalized before the MIC is 1022 calculated. 1024 - For unsigned, unencrypted messages, the MIC MUST be calculated 1025 over the message contents prior to Content-Tranfer-Encoding and 1026 without the MIME or any other RFC 822 headers, since these are 1027 sometimes altered or reordered by MTAs. 1029 7.4 MDN Format and value 1031 This section defines the format of the AS3 Message Disposition 1032 Notification (AS3-MDN). 1034 7.4.1 AS3-MDN General Formats 1036 The AS3-MDN follows the MDN specification [6] except where noted in 1037 this section. The modified entity definitions in this document use 1038 the vertical-bar character, '|', to denote a logical "OR" 1039 construction. Refer to RFC 2045 for format of MIME-message-headers. 1041 The format of the AS3-MDN is 1043 AS3-MDN = *(( MIME-message-headers | entity-headers )CRLF) 1044 CRLF 1045 AS3-MDN-body 1047 AS3-MDN-body = 1048 AS3-signed-MDN-body | AS3-unsigned-MDN-body 1050 7.4.2 AS3-MDN Construction 1052 The AS3-MDN-body is formatted as a MIME multipart/report with a 1053 report-type of "disposition-notification". 1055 When unsigned, the transfer-layer ( "outermost" ) entity-headers of 1056 the AS3-MDN contain the content-type header that specifies a 1057 content-type of "multipart/report" and parameters indicating the 1058 report-type, and the value of the outermost multipart boundary. 1060 When the AS3-MDN is signed, the transfer-layer ( "outermost" ) 1061 entity-headers of the AS3-MDN contain a content-type header that 1062 specifies a content-type of "multipart/signed" and parameters 1063 indicating the algorithm used to compute the message digest, the 1064 signature formatting protocol ( e.g. pkcs7-signature ), and the 1065 value of the outermost multipart boundary. The first part of the 1066 MIME multipart/signed message is an embedded MIME multipart/report 1067 of type "disposition-notification". The second part of the 1068 multipart/signed message contains a MIME 1069 application/pkcs7-signature message. 1071 The first part of the MIME multipart/report is a "human-readable" 1072 portion that contains a general description of the message 1073 disposition. The second part of the MIME multipart/report is a 1074 "machine-readable" portion that is defined as 1076 AS3-disposition-notification-content = 1077 [ reporting-ua-field CRLF ] 1078 [ mdn-gateway-field CRLF ] 1079 [ original-recipient-field CRLF ] 1080 final-recipient-field CRLF 1081 [ original-message-id-field CRLF ] 1082 AS3-disposition-field CRLF 1083 *( failure-field CRLF ) 1084 *( error-field CRLF ) 1085 *( warning-field CRLF ) 1086 *( extension-field CRLF ) 1087 [ AS3-received-content-MIC-field CRLF ] 1089 It is noted that several of the optional fields defined by RFC 2298 1090 and shown above are not relevant to a point-to-point transport such 1091 as FTP and would not normally appear in an AS3 MDN. 1093 7.4.3 AS3-MDN Fields 1095 The rules for constructing the AS3-disposition-notification-content 1096 are identical to the rules for constructing the 1097 disposition-notification-content as defined in section 7 of RFC 1098 2298 [6] except that the RFC 2298 disposition-field has 1099 been replaced with the AS3-disposition-field and that the 1100 AS3-received-content-MIC field has been added. The differences 1101 between the RFC 2298 disposition-field and the 1102 AS3-disposition-field are described below. Where 1103 there are differences between this document and RFC 2298, those 1104 entity names have been changed by prepending "AS3-". Entities below 1105 that do not differ from RFC 2298 are not necessarily further 1106 defined in this document. 1108 Refer to RFC 2298 for AS3-MDN entities that are not further defined 1109 in this document. 1111 AS3-disposition-field = "Disposition" ":" disposition-mode ";" 1112 AS3-disposition-type [ '/' AS3-disposition-modifier] 1114 disposition-mode = action-mode "/" sending-mode 1115 action-mode = "manual-action" | "automatic-action" 1117 sending-mode = "MDN-sent-manually" | "MDN-sent-automatically" 1119 AS3-disposition-type = "processed" | "failed" 1121 AS3-disposition-modifier = ( "error" | "warning" ) | 1122 AS3-disposition-modifier-extension 1124 AS3-disposition-modifier-extension = 1125 "error: authentication-failed" | 1126 "error: decompression-failed" | 1127 "error: decryption-failed" | 1128 "error: insufficient-message-security" | 1129 "error: integrity-check-failed" | 1130 "error: unexpected-processing-error" | 1131 "warning: " AS3-MDN-warning-description | 1132 "failure: " AS3-MDN-failure-description 1134 AS3-MDN-warning-description = *( TEXT ) 1136 AS3-MDN-failure-description = *( TEXT ) 1138 AS3-received-content-MIC-field = 1139 "Received-content-MIC" ":" encoded-message-digest 1140 "," digest-alg-id CRLF 1142 encoded-message-digest = 1143 1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' ) 0*3( '=' ) 1144 ( i.e. base64( message-digest ) ) 1146 digest-alg-id = "sha1" | "md5" 1148 The "Received-content-MIC" extension field is set after the 1149 integrity of the received message is verified. The MIC is the 1150 base64-encoded message-digest computed over the received message 1151 with a hash function. This field is required for signed receipts 1152 but optional for unsigned receipts. For details defining the 1153 specific content over which the message-digest is to be computed, 1154 see Section 7.3.1 of this document. 1156 The algorithm used to calculate the message digest MUST be the 1157 same as the "micalg" value used by the sender in the 1158 multipart/signed message. When no signature is received the 1159 message-digest MUST be calculated using the algorithm specified 1160 by the "micalg" value in the Disposition-Notification-Options 1161 header. When no signature is received and no micalg parameter is 1162 provided, then the SHA-1 algorithm MUST be used to calculate the 1163 digest. This field is set only when the contents of the message are 1164 processed successfully. This field is used in conjunction with 1165 the recipient's signature on the MDN in order for the sender to 1166 verify non-repudiation of receipt. 1168 AS3-MDN field names ( e.g. "Disposition:", "Final-Recipient:") 1169 are case-insensitive ( cf. RFC 2298, 3.1.1 ). 1171 AS3-MDN action-modes, sending-modes, AS3-disposition-types, and 1172 AS3-disposition-modifier values that are defined above, and 1173 user-supplied *( TEXT ) values are also case-insensitive. AS3 1174 implementations MUST NOT make assumptions regarding the values 1175 supplied for AS3-MDN-warning-description, 1176 AS3-MDN-failure-description nor for the values of any (optional) 1177 error, warning, or failure fields. 1179 7.4.4 Additional AS3-MDN Programming Notes 1181 1. Unlike SMTP, for FTP transactions, Original-Recipient and 1182 Final Recipient SHOULD NOT be different. The value in 1183 Original-Message-ID MUST match the original Message-ID 1184 header value. 1186 2. Refer to RFC 1892 and RFC 2298 for the formatting of the 1187 content-type entity-headers for the MDN. 1189 3. Use an action-mode of "automatic-action" when the disposition 1190 described by the disposition type was a result of an automatic 1191 action, rather than an explicit instruction by the user for 1192 this message. 1194 4. Use an action-mode of "manual-action" when the disposition 1195 described by the disposition type was a result of an explicit 1196 instruction by the user rather than some sort of automatically 1197 performed action. 1199 5. Use a sending-mode of "MDN-sent-automatically" when the MDN is 1200 sent because the UA had previously been configured to do so. 1202 6. Use a sending-mode of "MDN-sent-manually" when the user 1203 explicitly gave permission for this particular MDN to be sent. 1205 7. The sending-mode "MDN-sent-manually" is ONLY meaningful with 1206 "manual-action", not with "automatic-action". 1208 8. The "failed" disposition type MAY NOT be used for the 1209 situation in which there is some problem in processing the 1210 message other than interpreting the request for an MDN. 1211 The "processed" or other disposition type with appropriate 1212 disposition modifiers is to be used in such situations. 1214 9. An AS3 implementation MUST present to its trading partners 1215 an ftp compliant server interface where inbound documents 1216 and mdns are received. 1218 10. An AS3 implementation MUST be able to retrieve inbound 1219 messages from it's currently configured ftp server interface. 1221 Note: Programming Notes 9 and 10 do not imply any specific method 1222 for supplying the ftp server interface. But, does allow for 1223 several different types of implementations. Some vendors may 1224 choose to imbed an ftp compliant server interface within their 1225 product and others may choose to utilize off-the-shelf ftp 1226 servers to supply the required ftp server interface. Some may 1227 choose to utilize hosting services provide by their trading 1228 partner or by a third party hosting service. Whichever method 1229 is utilized, an AS3 implementation MUST support rules 9 and 1230 10. 1232 11. AS3 implementations MAY imbed an ftp server interface within 1233 their product. 1235 12. AS3 implementations MUST be configurable to allow the use of 1236 an external ftp hosting service. 1238 Note: An external ftp hosting service may be hosted by a third-party 1239 Or possibly hosted by your trading partner. 1241 13. An AS3 implementation MUST be able to send business documents 1242 and mdns to a trading partner's currently configured ftp server 1243 interface. 1245 14. An AS3 implementation may imbed ftp client code into their 1246 product or use an third-party ftp client. 1248 15. Example Configurations 1250 1. Peer to Peer 1251 TPA is using a local ftp server and TPB is using an imbedded 1252 ftp server. 1254 [A Client] ----( connect )----> [B Server] 1255 [A Client] ----( send )-------> [B Server] [AS3-Message] 1256 [A Client] ----( disconnect )-> [B Server] 1258 [A Server] <---( connect )----- [B Client] 1259 [A Server] <---( send )-------- [B Client] [AS3-MDN]] 1260 [A Server] <---( disconnect )-- [B Server] 1261 [A Client] <---( GET )--------- [A Server] 1263 2. Third Party Hosting 1264 Both parties are using the same third-party hosted ftp 1265 server. 1267 [A Client] ----( connect )----> [Hosted Server] 1268 [A Client] ----( send )-------> [Hosted Server] [AS3-Message] 1269 [A Client] ----( disconnect )-> [Hosted Server] 1270 [Hosted Server]( GET )--------> [B Client] 1272 [Hosted Server] <---( connect )----- [B Client] 1273 [Hosted Server] <---( send )-------- [B Client] [AS3-MDN]] 1274 [Hosted Server] <---( disconnect )-- [B Client] 1275 [A Client] <---( GET )--------- [Hosted Server] 1277 3. Trading Partner Hosting 1278 TPA is using the imbedded ftp server hosted by TPB. 1280 [A Client] ----( connect )----> [B Server] 1281 [A Client] ----( send )-------> [B Server] [AS3-Message] 1283 [A Client] ----( disconnect )-> [B Server] 1285 [B Server] <---( connect )----- [B Client] 1286 [B Server] <---( send )-------- [B Client] [AS3-MDN]] 1287 [B Server] <---( disconnect )-- [B Client] 1288 [A Client] <---( GET )--------- [B Server] 1290 7.5 Disposition Mode, Type, and Modifier 1292 7.5.1 Disposition Mode Overview 1294 This section will provide a brief overview of how processed, 1295 error, failure, and warnings are used. 1297 7.5.2 Successful Processing status indication 1299 When the request for a receipt or signed receipt, and the received 1300 message contents are successfully processed by the receiving EDI 1301 UA, a receipt or MDN SHOULD be returned with the 1302 "disposition-type" set to 'processed'. When the MDN is sent 1303 automatically by the EDI UA, and there is no explicit 1304 way for a user to control the sending of the MDN, then the first 1305 part of the "disposition-mode" should be set to "automatic-action". 1307 When the MDN is being sent under user configurable control, then 1308 the first part of the "disposition-mode" should be set to 1309 "manual-action". Since a request for a signed receipt should always 1310 be honored, the user MUST not be allowed to configure the UA to not 1311 send a signed receipt when the sender requests one. 1313 The second part of the "disposition-mode" is set to 1314 "MDN-sent-manually" if the user gave explicit permission for the 1315 MDN to be sent. Again, the user MUST not be allowed to explicitly 1316 refuse to send a signed receipt when the sender requests one. The 1317 second part of the "disposition-mode" is set to 1318 "MDN-sent-automatically" whenever the EDI UA sends the MDN 1319 automatically, regardless of whether the sending was under a 1320 user's, administrator's, or under software control. 1322 Since EDI content is generally handled automatically by the EDI UA, 1323 a request for a receipt or signed receipt will generally return the 1324 following in the "disposition-field": 1326 Disposition: automatic-action/MDN-sent-automatically; processed 1328 Note this specification does not restrict the use of the 1329 "disposition-mode" to just automatic actions. Manual actions are 1330 valid as long as it is kept in mind that a request for a signed 1331 receipt MUST be honored. 1333 7.5.3 Unsuccessful processed Content 1335 The request for a signed receipt requires the use of two 1336 "disposition-notification-options", which specify the protocol 1337 format of the returned signed receipt, and the MIC algorithm used 1338 to calculate the MIC over the message contents. The 1339 "disposition-field" values that should be used in the case where 1340 the message content is being rejected or ignored, for instance if 1341 the EDI UA determines that a signed receipt cannot be returned 1342 because it does not support the requested protocol format, so the 1343 EDI UA chooses not to process the message contents itself, should 1344 be specified in the MDN "disposition-field" as follows: 1346 Disposition: "disposition-mode"; failed/Failure: unsupported Format 1348 The "failed" AS3-disposition-type should be used when a failure 1349 occurs that prevents the proper generation of an MDN. 1351 For example, this disposition-type would apply if the sender of the 1352 message requested the application of an unsupported 1353 message-integrity-check (MIC) algorithm. 1355 The "failure:" AS3-disposition-modifier-extension should be used 1356 with an implementation-defined description of the failure. 1358 Further information about the failure may be contained in a 1359 failure-field. The syntax of the "failed" "disposition-type" is 1360 general, allowing the sending of any textual information along with 1361 the "failed" "disposition-type". Implementations WILL support any 1362 printable textual characters after the Failure disposition-type. 1364 For use in Internet EDI, the following "failed" values are 1365 pre-defined and MUST be supported: 1367 "Failure: unsupported format" 1368 "Failure: unsupported MIC-algorithms" 1370 7.5.4 Unsuccessful Non-Content Processing 1372 When errors occur processing the received message other than 1373 content, the "disposition-field" should be set to the "processed" 1374 "disposition-type" value and the "error" "disposition-modifier" \ 1375 value. 1377 The "error" AS3-disposition-modifier with the "processed" 1378 disposition-type should be used to indicate that an error of some 1379 sort occurred that prevented successful processing of the message. 1381 Further information may be contained in an error-field. 1383 An "error:" AS3-disposition-modifier-extension should be used to 1384 combine the indication of an error with a pre-defined description 1385 of a specific, well-known error. Further information about the 1386 error may be contained in an error-field. 1388 For use in Internet EDI, the following "error" 1389 "disposition-modifier" values are defined: 1391 "Error: decryption-failed" - the receiver could not decrypt the 1392 message contents. 1394 "Error: authentication-failed" - the receiver could not 1395 authenticate the sender. 1397 "Error: integrity-check-failed" - the receiver could not verify 1398 content integrity. 1400 "Error: insufficient-message-security" - the security level of the 1401 message did not match the 1402 agreed level between TPs. 1404 "Error: decompression-failed" - the receiver could not decompress 1405 the message contents. 1407 "Error: unexpected-processing-error" - a catch-all for any 1408 additional processing 1409 errors. 1411 An example of how the "disposition-field" would look when other 1412 than content processing errors are detected is as follows: 1414 EXAMPLE 1415 Disposition: "disposition-mode"; 1416 processed/Error: decryption-failed 1418 7.5.5 Processing Warnings 1420 Situations arise in EDI where even if a trading partner cannot be 1421 authenticated correctly, the trading partners still agree to 1422 continue processing the EDI transactions. Transaction 1423 reconciliation is done between the trading partners at a later 1424 time. In the content processing warning situations as described 1425 above, the "disposition-field' SHOULD be set to the "processed" 1426 "disposition-type" value, and the "warning" "disposition-modifier" 1427 value. 1429 The "warning" AS3-disposition-modifier should be used with the 1430 "processed" disposition-type to indicate that the message was 1431 successfully processed but that an exceptional condition occurred. 1433 Further information may be contained in a warning-field. 1435 A "warning:" AS3-disposition-modifier-extension should be used to 1436 combine the indication of a warning with an implementation-defined 1437 description of the warning. Further information about the warning 1438 may be contained in an warning-field. 1440 For use in Internet EDI, the following "warning" 1441 "disposition-modifier" values are defined: 1443 "Warning: authentication-failed, processing continued" 1445 An example of how the "disposition-field" would look when other 1446 than content processing warnings are detected is as follows: 1448 EXAMPLE 1449 Disposition: "disposition-mode"; processed/Warning: 1450 authentication-failed, processing continued 1452 8. Public key certificate handling 1454 In the near term, the exchange of public keys and certification of 1455 these keys must be handled as part of the process of establishing a 1456 trading partnership. The UA and/or EDI application interface must 1457 maintain a database of public keys used for encryption or 1458 signatures, in addition to the mapping between EDI trading partner 1459 ID and FTP URL/URI. The procedures for establishing a trading 1460 partnership and configuring the secure EDI messaging system might 1461 vary among trading partners and software packages. 1463 X.509 certificates are REQUIRED. It is RECOMMENDED that trading 1464 partners self-certify each other if an agreed upon certification 1465 authority is not used. This applicability statement does NOT 1466 require the use of a certification authority. 1468 The use of a certification authority is therefore OPTIONAL. 1469 Certificates may be self-signed. It is RECOMMENDED that when 1470 trading partners are using S/MIME, that they also exchange public 1471 key certificates using the recommendations specified in the S/MIME 1472 Version 3 Message Specification. 1474 The message formats and S/MIME conformance requirements for 1475 certificate exchange are specified in this document. In the long 1476 term, additional Internet-EDI standards may be developed to 1477 simplify the process of establishing a trading partnership, 1478 including the third party authentication of trading partners, 1479 as well as attributes of the trading relationship. 1481 9. Security Considerations 1483 This entire document is concerned with secure transport of business 1484 to business data, and considers both privacy and authentication 1485 issues. 1487 Extracted from S/MIME Version 2 Message Specification: 40-bit 1488 encryption is considered weak by most cryptographers. Using weak 1489 cryptography offers little actual security over sending plaintext. 1491 However, other features of S/MIME, such as the specification of 1492 tripleDES or AES and the ability to announce stronger cryptographic 1493 capabilities to parties with whom you communicate, allow senders to 1494 create messages that use strong encryption. Using weak cryptography 1495 is never recommended unless the only alternative is no 1496 cryptography. When feasible, sending and receiving agents should 1497 inform senders and recipients the relative cryptographic strength 1498 of messages. 1500 Extracted from S/MIME Version 3 Certificate Handling (ref [11]): 1502 When processing certificates, there are many situations where the 1503 processing might fail. Because the processing may be done by a user 1504 agent, a security gateway, or other program, there is no single way 1505 to handle such failures. Just because the methods to handle the 1506 failures have not been listed, however, the reader should not 1507 assume that they are not important. The opposite is true: if a 1508 certificate is not provably valid and associated with the message, 1509 the processing software should take immediate and noticeable steps 1510 to inform the end user about it. 1512 Some of the many places where signature and certificate checking 1513 might fail include: 1515 - no certificate chain leads to a trusted CA 1516 - no ability to check the CRL for a certificate 1517 - an invalid CRL was received 1518 - the CRL being checked is expired 1519 - the certificate is expired 1520 - the certificate has been revoked 1522 There are certainly other instances where a certificate may be 1523 invalid, and it is the responsibility of the processing software to 1524 check them all thoroughly, and to decide what to do if the check 1525 fails. 1527 The following certificate types MUST be supported. 1528 With URL 1529 Without URL 1530 Self Certified 1531 Certification Authority Certified 1533 The complete certification chain MUST be included in all 1534 certificates. All certificate verifications MUST "chain to root". 1535 Additionally, the certificate hash should match the hash recomputed 1536 by the receiver. 1538 10. IANA Considerations 1540 This document has no actions for IANA. 1542 11. References 1544 Normative References 1546 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail 1547 Extensions (MIME) 1548 Part One: Format of Internet Message Bodies", RFC 2045, 1549 December 02, 1996. 1551 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1552 Extensions (MIME) 1553 Part Two: Media Types", RFC 2046, December 02, 1996. 1555 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1556 Extensions (MIME) 1557 Part Five: Conformance Criteria and Examples", RFC 2049 , 1558 December 02, 1996. 1560 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 1561 March 2, 1995. 1563 [3] J. Postel, J. Reynolds, 1564 "FILE TRANSFER PROTOCOL (FTP)", RFC 959, October 1985. 1566 [4] M. Horowitz, S. Lunt, "FTP Security Extensions", RFC 2228, 1567 October, 1997 1569 [5] T. Harding, R. Drummond, C. Shih, "Peer-to-Peer MIME-based 1570 Secure Business Data Interchange", RFC 3335, September 2002. 1572 [6] R. Fajman, "An Extensible Message Format for Message Disposition 1573 Notifications", RFC 2298, March 1998. 1575 [7] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 1576 Multiparts for MIME: 1577 Multipart/Signed and Multipart/Encryptezd", RFC 1847, Oct. 3, 1578 1995 1580 [8] J. Postel, "Simple Mail Transfer Protocozl", STD 10, RFC 821, 1581 August 1, 1982. 1583 [9] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 1585 [10] B. Ramsdell, "S/MIME Version 3 Message Specification; 1586 RFC 2633 June 1999. 1588 [11] B. Ramsdell, "S/MIME Version 3 Certificate Handling", RFC 2632, 1589 June 1999 1591 [12] G. Vaudreuil, "The Multipart/Report Content Type for the 1592 Reporting of Mail System Administrative Messages", RFC 1892, 1593 March 15, 1996. 1595 [13] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246, 1596 March 1999. 1598 [14] D. Crocker, "Standard for the Format of ARPA Internet Text 1599 Messages", STD 11, RFC 822, August 13, 1982. 1601 [15] P. Resnick, "Internet Message Format", RFC 2822, April 2001. 1603 [16] E. Whitehead, M. Murata, "XML Media Types", RFC 2376, July 1998. 1605 [17] P. Gutmann, "Compressed Data Content Type for Cryptographic 1606 Message Syntax (CMS)", RFC 3274, June 2002 1608 [18] T. Harding, "Compressed Data for EDIINT", EDIINT Internet Draft, 1609 Feb, 2005, draft-ietf-ediint-compression-03.txt 1611 [MURRAY] Paul Ford-Hutchinson, "Securing FTP with TLS", IETF Draft, 1612 Feb, 2005, draft-murray-auth-ftp-ssl-16.txt 1614 12. Authors' Addresses 1616 Terry Harding 1617 tharding@cyclonecommerce.com 1618 Cyclone Commerce 1619 8388 E. Hartford Drive, Suite 100 1620 Scottsdale, AZ 85255 USA 1622 Richard Scott 1623 rscott@cyclonecommerce.com 1624 Cyclone Commerce 1625 8388 E. Hartford Drive, Suite 100 1626 Scottsdale, AZ 85255 USA 1628 Appendices 1630 A. Message Examples 1632 NOTE: All examples are provided as an illustration only, and are not 1633 considered part of the protocol specification. If an example 1634 conflicts with the protocol definitions specified above or with 1635 that of a referenced RFC, the example is wrong. 1637 A.1 Signed message requesting a signed receipt 1639 Date: Wed, 31 Jul 2002 13:34:50 GMT 1640 AS3-Version: 1.0 1641 AS3-From: cyclone 1642 AS3-To: "trading partner" 1643 Message-Id: <200207310834482A70BF63@host.com> 1644 Disposition-Notification-To: ftp://host:port/mdnbox 1645 Disposition-Notification-Options: signed-receipt- 1646 protocol=optional,pkcs7-signature; 1647 signed-receipt-micalg=optional,sha1 1648 Content-Type: multipart/signed; boundary="as3BouNdary1as3"; 1649 protocol="application/pkcs7-signature"; micalg=sha1 1650 Content-Length: 3075 1652 --as3BouNdary1as3 1653 Content-Type: application/edi-x12 1654 Content-Disposition: Attachment; filename=rfc1767.dat 1656 [ISA ...EDI transaction data...IEA...] 1658 --as3BouNdary1as3 1659 Content-Type: application/pkcs7-signature 1661 [omitted binary pkcs7 signature data] 1662 --as3BouNdary1as3-- 1664 A.2 MDN for Message A.1 Above 1666 Date: Wed, 31 Jul 2002 13:34:50 GMT 1667 From: "trading partner" 1668 AS3-To: cyclone 1669 AS3-Version: 1.0 1670 Message-ID: <709700825.1028122454671.JavaMail@ediXchange> 1671 Content-Type: multipart/signed; micalg=sha1; 1672 protocol="application/pkcs7-signature"; 1673 boundary="----=_Part_57_648441049.1028122454671" 1674 Content-Length: 1024 1676 ------=_Part_57_648441049.1028122454671 1678 & Content-Type: multipart/report; 1679 & Report-Type=disposition-notification; 1680 & boundary="----=_Part_56_1672293592.1028122454656" 1681 & 1682 &------=_Part_56_1672293592.1028122454656 1683 &Content-Type: text/plain 1684 &Content-Transfer-Encoding: 7bit 1685 & 1686 &MDN for - 1687 & Message ID: <200207310834482A70BF63@host.com> 1688 & From: cyclone 1689 & To: "trading partner" 1690 & Received on: 2002-07-31 at 09:34:14 (EDT) 1691 & Status: processed 1692 & Comment: This is not a guarantee that the message has been 1693 & completely processed or understood by the receiving translator 1694 & 1695 &------=_Part_56_1672293592.1028122454656 1696 & Content-Type: message/disposition-notification 1697 & Content-Transfer-Encoding: 7bit 1698 & 1699 & Reporting-UA: AS3 Server 1700 & Original-Recipient: rfc822; "trading partner" 1701 & Final-Recipient: rfc822; "trading partner" 1702 & Original-Message-ID: <200207310834482A70BF63@host.com> 1703 & Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1 1704 & Disposition: automatic-action/MDN-sent-automatically; processed 1705 & 1706 &------=_Part_56_1672293592.1028122454656-- 1708 ------=_Part_57_648441049.1028122454671 1709 Content-Type: application/pkcs7-signature; name=smime.p7s 1710 Content-Transfer-Encoding: base64 1711 Content-Disposition: attachment; filename=smime.p7s 1713 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ 1714 cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA 1715 ------=_Part_57_648441049.1028122454671-- 1717 Notes: 1719 1. The lines proceeded with "&" is what the signature is calculated 1720 over. 1722 2. For details on how to prepare the multipart/signed with protocol = 1723 "application/pkcs7-signature" see the "S/MIME Message 1724 Specification, PKCS Security Services for MIME".) 1726 3. Note that the textual first body part of the multipart/report can 1727 be used to include a more detailed explanation of the error 1728 conditions reported by the disposition headers. The first body part 1729 of the multipart/report when used in this way, allows a person to 1730 better diagnose a problem in detail. 1732 4. As specified by RFC 1892 [10], returning the original or portions 1733 of the original message in the third body part of the 1734 multipart/report is not required. This is an optional body part. 1735 However, it is RECOMMENDED that this body part be omitted or left 1736 blank. 1738 Disclaimer 1740 This document and the information contained herein are provided on an 1741 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1742 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1743 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1744 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1745 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1748 Copyright Statement 1750 Copyright (C) The Internet Society (2006). 1752 This document is subject to the rights, licenses and restrictions 1753 contained in BCP 78, and except as set forth therein, the authors 1754 retain all their rights. 1756 This document and the information contained herein are provided on an 1757 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1758 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1759 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1760 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1761 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1762 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1764 Expires August 2006