idnits 2.17.1 draft-ietf-ediint-as2-20.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 3667, Section 5.1 on line 39. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2157. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2139. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2145. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 43 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2.0 Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9.0 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10.0 IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([15], [Peer1], [2], [16], [Peer2], [3], [17], [4], [5], [6], [7], [AS2-Message], [8], [9], [10], [11], [12], [13], [14], [AS2-MDN], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 sending system may choose to limit the possible AS2- To/AS2-From textual values but MUST not exceed them. The receiving system MUST make no restrictions on the textual values and SHOULD handle all possible implementations. However, implementers must be aware that older AS2 products may not adhere to this convention. Trading partner agreements should be made to insure that older products can support the system identifiers that are used. == 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 'SHOULD not' in this paragraph: o Unlike SMTP, for HTTP transactions, Original-Recipient and Final-Recipient SHOULD not be different. The value in Original-Message-ID SHOULD match the original Message-ID header value. == 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 request for a receipt or signed receipt, and the received message contents are successfully processed by the receiving EDI UA, a receipt or MDN SHOULD be returned with the disposition-type set to 'processed'. When the MDN is sent automatically by the EDI UA, and there is no explicit way for a user to control the sending of the MDN, then the first part of the "disposition-mode" SHOULD be set to "automatic-action". 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 the control of a user, administrator, or software. -- 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 (21 December 2004) is 7065 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 section? '2' on line 1836 looks like a reference -- Missing reference section? '4' on line 1842 looks like a reference -- Missing reference section? '13' on line 1865 looks like a reference -- Missing reference section? '3' on line 1839 looks like a reference -- Missing reference section? '8' on line 1852 looks like a reference -- Missing reference section? '6' on line 1848 looks like a reference -- Missing reference section? '9' on line 2022 looks like a reference -- Missing reference section? '1' on line 1822 looks like a reference -- Missing reference section? '5' on line 1845 looks like a reference -- Missing reference section? '12' on line 1862 looks like a reference -- Missing reference section? '10' on line 1882 looks like a reference -- Missing reference section? 'Peer1' on line 903 looks like a reference -- Missing reference section? 'Peer2' on line 903 looks like a reference -- Missing reference section? 'AS2-Message' on line 898 looks like a reference -- Missing reference section? 'AS2-MDN' on line 902 looks like a reference -- Missing reference section? '11' on line 1859 looks like a reference -- Missing reference section? '15' on line 1871 looks like a reference -- Missing reference section? '16' on line 1874 looks like a reference -- Missing reference section? '14' on line 1868 looks like a reference -- Missing reference section? '7' on line 1879 looks like a reference -- Missing reference section? '17' on line 1885 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Moberg 3 draft-ietf-ediint-as2-20.txt R. Drummond 4 Category: Standards Track 21 December 2004 5 Expires: May 2005 7 MIME-based Secure Peer-to-Peer 8 Business Data Interchange Using HTTP, 9 Applicability Statement 2 (AS2) 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 IPR Statement 36 By submitting this Internet-Draft, I certify that any applicable 37 patent or other IPR claims of which I am aware have been disclosed, 38 or will be disclosed, and any of which I become aware will be 39 disclosed, in accordance with RFC 3668. 41 Abstract 43 This document provides a applicability statement (RFC 2026, 3.2) 44 that describes how to exchange structured business data securely 45 using the HTTP transfer protocol, instead of SMTP; the 46 applicability statement for SMTP is found in RFC 3335. Structured 47 business data may be XML, Electronic Data Interchange 48 (EDI) in either the American National Standards Committee (ANSI) 49 X12 format, or in the UN Electronic Data Interchange for 50 Administration, Commerce and Transport (UN/EDIFACT) format, 51 or in other structured data formats. The data is packaged using 52 standard MIME structures. Authentication and data confidentiality 53 are obtained by using Cryptographic Message Syntax with S/MIME 54 security body parts. Authenticated acknowledgements make use of 55 multipart/signed Message Disposition Notification (MDN) 56 responses to the original HTTP message. This applicability 57 statement is informally referred to as "AS2" because it is the 58 second applicability statement, produced after "AS1," RFC 3335. 60 Feedback Instructions: 62 NOTE TO RFC EDITOR: This section should be removed by the RFC editor 63 prior to publication. 65 If you want to provide feedback on this draft, follow these 66 guidelines: 68 -Send feedback via e-mail to the ietf-ediint list for discussion, 69 with "AS#2" in the Subject field. To enter or follow the discussion, 70 you need to subscribe to ietf-ediint@imc.org. 72 -Be specific as to what section you are referring to, preferably 73 quoting the portion that needs modification, after which you state 74 your comments. 76 -If you are recommending some text to be replaced with your suggested 77 text, again, quote the section to be replaced, and be clear on the 78 section in question. 80 Table of Contents 82 1.0 Introduction 83 1.1 Applicable RFCs..........................................4 84 1.2 Terms ...................................................4 85 2.0 Overview .....................................................5 86 2.1 Overall operation .......................................5 87 2.2 Purpose of a security guideline for MIME EDI ............6 88 2.3 Definitions .............................................6 89 2.4 Assumptions .............................................7 90 3.0 Referenced RFCs ..............................................9 91 3.1 RFC 2616 HTTP v1.1 ......................................9 92 3.2 RFC 1847 MIME Security Multiparts .......................9 93 3.3 RFC 3462 Multipart/report ...............................9 94 3.4 RFC 1767 EDI Content ....................................9 95 3.5 RFC 2045, 2046, 2049 MIME ..............................10 96 3.6 RFC 3798 Message Disposition Notification ..............10 97 3.7 RFC 3851, 2630 S/MIME Version 3 Message Specifications..10 98 3.8 RFC 3023 XML Media Types ...............................10 99 4.0 Structure of an AS2 message .................................10 100 4.1 Introduction ...........................................10 101 4.2 Structure of an Internet EDI MIME message ..............10 102 5.0 HTTP Considerations .........................................11 103 5.1 Sending EDI in HTTP Post Requests ......................11 104 5.2 Unused MIME Headers and Operations .....................12 105 5.3 Modification of MIME or other headers...................12 106 5.4 HTTP Response Status Codes .............................13 107 5.5 HTTP Error Recovery ....................................14 108 6.0 Additional AS2 Specific HTTP Headers ........................14 109 6.1 AS2 Version Header .....................................14 110 6.2 AS2 System Identifiers .................................15 111 7.0 Structure and Processing of an MDN Message ..................16 112 7.1 Introduction ...........................................16 113 7.2 Synchronous and Asynchronous MDNs ......................18 114 7.3 Requesting a Signed Receipt ............................19 115 7.4 MDN Format .............................................23 116 7.5 Disposition Mode, Type, and Modifier ...................28 117 7.6 Receipt Reply Considerations in a HTTP Post ...........32 118 8.0 Public Key Certificate Handling .............................33 119 9.0 Security Considerations .....................................34 120 10.0 IANA Considerations ........................................36 121 10.1 Registration...........................................36 122 11.0 Acknowledgements ...........................................36 123 12.0 References .................................................37 124 12.1 Normative References ..................................37 125 12.2 Informative References ................................38 126 13.0 Authors' Addresses .........................................38 127 Appendix ........................................................39 128 A. Message Examples .............................................39 130 1.0 Introduction 132 1.1 Applicable RFCs 134 Previous work on Internet EDI focused on specifying MIME content 135 types for EDI data [2] and extending this work to support secure 136 EC/EDI transport over SMTP [4]. This document expands on RFC 1767 to 137 specify a comprehensive set of data security features, specifically 138 data confidentiality, data integrity/authenticity, non-repudiation of 139 origin and non-repudiation of receipt over HTTP. This document also 140 recognizes contemporary RFCs and is attempting to "re-invent" as 141 little as possible. While this document focuses on EDI data, any 142 other data types describable in a MIME format are also supported. 144 Internet MIME based EDI can be accomplished by using and complying 145 with the following RFCs: 147 o RFC 2616 Hyper Text Transfer Protocol 148 o RFC 1767 EDI Content Type 149 o RFC 3023 XML Media Types 150 o RFC 1847 Security Multiparts for MIME 151 o RFC 3462 Multipart/Report 152 o RFC 2045 to 2049 MIME RFC's 153 o RFC 3798 Message Disposition Notification 154 o RFC 3851, 3852 S/MIME v3.1 Specification 156 Our intent here is to define clearly and precisely how these are used 157 together, and what is required by user agents to be compliant with 158 this document. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [13]. 164 1.2 Terms 166 AS2 - Applicability Statement 2 (this document) 167 EDI - Electronic Data Interchange 169 EC - Business to Business Electronic Commerce 171 B2B - Business to Business 173 Receipt - The functional message that is sent from a receiver to a 174 sender to acknowledge receipt of an EDI/EC interchange. This message 175 may be either synchronous or asynchronous in nature. 177 Signed Receipt - A receipt with a digital signature. 179 Synchronous Receipt - A receipt returned to the sender during the 180 same HTTP session as the sender's original message. 182 Asynchronous Receipt - A receipt returned to the sender on a 183 different communication session than the sender's original message 184 session. 186 Message Disposition Notification (MDN) - The Internet messaging 187 format used to convey a receipt. This term is used interchangeably 188 with receipt. A MDN is a receipt. 190 Non-repudiation of receipt (NRR) - NRR is a "legal event" that occurs 191 when the original sender of an signed EDI/EC interchange has verified 192 the signed receipt coming back from the receiver. The receipt 193 contains data identifying the original message for which it is a 194 receipt, including the message-ID and a cryptographic hash (MIC). 195 The original sender must retain suitable records providing evidence 196 concerning the message content, its message-ID, and its hash value. 197 The original sender verifies that the retained hash value is the 198 same as the digest of the original message as reported in the 199 signed receipt. NRR is not considered to be a technical message, 200 but instead is thought of as an outcome of possessing relevant 201 evidence. 203 S/MIME - A format and protocol for adding Cryptographic signature 204 and/or encryption services to Internet MIME messages. 206 CMS - Cryptographic Message Syntax (CMS) is an encapsulation syntax 207 used to digitally sign, digest, authenticate, or encrypt arbitrary 208 messages. 210 SHA-1 - A secure, one-way hash algorithm used in conjunction with 211 digital signature. This is the recommended algorithm for AS2. 213 MD5 - A secure, one-way hash algorithm used in conjunction with 214 digital signature. This algorithm is allowed in AS2. 216 MIC - The message integrity check (MIC), also called the message 217 digest, is the digest output of the hash algorithm used by the 218 digital signature. The digital signature is computed over the MIC. 220 User Agent (UA) - The application that handles and processes the AS2 221 request. 223 2.0 Overview 225 2.1 Overall Operation 227 A HTTP POST operation [3] is used to send appropriately packaged EDI, 228 XML, or other business data. The Request-URI ([3], section 9.5) 229 identifies a process to unpack and handle the message data and to 230 generate a reply for the client that contains a message disposition 231 acknowledgement (MDN), either signed or unsigned. The MDN is either 232 returned in the HTTP response message-body or by a new HTTP POST 233 operation to a URL for the original sender. 235 This request/reply transactional interchange can 236 provide secure, reliable, and authenticated transport for 237 EDI or other business data using HTTP as a transfer protocol. 239 The security protocols and structures used also support auditable 240 records of these document data transmissions, acknowledgements and 241 authentication. 243 2.2 Purpose of a security guideline for MIME EDI 245 The purpose of these specifications is to ensure interoperability 246 between B2B Electronic Commerce user agents, invoking some or all of 247 the commonly expected security features. This document is also NOT 248 limited to strict EDI use, but applies to any electronic commerce 249 application where business data needs to be exchanged over the 250 Internet in a secure manner. 252 2.3 Definitions 254 2.3.1 The secure transmission loop 256 This document's focus is on the formats and protocols for exchanging 257 EDI/EC content securely in the Internet's HTTP environment. 259 The "secure transmission loop" for EDI/EC involves one organization 260 sending a signed and encrypted EDI/EC interchange to another 261 organization, requesting a signed receipt, followed later by the 262 receiving organization sending this signed receipt back to the 263 sending organization. In other words, the following transpires: 265 o The organization sending EDI/EC data signs and encrypts the 266 data using S/MIME. In addition, the message will request a 267 signed receipt to be returned to the sender of the message. 269 To support NRR, the original sender retains records of the 270 message, message-ID, and digest (MIC) value. 271 o The receiving organization decrypts the message and verifies 272 the signature, resulting in verified integrity of the data 273 and authenticity of the sender. 274 o The receiving organization then returns a signed receipt 275 using the HTTP reply body or a separate HTTP POST operation 276 to the sending organization in the form of a signed message 277 disposition notification. This signed receipt will contain 278 the hash of the received message, allowing the original 279 sender to have evidence that the received message was 280 authenticated and/or decrypted properly by the receiver. 282 The above describes functionality which, if implemented, will satisfy 283 all security requirements and implement non-repudiation of receipt 284 for the exchange. This specification, however, leaves full 285 flexibility for users to decide the degree to which they want to 286 deploy those security features with their trading partners. 288 2.3.2 Definition of receipts 290 The term used for both the functional activity and the message for 291 acknowledging delivery of an EDI/EC interchange is receipt or signed 292 receipt. The term is used if the acknowledgment is for an 293 interchange resulting in a receipt which is NOT signed. The second 294 term is used if the acknowledgment is for an interchange resulting in 295 a receipt which IS signed. 297 A term often used in combination with receipts is non-repudiation of 298 receipt. NRR refers to a legal event which occurs only when the 299 original sender of an interchange has verified the signed receipt 300 coming back from recipient of the message, and has verified that 301 the returned MIC value inside the MDN matches the previously 302 recorded value for the original message. 304 NRR is best established when both the original message and the 305 receipt make use of digital signatures. See also the Security 306 Considerations section for some cautions regarding NRR. 308 For information on how to format and process receipts in AS2, refer 309 to section 7. 311 2.4 Assumptions 313 2.4.1 EDI/EC process assumptions 315 o Encrypted object is an EDI/EC Interchange 317 This specification assumes that a typical EDI/EC interchange is the 318 lowest level object that will be subject to security services. 320 Specifically, in EDI ANSI X12, this means that anything between, and 321 including segments ISA and IEA, is secured. In EDIFACT, this means 322 anything between, and including, segments UNA/UNB and UNZ is secured. 323 In other words, the EDI/EC interchanges including envelope segments 324 remain intact and unreadable during fully secured transport. 326 o EDI envelope headers are encrypted 328 Congruent with the above statement, EDI envelope headers are NOT 329 visible in the MIME package. 331 In order to optimize routing from existing commercial EDI networks 332 (called Value Added Networks or VANs) to the Internet, it would be 333 useful to make some envelope information visible. This 334 specification, however, provides no support for this optimization. 336 o X12.58 and UN/EDIFACT security considerations 338 The most common EDI standards bodies, ANSI X12 and EDIFACT, have 339 defined internal provisions for security. X12.58 is the security 340 mechanism for ANSI X12 and AUTACK provides security for EDIFACT. This 341 specification does NOT dictate use or non-use of these security 342 standards. They are both fully compatible, though possibly 343 redundant, with this specification. 345 2.4.2 Flexibility assumptions 347 o Encrypted or unencrypted data 349 This specification allows for EDI/EC message exchange where the 350 EDI/EC data can either be unprotected or protected by means of 351 encryption. 353 o Signed or unsigned data 355 This specification allows for EDI/EC message exchange with or without 356 digital signature of the original EDI transmission. 358 o Use of receipt or not 360 This specification allows for EDI/EC message transmission with or 361 without a request for receipt notification. If a signed receipt 362 notification is requested however, a MIC value is REQUIRED as part 363 of the returned receipt, except when a severe error condition 364 prevents computation of the digest value. In the exceptional case, 365 a signed receipt should be returned with an error message that 366 effectively explains why the MIC is absent. 368 o Use of synchronous or asynchronous receipts 370 This specification allows in addition to a receipt request the 371 specification of the type of receipt that should be returned. It 372 supports synchronous or asynchronous receipts in the MDN format 373 specified in section 7 of this document. 375 o Security Formatting 377 This specification relies on the guidelines set forth in RFC 378 3851/3852 [8] "S/MIME Version 3.1 Message Specification; 379 Cryptographic Message Syntax". 381 o Hash function, message digest choices 383 When a signature is used, it is RECOMMENDED that the SHA-1 hash 384 algorithm be used for all outgoing messages, and that both MD5 and 385 SHA-1 be supported for incoming messages. 387 o Permutation Summary 389 In summary, the following twelve security permutations are possible 390 in any given trading relationship: 392 1. Sender sends un-encrypted data, does NOT request a receipt. 393 2. Sender sends un-encrypted data, requests an unsigned receipt. 394 The receiver sends back the unsigned receipt. 395 3. Sender sends un-encrypted data, requests a signed receipt. 396 The receiver sends back the signed receipt. 397 4. Sender sends encrypted data, does NOT request a receipt. 398 5. Sender sends encrypted data, requests an unsigned receipt. 399 The receiver sends back the unsigned receipt. 400 6. Sender sends encrypted data, requests a signed receipt. 401 The receiver sends back the signed receipt. 402 7. Sender sends signed data, does NOT request a signed or 403 unsigned receipt. 404 8. Sender sends signed data, requests an unsigned receipt. 405 Receiver sends back the unsigned receipt. 406 9. Sender sends signed data, requests a signed receipt. 407 Receiver sends back the signed receipt. 408 10. Sender sends encrypted and signed data, does NOT request a 409 signed or unsigned receipt. 410 11. Sender sends encrypted and signed data, requests an unsigned 411 receipt. Receiver sends back the unsigned receipt. 412 12. Sender sends encrypted and signed data, requests a signed 413 receipt. Receiver sends back the signed receipt. 415 Users can choose any of the twelve possibilities, but only the 416 last example (12), when a signed receipt is requested, offers the 417 whole suite of security features described in the "Secure 418 transmission loop" above. 420 Additionally, the receipts discussed above may be either synchronous 421 or asynchronous in nature depending on the type requested. The use of 422 either the synchronous or asynchronous receipts does not change the 423 nature of the "Secure transmission loop" in support of NRR. 425 3.0 Referenced RFC's and their contribution 427 3.1 RFC 2616 HTTP v1.1 [3] 429 This document specifies how data is transferred using HTTP. 431 3.2 RFC 1847 MIME Security Multiparts [6] 433 This document defines security multipart for MIME: 434 multipart/encrypted and multipart/signed. 436 3.3 RFC 3462 Multipart/report [9] 438 This RFC defines the use of the multipart/report content type, 439 something that the MDN RFC 3798 builds upon. 441 3.4 RFC 1767 EDI Content [2] 443 This RFC defines the use of content type "application" for ANSI X12 444 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually 445 defined EDI (application/EDI-Consent). 447 3.5 RFC 2045, 2046, and 2049 MIME [1] 449 These are the basic MIME standards, upon which all MIME related RFCs 450 build, including this one. Key contributions include definition of 451 "content type", "sub-type" and "multipart", as well as encoding 452 guidelines, which establishes 7-bit US-ASCII as the canonical 453 character set to be used in Internet messaging. 455 3.6 RFC 3798 Message Disposition Notification [5] 457 This Internet RFC defines how a MDN is requested, and the format and 458 syntax of the MDN. The MDN is the basis upon which receipts and 459 signed receipts are defined in this specification. 461 3.7 RFC 3851 and 3852 S/MIME Version 3.1 Message Specifications and 462 Cryptographic Message Syntax (CMS) [8] 464 This specification describes how S/MIME shall carry CMS Objects. 466 3.8 RFC 3023 XML Media Types [12] 468 This RFC defines the use of content type "application" for XML 469 (application/xml). 471 4.0 Structure of an AS2 message 472 4.1 Introduction 474 The basic structure of an AS2 messages consists of MIME format inside 475 an HTTP message with a few additional specific AS2 headers. The 476 structures below are described hierarchically in terms of which RFC's 477 are applied to form the specific structure. For details of how to 478 code in compliance with all RFC's involved, turn directly to the 479 RFC's referenced. Any difference between AS2 implantations and RFCs 480 are mentioned specifically in the sections below. 482 4.2 Structure of an Internet EDI MIME message 484 No encryption, no signature 485 -RFC2616/2045 486 -RFC1767/RFC3023 (application/EDIxxxx or /xml) 488 No encryption, signature 489 -RFC2616/2045 490 -RFC1847 (multipart/signed) 491 -RFC1767/RFC3023 (application/EDIxxxx or /xml) 492 -RFC3851 (application/pkcs7-signature) 494 Encryption, no signature 495 -RFC2616/2045 496 -RFC3851 (application/pkcs7-mime) 497 -RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted) 499 Encryption, signature 500 -RFC2616/2045 501 -RFC3851 (application/pkcs7-mime) 502 -RFC1847 (multipart/signed)(encrypted) 503 -RFC1767/RFC3023 (application/EDIxxxx or 504 /xml)(encrypted) 505 -RFC3851 (application/pkcs7-signature)(encrypted) 507 MDN over HTTP, no signature 508 -RFC2616/2045 509 -RFC3798 (message/disposition-notification) 511 MDN over HTTP, signature 512 -RFC2616/2045 513 -RFC1847 (multipart/signed) 514 -RFC3798 (message/disposition-notification) 515 -RFC3851 (application/pkcs7-signature) 517 MDN over SMTP, no signature 518 MDN over SMTP, signature 519 Refer to the EDI over SMTP standard [4]. 521 While all MIME content types SHOULD be supported. The 522 following MIME content types MUST be supported: 524 Content-type: multipart/signed 525 Content-Type: multipart/report 526 Content-type: message/disposition-notification 527 Content-Type: application/PKCS7-signature 528 Content-Type: application/PKCS7-mime 529 Content-Type: application/EDI-X12 530 Content-Type: application/EDIFACT 531 Content-Type: application/edi-consent 532 Content-Type: application/XML 534 5.0 HTTP Considerations 536 5.1 Sending EDI in HTTP POST Requests 538 The request line will have the form: "POST Request-URI HTTP/1.1", 539 with spaces and followed by a CRLF. The Request URI is typically 540 exchanged out of band, as part of setting up a bilateral trading 541 partner agreement. Applications SHOULD be prepared to deal with an 542 initial reply containing a status indicating a need for 543 authentication of the usual types used for authorizing access to the 544 Request-URI ([3], section 10.4.2 and elsewhere). 546 The request line is followed by entity headers specifying content 547 length ([3] section 14.14) and content type ([3],section 14.18). The 548 Host request header ([3] sections 9 and 14.23) is also included. 550 When using Transport Layer Security [10] or SSLv3, the request-URI 551 SHOULD indicate the appropriate scheme value, HTTPS. Usually only a 552 multipart/signed message body would be sent using TLS, as encrypted 553 message bodies would be redundant. However, encrypted message bodies 554 are not prohibited. 556 The receiving AS2 system MAY disconnect from the sending AS2 system 557 before completing the reception of the entire entity if it determines 558 the entity being sent is too large to process. 560 For HTTP version 1.1, TCP persistent connections are the default, 561 ([3] sections 8.1.2, 8.2, and 19.7.1). A number of other differences 562 exist because HTTP does not conform to MIME [1] as used in SMTP 563 transport. Relevant differences are summarized below. 565 5.2 Unused MIME Headers and Operations 567 5.2.1 Content-Transfer-Encoding not used in HTTP transport 569 HTTP can handle binary data and so there is no need to use the 570 content transfer encodings of MIME [1]. This difference is discussed 571 in [3] section 19.4.5. However, a Content transfer encoding value of 572 binary or 8-bit is permissible but not required. The absence of this 573 header MUST NOT result in transaction failure. Content transfer 574 encoding of MIME bodyparts within the AS2 message body is also 575 allowed. 577 5.2.2 Message bodies 579 In [3] section 3.7.2, it is explicitly noted that multiparts MUST 580 have null epilogues. 582 In [4], sections 5.4.1, options for large file processing are 583 discussed for SMTP transport. For HTTP, large files SHOULD be handled 584 correctly by the TCP layer. However, [3] sections 3.5 and 3.6 discuss 585 some options for compressing or chunking entities to be transferred. 586 [3] Section 8.1.2.2 discusses a pipelining option that is useful for 587 segmenting large amounts of data. 589 5.3 Modification of MIME or other headers or parameters used 591 5.3.1 Content-Length 593 The use of the content-length header MUST follow the guidelines of 594 [3], specifically sections 4.4 and 14.13. 596 5.3.2 Final Recipient and Original Recipient 598 The final and original recipient values SHOULD be the same value. 599 These values MUST NOT be aliases or mailing lists. 601 5.3.3 Message-Id and Original-Message-Id 603 Message-Id and Original-Message-Id is formatted as defined in 604 RFC2822: 606 "<" id-left "@" id-right ">" (RFC2822 3.6.4) 608 Message-Id length is a maximum of 998 characters. For maximum 609 backward compatibility, Message-Id length SHOULD be 255 characters or 610 less. Message-Id SHOULD be globally unique, id-right SHOULD be 611 something unique to the sending host environment (e.g. a host name). 613 When sending a message, always include the angle brackets. Angle 614 brackets are not part of the Message-Id value. For maximum backward 615 compatibility, when receiving a message, do not check for angle 616 brackets. When creating the Original-Message-Id header in an MDN, 617 always use the exact syntax as received on the original message; 618 don't strip or add angle brackets. 620 5.3.4 Host header 622 The host request header field MUST be included in the POST request 623 made when sending business data. This field is to allow one server IP 624 address to service multiple hostnames, and potentially conserve IP 625 addresses. See [3], sections 14.23 and 19.5.1. 627 5.4 HTTP Response Status Codes 629 The status codes return status concerning HTTP operations. For 630 example, the status code 401, together with the WWW- Authenticate 631 header, is used to challenge the client to repeat the request with 632 an Authorization header. Other explicit status codes are documented 633 in [3], sections 6.1.1 and throughout section 10. 635 For errors in the request-URI, 400 ("Bad Request"), 404 ("Not Found") 636 and similar codes are appropriate status codes. These codes and their 637 semantics are specified by [3]. A careful examination of these codes 638 and their semantics should be made before implementing any retry 639 functionality. Retries SHOULD NOT be made if the error is not 640 transient or if retries are explicitly discouraged. 642 5.5 HTTP Error Recovery 644 If the HTTP client fails to read the HTTP server response data, the 645 POST operation with identical content, including same Message-ID 646 SHOULD be repeated, if the condition is transient. 648 The Message-ID on a POST operation can be reused if and only if all 649 of the content (including the original Date) is identical. 651 Details of the retry process -- including time intervals to pause, 652 number of retries to attempt, timeouts for retrying are 653 implementation dependent. These settings are selected as part of the 654 trading partner agreement. 656 Servers SHOULD be prepared to receive a POST with a repeated 657 Message-ID. The MIME reply body previously sent SHOULD be resent, 658 including the MDN and other MIME parts. 660 6.0 Additional AS2 Specific HTTP Headers 662 The following headers are to be included in all AS2 messages and all 663 AS2 MDNs, except for asynchronous MDNs that are sent using SMTP and 664 follow the AS1 semantics[4]. 666 6.1 AS2 Version Header 668 To promote backward compatibility AS2 includes a version: 670 AS2-Version: 1.0 - Used in all implementations implementing this 671 specification. 1.x will be interpreted as 1.0 by 672 all implementation implemented with the AS2 673 Version: 1.0 header. That is only the most 674 significant digit is used as the version 675 identifier for those not implementing additional 676 non-AS2 specified functionality. 677 AS2-Version: 1.0 through 1.9 MAY be used 678 All implementations MUST interpret "1.0 through 679 1.9" as implementing this specification. However 680 Implementation MAY extend this specification with 681 additional functionality by specifying versions 682 1.1 through 1.9. If this mechanism is used the 683 additional functionality MUST be completely 684 transparent to implementations with AS2-Version: 685 1.0 designation. 687 AS2-Version: 1.1 - Designates those implementations which support 688 compression as defined by RFC 3274. 690 Receiving systems MUST NOT fail due to the absence of the AS2-Version 691 header. Absence would indicate the message is from an implementation 692 based on a previous version of this specification. 694 6.2 AS2 System Identifiers 696 To aid the receiving system in identifying the sending system, 697 AS2-From and AS2-To headers are used. 699 AS2-From: < AS2-name > 700 AS2-To: < AS2-name > 702 These AS2 headers contain textual values, as described below, 703 identifying the sender/receiver of a data exchange. Their values may 704 be company specific, such as DUNS number, or it may be simply an 705 identification string agreed upon between the trading partners. 707 AS2-text = "!" / ; printable ASCII characters 708 %d35-91 / ; except double-quote (%d34) 709 %d93-126 ; or backslash (%d92) 711 AS2-qtext = AS2-text / SP ; allow space only in quoted text 713 AS2-quoted-pair = "\" DQUOTE / ; \" or 714 "\" "\" ; \\ 716 AS2-quoted-name = DQUOTE 1*128( AS2-qtext / 717 AS2-quoted-pair) DQUOTE 719 AS2-atomic-name = 1*128AS2-text 721 AS2-name = AS2-atomic-name / AS2-quoted-name 723 The AS2-From header value and the AS2-To header value MUST each be an 724 AS2-name, MUST each be comprised of from 1 to 128 printable ASCII 725 characters and MUST NOT be folded. The value in each of these headers 726 is case-sensitive. The string definitions given above are in ABNF 727 format. 729 The AS2-quoted-name SHOULD be used only if the AS2-name does not 730 conform to AS2-atomic-name. 732 The AS2-To and AS2-From header fields MUST be present in all AS2 733 messages and AS2 MDN's whether asynchronous or synchronous in nature, 734 except for asynchronous MDNs which are sent using SMTP. 736 The AS2-name for the AS2-To header in a response or MDN MUST match 737 the AS2-name of the AS2-From header in the corresponding request 738 message. Likewise, the AS2-name for the AS2-From header in a response 739 or MDN MUST match the AS2-name of the AS2-To header in the 740 corresponding AS2 request message. 742 The sending system may choose to limit the possible AS2- To/AS2-From 743 textual values but MUST not exceed them. The receiving system MUST 744 make no restrictions on the textual values and SHOULD handle all 745 possible implementations. However, implementers must be aware that 746 older AS2 products may not adhere to this convention. Trading partner 747 agreements should be made to insure that older products can support 748 the system identifiers that are used. 750 There is no required response to a client request containing invalid 751 or unknown AS2-From or AS2-To header values. The receiving AS2 system 752 MAY return an unsigned MDN with an explanation of the error, if the 753 sending system requested an MDN. 755 7.0 Structure and Processing of an MDN Message 757 7.1 Introduction 759 In order to support non-repudiation of receipt, a signed receipt, 760 based on digitally signing a message disposition notification, is to 761 be implemented by a receiving trading partner's UA. The message 762 disposition notification, specified by RFC 3798, is digitally signed 763 by a receiving trading partner as part of a multipart/signed MIME 764 message. 766 The following support for signed receipts is REQUIRED: 768 1. The ability to create a multipart/report; where the 769 report-type = disposition-notification. 770 2. The ability to calculate a message integrity check (MIC) on 771 the received message. The calculated MIC value will be 772 returned to the sender of the message inside the signed 773 receipt. 774 3. The ability to create a multipart/signed content with the 775 message disposition notification as the first body part, and 776 the signature as the second body part. 777 4. The ability to return the signed receipt to the sending 778 trading partner. 779 5. The ability to return either a synchronous or asynchronous 780 receipt as the sending party requests. 782 The signed receipt is used to notify a sending trading partner that 783 requested the signed receipt that: 785 1. The receiving trading partner acknowledges receipt of the 786 sent EC Interchange. 787 2. If the sent message was signed, then the receiving trading 788 partner has authenticated the sender of the EC Interchange. 789 3. If the sent message was signed, then the receiving trading 790 partner has verified the integrity of the sent EC 791 Interchange. 793 Regardless of whether the EDI/EC Interchange was sent in S/MIME 794 format or not, the receiving trading partner's UA MUST provide the 795 following basic processing: 797 1. If the sent EDI/EC Interchange is encrypted, then the 798 encrypted symmetric key and initialization vector (if 799 applicable) is decrypted using the receiver's private key. 800 2. The decrypted symmetric encryption key is then used to 801 decrypt the EDI/EC Interchange. 802 3. The receiving trading partner authenticates signatures in a 803 message using the sender's public key. The authentication 804 algorithm performs the following: 805 a. The message integrity check (MIC or Message Digest), is 806 decrypted using the sender's public key. 807 b. A MIC on the signed contents (the MIME header and 808 encoded EDI object, as per RFC 1767) in the message 809 received is calculated using the same oneway hash 810 function that the sending trading partner used. 811 c. The MIC extracted from the message that was sent, and 812 the MIC calculated using the same oneway hash function 813 that the sending trading partner used is compared for 814 equality. 815 4. The receiving trading partner formats the MDN and sets the 816 calculated MIC into the "Received-content-MIC" extension 817 field. 818 5. The receiving trading partner creates a multipart/signed MIME 819 message according to RFC 1847. 820 6. The MDN is the first part of the multipart/signed message, 821 and the digital signature is created over this MDN, including 822 its MIME headers. 823 7. The second part of the multipart/signed message contains the 824 digital signature. The "protocol" option specified in the 825 second part of the multipart/signed is as follows: 827 S/MIME: protocol = "application/pkcs-7-signature" 829 8. The signature information is formatted according to S/MIME 830 specifications. 832 The EC Interchange and the RFC 1767 MIME EDI content header can 833 actually be part of a multi-part MIME content-type. When the EDI 834 Interchange is part of a multi-part MIME content-type, the MIC MUST 835 be calculated across the entire multi-part content, including the 836 MIME headers. 838 The signed MDN, when received by the sender of the EDI Interchange 839 can be used by the sender: 841 o As an acknowledgment that the EDI Interchange sent, was 842 delivered and acknowledged by the receiving trading partner. 843 The receiver does this by returning the original-message-id 844 of the sent message in the MDN portion of the signed receipt. 846 o As an acknowledgment that the integrity of the EDI 847 Interchange was verified by the receiving trading partner. 848 The receiver does this by returning the calculated MIC of 849 the received EC Interchange (and 1767 MIME headers) in the 850 "Received-content-MIC" field of the signed MDN. 852 o As an acknowledgment that the receiving trading partner has 853 authenticated the sender of the EDI Interchange. 855 o As a non-repudiation of receipt when the signed MDN is 856 successfully verified by the sender with the receiving 857 trading partner's public key and the returned MIC value 858 inside the MDN is the same as the digest of the original 859 message. 861 7.2 Synchronous and Asynchronous MDNs 863 The AS2-MDN exists in two varieties: synchronous and asynchronous. 865 The synchronous AS2-MDN is sent as an HTTP response to an HTTP POST 866 or as an HTTPS response to an HTTPS POST. This form of AS2-MDN is 867 called synchronous because the AS2-MDN is returned to the originator 868 of the POST on the same TCP/IP connection. 870 The asynchronous AS2-MDN is sent on a separate HTTP, HTTPS, or SMTP 871 TCP/IP connection. Logically, the asynchronous AS2- MDN is a response 872 to an AS2 message. However, at the transfer-protocol layer, assuming 873 that no HTTP pipelining is utilized, the asynchronous AS2-MDN is 874 delivered on a unique TCP/IP connection, distinct from that used to 875 deliver the original AS2 message. When handling an asynchronous 876 request, the HTTP response MUST be sent back before the MDN is 877 processed and sent on the separate connection. 879 When an asynchronous AS2-MDN is requested by the sender of an AS2 880 message, the synchronous HTTP or HTTPS response returned to the 881 sender prior to terminating the connection MUST be a transfer-layer 882 response indicating the success or failure of the data transfer. The 883 format of such a synchronous response MAY be the same as that 884 response returned when no AS2-MDN is requested. 886 The following diagram illustrates the synchronous versus asynchronous 887 varieties of AS2-MDN delivery using HTTP: 889 Synchronous AS2-MDN 891 [Peer1] ----( connect )----> [Peer2] 892 [Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]] 893 [Peer1] <---( receive )----- [Peer2] [HTTP Response [AS2-MDN]] 895 Asynchronous AS2-MDN 897 [Peer1] ----( connect )----> [Peer2] 898 [Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]] 899 [Peer1] <---( receive )----- [Peer2] [HTTP Response] 901 [Peer1]*<---( connect )----- [Peer2] 902 [Peer1] <--- ( send )------- [Peer2] [HTTP Request [AS2-MDN]] 903 [Peer1] ----( receive )----> [Peer2] [HTTP Response] 905 * Note: An AS2-MDN may be directed to a different host than that of 906 the sender of the AS2 message. It may utilize a different transfer 907 protocol than that used to send the original AS2 message. 909 The advantage of the synchronous MDN is that it can provide the 910 sender of the AS2 Message with a verifiable confirmation of message 911 delivery within a synchronous logic flow. However, if the message is 912 relatively large, the time required to process this message and 913 return an AS2-MDN to the sender on the same TCP/IP connection may 914 exceed the maximum configured time permitted for an IP connection. 916 The advantage of the asynchronous MDN is that it provides for the 917 rapid return of a transfer-layer response from the receiver 918 confirming the receipt of data, therefore not requiring a TCP/IP 919 connection to necessarily remain open for very long. However, this 920 design requires that the asynchronous AS2-MDN contain enough 921 information to uniquely identify the original message so that, when 922 received by the AS2 Message originator, the status of the original 923 AS2 Message can be properly updated based on the contents of the 924 AS2-MDN. 926 Synchronous or asynchronous HTTP or HTTPS MDNs are handled according 927 to the requirements of this specification. 929 However, SMTP MDNs are formatted according to the requirements of 930 RFC 3335 [4]. 932 7.3 Requesting a Signed Receipt 934 Message Disposition Notifications are requested as per RFC 3798. A 935 request that the receiving user agent issue a message disposition 936 notification is made by placing the following header into the message 937 to be sent: 939 MDN-request-header = "Disposition-notification-to" 940 ":" mail-address 942 Example requesting a MDN: 944 Disposition-notification-to: xxx@example.com 946 This syntax is a residue of the use of MDNs using SMTP transfer. 947 Since this specification is adjusting the functionality from SMTP to 948 HTTP while retaining as much as possible from the [4] functionality, 949 the mail-address MUST be present. The mail-address field is 950 specified as an RFC 2822 localpart@domain [addr-spec] address. 951 However, the address is not used to identify where to return 952 the MDN. Receiving applications MUST ignore the value, and not 953 complain about RFC 2822 address syntax violations. 955 When requesting MDN based receipts, the originator supplies 956 additional extension headers that precede the message body. 957 These header "tags" are as follows: 959 A Message-ID header is added to support message reconciliation, 960 so that an Original-Message-Id value can be returned in the body 961 part of MDN. Other headers, especially "Subject" and "Date", SHOULD 962 be supplied; the values of these headers are often mentioned in 963 the human-readable section of a MDN to aid in identifying the 964 original message. 966 MDNs will be returned in the HTTP response when requested unless 967 an asynchronous return is requested. 969 To request an asynchronous message disposition notification, the 970 following header is placed into the message that is sent: 972 Receipt-Delivery-Option: return-URL 974 Here is an example requesting the MDN to be asynchronous 976 Receipt-Delivery-Option: http://www.example.com/Path 978 Receipt-delivery-option syntax allows return-url to use some schemes 979 other that HTTP using the POST method. 981 The "receipt-delivery-option: return-url" string indicates the URL 982 to use for an asynchronous MDN. This header is NOT present if the 983 receipt is to be synchronous. The email value in 984 Disposition-notification-to is not used in this specification 985 because it was limited to RFC 2822 addresses; the extension header 986 "Receipt-delivery-option" has introduced to provide a URL for 987 the MDN return by several transfer options. 989 The receipt-delivery-option's value MUST be a URL indicating the 990 delivery transport destination for the receipt. 992 An example request for an asynchronous MDN via an HTTP transport: 994 Receipt-delivery-option: http://www.example.com 996 An example request for an asynchronous MDN via an HTTP/S transport: 998 Receipt-delivery-option: https://www.example.com 1000 An example request for an asynchronous MDN via an SMTP transport: 1002 Receipt-delivery-option: mailto:as2@example.com 1004 For more information on requesting SMTP MDNs, refer to RFC 3335 [4]. 1006 Finally, the header, Disposition-notification-options, identifies 1007 characteristics of message disposition notification as in [5]. 1008 The most important of these options is for indicating the signing 1009 options for the MDN as in the following example: 1011 Disposition-notification-options: 1012 signed-receipt-protocol=optional,pkcs7-signature; 1013 signed-receipt-micalg=optional,sha1,md5 1015 For signing options, consider the disposition-notification-options 1016 syntax: 1018 Disposition-notification-options = 1019 "Disposition-Notification-Options" ":" 1020 disposition-notification-parameters 1022 where 1023 disposition-notification-parameters = 1024 parameter *(";" parameter) 1026 where 1027 parameter = attribute "=" importance ", " 1#value" 1029 where 1030 importance = "required" | "optional" 1032 So the Disposition-notification-options string could be: 1034 signed-receipt-protocol=optional,; 1035 signed-receipt-micalg=optional,,,...; 1037 The currently used value for is "pkcs7-signature" 1038 for the S/MIME detached signature format. 1040 The currently supported values for MIC algorithm values are: 1042 Algorithm Value Used 1043 --------- ------- 1044 SHA-1 sha1 1045 MD5 md5 1047 The semantics of the "signed-receipt-protocol" and the 1048 "signed-receipt-micalg" parameters are as follows: 1050 1. The "signed-receipt-protocol" parameter is used to request a 1051 signed receipt from the recipient trading partner. The 1052 "signed-receipt-protocol" parameter also specifies the format 1053 in which the signed receipt SHOULD be returned to the requester. 1055 The "signed-receipt-micalg" parameter is a list of MIC algorithms 1056 preferred by the requester for use in signing the returned receipt. 1057 The list of MIC algorithms SHOULD be honored by the recipient from 1058 left to right. 1060 Both the "signed-receipt-protocol" and the "signed- receipt-micalg" 1061 option parameters are REQUIRED when requesting a signed receipt. 1063 The lack of the presence of the "Receipt-Delivery-Option" indicates a 1064 receipt is synchronous in nature. The presence of the 1065 "Receipt-Delivery-Option: return-url" indicates that an asynchronous 1066 receipt is requested and SHOULD be sent to the "return-url". 1068 2. The "importance" attribute of "Optional" is defined in the RFC 1069 3798 section 2.2 and has the following meaning: 1071 Parameters with an importance of "Optional" permit a UA that does not 1072 understand the particular options parameter to still generate a MDN 1073 in response to a request for a MDN. 1075 A UA that does not understand the "signed-receipt-protocol" 1076 parameter, or the "signed-receipt-micalg" will obviously not return a 1077 signed receipt. 1079 The importance of "Optional" is used for the signed receipt 1080 parameters because it is RECOMMENDED that an MDN be returned to the 1081 requesting trading partner even if the recipient could not sign it. 1083 The returned MDN will contain information on the disposition of the 1084 message as well as why the MDN could not be signed. See the 1085 Disposition field in section 7.5 for more information. 1087 Within an EDI trading relationship, if a signed receipt is expected 1088 and is not returned, then the validity of the transaction is up to 1089 the trading partners to resolve. 1091 In general, if a signed receipt is required in the trading 1092 relationship and is not received, the transaction will likely not be 1093 considered valid. 1095 7.3.1 Signed receipt considerations 1097 The method used to request a receipt or a signed receipt is defined 1098 in RFC 3798, "An Extensible Message Format for Message Disposition 1099 Notifications". 1101 The "rule" is: 1103 1. When a receipt is requested, explicitly specifying that the 1104 receipt be signed, then the receipt MUST be returned with a 1105 signature. 1107 2. When a receipt is requested, explicitly specifying that the 1108 receipt be signed, but the recipient cannot support either the 1109 requested protocol format, or requested MIC algorithms, then either a 1110 signed or unsigned receipt SHOULD be returned. 1112 3. When a signature is not explicitly requested, or if the signed 1113 receipt request parameter is not recognized by the UA, then no 1114 receipt, an unsigned receipt, or a signed receipt MAY be returned by 1115 the recipient. 1117 NOTE: For Internet EDI, it is RECOMMENDED that when a signature is 1118 not explicitly requested, or if parameters are not recognized, that 1119 the UA send back at a minimum, an unsigned receipt. If a signed 1120 receipt however was always returned as a policy, whether requested or 1121 not, then any false unsigned receipts can be repudiated. 1123 When a request for a signed receipt is made, but there is an error in 1124 processing the contents of the message, a signed receipt MUST still 1125 be returned. The request for a signed receipt SHALL still be honored, 1126 though the transaction itself may not be valid. The reason for why 1127 the contents could not be processed MUST be set in the 1128 "disposition-field". 1130 When a signed receipt request is made, the "Received-content-MIC" 1131 MUST always be returned to the requester (except when corruption 1132 prevents computation of the digest in accordance with the following 1133 specification). The "Received-content-MIC" MUST be calculated 1134 as follows: 1136 o For any signed messages, the MIC to be returned is calculated 1137 on the RFC1767/RFC3023 MIME header and content. 1138 Canonicalization on the MIME headers MUST be performed 1139 before the MIC is calculated, since the sender requesting 1140 the signed receipt was also REQUIRED to canonicalize. 1142 o For encrypted, unsigned messages, the MIC to be returned is 1143 calculated on the decrypted RFC 1767/RFC3023 MIME header 1144 and content. The content after decryption MUST be canonicalized 1145 before the MIC is calculated. 1147 o For unsigned, unencrypted messages, the MIC MUST be calculated 1148 over the message contents without the MIME or any other RFC 1149 822 headers, since these are sometimes altered or reordered 1150 by MTAs. 1152 7.4 MDN Format and Values 1154 This section defines the format of the AS2 Message Disposition 1155 Notification (AS2-MDN). 1157 7.4.1 AS2-MDN general formats 1159 The AS2-MDN follows the MDN specification [5] except where noted in 1160 this section. The modified ABNF definitions in this document use 1161 the vertical-bar character, '|', to denote a logical "OR" 1162 construction. This usage follows RFC 2616 [3]. HTTP entities referred 1163 to below are not further defined in this document. Refer to RFC 2616 1164 [3] for complete definitions of HTTP entities. The format of the 1165 AS2-MDN is: 1167 AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN | 1168 AS2-async-smtp-MDN 1170 AS2-sync-MDN = 1171 Status-Line 1172 *(( general-header | response-header | entity-header ) 1173 CRLF ) 1174 CRLF 1175 AS2-MDN-body 1177 Status-Line = 1178 HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1180 AS2-async-http-MDN = 1181 Request-Line 1182 *(( general-header | request-header | entity-header ) 1183 CRLF ) 1184 CRLF 1185 AS2-MDN-body 1187 Request-Line = 1188 Method SP Request-URI SP HTTP-Version CRLF 1190 AS2-async-smtp-MDN = 1191 *(( general-header | request-header | entity-header ) 1192 CRLF ) 1193 CRLF 1194 AS2-MDN-body 1196 AS2-MDN-body = 1197 AS2-signed-MDN-body | AS2-unsigned-MDN-body 1199 7.4.2 AS2-MDN construction 1201 The AS2-MDN-body is formatted as a MIME multipart/report with a 1202 report-type of "disposition-notification". When unsigned, the 1203 transfer-layer ( "outermost" ) entity-headers of the AS2-MDN contain 1204 the content-type header that specifies a content-type of 1205 "multipart/report" and parameters indicating the report-type, and the 1206 value of the outermost multipart boundary. 1208 When the AS2-MDN is signed, the transfer-layer ("outermost") 1209 entity-headers of the AS2-MDN contain a content-type header that 1210 specifies a content-type of "multipart/signed" and parameters 1211 indicating the algorithm used to compute the message digest, the 1212 signature formatting protocol ( e.g.pkcs7-signature ), and the value 1213 of the outermost multipart boundary. The first part of the MIME 1214 multipart/signed message is an embedded MIME multipart/report of type 1215 "disposition-notification". The second part of the multipart/signed 1216 message contains a MIME application/pkcs7-signature message. 1218 The first part of the MIME multipart/report is a "human-readable" 1219 portion that contains a general description of the message 1220 disposition. The second part of the MIME multipart/report is a 1221 "machine-readable" portion that is defined as: 1223 AS2-disposition-notification-content = 1224 [ reporting-ua-field CRLF ] 1225 [ mdn-gateway-field CRLF ] 1226 final-recipient-field CRLF 1227 [ original-message-id-field CRLF ] 1228 AS2-disposition-field CRLF 1229 *( failure-field CRLF ) 1230 *( error-field CRLF ) 1231 *( warning-field CRLF ) 1232 *( extension-field CRLF ) 1233 [ AS2-received-content-MIC-field CRLF ] 1235 7.4.3 AS2-MDN fields 1237 The rules for constructing the AS2-disposition-notification content 1238 are identical to those for the disposition-notification-content 1239 rules provided in section 7 of RFC 3798 [5] except that 1240 the RFC 3798 disposition-field has been replaced with the 1241 AS2-disposition-field and that the AS2-received-content-MIC field has 1242 been added. The differences between the RFC 3798 disposition-field 1243 and the AS2-disposition-field are described below. Where there are 1244 differences between this document and RFC 3798, those entity names 1245 have been changed by pre-pending "AS2-". Entities that do not 1246 differ from RFC 3798 are not necessarily further defined in this 1247 document; refer to RFC 3798, section 7 "Collected Grammar" 1248 for the original grammar. 1250 AS2-disposition-field = 1251 "Disposition" ":" disposition-mode ";" 1252 AS2-disposition-type [ '/' AS2-disposition-modifier ] 1254 disposition-mode = 1255 action-mode "/" sending-mode 1257 action-mode = 1258 "manual-action" | "automatic-action" 1260 sending-mode = 1261 "MDN-sent-manually" | "MDN-sent-automatically" 1263 AS2-disposition-type = 1264 "processed" | "failed" 1266 AS2-disposition-modifier = 1267 ( "error" | "warning" ) | AS2-disposition-modifier-extension 1269 AS2-disposition-modifier-extension = 1270 "error: authentication-failed" | 1271 "error: decompression-failed" | 1272 "error: decryption-failed" | 1273 "error: insufficient-message-security" | 1274 "error: integrity-check-failed" | 1275 "error: unexpected-processing-error" | 1276 "warning: " AS2-MDN-warning-description | 1277 "failure: " AS2-MDN-failure-description 1279 AS2-MDN-warning-description = *( TEXT ) 1281 AS2-MDN-failure-description = *( TEXT ) 1283 AS2-received-content-MIC-field = 1284 "Received-content-MIC" ":" encoded-message-digest "," 1285 digest-alg-id CRLF 1287 encoded-message-digest = 1288 1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' ) ( 1289 i.e. base64( message-digest ) ) 1291 digest-alg-id = "sha1" | "md5" 1293 "Insufficient-message-security" and "decompression-failed" are new 1294 error codes that are not mentioned in the AS1 RFC 3335, 1295 and may not be compatible with earlier implementations of AS2. 1297 The "Received-content-MIC" extension field is set when the integrity 1298 of the received message is verified. The MIC is the base64-encoded 1299 message-digest computed over the received message with a hash 1300 function. This field is required for signed receipts but optional for 1301 unsigned receipts. For details defining the specific content over 1302 which the message digest is to be computed, see Section 7.3.1 of 1303 this document. 1305 For signed messages, the algorithm used to calculate the MIC MUST be 1306 the same as the algorithm that was used on the message that was 1307 signed. If the message is not signed, then the SHA-1 algorithm SHOULD 1308 be used. This field is set only when the contents of the message are 1309 processed successfully. This field is used in conjunction with the 1310 recipient's signature on the MDN in order for the sender to verify 1311 non-repudiation of receipt. 1313 AS2-MDN field names ( e.g. "Disposition:", "Final-Recipient:") 1314 are case-insensitive ( cf. RFC 3798, 3.1.1 ). AS2-MDN action-modes, 1315 sending-modes, AS2-disposition-types, and AS2-disposition-modifier 1316 values that are defined above, and user-supplied *( TEXT ) values 1317 are also case insensitive. AS2 implementations MUST NOT make 1318 assumptions regarding the values supplied for AS2-MDN- 1319 warning-description, AS2-MDN-failure-description nor for the values 1320 of any (optional) error, warning, or failure fields. 1322 7.4.4 Additional AS2-MDN programming notes 1324 o Unlike SMTP, for HTTP transactions, Original-Recipient and 1325 Final-Recipient SHOULD not be different. The value in 1326 Original-Message-ID SHOULD match the original Message-ID 1327 header value. 1329 o Refer to RFC 3798 for the formatting of the MDN except for the 1330 specific deviations mentioned above. 1332 o Refer to RFC 3462 and RFC 3798 for the formatting of the 1333 content-type entity-headers for the MDN. 1335 o Use an action-mode of "automatic-action" when the disposition 1336 described by the disposition type was a result of an automatic 1337 action, rather than an explicit instruction by the user for 1338 this message. 1340 o Use an action-mode of "manual-action" when the disposition 1341 described by the disposition type was a result of an explicit 1342 instruction by the user rather than some sort of automatically 1343 performed action. 1345 o Use a sending-mode of "MDN-sent-automatically" when the MDN is 1346 sent because the UA had previously been configured to do so. 1348 o Use a sending-mode of "MDN-sent-manually" when the user 1349 explicitly gave permission for this particular MDN to be sent. 1351 o The sending-mode "MDN-sent-manually" is ONLY meaningful with 1352 "manual-action", not with "automatic-action". 1354 o The "failed" disposition type MUST NOT be used for the 1355 situation in which there is some problem in processing the 1356 message other than interpreting the request for an MDN. The 1357 "processed" or other disposition type with appropriate 1358 disposition modifiers is to be used in such situations. 1360 7.5 Disposition Mode, Type, and Modifier 1362 7.5.1 Disposition mode overview 1364 This section would provide a brief overview of how processed, error, 1365 failure, and warnings are used. 1367 7.5.2 Successful processing status indication 1369 When the request for a receipt or signed receipt, and the received 1370 message contents are successfully processed by the receiving EDI UA, 1371 a receipt or MDN SHOULD be returned with the disposition-type set 1372 to 'processed'. When the MDN is sent automatically by the EDI UA, and 1373 there is no explicit way for a user to control the sending of the 1374 MDN, then the first part of the "disposition-mode" SHOULD be set to 1375 "automatic-action". When the MDN is being sent under user 1376 configurable control, then the first part of the "disposition-mode" 1377 SHOULD be set to "manual-action". Since a request for a signed 1378 receipt should always be honored, the user MUST not be allowed to 1379 configure the UA to not send a signed receipt when the sender 1380 requests one. 1382 The second part of the disposition-mode is set to "MDN-sent-manually" 1383 if the user gave explicit permission for the MDN to be 1384 sent. Again, the user MUST not be allowed to explicitly refuse to 1385 send a signed receipt when the sender requests one. The second part 1386 of the "disposition-mode" is set to "MDN-sent-automatically" whenever 1387 the EDI UA sends the MDN automatically, regardless of whether the 1388 sending was under the control of a user, administrator, or software. 1390 Since EDI content is generally handled automatically by the EDI UA, a 1391 request for a receipt or signed receipt will generally return the 1392 following in the "disposition-field": 1394 Disposition: automatic-action/MDN-sent-automatically; processed 1396 Note this specification does not restrict the use of the 1397 "disposition-mode" to just automatic actions. Manual actions are 1398 valid as long as it is kept in mind that a request for a signed 1399 receipt MUST be honored. 1401 7.5.3 Unsuccessful processed content 1403 The request for a signed receipt requires the use of two 1404 "disposition-notification-options", which specify the protocol format 1405 of the returned signed receipt, and the MIC algorithm used to 1406 calculate the MIC over the message contents. The "disposition-field" 1407 values that should be used in the case where the message content is 1408 being rejected or ignored, for instance if the EDI UA determines that 1409 a signed receipt cannot be returned because it does not support the 1410 requested protocol format, so the EDI UA chooses not to process the 1411 message contents itself, MUST be specified in the MDN 1412 "disposition-field" as follows: 1414 Disposition: "disposition-mode"; failed/Failure: 1415 unsupported format 1417 The "failed" AS2-disposition-type MUST be used when a failure occurs 1418 that prevents the proper generation of an MDN. For example, this 1419 disposition-type would apply if the sender of the message requested 1420 the application of an unsupported message-integrity-check (MIC) 1421 algorithm. 1423 The "failure:" AS2-disposition-modifier-extension SHOULD be used with 1424 an implementation-defined description of the failure. Further 1425 information about the failure may be contained in a failure-field. 1427 The syntax of the "failed" disposition-type is general, allowing 1428 the sending of any textual information along with the "failed" 1429 disposition-type. Implementations MUST support any printable 1430 textual characters after the Failure disposition-type. For use in 1431 Internet EDI, the following "failed" values are pre-defined and MUST 1432 be supported: 1434 "Failure: unsupported format" 1436 "Failure: unsupported MIC-algorithms" 1438 7.5.4 Unsuccessful non-content processing 1440 When errors occur processing the received message other than content, 1441 the "disposition-field" MUST be set to the "processed" value of 1442 disposition-type and the "error" value for disposition-modifier. 1444 The "error" AS2-disposition-modifier with the "processed" 1445 disposition-type MUST be used to indicate that an error of some sort 1446 occurred that prevented successful processing of the message. Further 1447 information may be contained in an error-field. 1449 An "error:" AS2-disposition-modifier-extension SHOULD be used to 1450 combine the indication of an error with a predefined description of a 1451 specific, well-known error. Further information about the error may 1452 be contained in an error field. 1454 For internet EDI use, the following "error" AS2-disposition-modifier 1455 values are defined: 1457 o "Error: decryption-failed" - the receiver could 1458 not decrypt the 1459 message contents. 1461 o "Error: authentication-failed" - the receiver could not 1462 authenticate the sender. 1464 o "Error: integrity-check-failed" - the receiver could not 1465 verify content integrity. 1467 o "Error: unexpected-processing-error" - a catch-all for any 1468 additional processing 1469 errors. 1471 An example of how the "disposition-field" would look when other than 1472 content processing errors are detected is as follows: 1474 Example 1476 Disposition: "disposition-mode"; processed/Error: 1477 decryption-failed 1479 7.5.5 Processing warnings 1481 Situations arise in EDI where even if a trading partner cannot be 1482 authenticated correctly, the trading partners still agree to continue 1483 processing the EDI transactions. Transaction reconciliation is done 1484 between the trading partners at a later time. In the content 1485 processing warning situations as described above, the 1486 "disposition-field' MUST be set to the "processed" disposition-type 1487 value, and the "warning" "disposition-modifier" value. 1489 The "warning" AS2-disposition-modifier MUST be used with the 1490 "processed" disposition-type to indicate that the message was 1491 successfully processed but that an exceptional condition occurred. 1492 Further information may be contained in a warning-field. 1494 A "warning:" AS2-disposition-modifier-extension SHOULD be used to 1495 combine the indication of a warning with an implementation-defined 1496 description of the warning. Further information about the warning may 1497 be contained in an warning-field. 1499 For use in Internet EDI, the following "warning" 1500 disposition-modifier-extension value is defined: 1502 "Warning: authentication-failed, processing continued" 1504 An example of how the "disposition-field" would look when other than 1505 content processing warnings are detected is as follows: 1507 Example: 1509 Disposition: "disposition-mode"; processed/Warning: 1510 authentication-failed, processing continued 1512 7.5.6 Backwards compatibility with disposition type, modifier and 1513 extension 1515 The following set of examples represent typical constructions of the 1516 Disposition field that have been in use by AS2 implementations. This 1517 is NOT an exhaustive list of possible constructions. However, AS2 1518 implementations MUST accept constructions of this type to be backward 1519 compatible with earlier AS2 versions. 1521 Disposition: automatic-action/MDN-sent-automatically; processed 1523 Disposition: automatic-action/MDN-sent-automatically; 1524 processed/error: authentication-failed 1526 Disposition: automatic-action/MDN-sent-automatically; 1527 processed/warning: duplicate-document 1529 Disposition: automatic-action/MDN-sent-automatically; 1530 failed/failure: sender-equals-receiver 1532 The following set of examples represent allowable constructions of 1533 the Disposition field that combine the historic constructions above 1534 with optional RFC 3798 error, warning and failure fields. AS2 1535 implementations MAY produce these constructions. However, AS2 servers 1536 are not required to recognize or process optional error, warning, or 1537 failure fields at this time. Note that the use of the multiple Error 1538 fields in the second example below provides for the indication of 1539 multiple error conditions. 1541 Disposition: automatic-action/MDN-sent-automatically; processed 1543 Disposition: automatic-action/MDN-sent-automatically; 1544 processed/error: decryption-failed 1545 Error: The signature did not decrypt into a valid PKCS#1 1546 Type-2 block. 1547 Error: The length of the decrypted key does not equal the 1548 octet length of the modulus. 1550 Disposition: automatic-action/MDN-sent-automatically; 1551 processed/warning: duplicate-document 1552 Warning: An identical message already exists at the 1553 destination server. 1555 Disposition: automatic-action/MDN-sent-automatically; 1556 failed/failure: sender-equals-receiver 1557 Failure: The AS2-To name is identical to the AS2-From name. 1559 The following set of examples represent allowable constructions of 1560 the Disposition field but that employ pure RFC 3798 1561 Disposition-modifiers with optional error, warning and failure 1562 fields. These examples are provided as informational only. These 1563 constructions are not guaranteed to be backward compatible with 1564 AS2 implementations prior to version 1.1. 1566 Disposition: automatic-action/MDN-sent-automatically; processed 1568 Disposition: automatic-action/MDN-sent-automatically; 1569 processed/error 1570 Error: authentication-failed 1571 Error: The signature did not decrypt into a valid PKCS#1 Type-2 1572 block. 1573 Error: The length of the decrypted key does not equal the 1574 octet length of the modulus. 1576 Disposition: automatic-action/MDN-sent-automatically; 1577 processed/warning 1578 Warning: duplicate-document 1580 Disposition: automatic-action/MDN-sent-automatically; failed 1581 Failure: sender-equals-receiver 1583 7.6 Receipt Reply Considerations in a HTTP POST 1585 The details of the response to the POST command vary depending upon 1586 whether a receipt has been requested. 1588 With no extended header requesting a receipt, and no errors accessing 1589 the request-URI specified processing, the status line in the Response 1590 to the POST request SHOULD be in the 200 range. Status codes in the 1591 200 range SHOULD also be used when an entity is returned (a signed 1592 receipt in a multipart/signed content type or an unsigned receipt in 1593 a multipart/report). Even when the disposition of the data was an 1594 error condition at the authentication, decryption or other higher 1595 level, the HTTP status code SHOULD indicate success at the HTTP 1596 level. 1598 The HTTP server-side application may respond with an unsolicited 1599 multipart/report as a message body that the HTTP client might not 1600 have solicited, but this may be discarded by the client. Applications 1601 SHOULD avoid emitting unsolicited receipt replies because bandwidth 1602 or processing limitations might have led administrators to suspend 1603 asking for acknowledgements. 1605 Message Disposition Notifications, when used in the HTTP reply 1606 context, will closely parallel a SMTP MDN. For example, the 1607 disposition field is a required element in the machine readable 1608 second part of a multipart/report for a MDN. The 1609 final-recipient-field ([5] section 3.1) value SHOULD be derived 1610 from the entity headers of the request. 1612 In a MDN, the first part of the multipart/report (the 1613 "human-readable" part) SHOULD include items such as the subject, 1614 date and other information when those fields are present in entity 1615 header fields following the POST request. An application MUST report 1616 the Message-ID of the request in the second part of the 1617 multipart/report (the "machine-readable" part). Also, a MDN SHOULD 1618 have its own unique Message-ID HTTP header. The HTTP reply SHOULD 1619 normally omit the third optional part of the multipart/report (used 1620 to return the original message or its headers in the SMTP context). 1622 8.0 Public Key Certificate Handling 1624 In the near term, the exchange of public keys and certification of 1625 these keys MUST be handled as part of the process of establishing a 1626 trading partnership. The UA and/or EDI application interface must 1627 maintain a database of public keys used for encryption or signatures, 1628 in addition to the mapping between EDI trading partner ID and RFC 1629 822 [11] email address and http URL/URI. The procedures for 1630 establishing a trading partnership and configuring the secure EDI 1631 messaging system might vary among trading partners and software 1632 packages. 1634 X.509 certificates are REQUIRED. It is RECOMMENDED that trading 1635 partners self-certify each other if an agreed upon certification 1636 authority is not used. This applicability statement does NOT require 1637 the use of a certification authority. The use of a certification 1638 authority is therefore OPTIONAL. Certificates may be self-signed. 1640 It is RECOMMENDED that when trading partners are using S/MIME, that 1641 they also exchange public key certificates considering advice 1642 provided in [15]. 1644 The message formats useful for certificate exchange are found in 1645 [8] and [16]. 1647 In the long term, additional standards may be developed 1648 to simplify the process of establishing a trading partnership, 1649 including the third party authentication of trading partners, 1650 as well as attributes of the trading relationship. 1652 9.0 Security Considerations 1654 This entire document is concerned with secure transport of business 1655 to business data, and considers both data confidentiality and 1656 authentication issues. 1658 Extracted from RFC 3851 [8]: 1659 40-bit encryption is considered weak by most cryptographers. 1660 Using weak cryptography in S/MIME offers little actual security over 1661 sending plaintext. However, other features of S/MIME, such as the 1662 specification of tripleDES and the ability to announce stronger 1663 cryptographic capabilities to parties with whom you communicate, 1664 allow senders to create messages that use strong encryption. Using 1665 weak cryptography is never recommended unless the only alternative is 1666 no cryptography. When feasible, sending and receiving agents SHOULD 1667 inform senders and recipients of the relative cryptographic strength 1668 of messages. 1670 Extracted from RFC 3850 [15]: 1671 When processing certificates, there are many situations where the 1672 processing might fail. Because the processing may be done by a user 1673 agent, a security gateway, or other program, there is no single way 1674 to handle such failures. Just because the methods to handle the 1675 failures have not been listed, however, the reader should not assume 1676 that they are not important. The opposite is true: if a certificate 1677 is not provably valid and associated with the message, the processing 1678 software should take immediate and noticeable steps to inform the end 1679 user about it. 1681 Some of the many places where signature and certificate checking 1682 might fail include: 1684 o no certificate chain leads to a trusted CA 1685 o no ability to check the CRL for a certificate 1686 o an invalid CRL was received 1687 o the CRL being checked is expired 1688 o the certificate is expired 1689 o the certificate has been revoked 1691 There are certainly other instances where a certificate may be 1692 invalid, and it is the responsibility of the processing software to 1693 check them all thoroughly, and to decide what to do if the check 1694 fails. See RFC 3280 for additional information on certificate path 1695 validation. 1697 The following are additional security considerations to those listed 1698 in [8] and [15]. 1700 NRR Cautions 1702 This specification seeks to provide multiple mechanisms that can be 1703 combined in accordance with local policies to achieve a wide range 1704 of security needs as determined by threat and risk analyses of the 1705 business peers. It is required that all these mechanisms be 1706 implemented by AS2 software so that the software has capabilities 1707 that promote strong interoperability, no matter what policies are 1708 adopted. 1710 One strong cluster of mechanisms (the secure transmission loop) 1711 can provide good support for meeting the evidentiary needs 1712 of non-repudiation of receipt by the original sender and by 1713 a third party supplied with all stated evidence. However, this 1714 specification does not itself define non-repudiation of receipt 1715 nor enumerate its essential properties because NRR is a business 1716 analyst and/or legal requirement, and not relevantly defined 1717 by a technical applicability statement. 1719 Some analyses observe that non-repudiation of receipt presupposes 1720 that non-repudiation of the sender of the original message obtains, 1721 and further that non-repudiation should be implemented by means 1722 of digital signature on the original message. To satisfy strict 1723 NRR evidence, authentication and integrity MUST be provided by 1724 some mechanism, and the RECOMMENDED mechanism is to digitally 1725 sign both the original message and the receipt message. 1727 Given that this specification has selected several mechanisms that 1728 can be combined in several ways, it is important to realize that 1729 if a digital signature is omitted from the original message, in 1730 order to satisfy the preceding analysis of NRR requirements, some 1731 authentication mechanism MUST accompany the request for a signed 1732 receipt and its included Received-content-MIC value. This 1733 authentication might be from using client-side SSL, 1734 authentication via IPSEC, or use of HTTP authentication 1735 (while using SSL). In any case, records of the message content, 1736 its security basis, and the digest value need to be retained 1737 for the NRR process. 1739 So, if NRR is one of the goals of the policy that is adopted, 1740 by using the mechanisms of the secure transmission 1741 loop mentioned above and by retaining appropriate records of 1742 authentication at the original message sender site, strong 1743 evidentiary requirements proposed for NRR can be fulfilled. 1745 Other ways of proceeding may fall short of fulfilling the 1746 most stringent sets of evidence required for NRR to obtain, 1747 but may nevertheless have been agreed to as part of a 1748 commercial trading agreement and, as such, are good enough 1749 for the parties involved. However, if MDNs are returned 1750 unsigned, evidentiary requirements for NRR are weak; some 1751 authentication of the identity of the receiver is needed. 1753 HTTPS Remark 1755 The following certificate types MUST be supported for SSL 1756 server-side certificates. 1758 o with URL in the Distinguished Name Common Name attribute 1759 o without URL in the Distinguished Name Common Name attribute 1760 o self-signed (self-issued) 1761 o certification authority certified 1763 The URL, which matches the source server identity, SHOULD be carried 1764 in the certificate. However, it is not required to make DNS checks 1765 or reverse lookups to vouch for the accuracy of the URL or server 1766 value. Since server side certificates are to be exchanged and also 1767 trust established during the configuration of the trading partner 1768 relationship, runtime checks are not required by implementations 1769 of this specification. 1771 The complete certification chain MUST be included in all 1772 certificates. All certificate verifications MUST "chain to root" or 1773 to an accepted trust anchor. Additionally, the certificate hash 1774 SHOULD match the hash recomputed by the receiver. 1776 Replay Remark 1778 Because business data documents normally contain transaction ids, 1779 replays, like resends of not-yet-acknowledged messages, are discarded 1780 as part of the normal process of duplicate detection. Detection of 1781 duplicates by Message-Id or by business transaction identifiers is 1782 recommended. 1784 10.0 IANA Considerations 1786 RFC 3335 registered two Disposition-Notification-Options parameters 1788 Parameter-name: signed-receipt-protocol 1789 Parameter-name: signed-receipt-micalg 1791 that are also used by this specification (see section 7.3). 1793 RFC 3335 also registered on MDN Extension field name 1794 Extension field name: Received-content-MIC 1796 that is also used by this specification (see section 7.4.3). 1797 Registration of the above is therefore NOT needed. 1799 10.1 This specification defines an extension to the Message 1800 Disposition Notification (MDN) protocol for a disposition-modifier 1801 in the Disposition field of a body of content-type 1802 "message/disposition-notification". 1804 10.1.1 Disposition modifier 'warning' 1806 Parameter-name: warning 1807 Semantics: (see sections 7.4.3 and 7.5.5 of this document) 1809 11.0 Acknowledgements 1811 Carl Hage, Karen Rosenfeld, Chuck Fenton and many others have 1812 provided valuable suggestions improving this applicability statement. 1813 The authors would also like to thank the vendors who participated in 1814 the Drummond Group Inc. AS2 interoperability testing. Their 1815 contributions led to great improvement in the clarity of this 1816 document. 1818 12.0 References 1820 12.1 Normative References 1822 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 1823 (MIME) 1824 Part One: Format of Internet Message Bodies", RFC 2045, 1825 December 02, 1996. 1827 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1828 Extensions (MIME) 1829 Part Two: Media Types", RFC 2046, December 02, 1996. 1831 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1832 Extensions (MIME) 1833 Part Five: Conformance Criteria and Examples", RFC 2049, 1834 December 02, 1996. 1836 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 1837 March 2, 1995. 1839 [3] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners- Lee, 1840 "Hypertext Transfer Protocol--HTTP/1.1", RFC 2616, March 1997. 1842 [4] T. Harding, R. Drummond, C. Shih, "Peer-to-Peer MIME-based 1843 Secure Business Data Interchange", RFC 3335, September 2002. 1845 [5] T. Hansen, G. Vaudreuil, "Message Disposition Notification", RFC 1846 3798, May 2004. 1848 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 1849 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1850 1847, Oct. 3, 1995 1852 [8] B. Ramsdell "S/MIME Version 3.1 Message Specification, RFC 3851, 1853 July 2004. 1855 [9] G. Vaudreuil, "The Multipart/Report Content Type for the 1856 Reporting of Mail System Administrative Messages", RFC 3462, January, 1857 2003. 1859 [11] D. Crocker, "Standard for the Format of ARPA Internet Text 1860 Messages", STD 11, RFC 822, August 13, 1982. 1862 [12] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", RFC 3023, 1863 January 2001. 1865 [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1866 Levels", BCP 14, RFC 2119, March 1997. 1868 [14] Bradner, S., "The Internet Standards Process -- Revision 3", 1869 RFC 2026, October 1996. 1871 [15] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1872 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July, 2004. 1874 [16] R. Housley "Cryptographic Message Syntax CMS", RFC 3852, 1875 July 2004. 1877 12.2 Informative References 1879 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 1880 August 1, 1982. 1882 [10] T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246, 1883 March 1999. 1885 [17] D. Crocker, "Augmented BNF for Syntax Specifications: ABNF", RFC 1886 2234, November, 1997. 1888 13.0 Authors' Addresses 1890 Dale Moberg 1891 dmoberg@cyclonecommerce.com 1892 Cyclone Commerce 1893 8388 E. Hartford Drive, Suite 100 1894 Scottsdale, AZ 85255 USA 1896 Rik Drummond 1897 rvd2@drummondgroup.com 1898 Drummond Group Inc. 1899 4700 Bryant Irvin Court, Suite 303 1900 Fort Worth, TX 76107 USA 1902 Copyright Notice 1904 Copyright (C) The Internet Society (2004). This document is subject 1905 to the rights, licenses and restrictions contained in BCP 78, and 1906 except as set forth therein, the authors retain all their rights. 1908 This document and the information contained herein are provided on an 1909 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1910 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1911 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1912 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1913 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1914 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1916 Appendices 1918 A. Message Examples 1920 NOTE: All examples are provided as an illustration only, and are not 1921 considered part of the protocol specification. If an example 1922 conflicts with the protocol definitions specified above or in the 1923 other referenced RFC's, the example is wrong. 1925 A.1 Signed message requesting a signed, synchronous receipt 1927 POST /receive HTTP/1.0 1928 Host: 10.234.160.12:80 1929 User-Agent: AS2 Company Server 1930 Date: Wed, 31 Jul 2002 13:34:50 GMT 1931 From: mrAS2@example.com 1932 AS2-Version: 1.1 1933 AS2-From: "\" as2Name \"" 1934 AS2-To: 0123456780000 1935 Subject: Test Case 1936 Message-Id: <200207310834482A70BF63@\"~~foo~~\"> 1937 Disposition-Notification-To: mrAS2@example.com 1938 Disposition-Notification-Options: signed-receipt-protocol=optional, 1939 pkcs7-signature; signed-receipt-micalg=optional,sha1 1940 Content-Type: multipart/signed; boundary="as2BouNdary1as2"; 1941 protocol="application/pkcs7-signature"; micalg=sha1 1942 Content-Length: 2464 1943 --as2BouNdary1as2 1944 Content-Type: application/edi-x12 1945 Content-Disposition: Attachment; filename=rfc1767.dat 1946 [ISA ...EDI transaction data...IEA...] 1948 --as2BouNdary1as2 1949 Content-Type: application/pkcs7-signature 1951 [omitted binary pkcs7 signature data] 1952 --as2BouNdary1as2-- 1954 A.2 MDN for Message A.1 Above 1956 HTTP/1.0 200 OK 1957 AS2-From: 0123456780000 1958 AS2-To: "\" as2Name \"" 1959 AS2-Version: 1.1 1960 Message-ID: <709700825.1028122454671.JavaMail@ediXchange> 1961 Content-Type: multipart/signed; micalg=sha1; 1962 protocol="application/pkcs7-signature"; 1963 boundary="----=_Part_57_648441049.1028122454671" 1964 Connection: Close 1965 Content-Length: 1980 1967 ------=_Part_57_648441049.1028122454671 1969 & Content-Type: multipart/report; 1970 & Report-Type=disposition-notification; 1971 & boundary="----=_Part_56_1672293592.1028122454656" 1972 & 1973 &------=_Part_56_1672293592.1028122454656 1974 &Content-Type: text/plain 1975 &Content-Transfer-Encoding: 7bit 1976 & 1977 &MDN for - 1978 & Message ID: <200207310834482A70BF63@\"~~foo~~\"> 1979 & From: "\" as2Name \"" 1980 & To: "0123456780000" 1981 & Received on: 2002-07-31 at 09:34:14 (EDT) 1982 & Status: processed 1983 & Comment: This is not a guarantee that the message has 1984 & been completely processed or &understood by the receiving 1985 & translator 1986 & 1987 &------=_Part_56_1672293592.1028122454656 1988 &Content-Type: message/disposition-notification 1989 &Content-Transfer-Encoding: 7bit 1990 & 1991 &Reporting-UA: AS2 Server 1992 &Original-Recipient: rfc822; 0123456780000 1993 &Final-Recipient: rfc822; 0123456780000 1994 &Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\"> 1995 &Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1 1996 &Disposition: automatic-action/MDN-sent-automatically; 1997 & processed 1998 & 1999 &------=_Part_56_1672293592.1028122454656-- 2001 ------=_Part_57_648441049.1028122454671 2002 Content-Type: application/pkcs7-signature; name=smime.p7s 2003 Content-Transfer-Encoding: base64 2004 Content-Disposition: attachment; filename=smime.p7s 2006 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ 2007 cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA 2008 ------=_Part_57_648441049.1028122454671-- 2010 Notes: 2012 1. The lines proceeded with "&" is what the signature is 2013 calculated over. 2014 2. For details on how to prepare the multipart/signed with protocol = 2015 "application/pkcs7-signature" see the "S/MIME Message Specification, 2016 PKCS Security Services for MIME".) 2017 3. Note that the textual first body part of the multipart/report can 2018 be used to include a more detailed explanation of the error 2019 conditions reported by the disposition headers. The first body part 2020 of the multipart/report when used in this way, allows a person to 2021 better diagnose a problem in detail. 2022 4. As specified by RFC 3462 [9], returning the original or portions 2023 of the original message in the third body part of the 2024 multipart/report is not required. This is an optional body part. 2025 However, it is RECOMMENDED that this body part be omitted or left 2026 blank. 2028 A.3 Signed, encrypted message requesting a signed, asynchronous 2029 receipt 2031 Message-ID: <#as2_company#01#a4260as2_companyout#> 2032 Date: Thu, 19 Dec 2002 15:04:18 GMT 2033 From: me@example.com 2034 Subject: Async MDN request 2035 Mime-Version: 1.0 2036 Content-Type: application/pkcs7-mime; 2037 smime-type=enveloped-data; name=smime.p7m 2038 Content-Transfer-Encoding: binary 2039 Content-Disposition: attachment; filename=smime.p7m 2040 Recipient-Address: 10.240.1.2// 2041 Disposition-Notification-To: 2043 http://10.240.1.2:8201/exchange/as2_company 2044 Disposition-Notification-Options: signed-receipt-protocol=optional, 2045 pkcs7-signature; signed-receipt-micalg=optional,sha1 2046 Receipt-Delivery-Option: 2047 http://10.240.1.2:8201/exchange/as2_company 2048 AS2-From: as2_company 2049 AS2-To: "AS2 Test" 2050 AS2-Version: 1.1 2051 Host: 10.240.1.2:8101 2052 Connection: close 2053 Content-Length: 3428 2055 [omitted binary encrypted data] 2057 A.4 Asynchronous MDN for Message A.3 Above 2059 POST / HTTP/1.1 2060 Host: 10.240.1.2:8201 2061 Connection: close, TE 2062 TE: trailers, deflate, gzip, compress 2063 User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000) 2064 Date: Thu, 19 Dec 2002 15:03:38 GMT 2065 Message-ID: 2066 AS2-Version: 1.1 2067 Mime-Version: 1.0 2068 Recipient-Address: 2069 http://10.240.1.2:8201/exchange/as2_company 2070 AS2-To: as2_company 2071 AS2-From: "AS2 Test" 2072 Subject: Your Requested MDN Response 2073 From: as2debug@example.com 2074 Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress 2075 Content-Type: multipart/signed; micalg=sha1; 2076 protocol="application/pkcs7-signature"; 2077 boundary="----=_Part_337_6452266.1040310218750" 2078 Content-Length: 3103 2080 ------=_Part_337_6452266.1040310218750 2081 Content-Type: multipart/report; 2082 report-type=disposition-notification; 2083 boundary="----=_Part_336_6069110.1040310218718" 2085 ------=_Part_336_6069110.1040310218718 2086 Content-Type: text/plain; charset=us-ascii 2087 Content-Transfer-Encoding: 7bit 2089 The message sent to Recipient on Thu, 19 Dec 2090 2002 15:04:18 GMT with Subject has been received, 2091 the EDI Interchange was successfully decrypted and its integrity was 2092 verified. In addition, the sender of the message, Sender 2093 at Location http://10.240.1.2:8201/exchange/as2_company 2094 was authenticated as the originator of the message. There is no 2095 guarantee however that the EDI interchange was syntactically correct, 2096 or was received by the EDI application/translator. 2098 ------=_Part_336_6069110.1040310218718 2099 Content-Type: message/disposition-notification 2100 Content-Transfer-Encoding: 7bit 2102 Reporting-UA: AS2@test:8101 2103 Original-Recipient: rfc822; "AS2 Test" 2104 Final-Recipient: rfc822; "AS2 Test" 2105 Original-Message-ID: <#as2_company#01#a4260as2_companyout#> 2106 Disposition: automatic-action/MDN-sent-automatically; 2107 processed 2108 Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1 2110 ------=_Part_336_6069110.1040310218718-- 2112 ------=_Part_337_6452266.1040310218750 2113 Content-Type: application/pkcs7-signature; name=smime.p7s 2114 Content-Transfer-Encoding: base64 2115 Content-Disposition: attachment; filename=smime.p7s 2117 BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM 2118 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j 2119 UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA= 2121 ------=_Part_337_6452266.1040310218750- 2123 Intellectual Property 2125 The IETF takes no position regarding the validity or scope of any 2126 Intellectual Property Rights or other rights that might be claimed 2127 to pertain to the implementation or use of the technology 2128 described in this document or the extent to which any license 2129 under such rights might or might not be available; nor does it 2130 represent that it has made any independent effort to identify any 2131 such rights. Information on the procedures with respect to 2132 rights in RFC documents can be found in BCP 78 and BCP 79. 2134 Copies of IPR disclosures made to the IETF Secretariat and any 2135 assurances of licenses to be made available, or the result of an 2136 attempt made to obtain a general license or permission for the use 2137 of such proprietary rights by implementers or users of this 2138 specification can be obtained from the IETF on-line IPR repository 2139 at http://www.ietf.org/ipr. 2141 The IETF invites any interested party to bring to its attention 2142 any copyrights, patents or patent applications, or other 2143 proprietary rights that may cover technology that may be required 2144 to implement this standard. Please address the information to the 2145 IETF at ietf-ipr@ietf.org. 2147 Copyright (C) The Internet Society (2004). This document is subject 2148 to the rights, licenses and restrictions contained in BCP 78, and 2149 except as set forth therein, the authors retain all their rights. 2151 This document and the information contained herein are provided on an 2152 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2153 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2154 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2155 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2156 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2157 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.