idnits 2.17.1 draft-ietf-ediint-as1-08.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. Found some kind of copyright notice around line 33 but it does not match any copyright boilerplate known by this tool. 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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 14) being 68 lines == 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 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 7 characters in excess of 72. ** There are 8 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 253: '...then the receipt MUST be returned with...' RFC 2119 keyword, line 257: '... or unsigned SHOULD be returned. I...' RFC 2119 keyword, line 319: '...ed however, a signature is REQUIRED as...' RFC 2119 keyword, line 322: '...d receipt or MDN SHOULD be returned wi...' RFC 2119 keyword, line 343: '...e is used, it is RECOMMENDED that the ...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 161 has weird spacing: '... as descr...' == Line 811 has weird spacing: '...here is some ...' == Line 919 has weird spacing: '...quested proto...' == Line 1130 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 (May 1998) is 9471 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) ** Obsolete normative reference: RFC 2298 (ref. '5') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) ** Downref: Normative reference to an Historic RFC: RFC 2312 (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: 19 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EDIINT Working Group Chuck Shih 3 draft-ietf-ediint-as1-08.txt Mats Jansson 4 Expires: Dec 1998 Rik Drummond 5 May 1998 7 MIME-based Secure EDI 9 draft-ietf-ediint-as1-08.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Copyright Notice 33 Copyright (c) The Internet Society (1998). All rights reserveds. 35 Abstract 37 This document describes how to securely exchange EDI documents 38 using MIME and public key cryptography. 40 Feedback Instructions: 42 If you want to provide feedback on this draft, follow these guidelines: 44 -Send feedback via e-mail to the ietf-ediint list for discussion, with 45 "AS#1"� in the Subject field. To enter/follow the discussion, you 46 need to subscribe at ietf-ediint@imc.org. 48 -Be specific as to what section you are referring to, preferably 49 quoting the portion that needs modification, after which you state 50 your comments. 52 -If you are recommending some text to be replaced with your suggested 53 text, again, quote the section to be replaced, and be clear on the 54 section in question. 56 Table of Contents 58 Security Considerations 3 59 1. Introduction 3 61 2. Overview 4 62 2.1 Purpose of a security guideline for MIME EDI 4 63 2.2 Definitions 64 2.2.1 Terms 4 65 2.2.2 The secure transmission loop 5 66 2.2.3 Definition of receipts 5 67 2.3 Assumptions 68 2.3.1 EDI process assumptions 6 69 2.3.2 Flexibility assumptions 7 71 3. Referenced RFCs and their contribution 8 72 3.1 RFC 821 SMTP [7] 8 73 3.2 RFC 822 Text Message Format [3] 9 74 3.3 RFC 1847 MIME Security Multiparts [6] 9 75 3.4 RFC 1892 Multipart/report [9] 9 76 3.5 RFC 1767 EDI Content [2] 9 77 3.6 RFC 2015 PGP/MIME [4] 9 78 3.7 RFC 2045, 2046 and 2049 MIME [1] 9 79 3.8 RFC 2298 Message Disposition Notification [5] 9 80 3.9 RFC 2311 & 2312 S/MIME V2 Message Specification [8] 9 82 4. Structure of an EDI MIME message - Applicability 10 83 4.1 Introduction 10 84 4.2 Structure of an EDI MIME message - PGP/MIME 10 85 4.2.1 No encryption, no signature 10 86 4.2.2 No encryption, signature 10 87 4.2.3 Encryption, no signature 10 88 4.2.4 Encryption, signature 10 89 4.3 Structure of an EDI MIME message - S/MIME 11 90 4.3.1 No encryption, no signature 11 91 4.3.2 No encryption, signature 11 92 4.3.3 Encryption, no signature 11 93 4.3.4 Encryption, signature 11 95 5. Receipts 11 96 5.1 Introduction 11 97 5.2 Requesting a signed receipt 14 98 5.2.1 Additional signed receipt considerations 15 99 5.3 Message Disposition Notification Format 16 100 5.3.1 Message Disposition Notification Extensions 18 101 5.3.2 Disposition Mode, Type and Modifier Use 19 102 5.3.2.1 Successful Processing 19 103 5.3.2.2 Unprocessed Content 19 104 5.3.2.3 Content Processing Errors 20 105 5.3.2.4 Content Processing Warnings 21 106 5.4 Message Disposition Notification Processing 21 107 5.4.1 Large File Processing 21 108 5.4.2 Example 22 110 6. Public key certificate handling 24 111 6.1 Near term approach 24 112 6.2 Long term approach 24 114 7. Acknowledgments 25 116 8. References 26 118 9. Authors' Addresses 27 120 Security Considerations 122 This document discusses the mechanisms, requirements 123 and technologies necessary to conduct secure EDI over 124 Internet using either PGP/MIME or S/MIME. It further 125 discusses the implementation of encryption, digital 126 signature, integrity and signed-receipt for MIME objects 127 transported over SMTP or HTTP. 129 1. Introduction 131 Previous work on Internet EDI focused on specifying MIME content 132 types for EDI data ([2] RFC 1767). This Applicability Statement 133 expands on RFC 1767 to specify use of a comprehensive set of data 134 security features, specifically data privacy, data 135 integrity/authenticity, non-repudiation of origin and non- 136 repudiation of receipt. This draft recognizes contemporary RFCs 137 and Internet drafts and is attempting to "re-invent" as little as 138 possible. 140 With an enhancement in the area of "receipts", as described below 141 (3.1.8), secure Internet MIME based EDI can be accomplished by 142 using and complying with the following RFCs: 144 -RFC 821 SMTP 145 -RFC 822 Text Message Formats 146 -RFC 1767 EDI Content Type 147 -RFC 1847 Security Multiparts for MIME 148 -RFC 1892 Multipart/Report 149 -RFC 2015 MIME/PGP 150 -RFC 2045 to 2049 MIME RFCs 151 -RFC 2298 Message Disposition Notification 152 -RFC 2311 S/MIME Specification 154 Our intent here is to define clearly and precisely how these 155 are used together, and what is required by user agents to be 156 compliant with this Applicability Statement. 158 Note that the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 159 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 160 "MAY", and "OPTIONAL" in this document are to be interpreted 161 as described in RFC 2119. 163 2. Overview 165 2.1 Purpose of a security guideline for MIME EDI 167 The purpose of these specifications is to ensure interoperability 168 between EDI user agents, invoking some or all of the commonly 169 expected security features. This standard is also NOT limited to 170 strict EDI use, but applies to any electronic commerce application 171 where business data needs to be exchanged over the Internet in a 172 secure manner. 174 2.2 Definitions 176 2.2.1. Terms 178 EDI Electronic Data Interchange 180 EC Electronic Commerce 182 Receipt The functional message that is sent from a 183 receiver to a sender to acknowledge receipt 184 of an EDI/EC interchange. 186 Signed Receipt Same as above, but with a digital signature. 188 Message Disposition The Internet messaging format used to 189 Notification convey a receipt. This term is used 190 interchangeably with receipt. A signed 191 MDN is a signed receipt. 193 Non-repudiation of NRR is a "legal event" that occurs when the 194 Receipt (NRR) original sender of an EDI/EC interchange has 195 verified the signed receipt coming back from 196 the receiver. NRR IS NOT a functional or a 197 technical message. 199 PGP/MIME Digital envelope security based on the Pretty 200 Good Privacy (PGP) standard (Zimmerman), 201 integrated with MIME Security Multiparts [6]. 203 S/MIME A format and protocol for adding cryptographic 204 signature and/or encryption services to 205 Internet MIME messages. 207 2.2.2 The secure transmission loop 209 The functional requirements document, [9] "Requirements for Inter- 210 operable Internet EDI" (can be found at www.ietf.org), provides 211 extensive information on EDI security and the user/business related 212 processes surrounding the need for and use of EDI security. In 213 this document, it is assumed that the reader is familiar with the 214 requirements document. 216 This document's focus is on the formats and protocols for 217 exchanging EDI content that has had security applied to it using 218 the Internet's messaging transport. 220 The "secure transmission loop" for EDI involves one organization 221 sending a signed and encrypted EDI interchange to another 222 organization, requesting a signed receipt, followed later by the 223 receiving organization sending this signed receipt back to the 224 sending organization. In other words, the following transpires: 226 -The organization sending EDI/EC data encrypts the data and 227 provides a digital signature, using either PGP/MIME or S/MIME. 228 In addition, they request a signed receipt. 230 -The receiving organization decrypts the message and verifies 231 the signature, resulting in verified integrity of the data and 232 authenticity of the sender. 234 -The receiving organization then sends a signed receipt in the 235 form of a signature over the hash of a message disposition 236 notification, which contains a hash of the received message. 238 The above describes functionality which if implemented, would 239 satisfy all security requirements. This specification, however, 240 leaves full flexibility for users to decide the degree to which 241 they want to deploy those security features with their EDI 242 trading partners. 244 2.2.3 Definition of receipts 246 The term used for both the functional activity and message for 247 acknowledging receipt of an EDI/EC interchange is receipt, or 248 signed receipt. The first term is used if the acknowledgment is 249 for an interchange resulting in a receipt which is NOT signed. 250 The second term is used if the acknowledgment is for an interchange 251 resulting in a receipt which IS signed. The "rule" is: If a 252 receipt is requested, explicitly specifying that the receipt be 253 signed, then the receipt MUST be returned with a signature. 254 If a receipt is requested, explicitly specifying that the receipt 255 be signed, but the recipient cannot support the requested protocol 256 format or requested MIC algorithms, then a receipt, either signed 257 or unsigned SHOULD be returned. If a signature is not explicitly 258 requested, or if the signed receipt request parameter is not 259 recognized by the UA, all bets are off -- a receipt may or may not 260 be returned. This behavior is consistent with the MDN RFC 2298. 262 A term often used in combination with receipts is "Non-repudiation 263 of Receipt (NRR). NRR refers to a legal event which occurs only 264 when the original sender of an interchange has verified the sender 265 and content of a signed receipt. Note that NRR is not possible 266 without signatures. 268 2.3 Assumptions 270 2.3.1 EDI process assumptions 272 -Encrypted object is an EDI Interchange 274 This specification assumes that a typical EDI interchange is 275 the lowest level object that will be subject to security 276 services. 278 In ANSI X12, this means anything between, and including 279 segments ISA and IEA. In EDIFACT, this means anything between, 280 and including, segments UNA/UNB and UNZ. In other words, the 281 EDI interchanges including envelope segments remain intact and 282 unreadable during secure transport. 284 -EDI envelope headers are encrypted 286 Congruent with the above statement, EDI envelope headers are NOT 287 visible in the MIME package. In order to optimize VAN-to- 288 Internet routing, work may need to be done in the future to 289 define ways to pull out some of the envelope information to make 290 them visible, however, this specification does not go into any 291 detail on that. 293 -X12.58 and UN/EDIFACT security considerations 295 The most common EDI standards bodies, ANSI X12 and EDIFACT, 296 have defined internal provisions for security. X12.58 is the 297 security mechanism for ANSI X12 and AUTACK provides security for 298 EDIFACT. This specification DOES NOT dictate use or non-use 299 of these security standards. They are both fully compatible, 300 though possibly redundant, with this specification. 302 2.3.2 Flexibility assumptions 304 -Encrypted or un-encrypted data 306 This specification allows for EDI message exchange where the 307 EDI data can either be un-protected or protected by means of 308 encryption. 310 -Signed or un-signed data 312 This specification allows for EDI message exchange with or 313 without digital signature of the original EDI transmission. 315 -Use of receipt or not 317 This specification allows for EDI message transmission with or 318 without a request for receipt notification. If a signed receipt 319 notification is requested however, a signature is REQUIRED as 320 part of the returned receipt, unless an error condition occurs 321 in which a signed-receipt cannot be returned. In error cases,an 322 un-signed receipt or MDN SHOULD be returned with the correct 323 "disposition modifier" error value. 325 -Formatting choices 327 This specification defines the use of two methods for formatting 328 EDI contents that have security applied to it: 330 -PGP/MIME 331 -S/MIME 333 This specification relies on the guidelines set forth in 334 RFC 2015, as reflected in [4] "MIME Security with Pretty Good 335 Privacy" (PGP), and RFC 2311/ 2312 [8] "S/MIME Message 336 Specification; PKCS Security Services for MIME". Compliance with 337 this specification REQUIRES the use of PGP/MIME or S/MIME 338 as defined in this Applicability statement, and the [9] 339 "Requirements for Inter-operable Internet EDI" draft. 341 -Hash function, message digest choices 343 When signature is used, it is RECOMMENDED that the SHA1 hash 344 algorithm be used for all outgoing messages, and that both 345 MD5 and SHA1 be supported for incoming messages. 347 In summary, the following eight permutations are possible in 348 any given trading relationship: 350 (1) Sender sends un-encrypted data, does NOT request a receipt. 352 (2) Sender sends un-encrypted data, requests a signed or 353 unsigned receipt. The receiver sends back the signed or 354 unsigned receipt. 356 (3) Sender sends encrypted data, does NOT request a receipt. 358 (4) Sender sends encrypted data, requests a signed or 359 unsigned receipt. The receiver sends back the signed 360 or un-signed receipt. 362 (5) Sender sends signed data, does NOT request a signed or 363 un-signed receipt. 365 (6) Sender sends signed data, requests a signed or un-signed 366 receipt. Receiver sends back the signed or un-signed receipt. 368 (7) Sender sends encrypted and signed data, does NOT request a 369 signed or un-signed receipt. 371 (8) Sender sends encrypted and signed data, requests a signed or 372 un-signed receipt. Receiver sends back the signed or un- 373 signed receipt. 375 NOTE: Users can choose any of the eight possibilities, but only 376 example (8), when a signed receipt is requested, offers the 377 whole suite of security features described in the "Secure 378 transmission loop" above. 380 3. Referenced RFCs and their contribution 382 3.1 RFC 821 SMTP [7] 384 This is the core mail transfer standard that all MTAs need to 385 adhere to. 387 3.2 RFC 822 Text Message Format [3] 389 Defines message header fields and the parts making up a message. 391 3.3 RFC 1847 MIME Security Multiparts [6] 393 This document defines security multiparts for MIME: 394 multipart/encrypted and multipart/signed. 396 3.4 RFC 1892 Multipart/report [10] 398 This RFC defines the use of the multipart/report content type, 399 something that the MDN RFC 2298 builds upon. 401 3.5 RFC 1767 EDI Content [2] 403 This RFC defines the use of content type "application" for ANSI 404 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 405 mutually defined EDI (application/EDI-Consent). 407 3.6 RFC 2015 PGP/MIME [4] 409 This RFC defines the use of content types 410 "multipart/encrypted", "multipart/signed", "application/pgp 411 encrypted" and "application/pgp-signature" for defining MIME PGP 412 content. 414 3.7 RFC 2045, 2046, and 2049 MIME [1] 416 These are the basic MIME standards, upon which all MIME related RFCs 417 build, including this one. Key contributions include definition of 418 "content type", "sub-type" and "multipart", as well as encoding 419 guidelines, which establishes 7-bit US-ASCII as the canonical 420 character set to be used in Internet messaging. 422 3.8 RFC 2298 Message Disposition Notification [5] 424 This Internet RFC defines how a message disposition notification 425 (MDN) is requested, and the format and syntax of the MDN. The MDN 426 is the basis upon which receipts and signed receipts are defined 427 in this and the "Requirements" specification. 429 3.9 RFC 2311 and 2312 S/MIME Message Specifications [8] 431 This specification describes how MIME shall carry PKCS7 432 envelopes. 434 4. Structure of an EDI MIME message - Applicability 436 4.1 Introduction 438 The structures below are described hierarchically in terms of which 439 RFC's are applied to form the specific structure. For details of 440 how to code in compliance with all RFC's involved, turn directly to 441 the RFC's referenced. The "requirements document" has several 442 examples described in an Appendix for those interested. 444 Also, these structures describe the initial transmission only. 445 Receipts, and requests for receipts are handled in section 5. 447 4.2 Structure of an EDI MIME message - PGP/MIME 449 4.2.1 No encryption, no signature 451 -RFC822/2045 452 -RFC1767 (application/EDIxxxx) 454 4.2.2 No encryption, signature 456 -RFC822/2045 457 -RFC1847 (multipart/signed) 458 -RFC1767 (application/EDIxxxx) 459 -RFC2015 (application/pgp-signature) 461 4.2.3 Encryption, no signature 463 -RFC822/2045 464 -RFC1847 (multipart/encrypted) 465 -RFC2015 (application/pgp-encrypted) 466 -"Version 1" 467 -RFC1767 (application/EDIxxxx) (encrypted) 469 4.2.4 Encryption, signature 471 -RFC822/2045 472 -RFC1847 (multipart/encrypted) 473 -RFC2015 (application/pgp-encrypted) 474 -"Version 1" 475 -RFC1767 (application/EDIxxxx) (encrypted) 476 -RFC2015 (application/pgp-signature) (encrypted) 478 4.3 Structure of an EDI MIME message - S/MIME 480 4.3.1 No encryption, no signature 482 -RFC822/2045 483 -RFC1767 (application/EDIxxxx) 485 4.3.2 No encryption, signature 487 -RFC822/2045 488 -RFC1847 (multipart/signed) 489 -RFC1767 (application/EDIxxxx) 491 -RFC2311 (application/pkcs7-signature) 493 4.3.3 Encryption, no signature 495 -RFC822/2045 496 -RFC2311 (application/pkcs7-mime) 497 -RFC1767 (application/EDIxxxx) (encrypted) 499 4.3.4 Encryption, signature 501 -RFC822/2045 502 -RFC2311 (application/pkcs7-mime) 503 -RFC1847 (multipart/signed) (encrypted) 504 -RFC1767 (application/EDIxxxx) (encrypted) 505 -RFC2311 (application/pkcs7-signature) (encrypted) 507 5. Receipts 509 5.1 Introduction 511 In order to support non-repudiation of receipt (NRR), a signed 512 receipt, based on digitally signing a message disposition notification, 513 is to be implemented by a receiving trading partner's UA (User Agent). 514 The message disposition notification, specified by 515 RFC 2298 is digitally signed by a receiving 516 trading partner as part of a multipart/signed MIME message. 518 The following support for signed receipts is REQUIRED: 520 1). The ability to create a multipart/report; where the report-type 521 = disposition-notification. 522 2). The ability to calculate a message integrity check (MIC) on the 523 message disposition notification. 524 3). The ability to digitally sign the MIC. 525 4). The ability to create a multipart/signed content with the message 526 disposition notification as the first body part, and the signed 527 MIC calculated on the message disposition notification as the 528 second body part. 529 5). The ability to return the signed receipt to the sending trading partner. 531 The signed receipt is used to notify a sending trading partner that requested 532 the signed receipt that: 534 1). The receiving trading partner acknowledges receipt of 535 the sent EDI Interchange. 537 2). If the sent message was signed, then the receiving trading 538 partner has authenticated the sender of the EDI Interchange. 540 3). If the sent message was signed, then the receiving trading 541 partner has verified the integrity of the sent EDI Interchange. 543 Regardless of whether the EDI Interchange was sent in S/MIME or 544 PGP/MIME format, the receiving trading partner's UA MUST provide 545 the following basic processing: 547 1). If the sent EDI Interchange is encrypted, then the encrypted 548 symmetric key and initialization vector (if applicable) is 549 decrypted using the receiver's private key. 551 2). The decrypted symmetric encryption key is then used to decrypt 552 the EDI Interchange. 554 3). The receiving trading partner authenticates signatures in a 555 message using the sender's public key. The authentication 556 algorithm performs the following: 558 a). The message integrity check (MIC or Message Digest), 559 is decrypted using the sender's public key. 561 b). A MIC on the signed contents (the MIME header and encoded 562 EDI object, as per RFC 1767) in the message received is 563 calculated using the same one-way hash function that the 564 sending trading partner used. 566 c). The MIC extracted from the message that was sent, and the 567 MIC calculated using the same one-way hash function that 568 the sending trading partner used is compared for equality. 570 4). The receiving trading partner formats the MDN and sets the 571 calculated MIC into the "Received-content-MIC" extension field. 573 5). The receiving trading partner creates a multipart/signed MIME 574 message according to RFC 1847. 576 6). The MDN is the first part of the multipart/signed message, and 577 the digital signature is created over this MDN, including its 578 MIME headers. 580 7). The second part of the multipart/signed message contains the 581 digital signature. The "protocol" option specified in the 582 second part of the multipart/signed is as follows: 584 S/MIME: protocol = "application/pkcs-7-signature" 586 PGP/MIME: protocol = "application/pgp-signature" 588 8). The signature information is formatted according to S/MIME 589 or PGP/MIME specifications. 591 The EDI Interchange and the RFC 1767 MIME EDI content header, can 592 actually be part of a multi-part MIME content-type. When the EDI 593 Interchange is part of a multi-part MIME content-type, the MIC MUST be 594 calculated across the entire multi-part content, including the MIME 595 headers. The multi-part MIME content that contains the EDI Interchange 596 is then enveloped in either S/MIME or PGP/MIME format. 598 The signed MDN, when received by the sender of the EDI Interchange 599 can be used by the sender: 601 1). As an acknowledgment that the EDI Interchange sent, was 602 delivered and acknowledged by the receiving trading partner. 603 The receiver does this by returning the original message 604 id of the sent message in the MDN portion of the signed receipt. 606 2). As an acknowledgment that the integrity of the EDI Interchange 607 was verified by the receiving trading partner. The receiver 608 does this by returning the calculated MIC of the received EDI 609 Interchange (and 1767 MIME headers) in the "Received-content-MIC" 610 field of the signed MDN. 612 3). As an acknowledgment that the receiving trading partner has 613 authenticated the sender of the EDI Interchange. 615 4). As a non-repudiation of receipt when the signed MIC calculated 616 over the MDN, is successfully decrypted by the sender with the 617 receiving trading partner's public key. 619 5.2 Requesting a signed receipt 621 Message Disposition Notifications are requested as per RFC 2298, 622 "An Extensible Message Format for Message Disposition 623 Notification". A request that the receiving user agent issue a 624 message disposition notification is made by placing the following header 625 into the message to be sent: 627 MDN-request-header = "Disposition-notification-to" ":" mail-address 629 The mail-address field is specified as an RFC 822 user@domain address, 630 and is the return address for the message disposition notification. 632 In addition to requesting a message disposition notification, a message 633 disposition notification that is digitally signed, or what has been 634 referred to as a signed receipt, can be requested by placing the 635 following in the message header following the "Disposition- 636 notification-to" line. 638 Disposition-notification-options = "Disposition-notification-options" ":" 639 disposition-notification-parameters 641 where 643 disposition-notification-parameters = parameter *(";" parameter) 645 where 647 parameter = attribute "=" importance ", " 1#value " 649 where 651 importance = "required" | "optional " 653 So the the Disposition-notification-options string could be either 655 optional, signed-receipt-protocol, ; 657 optional, signed-receipt-micalg, , ,...; 659 The currently supported values for are "pkcs7- 660 signature", for the S/MIME detached signature format, or "pgp-signature", 661 for the pgp signature format. 663 The signed-receipt-micalg is a list of MIC algorithm values defined in 664 RFC1847, an IANA registered MIC algorithm ID token. 666 An example of a formatted options line would be as follows: 668 Disposition-notification-options: optional, signed-receipt-protocol, 669 pkcs7-signature; optional, signed-receipt-micalg, md5; 671 The semantics of the "signed-receipt-protocol" parameter is as follows: 673 1). The "signed-receipt-protocol" parameter is used to request a signed 674 receipt from the recipient trading partner. The "signed-receipt- 676 protocol" parameter also specifies the format in which the signed 677 receipt should be returned to the requester. 679 The "signed-receipt-micalg" parameter is a list of MIC algorithms 680 preferred by the requester for use in signing the returned receipt. 681 The list of MIC algorithms should be honored by the recipient from 682 left to right. 684 Both the "signed-receipt-protocol" and the "signed-receipt-micalg" 685 option parameters are REQUIRED when requesting a signed receipt. 687 2). The "importance" attribute of "Optional" is defined in the MDN RFC 2298 and 688 has the following meaning: 690 Parameters with an importance of "Optional" permit a UA that does not 691 understand the particular options parameter to still generate a MDN 692 in response to a request for a MDN. A UA that does not understand the 693 "signed-receipt-protocol" parameter, will obviously not return a 694 signed receipt. 696 The importance of "Optional" is used for the signed receipt parameters 697 because it is RECOMMENDED that an MDN be returned to the requesting 698 trading partner even if the recipient could not sign it. The returned 699 MDN will contain information on the disposition of the message 700 as well as why the MDN could not be signed. See the disposition 701 field in section 5.3 for more information. 703 Within an EDI trading relationship, if a signed receipt is expected 704 and is not returned, then the validity of the transaction is up to the 705 trading partners to resolve. In general, if a signed receipt is 706 required in the trading relationship and is not received, the 707 transaction will likely not be considered valid. 709 5.2.1 Additional Signed Receipt Considerations 711 The "rules" stated in Section 2.2.3 for signed receipts are as 712 follows: 714 1). When a receipt is requested, explicitly specifying that the 715 receipt be signed, then the receipt MUST be returned with a 716 signature. 718 2). When a receipt is requested, explicitly specifying that the 719 receipt be signed, but the recipient cannot support either 720 the requested protocol format, or requested MIC algorithms, 721 then either a signed or unsigned receipt SHOULD be returned. 723 3). When a signature is not explicitly requested, or if the 724 signed receipt request parameter is not recognized by the UA, 725 then all bets are off. In this situation, no receipt, an unsigned 726 receipt, or a signed receipt MAY be returned by the recipient. 728 NOTE: For Internet EDI, it is RECOMMENDED that when a signature is not 729 explicitly requested, or if parameters are not recognized, that the UA 730 send back at a minimum, an unsigned receipt. If a signed receipt however 731 was always returned as a policy, whether requested or not, then any false 732 unsigned receipts can be repudiated. 734 When a request for a signed receipt is made, but there is an error in 735 processing the contents of the message, a signed receipt MUST still 736 be returned. The request for a signed receipt SHALL still be honored, 737 though the transaction itself may not be valid. The reason for why the 738 contents could not be processed MUST be set in the "disposition-field". 740 When a request for a signed receipt is made, the "Received-content-MIC" 741 MUST always be returned to the requester. The "Received-content-MIC" 742 MUST be calculated as follows: 744 - For any signed messages, the MIC to be returned is calculated 745 on the RFC1767 MIME header and content, or the multipart MIME 746 header and content. Canonicalization as specified in RFC 1848 MUST 747 be performed before the MIC is calculated, since the sender 748 requesting the signed receipt was also REQUIRED to canonicalize. 750 - For encrypted, unsigned messages, the MIC to be returned is 751 calculated on the decrypted RFC 1767 MIME header and content, 752 or the multipart MIME header and content. The content after 753 decryption MUST be canonicalized before the MIC is calculated. 755 - For unsigned, unencrypted messages, the MIC MUST be calculated 756 over the message contents prior to Content-Transfer-Encoding or 757 Content-Encoding, and without the MIME or any other RFC 822 758 headers, since these are sometimes altered or reordered by MTAs. 760 5.3 Message Disposition Notification Format 762 The format of a message disposition notification is specified in 763 RFC 2298 For use in Internet EDI, the following format will be used: 765 - content-type - per RFC 1892 and the RFC 2298 specification 767 - reporting-ua-field - per RFC 2298 specification 768 - MDN-gateway-field - per RFC 2298 specification 770 - original-recipient-field - per RFC 2298 specification 772 - final-recipient-field - per RFC 2298 specification 774 - original-message-id-field - per RFC 2298 specification 776 - disposition-field - the following "disposition-mode" 777 values SHOULD be used for 778 Internet EDI: 780 "automatic-action" - The disposition described by the disposi- 781 tion type was a result of an automatic 782 action, rather than an explicit instruc- 783 tion by the user for this message. 785 "manual-action" - The disposition described by the disposi- 786 tion type was a result of an explicit 787 instruction by the user rather than some 788 sort of automatically performed action. 790 "MDN-sent-automatically" - The MDN was sent because the UA had 791 previously been configured to do so. 793 "MDN-sent-manually" - The user explicitly gave permission for 794 this particular MDN to be sent. "MDN- 795 sent-manually" is meaningful with 796 "manual-action", but not with "automatic- 797 action". 799 - disposition-field - the following "disposition-type" values SHOULD 800 be used for Internet EDI: 802 "processed" - The message has been processed in some manner 803 (e.g., printed, faxed, forwarded, gatewayed) 804 without being displayed to the user. The user may 805 or may not see the message later. 807 "failed" - A failure occurred that prevented the proper gener- 808 ation of an MDN. More information about the cause of 809 the failure may be contained in a Failure field. The 810 "failed" disposition type is not to be used for the 811 situation in which there is some problem in 812 processing the message other than interpreting the 813 request for an MDN. The "processed" or other dis- 814 position type with appropriate disposition modifiers 815 is to be used in such situations. 817 - disposition-field - the following "disposition-modifier" values 818 SHOULD be used for Internet EDI: 820 "error" - An error of some sort occurred 821 that prevented successful 822 processing of the message. 823 Further information is contained 824 in an Error field. 826 "warning" - The message was successfully 827 processed but some sort of 828 exceptional condition occurred. 829 Further information is contained 830 in a Warning field. 832 5.3.1 Message Disposition Notification Extensions 834 The following "extension field" will be added in order to support 835 signed receipts for RFC 1767 MIME content type and multipart MIME 836 content types that include the RFC 1767 MIME content type. The 837 "extension field" defined below follows the "disposition-field" in the 838 MDN. 840 The "Received-content-MIC" extension field is set when the integrity 841 of the received message is verified. The MIC is the base64 encoded 842 quantity computed over the received message with a hash 843 function. For details of "what" the "Received-content-MIC" should be 844 calculated over, see Section 5.2.1. The algorithm used to calculate the 845 "Received-content-MIC" value MUST be the same as the "micalg" value 846 used by the sender in the multipart/signed message. When no signature 847 is received, then it is RECOMMENDED that the SHA1 algorithm be used 848 to calculate the MIC on the received message or message contents. 850 This field is set only when the contents of the message are processed 851 successfully. This field is used in conjunction with the recipient's 852 signature on the MDN in order for the sender to verify "non-repudiation 853 of receipt". 855 - extension field = "Received-content-MIC" ":" MIC 857 where: 859 = "," 861 = the result of the one way hash function, base64 862 encoded. 864 MIME-based Secure EDI 8 July 199 866 < micalg> = the micalg value defined in RFC1847, an IANA registered 867 MIC algorithm ID token. 869 5.3.2 Disposition Mode, Type, and Modifier Use 871 Guidelines for use of the "disposition-mode", "disposition-type", and 872 "disposition-modifier" fields within Internet EDI are discussed in 873 this section. The "disposition-mode", "disposition-type', and 874 "disposition-modifier' fields are described in detail in RFC 2298. 875 The "disposition-mode', "disposition-type" and 876 "disposition-modifier" values SHOULD be used as follows: 878 5.3.2.1 Successful Processing 880 When the request for a receipt or signed receipt, and the 881 received message contents are successfully processed by the receiving 882 EDI UA, a receipt or MDN SHOULD be returned with the "disposition- 883 type" set to 'processed'. When the MDN is sent automatically by the 884 EDI UA, and there is no explicit way for a user to control the sending of 885 the MDN, then the first part of the "disposition-mode" should be set 886 to "automatic-action". When the MDN is being sent under user 887 configurable control, then the first part of the "disposition-mode" 888 should be set to "manual-action". Since a request for a signed receipt 889 should always be honored, the user MUST not be allowed to configure 890 the UA to not send a signed receipt when the sender requests one. 892 The second part of the "disposition-mode" is set to "MDN-sent-manually" 893 if the user gave explicit permission for the MDN to be sent. Again, the 894 user MUST not be allowed to explicitly refuse to send a signed receipt 895 when the sender requests one. The second part of the "disposition- 896 mode" is set to "MDN-sent-automatically" whenever the EDI UA sends 897 the MDN automatically, regardless of whether the sending was under a 898 user�s, administrator�s, or under software control. 900 Since EDI content is generally handled automatically by the EDI UA, 901 a request for a receipt or signed receipt will generally return the 902 following in the "disposition-field": 904 Disposition: automatic-action/MDN-sent-automatically; processed 906 Note this specification does not restrict the use of the 907 "disposition-mode" to just automatic actions. Manual actions are 908 valid as long as it is kept in mind that a request for a signed 909 receipt MUST be honored. 911 5.3.2.2 Unprocessed Content 912 The request for a signed receipt requires the use of two 913 "disposition-notification-options", which specify the protocol 914 format of the returned signed receipt, and the MIC algorithm used 915 to calculate the hash over the MDN. The "disposition-field" values 916 that should be used in the case where the message content is being 917 rejected or ignored, for instance if the EDI UA determines that a 918 signed receipt cannot be returned because it does not support the 919 requested protocol format, so the EDI UA chooses not to process 920 the message contents itself, should be specified in the MDN 921 "disposition-field" as follows: 923 Disposition: "disposition-mode"; failed, Failure: unsupported format 925 The syntax of the "failed" "disposition-type" is general, allowing 926 the sending of any textual information along with the "failed" 927 "disposition-type". For use in Internet EDI, the following "failed" 928 values are defined: 930 "Failure: unsupported format" 931 "Failure: unsupported MIC-algorithms" 933 5.3.2.3 Content Processing Errors 935 When errors occur processing the received message content, the 936 "disposition-field" should be set to the "processed" "disposition- 937 type" value and the "error" "disposition-modifier" value. For use 938 in Internet EDI, the following "error" "disposition-modifier" values 939 are defined: 941 "Error: decryption-failed" - the receiver could not decrypt the 942 message contents. 944 "Error: authentication-failed" - the receiver could not authenticate 945 the sender. 947 "Error: integrity-check-failed" - the receiver could not verify 948 content integrity. 950 "Error: unexpected-processing-error" - a catch-all for any additional 951 processing errors. 953 An example of how the "disposition-field" would look when content 954 processing errors are detected is as follows: 956 Disposition: "disposition-mode"; processed/Error: decryption-failed 957 5.3.2.4 Content Processing Warnings 959 Situations arise in EDI where even if a trading partner cannot be 960 authenticated correctly, the trading partners still agree 961 to continue processing the EDI transactions. Transaction 962 reconciliation is done between the trading partners at a later 963 time. In the content processing warning situations as described 964 above, the "disposition-field' SHOULD be set to the "processed" 965 "disposition-type" value, and the "warning" "disposition-modifier" 966 value. For use in Internet EDI, the following "warning" 967 �disposition-modifier� values are defined: 969 "Warning: authentication-failed, processing continued" 971 An example of how the "disposition-field" would look when content 972 processing warnings are detected is as follows: 974 Disposition: "disposition-mode"; processed/Warning: 975 authentication-failed, processing continued 977 5.4 Message Disposition Notification Processing 979 5.4.1 Large File Processing 981 Large EDI Interchanges sent via SMTP can be automatically 982 fragmented by some message transfer agents. A subtype of message, 983 "partial", is defined in RFC 2045 [1] to allow large objects to be 984 delivered as separate pieces of mail and to be automatically 985 reassembled by the receiving user agent. Using message, "partial", 986 can help alleviate fragmentation of large messages by different 987 message transfer agents, but does not completely eliminate the 988 problem. It is still possible that a piece of a partial message, 989 upon re-assembly, may prove to contain a partial message as well. 990 This is allowed by the Internet standards, and it is 991 the responsibility of the user agent to re-assemble the fragmented 992 pieces. 994 It is RECOMMENDED that the size of the EDI Interchange sent via 995 SMTP be configurable so that if fragmentation does occur, then 996 message, "partial" can be used to send the large EDI Interchange 997 in smaller pieces. RFC 2045 [1] defines the use of Content-Type: 998 message/partial. Support of the message/partial content type for 999 use in Internet EDI is OPTIONAL. 1001 The receiving UA is required to re-assemble the original message 1002 before sending the message disposition notification to the 1003 original sender of the message. A message disposition notification 1004 is used to specify the disposition of the entire message that was 1005 sent, and should not be returned by a processing UA until the 1006 entire message is received, even if the received message requires 1007 re-assembling. 1009 In general, EDI content compresses well, since there is repetitive 1010 data in most EDI Interchanges. Instead of implementing the 1011 message/partial, compression of the EDI Interchange can be done 1012 after the signature is applied to the EDI Interchange, and before 1013 encryption. When no signature is applied, then compression is applied 1014 before the encryption. Compression is an alternative solution to 1015 implementing Content-Type: message/partial when sending large EDI 1016 Interchanges on the Internet. 1018 Applying compression before encryption strengthens cryptographic 1019 security since repetitious strings are reduced. This sequence of 1020 signature, compression, then encryption, or compression then 1021 encryption, is consistent with the order in which PGP 1022 implementations handle compression. 1024 Note: Compression is done automatically when using PGP encryption. 1026 The MIME standards [1], do not define a way in which to convey 1027 that a message has been compressed. However, RFC 2045 [1] does 1028 allow the definition of additional MIME header fields to further 1029 describe the content of a message. 1031 RFC 2068 [11], the HTTP/1.1 specification does define a Content- 1032 Encoding field that is primarily used to convey compression 1033 information: 1035 Content-Encoding = "Content-Encoding" ":" content-coding 1037 where content-coding can take on the values of "gzip" or "compress". 1039 The gzip compression standard is further described in RFC 1952 [12], 1040 and compress is the standard UNIX file compression program. Both 1041 gzip and compress are registered with IANA. 1043 Trading partners can adopt the use of the Content-Encoding header if 1044 they need to compress their EDI data and convey the compression 1045 type to their trading partners. 1047 5.4.2 Example 1049 The following is an example of a signed receipt returned by a UA 1050 after successfully processing a MIME EDI content type. The sending 1051 trading partner has requested a return signed receipt. 1053 MIME-based Secure EDI 8 July 199 1055 This example follows the S/MIME application/pkcs-7-signature 1056 format. 1058 NOTE: This example is provided as an illustration only, and is 1059 not considered part of the protocol specification. If an example 1060 conflicts with the protocol definitions specified above or in the 1061 other referenced RFCs, the example is wrong. 1063 To: 1064 Subject: 1065 From: 1066 Date: 1067 Mime-Version: 1.0 1068 Content-Type: multipart/signed; boundary="separator"; 1069 micalg=sha1; protocol="application/pkcs7-signature" 1071 --separator 1072 &Content-Type: multipart/report; report-type=disposition 1073 & notification; boundary = "xxxxx" 1074 & 1075 &--xxxxx 1076 &Content-Type: text/plain 1077 & 1078 &The message sent to Edi Recipient 1079 &has been received, the EDI Interchange was successfully 1080 &decrypted and its integrity was verified. In addition, the 1081 &sender of the message, Edi Sender 1082 &was authenticated as the originator of the message. There is 1083 &no guarantee however that the EDI Interchange was 1084 &syntactically correct, or was received by the EDI 1085 &application. 1086 & 1087 &--xxxxx 1088 &Content-Type: message/disposition-notification 1089 & 1090 &Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0) 1091 &Original-Recipient: rfc822; Edi_Recipient@edicorp.com 1092 &Final-Recipient: rfc822; Edi_Recipient@edicorp.com 1093 &Original-Message-ID: <17759920005.12345@edicorp.com> 1094 &Disposition: automatic-action/MDN-sent-automatically; processed 1095 &Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1 1096 & 1097 &--xxxxx 1098 &Content-Type: message/rfc822 1099 & 1100 &To: 1101 &Subject: 1102 & 1103 & [additional header fields go here] 1104 & 1105 &--xxxxx-- 1107 --separator 1108 Content-Type: application/pkcs7-signature; name=smime.p7s; 1109 Content-Transfer-Encoding: base64 1110 Content-Disposition: attachment; filename=smime.p7s 1112 @ContentType = SignedData 1113 @version = Version 1114 @digestAlgorithms = DigestAlgorithmIdentifiers 1115 @signerInfos = SignerInfo 1116 --separator-- 1118 Notes: 1120 -The lines preceded with "&" is what the signature is calculated 1121 over. 1123 -The text preceded by "@" indicates PKCS#7 defined fields and types. 1125 (For details on how to prepare the multipart/signed with protocol 1126 = "application/pkcs7-signature" see the "S/MIME Message 1127 Specification, PKCS Security Services for MIME".) 1129 Note: As specified by RFC 1892 [10], returning the original or 1130 portions of the original message in the third body part of the 1131 multipart/report is not required. This is an optional body part. It is 1132 RECOMMENDED that the received headers from the original 1133 message be placed in the third body part, as they can be helpful in 1134 tracking problems. 1136 Also note that the textual first body part of the multipart/report 1137 can be used to include a more detailed explanation of the error 1138 conditions reported by the disposition headers. The first body 1139 part of the multipart/report when used in this way, allows a 1140 person to better diagnose a problem in detail. 1142 6. Public key certificate handling 1144 6.1 Near term approach 1146 In the near term, the exchange of public keys and certification 1148 MIME-based Secure EDI 8 July 199 1150 of these keys must be handled as part of the process of 1151 establishing a trading partnership. The UA and/or EDI application 1152 interface must maintain a database of public keys used for 1153 encryption or signatures, in addition to the mapping between EDI 1154 trading partner ID and RFC 822 [3] email address. The procedures for 1155 establishing a trading partnership and configuring the secure EDI 1156 messaging system might vary among trading partners and software 1158 packages. 1160 For systems which make use of X.509 certificates, it is RECOMMENDED 1161 that trading partners self-certify each other if an agreed upon 1162 certification authority is not used. It is highly RECOMMENDED that 1163 when trading partners are using S/MIME, that they also exchange 1164 public key certificates using the recommendations specified in the 1165 S/MIME Implementation Guide Version 2. The message formats and 1166 S/MIME conformance requirements for certificate exchange are 1167 specified in this document. 1169 This applicability statement does NOT require the use of a 1170 certification authority. The use of a certification authority 1171 is therefore OPTIONAL. 1173 6.2 Long term approach 1175 In the long term, additional Internet-EDI standards may be 1176 developed to simplify the process of establishing a trading 1177 partnership, including the third party authentication of trading 1178 partners, as well as attributes of the trading relationship. 1180 7. Acknowledgments 1182 The authors would like to extend special thanks to Carl Hage, 1183 Jun Ding, Dale Moberg, and Karen Rosenthal for providing the team 1184 with valuable, and very thorough feedback. Without participants like 1185 those cited above, these efforts become hard to complete in a way 1186 useful to the users and implementers of the technology. 1188 In addition, the authors would like to thank Harald Alvestrand, Jim Galvin, 1189 and Roger Fajman for their guidance and input. 1191 8. References 1193 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1194 Part One: Format of Internet Message Bodies", RFC 2045, December 02, 1996. 1196 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1197 Part Two: Media Types", RFC 2046, December 02, 1996. 1199 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) 1200 Part Five: Conformance Criteria and Examples", RFC 2049 , December 02, 1201 1996. 1203 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 1204 2, 1995. 1206 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 1207 Messages", STD 11, RFC 822, August 13, 1982. 1209 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 1210 2015, Sept. 1996. 1212 [5] R. Fajman, "An Extensible Message Format for Message Disposition 1213 Notifications", RFC 2298, March 1998. 1215 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts 1216 for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 1217 3, 1995 1219 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 1220 August 1, 1982. 1222 [8] S. Dusse, "S/MIME Version 2 Message Specification; PKCS Security 1223 Services for MIME", RFC 2311 RFC 2312, March 1998. 1225 [9] C. Shih, "Requirements for Inter-operable Internet EDI", 1226 Internet draft: draft-ietf-ediint-req03.txt July 1997. 1228 [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting 1229 of Mail System Administrative Messages", RFC 1892, January 15, 1230 1996. 1232 [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext 1233 Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. 1235 [12] L. Deutsch, "GZIP File Format Specification Version 4.3", RFC 1952, 1236 May 23, 1996. 1238 9. Authors' Addresses 1240 Chuck Shih 1241 chuck.shih@gartner.com 1242 Gartner Group. 1243 251 River Oaks Parkway 1244 San Jose, CA 95134-1913 USA 1246 Mats Jansson 1247 mjansson@agathon.com 1248 LiNK 1249 2317 Broadway, Suite 330 1250 Redwood City, CA 94063 USA 1252 Rik Drummond 1253 drummond@onramp.com 1254 The Drummond Group 1255 5008 Bentwood Ct. 1256 Ft. Worth, TX 76132 USA