idnits 2.17.1 draft-ietf-ediint-as1-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 45 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 238: '...then the receipt MUST be returned with...' RFC 2119 keyword, line 242: '... or unsigned SHOULD be returned. I...' RFC 2119 keyword, line 305: '...ed however, a signature is REQUIRED as...' RFC 2119 keyword, line 308: '...d receipt or MDN SHOULD be returned wi...' RFC 2119 keyword, line 329: '...e is used, it is RECOMMENDED that the ...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 146 has weird spacing: '... as descr...' == Line 781 has weird spacing: '...here is some ...' == Line 889 has weird spacing: '...quested proto...' == Line 1099 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.) -- The document date (8 July 1997) is 9782 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) ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) == Outdated reference: A later version (-07) exists of draft-ietf-receipt-mdn-04 ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) -- Possible downref: Normative reference to a draft: ref. '8' -- No information found for draft-ietf-ediint-req03 - 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: 18 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EDIINT Working Group Chuck Shih 2 draft-ietf-ediint-as1-04.txt Mats Jansson 3 Expires: 10 December 1997 Rik Drummond 4 8 July 1997 6 MIME-based Secure EDI 8 draft-ietf-ediint-as1-04.txt 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This document describes how to securely exchange EDI documents 32 using MIME and public key cryptography. 34 Feedback Instructions: 36 If you want to provide feedback on this draft, follow these guidelines: 38 -Send feedback via e-mail to the ietf-ediint list for discussion, with 39 "AS#1"� in the Subject field. To enter/follow the discussion, you 40 need to subscribe at ietf-ediint@imc.org. 42 -Be specific as to what section you are referring to, preferably 43 quoting the portion that needs modification, after which you state 44 your comments. 46 -If you are recommending some text to be replaced with your suggested 47 text, again, quote the section to be replaced, and be clear on the 48 section in question. 50 Table of Contents 52 1. Introduction 3 54 2. Overview 4 55 2.1 Purpose of a security guideline for MIME EDI 4 56 2.2 Definitions 57 2.2.1 Terms 4 58 2.2.2 The secure transmission loop 5 59 2.2.3 Definition of receipts 5 60 2.3 Assumptions 61 2.3.1 EDI process assumptions 6 62 2.3.2 Flexibility assumptions 7 64 3. Referenced RFCs and their contribution 8 65 3.1 RFC 821 SMTP [7] 8 66 3.2 RFC 822 Text Message Format [3] 9 67 3.3 RFC 1847 MIME Security Multiparts [6] 9 68 3.4 RFC 1892 Multipart/report [9] 9 69 3.5 RFC 1767 EDI Content [2] 9 70 3.6 RFC 2015 PGP/MIME [4] 9 71 3.7 RFC 2045,2046, and 2049 MIME [1] 9 72 3.8 Internet draft (fajman): Message Disposition 9 73 Notification [5] 74 3.9 Internet draft (dusse): - S/MIME Specification [8] 9 76 4. Structure of an EDI MIME message - Applicability 10 77 4.1 Introduction 10 78 4.2 Structure of an EDI MIME message - PGP/MIME 10 79 4.2.1 No encryption, no signature 10 80 4.2.2 No encryption, signature 10 81 4.2.3 Encryption, no signature 10 82 4.2.4 Encryption, signature 10 83 4.3 Structure of an EDI MIME message - S/MIME 11 84 4.3.1 No encryption, no signature 11 85 4.3.2 No encryption, signature 11 86 4.3.3 Encryption, no signature 11 87 4.3.4 Encryption, signature 11 89 5. Receipts 11 90 5.1 Introduction 11 91 5.2 Requesting a signed receipt 14 92 5.2.1 Additional signed receipt considerations 15 93 5.3 Message Disposition Notification Format 16 94 5.3.1 Message Disposition Notification Extensions 18 95 5.3.2 Disposition Mode, Type and Modifier Use 19 96 5.3.2.1 Successful Processing 19 97 5.3.2.2 Unprocessed Content 19 98 5.3.2.3 Content Processing Errors 20 99 5.3.2.4 Content Processing Warnings 21 100 5.4 Message Disposition Notification Processing 21 101 5.4.1 Large File Processing 21 102 5.4.2 Example 22 104 6. Public key certificate handling 24 105 6.1 Near term approach 24 106 6.2 Long term approach 24 108 7. Acknowledgments 25 110 8. References 26 112 9. Authors' Addresses 27 114 1. Introduction 116 Previous work on Internet EDI focused on specifying MIME content 117 types for EDI data ([2] RFC 1767). This Applicability Statement 118 expands on RFC 1767 to specify use of a comprehensive set of data 119 security features, specifically data privacy, data 120 integrity/authenticity, non-repudiation of origin and non- 121 repudiation of receipt. This draft recognizes contemporary RFCs 122 and Internet drafts and is attempting to "re-invent" as little as 123 possible. 125 With an enhancement in the area of "receipts", as described below 126 (3.1.8), secure Internet MIME based EDI can be accomplished by 127 using and complying with the following RFCs and drafts: 129 -RFC 821 SMTP 130 -RFC 822 Text Message Formats 131 -RFC 1767 EDI Content Type 132 -RFC 1847 Security Multiparts for MIME 133 -RFC 1892 Multipart/Report 134 -RFC 2015 MIME/PGP (elkins) 135 -RFC 2045 to 2049 MIME RFCs 136 -Internet draft: Message Disposition Notification (fajman) 137 -Internet draft: S/MIME Specification (dusse) 139 Our intent here is to define clearly and precisely how these 140 are used together, and what is required by user agents to be 141 compliant with this Applicability Statement. 143 Note that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 144 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 145 "MAY", and "OPTIONAL" in this document are to be interpreted 146 as described in RFC 2119. 148 2. Overview 150 2.1 Purpose of a security guideline for MIME EDI 152 The purpose of these specifications is to ensure interoperability 153 between EDI user agents, invoking some or all of the commonly 154 expected security features. This standard is also NOT limited to 155 strict EDI use, but applies to any electronic commerce application 156 where business data needs to be exchanged over the Internet in a 157 secure manner. 159 2.2 Definitions 161 2.2.1. Terms 163 EDI Electronic Data Interchange 165 EC Electronic Commerce 167 Receipt The functional message that is sent from a 168 receiver to a sender to acknowledge receipt 169 of an EDI/EC interchange. 171 Signed Receipt Same as above, but with a digital signature. 173 Message Disposition The Internet messaging format used to 174 Notification convey a receipt. This term is used 175 interchangeably with receipt. A signed 176 MDN is a signed receipt. 178 Non-repudiation of NRR is a "legal event" that occurs when the 179 Receipt (NRR) original sender of an EDI/EC interchange has 180 verified the signed receipt coming back from 181 the receiver. NRR IS NOT a functional or a 182 technical message. 184 PGP/MIME Digital envelope security based on the Pretty 185 Good Privacy (PGP) standard (Zimmerman), 186 integrated with MIME Security Multiparts [6]. 188 S/MIME A format and protocol for adding cryptographic 189 signature and/or encryption services to 190 Internet MIME messages. 192 2.2.2 The secure transmission loop 194 The functional requirements document, [9] "Requirements for Inter- 195 operable Internet EDI" (can be found at www.ietf.org), provides 196 extensive information on EDI security and the user/business related 197 processes surrounding the need for and use of EDI security. In 198 this document, it is assumed that the reader is familiar with the 199 requirements document. 201 This document's focus is on the formats and protocols for 202 exchanging EDI content that has had security applied to it using 203 the Internet's messaging transport. 205 The "secure transmission loop" for EDI involves one organization 206 sending a signed and encrypted EDI interchange to another 207 organization, requesting a signed receipt, followed later by the 208 receiving organization sending this signed receipt back to the 209 sending organization. In other words, the following transpires: 211 -The organization sending EDI/EC data encrypts the data and 212 provides a digital signature, using either PGP/MIME or S/MIME. 213 In addition, they request a signed receipt. 215 -The receiving organization decrypts the message and verifies 216 the signature, resulting in verified integrity of the data and 217 authenticity of the sender. 219 -The receiving organization then sends a signed receipt in the 220 form of a signature over the hash of a message disposition 221 notification, which contains a hash of the received message. 223 The above describes functionality which if implemented, would 224 satisfy all security requirements. This specification, however, 225 leaves full flexibility for users to decide the degree to which 226 they want to deploy those security features with their EDI 227 trading partners. 229 2.2.3 Definition of receipts 231 The term used for both the functional activity and message for 232 acknowledging receipt of an EDI/EC interchange is receipt, or 233 signed receipt. The first term is used if the acknowledgment is 234 for an interchange resulting in a receipt which is NOT signed. 235 The second term is used if the acknowledgment is for an interchange 236 resulting in a receipt which IS signed. The "rule" is: If a 237 receipt is requested, explicitly specifying that the receipt be 238 signed, then the receipt MUST be returned with a signature. 239 If a receipt is requested, explicitly specifying that the receipt 240 be signed, but the recipient cannot support the requested protocol 241 format or requested MIC algorithms, then a receipt, either signed 242 or unsigned SHOULD be returned. If a signature is not explicitly 243 requested, or if the signed receipt request parameter is not 244 recognized by the UA, all bets are off -- a receipt may or may not 245 be returned. This behavior is consistent with the MDN Internet 246 draft. 248 A term often used in combination with receipts is "Non-repudiation 249 of Receipt (NRR). NRR refers to a legal event which occurs only 250 when the original sender of an interchange has verified the sender 251 and content of a signed receipt. Note that NRR is not possible 252 without signatures. 254 2.3 Assumptions 256 2.3.1 EDI process assumptions 258 -Encrypted object is an EDI Interchange 260 This specification assumes that a typical EDI interchange is 261 the lowest level object that will be subject to security 262 services. 264 In ANSI X12, this means anything between, and including 265 segments ISA and IEA. In EDIFACT, this means anything between, 266 and including, segments UNA/UNB and UNZ. In other words, the 267 EDI interchanges including envelope segments remain intact and 268 unreadable during secure transport. 270 -EDI envelope headers are encrypted 272 Congruent with the above statement, EDI envelope headers are NOT 273 visible in the MIME package. In order to optimize VAN-to- 274 Internet routing, work may need to be done in the future to 275 define ways to pull out some of the envelope information to make 276 them visible, however, this specification does not go into any 277 detail on that. 279 -X12.58 and UN/EDIFACT security considerations 281 The most common EDI standards bodies, ANSI X12 and EDIFACT, 282 have defined internal provisions for security. X12.58 is the 283 security mechanism for ANSI X12 and AUTACK provides security for 284 EDIFACT. This specification DOES NOT dictate use or non-use 285 of these security standards. They are both fully compatible, 286 though possibly redundant, with this specification. 288 2.3.2 Flexibility assumptions 290 -Encrypted or un-encrypted data 292 This specification allows for EDI message exchange where the 293 EDI data can either be un-protected or protected by means of 294 encryption. 296 -Signed or un-signed data 298 This specification allows for EDI message exchange with or 299 without digital signature of the original EDI transmission. 301 -Use of receipt or not 303 This specification allows for EDI message transmission with or 304 without a request for receipt notification. If a signed receipt 305 notification is requested however, a signature is REQUIRED as 306 part of the returned receipt, unless an error condition occurs 307 in which a signed-receipt cannot be returned. In error cases,an 308 un-signed receipt or MDN SHOULD be returned with the correct 309 "disposition modifier" error value. 311 -Formatting choices 313 This specification defines the use of two methods for formatting 314 EDI contents that have security applied to it: 316 -PGP/MIME 317 -S/MIME 319 This specification relies on the guidelines set forth in 320 RFC 2015, as reflected in [4] "MIME Security with Pretty Good 321 Privacy" (PGP), and Internet draft [8] "S/MIME Message 322 Specification; PKCS Security Services for MIME". Compliance with 323 this specification REQUIRES the use of PGP/MIME or S/MIME 324 as defined in this Applicability statement, and the [9] 325 "Requirements for Inter-operable Internet EDI" draft. 327 -Hash function, message digest choices 329 When signature is used, it is RECOMMENDED that the SHA1 hash 330 algorithm be used for all outgoing messages, and that both 331 MD5 and SHA1 be supported for incoming messages. 333 In summary, the following eight permutations are possible in 334 any given trading relationship: 336 (1) Sender sends un-encrypted data, does NOT request a receipt. 338 (2) Sender sends un-encrypted data, requests a signed or 339 unsigned receipt. The receiver sends back the signed or 340 unsigned receipt. 342 (3) Sender sends encrypted data, does NOT request a receipt. 344 (4) Sender sends encrypted data, requests a signed or 345 unsigned receipt. The receiver sends back the signed 346 or un-signed receipt. 348 (5) Sender sends signed data, does NOT request a signed or 349 un-signed receipt. 351 (6) Sender sends signed data, requests a signed or un-signed 352 receipt. Receiver sends back the signed or un-signed receipt. 354 (7) Sender sends encrypted and signed data, does NOT request a 355 signed or un-signed receipt. 357 (8) Sender sends encrypted and signed data, requests a signed or 358 un-signed receipt. Receiver sends back the signed or un- 359 signed receipt. 361 NOTE: Users can choose any of the eight possibilities, but only 362 example (8), when a signed receipt is requested, offers the 363 whole suite of security features described in the "Secure 364 transmission loop" above. 366 3. Referenced RFCs and their contribution 368 3.1 RFC 821 SMTP [7] 370 This is the core mail transfer standard that all MTAs need to 371 adhere to. 373 3.2 RFC 822 Text Message Format [3] 375 Defines message header fields and the parts making up a message. 377 3.3 RFC 1847 MIME Security Multiparts [6] 379 This document defines security multiparts for MIME: 380 multipart/encrypted and multipart/signed. 382 3.4 RFC 1892 Multipart/report [10] 384 This RFC defines the use of the multipart/report content type, 385 something that the MDN draft (fajman) builds upon. 387 3.5 RFC 1767 EDI Content [2] 389 This RFC defines the use of content type "application" for ANSI 390 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 391 mutually defined EDI (application/EDI-Consent). 393 3.6 RFC 2015 PGP/MIME [4] 395 This RFC defines the use of content types 396 "multipart/encrypted", "multipart/signed", "application/pgp 397 encrypted" and "application/pgp-signature" for defining MIME PGP 398 content. 400 3.7 RFC 2045, 2046, and 2049 MIME [1] 402 These are the basic MIME standards, upon which all MIME related RFCs 403 build, including this one. Key contributions include definition of 404 "content type", "sub-type" and "multipart", as well as encoding 405 guidelines, which establishes 7-bit US-ASCII as the canonical 406 character set to be used in Internet messaging. 408 3.8 Internet draft (fajman): Message Disposition Notification [5] 410 This Internet draft defines how a message disposition notification 411 (MDN) is requested, and the format and syntax of the MDN. The MDN 412 is the basis upon which receipts and signed receipts are defined 413 in this and the "Requirements" specification. 415 3.9 Internet draft (dusse): S/MIME Message Specification [8] 417 This specification describes how MIME shall carry PKCS7 418 envelopes. 420 4. Structure of an EDI MIME message - Applicability 422 4.1 Introduction 424 The structures below are described hierarchically in terms of which 425 RFC's are applied to form the specific structure. For details of 426 how to code in compliance with all RFC's involved, turn directly to 427 the RFC's referenced. The "requirements document" has several 428 examples described in an Appendix for those interested. 430 Also, these structures describe the initial transmission only. 431 Receipts, and requests for receipts are handled in section 5. 433 4.2 Structure of an EDI MIME message - PGP/MIME 435 4.2.1 No encryption, no signature 437 -RFC822/2045 438 -RFC1767 (application/EDIxxxx) 440 4.2.2 No encryption, signature 442 -RFC822/2045 443 -RFC1847 (multipart/signed) 444 -RFC1767 (application/EDIxxxx) 445 -RFC2015 (application/pgp-signature) 447 4.2.3 Encryption, no signature 449 -RFC822/2045 450 -RFC1847 (multipart/encrypted) 451 -RFC2015 (application/pgp-encrypted) 452 -"Version 1" 453 -RFC1767 (application/EDIxxxx) (encrypted) 455 4.2.4 Encryption, signature 457 -RFC822/2045 458 -RFC1847 (multipart/encrypted) 459 -RFC2015 (application/pgp-encrypted) 460 -"Version 1" 461 -RFC1767 (application/EDIxxxx) (encrypted) 462 -RFC2015 (application/pgp-signature) (encrypted) 464 4.3 Structure of an EDI MIME message - S/MIME 466 4.3.1 No encryption, no signature 468 -RFC822/2045 469 -RFC1767 (application/EDIxxxx) 471 4.3.2 No encryption, signature 473 -RFC822/2045 474 -RFC1847 (multipart/signed) 475 -RFC1767 (application/EDIxxxx) 476 -Draft (dusse) (application/x-pkcs7-signature) 478 4.3.3 Encryption, no signature 480 -RFC822/2045 481 -Draft (dusse) (application/x-pkcs7-mime) 482 -RFC1767 (application/EDIxxxx) (encrypted) 484 4.3.4 Encryption, signature 486 -RFC822/2045 487 -Draft (dusse) (application/x-pkcs7-mime) 488 -RFC1847 (multipart/signed) (encrypted) 489 -RFC1767 (application/EDIxxxx) (encrypted) 490 -Draft (dusse) (application/x-pkcs7-signature) (encrypted) 492 5. Receipts 494 5.1 Introduction 496 In order to support non-repudiation of receipt (NRR), a signed 497 receipt, based on digitally signing a message disposition notification, 498 is to be implemented by a receiving trading partner's UA (User Agent). 499 The message disposition notification, specified by 500 draft-ietf-receipt-mdn-04.txt is digitally signed by a receiving 501 trading partner as part of a multipart/signed MIME message. 503 The following support for signed receipts is REQUIRED: 505 1). The ability to create a multipart/report; where the report-type 506 = disposition-notification. 507 2). The ability to calculate a message integrity check (MIC) on the 508 message disposition notification. 509 3). The ability to digitally sign the MIC. 510 4). The ability to create a multipart/signed content with the message 511 disposition notification as the first body part, and the signed 512 MIC calculated on the message disposition notification as the 513 second body part. 514 5). The ability to return the signed receipt to the sending trading partner. 516 The signed receipt is used to notify a sending trading partner that requested 517 the signed receipt that: 519 1). The receiving trading partner acknowledges receipt of 520 the sent EDI Interchange. 522 2). If the sent message was signed, then the receiving trading 523 partner has authenticated the sender of the EDI Interchange. 525 3). If the sent message was signed, then the receiving trading 526 partner has verified the integrity of the sent EDI Interchange. 528 Regardless of whether the EDI Interchange was sent in S/MIME or 529 PGP/MIME format, the receiving trading partner's UA MUST provide 530 the following basic processing: 532 1). If the sent EDI Interchange is encrypted, then the encrypted 533 symmetric key and initialization vector (if applicable) is 534 decrypted using the receiver's private key. 536 2). The decrypted symmetric encryption key is then used to decrypt 537 the EDI Interchange. 539 3). The receiving trading partner authenticates signatures in a 540 message using the sender's public key. The authentication 541 algorithm performs the following: 543 a). The message integrity check (MIC or Message Digest), 544 is decrypted using the sender's public key. 546 b). A MIC on the signed contents (the MIME header and encoded 547 EDI object, as per RFC 1767) in the message received is 548 calculated using the same one-way hash function that the 549 sending trading partner used. 551 c). The MIC extracted from the message that was sent, and the 552 MIC calculated using the same one-way hash function that 553 the sending trading partner used is compared for equality. 555 4). The receiving trading partner formats the MDN and sets the 556 calculated MIC into the "Received-content-MIC" extension field. 558 5). The receiving trading partner creates a multipart/signed MIME 559 message according to RFC 1847. 561 6). The MDN is the first part of the multipart/signed message, and 562 the digital signature is created over this MDN, including its 563 MIME headers. 565 7). The second part of the multipart/signed message contains the 566 digital signature. The "protocol" option specified in the 567 second part of the multipart/signed is as follows: 569 S/MIME: protocol = "application/pkcs-7-signature" 571 PGP/MIME: protocol = "application/pgp-signature" 573 8). The signature information is formatted according to S/MIME 574 or PGP/MIME specifications. 576 The EDI Interchange and the RFC 1767 MIME EDI content header, can 577 actually be part of a multi-part MIME content-type. When the EDI 578 Interchange is part of a multi-part MIME content-type, the MIC MUST be 579 calculated across the entire multi-part content, including the MIME 580 headers. The multi-part MIME content that contains the EDI Interchange 581 is then enveloped in either S/MIME or PGP/MIME format. 583 The signed MDN, when received by the sender of the EDI Interchange 584 can be used by the sender: 586 1). As an acknowledgment that the EDI Interchange sent, was 587 delivered and acknowledged by the receiving trading partner. 588 The receiver does this by returning the original message 589 id of the sent message in the MDN portion of the signed receipt. 591 2). As an acknowledgment that the integrity of the EDI Interchange 592 was verified by the receiving trading partner. The receiver 593 does this by returning the calculated MIC of the received EDI 594 Interchange (and 1767 MIME headers) in the "Received-content-MIC" 595 field of the signed MDN. 597 3). As an acknowledgment that the receiving trading partner has 598 authenticated the sender of the EDI Interchange. 600 4). As a non-repudiation of receipt when the signed MIC calculated 601 over the MDN, is successfully decrypted by the sender with the 602 receiving trading partner's public key. 604 5.2 Requesting a signed receipt 606 Message Disposition Notifications are requested as per draft-ietf- 607 receipt-MDN-04.txt, "An Extensible Message Format for Message Disposition 608 Notification". A request that the receiving user agent issue a 609 message disposition notification is made by placing the following header 610 into the message to be sent: 612 MDN-request-header = "Disposition-notification-to" ":" mail-address 614 The mail-address field is specified as an RFC 822 user@domain address, 615 and is the return address for the message disposition notification. 617 In addition to requesting a message disposition notification, a message 618 disposition notification that is digitally signed, or what has been 619 referred to as a signed receipt, can be requested by placing the 620 following in the message header following the "Disposition- 621 notification-to" line. 623 Disposition-notification-options = "Disposition-notification-options" ":" 624 disposition-notification-parameters 626 Where disposition-notification-parameters = signed-receipt-protocol=O, 627 ; signed-receipt-micalg=O, , ,...; 629 The currently supported values for are "x-pkcs7- 630 signature", for the S/MIME detached signature format, or "pgp-signature", 631 for the pgp signature format. 633 The signed-receipt-micalg is a list of MIC algorithm values defined in 634 RFC1847, an IANA registered MIC algorithm ID token. 636 An example of a formatted options line would be as follows: 638 Disposition-notification-options: signed-receipt-protocol=O, 639 x-pkcs7-signature; signed-receipt-micalg=O, rsa-md5; 641 The semantics of the "signed-receipt-protocol" parameter is as follows: 643 1). The "signed-receipt-protocol" parameter is used to request a signed 644 receipt from the recipient trading partner. The "signed-receipt- 646 protocol" parameter also specifies the format in which the signed 647 receipt should be returned to the requester. 649 The "signed-receipt-micalg" parameter is a list of MIC algorithms 650 preferred by the requester for use in signing the returned receipt. 651 The list of MIC algorithms should be honored by the recipient from 652 left to right. 654 Both the "signed-receipt-protocol" and the "signed-receipt-micalg" 655 option parameters are REQUIRED when requesting a signed receipt. 657 2). The "importance" attribute of "O" is defined in the MDN draft and 658 has the following meaning: 660 Parameters with an importance of "O" permit a UA that does not 661 understand the particular options parameter to still generate a MDN 662 in response to a request for a MDN. A UA that does not understand the 663 "signed-receipt-protocol" parameter, will obviously not return a 664 signed receipt. 666 The importance of "O" is used for the signed receipt parameters 667 because it is RECOMMENDED that an MDN be returned to the requesting 668 trading partner even if the recipient could not sign it. The returned 669 MDN will contain information on the disposition of the message 670 as well as why the MDN could not be signed. See the disposition 671 field in section 5.3 for more information. 673 Within an EDI trading relationship, if a signed receipt is expected 674 and is not returned, then the validity of the transaction is up to the 675 trading partners to resolve. In general, if a signed receipt is 676 required in the trading relationship and is not received, the 677 transaction will likely not be considered valid. 679 5.2.1 Additional Signed Receipt Considerations 681 The "rules" stated in Section 2.2.3 for signed receipts are as 682 follows: 684 1). When a receipt is requested, explicitly specifying that the 685 receipt be signed, then the receipt MUST be returned with a 686 signature. 688 2). When a receipt is requested, explicitly specifying that the 689 receipt be signed, but the recipient cannot support either 690 the requested protocol format, or requested MIC algorithms, 691 then either a signed or unsigned receipt SHOULD be returned. 693 3). When a signature is not explicitly requested, or if the 694 signed receipt request parameter is not recognized by the UA, 695 then all bets are off. In this situation, no receipt, an unsigned 696 receipt, or a signed receipt MAY be returned by the recipient. 698 NOTE: For Internet EDI, it is RECOMMENDED that when a signature is not 699 explicitly requested, or if parameters are not recognized, that the UA 700 send back at a minimum, an unsigned receipt. If a signed receipt however 701 was always returned as a policy, whether requested or not, then any false 702 unsigned receipts can be repudiated. 704 When a request for a signed receipt is made, but there is an error in 705 processing the contents of the message, a signed receipt MUST still 706 be returned. The request for a signed receipt SHALL still be honored, 707 though the transaction itself may not be valid. The reason for why the 708 contents could not be processed MUST be set in the "disposition-field". 710 When a request for a signed receipt is made, the "Received-content-MIC" 711 MUST always be returned to the requester. The "Received-content-MIC" 712 MUST be calculated as follows: 714 - For any signed messages, the MIC to be returned is calculated 715 on the RFC1767 MIME header and content, or the multipart MIME 716 header and content. Canonicalization as specified in RFC 1848 MUST 717 be performed before the MIC is calculated, since the sender 718 requesting the signed receipt was also REQUIRED to canonicalize. 720 - For encrypted, unsigned messages, the MIC to be returned is 721 calculated on the decrypted RFC 1767 MIME header and content, 722 or the multipart MIME header and content. The content after 723 decryption MUST be canonicalized before the MIC is calculated. 725 - For unsigned, unencrypted messages, the MIC MUST be calculated 726 over the message contents prior to Content-Transfer-Encoding or 727 Content-Encoding, and without the MIME or any other RFC 822 728 headers, since these are sometimes altered or reordered by MTAs. 730 5.3 Message Disposition Notification Format 732 The format of a message disposition notification is specified in 733 draft-ietf-receipt-mdn-04.txt. For use in Internet EDI, the 734 following format will be used: 736 - content-type - per RFC 1892 and the ietf-receipt-MDN specification 738 - reporting-ua-field - per ietf-receipt-MDN specification 739 - MDN-gateway-field - per ietf-receipt-MDN specification 741 - original-recipient-field - per ietf-receipt-MDN specification 743 - final-recipient-field - per ietf-receipt-MDN specification 745 - original-message-id-field - per ietf-receipt-MDN specification 747 - disposition-field - the following "disposition-mode" values SHOULD 748 be used for Internet EDI: 750 "automatic-action" - The disposition described by the disposi- 751 tion type was a result of an automatic 752 action, rather than an explicit instruc- 753 tion by the user for this message. 755 "manual-action" - The disposition described by the disposi- 756 tion type was a result of an explicit 757 instruction by the user rather than some 758 sort of automatically performed action. 760 "MDN-sent-automatically" - The MDN was sent because the UA had 761 previously been configured to do so. 763 "MDN-sent-manually" - The user explicitly gave permission for 764 this particular MDN to be sent. "MDN- 765 sent-manually" is meaningful with 766 "manual-action", but not with "automatic- 767 action". 769 - disposition-field - the following "disposition-type" values SHOULD 770 be used for Internet EDI: 772 "processed" - The message has been processed in some manner 773 (e.g., printed, faxed, forwarded, gatewayed) 774 without being displayed to the user. The user may 775 or may not see the message later. 777 "failed" - A failure occurred that prevented the proper gener- 778 ation of an MDN. More information about the cause of 779 the failure may be contained in a Failure field. The 780 "failed" disposition type is not to be used for the 781 situation in which there is some problem in 782 processing the message other than interpreting the 783 request for an MDN. The "processed" or other dis- 784 position type with appropriate disposition modifiers 785 is to be used in such situations. 787 - disposition-field - the following "disposition-modifier" values 788 SHOULD be used for Internet EDI: 790 "error" - An error of some sort occurred 791 that prevented successful 792 processing of the message. 793 Further information is contained 794 in an Error field. 796 "warning" - The message was successfully 797 processed but some sort of 798 exceptional condition occurred. 799 Further information is contained 800 in a Warning field. 802 5.3.1 Message Disposition Notification Extensions 804 The following "extension field" will be added in order to support 805 signed receipts for RFC 1767 MIME content type and multipart MIME 806 content types that include the RFC 1767 MIME content type. The 807 "extension field" defined below follows the "disposition-field" in the 808 MDN. 810 The "Received-content-MIC" extension field is set when the integrity 811 of the received message is verified. The MIC is the base64 encoded 812 quantity computed over the received message with a hash 813 function. For details of "what" the "Received-content-MIC" should be 814 calculated over, see Section 5.2.1. The algorithm used to calculate the 815 "Received-content-MIC" value MUST be the same as the "micalg" value 816 used by the sender in the multipart/signed message. When no signature 817 is received, then it is RECOMMENDED that the SHA1 algorithm be used 818 to calculate the MIC on the received message or message contents. 820 This field is set only when the contents of the message are processed 821 successfully. This field is used in conjunction with the recipient's 822 signature on the MDN in order for the sender to verify "non-repudiation 823 of receipt". 825 - extension field = "Received-content-MIC" ":" MIC 827 where: 829 = "," 831 = the result of the one way hash function, base64 832 encoded. 834 MIME-based Secure EDI 8 July 199 836 < micalg> = the micalg value defined in RFC1847, an IANA registered 837 MIC algorithm ID token. 839 5.3.2 Disposition Mode, Type, and Modifier Use 841 Guidelines for use of the "disposition-mode", "disposition-type", and 842 "disposition-modifier" fields within Internet EDI are discussed in 843 this section. The "disposition-mode", "disposition-type', and 844 "disposition-modifier' fields are described in detail in draft-ietf- 845 receipt-mdn-04.txt. The "disposition-mode', "disposition-type" and 846 "disposition-modifier" values SHOULD be used as follows: 848 5.3.2.1 Successful Processing 850 When the request for a receipt or signed receipt, and the 851 received message contents are successfully processed by the receiving 852 EDI UA, a receipt or MDN SHOULD be returned with the "disposition- 853 type" set to 'processed'. When the MDN is sent automatically by the 854 EDI UA, and there is no explicit way for a user to control the sending of 855 the MDN, then the first part of the "disposition-mode" should be set 856 to "automatic-action". When the MDN is being sent under user 857 configurable control, then the first part of the "disposition-mode" 858 should be set to "manual-action". Since a request for a signed receipt 859 should always be honored, the user MUST not be allowed to configure 860 the UA to not send a signed receipt when the sender requests one. 862 The second part of the "disposition-mode" is set to "MDN-sent-manually" 863 if the user gave explicit permission for the MDN to be sent. Again, the 864 user MUST not be allowed to explicitly refuse to send a signed receipt 865 when the sender requests one. The second part of the "disposition- 866 mode" is set to "MDN-sent-automatically" whenever the EDI UA sends 867 the MDN automatically, regardless of whether the sending was under a 868 user�s, administrator�s, or under software control. 870 Since EDI content is generally handled automatically by the EDI UA, 871 a request for a receipt or signed receipt will generally return the 872 following in the "disposition-field": 874 Disposition: automatic-action/MDN-sent-automatically; processed 876 Note this specification does not restrict the use of the 877 "disposition-mode" to just automatic actions. Manual actions are 878 valid as long as it is kept in mind that a request for a signed 879 receipt MUST be honored. 881 5.3.2.2 Unprocessed Content 882 The request for a signed receipt requires the use of two 883 "disposition-notification-options", which specify the protocol 884 format of the returned signed receipt, and the MIC algorithm used 885 to calculate the hash over the MDN. The "disposition-field" values 886 that should be used in the case where the message content is being 887 rejected or ignored, for instance if the EDI UA determines that a 888 signed receipt cannot be returned because it does not support the 889 requested protocol format, so the EDI UA chooses not to process 890 the message contents itself, should be specified in the MDN 891 "disposition-field" as follows: 893 Disposition: "disposition-mode"; failed, Failure: unsupported format 895 The syntax of the "failed" "disposition-type" is general, allowing 896 the sending of any textual information along with the "failed" 897 "disposition-type". For use in Internet EDI, the following "failed" 898 values are defined: 900 "Failure: unsupported format" 901 "Failure: unsupported MIC-algorithms" 903 5.3.2.3 Content Processing Errors 905 When errors occur processing the received message content, the 906 "disposition-field" should be set to the "processed" "disposition- 907 type" value and the "error" "disposition-modifier" value. For use 908 in Internet EDI, the following "error" "disposition-modifier" values 909 are defined: 911 "Error: decryption-failed" - the receiver could not decrypt the 912 message contents. 914 "Error: authentication-failed" - the receiver could not authenticate 915 the sender. 917 "Error: integrity-check-failed" - the receiver could not verify 918 content integrity. 920 "Error: unexpected-processing-error" - a catch-all for any additional 921 processing errors. 923 An example of how the "disposition-field" would look when content 924 processing errors are detected is as follows: 926 Disposition: "disposition-mode"; processed, Error: decryption-failed 927 5.3.2.4 Content Processing Warnings 929 Situations arise in EDI where even if a trading partner cannot be 930 authenticated correctly, the trading partners still agree 931 to continue processing the EDI transactions. Transaction 932 reconciliation is done between the trading partners at a later 933 time. In the content processing warning situations as described 934 above, the "disposition-field' SHOULD be set to the "processed" 935 "disposition-type" value, and the "warning" "disposition-modifier" 936 value. For use in Internet EDI, the following "warning" 937 �disposition-modifier� values are defined: 939 "Warning: authentication-failed, processing continued" 941 An example of how the "disposition-field" would look when content processing warnings 942 are detected is as follows: 944 Disposition: "disposition-mode"; processed, Warning: 945 authentication-failed, processing continued 947 5.4 Message Disposition Notification Processing 949 5.4.1 Large File Processing 951 Large EDI Interchanges sent via SMTP can be automatically 952 fragmented by some message transfer agents. A subtype of message, 953 "partial", is defined in RFC 2045 [1] to allow large objects to be 954 delivered as separate pieces of mail and to be automatically 955 reassembled by the receiving user agent. Using message, "partial", 956 can help alleviate fragmentation of large messages by different 957 message transfer agents, but does not completely eliminate the 958 problem. It is still possible that a piece of a partial message, 959 upon re-assembly, may prove to contain a partial message as well. 960 This is allowed by the Internet standards, and it is 961 the responsibility of the user agent to re-assemble the fragmented 962 pieces. 964 It is RECOMMENDED that the size of the EDI Interchange sent via 965 SMTP be configurable so that if fragmentation does occur, then 966 message, "partial" can be used to send the large EDI Interchange 967 in smaller pieces. RFC 2045 [1] defines the use of Content-Type: 968 message/partial. Support of the message/partial content type for 969 use in Internet EDI is OPTIONAL. 971 The receiving UA is required to re-assemble the original message 972 before sending the message disposition notification to the 973 original sender of the message. A message disposition notification 974 is used to specify the disposition of the entire message that was 975 sent, and should not be returned by a processing UA until the 976 entire message is received, even if the received message requires 977 re-assembling. 979 In general, EDI content compresses well, since there is repetitive 980 data in most EDI Interchanges. Instead of implementing the 981 message/partial, compression of the EDI Interchange can be done 982 after the signature is applied to the EDI Interchange, and before 983 encryption. When no signature is applied, then compression is applied 984 before the encryption. Compression is an alternative solution to 985 implementing Content-Type: message/partial when sending large EDI 986 Interchanges on the Internet. 988 Applying compression before encryption strengthens cryptographic 989 security since repetitious strings are reduced. This sequence of 990 signature, compression, then encryption, or compression then 991 encryption, is consistent with the order in which PGP 992 implementations handle compression. 994 Note: Compression is done automatically when using PGP encryption. 996 The MIME standards [1], do not define a way in which to convey 997 that a message has been compressed. However, RFC 2045 [1] does 998 allow the definition of additional MIME header fields to further 999 describe the content of a message. 1001 RFC 2068 [11], the HTTP/1.1 specification does define a Content- 1002 Encoding field that is primarily used to convey compression 1003 information: 1005 Content-Encoding = "Content-Encoding" ":" content-coding 1007 where content-coding can take on the values of "gzip" or "compress". 1009 The gzip compression standard is further described in RFC 1952 [12], 1010 and compress is the standard UNIX file compression program. Both 1011 gzip and compress are registered with IANA. 1013 Trading partners can adopt the use of the Content-Encoding header if 1014 they need to compress their EDI data and convey the compression 1015 type to their trading partners. 1017 5.4.2 Example 1019 The following is an example of a signed receipt returned by a UA 1020 after successfully processing a MIME EDI content type. The sending 1021 trading partner has requested a return signed receipt. 1023 MIME-based Secure EDI 8 July 199 1025 This example follows the S/MIME application/x-pkcs-7-signature 1026 format. 1028 NOTE: This example is provided as an illustration only, and is 1029 not considered part of the protocol specification. If an example 1030 conflicts with the protocol definitions specified above or in the 1031 other referenced RFCs, the example is wrong. 1033 To: 1034 Subject: 1035 From: 1036 Date: 1037 Mime-Version: 1.0 1038 Content-Type: multipart/signed; boundary="separator"; 1039 micalg=rsa-sha1; protocol="application/x-pkcs7-signature" 1041 --separator 1042 &Content-Type: multipart/report; report-type=disposition 1043 & notification; boundary = "xxxxx" 1044 & 1045 &--xxxxx 1046 &Content-Type: text/plain 1047 & 1048 &The message sent to Edi Recipient 1049 &has been received, the EDI Interchange was successfully 1050 &decrypted and its integrity was verified. In addition, the 1051 &sender of the message, Edi Sender 1052 &was authenticated as the originator of the message. There is 1053 &no guarantee however that the EDI Interchange was 1054 &syntactically correct, or was received by the EDI 1055 &application. 1056 & 1057 &--xxxxx 1058 &Content-Type: message/disposition-notification 1059 & 1060 &Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0) 1061 &Original-Recipient: rfc822; Edi_Recipient@edicorp.com 1062 &Final-Recipient: rfc822; Edi_Recipient@edicorp.com 1063 &Original-Message-ID: <17759920005.12345@edicorp.com> 1064 &Disposition: automatic-action/MDN-sent-automatically, processed 1065 &Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, rsa-sha1 1066 & 1067 &--xxxxx 1068 &Content-Type: message/rfc822 1069 & 1070 &To: 1071 &Subject: 1072 & 1073 & [additional header fields go here] 1074 & 1075 &--xxxxx-- 1077 --separator 1078 Content-Type: application/x-pkcs7-signature 1079 Content-Transfer-Encoding: base64 1081 @ContentType = SignedData 1082 @version = Version 1083 @digestAlgorithms = DigestAlgorithmIdentifiers 1084 @signerInfos = SignerInfo 1085 --separator-- 1087 Notes: 1089 -The lines preceded with "&" is what the signature is calculated 1090 over. 1092 -The text preceded by "@" indicates PKCS#7 defined fields and types. 1094 (For details on how to prepare the multipart/signed with protocol 1095 = "application/x-pkcs7-signature" see the "S/MIME Message 1096 Specification, PKCS Security Services for MIME".) 1098 Note: As specified by RFC 1892 [10], returning the original or 1099 portions of the original message in the third body part of the 1100 multipart/report is not required. This is an optional body part. It is 1101 RECOMMENDED that the received headers from the original 1102 message be placed in the third body part, as they can be helpful in 1103 tracking problems. 1105 Also note that the textual first body part of the multipart/report 1106 can be used to include a more detailed explanation of the error 1107 conditions reported by the disposition headers. The first body 1108 part of the multipart/report when used in this way, allows a 1109 person to better diagnose a problem in detail. 1111 6. Public key certificate handling 1113 6.1 Near term approach 1115 In the near term, the exchange of public keys and certification 1117 MIME-based Secure EDI 8 July 199 1119 of these keys must be handled as part of the process of 1120 establishing a trading partnership. The UA and/or EDI application 1121 interface must maintain a database of public keys used for 1122 encryption or signatures, in addition to the mapping between EDI 1123 trading partner ID and RFC 822 [3] email address. The procedures for 1124 establishing a trading partnership and configuring the secure EDI 1125 messaging system might vary among trading partners and software 1126 packages. 1128 For systems which make use of X.509 certificates, it is RECOMMENDED 1129 that trading partners self-certify each other if an agreed upon 1130 certification authority is not used. It is highly RECOMMENDED that 1131 when trading partners are using S/MIME, that they also exchange 1132 public key certificates using the recommendations specified in the 1133 S/MIME Implementation Guide Version 2. The message formats and 1134 S/MIME conformance requirements for certificate exchange are 1135 specified in this document. 1137 This applicability statement does NOT require the use of a 1138 certification authority. The use of a certification authority 1139 is therefore OPTIONAL. 1141 6.2 Long term approach 1143 In the long term, additional Internet-EDI standards may be 1144 developed to simplify the process of establishing a trading 1145 partnership, including the third party authentication of trading 1146 partners, as well as attributes of the trading relationship. 1148 7. Acknowledgments 1150 The authors would like to extend special thanks to Carl Hage, 1151 Jun Ding, Dale Moberg, and Karen Rosenthal for providing the team 1152 with valuable, and very thorough feedback. Without participants like 1153 those cited above, these efforts become hard to complete in a way 1154 useful to the users and implementers of the technology. 1156 In addition, the authors would like to thank Harald Alvestrand, Jim Galvin, 1157 and Roger Fajman for their guidance and input. 1159 8. References 1161 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1162 Part One: Format of Internet Message Bodies", RFC 2045, December 02, 1996. 1164 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1165 Part Two: Media Types", RFC 2046, December 02, 1996. 1167 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1168 Part Five: Conformance Criteria and Examples", RFC 2049 , December 02, 1169 1996. 1171 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 1172 2, 1995. 1174 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 1175 Messages", STD 11, RFC 822, August 13, 1982. 1177 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 1178 2015, Sept. 1996. 1180 [5] R. Fajman, "An Extensible Message Format for Message Disposition 1181 Notifications", draft-ietf-receipt-mdn-04.txt, June 14, 1997. 1183 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts 1184 for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 1185 3, 1995 1187 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 1188 August 1, 1982. 1190 [8] S. Dusse, "S/MIME Message Specification; PKCS Security 1191 Services for MIME", Internet draft: draft-dusse-mime-msg-spec 1192 00.txt 1194 [9] C. Shih, "Requirements for Inter-operable Internet EDI", 1195 Internet draft: draft-ietf-ediint-req03.txt July 1997. 1197 [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting 1198 of Mail System Administrative Messages", RFC 1892, January 15, 1199 1996. 1201 [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext 1202 Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. 1204 [12] L. Deutsch, "GZIP File Format Specification Version 4.3", RFC 1952, 1205 May 23, 1996. 1207 9. Authors' Addresses 1209 Chuck Shih 1210 chucks@actracorp.com 1211 Actra Corp. 1212 610 East Caribbean Drive 1213 Sunnyvale, CA 94089 USA 1215 Mats Jansson 1216 mjansson@agathon.com 1217 LiNK 1218 2317 Broadway, Suite 330 1219 Redwood City, CA 94063 USA 1221 Rik Drummond 1222 drummond@onramp.com 1223 The Drummond Group 1224 5008 Bentwood Ct. 1225 Ft. Worth, TX 76132 USA