idnits 2.17.1 draft-ietf-ediint-as1-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 48 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 308 has weird spacing: '...non-use of...' == Line 329 has weird spacing: '...ication is re...' == Line 966 has weird spacing: '...quested proto...' == Line 1180 has weird spacing: '...ions of the o...' == 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 a user's, administrator's, or under software control. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2298 (ref. '5') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2630 (ref. '8') (Obsoleted by RFC 3369, RFC 3370) -- No information found for draft-ietf-ediint-req07 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 1892 (ref. '10') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 2068 (ref. '11') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Informational RFC: RFC 1952 (ref. '12') Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EDIINT Working Group T. Harding 2 Internet draft Cyclone Software 3 Expires: Mar / 2000 R. Drummond 4 Drummond Group 5 September, 1999 7 MIME-based Secure EDI 9 draft-ietf-ediint-as1-10.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Any questions, comments, and reports of defects or ambiguities in 34 this specification may be sent to the mailing list for the EDIINT 35 working group of the IETF, using the address 36 . Requests to subscribe to the mailing list 37 should be addressed to . 39 Copyright Notice 41 Copyright (c) The Internet Society (1998). All rights reserved. 43 Abstract 45 This document describes how to securely exchange EDI and other 46 business related documents using MIME and public key 47 cryptography. 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 50 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 51 "OPTIONAL" in this document are to be interpreted as described in 52 RFC 2119. 54 Feedback Instructions: 56 If you want to provide feedback on this draft, follow these 57 guidelines: 59 -Send feedback via e-mail to the ietf-ediint list for discussion, 60 with "AS#1" in the Subject field. To enter or follow the 61 discussion, you need to subscribe to ietf-ediint@imc.org. 63 -Be specific as to what section you are referring to, preferably 64 quoting the portion that needs modification, after which you 65 state your comments. 67 -If you are recommending some text to be replaced with your 68 suggested text, again, quote the section to be replaced, and be 69 clear on the section in question. 71 Table of Contents 73 Security Considerations 3 74 1.0 Introduction 3 75 2.0 Overview 4 76 2.1 Purpose of a security guideline for MIME EDI 4 77 2.2 Definitions 4 78 2.2.1. Terms 4 79 2.2.2 The secure transmission loop 5 80 2.2.3 Definition of receipts 5 81 2.3 Assumptions 6 82 2.3.1 EDI process assumptions 6 83 2.3.2 Flexibility assumptions 7 84 3.0 Referenced RFCs and their contribution 8 85 3.1 RFC 821 SMTP [7] 8 86 3.2 RFC 822 Text Message Format [3] 8 87 3.3 RFC 1847 MIME Security Multiparts [6] 9 88 3.4 RFC 1892 Multipart/report [10] 9 89 3.5 RFC 1767 EDI Content [2] 9 90 3.6 RFC 2015 PGP/MIME [4] 9 91 3.7 RFC 2045, 2046, and 2049 MIME [1] 9 92 3.8 RFC 2298 Message Disposition Notification [5] 9 93 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 9 94 4.0 Structure of an EDI MIME message - Applicability 10 95 4.1 Introduction 10 96 4.2 Structure of an EDI MIME message - PGP/MIME 10 97 4.2.1 No encryption, no signature 10 98 4.2.2 No encryption, signature 10 99 4.2.3 Encryption, no signature 10 100 4.2.4 Encryption, signature 10 101 4.3 Structure of an EDI MIME message - S/MIME 11 102 4.3.1 No encryption, no signature 11 103 4.3.2 No encryption, signature 11 104 4.3.3 Encryption, no signature 11 105 4.3.4 Encryption, signature 11 106 5.0 Receipts 11 107 5.1 Introduction 11 108 5.2 Requesting a signed receipt 14 109 5.2.1 Additional Signed Receipt Considerations 16 110 5.3 Message Disposition Notification Format 17 111 5.3.1 Message Disposition Notification Extensions 18 112 5.3.2 Disposition Mode, Type, and Modifier Use 19 113 5.4 Message Disposition Notification Processing 21 114 5.4.1 Large File Processing 21 115 5.4.2 Example 23 116 6.0 Public key certificate handling 25 117 6.1 Near term approach 25 118 6.2 Long term approach 25 119 7.0 Acknowledgments 25 120 8.0 References 26 121 9.0 Authors' Addresses 27 123 Security Considerations 125 This document discusses the mechanisms, requirements and 126 Technologies necessary to conduct secure EDI over Internet using 127 either PGP/MIME or S/MIME. It further discusses the 128 implementation of encryption, digital signature, integrity and 129 signed-receipt for MIME objects transported over SMTP, HTTP or 130 FTP. 132 1.0 Introduction 134 Previous work on Internet EDI focused on specifying MIME content 135 Types for EDI data ([2] RFC 1767). This Applicability Statement 136 expands on RFC 1767 to specify use of a comprehensive set of data 137 security features, specifically data privacy, data 138 integrity/authenticity, non-repudiation of origin and non- 139 repudiation of receipt. This draft recognizes contemporary RFCs 140 and Internet drafts and is attempting to "re-invent" as little as 141 possible. 143 With an enhancement in the area of "receipts", as described below 144 (3.1.8), secure Internet MIME based EDI can be accomplished by 145 using and complying with the following RFCs: 147 -RFC 821 SMTP 148 -RFC 822 Text Message Formats 149 -RFC 1767 EDI Content Type 150 -RFC 1847 Security Multiparts for MIME 151 -RFC 1892 Multipart/Report 152 -RFC 2015 MIME/PGP 153 -RFC 2045 to 2049 MIME RFCs 154 -RFC 2298 Message Disposition Notification 155 -RFC 2630, 2633 S/MIME v3 Specification 157 Our intent here is to define clearly and precisely how these are 158 Used together, and what is required by user agents to be 159 compliant with this Applicability Statement. 161 2.0 Overview 163 2.1 Purpose of a security guideline for MIME EDI 165 The purpose of these specifications is to ensure interoperability 166 between EDI user agents, invoking some or all of the commonly 167 expected security features. This standard is also NOT limited to 168 strict EDI use, but applies to any electronic commerce 169 application where business data needs to be exchanged over the 170 Internet in a secure manner. 172 2.2 Definitions 174 2.2.1. Terms 176 EDI Electronic Data Interchange 178 EC Electronic Commerce 180 Receipt The functional message that is sent from a 181 receiver to a sender to acknowledge 182 receipt of an EDI/EC interchange. 184 Signed Receipt Same as above, but with a digital 185 signature. 187 Message Disposition The Internet messaging format used to 188 Notification convey a receipt. This term is used 189 interchangeably with receipt. A signed 190 MDN is a signed receipt. 192 Non-repudiation of NRR is a "legal event" that occurs when 193 Receipt (NRR) the original sender of an EDI/EC 194 interchange has verified the signed 195 receipt coming back from the receiver. 196 NRR IS NOT a functional or a technical 197 message. 199 PGP/MIME Digital envelope security based on the 200 Pretty Good Privacy (PGP) standard 201 (Zimmerman), integrated with MIME Security 202 Multiparts [6]. 204 S/MIME A format and protocol for adding 205 Cryptographic signature and/or encryption 206 services to Internet MIME messages. 208 2.2.2 The secure transmission loop 210 The functional requirements document, [9] "Requirements for 211 Inter-operable Internet EDI" (can be found at www.ietf.org), 212 Provides extensive information on EDI security and the 213 user/business related processes surrounding the need for and use 214 of EDI security. In this document, it is assumed that the reader 215 is familiar with the requirements document. 217 This document's focus is on the formats and protocols for 218 Exchanging EDI content that has had security applied to it using 219 the Internet's messaging transport. 221 The "secure transmission loop" for EDI involves one organization 222 sending a signed and encrypted EDI interchange to another 223 organization, requesting a signed receipt, followed later by the 224 receiving organization sending this signed receipt back to the 225 sending organization. In other words, the following transpires: 227 -The organization sending EDI/EC data signs and encrypts the 228 data using either PGP/MIME or S/MIME. In addition, the message 229 will request a signed receipt to be returned to the sender of 230 the message. 232 -The receiving organization decrypts the message and verifies 233 the signature, resulting in verified integrity of the data and 234 authenticity of the sender. 236 -The receiving organization then returns a signed receipt to 237 the sending organization in the form of a message disposition 238 notification message. This signed receipt will contain the 239 hash of the signature from the received message, indicating to 240 the sender that the received message was verified and/or 241 decrypted properly. 243 The above describes functionality which if implemented, would 244 Satisfy all security requirements. This specification, however, 245 leaves full flexibility for users to decide the degree to which 246 they want to deploy those security features with their EDI 247 trading partners. 249 2.2.3 Definition of receipts 251 The term used for both the functional activity and message for 252 acknowledging receipt of an EDI/EC interchange is receipt, or 253 signed receipt. The first term is used if the acknowledgment is 254 for an interchange resulting in a receipt which is NOT signed. 255 The second term is used if the acknowledgment is for an 256 interchange resulting in a receipt which IS signed. 258 The "rule" is: 260 - If a receipt is requested, explicitly specifying that the 261 receipt be signed, then the receipt MUST be returned with a 262 signature. 264 - If a receipt is requested, explicitly specifying that the 265 receipt be signed, but the recipient cannot support the 266 requested protocol format or requested MIC algorithms, then a 267 receipt, either signed or unsigned SHOULD be returned. 269 - If a signature is not explicitly requested, or if the signed 270 receipt request parameter is not recognized by the UA, a 271 receipt may or may not be returned. This behavior is 272 consistent with the MDN RFC 2298. 274 A term often used in combination with receipts is "Non- 275 Repudiation of Receipt (NRR). NRR refers to a legal event which 276 occurs only when the original sender of an interchange has 277 verified the signed receipt coming back from recipient of the 278 message. Note that NRR is not possible without signatures. 280 2.3 Assumptions 282 2.3.1 EDI process assumptions 284 -Encrypted object is an EDI Interchange 286 This specification assumes that a typical EDI interchange is the 287 lowest level object that will be subject to security services. 289 In ANSI X12, this means anything between, and including segments 290 ISA and IEA. In EDIFACT, this means anything between, and 291 including, segments UNA/UNB and UNZ. In other words, the EDI 292 interchanges including envelope segments remain intact and 293 unreadable during secure transport. 295 -EDI envelope headers are encrypted 296 Congruent with the above statement, EDI envelope headers are NOT 297 visible in the MIME package. In order to optimize VAN-to- 298 Internet routing, work may need to be done in the future to 299 define ways to pull out some of the envelope information to make 300 them visible, however, this specification does not go into any 301 detail on that. 303 -X12.58 and UN/EDIFACT security considerations 305 The most common EDI standards bodies, ANSI X12 and EDIFACT, have 306 defined internal provisions for security. X12.58 is the 307 security mechanism for ANSI X12 and AUTACK provides security for 308 EDIFACT. This specification DOES NOT dictate use or non-use of 309 these security standards. They are both fully compatible, 310 though possibly redundant, with this specification. 312 2.3.2 Flexibility assumptions 314 -Encrypted or un-encrypted data 316 This specification allows for EDI message exchange where the EDI 317 Data can either be un-protected or protected by means of 318 encryption. 320 -Signed or un-signed data 322 This specification allows for EDI message exchange with or 323 Without digital signature of the original EDI transmission. 325 -Use of receipt or not 327 This specification allows for EDI message transmission with or 328 Without a request for receipt notification. If a signed receipt 329 notification is requested however, a mic value is REQUIRED as 330 part of the returned receipt, unless an error condition occurs 331 in which a mic value cannot be returned. In error cases, an un- 332 signed receipt or MDN SHOULD be returned with the correct 333 "disposition modifier" error value. 335 -Formatting choices 337 This specification defines the use of two methods for formatting 338 EDI contents that have security applied to it: 340 -PGP/MIME 341 -S/MIME 343 This specification relies on the guidelines set forth in RFC 344 2015, as reflected in [4] "MIME Security with Pretty Good 345 Privacy" (PGP), and RFC 2633/ 2630 [8] "S/MIME Version 3 346 Message Specification; Cryptographic Message Syntax". Compliance 347 with this specification REQUIRES the use of PGP/MIME or S/MIME 348 as defined in this Applicability statement, and the [9] 349 "Requirements for Inter-operable Internet EDI" draft. 351 -Hash function, message digest choices 353 When a signature is used, it is RECOMMENDED that the SHA1 hash 354 algorithm be used for all outgoing messages, and that both MD5 355 and SHA1 be supported for incoming messages. 357 In summary, the following eight permutations are possible in any 358 given trading relationship: 360 (1) Sender sends un-encrypted data, does NOT request a receipt. 362 (2) Sender sends un-encrypted data, requests a signed or 363 unsigned receipt. The receiver sends back the signed or 364 unsigned receipt. 366 (3) Sender sends encrypted data, does NOT request a receipt. 368 (4) Sender sends encrypted data, requests a signed or unsigned 369 receipt. The receiver sends back the signed or un-signed 370 receipt. 372 (5) Sender sends signed data, does NOT request a signed or un- 373 signed receipt. 375 (6) Sender sends signed data, requests a signed or un-signed 376 receipt. Receiver sends back the signed or un-signed 377 receipt. 379 (7) Sender sends encrypted and signed data, does NOT request a 380 signed or un-signed receipt. 382 (8) Sender sends encrypted and signed data, requests a signed or 383 un-signed receipt. Receiver sends back the signed or un- 384 signed receipt. 386 NOTE: Users can choose any of the eight possibilities, but only 387 example (8), when a signed receipt is requested, offers the 388 whole suite of security features described in the "Secure 389 transmission loop" above. 391 3.0 Referenced RFCs and their contribution 393 3.1 RFC 821 SMTP [7] 395 This is the core mail transfer standard that all MTAs need to 396 Adhere to. 398 3.2 RFC 822 Text Message Format [3] 400 Defines message header fields and the parts making up a message. 402 3.3 RFC 1847 MIME Security Multiparts [6] 404 This document defines security multiparts for MIME: 405 multipart/encrypted and multipart/signed. 407 3.4 RFC 1892 Multipart/report [10] 409 This RFC defines the use of the multipart/report content type, 410 something that the MDN RFC 2298 builds upon. 412 3.5 RFC 1767 EDI Content [2] 414 This RFC defines the use of content type "application" for ANSI 415 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 416 Mutually defined EDI (application/EDI-Consent). 418 3.6 RFC 2015 PGP/MIME [4] 420 This RFC defines the use of content types "multipart/encrypted", 421 "multipart/signed", "application/pgp encrypted" and 422 "application/pgp-signature" for defining MIME PGP content. 424 3.7 RFC 2045, 2046, and 2049 MIME [1] 426 These are the basic MIME standards, upon which all MIME related 427 RFCs build, including this one. Key contributions include 428 definition of "content type", "sub-type" and "multipart", as well 429 as encoding guidelines, which establishes 7-bit US-ASCII as the 430 canonical character set to be used in Internet messaging. 432 3.8 RFC 2298 Message Disposition Notification [5] 434 This Internet RFC defines how a message disposition notification 435 (MDN) is requested, and the format and syntax of the MDN. The MDN 436 is the basis upon which receipts and signed receipts are defined 437 in this and the "Requirements" specification. 439 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 441 This specification describes how MIME shall carry CMS Objects. 443 4.0 Structure of an EDI MIME message - Applicability 445 4.1 Introduction 447 The structures below are described hierarchically in terms of 448 Which RFC's are applied to form the specific structure. For 449 details of how to code in compliance with all RFC's involved, 450 turn directly to the RFC's referenced. The "requirements 451 document" has several examples described in an Appendix for those 452 interested. 454 Also, these structures describe the initial transmission only. 455 Receipts, and requests for receipts are handled in section 5. 457 4.2 Structure of an EDI MIME message - PGP/MIME 459 4.2.1 No encryption, no signature 461 -RFC822/2045 462 -RFC1767 (application/EDIxxxx) 464 4.2.2 No encryption, signature 466 -RFC822/2045 467 -RFC1847 (multipart/signed) 468 -RFC1767 (application/EDIxxxx) 469 -RFC2015 (application/pgp-signature) 471 4.2.3 Encryption, no signature 473 -RFC822/2045 474 -RFC1847 (multipart/encrypted) 475 -RFC2015 (application/pgp-encrypted) 476 -"Version: 1" 477 -RFC2015 (application/octet-stream) 478 -RFC1767 (application/EDIxxxx) (encrypted) 480 4.2.4 Encryption, signature 482 -RFC822/2045 483 -RFC1847 (multipart/encrypted) 484 -RFC2015 (application/pgp-encrypted) 485 -"Version: 1" 486 -RFC2015 (application/octet-stream) 487 -RFC1847 (multipart/signed)(encrypted) 488 -RFC1767 (application/EDIxxxx)(encrypted) 489 -RFC2015 (application/pgp-signature)(encrypted) 491 4.3 Structure of an EDI MIME message - S/MIME 493 4.3.1 No encryption, no signature 495 -RFC822/2045 496 -RFC1767 (application/EDIxxxx) 498 4.3.2 No encryption, signature 500 -RFC822/2045 501 -RFC1847 (multipart/signed) 502 -RFC1767 (application/EDIxxxx) 503 -RFC2633 (application/pkcs7-signature) 505 4.3.3 Encryption, no signature 507 -RFC822/2045 508 -RFC2633 (application/pkcs7-mime) 509 -RFC1767 (application/EDIxxxx) (encrypted) 511 4.3.4 Encryption, signature 513 -RFC822/2045 514 -RFC2633 (application/pkcs7-mime) 515 -RFC1847 (multipart/signed) (encrypted) 516 -RFC1767 (application/EDIxxxx) (encrypted) 517 -RFC2633 (application/pkcs7-signature) (encrypted) 519 5.0 Receipts 521 5.1 Introduction 523 In order to support non-repudiation of receipt (NRR), a signed 524 receipt, based on digitally signing a message disposition 525 notification, is to be implemented by a receiving trading 526 partner's UA (User Agent). The message disposition notification, 527 specified by RFC 2298 is digitally signed by a receiving trading 528 partner as part of a multipart/signed MIME message. 530 The following support for signed receipts is REQUIRED: 532 1). The ability to create a multipart/report; where the report- 533 type = disposition-notification. 535 2). The ability to calculate a message integrity check (MIC) on 536 the received message. The calculated MIC value will be 537 returned to the sender of the message inside the signed 538 receipt. 540 4). The ability to create a multipart/signed content with the 541 message disposition notification as the first body part, and 542 the signature as the second body part. 544 5). The ability to return the signed receipt to the sending 545 trading partner. 547 The signed receipt is used to notify a sending trading partner 548 that requested the signed receipt that: 550 1). The receiving trading partner acknowledges receipt of the 551 sent EDI Interchange. 553 2). If the sent message was signed, then the receiving trading 554 partner has authenticated the sender of the EDI Interchange. 556 3). If the sent message was signed, then the receiving trading 557 partner has verified the integrity of the sent EDI 558 Interchange. 560 Regardless of whether the EDI Interchange was sent in S/MIME or 561 PGP/MIME format, the receiving trading partner's UA MUST provide 562 the following basic processing: 564 1). If the sent EDI Interchange is encrypted, then the encrypted 565 symmetric key and initialization vector (if applicable) is 566 decrypted using the receiver's private key. 568 2). The decrypted symmetric encryption key is then used to 569 decrypt the EDI Interchange. 571 3). The receiving trading partner authenticates signatures in a 572 message using the sender's public key. The authentication 573 algorithm performs the following: 575 a). The message integrity check (MIC or Message Digest), 576 is decrypted using the sender's public key. 578 b). A MIC on the signed contents (the MIME header and 579 encoded EDI object, as per RFC 1767) in the message 580 received is calculated using the same one-way hash 581 function that the sending trading partner used. 583 c). The MIC extracted from the message that was sent, and 584 the MIC calculated using the same one-way hash function 585 that the sending trading partner used is compared for 586 equality. 588 4). The receiving trading partner formats the MDN and sets the 589 calculated MIC into the "Received-content-MIC" extension 590 field. 592 5). The receiving trading partner creates a multipart/signed MIME 593 message according to RFC 1847. 595 6). The MDN is the first part of the multipart/signed message, 596 and the digital signature is created over this MDN, including 597 its MIME headers. 599 7). The second part of the multipart/signed message contains the 600 digital signature. The "protocol" option specified in the 601 second part of the multipart/signed is as follows: 603 S/MIME: protocol = "application/pkcs-7-signature" 605 PGP/MIME: protocol = "application/pgp-signature" 607 8). The signature information is formatted according to S/MIME or 608 PGP/MIME specifications. 610 The EDI Interchange and the RFC 1767 MIME EDI content header, can 611 actually be part of a multi-part MIME content-type. When the EDI 612 Interchange is part of a multi-part MIME content-type, the MIC 613 MUST be calculated across the entire multi-part content, 614 including the MIME headers. 616 The signed MDN, when received by the sender of the EDI 617 Interchange can be used by the sender: 619 1). As an acknowledgment that the EDI Interchange sent, was 620 delivered and acknowledged by the receiving trading 621 partner. The receiver does this by returning the original 622 message id of the sent message in the MDN portion of the 623 signed receipt. 625 2). As an acknowledgment that the integrity of the EDI 626 Interchange was verified by the receiving trading partner. 627 The receiver does this by returning the calculated MIC of 628 the received EDI Interchange (and 1767 MIME headers) in the 629 "Received-content-MIC" field of the signed MDN. 631 3). As an acknowledgment that the receiving trading partner has 632 authenticated the sender of the EDI Interchange. 634 4). As a non-repudiation of receipt when the signed MDN is 635 successfully verified by the sender with the receiving 636 trading partner's public key and the returned mic value 637 inside the MDN is the same as the digest of the original 638 message. 640 5.2 Requesting a signed receipt 642 Message Disposition Notifications are requested as per RFC 2298, 643 "An Extensible Message Format for Message Disposition 644 Notification". A request that the receiving user agent issue a 645 message disposition notification is made by placing the following 646 header into the message to be sent: 648 MDN-request-header = "Disposition-notification-to" ":" 649 mail-address 651 The mail-address field is specified as an RFC 822 user@domain 652 address, and is the return address for the message disposition 653 notification. 655 In addition to requesting a message disposition notification, a 656 message disposition notification that is digitally signed, or 657 what has been referred to as a signed receipt, can be requested 658 by placing the following in the message header following the 659 "Disposition-Notification-To" line. 661 Disposition-notification-options = 662 "Disposition-Notification-Options" ":" 663 disposition-notification-parameters 665 where 667 disposition-notification-parameters = 668 parameter *(";" parameter) 670 where 672 parameter = attribute "=" importance ", " 1#value" 674 where 676 importance = "required" | "optional" 678 So the Disposition-notification-options string could be: 680 signed-receipt-protocol=optional, ; 681 signed-receipt-micalg=optional, , ,...; 683 The currently supported values for are 684 "pkcs7-signature", for the S/MIME detached signature format, or 685 "pgp-signature", for the pgp signature format. 687 The currently supported values for MIC algorithm values are: 689 Algorithm Value 690 used 692 MD5 md5 693 SHA-1 sha1 695 (Historical note: some early implementations of EDIINT emitted 696 and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) 697 Receiving agents SHOULD be able to recover gracefully from a 698 micalg parameter value that they do not recognize. 700 An example of a formatted options line would be as follows: 702 Disposition-notification-options: 703 signed-receipt-protocol=optional, pkcs7-signature; 704 signed-receipt-micalg=optional, sha1, md5 706 The semantics of the "signed-receipt-protocol" parameter is as 707 follows: 709 1). The "signed-receipt-protocol" parameter is used to request a 710 signed receipt from the recipient trading partner. The 711 "signed-receipt-protocol" parameter also specifies the format 712 in which the signed receipt should be returned to the 713 requester. 715 The "signed-receipt-micalg" parameter is a list of MIC 716 Algorithms preferred by the requester for use in signing the 717 returned receipt. The list of MIC algorithms should be 718 honored by the recipient from left to right. 720 Both the "signed-receipt-protocol" and the "signed-receipt- 721 micalg" option parameters are REQUIRED when requesting a 722 signed receipt. 724 2). The "importance" attribute of "Optional" is defined in the 725 MDN RFC 2298 and has the following meaning: 727 Parameters with an importance of "Optional" permit a UA that 728 does not understand the particular options parameter to still 729 generate a MDN in response to a request for a MDN. A UA that 730 does not understand the "signed-receipt-protocol" parameter, 731 or the "signed-receipt-micalg" will obviously not return a 732 signed receipt. 734 The importance of "Optional" is used for the signed receipt 735 parameters because it is RECOMMENDED that an MDN be returned 736 to the requesting trading partner even if the recipient could 737 not sign it. 738 The returned MDN will contain information on the disposition 739 of the message as well as why the MDN could not be signed. 740 See the Disposition field in section 5.3 for more 741 information. 743 Within an EDI trading relationship, if a signed receipt is 744 expected and is not returned, then the validity of the 745 transaction is up to the trading partners to resolve. In 746 general, if a signed receipt is required in the trading 747 relationship and is not received, the transaction will likely 748 not be considered valid. 750 5.2.1 Additional Signed Receipt Considerations 752 The "rules" stated in Section 2.2.3 for signed receipts are as 753 follows: 755 1). When a receipt is requested, explicitly specifying that the 756 receipt be signed, then the receipt MUST be returned with a 757 signature. 759 2). When a receipt is requested, explicitly specifying that the 760 receipt be signed, but the recipient cannot support either 761 the requested protocol format, or requested MIC algorithms, 762 then either a signed or unsigned receipt SHOULD be returned. 764 3). When a signature is not explicitly requested, or if the 765 signed receipt request parameter is not recognized by the UA, 766 then no receipt, an unsigned receipt, or a signed receipt MAY 767 be returned by the recipient. 769 NOTE: For Internet EDI, it is RECOMMENDED that when a signature 770 is not explicitly requested, or if parameters are not recognized, 771 that the UA send back at a minimum, an unsigned receipt. If a 772 signed receipt however was always returned as a policy, whether 773 requested or not, then any false unsigned receipts can be 774 repudiated. 776 When a request for a signed receipt is made, but there is an 777 error in processing the contents of the message, a signed receipt 778 MUST still be returned. The request for a signed receipt SHALL 779 still be honored, though the transaction itself may not be valid. 780 The reason for why the contents could not be processed MUST be 781 set in the "disposition-field". 783 When a request for a signed receipt is made, the "Received- 784 content-MIC" MUST always be returned to the requester. The 785 "Received-content-MIC" MUST be calculated as follows: 787 - For any signed messages, the MIC to be returned is calculated 788 on the RFC1767 MIME header and content. Canonicalization as 789 specified in RFC 1848 MUST be performed before the MIC is 790 calculated, since the sender requesting the signed receipt was 791 also REQUIRED to canonicalize. 793 - For encrypted, unsigned messages, the MIC to be returned is 794 calculated on the decrypted RFC 1767 MIME header and content. 795 The content after decryption MUST be canonicalized before the 796 MIC is calculated. 798 - For unsigned, unencrypted messages, the MIC MUST be calculated 799 over the message contents prior to Content-Transfer-Encoding or 800 Content-Encoding, and without the MIME or any other RFC 822 801 headers, since these are sometimes altered or reordered by MTAs. 803 5.3 Message Disposition Notification Format 805 The format of a message disposition notification is specified in 806 RFC 2298 For use in Internet EDI, the following format will be 807 used: 809 - content-type - per RFC 1892 and the RFC 2298 specification 811 - reporting-ua-field - per RFC 2298 specification 813 - MDN-gateway-field - per RFC 2298 specification 815 - original-recipient-field - per RFC 2298 specification 817 - final-recipient-field - per RFC 2298 specification 819 - original-message-id-field - per RFC 2298 specification 821 - disposition-field - the following "disposition-mode" 822 values SHOULD be used for 823 Internet EDI: 825 "automatic-action" - The disposition described by the 826 disposition type was a result of an 827 automatic action, rather than an explicit 828 instruction by the user for this message. 830 "manual-action" - The disposition described by the 831 disposition type was a result of an 832 explicit instruction by the user rather 833 than some sort of automatically performed 834 action. 836 "MDN-sent-automatically" - The MDN was sent because the UA had 837 previously been configured to do 838 so. 840 "MDN-sent-manually" - The user explicitly gave permission for 841 this particular MDN to be sent. "MDN- 842 sent-manually" is meaningful with 843 "manual-action", but not with 844 "automatic-action". 846 - disposition-field - the following "disposition-type" values 847 SHOULD be used for Internet EDI: 849 "processed" - The message has been processed in some manner 850 (e.g., printed, faxed, forwarded, gatewayed) 851 without being displayed to the user. The user 852 may or may not see the message later. 854 "failed" - A failure occurred that prevented the proper 855 generation of an MDN. More information about the 856 cause of the failure may be contained in a 857 Failure field. The "failed" disposition type is 858 not to be used for the situation in which there 859 is some problem in processing the message other 860 than interpreting the request for an MDN. The 861 "processed" or other disposition type with 862 appropriate disposition modifiers is to be used 863 in such situations. 865 - disposition-field - the following "disposition-modifier" 866 values SHOULD be used for Internet EDI: 868 "error" - An error of some sort occurred that prevented 869 successful processing of the message. Further 870 information is contained in an Error field. 872 "warning" - The message was successfully processed but some 873 sort of exceptional condition occurred. Further 874 information is contained in a Warning field. 876 5.3.1 Message Disposition Notification Extensions 878 The following "extension field" will be added in order to support 879 signed receipts for RFC 1767 MIME content type and multipart MIME 880 content types that include the RFC 1767 MIME content type. The 881 extension field" defined below follows the "disposition-field" in 882 the MDN. 884 The "Received-content-MIC" extension field is set when the 885 integrity of the received message is verified. The MIC is the 886 base64 encoded quantity computed over the received message with a 887 hash function. For details of "what" the "Received-content-MIC" 888 should be calculated over, see Section 5.2.1. The algorithm used 889 to calculate the "Received-content-MIC" value MUST be the same as 890 the "micalg" value used by the sender in the multipart/signed 891 message. When no signature is received, or the mic-alg parameter 892 is not supported then it is RECOMMENDED that the SHA1 algorithm 893 be used to calculate the MIC on the received message or message 894 contents. 896 This field is set only when the contents of the message are 897 processed successfully. This field is used in conjunction with 898 the recipient's signature on the MDN in order for the sender to 899 verify "non-repudiation of receipt". 901 - extension field = "Received-content-MIC" ":" MIC 903 where: 905 = "," 907 = the result of one way hash function, base64 908 encoded. 910 < micalg> = the micalg value defined in RFC1847, an IANA 911 registered MIC algorithm ID token. 913 5.3.2 Disposition Mode, Type, and Modifier Use 915 Guidelines for use of the "disposition-mode", "disposition- 916 type", and "disposition-modifier" fields within Internet EDI are 917 discussed in this section. The "disposition-mode", "disposition- 918 type', and "disposition-modifier' fields are described in detail 919 in RFC 2298. The "disposition-mode', "disposition-type" and 920 "disposition-modifier" values SHOULD be used as follows: 922 5.3.2.1 Successful Processing 924 When the request for a receipt or signed receipt, and the 925 received message contents are successfully processed by the 926 receiving EDI UA, a receipt or MDN SHOULD be returned with the 927 "disposition-type" set to 'processed'. When the MDN is sent 928 automatically by the EDI UA, and there is no explicit way for a 929 user to control the sending of the MDN, then the first part of 930 the "disposition-mode" should be set to "automatic-action". When 931 the MDN is being sent under user configurable control, then the 932 first part of the "disposition-mode" should be set to "manual- 933 action". Since a request for a signed receipt should always be 934 honored, the user MUST not be allowed to configure the UA to not 935 send a signed receipt when the sender requests one. 937 The second part of the "disposition-mode" is set to "MDN-sent- 938 manually" if the user gave explicit permission for the MDN to be 939 sent. Again, the user MUST not be allowed to explicitly refuse 940 to send a signed receipt when the sender requests one. The 941 second part of the "disposition-mode" is set to "MDN-sent- 942 automatically" whenever the EDI UA sends the MDN automatically, 943 regardless of whether the sending was under a user's, 944 administrator's, or under software control. 946 Since EDI content is generally handled automatically by the EDI 947 UA, a request for a receipt or signed receipt will generally 948 return the following in the "disposition-field": 950 Disposition: automatic-action/MDN-sent-automatically; processed 952 Note this specification does not restrict the use of the 953 "disposition-mode" to just automatic actions. Manual actions are 954 valid as long as it is kept in mind that a request for a signed 955 receipt MUST be honored. 957 5.3.2.2 Unprocessed Content 959 The request for a signed receipt requires the use of two 960 "disposition-notification-options", which specify the protocol 961 format of the returned signed receipt, and the MIC algorithm 962 used to calculate the mic over the message contents. The 963 "disposition-field" values that should be used in the case where 964 the message content is being rejected or ignored, for instance 965 if the EDI UA determines that a signed receipt cannot be 966 returned because it does not support the requested protocol 967 format, so the EDI UA chooses not to process the message 968 contents itself, should be specified in the MDN "disposition- 969 field" as follows: 971 Disposition: "disposition-mode"; 972 failed/Failure: unsupported format 974 The syntax of the "failed" "disposition-type" is general, 975 Allowing the sending of any textual information along with the 976 "failed" "disposition-type". For use in Internet EDI, the 977 following "failed" values are defined: 979 "Failure: unsupported format" 980 "Failure: unsupported MIC-algorithms" 982 5.3.2.3 Content Processing Errors 984 When errors occur processing the received message content, the 985 "disposition-field" should be set to the "processed" 986 "disposition-type" value and the "error" "disposition-modifier" 987 value. For use in Internet EDI, the following "error" 988 "disposition-modifier" values are defined: 990 "Error: decryption-failed" - the receiver could not decrypt the 991 message contents. 993 "Error: authentication-failed" - the receiver could not 994 authenticate the sender. 996 "Error: integrity-check-failed" - the receiver could not verify 997 content integrity. 999 "Error: unexpected-processing-error" - a catch-all for any 1000 additional processing 1001 errors. 1003 An example of how the "disposition-field" would look when 1004 content processing errors are detected is as follows: 1006 Disposition: "disposition-mode"; 1007 processed/Error: decryption-failed 1009 5.3.2.4 Content Processing Warnings 1011 Situations arise in EDI where even if a trading partner cannot 1012 be authenticated correctly, the trading partners still agree 1013 to continue processing the EDI transactions. Transaction 1014 reconciliation is done between the trading partners at a later 1015 time. In the content processing warning situations as described 1016 above, the "disposition-field' SHOULD be set to the "processed" 1017 "disposition-type" value, and the "warning" "disposition- 1018 modifier" value. For use in Internet EDI, the following 1019 "warning" "disposition-modifier" values are defined: 1021 "Warning: authentication-failed, processing continued" 1023 An example of how the "disposition-field" would look when 1024 content processing warnings are detected is as follows: 1026 Disposition: "disposition-mode"; processed/Warning: 1027 authentication-failed, processing continued 1029 5.4 Message Disposition Notification Processing 1031 5.4.1 Large File Processing 1033 Large EDI Interchanges sent via SMTP can be automatically 1034 fragmented by some message transfer agents. A subtype of 1035 message, "partial", is defined in RFC 2045 [1] to allow large 1036 objects to be delivered as separate pieces of mail and to be 1037 automatically reassembled by the receiving user agent. Using 1038 message, "partial", can help alleviate fragmentation of large 1039 messages by different message transfer agents, but does not 1040 completely eliminate the problem. It is still possible that a 1041 piece of a partial message, upon re-assembly, may prove to 1042 contain a partial message as well. This is allowed by the 1043 Internet standards, and it is the responsibility of the user 1044 agent to re-assemble the fragmented pieces. 1046 It is RECOMMENDED that the size of the EDI Interchange sent via 1047 SMTP be configurable so that if fragmentation does occur, then 1048 message, "partial" can be used to send the large EDI 1049 Interchange in smaller pieces. RFC 2045 [1] defines the use of 1050 Content-Type: message/partial. Support of the message/partial 1051 content type for use in Internet EDI is OPTIONAL. 1053 The receiving UA is required to re-assemble the original 1054 message before sending the message disposition notification to 1055 the original sender of the message. A message disposition 1056 notification is used to specify the disposition of the entire 1057 message that was sent, and should not be returned by a 1058 processing UA until the entire message is received, even if the 1059 received message requires re-assembling. 1061 In general, EDI content compresses well, since there is 1062 Repetitive data in most EDI Interchanges. Instead of 1063 implementing the message/partial, compression of the EDI 1064 Interchange can be done after the signature is applied to the 1065 EDI Interchange, and before encryption. When no signature is 1066 applied, then compression is applied before the encryption. 1067 Compression is an alternative solution to implementing Content- 1068 Type: message/partial when sending large EDI Interchanges on 1069 the Internet. 1071 Applying compression before encryption strengthens 1072 cryptographic security since repetitious strings are reduced. 1073 This sequence of signature, compression, then encryption, or 1074 compression then encryption, is consistent with the order in 1075 which PGP implementations handle compression. 1077 Note: Compression is done automatically when using PGP 1078 encryption. 1080 The MIME standards [1], do not define a way in which to convey 1081 that a message has been compressed. However, RFC 2045 [1] does 1082 allow the definition of additional MIME header fields to 1083 further describe the content of a message. 1085 RFC 2068 [11], the HTTP/1.1 specification does define a 1086 Content-Encoding field that is primarily used to convey 1087 compression information: 1089 Content-Encoding = "Content-Encoding" ":" content-coding 1091 where content-coding can take on the values of "gzip" or 1092 "compress". The gzip compression standard is further described 1093 in RFC 1952 [12], and compress is the standard UNIX file 1094 compression program. Both gzip and compress are registered with 1095 IANA. 1097 Trading partners can adopt the use of the Content-Encoding 1098 header if they need to compress their EDI data and convey the 1099 compression type to their trading partners. 1101 5.4.2 Example 1103 The following is an example of a signed receipt returned by a 1104 UA after successfully processing a MIME EDI content type. The 1105 Sending trading partner has requested a return signed receipt. 1107 This example follows the S/MIME application/pkcs-7-signature 1108 format. 1110 NOTE: This example is provided as an illustration only, and is 1111 not considered part of the protocol specification. If an 1112 example conflicts with the protocol definitions specified above 1113 or in the other referenced RFCs, the example is wrong. 1115 To: 1116 Subject: 1117 From: 1118 Date: 1119 Mime-Version: 1.0 1120 Content-Type: multipart/signed; boundary="separator"; 1121 micalg=sha1; protocol="application/pkcs7-signature" 1123 --separator 1124 & Content-Type: multipart/report; report-type=disposition 1125 & notification; boundary="xxxxx" 1126 & 1127 & --xxxxx 1128 & Content-Type: text/plain 1129 & 1130 & The message sent to Recipient 1131 & has been received, the EDI Interchange was successfully 1132 & decrypted and its integrity was verified. In addition, the 1133 & sender of the message, Sender 1134 & was authenticated as the originator of the message. There is 1135 & no guarantee however that the EDI Interchange was 1136 & syntactically correct, or was received by the EDI 1137 & application. 1138 & 1139 & --xxxxx 1140 & Content-Type: message/disposition-notification 1141 & 1142 & Reporting-UA: Interchange.cyclonesoftware.com (CI 2.2) 1143 & Original-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1144 & Final-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1145 & Original-Message-ID: <17759920005.12345@cyclonesoftware.com > 1146 & Disposition: automatic-action/MDN-sent-automatically; processed 1147 & Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1 1148 & 1149 & --xxxxx 1150 & Content-Type: message/rfc822 1151 & 1152 & To: 1153 & Subject: 1154 & 1155 & [additional header fields go here] 1156 & 1157 & --xxxxx- 1159 --separator 1160 Content-Type: application/pkcs7-signature; name=smime.p7s; 1161 Content-Transfer-Encoding: base64 1162 Content-Disposition: attachment; filename=smime.p7s 1164 MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg 1165 ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA 1166 oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU= 1168 --separator-- 1170 Notes: 1172 -The lines preceded with "&" is what the signature is calculated 1173 over. 1175 (For details on how to prepare the multipart/signed with 1176 protocol = "application/pkcs7-signature" see the "S/MIME 1177 Message Specification, PKCS Security Services for MIME".) 1179 Note: As specified by RFC 1892 [10], returning the original or 1180 portions of the original message in the third body part of the 1181 multipart/report is not required. This is an optional body part. 1182 It is RECOMMENDED that the received headers from the original 1183 message be placed in the third body part, as they can be helpful 1184 in tracking problems. 1186 Also note that the textual first body part of the 1187 multipart/report can be used to include a more detailed 1188 explanation of the error conditions reported by the disposition 1189 headers. The first body part of the multipart/report when used in 1190 this way, allows a person to better diagnose a problem in detail. 1192 6.0 Public key certificate handling 1194 6.1 Near term approach 1196 In the near term, the exchange of public keys and certification 1197 of these keys must be handled as part of the process of 1198 establishing a trading partnership. The UA and/or EDI application 1199 interface must maintain a database of public keys used for 1200 encryption or signatures, in addition to the mapping between EDI 1201 trading partner ID and RFC 822 [3] email address. The procedures 1202 for establishing a trading partnership and configuring the secure 1203 EDI messaging system might vary among trading partners and 1204 Software packages. 1206 For systems which make use of X.509 certificates, it is 1207 RECOMMENDED that trading partners self-certify each other if an 1208 agreed upon certification authority is not used. It is highly 1209 RECOMMENDED that when trading partners are using S/MIME, that 1210 they also exchange public key certificates using the 1211 recommendations specified in the S/MIME Version 3 Message 1212 Specification. The message formats and S/MIME conformance 1213 requirements for certificate exchange are specified in this 1214 document. 1216 This applicability statement does NOT require the use of a 1217 certification authority. The use of a certification authority 1218 is therefore OPTIONAL. 1220 6.2 Long term approach 1222 In the long term, additional Internet-EDI standards may be 1223 developed to simplify the process of establishing a trading 1224 partnership, including the third party authentication of trading 1225 partners, as well as attributes of the trading relationship. 1227 7.0 Acknowledgments 1229 Many thanks go out to the previous authors of the MIME-based 1230 Secure EDI IETF Draft: Chuck Shih, Mats Jansson. 1232 The authors would like to extend special thanks to Carl Hage, Jun 1233 Ding, Dale Moberg, and Karen Rosenthal for providing the team 1234 with valuable, and very thorough feedback. Without participants 1235 like those cited above, these efforts become hard to complete in 1236 a way useful to the users and implementers of the technology. 1238 In addition, the authors would like to thank Harald Alvestrand, 1239 Jim Galvin, and Roger Fajman for their guidance and input. 1241 8.0 References 1243 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail 1244 Extensions (MIME) 1245 Part One: Format of Internet Message Bodies", RFC 2045, 1246 December 02, 1996. 1248 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1249 Extensions (MIME) 1250 Part Two: Media Types", RFC 2046, December 02, 1996. 1252 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1253 Extensions (MIME) 1254 Part Five: Conformance Criteria and Examples", RFC 2049 , 1255 December 02, 1996. 1257 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 1258 March 2, 1995. 1260 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 1261 Messages", STD 11, RFC 822, August 13, 1982. 1263 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", 1264 RFC 2015, Sept. 1996. 1266 [5] R. Fajman, "An Extensible Message Format for Message 1267 Disposition Notifications", RFC 2298, March 1998. 1269 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 1270 Multiparts for MIME: Multipart/Signed and 1271 Multipart/Encrypted", RFC 1847, Oct. 3, 1995 1273 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 1274 821, August 1, 1982. 1276 [8] B. Ramsdell, "S/MIME Version 3 Message Specification; 1277 Cryptographic Message Syntax", RFC 2633 RFC 2630, June 1999. 1279 [9] T. Harding, R. Drummond, "Requirements for Inter-operable 1280 Internet EDI", Internet draft: draft-ietf-ediint-req07.txt 1281 September 1999. 1283 [10] G. Vaudreuil, "The Multipart/Report Content Type for the 1284 Reporting of Mail System Administrative Messages", RFC 1285 1892, January 15, 1996. 1287 [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 1288 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1289 1997. 1291 [12] L. Deutsch, "GZIP File Format Specification Version 4.3", 1292 RFC 1952, May 23, 1996. 1294 9.0 Authors' Addresses 1296 Terry Harding 1297 tharding@cyclonesoftware.com 1298 Cyclone Software 1299 14505 N. Hayden Road. Suite 300 1300 Scottsdale, AZ, 85260 1302 Rik Drummond 1303 drummond@onramp.com 1304 The Drummond Group 1305 5008 Bentwood Ct. 1306 Ft. Worth, TX 76132 USA